Different types of bindings
IBM MQ supports two ways that an application can connect:
1. Local bindings: This is when the application and queue manager are on the same operating image. CHLAUTH is not relevant to this type of application connection.
2. Client bindings: This is when the application and queue manager use the network to communicate. The application and queue manager may be running on the same machine or they may be on different machines. In MQ a client connection is handled in the form of a server-connection (SVRCONN) channel. Both CONNAUTH and CHLAUTH are applicable, and it is this type of connection which is discussed.
The binding steps of a receiving end of a channel
When an application connects to a queue manager there is a lot of checking to perform to ensure that both ends of the channel understand what is supported by the other end. The receiving end does some extra checking to ensure that the client is allowed to connect. This checking involves CHLAUTH and CONNAUTH. This process may also include a security exit as this can affect the result. This channel connecting phase is also referred to as the binding phase.
In MQ version 7 SHARECNV was added to SVRCONN channels so multiple connections/conversations can share the same channel. This article does not cover what happens in terms of CHLAUTH and CONNAUTH when a second and following conversations share the same channel.
Figure 1 shows the steps that a SVRCONN channel goes through when the server end (at the queue manager) starts.
Step 1: Receive a connection request
The channel initiator or listener receives a connection request from somewhere on the network.
Step 2: Is address allowed to connect?
Before any data is read from the wire, MQ will check the partner’s IP address against the CHLAUTH rules to see if the address is in the BLOCKADDR rule. If the address is not found and so not blocked the flow proceeds to the next step.
Step 3: Read data from the channel
MQ can now read the data from the wire into a buffer and start to process the sent information.
Step 4: Look up channel definition
In the first data flow MQ sends amongst other things the name of the channel which the sending end is trying to start. The receiving queue manager can then look up the channel definition, which has all the settings that are specified for the channel.
Step 5: CHLAUTH mapping
The CHLAUTH cache is inspected again to look for mapping rules (SSLPEERMAP, USERMAP, QMGRMAP and ADDRESSMAP). The rule that matches the incoming channel most specifically will be used. If the rule has USERSRC(CHANNEL) or USERSRC(MAP) the channel continues on binding. Rules that have USERSRC(NOACCESS) means that the channel would be blocked from connecting and the network connection is ended.
Step 6: Call security exit
If the channel has a security exit (SCYEXIT) defined, this is called with the exit reason (MQCXP.ExitReason) set to MQXR_SEC_PARMS. If the client application has specified security credentials on a MQCONNX call (via MQCSP on the MQCNO) these will be passed in the exit parameters (a pointer to MQCSP will be present in the SecurityParms field of the MQCXP). The MQCSP structure has pointers to the user ID (MQCSP.CSPUserIdPtr) and password (MQCSP.CSPPasswordPtr). It is possible for the security exit to change these. Example 1 shows how a security exit would access the userId and password fields.
Step 7: Is user authorised?
The authorisation phase happens if CONNAUTH is enabled on the queue manager. To check this issue the MQSC command ‘DISPLAY QMGR CONNAUTH’. Figures 2 and 3 show the output of this command on MQ for z/OS and distributed MQ.
For example, say I don’t have a MCAUSER set on the SVRCONN channel and my client is running under ‘markw1′ on my linux machine. My application specifies user ‘fred’ in the MQCSP the channel will start running with ‘markw1′ as the active MCAUSER. After the CONNAUTH check the user ‘fred’ will be adopted and the channel run with ‘fred’ as the active MCAUSER.
Step 8: Is user allowed on this channel?
If the CONNAUTH checking is successful the CHLAUTH cache is then inspected again to check if the active MCAUSER is blocked by a BLOCKUSER rule. If the user is blocked the channel will be terminated.
Steps 9 and 10: Object authorisation checks
The client application has now connected. As with locally bound applications any objects that the application opens e.g. a queue, requires a check will be made to ensure that the active MCAUSER has the appropriate authority for that object.
Conclusion
In this article I have described what stages a channel goes through when connecting in terms of security checking. In the next article I will demonstrate how an application supplies user credentials.
Resources
The following links are provided to give more information the topics covered:
CHLAUTH
CONNAUTH
Blocking IP addresses with CHLAUTH Which type to use blog
IBM MQ supports two ways that an application can connect:
1. Local bindings: This is when the application and queue manager are on the same operating image. CHLAUTH is not relevant to this type of application connection.
2. Client bindings: This is when the application and queue manager use the network to communicate. The application and queue manager may be running on the same machine or they may be on different machines. In MQ a client connection is handled in the form of a server-connection (SVRCONN) channel. Both CONNAUTH and CHLAUTH are applicable, and it is this type of connection which is discussed.
The binding steps of a receiving end of a channel
When an application connects to a queue manager there is a lot of checking to perform to ensure that both ends of the channel understand what is supported by the other end. The receiving end does some extra checking to ensure that the client is allowed to connect. This checking involves CHLAUTH and CONNAUTH. This process may also include a security exit as this can affect the result. This channel connecting phase is also referred to as the binding phase.
In MQ version 7 SHARECNV was added to SVRCONN channels so multiple connections/conversations can share the same channel. This article does not cover what happens in terms of CHLAUTH and CONNAUTH when a second and following conversations share the same channel.
Figure 1 shows the steps that a SVRCONN channel goes through when the server end (at the queue manager) starts.
Figure 1: the steps that a SVRCONN channel goes through when starting up.
Step 1: Receive a connection request
The channel initiator or listener receives a connection request from somewhere on the network.
Step 2: Is address allowed to connect?
Before any data is read from the wire, MQ will check the partner’s IP address against the CHLAUTH rules to see if the address is in the BLOCKADDR rule. If the address is not found and so not blocked the flow proceeds to the next step.
Step 3: Read data from the channel
MQ can now read the data from the wire into a buffer and start to process the sent information.
Step 4: Look up channel definition
In the first data flow MQ sends amongst other things the name of the channel which the sending end is trying to start. The receiving queue manager can then look up the channel definition, which has all the settings that are specified for the channel.
Step 5: CHLAUTH mapping
The CHLAUTH cache is inspected again to look for mapping rules (SSLPEERMAP, USERMAP, QMGRMAP and ADDRESSMAP). The rule that matches the incoming channel most specifically will be used. If the rule has USERSRC(CHANNEL) or USERSRC(MAP) the channel continues on binding. Rules that have USERSRC(NOACCESS) means that the channel would be blocked from connecting and the network connection is ended.
Step 6: Call security exit
If the channel has a security exit (SCYEXIT) defined, this is called with the exit reason (MQCXP.ExitReason) set to MQXR_SEC_PARMS. If the client application has specified security credentials on a MQCONNX call (via MQCSP on the MQCNO) these will be passed in the exit parameters (a pointer to MQCSP will be present in the SecurityParms field of the MQCXP). The MQCSP structure has pointers to the user ID (MQCSP.CSPUserIdPtr) and password (MQCSP.CSPPasswordPtr). It is possible for the security exit to change these. Example 1 shows how a security exit would access the userId and password fields.
Example 1: accessing the user ID and password in an exit
The exit could tell MQ to close the channel by returning
MQXCC_CLOSE_CHANNEL or MQXCC_FAILED in MQCXP.ExitResponse field.
Otherwise, channel processing continues to the connection authorisation
phase.Step 7: Is user authorised?
The authorisation phase happens if CONNAUTH is enabled on the queue manager. To check this issue the MQSC command ‘DISPLAY QMGR CONNAUTH’. Figures 2 and 3 show the output of this command on MQ for z/OS and distributed MQ.
Figure 2: output of the command DISPLAY QMGR CONNAUTH from a queue manager running on z/OS
Figure 3: output of the command DISPLAY QMGR CONNAUTH from a distributed MQ queue manager
The CONNAUTH value is a name of an AUTHINFO MQ object. MQ version
8 supports two methods of authentication: using the operating system
(AUTHTYPE(IDPWOS)) or using LDAP (not available on z/OS)
(AUTHTYPE(IDPWLDAP)). This article concentrates on operation system
authentication. In a future article. I will cover using LDAP for
authentication. Figures 4 and 5 shows the shipped default object for
AUTHINFO type(IDPWOS) in MQ for z/OS and distributed MQ.
Figure 4: displaying the shipped default object for AUTHINFO type(IDPWOS) from a queue manager running on z/OS
Figure 5: displaying the shipped default object for AUTHINFO type(IDPWOS) from a distributed queue manager.
The AUTHINFO TYPE(IDPWOS) has an attribute called CHCKCLNT. If
the value is changed to REQUIRED all client applications would have to
supply a valid user ID and password. While we are looking at the
attributes involved with CONNAUTH, I must mention the adopt context
(ADOPTCTX) option. The ADOPTCTX attribute controls whether the channel
runs under MCAUSER or the user ID the application has supplied If
ADOPTCTX is YES then the channel will adopt that user to run under (the
active MCAUSER) and the object authorization will be done against this
user. This will also be used in step 8 in the CONNAUTH check.For example, say I don’t have a MCAUSER set on the SVRCONN channel and my client is running under ‘markw1′ on my linux machine. My application specifies user ‘fred’ in the MQCSP the channel will start running with ‘markw1′ as the active MCAUSER. After the CONNAUTH check the user ‘fred’ will be adopted and the channel run with ‘fred’ as the active MCAUSER.
Step 8: Is user allowed on this channel?
If the CONNAUTH checking is successful the CHLAUTH cache is then inspected again to check if the active MCAUSER is blocked by a BLOCKUSER rule. If the user is blocked the channel will be terminated.
Steps 9 and 10: Object authorisation checks
The client application has now connected. As with locally bound applications any objects that the application opens e.g. a queue, requires a check will be made to ensure that the active MCAUSER has the appropriate authority for that object.
Conclusion
In this article I have described what stages a channel goes through when connecting in terms of security checking. In the next article I will demonstrate how an application supplies user credentials.
Resources
The following links are provided to give more information the topics covered:
CHLAUTH
CONNAUTH
Blocking IP addresses with CHLAUTH Which type to use blog
Hi Karthick
ReplyDeleteAs you seem to have copied this blog from my developerworks article (
https://developer.ibm.com/messaging/2015/09/08/the-interaction-of-chlauth-and-connauth-in-ibm-mq-2/). I would appreciate if you could acknowledge this in your blog post.
Thanks
Mark Wilson
I would like to thank you for the efforts you have made in writing this article. I am sharing additional information regarding Biztalk online Training .
ReplyDelete