The level of queue-based security to be used is determined through the setting of attributes on queues. As a consequence of these attributes, WebSphere MQ Everyplace uses, if required, appropriate secure channels, and cryptors, compressors and controls access through authenticators.
The relevant queue properties are:
Certain security property, such as com.ibm.mqe.attributes.MQeWTLSCertAuthenticator, prerequisite an appropriate private registry, where the entity's private/public keys can be found, and, in some cases the queue manager's public registry, where foreign entities' public keys can be found. This happens when a security attribute uses a public/private key based algorithm to perform encryption/authentication.
There are two types of private registries, queue manager owed and queue owed and each private registry only stores its owner's security credentials. The queue manager's credential, however, can be shared by the queues it owes. For this reason, if the com.ibm.mqe.attributes.MQeWTLSCertAuthenticator class authenticator is used, an additional parameter "target registry" on the queue attribute the authenticator is attached to must also be set. This parameter determines which registry is to supply the credentials for authentication, and can have the value of either "Queue manager" or "Queue".
If "Queue manager" is specified, the credentials used are those of the queue manager owning the queue, and come from the private registry of the queue manager. The queue manager originally obtains these credentials through auto-registration with the mini-certificate server (see the relevant "Private Registry Service" section the WebSphere MQ Everyplace Application Programming Guide for further details). This option is the recommended default.
If "Queue" is specified, the credentials used are those of the queue itself, and come from the private registry of the queue. The queue originally obtains these credentials through auto-registration with the mini-certificate server as well.
Please refer to the "Mini-certificate issuance service" in the WebSphere MQ Everyplace Application Programming Guide for issues related to mini-certificate management issues.
Queue attribute can be set on all queue definitions. They not only affect the way messages are stored one the queues in question but also affect the way messages are transmitted over communication channels. WebSphere MQ Everyplace creates security attributes internally based on target queue attributes. The actual effect they have depends upon the kind of queue definition the queue attributes are involved:
When data is sent between a queue manager and a remote queue, the queue manager opens a channel to the remote queue manager that owns the queue. By default, if the remote queue is protected, for example with a cryptor, the channel is given exactly the same level of protection as the queue. For efficiency in queue-based security, a WebSphere MQ Everyplace channel uses symmetric cryptors (for example, DES, 3DES, MARS, RC4, RC6); a consequence of which is that the two queue managers at either end must use the same encryption key. When such a channel is established, a protocol, called the Diffie Hellman key exchange, is used to establish a secret key that only the two queue managers know. This protocol is susceptible to a "man in the middle" attack, but for that to be successful, the "man in the middle" must know some of the data that is fed into the Diffie Hellman protocol. This data is held in the com.ibm.mqe.attributes.MQeDHk class. It is possible for an attacker to get hold of this data, by examining the shipped WebSphere MQ Everyplace classes. However, this data can be changed by running the com.ibm.mqe.attributes.MQeGenDH utility; it generates a new Java source file com.ibm.mqe.attributes.MQeDHk.java. This file can then be compiled into a replacement com.ibm.mqe.attributes.MQeDHk.class file. When the com.ibm.mqe.attributes.MQeWTLSCertAuthenticator is used, the two queue managers (or queues) swap certificates in order to authenticate each other. If this is used in conjunction with a cryptor on the queue, the exchanges which establish the secret key for the cryptor are protected with the public keys from the certificates, making a "man in the middle" attack even more difficult.
With synchronous remote 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 channel with appropriate security attributes and is stored on the secure queue.
With asynchronous remote 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 establishes a channel with security attributes that match the queue that it owns. The queue manager receiving the request checks that the channel 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 establishes a DES encrypted channel to the server; the server asks the Store-and-forward queue whether it will accept messages over a DES encrypted channel. If the Store-and-forward queue considers DES is not as strong as its own MARS cryptor (determined by the queue attribute rule), 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. For example, if the attribute rule always allows reuse, the queue will accept channels 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 channel with a strong cryptor already exists between the queue managers, this can be reused (depending on the attribute rules on the channel) and result in the message being delivered.
One slight exception to the above behavior is when a Store-and-forward queue is used to forward (push) messages to other queues. The Store-and-forward queue establishes a channel with security attributes that match its own. However, in this case the destination queue accepts the channel without checking its attributes against the queue's. For example, a Store-and-forward queue without a cryptor would establish a channel without a cryptor and this would be used to forward messages to a destination queue even if the queue had a cryptor on it. Normally, with other queue types, this would result in an "attribute mismatch" exception. When using a Store-and-forward queue in this way, you should ensure that it has a cryptor that is comparable to any cryptor on a destination queue. This does not apply when a Home-server queue polls for messages from a Store-and-forward queue (in this case the Home-server queue establishes the channel, not the Store-and-forward queue).
To reduce the number of channels open concurrently, the queue manager can reuse an existing channel if its level of protection is adequate. If none of the channels has a suitable level of protection, the queue manager can also change (upgrade) the level of protection on an existing channel to match that required for the queue. This kind of behavior is governed by the MQeattributeRule on both the queue and the channel. These rules apply to the attribute on the queue (and channel), they are not the same as queue rules. Attribute rules are set on a queue when it is created or modified using administration messages.
The isAcceptable() method on the MQeAttributeRule class determines if a channel can be reused. This provides protection against inconsistency in the queue attribute rules on the local and target queue managers. If the isAcceptable() method returns true, the channel is used. Otherwise, the channel will not be reused.
If none of the existing channels can be reused, the queue manager checks if any of the channels can be upgraded to the required level. The permit() method on the MQeAttributeRule class determines this. If the permit() method returns true, the channel is upgraded. Otherwise, the channel is be upgraded.
WebSphere MQ Everyplace provides a default rule, com.ibm.mqe.MQeAttributeRule (identical to examples.rules.AttributeRule. This is specified as the attribute rule for a queue by WebSphere MQ Everyplace by default.
This rule has the following upgrade behavior:
If the attribute rule is explicitly set to null, WebSphere MQ Everyplace adopts an internal rule, com.ibm.mqe.MQeAttributeDefaultRule. This rule only accepts a channel that has exactly the same authenticator (and authenticated to the same entity), cryptor, and compressor as itself for reuse and always allow channel upgrade.
Because of the way channel security works, when a specific attribute rule is specified for a target queue, it forces the local queue manager to create an instance of the same attribute rule (examples.rules.AttributeRule and com.ibm.mqe.MQeAttributeRule are treated as the same rule for backward compatibility). A null rule can be specified for the target queue, to avoid the need to have the same attribute rule available remotely.
While the com.ibm.mqe.MQeAttributeRule provides practical defaults, there may be a solution specific reason why different behavior is required. You can modify the way channels are reused by extending or replacing the default com.ibm.mqe.MQeAttributeRule with rules that define the desired behavior.