What are my options for using AMS and WebSphere Application Server Traditional?
Paul_Titheridge
Published on 02/03/2018 / Updated on 09/03/2018
IBM MQ Advanced Message Security (AMS), part of the MQ Advanced offering, provides a security model that allows messages to be protected “at rest” (while they are on a queue) and “in transit” (while they are being passed to applications for processing). Something that comes up quite a bit is “Is there a way I can take advantage of IBM MQ AMS for my applications running inside of WebSphere Application Server Traditional?”.
If your application server is installed onto the same system as your AMS enabled queue manager, and is connecting to it using the BINDINGS transport, then the good news is that it should just work. When enterprise applications running inside of WebSphere Application Server put messages to a protected queue, the queue manager will encrypt them before putting them onto the queue. If an enterprise application gets messages from a protected queue, then the queue manager will decrypt it before returning it to the application. This means that any supported version of WebSphere Application Server that is connecting to an AMS enabled queue manager using the BINDINGS transport can make use of AMS.
If your application server is located on a different system to the queue manager, and is connecting to it using the CLIENT transport, then you have three options:
Option 1: Use WebSphere Application Server Traditional V9.
The easiest option is to install and use WebSphere Application Server Traditional V9. This version of the application server embeds the IBM MQ V9 resource adapter, which contains the code needed to encrypt and decrypt messages that are put to, and received from, protected queues.
When an enterprise application running inside of the application server puts a message to a protected queue, then the IBM MQ resource adapter encrypts the message before sending it over to the queue manager. The queue manager will then store the encrypted message on the target queue.
Figure 1: Messages are encrypted by the MQ resource adapter before being sent to the queue manager. Similarly, when an enterprise application gets a message from a protected queue, the queue manager will send the encrypted message to the application server. The IBM MQ resource adapter will decrypt the message and then pass the unencrypted message to the application for processing.Figure 2: The queue manager sends encrypted messages to the IBM MQ resource adapter, which decrypts it before giving it to the application.
Option 2: Enable Message Channel Agent AMS interception.
If you are unable to use WebSphere Application Server Traditional V9, and you are connecting to a queue manager running on a distributed platform, then you can use message channel agent (MCA) AMS interception.
When MCA AMS interception is enabled on a channel, then if an enterprise application connects to a queue manager using that channel and puts a message to a protected queue, the message data will be unencrypted when it flows over the channel. The MCA will then encrypt the data before putting the message to the queue. Note that if you want to protect the message while it is “in transit” (flowing over the channel), the channel should be configured with SSL or TLS.
Figure 3: Messages are encrypted by the MCA before being put on the queue.
If an enterprise application connects to the queue manager over the channel and gets a message from a protected queue, the MCA will decrypt the message data. The MCA will then pass the decrypted message to the WebSphere MQ resource adapter embedded within the application server, which hands the message off to the application for processing. Once again, if you want to ensure that the message data is protected while it is “in transit” between the queue manager and the application server, configure the channel with either SSL or TLS.
Figure 4: Messages are decrypted by the MCA before being passed to the application server.
One thing to be aware of here is that encryption and decryption are heavyweight operations, and CPU intensive. If there are lots of enterprise applications putting to, and getting from, protected queues, there will be a significant load on the queue manager system. This isn’t an issue when using option 1, as the encryption and decryption occurs within the IBM MQ resource adapter embedded within WebSphere Application Server rather than on the queue manager.
Option 3: Use an intermediate queue manager.
MCA AMS interception is only available in queue managers running on distributed platforms. If your enterprise applications running inside of WebSphere Application Server V8.5 (or earlier) needs to access protected queues hosted on an IBM MQ for z/OS queue manager, then you will need to use an intermediate queue manager on a distributed platform. The intermediate queue manager will need to be set up with sender and receiver channels for the IBM MQ for z/OS queue manager, so that it can route messages to it, and must be configured with message channel agent (MCA) interception enabled.
When the enterprise application is putting messages to the protected queue, it connects to the intermediate queue manager and sends the unencrypted message. The MCA encrypts the message when it arrives over the channel, and forwards it to the target queue manager on z/OS. The target queue manager then puts the encrypted message onto the protected queue.
Figure 5: Messages are encrypted by the MCA on the intermediate queue manager, before being put to the protected queue on the IBM MQ for z/OS queue manager.
When receiving messages, a remote queue needs to be defined on the IBM MQ for z/OS queue manager that points to a local queue on the intermediate queue manager. The local queue needs to be protected. Applications that are connecting to the IBM MQ for z/OS queue manager will put protected messages to the remote queue. These protected messages are forwarded to the protected queue on the intermediate queue manager. When enterprise applications get messages from the local queue, the MCA will decrypt the message before passing it to the WebSphere MQ resource adapter embedded in the application server. Finally, the WebSphere MQ resource adapter hands the message off to the enterprise application for processing.
Figure 6: An application puts the encrypted messages to a remote queue, where they are forwarded to the protected queue. The enterprise application then gets the messages from the protected queue, using the MCA to do the decryption.
As with option 2 above, there are a few things that you should be aware of when adopting this approach.
- The message data will be encrypted when the message is “at rest” on the protected queues, and when it flows between the intermediate queue manager and the queue manager on z/OS. However, it will be unencrypted when it is “in transit” between the intermediate queue manager and the application server. To protect the data during this part of the flow, ensure that the channel is configured with TLS or SSL.
- Encryption and decryption are heavyweight operations, and are quite CPU intensive. If there are lots of enterprise applications putting to, and getting from, protected queues, there will be a significant load on the intermediate queue manager.
I hope this has given you a good, high-level overview of how to set up your environment so that enterprise applications running inside of WebSphere Application Server can make use of IBM MQ AMS. As always, if you have any questions, feel free to ask and I’ll be happy to answer them.
TAGS AMS, AMS INTERCEPTION, IBM MQ, WEBSPHERE
by Paul_Titheridge
2 comments on"What are my options for using AMS and WebSphere Application Server Traditional?"
- Paul_TitheridgeFebruary 26, 2020
Hi Abdul,
Thanks for the comment.
If AMS detects an issue with a message, it will put a dead letter header (MQDLH) onto the message and move it to the system queue SYSTEM.PROTECTION.ERROR.QUEUE. The information in the MQDLH will indicate why the message couldn’t be processed. It should be possible to use that to determine the cause of the issue.
More information on the way AMS handles errors can be found in the “Error handling” topic in the MQ sections of IBM Knowledge Center. The URI for this topic in the MQ V9.1.x section of IBM Knowledge Center is https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.1.0/com.ibm.mq.sec.doc/q014595_.htm.
Hope this helps!
Paul
Reply
- Abdul HalimFebruary 16, 2020
In case of AMS, the activity logs will also contain message in encrypted format.
In case of any issue such as message loss or put request failure on this queue how would we investigate and reconcile the message sent by external application and one received in mq queue.