When a local TP attempts to allocate a conversation with a partner TP, the local LU sends an attach request to the partner LU, asking it to attach the partner TP. Under certain circumstances, the attach request can contain security information, which the partner LU can use to authenticate the local TP. This is known as conversation level authentication, or end user verification.
The following sections describe how WebSphere MQ provides support for conversation level authentication.
The support for conversation level authentication in WebSphere MQ for iSeries, WebSphere MQ on UNIX(R) systems, and WebSphere MQ for Windows is illustrated in Figure 10. The numbers in the diagram correspond to the numbers in the description that follows.
On i5/OS(TM), UNIX systems, and Windows(R) 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:
A side information entry can also specify the following security information:
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 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 ):
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 books.
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.
On WebSphere MQ for z/OS, MCAs do not use CPI-C. Instead, they use APPC/MVS TP Conversation Callable Services, an implementation of Advanced Program-to-Program Communication (APPC), which has some CPI-C features. When a caller MCA allocates a conversation, a security type of SAME is specified on the call. Therefore, because an APPC/MVS LU supports persistent verification only for inbound conversations, not for outbound conversations, there are two possibilities:
On WebSphere MQ for z/OS, the USERID and PASSWORD parameters on the DEFINE CHANNEL command cannot be used for a message channel and are valid only at the client connection end of an MQI channel. Therefore, an attach request from an APPC/MVS LU never contains values specified by these parameters.
For more information about conversation level authentication, see Systems Network Architecture LU 6.2 Reference: Peer Protocols, SC31-6808. For information specific to z/OS(R), see z/OS MVS(TM) Planning: APPC/MVS Management, SA22-7599.
For more information about CPI-C, see Common Programming Interface Communications CPI-C Specification, SC31-6180. For more information about APPC/MVS TP Conversation Callable Services, see z/OS MVS Programming: Writing Transaction Programs for APPC/MVS, SA22-7621.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ls1snaconv |