Routing protected messages using IBM Integration Bus

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

About this task

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 IBM Integration Bus, we can either allow IBM Integration Bus 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 - Integration Bus cannot see message content

Before starting

We should have the IBM Integration Bus 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 Advanced Message Security protects only the message payload and not its headers and properties which remain unprotected and can be read by IBM Integration Bus. Advanced Message Security is used only by alice, bob and cecil. It is not necessary to install or configure it for the IBM Integration Bus.

IBM Integration Bus 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 IBM Integration Bus 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). IBM Integration Bus puts the routed message to an unprotected alias. The recipients retrieve the message from a protected output queue where AMS will transparently decrypt the message.

Procedure

1. Configure alice, bob and cecil to use Advanced Message Security as described in the Quick Start Guide ( Windows or UNIX ). Ensure the following steps are completed:
   • Create and authorizing users
   • Create Key Database and Certificates
   • Create keystore.conf

2. Provide alice's certificate to bob and cecil, so alice can be identified by them when checking digital signatures on messages.

   Do this by extracting the certificate identifying alice to an external file, then adding the extracted certificate to bob's and cecil's keystores. It is important that we use the method described in Task 5. Sharing Certificates in the Quick Start Guide (Windows or UNIX).

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

   Do this using the method specified in the previous step.

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

   DEFINE QLOCAL(QIN)
   

5. Set up 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 IBM Integration Bus 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 IBM Integration Bus 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 IBM Integration Bus from the AIN alias queue. IBM Integration Bus decides where to route the message reading the routeTo property which is, as all properties, not encrypted. IBM Integration Bus 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 - Integration Bus can see message content

About this task

In this scenario, a group of individuals are allowed to send messages to IBM Integration Bus. Another group are authorized to receive messages which are created by IBM Integration Bus. The transmission between the parties and IBM Integration Bus cannot be eavesdropped. Remember that IBM Integration Bus reads protection policies and certificates only when a queue is opened, so we must reload the execution group after making any updates to protection policies for the changes to take effect.

mqsireload execution-group-name

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

Procedure

1. Configure alice, bob, cecil and dave and the IBM Integration Bus service user, to use Advanced Message Security as described in the Quick Start Guide ( Windows or UNIX ). Ensure the following steps are completed:
   • Create and authorizing users
   • Create Key Database and Certificates
   • Create keystore.conf

2. Provide alice, bob, cecil and dave's certificates to the IBM Integration Bus service user.

   Do this by extracting each of the certificates identifying alice, bob, cecil and dave to external files, then adding the extracted certificates to the IBM Integration Bus keystore. It is important that we use the method described in Task 5. Sharing Certificates in the Quick Start Guide (Windows or UNIX).

3. Provide the IBM Integration Bus service user's certificate to alice, bob, cecil and dave.

   Do this using the method specified in the previous step.

   Note: Alice and bob need the IBM Integration Bus service user's certificate to encrypt the messages correctly. The IBM Integration Bus service user needs alice's and bob's certificates to verify authors of the messages. The IBM Integration Bus service user needs cecil's and dave's certificates to encrypt the messages for them. cecil and dave need the IBM Integration Bus service user's certificate to verify if the message comes from IBM Integration Bus.
4. Define a local queue named IN and define the security policy with alice and bob specified as authors, and the service user for the IBM Integration Bus 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 the service user for the IBM Integration Bus 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 IBM Integration Bus 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 IBM Integration Bus 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 IBM Integration Bus to read it. IBM Integration Bus only accepts messages from alice and bob and rejects any others. The accepted messages are 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 IBM Integration Bus are rejected. ¹ cecil's