IBM MQ for z/OS V9.1.3 Advanced Message Security Interception on server to server message channels

By Mayur RAJA posted Thu October 31, 2019 06:36 AM


IBM MQ Advanced Message Security (AMS) has been available for several years now. AMS allows you to protect messages at rest, in-transit and in memory, while dataset encryption allows you to protect messages at rest, and TLS enabled channels allow you to protect messages in transit.

Originally, AMS provided Privacy (sign and encrypt) and Integrity (sign only) levels of protection. However, more recently, Confidentiality (encrypt only) has been provided as a more performant level of protection. For specific details about the performance of each type of protection, please refer to the MQ Performance reports available at: .

It is also worth noting that while AMS has to be enabled at the Queue Manager level, AMS protection can be enabled, without the need to make any application changes, by defining policies on a per-queue basis. This means that AMS protection can be limited to those queues that hold critical or high value data, rather than enabling it for all queues in your MQ environment.

Prior to IBM MQ V9.1.3, when sending messages to AMS protected queues across queue managers, the requirement has been that Queue Managers should be enabled for AMS and that AMS protection should be enabled for both the source and target queues. Consider the following example of a Clearing House that requires that messages in its MQ network are protected:
Clearing House Example This means that for the Clearing House to exchange messages with a bank for example, policies need to be defined for the remote and target local queues:

Policies for remote and local target queuesHowever, it is highly likely that some banks or business partners do not support AMS:

Some banks or business partners do not support AMS

So, it would be unreasonable for the Clearing House to send protected messages to them because they would not be able to understand them. Similarly, as the Clearing House requires that all messages in their MQ network are protected, it needs to ensure that any messages it receives from banks or business partners that do not support AMS, are somehow protected.

MQ for z/OS V9.1.3 introduced support for AMS interception on server to server message channels. This feature adds the SPLPROT (Security Policy Protection) attribute on Sender and Receiver type server to server channels to control whether message protection should be added or removed:

SPLPROT attribute

The following example shows that by setting SPLPROT(REMOVE) on the sender channel, the Clearing House can unprotect messages before sending to a bank that does not support AMS. Similarly, by setting SPLPROT(ASPOLICY) on the receiver channel, the Clearing House can ensure that any inbound unprotected messages are protected on receive:

Unprotecting and Protecting Messages

Of course, additional policies would be required to achieve this as shown in the following examples:

Unprotect messages prior to sendIn the above example, the policy defined for the remote queue is used to protect messages at rest in the Clearing House, and the policy defined for the transmission queue is used to remove protection from the message before sending to the bank which does not support AMS.

Protect messages on receive

In the above example, the policy defined for the target local queue in the Clearing House is used to protected unprotected inbound messages from the bank and to unprotect messages when an application gets the messages.

Of course, suitable certificates also need to be defined for the above examples. The IBM MQ Knowledge Center documents additional AMS examples for IBM MQ for z/OS which list the RACF commands required to define suitable certificates. Refer to the folloing section for further details:

For details of the performance impact of using IBM MQ for z/OS V9.1.3 AMS interception on server to server message channels, refer to: . 

Support for the SPLPROT attribute on distributed MQ platforms will be considered in the future.