Identifying and authenticating users

We can identify and authenticate users by using X.509 certificates, the MQCSP structure or in several types of user exit program.

Use X.509 certificates

We can identify and authenticate users by using x.509 certificates with the CHLAUTH command and SSLPEER parameter. The SSLPEER parameter specifies a filter to use to compare with the Subject Distinguished Name of the certificate from the peer queue manager or client at the other end of the channel.

For more information about using the CHLAUTH command and SSLPEER parameter, see SET CHLAUTH.

Use the MQCSP structure

Implement identification and authentication in security exits

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 IBM MQ client application. In this situation, mutual authentication actually takes place between two queue managers, or between a queue manager and the user of an IBM MQ MQI client application.

The supplied security exit (the SSPI channel exit) illustrates how mutual authentication can be implemented by exchanging authentication tokens that are generated, and then checked, by a trusted authentication server such as Kerberos. For more details, see The SSPI channel exit program on Windows.

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.

Transport Layer Security (TLS) uses PKI techniques like the ones just described. For more information about how TLS performs authentication, see Transport Layer Security (TLS) 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 Implement confidentiality in user exit programs. 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.

Implement identification and authentication in message exits

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. For more information, see Identity mapping in the API exit and API-crossing exit.

Implement identification and authentication in the API exit and API-crossing exit

At the level of an individual message, identification and authentication is a service that involves two users, the sender and the receiver of the message. 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. Note that the requirement is for one way, not two way, authentication.

Depending on how it is implemented, the users and their applications might need to interface, or even interact, with the service. In addition, when and how the service is used might depend on where the users and their applications are located, and on the nature of the applications themselves. It is therefore natural to consider implementing the service at the application level rather than at the link level.

• On a message channel, how do you apply the service only to those messages that require it?
• How do you enable users and their applications to interface, or interact, with the service, if this is a requirement?
• In a multi-hop situation, where a message is sent over more than one message channel on the way to its destination, where do you invoke the components of the service?

Here are some examples of how the identification and authentication service can be implemented at the application level. The term API exit means either an API exit or an API-crossing exit.

• When an application puts a message on a queue, an API exit can acquire an authentication token from a trusted authentication server such as Kerberos. The API exit can add this token to the application data in the message. When the message is retrieved by the receiving application, a second API exit can ask the authentication server to authenticate the sender by checking the token.
• When an application puts a message on a queue, an API exit can append the following items to the application data in the message:
  • The digital certificate of the sender
  • The digital signature of the sender

  If different algorithms for generating a message digest are available for use, the API exit can include the name of the algorithm it has used. When the message is retrieved by the receiving application, a second API exit can perform the following checks:

  • The API exit can validate the digital certificate by working through the certificate chain to the root CA certificate. To do this, the API exit must have access to a key repository that contains the remaining certificates in the certificate chain. This check provide assurance that the sender, identified by the Distinguished Name, is the genuine owner of the public key contained in the certificate.
  • The API exit can check the digital signature using the public key contained in the certificate. This check authenticates the sender.

  The Distinguished Name of the sender can be sent instead of the whole digital certificate. In this case, the key repository must contain the sender's certificate so that the second API exit can find the public key of the sender. Another possibility is to send all the certificates in the certificate chain.

• When an application puts a message on a queue, the UserIdentifier field in the message descriptor contains a user ID associated with the application. The user ID can be used to identify the sender. To enable authentication, an API exit can append some data, such as an encrypted password, to the application data in the message. When the message is retrieved by the receiving application, a second API exit can authenticate the user ID by using the data that has travelled with the message.

  This technique might be considered sufficient for messages that originate in a controlled and trusted environment, and in circumstances where a trusted authentication server or PKI support is not available.

Pluggable Authentication Method (PAM)

PAM is now common across UNIX and Linux platforms, and provides a general mechanism that hides the details of user authentication from services.

Different authentication rules can be used for different services, by configuring the rules, without any change needed to the services themselves.

See Use the Pluggable Authentication Method (PAM) for further information.

• Privileged users
  A privileged user is one that has full administrative authorities for IBM MQ.
• Identifying and authenticating users using the MQCSP structure
  We can specify the MQCSP connection security parameters structure on an MQCONNX call.
• Implement identification and authentication in security exits
  We can use a security exit to implement one-way or mutual authentication.
• Identity mapping in message exits
  We can use message exits to process information to authenticate a user ID, though it might be better to implement authentication at the application level.
• Identity mapping in the API exit and API-crossing exit
  An application that receives a message must be able to identify and authenticate the user of the application that sent the message. This service is typically best implemented at the application level. API exits can implement the service in a number of ways.
• Work with revoked certificates
  Digital certificates can be revoked by Certificate Authorities. We can check the revocation status of certificates using OCSP, or CRLs on LDAP servers, depending on platform.
• Use the Pluggable Authentication Method (PAM)
  We can use PAM only on UNIX and Linux platforms. A typical UNIX system has PAM modules that implement the traditional authentication mechanism; however, there might be more. As well as the basic task of validating passwords, PAM modules can also be invoked to carry out additional rules.

Parent topic: Securing IBM MQ