IBM WebSphere Developer Technical Journal: Securing connections between WebSphere Application Server and WebSphere MQ -- Part 2

Secure the WebSphere MQ link using the service integration bus

This article demonstrates how to configure an SSL connection between the IBM® WebSphere® Application Server service integration bus and an IBM WebSphere MQ queue manager running on Windows® XP.

Share:

Martin Smithson (msmiths@uk.ibm.com), Senior IT Specialist, IBM

Martin Smithson is a Senior IT Specialist with IBM Software Group in the UK. He has nine years of experience working in the IT Industry and has spent the last four years working as a technical consultant for the EMEA IBM Software Services for WebSphere team. His areas of expertise include the architecure, design and development of J2EE applications. He is also an expert on IBM WebSphere Application Server. He holds a degree in Software Engineering from City University in London. He is also a co-author of the WebSphere Application Server V6: System Management & Configuration Handbook


developerWorks Contributing author
        level

18 January 2006

Also available in Chinese

From the IBM WebSphere Developer Technical Journal.

Introduction

The Java™ 2 Platform Enterprise Edition (J2EE™) Specification, Version 1.3, required software vendors to include a Java Message Service (JMS) provider within their application server products. IBM WebSphere Application Server V5.0 provided this support through the WebSphere JMS provider, a reduced footprint version of IBM WebSphere MQ and IBM WebSphere Business Integration Event Broker. However, the WebSphere JMS provider was unable to communicate with other WebSphere MQ queue managers.

WebSphere Application Server V6.0 addresses this limitation of the WebSphere JMS provider by replacing it with the service integration bus. The service integration bus enhances the messaging capabilities that are embedded within WebSphere Application Server beyond that provided within WebSphere Application Server V5.0. One of the key enhancements provided by the service integration bus is the ability to communicate with existing WebSphere MQ queue managers. This functionality enables the seamless integration of messaging applications running inside the WebSphere Application Server V6.0 environment with messaging applications running inside the WebSphere MQ environment.

This article demonstrates how to configure an SSL connection between a messaging engine running within WebSphere Application Server V6.0 and a WebSphere MQ queue manager. This article assumes you have a working knowledge of both WebSphere Application Server V6.0, WebSphere MQ V5.3 or V6.0, that you understand the concepts and architecture of the service integration bus component, and that you have worked through Part 1: Using the WebSphere MQ JMS provider.


WebSphere MQ link overview

Defining a foreign bus on a service integration bus simply defines a link between the two buses at an architectural level. When the foreign bus in question represents a WebSphere MQ network, the link is implemented at run time by establishing sender and receiver channels between a specific messaging engine and a WebSphere MQ queue manager. These channels are configured on a messaging engine by defining a WebSphere MQ link.

To a messaging engine configured with a WebSphere MQ link, the WebSphere MQ queue manager appears to be a foreign bus. To the WebSphere MQ queue manager, the messaging engine appears to be another WebSphere MQ queue manager. When configuring a WebSphere MQ link, an administrator must specify a virtual queue manager name. This is the queue manager name by which the messaging engine will be known to the remote WebSphere MQ queue manager. The WebSphere MQ queue manager is completely unaware that it is communicating with a messaging engine.

WebSphere MQ link sender channel

The WebSphere MQ link sender channel establishes a connection to a receiver channel on the target WebSphere MQ queue manager. It converts messages from the format used within the service integration bus to the format used by WebSphere MQ, and then sends these messages to the receiver channel on the target WebSphere MQ queue manager.

When you configure a WebSphere MQ link sender channel, you are required to specify the following information:

  • A name for the channel, which must exactly match, including case, the name of the receiver channel defined on the target WebSphere MQ queue manager.
  • The host name or IP address of the machine hosting the target WebSphere MQ queue manager.
  • The port number on which the target WebSphere MQ queue manager is listening for inbound communication requests.
  • An outbound transport chain.

If the receiver channel on the target WebSphere MQ queue manager accepts only SSL connections, you must associate the transport chain with a suitably compatible set of SSL credentials.

WebSphere MQ link receiver channel

The WebSphere MQ link receiver channel enables a sender channel within a WebSphere MQ queue manager to establish a connection to a messaging engine within the service integration bus. It converts messages from the format used within WebSphere MQ to the format used by the service integration bus. The WebSphere MQ link receiver channel emulates the behavior of a receiver channel in WebSphere MQ.

When configuring a WebSphere MQ link receiver channel, the following information is required:

  • A name for the channel, which must exactly match, including case, the name of the sender channel defined on the target WebSphere MQ queue manager.

The inbound transport chain, with which the sender channel on the WebSphere MQ queue manager communicates, is dependent on the configuration of the WebSphere MQ sender channel. The WebSphere MQ administrator should be consulted to ensure that the sender channel is configured appropriately. The InboundBasicMQLink transport chain defaults to listening on port 5558 for connections from WebSphere MQ, and the InboundSecureMQLink transport chain defaults to listening on port 5578 for connections from WebSphere MQ.


WebSphere MQ link security

An insecure WebSphere MQ link communicates with WebSphere MQ using insecure transport chains. The WebSphere MQ link sender channel communicates with the WebSphere MQ receiver channel using the OutboundBasicMQLink transport chain. The WebSphere MQ sender channel communicates with the WebSphere MQ link receiver channel using the InboundBasicMQLink transport chain. The InboundBasicMQLink transport chain listens on the port associated with the SIB_MQ_ENDPOINT_ADDRESS, which defaults to 5558. This configuration is shown in Figure 1.

Figure 1. WebSphere MQ link architecture
WebSphere MQ link architecture

To establish an SSL connection between WebSphere MQ and WebSphere Application Server, this configuration must be modified to ensure that secure transport chains within WebSphere Application Server are be used. A number of suitable transport chains are created by default when creating an application server. These are:

  • InboundSecureMQLink
  • OutboundSecureMQLink

We will need to modify the configuration of the WebSphere MQ link sender channel so that it communicates with the WebSphere MQ receiver channel using the OutboundSecureMQLink transport chain. We will also need to modify the configuration of the WebSphere MQ sender channel, so that it communicates with the WebSphere MQ link receiver channel, using the InboundSecureMQLink transport chain. The InboundSecureMQLink transport chain listens on the port associated with the SIB_MQ_ENDPOINT_SECURE_ADDRESS, which defaults to 5578. The configuration for the secure WebSphere MQ link is shown in Figure 2.

Figure 2. Secure WebSphere MQ link architecture
Secure WebSphere MQ link architecture

Both of these channels are associated with an SSL repertoire. This SSL repertoire defines the location of the key file and trust file that will be used by these transport chains, when establishing SSL connections with clients or servers. For example, when the WebSphere MQ sender channel attempts to establish a connection with the WebSphere MQ link receiver channel, the certificate contained within the key file will be presented to WebSphere MQ during the SSL handshake. Because the key store for the WebSphere MQ queue manager contains the corresponding signer certificate, it will trust the certificate from WebSphere Application Server and an SSL connection will be established.

It is also possible to define your own transport chains for communicating with WebSphere MQ. However, this is considered to be an advanced administrative task and is outside the scope of this article.


Configure WebSphere MQ

Part 1 of this series described how to obtain a certificate for the WebSphere MQ queue manager and how to configure the WebSphere MQ queue manager to use this certificate when establishing SSL connections. When configuring the sender and reciever channels to communicate with the service integration bus, the WebSphere MQ queue manager will make use of the same certificates.

The following steps must be performed to configure the sender and receiver channels within the WebSphere MQ queue manager:

  1. Define the WebSphere MQ sender channel
  2. Define the WebSphere MQ receiver channel
  3. Define the WebSphere MQ transmission queue
  4. Define the remote queue defintion

The following sections describe these tasks in detail.

A. Define the WebSphere MQ sender channel

The WebSphere MQ sender channel will be used to send messages from the WebSphere MQ queue manager to the service integration bus. We will use the default value for the InboundSecureMQLink when configuring the sender channel. To configure the WebSphere MQ sender channel:

  1. Logon to the machine on which WebSphere MQ is running.

  2. From a command window or shell, execute the runmqsc command, as follows:

    runmqsc testJMSQMgr
  3. On the MQSC command line, enter the following command to define the sender channel, where 5578 is the port number of the InboundSecureMQLink transport for the messaging engine:

    DEFINE CHANNEL(MQ_TO_WAS)
           CHLTYPE(SDR)
           CONNAME('localhost(5578)')
           XMITQ(QM_was)
           TRPTYPE(TCP)
           SSLCIPH(TRIPLE_DES_SHA_US)
           SSLPEER('CN=jmsclient,OU=issw,O=ibm,C=US')

    Do not exit the MQSC environment as we will be using it in the sections that follow.

CipherSpecs and SSLPEERs

The CipherSpec that we have used within this article, TRIPLE_DES_SHA_US, provides a relatively strong encryption algorithm. You should evaluate your organization's security needs and consider alternative ciphers if necessary.

WebSphere MQ uses the SSLPEER attribute on the channel to check which Distinguished Name values of client certificates it can accept. In this case, the WebSphere Application Server client certificate matches the DN 'CN=jmsclient, ou=issw, o=ibm, c=US' (which is listed on the SSLPEER attribute, so it is a trusted identity to WebSphere MQ). Without an SSLPEER being set, WebSphere MQ would accept any other client certificate issued by the VeriSign trial CA.

B. Define the WebSphere MQ receiver channel

The WebSphere MQ receiver channel will be used to receive messages from the service integration bus. To configure the WebSphere MQ receiver channel:

  1. On the MQSC command line, enter the following command to define the receiver channel:

    DEFINE CHANNEL(WAS_TO_MQ)
           CHLTYPE(RCVR)
           TRPTYPE(TCP)
           SSLCAUTH(REQUIRED)
           SSLCIPH(TRIPLE_DES_SHA_US)
           SSLPEER('CN=jmsclient,OU=issw,O=ibm,C=US')

    Do not exit the MQSC environment as we will be using it in the sections that follow.

C. Define the WebSphere MQ transmission queue

WebSphere MQ transmission queues are queues that temporarily store messages that are destined for a remote queue manager. At least one transmission queue must be defined for each remote queue manager to which the local queue manager is to send messages directly. To configure the WebSphere MQ transmission queue:

  1. On the MQSC command line, enter the following command to define the transmission queue:

    DEFINE QLOCAL(QM_WAS)
           USAGE(XMITQ)
           TRIGGER
           INITQ(SYSTEM.CHANNEL.INITQ)
           TRIGDATA(MQ_TO_WAS)

    Do not exit the MQSC environment as we will be using it in the sections that follow.

D. Define the remote queue defintion

A remote queue definition is a queue definition on the local queue manager that refers to a queue on a remote queue manager, or in this case, a queue on the service integration bus. To configure the remote queue definition:

  1. On the MQSC command line, enter the following command to define the remote queue definition:

    DEFINE QREMOTE(TOWASQ)
           RNAME(FROMMQQ)
           RQMNAME(QM_WAS)
           XMITQ(QM_WAS)
  2. Type end to exit the MQSC environment.


Create the SSL repertoire for the WebSphere MQ link

As discussed in the WebSphere MQ link security section, the InboundSecureMQLink and OutboundSecureMQLink transport chains are associated with an SSL repertoire. To be more specific, they are associated with the default SSL repertoire for the cell. In Part 1, this SSL repertoire was configured to use the key file (WASServerKeyFile) and trust file (WASServerTrustFile) that we created. This SSL repertoire is used by the WebSphere Application Server processes within a cell to encrypt the data that is passed between them when security is enabled. Do not use this SSL repertoire when configuring security for the WebSphere MQ link, because any changes to the SSL repertoire required by the WebSphere MQ link would also impact the inter-process communications within the cell.

For this reason, we will configure a new SSL repertoire that will be used by the InboundSecureMQLink and OutboundSecureMQLink transport chains. For simplicity, this new SSL repertoire will use the same key file and trust file as before. However, it is possible to make use of a different key file and trust file for encrypting the communication between WebSphere Application Server and WebSphere MQ.

Also, since we have specified a CipherSpec of TRIPLE_DES_SHA_US on the sender and receiver channels within the WebSphere MQ queue manager, we must also specify a corresponding Cipher Suite on the new SSL repertoire used by the InboundSecureMQLink and OutboundSecureMQLink transport chains to be able to establish the SSL connection. The table below shows a list of WebSphere MQ CipherSpecs and the associated JSSE CipherSuite.

WebSphere MQ CipherSpecAssociated JSSE CipherSuite
NULL_MD5SSL_RSA_WITH_NULL_MD5
NULL_SHASSL_RSA_WITH_NULL_SHA
RC4_MD5_EXPORTSSL_RSA_EXPORT_WITH_RC4_40_MD5
RC4_MD5_USSSL_RSA_WITH_RC4_128_MD5
RC4_SHA_USSSL_RSA_WITH_RC4_128_SHA
RC2_MD5_EXPORTSSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
DES_SHA_EXPORTSSL_RSA_WITH_DES_CBC_SHA
TRIPLE_DES_SHA_USSSL_RSA_WITH_3DES_EDE_CBC_SHA

The following steps must be performed to create a new SSL repertoire and configure the InboundSecureMQLink and OutboundSecureMQLink transport chains to use it:

  1. Create the SSL repertoire
  2. Modify the InboundSecureMQLink
  3. Modify the OutboundSecureMQLink

The following sections describe these tasks in detail.

A. Create the SSL repertoire

To create a SSL repertoire:

  1. Logon to the WebSphere Application Server administrative console.

  2. Select Security => SSL in the left navigation pane.

  3. In the main content pane, click the New JSSE repertoire button (Figure 3).

    Figure 3. Creating an SSL repertoire
    Creating an SSL repertoire
  4. Enter WMQLinkSSLSettings in the Alias entry field.

  5. In the Cipher suites section, select the SSL_RSA_WITH_3DES_EDE_CBC_SHA cipher suite in the list on the left.

  6. Click Add >>.

  7. The selected SSL_RSA_WITH_3DES_EDE_CBC_SHA cipher suite will now appear in the list on the right (Figure 4). Specifying a cipher suite in this manner overrides any cipher suites that are associated with the specifed Security Level.

    Figure 4. Specifying a Cipher Suite
    Specifying a Cipher Suite
  8. Specify the full path to the WASServerKeyFile.jks file in the Key file name entry field.

  9. Enter the password for the key file in the Key file password entry field and ensure that JKS is specified as the Key file format (Figure 5).

    Figure 5. Specifying the key file
    Specifying the key file
  10. Specify the full path to the WASServerTrustFile.jks file in the Trust file name entry field.

  11. Enter the password for the trust file in the Trust file password entry field and ensure that JKS is specified as the Trust file format (Figure 6).

    Figure 6. Specifying the trust file
    Specifying the trust file
  12. Click OK.

  13. The new SSL repertoire will appear in the list of SSL repertoires defined within the cell. Notice that the new SSL repertoire has been defined at the cell level.

  14. Save the changes and synchronize them with the nodes.

The InboundSecureMQLink transport chain needs to modified to associate it with the new SSL repertoire. This can be done using the WebSphere administrative console. To modify the InboundSecureMQLink transport chain:

  1. Select Servers => Application servers in the left navigation pane.

  2. In the main content pane, select the server1 link from the list of application servers.

  3. Under Server messaging, select WebSphere MQ link inbound transports (Figure 7).

    Figure 7. Viewing the WebSphere MQ link inbound transports
    Viewing the WebSphere MQ link inbound transports
  4. Select the InboundSecureMQLink link from the list of transport chains.

  5. Select the SSL Inbound Channel (SIB_SSL_MQFAP) link from the list of transport channels (Figure 8).

    Figure 8. Viewing the SSL Inbound Channel
    Viewing the SSL Inbound Channel
  6. Select the new SSL repertoire from the SSL repertoire drop down list (Figure 9).

    Figure 9. Specifying the SSL repertoire
    Specifying the SSL repertoire
  7. Click OK.

  8. Save the changes and synchronize them with the nodes.

The OutboundSecureMQLink transport chain needs to be modified to associate it with the new SSL repertoire. At present, this can only be achieved using the wsadmin command line environment. To modify the OutboundSecureMQLink transport chain:

  1. Logon to the machine on which the WebSphere Application Server deployment manager is running.

  2. From a command window or shell, change to the <WAS_PROFILE_ROOT>\bin directory and execute the wsadmin command, as follows:

    wsadmin localhost 8879
  3. Because global security is enabled, you will be prompted for a user ID/password. Enter your WebSphere Application Server administrator ID and password and select OK.

  4. The first thing we need to do is identify which outbound channel needs to be modified. On the wsadmin command line, enter the following command:

    Click to see code listing

    wsadmin>$AdminConfig list SSLOutboundChannel
    
    SIB_SSL_JFAP_SSL_OUT(cells/MQJmsSSLCell/nodes/MQJmsSSLNode/servers/server1|server.xml#SSLOutboundChannel_
    1132565466173)
    SIB_SSL_JFAP_TUN_SSL_OUT(cells/MQJmsSSLCell/nodes/MQJmsSSLNode/servers/server1|server.xml#SSLOutboundChan
    nel_1132565466174)
    SIB_SSL_MQFAP_SSL_OUT(cells/MQJmsSSLCell/nodes/MQJmsSSLNode/servers/server1|server.xml#SSLOutboundChannel
    _1132565466172)
  5. Notice that three SSL outbound channels are defined for server1 (if you have more servers defined within your environment, you will see several more entries in the list). We are interested in the SIB_SSL_MQFAP_SSL_OUT outbound channel, which is the third entry in the list shown above. To simplify subsequent commands, we will store the ID of this outbound channel in a variable. On the wsadmin command line, enter the following command:

    Click to see code listing

    wsadmin>set outboundSecureMQLink [lindex [$AdminConfig list SSLOutboundChannel] 2]
    
    SIB_SSL_MQFAP_SSL_OUT(cells/MQJmsSSLCell/nodes/MQJmsSSLNode/servers/server1|server.xml#SSLOutboundChannel_
    1132565466172)
  6. The outboundSecureMQLink variable now contains the ID of the SIB_SSL_MQFAP_SSL_OUT outbound channel (notice that the lindex command works on zero indexed lists). Now we need to modify this channel to use the new SSL repertoire. On the wsadmin command line, enter the following command:

    wsadmin>$AdminConfig modify $outboundSecureMQLink {{sslConfigAlias MQJmsSSLCell/WMQLinkSSLSettings}}
    wsadmin>$AdminConfig save
    wsadmin>quit

    In the modify command above, notice that the name of the SSL repertoire was scoped to the cell. Modify the name specified to match the name of the cell within your environment.


Configure the service integration bus

The following steps must be performed to configure the service integration bus within the WebSphere Application Server environment:

The following sections describe these tasks in detail.

A. Create the service integration bus

End-to-End security

To simplify this example, no Inter-engine transport chain has been specified for the bus. As a result, if additional members were added to the bus, the communications between the corresponding messaging engines would not be encrypted. If you need to provide end-to-end security for messages as they flow across the bus, please refer to WebSphere Application Server V6 advanced security hardening.

A service integration bus, or bus, within WebSphere Application Server V6 is simply an architectural concept. It gives an administrator the ability to group a collection of resources together that provide the messaging capabilities of the bus. At run time, the bus presents these cooperating messaging resources to applications as a single entity, hiding from those applications the details of how the bus is configured and where on the bus the different resources are located.

Resources are created within, or added to, the scope of a specific bus. Simply defining a bus within a WebSphere cell has no run time impact on any of the components running within a cell. It is not until members are added to a bus that any of the run time components within an application server are affected.

To create a service integration bus:

  1. Select Service Integration => Buses in the left navigation pane.

  2. In the main content pane, click the New button (Figure 10).

    Figure 10. Creating a service integration bus
    Creating a service integration bus
  3. Enter TestBus in the Name entry field (Figure 11).

    Figure 11. Specifying a bus name
    Specifying a bus name
  4. Click the OK button.

  5. Save changes to the master configuration and synchronize the changes with the nodes.

  6. The new service integration bus, TestBus, should now appear in the list of buses (Figure 12).

    Figure 12. Service integration bus list
    Service integration bus list

B. Add members to the service integration bus

A bus member is simply an application server, or cluster of application servers, that has been added as a member of a bus. Adding an application server, or cluster of application servers, as a member of a bus automatically defines a number of resources on the bus member in question. In terms of the functionality provided by a service integration bus, the most important of the resources that are automatically defined is a messaging engine.

To add a member to the service integration bus:

  1. Select Service Integration => Buses in the left navigation pane.

  2. In the main content pane, select the TestBus link from the list of buses.

  3. Under Topology, select the Bus members link (Figure 13).

    Figure 13. Adding a bus member
    Adding a bus member
  4. Click the Add button.

  5. In Step 1: Select server or cluster of the Add a new bus member wizard, ensure that the Server radio button is selected.

  6. Select server1 from the Server drop down list (Figure 14).

    Figure 14. Selecting the new bus member
    Selecting the new bus member
  7. Click Next

  8. Click Finish

  9. Save changes to the master configuration and synchronize the changes with the nodes.

C. Define the foreign bus

A service integration bus can be configured to connect to, and exchange messages with, other messaging networks. To do this, a foreign bus must be configured. A foreign bus encapsulates information related to the remote messaging network, such as the type of the foreign bus and whether messaging applications are allowed to send messages to the foreign bus. A foreign bus can represent:

  • A service integration bus in the same WebSphere Application Server V6 cell as the local bus.
  • A service integration bus in a different WebSphere Application Server V6 cell from the local bus.
  • A WebSphere MQ network.

To define the foreign bus:

  1. Select Service Integration => Buses in the left navigation pane.

  2. In the main content pane, select the TestBus link from the list of buses.

  3. Under Topology, select the Foreign buses link (Figure 15).

    Figure 15. Adding a foreign bus
    Adding a foreign bus
  4. Click the New button.

  5. In Step 1: Foreign bus properties of the Create foreign bus routing definition wizard, enter testJMSQMgr in the Name entry field.

  6. Make sure that the Send allowed check box is checked (Figure 16).

    Figure 16. Specifying a foreign bus name
    Specifying a foreign bus name
  7. Click Next

  8. In Step 2: Routing definition type, select Direct, WebSphere MQ Link in the Routing type drop down list (Figure 17).

    Figure 17. Specifying the routing definition type
    Specifying the routing definition type
  9. Click Next

  10. In Step 3: Routing definition properties, enter a user ID in the Inbound user ID entry field (Figure 18). This user ID must be a valid user ID in the WebSphere User Registry. This user ID will be assigned to messages that arrive on the service integration bus from the WebSphere MQ queue manager and will be used to determine whether the message is authorized to be placed on the target bus destination.

    Figure 18. Specifying an Inbound User ID
    Specifying an Inbound User ID
  11. Click Next

  12. Click Finish

  13. Save changes to the master configuration and synchronize the changes with the nodes.

D. Create destinations

A destination within a service integration bus is a logical address to which applications can attach as message producers, message consumers, or both, in order to exchange messages. The types of destination that we will be configuring are:

  • Queue destinations are destinations that can be configured for point-to-point messaging.
  • Alias destinations are destinations that can be configured to refer to another destination, potentially on a foreign bus. They can provide an extra level of indirection for messaging applications. An alias destination can also be used to override some of the values specified on the target destination, such as default reliability and maximum reliability.

To define the destinations:

  1. Select Service Integration => Buses in the left navigation pane.

  2. In the main content pane, select the TestBus link from the list of buses.

  3. Under Destination resources, select the Destinations link (Figure 19).

    Figure 19. Creating a destination
    Creating a destination
  4. Click the New button.

  5. Select the Queue radio button to specify the destination type (Figure 20).

    Figure 20. Selecing the queue destination type
    Selecting the queue destination type
  6. Click the Next button.

  7. In Step 1: Set queue attributes of the Create new queue wizard, enter FROMMQQ in the Identifier entry field (Figure 21).

    Figure 21. Specifying the queue identifier
    Specifying the queue identifier
  8. Click the Next button.

  9. In Step 2: Assign the queue to a bus member, select server1 from the Bus member drop down list (Figure 22).

    Figure 22. Assigning the queue to a bus member
    Assigning the queue to a bus member
  10. Click the Next button.

  11. Click Finish

  12. The new queue destination will appear in the list of destinations for the bus. We now need to create an Alias destination that acts as an alias for a queue hosted by the WebSphere MQ queue manager.

  13. Click the New button.

  14. Select the Alias radio button to specify the destination type (Figure 23).

    Figure 23. Selecting the Alias destination type
    Selecting the Alias destination type
  15. Click the Next button.

  16. In Step 1: Set alias destination attributes of the Create new alias destination wizard, enter TOMQQ in the Identifier entry field.

  17. Select TestBus from the Bus drop down list.

  18. Select testJMSQMgr in the Target bus drop down list.

  19. Select other, please specify in the Target identifier drop down list and then enter FROMWASQ in the entry field that appears (Figure 24). This is name of the queue on the WebSphere MQ queue manager for which this destination is an alias.

    Figure 24. Specifying the alias destination attributes
    Specifying the alias destination attributes
  20. Click the Next button.

  21. Click Finish

  22. Save changes to the master configuration and synchronize the changes with the nodes.

The WebSphere MQ link was described in detail above. To define the WebSphere MQ link :

  1. Select Service Integration => Buses in the left navigation pane.

  2. In the main content pane, select the TestBus link from the list of buses.

  3. Under Topology, select the Messaging engines link (Figure 25).

    Figure 25. Viewing the Messaging Engines within a Bus
    Viewing the Messaging Engines within a Bus
  4. There should only be one messaging engine listed for TestBus. Select the link for this messaging engine.

  5. Under Additional Properties, select the WebSphere MQ links link (Figure 26).

    Figure 26. Viewing the WebSphere MQ links for a messaging engine
    Viewing the WebSphere MQ links for a messaging engine
  6. Click the New button.

  7. In Step 1: General WebSphere MQ link properties of the Create new WebSphere MQ link wizard, enter TestJMSQMgrLink in the Name entry field.

  8. Select testJMSQMgr from the Foreign bus name drop down list.

  9. Enter QM_WAS in the Queue manager name entry field (Figure 27). The queue manager name entered here is the virtual queue manager name by which WebSphere MQ knows this messaging engine.

    Figure 27. Specifying general WebSphere MQ link properties
    Specifying general WebSphere MQ link properties
  10. Click the Next button.

  11. In Step 2: Sender channel WebSphere MQ link properties, enter WAS_TO_MQ in the Sender MQ channel name entry field. This name must match the name of the receiver channel configured within WebSphere MQ.

  12. Enter localhost in the Host name entry field.

  13. Enter 1414 in the Port entry field.

  14. Select OutboundSecureMQLink from the Transport chain drop down list (Figure 28). Recall that the OutboundSecureMQLink transport chain was associated with the WMQLinkSSLSettings SSL repertoire in the Creating the SSL Repertoire for the WebSphere MQ Link section, and that this SSL repertoire specifies a CipherSuite that corresponds to the CipherSpec defined on the WebSphere MQ sender and receiver channels.

    Figure 28. Specifying sender channel WebSphere MQ link properties
    Specifying sender channel WebSphere MQ link properties
  15. Click the Next button.

  16. In Step 3: Receiver channel WebSphere MQ link properties, enter MQ_TO_WAS in the Receiver MQ channel name entry field. This name must match the name of the sender channel configured within WebSphere MQ (Figure 29).

    Figure 29. Specifying receiver channel WebSphere MQ link properties
    Specifying receiver channel WebSphere MQ link properties
  17. Click the Next button.

  18. Click Finish

  19. Save changes to the master configuration and synchronize the changes with the nodes.


Configure the JMS administered objects

We have now configured all of the objects that we require on the service integration bus. However, before they can be used by the sample application, we need to define a number of JMS administered objects so that the sample application can interact with them using the JMS 1.1 API. We will also create two JMS queue objects for use by the sample application. The reason for this is that the sample application will now send messages to WebSphere MQ using the TOMQQ alias destination that we have configured, but it cannot browse messages on this alias. It can only browse messages on queue destinations hosted by the service integration bus to which it is connected. Therefore, we will create a second JMS queue object that the sample application will use to browse the FROMMQQ.

The following steps must be performed to configure the JMS administered objects within the WebSphere Application Server environment:

  1. Create the JMS queue connection factory
  2. Create the JMS queues

The following sections describe these tasks in detail.

End-to-End security

To simplify this example, no Target inbound transport chain has been specified for the connection factory. As a result, the communications between JMS clients and the service integration bus will not be encrypted. If you need to provide end-to-end security for messages as they flow across the bus, please refer to WebSphere Application Server V6 advanced security hardening.

A. Create the JMS queue connection factory

To define the JMS queue connection factory object:

  1. Select Resources => JMS Providers => Default messaging in the left navigation pane.

  2. In the main content pane, under Connection Factories, select the JMS connection factory link (Figure 30).

    Figure 30. Creating a JMS connection factory
    Creating a JMS connection factory
  3. Click the New button.

  4. Within the Administration properties section, enter TestBusCF in the Name entry field.

  5. Enter jms/TestBusCF in the JNDI name entry field.

  6. Within the Connection properties section, select TestBus from the Bus name drop down list (Figure 31).

    Figure 31. Specifying JMS connection factory properties
    Specifying JMS connection factory properties
  7. Click OK.

  8. Save changes to the master configuration and synchronize the changes with the nodes.

B. Create the JMS queues

To define the JMS queue administered objects:

  1. Select Resources => JMS Providers => Default messaging in the left navigation pane.

  2. In the main content pane, under Destinations, select the JMS queue link.

  3. Click the New button.

  4. Within the Administration properties section, enter FROMMQQ in the Name entry field.

  5. Enter jms/FROMMQQ in the JNDI name entry field.

  6. Within the Connection properties section, select TestBus from the Bus name drop down list.

  7. Select FROMMQQ from the Queue name drop down list (Figure 32).

    Figure 32. Specifying JMS queue properties
    Specifying JMS queue properties
  8. Click OK.

  9. Click the New button.

  10. Within the Administration properties section, enter TOMQQ in the Name entry field.

  11. Enter jms/TOMQQ in the JNDI name entry field.

  12. Within the Connection properties section, select TestBus from the Bus name drop down list.

  13. Select TOMQQ from the Queue name drop down list (Figure 33).

    Figure 33. Specifying JMS queue properties
    Specifying JMS queue properties
  14. Click OK.

  15. Save changes to the master configuration and synchronize the changes with the nodes.


Modify the deployment properties for the sample application

The sample application is currently configured to make use of resources configured on the WebSphere MQ JMS provider. For the sample application to be able to access the resources on the service integration bus, several steps must be performed. These steps are not simply restricted to modifying the resource reference mappings for the application. Several security related operations must also be performed. This is due to the fact that when global security is enabled within WebSphere Application Server, all service integration bus resources are also secured. Access to most of these resources is restricted to users authenticated to WebSphere. Administrators can further restrict access to the service integration bus resources to only permit access by specific users or groups.

The following steps must be performed to modify the deployment properties for the sample application:

  1. Define a J2C authentication alias for connecting to the service integration bus
  2. Modify the resource reference mappings for the sample application
  3. Modify the resource environment entry reference mappings for the sample application
  4. Modify the foreign bus role

The following sections describe these tasks in detail.

A. Define a J2C authentication alias for connecting to the service integration bus

The first step is to define a J2C authentication alias. This alias will be used by the sample application so that it can authenticate to the service integration bus when it attempts to connect. To create a J2C authentication alias:

  1. Select Security => Global security in the left navigation pane.

  2. In the main content pane, under Authentication, select JAAS Configuration => J2C Authentication data (Figure 34).

    Figure 34. Creating a J2C authentication alias
    Creating a J2C authentication alias
  3. Click the New button.

  4. Enter sibusAlias in the Alias entry field.

  5. Enter a suitable user ID in the User ID entry field. This user ID must be a valid user ID in the WebSphere User Registry.

  6. Enter the password for this user in the Password entry field (Figure 35).

    Figure 35. Specifying J2C Authentication alias properties
    Specifying J2C Authentication alias properties
  7. Click OK.

  8. Save changes to the master configuration and synchronize the changes with the nodes.

B. Modifying the resource reference mappings for the sample application

We now need to modify the resource reference mappings used by the sample application so that it can connect to the service integration bus. To do this:

  1. Select Applications => Enterprise Applications in the left navigation pane.

  2. In the main content pane, select JmsTestEAR.

  3. Under Additional Properties, select Map resource references to resources (Figure 36).

    Figure 36. Modifying the resource reference mappings
    Modifying the resource reference mappings
  4. Select both of the check boxes for resource references defined within the sample application.

  5. Select jms/TestBusCF from the Specify existing Resource JNDI name drop down list box.

  6. Click the Apply button next to this list box (Figure 37).

    Figure 37. Specifying the JNDI name
    Specifying the JNDI name
  7. Select both of the check boxes for resource references defined within the sample application.

  8. In the Specify authentication method section, select the Use default method radio button

  9. Select sibusAlias from the Select authentication data entry drop down list box.

  10. Click the Apply button (Figure 38).

    Figure 38. Specifying the authentication data entry
    Specifying the authentication data entry
  11. Click OK.

  12. Save changes to the master configuration and synchronize the changes with the nodes.

C. Modify the resource environment entry reference mappings for the sample application

The resource environment entry references are used by the sample application to determine which destinations it will browse or send messages to. As discussed previously, to demonstrate messages passing in both directions over the WebSphere MQ link, we must use different destinations for browsing and sending within the sample application. To do this, we must map the resource environment entry reference in each module of the sample application to a different JMS queue. To do this:

  1. Select Applications => Enterprise Applications in the left navigation pane.

  2. In the main content pane, select JmsTestEAR.

  3. Under Additional Properties, select Map resource env entry references to resources (Figure 39).

    Figure 39. Modifying the resource environment entry reference mappings
    Modifying the resource environment entry reference mappings
  4. Enter jms/TOMQQ in the JNDI name entry field for the JmsTestEJB module.

  5. Enter jms/FROMMQQ in the JNDI name entry field for the JmsTestWeb module (Figure 40).

    Figure 40. Specifying the JNDI names
    Specifying the JNDI names
  6. Click OK.

  7. Save changes to the master configuration and synchronize the changes with the nodes.

D. Modifying the foreign bus role

When global security is enabled within WebSphere Application Server, all service integration bus resources are also secured. Access to most of these resources is restricted to users authenticated to WebSphere. Administrators can further restrict access to the service integration bus resources to only permit access by specific users or groups.

Foreign buses, however, are a resource to which access is not allowed by default within a secure bus. For the sample application to access resources that are related to the testJMSQMgr foreign bus, we must add the relevant user to the sender role for the foreign bus. To do this:

  1. Logon to the machine on which the WebSphere Application Server deployment manager is running.

  2. From a command window or shell, change to the <WAS_PROFILE_ROOT>\bin directory and execute the wsadmin command, as follows:

    wsadmin localhost 8879
  3. Because global security is enabled, you will be prompted for a user ID/password. Enter your WebSphere Application Server administrator ID and password and click OK.

  4. On the wsadmin command line, enter the following commands:

    Click to see code listing

    wsadmin>$AdminTask addUserToForeignBusRole {-bus TestBus -foreignBus testJMSQMgr -role sender -user wasuser}
    wsadmin>$AdminConfig save
    wsadmin>quit

Verify the WebSphere MQ link connection

The setup is now complete. However, to ensure that all of the changes that we have made are effective, we need to restart all of the WebSphere Application Server processes within the cell (deployment manager, nodeagent, and application server). We will then use a combination of tools to verify that a message can travel in both directions over the WebSphere MQ link. Once you have restarted your WebSphere Application Server processes, perform the steps in the following sections to verify connectivity in each direction:

  1. Verify WebSphere MQ to WebSphere Application Server connectivity
  2. Verify WebSphere Application Server to WebSphere MQ connectivity

A. Verify WebSphere MQ to WebSphere Application Server connectivity

To verify connectivity from WebSphere MQ to WebSphere Application Server, we need to be able to send a message to the remote queue TOWASQ that we defined earlier. Fortunately, WebSphere MQ provides a utility that will do this, called amqsput. To use this utility to send the message:

  1. Logon to the machine on which WebSphere MQ is running.

  2. From a command window or shell, run the amqsput utility, as follows:

    amqsput TOWASQ testJMSQMgr
  3. The amqsput utility will display a message indicating the target queue. Type the text that will be placed into the test message, for instance, Test message from WebSphere MQ!!!.

  4. Press Enter twice.

  5. You can now verify whether the message arrived on the FROMMQQ on the service integration bus by opening a browser to the URL http://localhost:9080/JmsTestWeb/BrowseAq.jsp (see Figure 41).

    Figure 41. Verifying WebSphere MQ to WebSphere Application Server connectivity
    Verifying WebSphere MQ to WebSphere Application Server connectivity

B. Verify WebSphere Application Server to WebSphere MQ connectivity

We can use the sample application to send messages from WebSphere Application Server to the FROMWASQ queue hosted by WebSphere MQ. However, the WebSphere MQ Explorer or the MQSC command line environment will need to be used to verify that the message has arrived. To do this:

  1. Use the Send a JMS Message link within the sample application to send a message as before.

  2. Logon to the machine on which WebSphere MQ is running.

  3. From a command window or shell, execute the runmqsc command, as follows:

    runmqsc testJMSQMgr
  4. On the MQSC command line, enter the following command:

    DISPLAY QUEUE(FROMWASQ) CURDEPTH
  5. The output from this command should show that the queue has a current depth of 1 message, 'CURDEPTH(1)'


Conclusion

This article described how to configure the WebSphere MQ link within WebSphere Application Server V6.0 to use SSL to communicate with a WebSphere MQ queue manager.


Acknowledgements

I would like to thank Keys Botzum, Sree Anand Ratnasinghe, Patrick Nogay, Graham Hopkins, and Roland Barcia for their extensive technical assistance and expertise.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, Architecture
ArticleID=102076
ArticleTitle=IBM WebSphere Developer Technical Journal: Securing connections between WebSphere Application Server and WebSphere MQ -- Part 2
publish-date=01182006