Routing protected messages using WebSphere Message Broker - Middleware News

Routing protected messages using WebSphere Message Broker

IBM WebSphere MQ Advanced Message Security can protect messages in an infrastructure where WebSphere Message Broker version 8.0.0.1 (or later) is installed. You should understand the nature of both products before applying security in the WebSphere Message Broker environment.

About this task

WebSphere MQ Advanced Message Security provides end-to-end security of the message payload. This means that only the parties specified as the valid senders and recipients of a message are capable of producing or receiving it. This implies that in order to secure messages flowing through WebSphere Message Broker, you can either allow WebSphere Message Broker to process messages without knowing their content (Scenario 1) or make it an authorized user able to receive and send messages (Scenario 2).

Parent topic: User scenarios

Scenario 1 - Message Broker cannot see message content

Before you begin

You should have your WebSphere Message Broker connected to an existing queue manager.. Replace QMgrName with this existing queue manager name in the commands that follow.

About this task

In this scenario, Alice puts a protected message into an input queue QIN. Based on the message property routeTo, the message is routed either to bob's (QBOB), ¹ (QCECIL), or the default (QDEF) queue. The routing is possible because WebSphere MQ Advanced Message Security protects only the message payload and not its headers and properties which remain unprotected and can be read by WebSphere Message Broker. WebSphere MQ Advanced Message Security is used only by alice, bob and cecil. It is not necessary to install or configure it for the WebSphere Message Broker.

WebSphere Message Broker receives the protected message from the unprotected alias queue in order to avoid any attempt to decrypt the message. If it were to use the protected queue directly, the message would be put onto the DEAD LETTER queue as impossible to decrypt. The message is routed by WebSphere Message Broker and arrives on the target queue unchanged. Therefore it is still signed by the original author (both bob and cecil only accept messages sent by alice) and protected as before (only bob and cecil can read it). WebSphere Message Broker puts the routed message to an unprotected alias. The recipients retrieve the message from a protected output queue where WebSphere MQ AMS will transparently decrypt the message.

Procedure

1. Configure alice, bob and cecil to use WebSphere MQ Advanced Message Security as described in the Quick Start Guide (Windows or UNIX). Ensure the following steps are completed:
   • Creating and authorizing users
   • Creating Key Database and Certificates
   • Creating keystore.conf
2. Provide alice's certificate to bob and cecil, so alice can be identified by them when checking digital signatures on messages.

   runmqakm -cert -export -db <location-of-alicekey.kdb> -pw passw0rd
   -label Alice_Cert -target <location-of-bobkey.kdb> -target_pw passw0rd

3. Provide bob and cecil's certificates to alice, so alice can send messages encrypted for bob and cecil.

   runmqakm -cert -export -db <location-of-bobkey.kdb> -pw passw0rd
   -label Bob_Cert -target <location-of-alicekey.kdb> -target_pw passw0rd

4. On your queue manager, define local queues called QIN, QBOB, QCECIL and QDEF.

   DEFINE QLOCAL(QIN)

5. Setup the security policy for the QIN queue to an eligible configuration. Use the identical setup for the QBOB, QCECIL and QDEF queues.

   setmqspl -m QMgrName -p QIN -s SHA1 -a "CN=alice,O=IBM,C=GB"
   -e AES256 -r "CN=bob,O=IBM,C=GB" -r "CN=cecil,O=IBM,C=GB"

   This scenario assumes the security policy where alice is the only authorized sender and bob and cecil are the recipients.
6. Define alias queues AIN, ABOB and ACECIL referencing local queues QIN, QBOB and QCECIL respectively.

   DEFINE QALIAS(AIN) TARGET(QIN)

7. Verify that the security configuration for the aliases specified in the previous step is not present; otherwise set its policy to NONE.

   dspmqspl -m QMgrName -p AIN

8. In WebSphere Message Broker create a message flow to route the messages arriving on the AIN alias queue to the BOB, CECIL, or DEF node depending on the routeTo property of the message. To do so:
   1. Create an MQInput node called IN and assign the AIN alias as its queue name.
   2. Create MQOutput nodes called BOB, CECIL and DEF and assign alias queues ABOB, ACECIL and ADEF as their respective queue names.
   3. Create a route node and call it TEST.
   4. Connect the IN node to the input terminal of the TEST node.
   5. Create bob, and cecil output terminals for the TEST node.
   6. Connect the bob output terminal to the BOB node.
   7. Connect the cecil output terminal to the CECIL node.
   8. Connect the DEF node to the default output terminal.
   9. Apply the following rules:

      $Root/MQRFH2/usr/routeTo/text()="bob"
      $Root/MQRFH2/usr/routeTo/text()="cecil"

9. Deploy the message flow to the WebSphere Message Broker runtime component.
10. Running as the user Alice put a message that also contains a message property called routeTo with a value of either bob or cecil. Running the sample application amqsstm will allow you to do this.

    Sample AMQSSTMA start
    target queue is TEST.Q
    Enter property name
    routeTo
    Enter property value
    bob
    Enter property name
    
    Enter message text
    My Message to Bob
    Sample AMQSSTMA end

11. Running as user bob retrieve the message from the queue QBOB using the sample application amqsget.

Results

When alice puts a message on the QIN queue, the message is protected. It is retrieved in protected form by the WebSphere Message Broker from the AIN alias queue. WebSphere Message Broker decides where to route the message reading the routeTo property which is, as all properties, not encrypted. WebSphere Message Broker places the message on the appropriate unprotected alias avoiding its further protection. When received by bob or cecil from the queue, the message is decrypted and the digital signature is verified.

Scenario 2 - Message Broker can see message content

About this task

In this scenario, a group of individuals are allowed to send messages to WebSphere Message Broker. Another group are authorized to receive messages which are created by WebSphere Message Broker. The transmission between the parties and WebSphere Message Broker cannot be eavesdropped.

Remember that WebSphere Message Broker reads protection policies and certificates only when a queue is opened, so you must reload the execution group after making any updates to protection policies for the changes to take effect.

mqsireload execution-group-name

If WebSphere Message is considered an authorized party allowed to read or sign the message payload, you must configure WebSphere MQ Advanced Message Security for the user starting the WebSphere Message Broker service. Be aware it is not necessarily the same user who puts/gets the messages onto queues nor the user creating and deploying the WebSphere Message Broker applications.

Procedure

1. Configure alice, bob, cecil and dave and the WebSphere Message Broker service user, to use WebSphere MQ Advanced Message Security as described in the Quick Start Guide (Windows or UNIX). Ensure the following steps are completed:
   • Creating and authorizing users
   • Creating Key Database and Certificates
   • Creating keystore.conf
2. Provide alice, bob, cecil and dave's certificate to the WebSphere Message Broker service user.

   runmqakm -cert -export -db <location-of-alicekey.kdb> -pw passw0rd
   -label Alice_Cert -target <location-of-Message-Broker-key-database> -target_pw passw0rd

3. Provide the WebSphere Message Broker service user's certificate to alice, bob, cecil and dave.

   runmqakm -cert -export -db <location-of-Message-Broker-key-database> -pw passw0rd
   -label Broker_Cert -target <location-of-alicekey.kdb> -target_pw passw0rd

   Note: Alice and bob need the WebSphere Message Broker service user's certificate to encrypt the messages correctly. The WebSphere Message Broker service user needs alice's and bob's certificates to verify authors of the messages. The WebSphere Message Broker service user needs cecil's and dave's certificates to encrypt the messages for them. cecil and dave need the WebSphere Message Broker service user's certificate to verify if the message comes from WebSphere Message Broker.
4. Define a local queue named IN and define the security policy with alice and bob specified as authors and WebSphere Message Broker's service user specified as recipient:

   setmqspl -m QMgrName -p IN -s MD5 -a "CN=alice,O=IBM,C=GB" -a "CN=bob,O=IBM,C=GB"
   -e AES256 -r "CN=broker,O=IBM,C=GB"

5. Define a local queue named OUT and define the security policy with WebSphere Message Broker's service user specified as author and cecil and dave specified as recipients:

   setmqspl -m QMgrName -p OUT -s MD5 -a "CN=broker,O=IBM,C=GB" -e AES256
   -r "CN=cecil,O=IBM,C=GB" -r "CN=dave,O=IBM,C=GB"

6. In WebSphere Message Broker create a message flow with an MQInput and MQOutput node. Configure the MQInput node to use the IN queue and the MQOutput node to use the OUT queue.
7. Deploy the message flow to the WebSphere Message Broker runtime component.
8. Running as user alice or bob put a message on the queue IN using the sample application amqsput.
9. Running as user cecil or dave retrieve the message from the queue OUT using the sample application amqsget.

Results

Messages sent by alice or bob to the input queue IN are encrypted allowing only WebSphere Message Broker to read it. WebSphere Message Broker will only accept messages from alice and bob and will reject any others. The accepted messages will be appropriately processed then signed and encrypted with cecil's and dave's keys before being put onto the output queue OUT. Only cecil and dave are capable of reading it, messages not signed by WebSphere Message Broker are rejected.