MQ

• Local binding
• Client binding

Local binding

With a local binding, an MQ application runs on the same machine where the MQ Server is running. In Local bindings applications use shared memory and pipes and hence we don’t need any channels to access the QMGR and its objects. As a result, channel authentication (CHLAUTH) configuration is not applicable here, but connection authentication (CONNAUTH) configuration is applicable.

Client binding

With a client binding, the communication between the MQ Client application and the QMGR uses a network connection to connect to the queue manager and to access its objects. This means that it needs a listener and a server-connection (SVRCONN) MQ channel to connect to the QMGR and its objects. Both CONNAUTH and CHLAUTH configuration is applicable here. When a client application connects there are two types of user ID that it can pass to the queue manager:

• Login user ID
• MQCSP user ID

Login userid

This is the system login user ID under which the MQ application is running. The same user ID needs to be defined on the queue manager's system as an operating system user to be used for authorization. For example, if the application is running under a user i.e. 'user1', then 'user1' must be defined on the MQ server machine.

MQCSP User ID

This user ID can be supplied by the MQ applications to the queue manager for authentication. Both a user ID and a password is supplied. Here the MQ application can optionally provide a user ID and password in the MQCSP structure in the MQCONNX call to a queue manager.

Security

MQ provides two types of user ID security to access Queue Manager and its objects:

• Connection Authentication
• Authorization

Connection Authentication

This optional authentication method allows MQ Client applications to provide a user ID and password for authentication to access the MQ Queue Manager. You can provide the user ID and password to the MQ application via the MQCSP structure.

In the MQ client application while calling MQCONNX API

You need to create an MQCSP structure to pass the user ID and password in CSPUserIdPtr and CSPPasswordPtr fields and pass this structure in the MQCNO structure's SecurityParmsPtr.

For example:

MQCSP csp = {MQCSP_DEFAULT};
csp.AuthenticationType = MQCSP_AUTH_USER_ID_AND_PWD;
csp.CSPUserIdPtr = "user2";
csp.CSPUserIdLength = strlen("user2"); /* Max: MQ_CLIENT_USER_ID_LENGTH */
csp.CSPPasswordPtr = "password";
csp.CSPPasswordLength = strlen("password");/* Max: MQ_CSP_PASSWORD_LENGTH*/
MQCNO cno = {MQCNO_DEFAULT};
cno.Version = MQCNO_VERSION_5;
cno.SecurityParmsPtr = &csp;
MQCONNX(QMName, &cno, &hConn, &CompCode, &Reason);

Using an environment variable with the sample applications: The “MQSAMP_USER_ID” environment variable is used with some IBM supplied samples,
For example, amqsputc.
$export MQSAMP_USER_ID=user2 (Unix)
C:\> set MQSAMP_USER_ID=user2 (Windows)
Note: When you run the MQ sample application, it will ask for a password to access the queue manager in stdout.

Authorization

The authorization services component provided in IBM MQ is called object authority manager (OAM). The OAM is by default automatically active for each queue manager. The OAM maintains an access control list (ACL) for each IBM MQ object it is controlling access to.
On Windows systems, both user IDs and group IDs can appear in an ACL. This means that authorities can be granted to individual users and groups. On UNIX systems only group IDs can appear in an ACL by default. However you can configure your queue manager to accept user IDs. MQ System administrator can use setmqaut to set authority. You can use control commands dspmqaut to display authority and dmpmqaut dump authority. setmqaut -m QMGR -t qmgr -p user1 +connect setmqaut -m QMGR -t queue -n localq -p user1 +get +put

Configuring CONNAUTH

Using CONNAUTH, a queue manager can be configured to use a supplied user ID and password to check whether an application has authority to access resources. By default CONNAUTH is set to SYSTEM.DEFAULT.AUTHINFO.IDPWOS in the Queue manager property. CONNAUTH(SYSTEM.DEFAULT.AUTHINFO.IDPWOS)

Here SYSTEM.DEFAULT.AUTHINFO.IDPWOS is the Authentication Information object defined in the QMGR. You can create the authentication policy using this object. Alternatively, you can create your own AUTHINFO object and update in the CONNAUTH property in the queue manager.

$runmqsc <QMGR> display
authinfo(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS)
AUTHTYPE(IDPWOS) ADOPTCTX(YES) DESCR( )
CHCKCLNT(OPTIONAL) CHCKLOCL(OPTIONAL) FAILDLAY(1) AUTHENMD(OS)
ALTDATE(2018-05-17) ALTTIME(16.26.22)

To validate the client connections, use the AUTHINFO attribute CHCKCLNT and to validate local binding connections use the attribute CHCKLOCL. The CHCKCLNT attribute has four values:

• NONE: Switch off the validation.
• OPTIONAL: It is not mandatory to provide the user ID and password but if the user ID and password is provided then it will ensure that they are a valid pair.
• REQUIRED: User ID and password are mandatory to be provided by each MQ Application.
• REQDADM: It means the privileged users must supply a valid user ID and password, but non-privileged users are treated as OPTIONAL settings.

Note: The Operating System user ID and password among MQ Application and MQ Queue Manager systems should be a valid pair.

CHLAUTH

A channel authentication record is used to secure the MQ Channel used to connect to a queue manager. Channel authentication records allow users to set rules to allow or block inbound connections to an access queue manager.

Scenarios

Let’s discuss a few scenarios which will show how an external client connects to MQ.

Note: Assume CONNAUTH is enabled in the queue manager.

Scenario 1

MQ Client application to connect using SVRCONN channel and put a message using a valid login-user as “user1", without using MQCSP.”

Here are the steps showing how a connection is validated by MQ:

• The MQ Client calls MQCONNX to connect to the queue manager. Internally the client passes the login user ID ‘user1’ to the MQ Server QMGR.
• Then the queue manager gets the group membership details for the user ‘user1’ from the OS repository and provides it to OAM.

Note: You must create a username ‘user1’ as an operating system user in the system where QM is running.

• MQ OAM checks to see whether the 'user1' is privileged and it demands a password, and since you didn't send the correct password, it fails with a 2035.
• MQ OAM checks whether ‘user1’ is authorized to connect to the queue manager and its object to perform respective operations called by the MQ application. If the specific authorization is not in OAM for ‘user1’, MQ will return 2035 to the application, else the connection will succeed.

Note: You must authorize ‘user1’ using setmqaut to connect to the queue manager and access its object.

Example: If an MQ application wants to put a message on a queue Q1 of queue manager QMGR1 in the MQ Queue Manager system, run:

setmqaut -m QMGR1 -t qmgr -p user1 +connect

setmqaut -m QMGR1 -t queue -n Q1 -p user1 +put +get

Scenario 2

Authenticate MQ Client applications to connect to the queue manager through a SVRCONN channel and put messages by sending only a valid MQCSP userid 'user2' and password using MQCSP structure

• An MQ client application is running under ‘user1’, which is the login user ID. The MQ client application passes user ID 'user2' and password 'xxxxx' in the MQCSP structure while calling the MQCONNX API.
• MQ checks the CONNAUTH(SYSTEM.DEFAULT.AUTHINFO.IPDWOS) object for the next validation.
• If CHCKCLNT is set to REQUIRED/OPTIONAL/REQDADM it checks whether “user2” is present in the OS user repository with the same password as provided by the MQ Application.
• If OS User 'user2' and its password are not a valid pair, i.e. if 'user2' is not present as OS user or the 'user2' password on the MQ Queue Manager system is not matching the supplied password, it returns MQRC 2035.
• If user ID 'user2' and its password are valid pairs, it checks the ADOPTCTX value.
• If ADOPTCTX is set to YES and CHLAUTH rules to set some other user ID. Then client side login user ID 'user1' is not checked by Queue Manager and instead ‘user2’ or the user specified by the CHLAUTH rule is checked.
• If ADOPTCTX is set to NO and CHLAUTH rule is not set to some other user ID then the queue manager will use the MQ Application login user ‘user1’ for checking.
• Once the queue manager knows what user to check it verifies that it exists in the OS user repository.
• The MQ Queue Manager checks whether the user is present in MQ OAM. If the user is part of mqm group , If not, then MQ returns 2035 to the client application, else continues to the next step.
• The MQ client application will successfully connect the MQ QMGR.

Note: If CHCKCLNT is set to NONE, it will directly connect to the QMGR without any user ID (user2) and password authentication check, however it checks whether 'user1' is authorized to connect to the queue manager.

Steps to Configure

1. ADOPTCTX is set to YES and CHLAUTH rules to set some other user ID, then the MQ application login user ID 'user1' is not validated by the queue manager.
2. If ADOPTCTX is set to NO and CHLAUTH rules to set user ID 'user1' then you need to make sure under the login user the MQ client is running must be present in MQ server as an OS user. For example if ‘user1’ is the login user, set MQ authority in MQ server side using the following commands:
   setmqaut -m QMGR1 -t qmgr -p user1 +connect
setmqaut -m QMGR1 -t queue -n Q1 -p user1 +put
3. In the MQ Queue Manager system create OS User 'user2'.
4. In the MQ Client application create MQCSP structure specifying user as user2 and password.
5. In the MQ CONNAUTH(SYSTEM.DEFAULT.AUTHINFO.IPDWOS) object, specify CHCKCLNT(REQUIRED) to mandate user ID and password authentication. If you want to keep MQCSP authentication as optional, set them as OPTIONAL or REQDADM.
6. Create SVRCONN channel APP1.SVRCONN in QMGR1.
7. If you don’t want to use 'user2' to run SVRCONN channel APP1.SVRCONN, change ADOPTCTX(NO).
8. Put message using amqsputc Q1 QMGR1. In this case the APP1.SVRCONN channel will be running as 'user1'.
9. If you want to use 'user2' to run server conn channel, and adopt 'user2' to do further authorization, change ADOPTCTX(YES). The SVR channel will run as 'user2'.
10. If ADOPTCTX is set to YES, you must add 'user2' to the access the OAM control list of QMGR1.
    setmqaut -m QMGR1 -t qmgr -p user2 +connect
setmqaut -m QMGR1 -t queue -n Q1 -p user2 +put
11. Export MQSERVER=APP1.SVRCONN/tcp/MQServer_IP(PORT)
12. You should be able to successfully put the message into Q1 using the MQ Client application, using this command:
    amqsputc Q1 QMGR1

References

• Object authority manager (OAM)
• MQCSP – Security parameters
• Connection authentication with the Java client
• The interaction of CHLAUTH and CONNAUTH in IBM MQ
• Connection authentication: Application changes