Security exit

 

Security exits normally work in pairs; one at each end of a channel. They are called immediately after the initial data negotiation has completed on channel startup. Security exits can be used to provide the security services described in the following sections.

 

Identification and authentication

The primary purpose of a security exit is to enable the MCA at each end of a channel to authenticate its partner. At each end of a message channel, and at the server end of an MQI channel, an MCA typically acts on behalf of the queue manager to which it is connected. At the client end of an MQI channel, an MCA typically acts on behalf of the user of the WebSphere MQ client application. In this situation, mutual authentication actually takes place between two queue managers, or between a queue manager and the user of a WebSphere MQ client application.

The supplied security exits illustrate how mutual authentication can be implemented by exchanging authentication tokens that are generated, and subsequently checked, by a trusted authentication server such as DCE or Kerberos.

Mutual authentication can also be implemented by using Public Key Infrastructure (PKI) technology. Each security exit generates some random data, signs it using the private key of the queue manager or user it is representing, and sends the signed data to its partner in a security message. The partner security exit performs the authentication by checking the digital signature using the public key of the queue manager or user. Before exchanging digital signatures, the security exits might need to agree the algorithm for generating a message digest, if more than one algorithm is available for use.

When a security exit sends the signed data to its partner, it also needs to send some means of identifying the queue manager or user it is representing. This might be a Distinguished Name, or even a digital certificate. If a digital certificate is sent, the partner security exit can validate the certificate by working through the certificate chain to the root CA certificate. This provides assurance of the ownership of the public key that is used to check the digital signature.

The partner security exit can validate a digital certificate only if it has access to a key repository that contains the remaining certificates in the certificate chain. If a digital certificate for the queue manager or user is not sent, one must be available in the key repository to which the partner security exit has access. The partner security exit cannot check the digital signature unless it can find the signer's public key.

The SSL uses PKI techniques similar to ones just described. For more information about how the SSL performs authentication, see SSL concepts.

If a trusted authentication server or PKI support is not available, other techniques can be used. A common technique, which can be implemented in security exits, uses a symmetric key algorithm.

One of the security exits, exit A, generates a random number and sends it in a security message to its partner security exit, exit B. Exit B encrypts the number using its copy of a key which is known only to the two security exits. Exit B sends the encrypted number to exit A in a security message with a second random number that exit B has generated. Exit A verifies that the first random number has been encrypted correctly, encrypts the second random number using its copy of the key, and sends the encrypted number to exit B in a security message. Exit B then verifies that the second random number has been encrypted correctly. During this exchange, if either security exit is not satisfied with the authenticity of other, it can instruct the MCA to close the channel.

An advantage of this technique is that no key or password is sent over the communications connection during the exchange. A disadvantage is that it does not provide a solution to the problem of how to distribute the shared key in a secure way. One solution to this problem is described in Confidentiality. A similar technique is used in SNA for the mutual authentication of two LUs when they bind to form a session. The technique is described in Session level authentication.

All the preceding techniques for mutual authentication can be adapted to provide one way authentication.

 

Access control

Security exits can play a role in access control.

Every instance of a channel that is current has an associated channel definition structure, MQCD. The initial values of the fields in MQCD are determined by the channel definition that is created by a WebSphere MQ administrator. In particular, the initial value of one of the fields, MCAUserIdentifier, is determined by the value of the MCAUSER parameter on the DEFINE CHANNEL command, or by the equivalent to MCAUSER if the channel definition is created in another way.

The MQCD structure is passed to a channel exit program when it is called by an MCA. When a security exit is called by an MCA, the security exit can change the value of MCAUserIdentifier, replacing any value that was specified in the channel definition.

On OS/400, UNIX systems, and Windows systems, unless the value of MCAUserIdentifier is blank, the queue manager uses the value of MCAUserIdentifier as the user ID for authority checks when an MCA attempts to access the queue manager's resources after it has connected to the queue manager. If the value of MCAUserIdentifier is blank, the queue manager uses the default user ID of the MCA instead. This applies only to receiving MCAs and server connection MCAs, and assumes that the PUTAUT parameter is set to DEF in the channel definition. The queue manager always uses the default user ID of a sending MCA for authority checks, even if the value of MCAUserIdentifier is not blank.

On z/OS, the queue manager might use the value of MCAUserIdentifier for authority checks, provided it is not blank. For receiving MCAs and server connection MCAs, whether the queue manager uses the value of MCAUserIdentifier for authority checks depends on:

For sending MCAs, it depends on:

The user ID that a security exit stores in MCAUserIdentifier can be acquired in various ways. Here are some examples:

  • Provided there is no security exit at the client end of an MQI channel, a user ID associated with the WebSphere MQ client application flows from the client connection MCA to the server connection MCA when the client application issues an MQCONN call. The server connection MCA stores this user ID in the RemoteUserIdentifier field in the channel definition structure, MQCD. If the value of MCAUserIdentifier is blank at this time, the MCA stores the same user ID in MCAUserIdentifier. If the MCA does not store the user ID in MCAUserIdentifier, a security exit can do it subsequently by setting MCAUserIdentifier to the value of RemoteUserIdentifier.

    If the user ID that flows from the client system is entering a new security domain and is not valid on the server system, the security exit can substitute the user ID for one that is valid and store the substituted user ID in MCAUserIdentifier.

  • The user ID can be sent by the partner security exit in a security message.

    On a message channel, a security exit called by the sending MCA can send the user ID under which the sending MCA is running. A security exit called by the receiving MCA can then store the user ID in MCAUserIdentifier. Similarly, on an MQI channel, a security exit at the client end of the channel can send the user ID associated with the WebSphere MQ client application. A security exit at the server end of the channel can then store the user ID in MCAUserIdentifier. As in the previous example, if the user ID is not valid on the target system, the security exit can substitute the user ID for one that is valid and store the substituted user ID in MCAUserIdentifier.

    If a digital certificate is received as part of the identification and authentication service, a security exit can map the Distinguished Name in the certificate to a user ID that is valid on the target system. It can then store the user ID in MCAUserIdentifier.

For more information about the MCAUserIdentifier field and the channel definition structure, MQCD, see WebSphere MQ Intercommunication. For more information about how the MCAUserIdentifier field is used for authority checks on z/OS, see the WebSphere MQ for z/OS System Setup Guide. For more information about the user ID that flows from a client system on an MQI channel, see WebSphere MQ Clients.

 

Confidentiality

Security exits can play a role in the confidentiality service by generating and distributing the symmetric key for encrypting and decrypting the data that flows on the channel. A common technique for doing this uses PKI technology.

One security exit generates a random data value, encrypts it with the public key of the queue manager or user that the partner security exit is representing, and sends the encrypted data to its partner in a security message. The partner security exit decrypts the random data value with the private key of the queue manager or user it is representing. Each security exit can now use the random data value to derive the symmetric key independently of the other by using an algorithm known to both of them. Alternatively, they can simply use the random data value as the key.

If the first security exit has not authenticated its partner by this time, the next security message sent by the partner can contain an expected value encrypted with the symmetric key. The first security exit can now authenticate its partner by checking that the partner security exit was able to encrypt the expected value correctly.

The security exits can also use this opportunity to agree the algorithm for encrypting and decrypting the data that flows on the channel, if more than one algorithm is available for use.

 

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.