server and websphere mq -- part 2 securing …...ibm websphere application server v5.0 provided this...

© Copyright IBM Corporation 2006 TrademarksIBM WebSphere Developer Technical Journal: Securingconnections between WebSphere Application Server andWebSphere MQ -- Part 2

of 43

IBM WebSphere Developer Technical Journal:Securing connections between WebSphere ApplicationServer and WebSphere MQ -- Part 2Secure the WebSphere MQ link using the service integration bus

Martin Smithson January 18, 2006

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 runningon Windows® XP.

From the IBM WebSphere Developer Technical Journal.

IntroductionThe Java™ 2 Platform Enterprise Edition (J2EE™) Specification, Version 1.3, required softwarevendors 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 JMSprovider, a reduced footprint version of IBM WebSphere MQ and IBM WebSphere BusinessIntegration Event Broker. However, the WebSphere JMS provider was unable to communicate withother WebSphere MQ queue managers.

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

This article demonstrates how to configure an SSL connection between a messaging enginerunning within WebSphere Application Server V6.0 and a WebSphere MQ queue manager. Thisarticle 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

http://www.ibm.com/legal/copytrade.shtml

https://www.ibm.com/developerworks/ibm/trademarks/

http://www.ibm.com/developerworks/websphere/techjournal/

developerWorks® ibm.com/developerWorks/

IBM WebSphere Developer Technical Journal: Securingconnections between WebSphere Application Server andWebSphere MQ -- Part 2

of 43

integration bus component, and that you have worked through Part 1: Using the WebSphere MQJMS provider.

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

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

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

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

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

• The host name or IP address of the machine hosting the target WebSphere MQ queuemanager.

• The port number on which the target WebSphere MQ queue manager is listening forinbound communication requests.

• An outbound transport chain.

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

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

http://www.ibm.com/developerworks/websphere/techjournal/0601_ratnasinghe/0601_ratnasinghe.html


ibm.com/developerWorks/ developerWorks®


of 43

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 senderchannel defined on the target WebSphere MQ queue manager.

The inbound transport chain, with which the sender channel on the WebSphere MQ queuemanager 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 isconfigured appropriately. The InboundBasicMQLink transport chain defaults to listening on port5558 for connections from WebSphere MQ, and the InboundSecureMQLink transport chaindefaults to listening on port 5578 for connections from WebSphere MQ.

WebSphere MQ link securityAn insecure WebSphere MQ link communicates with WebSphere MQ using insecure transportchains. The WebSphere MQ link sender channel communicates with the WebSphere MQ receiverchannel using the OutboundBasicMQLink transport chain. The WebSphere MQ sender channelcommunicates with the WebSphere MQ link receiver channel using the InboundBasicMQLinktransport chain. The InboundBasicMQLink transport chain listens on the port associated with theSIB_MQ_ENDPOINT_ADDRESS, which defaults to 5558. This configuration is shown in Figure 1.

Figure 1. 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 WebSphereApplication Server are be used. A number of suitable transport chains are created by default whencreating an application server. These are:



of 43

• InboundSecureMQLink• OutboundSecureMQLink

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

Figure 2. Secure WebSphere MQ link architecture

Both of these channels are associated with an SSL repertoire. This SSL repertoire defines thelocation of the key file and trust file that will be used by these transport chains, when establishingSSL connections with clients or servers. For example, when the WebSphere MQ sender channelattempts to establish a connection with the WebSphere MQ link receiver channel, the certificatecontained 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 signercertificate, it will trust the certificate from WebSphere Application Server and an SSL connectionwill 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 thisarticle.



of 43

Configure WebSphere MQPart 1 of this series described how to obtain a certificate for the WebSphere MQ queue managerand how to configure the WebSphere MQ queue manager to use this certificate when establishingSSL connections. When configuring the sender and reciever channels to communicate withthe service integration bus, the WebSphere MQ queue manager will make use of the samecertificates.

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

A. Define the WebSphere MQ sender channelB. Define the WebSphere MQ receiver channelC. Define the WebSphere MQ transmission queueD. 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 WebSphereMQ queue manager to the service integration bus. We will use the default value for theInboundSecureMQLink when configuring the sender channel. To configure the WebSphere MQsender 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 messagingengine: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 SSLPEERsThe CipherSpec that we have used within this article, TRIPLE_DES_SHA_US, provides arelatively strong encryption algorithm. You should evaluate your organization's security needsand consider alternative ciphers if necessary.

WebSphere MQ uses the SSLPEER attribute on the channel to check which DistinguishedName values of client certificates it can accept. In this case, the WebSphere ApplicationServer client certificate matches the DN 'CN=jmsclient, ou=issw, o=ibm, c=US' (which islisted on the SSLPEER attribute, so it is a trusted identity to WebSphere MQ). Without an

/developerworks/websphere/techjournal/0601_ratnasinghe/0601_ratnasinghe.html



of 43

SSLPEER being set, WebSphere MQ would accept any other client certificate issued by theVeriSign trial CA.

B. Define the WebSphere MQ receiver channelThe WebSphere MQ receiver channel will be used to receive messages from the serviceintegration bus. To configure the WebSphere MQ receiver channel:

4. 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')


C. Define the WebSphere MQ transmission queueWebSphere MQ transmission queues are queues that temporarily store messages that aredestined for a remote queue manager. At least one transmission queue must be defined foreach remote queue manager to which the local queue manager is to send messages directly. Toconfigure the WebSphere MQ transmission queue:

5. 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)


D. Define the remote queue defintionA remote queue definition is a queue definition on the local queue manager that refers to a queueon a remote queue manager, or in this case, a queue on the service integration bus. To configurethe remote queue definition:

6. On the MQSC command line, enter the following command to define the remote queuedefinition:DEFINE QREMOTE(TOWASQ) RNAME(FROMMQQ) RQMNAME(QM_WAS) XMITQ(QM_WAS)

7. Type end to exit the MQSC environment.

Create the SSL repertoire for the WebSphere MQ linkAs discussed in the WebSphere MQ link security section, the InboundSecureMQLink andOutboundSecureMQLink transport chains are associated with an SSL repertoire. To bemore specific, they are associated with the default SSL repertoire for the cell. In Part 1,



of 43

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 ApplicationServer processes within a cell to encrypt the data that is passed between them when security isenabled. 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 impactthe inter-process communications within the cell.

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

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

WebSphere MQ CipherSpec Associated JSSE CipherSuite

NULL_MD5 SSL_RSA_WITH_NULL_MD5

NULL_SHA SSL_RSA_WITH_NULL_SHA

RC4_MD5_EXPORT SSL_RSA_EXPORT_WITH_RC4_40_MD5

RC4_MD5_US SSL_RSA_WITH_RC4_128_MD5

RC4_SHA_US SSL_RSA_WITH_RC4_128_SHA

RC2_MD5_EXPORT SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5

DES_SHA_EXPORT SSL_RSA_WITH_DES_CBC_SHA

TRIPLE_DES_SHA_US SSL_RSA_WITH_3DES_EDE_CBC_SHA

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

A. Create the SSL repertoireB. Modify the InboundSecureMQLinkC. Modify the OutboundSecureMQLink


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).



of 43

Figure 3. 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 suitesthat are associated with the specifed Security Level.

Figure 4. 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



of 43

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

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.

B. Modify the InboundSecureMQLink

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

15. Select Servers => Application servers in the left navigation pane.16. In the main content pane, select the server1 link from the list of application servers.17. Under Server messaging, select WebSphere MQ link inbound transports (Figure 7).

Figure 7. Viewing the WebSphere MQ link inbound transports

18. Select the InboundSecureMQLink link from the list of transport chains.



of 43

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

Figure 8. Viewing the SSL Inbound Channel

20. Select the new SSL repertoire from the SSL repertoire drop down list (Figure 9).



of 43

Figure 9. Specifying the SSL repertoire

21. Click OK.22. Save the changes and synchronize them with the nodes.

C. Modify the OutboundSecureMQLink

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

23. Logon to the machine on which the WebSphere Application Server deployment manager isrunning.

24. From a command window or shell, change to the <WAS_PROFILE_ROOT>\bin directory andexecute the wsadmin command, as follows:wsadmin localhost 8879

25. Because global security is enabled, you will be prompted for a user ID/password. Enter yourWebSphere Application Server administrator ID and password and select OK.

26. The first thing we need to do is identify which outbound channel needs to be modified. On thewsadmin command line, enter the following command: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#SSLOutboundChannel_1132565466174)SIB_SSL_MQFAP_SSL_OUT(cells/MQJmsSSLCell/nodes/MQJmsSSLNode/servers/server1|server.xml#SSLOutboundChannel_1132565466172)



of 43

27. Notice that three SSL outbound channels are defined for server1 (if you have more serversdefined within your environment, you will see several more entries in the list). We areinterested in the SIB_SSL_MQFAP_SSL_OUT outbound channel, which is the third entry inthe list shown above. To simplify subsequent commands, we will store the ID of this outboundchannel in a variable. On the wsadmin command line, enter the following command:wsadmin>set outboundSecureMQLink [lindex [$AdminConfig list SSLOutboundChannel] 2]

SIB_SSL_MQFAP_SSL_OUT(cells/MQJmsSSLCell/nodes/MQJmsSSLNode/servers/server1|server.xml#SSLOutboundChannel_1132565466172)

28. The outboundSecureMQLink variable now contains the ID of theSIB_SSL_MQFAP_SSL_OUT outbound channel (notice that the lindex command works onzero indexed lists). Now we need to modify this channel to use the new SSL repertoire. Onthe wsadmin command line, enter the following command:wsadmin>$AdminConfig modify $outboundSecureMQLink {{sslConfigAlias MQJmsSSLCell/WMQLinkSSLSettings}}wsadmin>$AdminConfig savewsadmin>quit

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

Configure the service integration busThe following steps must be performed to configure the service integration bus within theWebSphere Application Server environment:

• Create the service integration bus• Add members to the service integration bus• Define the foreign bus• Create destinations• Define the WebSphere MQ link


A. Create the service integration bus

End-to-End securityTo 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 thecorresponding messaging engines would not be encrypted. If you need to provide end-to-endsecurity for messages as they flow across the bus, please refer to WebSphere ApplicationServer V6 advanced security hardening.

A service integration bus, or bus, within WebSphere Application Server V6 is simply anarchitectural concept. It gives an administrator the ability to group a collection of resourcestogether that provide the messaging capabilities of the bus. At run time, the bus presents thesecooperating messaging resources to applications as a single entity, hiding from those applicationsthe 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 buswithin a WebSphere cell has no run time impact on any of the components running within a cell. It

http://www.ibm.com/developerworks/websphere/techjournal//0512_botzum/0512_botzum1.html




of 43

is not until members are added to a bus that any of the run time components within an applicationserver 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

3. Enter TestBus in the Name entry field (Figure 11).



of 43

Figure 11. 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).



of 43

Figure 12. 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 beenadded as a member of a bus. Adding an application server, or cluster of application servers, as amember of a bus automatically defines a number of resources on the bus member in question. Interms of the functionality provided by a service integration bus, the most important of the resourcesthat are automatically defined is a messaging engine.

To add a member to the service integration bus:

7. Select Service Integration => Buses in the left navigation pane.8. In the main content pane, select the TestBus link from the list of buses.9. Under Topology, select the Bus members link (Figure 13).



of 43

Figure 13. Adding a bus member

10. Click the Add button.11. In Step 1: Select server or cluster of the Add a new bus member wizard, ensure that the

Server radio button is selected.12. Select server1 from the Server drop down list (Figure 14).



of 43

Figure 14. Selecting the new bus member

13. Click Next14. Click Finish15. 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, othermessaging networks. To do this, a foreign bus must be configured. A foreign bus encapsulatesinformation related to the remote messaging network, such as the type of the foreign bus andwhether messaging applications are allowed to send messages to the foreign bus. A foreign buscan 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:

16. Select Service Integration => Buses in the left navigation pane.17. In the main content pane, select the TestBus link from the list of buses.18. Under Topology, select the Foreign buses link (Figure 15).



of 43

Figure 15. Adding a foreign bus

19. Click the New button.20. In Step 1: Foreign bus properties of the Create foreign bus routing definition wizard, enter

testJMSQMgr in the Name entry field.21. Make sure that the Send allowed check box is checked (Figure 16).



of 43

Figure 16. Specifying a foreign bus name

22. Click Next23. 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

24. Click Next25. 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. Thisuser ID will be assigned to messages that arrive on the service integration bus from theWebSphere MQ queue manager and will be used to determine whether the message isauthorized to be placed on the target bus destination.



of 43

Figure 18. Specifying an Inbound User ID

26. Click Next27. Click Finish28. 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 attachas message producers, message consumers, or both, in order to exchange messages. The typesof 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 messagingapplications. An alias destination can also be used to override some of the values specifiedon the target destination, such as default reliability and maximum reliability.

To define the destinations:

29. Select Service Integration => Buses in the left navigation pane.30. In the main content pane, select the TestBus link from the list of buses.31. Under Destination resources, select the Destinations link (Figure 19).



of 43

Figure 19. Creating a destination

32. Click the New button.33. Select the Queue radio button to specify the destination type (Figure 20).



of 43

Figure 20. Selecing the queue destination type

34. Click the Next button.35. 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

36. Click the Next button.37. In Step 2: Assign the queue to a bus member, select server1 from the Bus member drop

down list (Figure 22).



of 43

Figure 22. Assigning the queue to a bus member

38. Click the Next button.39. Click Finish40. 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 MQqueue manager.

41. Click the New button.42. Select the Alias radio button to specify the destination type (Figure 23).

Figure 23. Selecting the Alias destination type

43. Click the Next button.44. In Step 1: Set alias destination attributes of the Create new alias destination wizard, enter

TOMQQ in the Identifier entry field.45. Select TestBus from the Bus drop down list.46. Select testJMSQMgr in the Target bus drop down list.47. 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 MQqueue manager for which this destination is an alias.



of 43

Figure 24. Specifying the alias destination attributes

48. Click the Next button.49. Click Finish50. Save changes to the master configuration and synchronize the changes with the nodes.

E. Define the WebSphere MQ link

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

51. Select Service Integration => Buses in the left navigation pane.52. In the main content pane, select the TestBus link from the list of buses.53. Under Topology, select the Messaging engines link (Figure 25).



of 43

Figure 25. Viewing the Messaging Engines within a Bus

54. There should only be one messaging engine listed for TestBus. Select the link for thismessaging engine.

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



of 43

Figure 26. Viewing the WebSphere MQ links for a messaging engine

56. Click the New button.57. In Step 1: General WebSphere MQ link properties of the Create new WebSphere MQ link

wizard, enter TestJMSQMgrLink in the Name entry field.58. Select testJMSQMgr from the Foreign bus name drop down list.59. 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 thismessaging engine.



of 43

Figure 27. Specifying general WebSphere MQ link properties

60. Click the Next button.61. 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 channelconfigured within WebSphere MQ.

62. Enter localhost in the Host name entry field.63. Enter 1414 in the Port entry field.64. Select OutboundSecureMQLink from the Transport chain drop down list (Figure

28). Recall that the OutboundSecureMQLink transport chain was associated with theWMQLinkSSLSettings SSL repertoire in the Creating the SSL Repertoire for the WebSphereMQ Link section, and that this SSL repertoire specifies a CipherSuite that corresponds to theCipherSpec defined on the WebSphere MQ sender and receiver channels.



of 43

Figure 28. Specifying sender channel WebSphere MQ link properties

65. Click the Next button.66. 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 senderchannel configured within WebSphere MQ (Figure 29).

Figure 29. Specifying receiver channel WebSphere MQ link properties



of 43

67. Click the Next button.68. Click Finish69. 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 JMSadministered objects so that the sample application can interact with them using the JMS 1.1API. We will also create two JMS queue objects for use by the sample application. The reason forthis is that the sample application will now send messages to WebSphere MQ using the TOMQQalias destination that we have configured, but it cannot browse messages on this alias. It canonly browse messages on queue destinations hosted by the service integration bus to which it isconnected. Therefore, we will create a second JMS queue object that the sample application willuse to browse the FROMMQQ.

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

A. Create the JMS queue connection factoryB. Create the JMS queues


End-to-End security

To simplify this example, no Target inbound transport chain has been specified for theconnection factory. As a result, the communications between JMS clients and the serviceintegration bus will not be encrypted. If you need to provide end-to-end security for messagesas they flow across the bus, please refer to WebSphere Application Server V6 advancedsecurity 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).





of 43

Figure 30. 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).



of 43

Figure 31. 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:

9. Select Resources => JMS Providers => Default messaging in the left navigation pane.10. In the main content pane, under Destinations, select the JMS queue link.11. Click the New button.12. Within the Administration properties section, enter FROMMQQ in the Name entry field.13. Enter jms/FROMMQQ in the JNDI name entry field.14. Within the Connection properties section, select TestBus from the Bus name drop down list.15. Select FROMMQQ from the Queue name drop down list (Figure 32).



of 43

Figure 32. Specifying JMS queue properties

16. Click OK.17. Click the New button.18. Within the Administration properties section, enter TOMQQ in the Name entry field.19. Enter jms/TOMQQ in the JNDI name entry field.20. Within the Connection properties section, select TestBus from the Bus name drop down list.21. Select TOMQQ from the Queue name drop down list (Figure 33).



of 43

Figure 33. Specifying JMS queue properties


Modify the deployment properties for the sample application

The sample application is currently configured to make use of resources configured on theWebSphere MQ JMS provider. For the sample application to be able to access the resourceson the service integration bus, several steps must be performed. These steps are not simplyrestricted to modifying the resource reference mappings for the application. Several securityrelated operations must also be performed. This is due to the fact that when global security isenabled within WebSphere Application Server, all service integration bus resources are alsosecured. 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 permitaccess by specific users or groups.

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



of 43

A. Define a J2C authentication alias for connecting to the service integration busB. Modify the resource reference mappings for the sample applicationC. Modify the resource environment entry reference mappings for the sample applicationD. Modify the foreign bus role


A. Define a J2C authentication alias for connecting to the service integrationbusThe first step is to define a J2C authentication alias. This alias will be used by the sampleapplication so that it can authenticate to the service integration bus when it attempts to connect. Tocreate 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

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).



of 43

Figure 35. Specifying J2C Authentication alias properties


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 itcan connect to the service integration bus. To do this:

9. Select Applications => Enterprise Applications in the left navigation pane.10. In the main content pane, select JmsTestEAR.11. Under Additional Properties, select Map resource references to resources (Figure 36).



of 43

Figure 36. Modifying the resource reference mappings

12. Select both of the check boxes for resource references defined within the sample application.13. Select jms/TestBusCF from the Specify existing Resource JNDI name drop down list box.14. Click the Apply button next to this list box (Figure 37).



of 43

Figure 37. Specifying the JNDI name

15. Select both of the check boxes for resource references defined within the sample application.16. In the Specify authentication method section, select the Use default method radio button17. Select sibusAlias from the Select authentication data entry drop down list box.18. Click the Apply button (Figure 38).



of 43

Figure 38. Specifying the authentication data entry


C. Modify the resource environment entry reference mappings for the sampleapplication

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

21. Select Applications => Enterprise Applications in the left navigation pane.22. In the main content pane, select JmsTestEAR.23. Under Additional Properties, select Map resource env entry references to resources

(Figure 39).



of 43

Figure 39. Modifying the resource environment entry reference mappings

24. Enter jms/TOMQQ in the JNDI name entry field for the JmsTestEJB module.25. Enter jms/FROMMQQ in the JNDI name entry field for the JmsTestWeb module (Figure 40).



of 43

Figure 40. Specifying the JNDI names


D. Modifying the foreign bus role

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

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

28. Logon to the machine on which the WebSphere Application Server deployment manager isrunning.

29. From a command window or shell, change to the <WAS_PROFILE_ROOT>\bin directory andexecute the wsadmin command, as follows:wsadmin localhost 8879

30. Because global security is enabled, you will be prompted for a user ID/password. Enter yourWebSphere Application Server administrator ID and password and click OK.

31. On the wsadmin command line, enter the following commands:wsadmin>$AdminTask addUserToForeignBusRole {-bus TestBus -foreignBus testJMSQMgr -role sender -user wasuser}wsadmin>$AdminConfig savewsadmin>quit

Verify the WebSphere MQ link connection

The setup is now complete. However, to ensure that all of the changes that we have made areeffective, 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



of 43

tools to verify that a message can travel in both directions over the WebSphere MQ link. Once youhave restarted your WebSphere Application Server processes, perform the steps in the followingsections to verify connectivity in each direction:

A. Verify WebSphere MQ to WebSphere Application Server connectivityB. 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 ableto send a message to the remote queue TOWASQ that we defined earlier. Fortunately, WebSphereMQ 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 willbe 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 Serverconnectivity



of 43

B. Verify WebSphere Application Server to WebSphere MQ connectivity

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

6. Use the Send a JMS Message link within the sample application to send a message asbefore.

7. Logon to the machine on which WebSphere MQ is running.8. From a command window or shell, execute the runmqsc command, as follows:

runmqsc testJMSQMgr

9. On the MQSC command line, enter the following command:DISPLAY QUEUE(FROMWASQ) CURDEPTH

10. 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 ApplicationServer 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, andRoland Barcia for their extensive technical assistance and expertise.



of 43

Related topics

• Configuring SSL Connections between JMS Clients and the WebSphere MQ JMS Provider• Using JSSE for Secure Socket Communication• Secure connections between WebSphere Application Server and WebSphere MQ, Part 1:

Securing JMS connections with SSL.• Deploying message-driven beans and JMS applications into the service integration bus.• Deploying publish and subscribe applications into the service integration bus.• Building an Enterprise Service Bus with WebSphere Application Server V6 -- Part 1.• Configuring SSL Connections between JMS Clients and the WebSphere MQ JMS Provider.• WebSphere Application Server V6 advanced security hardening.• Enterprise Messaging Using JMS and WebSphere by Kareem Yusuf (Prentice Hall, 2004,

ISBN: 0-13-146863-4).• A presentation on WebSphere MQ Channel Security with SSL• WebSphere MQ v5.3 User Guides

• WebSphere MQ 5.3 Using Java• WebSphere MQ 5.3 Security• WebSphere MQ 5.3 System Administration Guide

• IBM Redbook: WebSphere Application Server V6: System Management & ConfigurationHandbook

© Copyright IBM Corporation 2006(www.ibm.com/legal/copytrade.shtml)Trademarks(www.ibm.com/developerworks/ibm/trademarks/)

http://www.ibm.com/developerworks/websphere/techjournal/0211_yusuf/yusuf.html

http://www.ibm.com/developerworks/edu/j-dw-javajsse-i.html



http://www.ibm.com/developerworks/websphere/library/techarticles/0504_barcia/0504_barcia.html

http://www.ibm.com/developerworks/websphere/techjournal/0508_barcia/0508_barcia.html

http://www.ibm.com/developerworks/websphere/techjournal/0501_reinitz/0501_reinitz.html

http://www.ibm.com/developerworks/websphere/techjournal/0211_yusuf/yusuf.html

http://www.ibm.com/developerworks/websphere/techjournal/0512_botzum/0512_botzum1.html

http://publibfp.boulder.ibm.com/epubs/pdf/csqzaw12.pdf

http://publibfp.boulder.ibm.com/epubs/pdf/csqzas01.pdf

http://publibfp.boulder.ibm.com/epubs/pdf/amqzag05.pdf

http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246451.pdf

http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246451.pdf

http://www.ibm.com/legal/copytrade.shtml

https://www.ibm.com/developerworks/ibm/trademarks/

server and websphere mq -- part 2 securing …...ibm websphere application server v5.0 provided this...

Documents