WebSphere MQ

- Connection Authentication (CONNAUTH).

© 2019
Connection Authentication
Connection Authentication.
 An application can provide a user ID and password.

 The application can be either a client, or it can use local bindings.

 A queue manager can be configured to act on a supplied user ID and

password.

 A repository can be used to determine whether a user ID and password

combination is valid.

3
Connection Authentication. In the diagram, two applications are
making connections with a queue manager,
-
one application as a client and one using
local bindings.

4
Connection Authentication.
 Applications might use a variety of APIs to connect to the queue
manager, but all have the ability to provide a user ID and a password.

 The user ID that the application is running under, User1 and User3 in
the diagram, which is the usual operating system user ID presented to
IBM® MQ, might be different from the user ID provided by the
application.

5
Connection Authentication.
 The queue manager receives configuration commands (in the diagram,
MQ Explorer is being used) and manages the opening of resources and
checks the authority to access those resources.

 There are many different resources in IBM MQ that an application

might require authority to access.

 The diagram illustrates opening a queue for output, but the same
principles apply to other resources as well.

 A queue manager can be configured to use a supplied user ID and

password to check whether a user has authority to access resources.

6
Turning on connection authentication on a queue manager.

 On a queue manager object, the CONNAUTH attribute can be set to

the name of an authentication information (AUTHINFO) object.

 This object (AUTHTYPE attribute) can be one of two types

 IDPWOS
 Indicates that the queue manager uses the local operating system
to authenticate the user ID and password.

 IDPWLDAP
 Indicates that the queue manager uses an LDAP server to
authenticate the user ID and password.

7
Turning on connection authentication on a queue manager.

 To check local connections, use the AUTHINFO attribute

CHCKLOCL (check local connections).

 To check client connections, use the AUTHINFO attribute

CHCKCLNT (check client connections).

 The configuration must be refreshed before the queue manager

recognizes the changes.

ALTER QMGR CONNAUTH(USE.PW)DEFINE

AUTHINFO(USE.PW) +AUTHTYPE(IDPWOS)
+FAILDLAY(10) +CHCKLOCL(OPTIONAL)
+CHCKCLNT(REQUIRED)REFRESH SECURITY
TYPE(CONNAUTH)

8
Turning on connection authentication on a queue manager.

 Where USE.PW in the CONNAUTH is a string that matches the

AUTHINFO definition.

 Both CHCKLOCL and CHCKCLNT - ( from the chat above ) have the
same set of possible values that allow the strictness of checking to be
varied:

NONE
Switches off checking.
OPTIONAL

Ensures that if a user ID and password are provided by an

application, they are a valid pair, but that it is not mandatory to provide
them. This option might be useful during migration, for example.

9
Turning on connection authentication on a queue manager.
+
OPTIONAL is the minimum value you can set, in order to use more
stringent CHLAUTH rules.

- If you select NONE and the client connection matches a CHLAUTH record
with CHCKCLNT REQUIRED (or REQDADM on platforms other than z/OS®),
the connection fails. You receive message AMQ9793 on platforms other
than z/OS, and message CSQX793E on z/OS.

REQUIRED

Requires that all applications provide a valid user ID and

password. See also the following note. z/OS systems.)

REQDADM

Privileged users must supply a valid user ID and password, but

non-privileged users are treated as with the OPTIONAL setting. See also
the following note. (This setting is not allowed on z/OS systems.)
10
Turning on connection authentication on a queue manager.

 Setting CHCKLOCL to REQUIRED or REQDADM means that in order

to locally administer the queue manager by using runmqsc, the user
must specify the -u UserId parameter on the runmqsc command
line.

 With that set, runmqsc prompts for the user's password at the
console.

 Otherwise an error; (error AMQ8135: Not authorized) will be

shown.

11
Turning on connection authentication on a queue manager.

 Similarly, a user running MQ Explorer on the local system will see

error AMQ4036 when attempting to connect to the queue manager.

 To specify a user name and password, right-click the local queue

manager object and select
– Connection Details > Properties... from the menu.
– In the Userid section, enter the user name and password to be
used, then click OK.

 Similar considerations apply to remote connections with CHCKCLNT.

 CONNAUTH is blank for migrated queue managers but set to

SYSTEM.DEFAULT.AUTHINFO.IDPWOS for new queue managers.

- The preceding AUTHINFO definition has CHCKCLNT set to REQDADM

12
by default.
Configuration granularity.

 In addition to CHCKLOCL and CHCKCLNT that are used to turn on

user ID and password checking, there are enhancements to the
CHLAUTH rules so that more specific configuration can be made using
CHCKCLNT.

 You can set the overall CHCKCLNT value to OPTIONAL, for example,
and then upgrade it to be more stringent for certain channels by
setting CHCKCLNT to REQUIRED or REQDADM on the CHLAUTH
rule.

 By default, CHLAUTH rules will run with CHCKCLNT(ASQMGR) so

this granularity does not have to be used.

13
Configuration granularity.
 . For example:

DEFINE AUTHINFO(USE.PW) AUTHTYPE(xxxxxx)

+CHCKCLNT(OPTIONAL)SET CHLAUTH('*')
TYPE(ADDRESSMAP) +ADDRESS('*') USERSRC(CHANNEL)
+CHCKCLNT(REQUIRED)SET CHLAUTH('*')
TYPE(SSLPEERMAP) +SSLPEER('CN=*')
USERSRC(CHANNEL)

14