Message exit
A message exit can be used only on a message channel, not on an MQI channel. It has access to both the transmission queue header, MQXQH, which includes the embedded message descriptor, and the application data in a message. It can modify the contents of the message and change its length. A message exit can be used for any purpose that requires access to the whole message rather than a portion of it.
Message exits can be used to provide the security services described in the following sections.
Identification and authentication
When an application puts a message on a queue, the UserIdentifier field in the message descriptor contains a user ID associated with the application. However, there is no data present that can be used to authenticate the user ID. This data can be added by a message exit at the sending end of a channel and checked by a message exit at the receiving end of the channel. The authenticating data can be an encrypted password or a digital signature, for example.
This service might be more effective if it is implemented at the application level. The basic requirement is for the user of the application that receives the message to be able to identify and authenticate the user of the application that sent the message. It is therefore natural to consider implementing this service at the application level.
Access control
In a client/server environment, consider a client application that sends a message to a server application. The server application can extract the user ID from the UserIdentifier field in the message descriptor and, provided it has alternate user authority, ask the queue manager to use this user ID for authority checks when it accesses WebSphere MQ resources on behalf of the client.
If the PUTAUT parameter is set to CTX (or ALTMCA on z/OS) in the channel definition at the receiving end of a channel, the user ID in the UserIdentifier field of each incoming message is used for authority checks when the MCA opens the destination queue.
In certain circumstances, when a report message is generated, it is put using the authority of the user ID in the UserIdentifier field of the message causing the report. In particular, confirm-on-delivery (COD) reports and expiration reports are always put with this authority.
Because of these situations, it might be necessary to substitute one user ID for another in the UserIdentifier field as a message enters a new security domain. This can be done by a message exit at the receiving end of the channel. Alternatively, you can ensure that the user ID in the UserIdentifier field of an incoming message is defined in the new security domain.
If an incoming message contains a digital certificate for the user of the application that sent the message, a message exit can validate the certificate and map the Distinguished Name in the certificate to a user ID that is valid on the receiving system. It can then set the UserIdentifier field in the message descriptor to this user ID.
If it is necessary for a message exit to change the value of the UserIdentifier field in an incoming message, it might be appropriate for the message exit to authenticate the sender of the message at the same time. For more details, see Identification and authentication.
Confidentiality
A message exit at the sending end of a channel can encrypt the application data in a message and another message exit at the receiving end of the channel can decrypt the data. For performance reasons, a symmetric key algorithm is normally used for this purpose. For more information about how the symmetric key can be generated and distributed, see Confidentiality.
Headers in a message, such as the transmission queue header, MQXQH, which includes the embedded message descriptor, must not be encrypted by a message exit. This is because data conversion of the message headers takes place either after a message exit is called at the sending end or before a message exit is called at the receiving end. If the headers are encrypted, data conversion fails and the channel stops.
Data integrity
A message can be digitally signed by a message exit at the sending end of a channel. The digital signature can then be checked by a message exit at the receiving end of a channel to detect whether the message has been deliberately modified.
Some protection can be provided by using a message digest instead of a digital signature. A message digest might be effective against casual or indiscriminate tampering, but it does not prevent the more informed individual from changing or replacing the message, and generating a completely new digest for it. This is particularly true if the algorithm that is used to generate the message digest is a well known one.
Non-repudiation
If incoming messages are digitally signed, a message exit at the receiving end of a channel can log sufficient evidence to enable the digital signature of a message to be checked at any time in the future. This can form the basis of a non-repudiation service with proof of origin.
Like the identification and authentication service, this service might be more effective if it is implemented at the application level. At the application level, the service can also be extended to provide proof of delivery. For more information about how this service can be implemented at the application level, see Non-repudiation.
Other uses of message exits
Message exits can be used for reasons other than security. For example, a message exit can be used for application data conversion, although a data conversion exit is normally more appropriate for this purpose. They can be used for compressing and decompressing the application data in messages if the communications subsystem cannot provide this function. Headers in a message must not be compressed by a message exit because it causes data conversion of the message headers to fail.
Message exits also play an important role in implementing reference messages. Reference messages allow a large object, such as a file, to be transferred from one system to another without needing to store the object in a WebSphere MQ queue at either the source or destination queue manager. For more information about reference messages, see the WebSphere MQ Application Programming Guide.
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.