Queue-based security and asynchronous queues

With synchronous queues, queue-based security is relatively simple. In this case a message is put to a synchronous remote queue definition that has the same security attributes as the destination queue. The message is transmitted over a connection with appropriate security attributes and is stored on the secure queue.

With asynchronous queues, especially Store-and-forward queues and Home-server queues, the transmitting and receiving queues are more likely to have different security attributes. These differences have to be managed during message transfer.

Once a message has been put to an asynchronous queue it is transmitted from one queue to another until it reaches its destination. A queue manager is responsible for requesting the transfer of the message between a pair of queues and another queue manager is responsible for responding to the request.

If queue based security is used, the requesting queue manager tries to establish a connection with security attributes that match the queue that it owns. The queue manager receiving the request checks that the existing attributes are sufficient for its queue. For example, suppose a client queue manager has a queue with a DES cryptor on it and messages are routed from this to a server's Store-and-forward queue that has a MARS cryptor. When the client is triggered to send a message it tries to establish a DES encrytped connection to the server; the server asks the Store-and-forward queue whether it will accept messages over a DES encrypted connection.

If a queue doesn't have any attribute rules, it only accepts a connection that has exactly the same cryptor as itself. This behavior can be overridden by attribute rules and by default queues use examples.rules.AttributeRules. These default rules group cryptors into four strengths:

  1. No cryptor
  2. XOR cryptor
  3. DES cryptor
  4. All the other cryptors (triple DES, MARS, RC4, RC6)

Using these rules, a queue accepts messages from a connection if the cryptor on the connection is at least as strong as its own cryptor:

In the previous example, if the Store-and-forward queue used these rules it would not accept a DES encrypted connection because DES is not as strong as its own MARS cryptor, it would throw an "attribute mismatch" exception.

A Home-server queue trying to pull messages from a Store-and-forward queue needs a cryptor that is at least as strong as that on the Store-and-forward queue, because the Home-server queue is at the initiating end of the request. Once the Home-server queue has received the message it can store it on a local queue that has any level of protection.

This behavior can be changed by using different attribute rules on the queues. The equals() method is used to compare the cryptors, so if the attribute rule has an equals() method that always returns true, the queue accepts connections with any cryptor.

Trying to send a message from a queue with a weaker cryptor to a queue with a stronger cryptor usually results in an "attribute mismatch" exception. However if a connection with a strong cryptor already exists between the queue managers, this can be reused (depending on the attribute rules on the connection) and result in the message being delivered.



© IBM Corporation 2000, 2003. All Rights Reserved