Support for conversation level authentication in IBM MQ on [IBMi] IBM i, UNIX systems, and Windows systems

Use this topic to gain an overview of how conversation level authentication works, on platforms other than z/OS®.

The support for conversation level authentication in IBM® MQ for [IBMi] IBM i, IBM MQ on UNIX systems, and IBM MQ for Windows is illustrated in Figure 1. The numbers in the diagram correspond to the numbers in the description that follows.
Figure 1. IBM MQ support for conversation level authentication
This diagram shows the support that IBM MQ provides for conversation level authentication. A DEFINE CHANNEL command specifies values for the USERID and PASSWORD parameters. The caller MCA calls CMINIT to initialize the characteristics of the conversation using the information in the CPI-C side information entry that is referenced by the value of the CONNAME parameter in the DEFINE CHANNEL command. The caller MCA then calls CMSCST, CMSCSU, and CMSCSP to set the security type for the conversation to CM_SECURITY_PROGRAM, the user ID to the value of the USERID parameter, and the password to the value of the PASSWORD parameter. When the caller MCA calls CMALLC to allocate the conversation, the LU sends an attach request containing the values of the USERID and PASSWORD parameters.
On IBM i, UNIX systems, and Windows systems, an MCA uses Common Programming Interface Communications (CPI-C) calls to communicate with a partner MCA across an SNA network. In the channel definition at the caller end of a channel, the value of the CONNAME parameter is a symbolic destination name, which identifies a CPI-C side information entry (1). This entry specifies:
  • The name of the partner LU
  • The name of the partner TP, which is a responder MCA
  • The name of the mode to be used for the conversation
A side information entry can also specify the following security information:
  • A security type.

    The commonly implemented security types are CM_SECURITY_NONE, CM_SECURITY_PROGRAM, and CM_SECURITY_SAME, but others are defined in the CPI-C specification.

  • A user ID.
  • A password.

A caller MCA prepares to allocate a conversation with a responder MCA by issuing the CPI-C call CMINIT, using the value of CONNAME as one of the parameters on the call. The CMINIT call identifies, for the benefit of the local LU, the side information entry that the MCA intends to use for the conversation. The local LU uses the values in this entry to initialize the characteristics of the conversation (2).

The caller MCA then checks the values of the USERID and PASSWORD parameters in the channel definition (3). If USERID is set, the caller MCA issues the following CPI-C calls (4):
  • CMSCST, to set the security type for the conversation to CM_SECURITY_PROGRAM.
  • CMSCSU, to set the user ID for the conversation to the value of USERID.
  • CMSCSP, to set the password for the conversation to the value of PASSWORD. CMSCSP is not called unless PASSWORD is set.
The security type, user ID, and password set by these calls override any values acquired previously from the side information entry.

The caller MCA then issues the CPI-C call CMALLC to allocate the conversation (5). In response to this call, the local LU sends an attach request (Function Management Header 5, or FMH-5) to the partner LU (6).

If the partner LU will accept a user ID and a password, the values of USERID and PASSWORD are included in the attach request. If the partner LU will not accept a user ID and a password, the values are not included in the attach request. The local LU discovers whether the partner LU will accept a user ID and a password as part of an exchange of information when the LUs bind to form a session.

In a later version of the attach request, a password substitute can flow between the LUs instead of a clear password. A password substitute is a DES Message Authentication Code (MAC), or an SHA-1 message digest, formed from the password. Password substitutes can be used only if both LUs support them.

When the partner LU receives an incoming attach request containing a user ID and a password, it might use the user ID and password for the purposes of identification and authentication. By referring to access control lists, the partner LU might also determine whether the user ID has the authority to allocate a conversation and attach the responder MCA.

In addition, the responder MCA might run under the user ID included in the attach request. In this case, the user ID becomes the default user ID for the responder MCA and is used for authority checks when the MCA attempts to connect to the queue manager. It might also be used for authority checks subsequently when the MCA attempts to access the queue manager's resources.

The way in which a user ID and a password in an attach request can be used for identification, authentication, and access control is implementation dependent. For information specific to your SNA subsystem, refer to the appropriate documentation.

If USERID is not set, the caller MCA does not call CMSCST, CMSCSU, and CMSCSP. In this case, the security information that flows in an attach request is determined solely by what is specified in the side information entry and what the partner LU will accept.