Overview of LDAP authorization

An overview of how you use LDAP authorization to remove the need for a local user ID.

Commands that handle authorization configuration, such as setmqaut and DISPLAY AUTHREC, can now process Distinguished Names. Previously, users were authenticated by comparing their credentials with the maximum available characters that exist for users and groups on the local operating system.

Attention: If you have run the DEFINE AUTHINFO command, you must restart the queue manager. If you do not restart the queue manager, the setmqaut command does not return the correct result.

If a user provides a user ID, rather than a Distinguished Name, the user ID is processed. For example, when there is an incoming message on a channel with PUTAUT(CTX), the characters in the user ID are mapped to an LDAP Distinguished Name, and the appropriate authorization checks are made.

Other commands such as DISPLAY CONN, continue to work with and show the actual value for the user ID, even though that user ID might not actually exist on the local OS.

When LDAP authorization is in place, the queue manager always uses the user model of security on UNIX platforms, regardless of the SecurityPolicy attribute in the qm.ini file. So, setting permissions for an individual user affects only that user, and not anyone else who belongs to any of that user's groups.

As with the OS model, a user still has the combined authority that has been assigned to both the individual and to all of the groups (if any) to which the user belongs.

For example, assume that the following records have been defined in an LDAP repository.

In the inetOrgPerson class:


dn="cn=JohnDoe, ou=users, o=yourcompany, c=yourcountry"
        email=JohnDoe1@yourcompany.com [longer than 12 characters]
        shortu=jodoe
        Phone=1234567

In the groupOfNames class:


dn="cn=Application Group A, ou=groups, o=yourcompany, c=yourcountry"
        longname=ApplicationGroupA [longer than 12 characters]
        members="cn=JaneDoe, ou=users, o=yourcompany, c=yourcountry",
                "cn=JohnDoe, ou=users, o=yourcompany, c=yourcountry"

For authentication purposes, a queue manager using this LDAP server must have been defined so that its CONNAUTH value points at an AUTHINFO object of type IDPWLDAP, and whose relevant name-resolution attributes are probably set as follows:


USRFIELD(email) SHORTUSR(shortu) 
BASEDNU(ou=users,o=yourcompany,c=yourcountry) CLASSUSR(inetOrgPerson)

Given this configuration for authentication, an application can fill in the CSPUserID field, used within the MQCNO call, with either of the following sets of values:


" cn=JohnDoe ", " JohnDoe1@yourcompany.com ", " email=JohnDoe1@yourcompany.com "


" cn=JohnDoe, ou=users, o=ibm, c=uk ", " shortu=jodoe "

In either case, the system can use the supplied values to authenticate the OS context of " jodoe".

Enabling LDAP authorization on the supported platforms

LDAP authorization is available on the following platforms:

UNIX
IBM® i

Important:

To enable configuration of the new authorization model, you must firstly change the command level of the queue manager to be higher than the IBM MQ Version 8.0.0.0 general availability level of 800.

You have to do this explicitly. The change is not done automatically by installation of the fix pack. For example:


strmqm -e CMDLEVEL=802 <qmname>
strmqm <qmname>

If you set CMDLEVEL to 802, you can rollback the fix pack, provided that you have not used the new function.

The queue manager command level controls whether or not configuration changes can be made that affect authorization. After this change you can see and modify the new attributes on the AUTHINFO object.

If you attempt to access the new AUTHINFO attributes from an upgraded code level, without also updating the command level, you receive an error message about needing to change the command level.

Note that the command level has no direct relationship to the Version, Release, Modification, Fix pack level.