Level: Introductory David Leigh (dleigh@us.ibm.com), Advisory Software Engineer, IBM
12 Mar 2004 This article describes how you can use IBM WebSphere® MQ to provide a secure transport for JMS messaging. The article discusses how to apply security among WebSphere Application Server and WebSphere MQ queue managers, and between WebSphere queue managers themselves. WebSphere MQ clustering is suggested as a good way to create an easy-to-manage and secure JMS transport infrastructure.
Introduction
Within the enterprise, an asynchronous messaging infrastructure is often used to integrate systems. Asynchronous messaging can provide a very reliable and flexible information transport that can handle service outages, or performance limitations, in message consumers without loss of data. In the supply chain scenario described in previous articles in this series, asynchronous messaging is a natural architectural choice for
distributing data between the enterprise information systems, the aggregation system, and the global repository.
The Java Message Service (JMS) is the J2EE standard platform API for accessing enterprise message systems. It lets developers write portable, message-based business applications without concern for which messaging system (or JMS provider) their applications are deployed on. JMS supports two types of messaging styles: point-to-point and publish-subscribe. It is the application server administrator's responsibility to configure a suitable JMS provider. For point-to-point messaging in WebSphere Application Server, this is done by configuring the appropriate queue connection factory and queue destination resources. For publish-subscribe messaging in WebSphere Application Server, this is done by configuring the appropriate topic connection factory and topic destination resources. For this article, I assume that the more common point-to-point messaging style is being used.
Using an example from the supply chain scenario in the introductory article, let's assume that the enterprise information system (EIS) that provides availability information, EIS3, is exposed to the supply chain aggregation system by JMS. To query EIS3, the aggregation system constructs and sends a JMS message that's received by the EIS3 message receiver, which in turn queries the back-end database and sends the result back to the aggregation system as a JMS reply.
The JMS standard does not address security issues; it considers them to be JMS provider-specific features.
A complete security solution involves many areas of consideration including (but not limited
to): authentication, authorization, encryption, confidentiality, data integrity, audit,
non-repudiation, and physical (hardware) security. This article discusses authentication, authorization, and encryption. The security goals of our secure JMS transport in this article are:
- Queues are protected so they can only be written to and accessed by designated systems.
- Messages are encrypted while traveling across the network.
This article presents a simple and straightforward approach to meeting these JMS transport security goals on the distributed platforms. When additional layers of message protection are required, Tivoli® Access Manager for Business Integration is highly recommended.
Choosing a JMS provider
When using WebSphere Application Server, the preferred JMS provider is WebSphere MQ. While WebSphere MQ is preferred, the WebSphere Application Server is capable of using
other JMS providers:
- WebSphere Embedded Messaging
- Is packaged with the
application server itself. Though lightweight, readily available, and useful in some environments, it is not suited to most production networks or to most application integration
scenarios because of its dependency on the application server runtime, and lack of
support for SSL. In comparison with WebSphere Embedded Messaging, WebSphere MQ provides
a much more flexible and reliable JMS transport.
- Third-party JMS provider
- The security implications
of using a third-party JMS transport are beyond the scope of this article.
This article assumes that the WebSphere MQ is the JMS provider.
WebSphere MQ queue managers
In WebSphere MQ, the server component is called the queue manager. A queue manager may "own" one or more local queues, and can communicate with MQ clients or with other queue managers. Queues that are owned by a queue manager are called local queues to that queue manager, and queues owned by other queue managers are called remote queues.
A queue manager can read and write to local queues, and (through communication with other queue managers) may write to remote queues. A queue manager may not read from remote queues. When using WebSphere MQ as a JMS provider, the application server is an MQ client that communicates with the queue manager using the WebSphere MQ Java API. A typical scenario will involve two or more application servers, each being a client to a unique queue manager, as shown in Figure 1.
Figure 1. A typical JMS provider scenario
If an application running on WAS_Agg needs to send a message to eis3_queue, it can send the message to QM_Agg.
QM_Agg will guarantee delivery to QM_EIS3, holding the message if necessary until QM_EIS3 is available. Once the message is received by QM_EIS3, it will be put in the eis3_queue where it can be seen by the WAS_EIS3 server and handled by the receiver application.
MQ channels
Another important component is the MQ channel. A WebSphere MQ channel is a logical communication link between a WebSphere MQ client and a WebSphere MQ queue manager (MQI channels), or between two queue managers (message channels). Channels can use one of several communication transports, such as TCP/IP, SNA, NetBIOS, and so on. WebSphere MQ channels can be individually configured for SSL-encryption, but they are initially set to be unencrypted. It is very important to know that WebSphere MQ does no authentication on channels. Any
client can connect to an unprotected MQ channel simply by presenting an authorized user ID (for example, mqm) and any
bogus password. So how can you protect MQ channels from this type of rogue access? There are essentially three approaches:
- Set the MCAUSER channel attribute to an invalid user ID.
- Configure a custom channel security exit.
- Enable SSL and control access based on the SSLPEER channel attribute.
If a particular channel is not needed in your environment, the easiest way to prevent access is to set the MCAUSER attribute of the channel to the name of an invalid user ID, or a user ID that isn't defined in the local operating system user registry. Ordinarily, authorization is performed based on the user ID that the client uses to access the channel. The MCAUSER channel attribute, which is blank by default, lets the WebSphere MQ administrator specify a user ID that's used for authorization by all clients connecting to the queue manager using that channel, regardless of the user ID used to access the channel. If the MCAUSER attribute of the channel specifies an invalid user ID, authorization will be denied for all clients using that channel.
MQ channels can also be configured to employ custom security exits, which are user-written programs that are called as part of the normal channel processing sequence. A custom security exit can be used to provide services such as authentication, authorization, and encryption based on technologies that are not supported by WebSphere MQ itself. For example, a custom security exit can be used to provide authentication based on an external user registry. While custom security exits can provide various useful security capabilities, they require design, development,
and test efforts that dramatically increase the work required to set up a JMS provider infrastructure. The "simple
but secure" JMS infrastructure described in this article intentionally avoids using custom security exits.
The third method of securing an MQ channel from unauthorized access is to enable SSL on the channel and use the SSLPEER channel attribute. SSLPEER is optional, and specifies a string which must appear in the distinguished name of the SSL certificate for each client or queue manager that will use the channel. This is a form of certificate-based authentication. For example, in a queue manager for the "myorg" organization, the SSLPEER attribute for a certain channel could be set to O=myorg. Then, this channel will be accessible only to clients and queue managers whose SSL certificates contain O=myorg as part of their
distinguished name. This is the preferred method of securing MQ channels that are needed in the environment, and
cannot be disabled using the MCAUSER method described above. Naturally, enabling SSL also lets us meet our other cluster security goal of message encryption.
The problem
The security problem can be logically broken into two parts:
-
Security between the WebSphere Application Servers and WebSphere MQ queue managers
-
Security between WebSphere MQ queue managers
Security between WebSphere Application Server and WebSphere MQ
The WebSphere MQ Java classes provide two different client connection modes, called bindings and client, that can be used to communicate between an application server and a queue manager.
Bindings versus client mode connections
Bindings-mode connections use the Java Native Interface (JNI) to call directly
into the queue manager API, rather than communicating over a network. This offers better
performance than client-mode connections, and is the default setting for WebSphere MQ JMS queue
connection factory resources in WebSphere Application Server. Client-mode connections
communicate with the queue manager over TCP/IP, and therefore let you create MQ Java
clients that talk to queue managers on remote machines.
When using bindings-mode connections on the distributed platforms, the connection to the queue manager is made with the implicit security context of the user who owns the JVM process. This will be the user ID that started the application server process. On the other hand, when using client-mode connections, a user ID and password must be explicitly passed to the queue manager. WebSphere MQ JMS queue connection factories using bindings mode do not need to specify a component-managed or a container-managed J2C authentication alias. However, if an authentication alias is specified, it must contain the same user ID that's used to run WebSphere itself.
The password, if specified, is always ignored in bindings-mode connections. Bindings-mode connections are
inherently secure; they're implicitly authenticated by the operating system, and encryption is unnecessary because messages are not traveling over a network.
 |
Caveat
An application server cannot connect to more than one queue manager in bindings mode. All bindings-mode queue connection factories on a given server must use the same queue manager. Since queue managers can easily forward messages to other queue managers (being one of their primary purposes), this is not usually a significant limitation.
|
|
WebSphere MQ JMS queue connection factories using client-mode access the queue manager by MQI Channels. When a queue manager is created, several different types of channels are created for that queue manager, including a default MQI channel (SYSTEM.DEF.SVRCONN) necessary to support MQ clients. Remember, channels are not used for communication with MQ Java clients using
bindings-mode connections.
We have two configuration choices that meet the security requirements between the application server and the queue manager:
- Use bindings-mode queue connection factories
- Best performance
- SYSTEM.DEF.SVRCONN must be disabled by specifying an invalid MCAUSER user ID
- No other configuration required
- Use client-mode queue connection factories with SSL-encrypted MQI channels and certificate-based authentication using SSLPEER
- Allows the queue manager to be on a remote server
- SSL configuration (such as certificate management) is required between WebSphere Application Server and WebSphere MQ
- J2C authentication aliases required
Unless there's a compelling reason that WebSphere MQ cannot be installed on the same machine as the
application server, bindings mode is the logical choice. However, client-mode access is enabled by
default so it is still necessary to disable the SYSTEM.DEF.SVRCONN channel to prevent unauthorized client access.
As described, if the MCAUSER attribute of the SYSTEM.DEF.SVRCONN channel specifies an invalid user ID, all authorization will be denied for all client-mode access.
Queue Authorization
WebSphere MQ allows individual queues to be authorized by the application of ACLs, which grant permissions to
users or groups. On the distributed platforms, authorization may be applied to local MQ queues using the setmqaut command. Assuming that the application server is using a bindings-mode queue
connection factory, the user ID that starts the WebSphere Application Server process should be authorized to
access the necessary local queues. The application server that hosts the message receiver must be authorized to
access the destination queue on its local queue manager, and the application server that hosts the message sender
must be authorized to access the SYSTEM.CLUSTER.TRANSMIT.QUEUE on its local queue manager.
Security between WebSphere MQ queue managers
There are two ways that queue managers can communicate with each other to pass messages to their destination queues: distributed queuing and MQ clusters.
The case for using MQ clusters
Distributed queuing requires that every queue manager have a channel configured for each remote queue manager with which it needs to communicate. For example, if queue manager QM_A needs to send messages to queue managers QM_B and QM_C, then QM_A must be configured with two channels: one for QM_B and one for QM_C. Likewise, if QM_B and QM_C need to send messages to QM_A and to each other, then four more channels will need to be configured (two on QM_B, and two on QM_C).
MQ clusters ease the administration of queue manager intercommunication by requiring that every queue manager
have just two channels configured: a single cluster-receiver channel and a single cluster-sender channel. By
eliminating the need to explicitly define a channel for each remote queue manager, MQ clusters significantly
simplify queue manager administration, especially as the number of queue managers in a network grows. Because security is applied to queue manager intercommunication on a channel by channel basis, MQ clusters also
greatly simplify security administration. In the rest of this article, I'll assume that MQ clusters are being used for queue manager intercommunication.
Securing MQ clusters
If all queue manager intercommunication is with MQ clustering, then the issue of security between WebSphere queue
managers is really an issue of securing the MQ cluster. The security goals are to ensure that:
- No unauthorized queue managers can join the cluster
- Communication between queue managers is encrypted.
An MQ cluster contains one or more (normally, at least two) queue managers designated as a cluster repository server, and any number of non-repository queue manager peers. A cluster repository server hosts information about all of the queue managers in the cluster. Each queue manager in the cluster needs a cluster-receiver channel used for receiving messages from a cluster repository server, and a cluster-sender channel used for sending messages to the cluster repository server. Other channels
used for communication with other cluster peers are created automatically as needed, using the peers' cluster-receiver channels as templates. In other words, the cluster-receiver channel on queue manager QM_A is used
as a template by QM_B to dynamically define a channel for sending messages to QM_A.
If you're a queue manager, joining a cluster is a matter of creating a cluster-receiver channel that tells other
cluster peers how to communicate with you, and creating a cluster-sender channel that tells you how to communicate
with one of the cluster repository servers. An MQ cluster repository server will, by default, allow any queue
manager to join the cluster simply by creating two channels: a cluster-receiver channel, and a cluster-sender
channel that specifies the repository server. To meet the security goals, we must prevent unauthorized
queue managers from joining the cluster. This is easy to do using the SSLPEER approach described above.
Enable SSL on the cluster-receiver channel of the repository server,
and use that channel's SSLPEER attribute to filter which queue managers may talk to the channel based on the
distinguished name in the queue manager's SSL certificate. For example, if QM_A is a cluster repository server for
the myorg organization, the SSLPEER attribute could be set to O=myorg. Then QM_B and
QM_C could join the cluster specifying QM_A as the cluster repository server in their cluster-sender channels, as
long as their SSL certificates have O=myorg as part of their distinguished name.
This approach works as long as administrators can ensure that no rogue queue managers are using O=myorg as part
of their distinguished name in a trusted certificate. One way to ensure this is to remove the default
certificate authority (CA) certificates (such as those representing Verisign, Thawte, and so on) from the cluster
repository server's keyring and replace them with a "local" CA certificate that's used to sign all SSL certificates
within the MQ cluster. This way, security administrators can be certain that only authorized queue managers can join the MQ cluster.
Stay tuned
The approach to JMS transport security described in this article can be applied virtually anywhere that requires a secure asynchronous messaging infrastructure.
Part 2 will provide a detailed example of how this approach is implemented in practice.
Resources
About the author | 
| | David Leigh is an Advisory Software Engineer in IBM Software Group's WebSphere Platform System House organization in Research Triangle Park, NC. His areas of expertise include the process choreographer, application and server security, high-availability, monitoring, IBM AIX, and Linux. You can contact David at dleigh@us.ibm.com. |
Rate this page
| 
