Securing IBM® WebSphere® MQ messaging

The sample configuration provided using IBM® WebSphere® MQ, is an example for illustration purposes only. The sample is by no means exhaustive or optimal.

Note: The following information references JMS queues. If you use JMS topics for JMS messaging, follow similar security recommendations.

There are other approaches to securing message queue, each with its own strengths and weaknesses. Since message queuing software is provided by third party vendors, we strongly encourage you to discuss your approach to hardening or securing message queues with IBM® WebSphere® MQ specialists. Products can evolve; hence, processes for hardening them might change over time. If you have any problems with the processes discussed here, we ask you work with IBM® directly. You should use the following recommendations as a starting point and customize the configuration for your specific operating environment.

Prerequisites

Install the correct version of WebSphere MQ and all patches up to the latest fix pack. WebSphere MQ is not a JMS, but it can be accessed via JMS implementation classes. To do so, you may need to install additional WebSphere MQ packages for Java™.

The Java packages for WebSphere MQ provide a tool known as JMSAdmin that can be used to bind JNDI entries for interfacing to WebSphere MQ as a JMS.

Configure WebSphere MQ messaging for security

Normally, WebSphere MQ is installed as user mqm and the installation directory is /opt/mqm, referred to here as WMQ_HOME. All commands should be run as user mqm unless otherwise noted.

Create a queue manager.

A queue manager is the process with which message clients interact to create and retrieve messages, and where administrators manage queues.

The crtmqm command line utility is used to create a queue manager for your WebSphere MQ installation. It takes one argument: the queue manager name. You will reference this name when starting or stopping the queue manager and when binding JNDI entries. In this example, we name the queue manager sciqm:
```
$ cd <WMQ_HOME>/bin
bin $ ./crtmqm sciqm
```
To start the queue manager, enter this command:
```
bin $ ./strmqm sciqm
```
Verify that the queue manager is running with this command:
```
bin $ ./dspmq
QMNAME (sciqm)          STATUS (Running)
```

Configure queues

Next, configure two agent and two integration queues.

The runmqsc command is a command line utility used to create objects in WebSphere MQ. The tool is found in the directory <WMQ_HOME>/bin. You need to pass the queue manager name you used when you issued the crtmqm command to identify the queue manager with which you want to interact.

bin $ ./runmqsc sciqm
define qlocal(SCHEDULE)
define qlocal (RELEASE)
define qlocal(CREATEORDER)
define qlocal(SHIPNOTICES)
chlauth(SYSTEM.DEF.SVRCONN) type(ADDRESSMAP) address(<IP_Address>) mcauser('quser')

It is beyond the scope of this document to explain all of the commands and options available through the runmqsc command line utility. For example, define commands are used to define objects for the queue manager, including defining a queue and creating channels, processes, remote queues and other objects. The chlauth command is used to disable user authentication.

It is possible to override the attributes of the queue at the time that you create it. For instance, you can override the maximum queue depth at the time that you create the queue.

For details on the define and other commands, refer to the WebSphere MQ documentation.

Configure authentication to the queue manager and to queues

Next, configure authentication to the queue manager and to queues to allow a user to connect to the queue manager and put messages into a queue. To do this, start the WebSphere MQ Listener.

Create the user on the system where the queue manager is running.

Use the setmquat command to allow the user to connect to connect to the queue manager.

bin $ ./setmqaut -m sciqm -t qmgr -p quser +all

The following commands authorize user "quser" to perform any action on the four queues:

bin $ ./setmqaut -m sciqm -n SCHEDULE -t q -p quser +all
bin $ ./setmqaut -m sciqm -n RELEASE -t q -p quser +all
bin $ ./setmqaut -m sciqm -n CREATEORDER -t q -p quser +all
bin $ ./setmqaut -m sciqm -n SHIPNOTICES -t q -p quser +all

Issue the following command to start the MQ and establish a listener:
```
bin $ ./runmqlsr -m sciqm -t TCP
```
This starts the listener on the default port of 1414 for the given queue manager. If an alternate port is required, use the -p option. For example:
```
bin $ ./runmqlsr -m sciqm -t TCP -p 1415
```
Note: runmqlsr ships with WebSphere MQ. You can also use inetd or xinetd as an alternate method of establishing a listener.

Binding the MQ queues to JNDI

After you create the queue manager and queues and have started the MQ listener, you need to bind the queues to the JNDI so that they can be located by your client applications.

The Java packages for WebSphere MQ provide a utility known as JMSAdmin that can be used to bind JNDI entries for WebSphere MQ. The tool can be used to bind queues into virtually any JNDI you wish to use. This document will focus on file bindings.

In a normal install, if you have installed the Java packages for WebSphere MQ, the JMSAdmin tool and related files will be in WMQ_HOME/java/bin. There are a few key files that you must back up and configure before you start.

Configuring JMSAdmin.config

The JMSAdmin.config file defines the ICF and URL the tool will connect to. To use file bindings, configure the file with values similar to what is shown here:

INITIAL_CONTEXT_FACTORY=com.sun.jndi.fscontext.RefFSContextFactory
PROVIDER_URL=file:/opt/mqm/filebindings

The INITIAL_CONTEXT_FACTORY tells JMSAdmin that you want to use file bindings. File bindings uses a regular file on the operating system to perform lookups to objects.

The PROVIDER_URL tells JMSAdmin where it should create the file bindings. In the example above, JMSAdmin will create /opt/mqm/filebindings/.bindings. This is a regular file that you can open with a text editor. Users or programs that need to read the binding file will need read access to the file.

JMSAdmin shell script

The file JMSAdmin is a sample shell script used to invoke the underlying java program JMSAdmin. To use the script, define the following environment variables:

Define JAVA_HOME and add the $JAVA_HOME/bin to the PATH in the shell script.
Add the following files to the CLASSPATH:
- ${WMQ_HOME}/java/lib/fscontext.jar
- ${WMQ_HOME}/java/lib/com.ibm.mq.jar
- ${WMQ_HOME}/java/lib/com.ibm.mqjms.jar
- ${WMQ_HOME}/java/lib/jms.jar

Note: The above CLASSPATH allows JMSAdmin to bind message queue objects into the file bindings (fscontext) when JMSAdmin is running with the Java that is shipped with the WebSphere MQ Java client. Java clients that do not use the MQ Java JDK may require the following additional JAR files:

${WMQ_HOME}/java/lib/providerutil.jar
${WMQ_HOME}/java/lib/dhbcore.jar
${WMQ_HOME}/java/lib/com.ibm.mq.jmqi.jar

For instance, those JAR files are needed if a WebLogic server running on a Sun JDK is used to invoke synchronous services that put messages in the MQ queues.

You can now run the JMS Admin tool, JMSAdmin. Start it in interactive mode by issuing a JMSAdmin command:

bin $ ./JMSAdmin

If successful, a prompt displays:

5724-H72, 5655-L82, 5724-L26 (c) Copyright IBM Corp. 2002,2005. All Rights 
   Reserved.
Starting Websphere MQ classes for Java(tm) Message Service Administration
InitCtx>

It is a common practice to put all the JMSAdmin commands into a script file with an scp file extension to define the objects in the JNDI. Instead, the document intends to explain how to create a QCF and JNDI entries for queues. The entries in a typical scp file are shown here:

InitCtx> def qcf(AGENT_QCF) qmgr(sciqm) tran(client) chan(SYSTEM.DEF.SVRCONN) 
  host(localhost) port(1414)
InitCtx> def q(SCHEDULE) qu(SCHEDULE) qmgr(sciqm) 
InitCtx> def q(RELEASE) qu(RELEASE) qmgr(sciqm) 
InitCtx> def q(CREATEORDER) qu(CREATEORDER) qmgr(sciqm) 
InitCtx> def q(SHIPNOTICES) qu(SHIPNOTICES) qmgr(sciqm)

The first line in this example shows how to define a QCF called AGENT_QCF that will service queues on the queue manager via the channel SYSTEM.DEF.SVRCONN via port 1414. It is important to understand that the port 1414 must have a listener running on it for this to achieve the desired goal. See the instructions to create a listener through runmqlsr under Configure authentication to the queue manager and to queues in this topic.

The remaining four lines show how to create four JNDI entries for the four queues. Notice that the qmgr is called out on the queue JNDI definition.