Security and a federated WebSphere MQ environment
Many customers are Web-enabling existing business applications in business to business (B2B) or business to consumer (B2C) models. Whilst this is often focused on the B2C model with e-business applications extending back-end business applications to browsers on the Web, it can also include B2B transactions where transactions are exchanged between businesses.
Many customers have used WebSphere MQ (previously called MQSeries®) to provide a message-based transactional capability between application components within their network. We are now seeing customers open up this message-based infrastructure to external clients, where messages are passed between businesses.
Extending a WebSphere MQ environment to the Internet has the same issues as extending applications to the Internet using HTTP and Web browsers. Security is a big issue. How do we control who is writing data into our internal network through queues? How do we ensure that data is not tampered with? How do we audit who has accessed data? Within an internal WebSphere MQ deployment. we can use IBM Tivoli Access Manager for Business Integration (TAMBI) to perform these functions. How does this work in a B2B scenario when crossing the Internet?
There is also the issue of protocols allowed across the Internet. Does a company trust having standard WebSphere MQ communications (i.e. MQ channels) across the internet and through firewalls? Many have standards to restrict firewall traversal to only allow HTTP and HTTPS. Others are concerned with the multiple firewall ports required to be open for multiple queue managers and queues. The WebSphere MQ Internet pass-thru (MQIPT) product was released to help solve these problems of WebSphere MQ over the Internet. A number of customers have deployed this are now asking how TAMBI fits into an environment where MQIPT is controlling MQ traversal across the Internet?
The challenge has been combining a good understanding of TAMBI with a good understanding of MQIPT. This document presents and overview of both TAMBI and MQIPT, then looks at how TAMBI works in an MQIPT environment. At the end of the article, a number of theoretical integration options are given with the associated pros and cons of each.
This document assumes the reader is familiar with WebSphere MQ and messaging concepts.
How IBM Tivoli Access Manager for Business Integration (TAMBI) works
TAMBI provides authentication and authorization of users attempting to access MQ queues, provides data protection for data in transit and at rest (on queues) and provides auditing. It is designed to secure the customer data in MQ, not the MQ infrastructure. TAMBI 5.1 Fix Pack 1 introduced a channel security exit that can check whether an incoming client channel connection is valid.
TAMBI hooks into the usual mechanisms to put data into queues and get data from the queues; the MQ programming Interface (MQI), MQI-C, or Java™ Message Service (JMS). The key components are shown in the following figure:
Figure 1. IBM Tivoli Access Manager for Business Integration components
When an application makes an MQ call (such as an MQPUT or a JMS call), TAMBI is called and determines the identity of the application, checks it's authorization database to determine if this user is allowed to perform the function requested. If a message is being put on a queue, it checks the Protected Object Policies (POPs) to determine if the message is to be signed ("integrity"), encrypted ("privacy"), both, or none.
Thus for the usual MQ application, where one component puts messages on a queue and another gets messages from a queue (often on different queue managers and different servers), TAMBI is checking whether the sending application is allowed to put data on the queue, it might be signing and encrypting the data before it's enqueued and decrypting and checking for tampering as it's dequeued, and checking whether the receiving application is allowed to get the data from the queue.
All of this happens irrespective of whether native SSL is used across the channels. Note that TAMBI is not checking messages at the channel level. However, with 5.1 Fix Pack 1, TAMBI can authenticate and authorize an incoming channel connection request by using the new exit (this capability does require SSL). When a client attempts to connect to the server listening port and establish a channel, it passes a certificate. The channel security exit maps this certificate to a TAM user and checks whether that user has the access rights to connect to the queue manager (new RemoteConnect permission).
TAMBI implements the application-level authentication and authorization functionality by means of Interceptors that intercept the applications' MQ calls. There are three interceptors:
- The JMS interceptor intercepts JMS calls and works with TAMBI
- The server interceptor intercepts MQI calls made to an MQ Server (queue manager, QMGR) and works with TAMBI
- The client interceptor intercepts MQI calls made to an MQ Client that is using the MQIC API to communicate with a QMGR and works with TAMBI
Each interceptor performs fundamentally the same function, but operates at the point that the application call is being made. Each relies on the TAMBI daemon/service and the TAM framework to provide the authentication, authorization, signing and encryption, and auditing capabilities.
Authentication of users is based on the operating system identity of the process that is making the MQI/JMS calls (described in Chapter 8 of the TAMBI 5.1 Administration Guide). This user is mapped to a certificate in a keystore and this certificate is used to: a) map to the TAM identity, and b) provide the signing/encrypting keys for the data.
For the channel RemoteConnect mechanism implemented through the channel security exit, the channel SSL certificate is checked by the exit and mapped to a TAM user. This authenticated user is then used for any enqueue and dequeue authorization checks and audit logging.
How MQIPT works
WebSphere MQ Internet pass-thru (MQIPT) is designed as a WebSphere MQ proxy; to sit between an MQ Client and Queue Manager (QMGR), or two QMGRs, and operate at the MQ channel level passing MQ-format messages. MQIPT is described in Support Pack MS81.
One of its key uses is to provide a VPN-like mechanism for WebSphere MQ across the Internet, as shown in the following figure:
Figure 2. MQIPT in a WebSphere MQ environment
MQIPT communicates with MQ Clients and QMGRs at the channel level. It can also communicate with other MQIPTs using MQ channels, either natively or using MQ channel-level SSL. MQIPT can also wrap MQ messages and send them as unsecured HTTP or over SSL (HTTPS). By wrapping MQ messages in HTTP, MQ can work with HTTP servers and HTTP proxies (such as WebSEAL in IBM Tivoli Access Manager for e-Business (TAMeB)).
It can act as an SSL termination point (with MQ Channel SSL and HTTPS) and act as an SSL proxy for the MQ Channel SSL. MQIPT cannot send MQ channel-level SSL data over HTTP, so MQIPT does NOT support end-to-end SSL authentication at present via HTTP. A client certificate cannot be presented to the target Queue manager - unless SSLProxyMode (that is, MQ channel-level SSL between two MQIPTs) is used, which means opening extra holes in the firewall and not using HTTP.
The current version of MQIPT has an exit, called the security exit, which can dynamically route the incoming request to different queue managers based on the channel information in the incoming request. It can work for all forms of incoming connection (native MQ, MQ over SSL, HTTP and HTTPS) except where the MQIPT is set as SSLProxyMode. The MQIPT security exit is only called when a connection request is received. There will be more information available to the exit if MQIPT is not using SSL, or MQIPT is acting as an SSL server (so it can work for MQ over HTTPS). The security exit function is not available in the servlet version of MQIPT.
There are two key design points from the information above:
- MQIPT supports HTTPS incoming from another partner
- MQIPT communicates at the channel level when communicating with QMGRs, NOT at the application level.
This will become relevant when discussing deployment options below.
How do they work in the same environment?
When we put the MQIPT and TAMBI components together, we get the following figure:
Figure 3. MQIPT and IBM Tivoli Access Manager for Business Integration
On the right of the figure is the internal MQ deployment with TAMBI. On the left is the MQIPT connection to another customer’s MQ environment. In this combined model, an MQ message can originate from the other customer’s MQ environment, be passed view the other customers MQIPT, across the Internet, through the local MQIPT and into the local MQ environment where it may be subject to TAMBI access control and quality of protection.
Ideally we would like to have all features of TAMBI (centralised access control and quality of protection primarily) applied from when the MQ message arrives at the local environment (that is, the MQIPT component) and throughout its traversal of the local MQ environment. However there are limitations, which will be discussed in the next section.
There are a number of limitations on an integrated solution, discussed in the following sections.
Impact on quality of protection
TAMBI is controlling access to queues within a queue manager from API calls. It is also applying integrity (signing) and privacy (encryption) to messages travelling between queue managers running TAMBI. The server, client and JMS interceptors are providing the ability to sign, encrypt, and decrypt the messages.
MQ messages coming through MQIPT are not passing through any of the TAMBI interceptors, so there is no opportunity to sign and encrypt the message, unless it has already been signed and encrypted by TAMBI running in the customer’s MQ environment. This requires synchronisation of certificates and keys between the business and its customers, so that the local TAMBI can open messages.
If the customer is not using TAMBI, or their TAMBI is not synchronised with the local TAMBI, there can be no quality of protection applied to the message data.
Impact on dynamic routing
MQIPT has the dynamic routing feature, the security exit, which can implement dynamic routing from MQIPT to different queue managers based on the contents of the message. For this feature to work, MQIPT must be able to interrogate the packet in clear text. The message must arrive in one of the unsecured modes (HTTP or native MQ), or MQIPT must act as an SSL termination point (incoming HTTPS or MQ over SSL).
To enforce connect and enqueue and dequeue control to the queues in the queue manager accessed by MQIPT, MQIPT needs to pass a client certificate to the queue manager, and this certificate must map to a TAM user with RemoteConnect permission in the TAM objectspace. This means the message must be sent to the queue manager as MQ over SSL (that is, MQIPT operating in SSLProxyMode) and will not be in the clear in MQIPT.
So if TAMBI enqueue and dequeue security is required within the queue manager, MQIPT must be in SSLProxyMode and this negates the use of the dynamic routing feature.
Impact on use of HTTPS
If HTTPS is used between MQIPTs, there is no way to pass a client certificate to the back-end queue manager. The MQIPT must communicate with the queue manager via MQ channels, so the HTTPS session is terminated at MQIPT and the message transferred to the MQ channel. To make use of TAMBI access control, a certificate must be presented to the queue manager that contains an identity that is mapped to a TAM identity. This requires the use of SSLProxyMode for the MQIPT, which is inconsistent with MQIPT accepting HTTPS traffic.
Even if SSL is used at the channel level between MQIPT and the queue manager, it is only a static certificate (that is, for the MQIPT client) not the one passed in the HTTPS session. So client-based authorization is not possible.
So if TAMBI enqueue and dequeue security is required within the queue manager, MQIPT must be in SSLProxytMode and this negates the use of HTTPS.
As with most solution design, there will often be a competing set of requirements that need to be prioritised to determine the most appropriate solution. This section looks at some different integration options based on one overriding requirement. These options are theoretical and would need to be tested in a live environment.
Requirement: Must use HTTPS through rxternal firewall
Many customers restrict port and protocol access through external firewalls to HTTPS only. If this is a high priority requirement, then MQIPT must be configured to act as an HTTPS endpoint.
This means the message sent to the queue manager will either be in the clear, or use a static certificate defined for the MQIPT client. The TAMBI enqueue and dequeue control will be limited to "unauthenticated" or mapped to the user defined in the static certificate. There is no way to have customer-specific access control when all messages are passing through the one MQIPT. If multiple MQIPTs were used and each had a unique certificate for the MQIPT to queue manager connection, then access could be controlled based on different MQIPTs.
To supplement the access control provided by TAMBI, the incoming HTTPS traffic could pass through WebSEAL (as part of TAMeB). If the origin of the message was controlled, you could limit the exposure caused by rogue servers sending MQ messages over HTTPS. If multiple MQIPTs are used, each with a different URL, WebSEAL can also control which originators can connect to the different MQIPTs (based on their URL).
Requirement: All MQ traffic must be encrypted within our network
Only the TAMBI interceptors can sign and encrypt the data in MQ messages. Native MQ can use SSL over channels, but not whilst the message data is in memory (or on disk if persistent queues are in use). If the requirement is that the data is encrypted from entry to the network (external firewall) through to it being processed by an application, there are two options:
- Use HTTPS or MQ over SSL coming into the MQIPT, then MQ over SSL to the queue manager. In this approach the packets are encrypted using SSL; into the network and then from MQIPT to the queue manager. The data is in the clear for some time in MQIPT (in memory) and when it arrives at the queue manager (in memory and potentially on disk). This approach does not use TAMBI. It has some exposure on the queue manager.
- Use TAMBI on both local and customer queue managers with quality of protection set to encrypt. The message will be encrypted by the TAMBI interceptor as it is being written to the customer queue manager; so the application data is encrypted not the whole MQ message. This message is then sent across the network by whatever means (HTTP, HTTPS, native MQ and MQ over SSL). The local MQIPT will pass it to the queue manager. The local application will use one of the TAMBI interceptors to get the message and it will be decrypted as it is read. This approach requires that TAMBI is used at both ends and the implementations share the necessary credentials to allow encryption and decryption at different sites. There needs to be some mechanism put in place between sites to keep the certificates synchronised.
Requirement: All access must be controlled and audited by customer
This requirement means that MQIPT must present the customer-specific certificate to the queue manager (which will be mapped to a TAM user by the TAMBI Channel Security Exit), so that the enqueue and dequeue requests can be checked and audited for each customer.
This requires that MQIPT be configured in SSLProxyMode, so MQIPT cannot act as a termination point for SSL, nor can it accept HTTP, HTTPS or MQ in the clear. The firewall configuration must allow customers to connect to the appropriate port and allow MQ traffic.
Requirement: Dynamic routing to different queue managers
This requirement means that MQIPT must act as an SSL termination point or receive messages in the clear (that is, HTTP or native MQ).
This limits the ability to use TAMBI access control. Either there will be no certificate passed from MQIPT to the various queue managers (meaning only "unauthenticated" access control) or a static certificate will be presented (meaning a fairly generic access control).
It might be possible to implement some custom coding in the MQIPT security exit that would use the TAM Java API (Authorization API). This would then leverage the single TAM object namespace that ITAMBI and ITAMeB also use. This would require customisation to interrogate the MQ message and determine access based on specific information, such as a company name. However it would not provide for the signing and encryption of messages. This is hypothetical and would need to be proven.
TAMBI and MQIPT are both very effective in doing what they were designed to do. When implementing both to apply security in a federated MQ environment, where MQ environment at two different customers are participating in a B2B model, there are some integration limitations that might apply. Whether these limitations will impact the integration depends on the level of security required and the level of complexity the customers are comfortable with.
This paper has outlined how TAMBI and MQIPT work in isolation. It has looked at how they integrate and the limitations on the integration. Finally, it has looked at how different requirements can affect the integration. These integration approaches are theoretical and not proven with live deployments.