Connection authentication: User repositories

For each of your queue managers, you can choose different types of authentication information object for authenticating user IDs and passwords.

A diagrammatic representation of... — Figure 1. Types of authentication information objects


DEFINE AUTHINFO(USE.OS) AUTHTYPE(IDPWOS)
DEFINE AUTHINFO(USE.LDAP) +
AUTHTYPE(IDPWLDAP) +
CONNAME('ldap1(389),ldap2(389)') +
LDAPUSER('CN=QMGR1') +
LDAPPWD('passw0rd') SECCOMM(YES)

There are two types of authentication information object, as represented in the diagram:

IDPWOS is used to indicate that the queue manager uses the local operating system to authentication the user ID and password. If you choose to use the local operating system, you only need to set the common attributes, as described in the preceding topics.
IDPWLDAP is used to indicate that the queue manager uses an LDAP server to authenticate the user ID and password. If you choose to use an LDAP server, more information is provided below.

Only one type of authentication information object can be chosen for each queue manager to use, by naming the appropriate object in the queue manager's CONNAUTH attribute.

Using an LDAP server for authentication.

Set the CONNAME field to the address of the LDAP server for the queue manager. You can provide additional addresses for the LDAP server in a comma-separated list, which can help with redundancy if the LDAP server does not provide this facility itself.

Set the required LDAP server ID and password in the LDAPUSER and LDAPPWD fields so that the queue manager can access the LDAP server and look up information about user records.

Secure connection to an LDAP Server

Unlike channels, there is no SSLCIPH parameter to turn on the use of SSL/TLS for communication with the LDAP server. In this case IBM® MQ is acting as a client to the LDAP server so much of the configuration is done at the LDAP server. Some existing parameters in IBM MQ are used to configure how that connection works.

Set the SECCOMM field to control whether connectivity to the LDAP server uses SSL/TLS.

In addition to this attribute, the queue manager attributes SSLFIPS and SUITEB restrict the set of cipher specs that are chosen. The certificate that is used to identify the queue manager to the LDAP server is the queue manager certificate, either ibmwebspheremq <qmgr-name> or the value of the CERTLABL attribute. See Digital certificate labels for details.

LDAP User Repository

When using an LDAP user repository there is some more configuration to be done on the queue manager other than just to tell the queue manager where to find the LDAP server.

User IDs defined in an LDAP server have a hierarchical structure that uniquely identifies them. An application can therefore connect to the queue manager and present its user ID as the fully qualified hierarchical user ID.

However, to simplify the information that an application has to provide, it is possible to configure the queue manager to assume that the first part of the hierarchy is common to all IDs, and to automatically add this before the shortened ID provide by the application. The queue manager can then present a complete ID to the LDAP server.

Set BASEDNU to the initial point that the LDAP search looks for the ID in the LDAP hierarchy. When you set BASEDNU, you must ensure that only one result is returned when you search for the ID in the LDAP hierarchy.

A diagrammatic representation of an LDAP hierarchy. — Figure 2. An example LDAP hierarchy

For example, in Figure 2 BASEDNU can be set to "ou=users,o=ibm,c=UK" or ",o=ibm,c=UK". However, because a distinguished name that contains "cn=useradm" exists in both the "o=ibm" branch and the "o=Company" branch, BASEDNU cannot be set to "c=UK". For performance and security reasons, use the highest point in your LDAP hierarchy that from which you can reference all of the userids that you need. In this example, that is "ou=users,o=ibm,c=UK".

Your application might submit to the queue manager the user ID without providing the LDAP attribute name, CN= for example. If you set USRFIELD to the LDAP attribute name, this value is added as a prefix to the user ID that comes from the application. This might be a useful migratory aid when moving from operating system user IDs to LDAP user IDs, as the application can then present the same string in both cases and you can avoid making changes to the application.

The complete user ID presented to the LDAP server therefore looks like this:


<USRFIELD> = <ID_from_application> <BASEDNU>