WebSphere MQ Everyplace queue-based security can be used whenever you need to protect the confidentiality of message data being transferred between queue managers.
A typical scenario could be a service that is delivered over an open network, like the internet, where an initiating application makes requests, using a queue manager on a client, to access a service provided by a server queue manager application.
This can be implemented as follows:
One way to support this simple example would be to define the following queues:
While a number of choices exist, setting the TestClient_HomeServerQ TimerInterval option, to 5000 for example, sets a 5sec poll interval and triggers the client queue manager to poll the server queue manager. This poll 'pulls' any messages on the server queue manager's store-and-forward queue that have been directed to the client queue manager. Also, before running any client queue manager application, the MQE_ADMIN_ACTION_ADD_QMGR option must be used to add a reference to the server queue manager.
Defining the TestServer_StoreAndForwardQ for use in this scenario requires two steps.
When using queue-based security all the choices for attribute are available:
Queue-based security is appropriate for solutions designed to use synchronous queues. In this case, the selection criteria is really concerned with the selection of the (synchronous) queue attribute's authenticator, cryptor and compressor.
The option to use an Authenticator is driven by the need to provide additional controls to prevent access to the local data by unauthorized users. This is equally relevant when the queue data is accessed locally or remotely.
Using a descendant of LogonAuthenticator, when the attribute is activated, for example when an application is performing a putMessage(), getMessage() or browseMessages() of data on the queue, the requirements of the authenticator have to be satisfied before the operation is permitted. In the queue-based Usage scenario, if the XXX_service_request queue is defined with an attribute including the NTAuthenticator, then access to the server XXX_service_request queue (for example when attempting to putMessage() requests to this queue from a client queue manager), is restricted to the set of users defined as valid NT users in the target server's domain.
Using MQeWTLSCertAuthenticator ensures that all remote accesses to a queue protected with an attribute using this authenticator have completed mutual authentication before the operation can be executed. The mutual authentication of the mini-certificates exchanged consists of each participant validating the mini-certificate it receives. This validation checks the mini-certificate received is a valid signed entity, signed by the same mini-certificate server as the requestor's own mini-certificate, and that it is valid with respect to date, that is the current date is not prior to its from-date or after its to-date. An administration option enables the solution creator to choose whether a target queue manager queue has its own credentials (that it is an authenticatable entity in its own right, with its own mini-certificate and associated private key) or shares the credentials of its owning queue manager. In the queue-based Usage scenario, if the XXX_service_request queue is defined with an attribute containing the MQeWTLSCertAuthenticator, then access to the server XXX_service_request queue, for example when the initiating client queue manager application performs a remote putMessage(), depends on the credentials of the initiating client queue manager and the target XXX_service_request queue being successfully mutually authenticated.
The choice of cryptor is driven by the strength of protection required, that is, the degree of difficulty that an attacker would face when cryptographically attacking the protected data to get illegal access. Data protected with symmetric ciphers which use 128 bit keys is acknowledged as being more difficult to attack than data protected using ciphers that use shorter keys. But in addition to cryptographic strength. The selection of a cipher may also be driven by many other factors. An example of this is some financial solutions require the use of triple DES in order to get audit approval.
The option to use a compressor is driven by the need to optimize the size of the protected data. However, the effectiveness of the compressor depends on the content of the data. The MQeRleCompressor performs run length encoding ; that is, the compressor routines compress and/or expand repeated bytes. Hence it is effective in compressing/decompressing data with many repeated bytes. MQeLZWCompressor uses the LZW scheme. The simplest form of the LZW algorithm uses a dictionary data structure in which various words (data patterns) are stored against different codes. This compressor is likely to be most effective where the data has a significant number of repeating words (data patterns).