[V8.0.0.2 Feb 2015]

Other considerations when using LDAP authorization

A brief description of changes to the Message Queue Interface (MQI) and other MQSC and PCF commands that you need to be aware of when using LDAP authorization from IBM® MQ 8.0.0, Fix Pack 2.

ADOPTCTX

There is no requirement for applications to provide authentication information, or for the ADOPTCTX attribute to be set to YES.

If an application does not explicitly authenticate, or if ADOPTCTX is set to NO for the active CONNAUTH object, the identity context associated with the application is taken from the operating system user ID.

When authorizations need to be applied, that context is mapped to an LDAP identity using the same rules as for the setmqaut commands.

Input parameters to MQI calls

MQOPEN, MQPUT1, and MQSUB have structures that allow an alternative user ID to be specified.

If those fields are used, the 12-character user ID is mapped to a DN using the same rules as on the setmqaut, dmpmqaut, and dspmqaut commands.

MQPUT and MQPUT1 also allow suitably authorized programs to set the MQMD UserIdentifier field. The value of this field is not policed during the PUT process, and can be set to any value.

As usual, however, the UserIdentifier value can be used for authorization at later stages of the message processing, for example when PUTAUT(CTX) is defined on a receiving channel.

At that point, the identifier will be checked for authorization using the configuration of that receiving queue manager - which can be LDAP or OS-based.

Output parameters to MQI calls

Wherever a user ID is provided to a program in an MQI structure, it is the 12-character short name version associated with the connection.

For example, the MQAXC.UserId value for API Exits is the short name returned from the LDAP mapping.

Other administrative MQSC and PCF commands

Commands that show user information in object status such as DISPLAY CONN USERID return the 12-character short name associated with the context. The full DN is not shown.

Commands that allow assertion of identities, such as the CHLAUTH mapping rules or MCAUSER values for channels, can take values up to the maximum length defined for those attributes (currently 64 characters).

There is no change to the syntax. When authorization is required for that identity, it is internally mapped to a DN using the same rules as for the setmqaut, dmpmqaut, and dspmqaut commands.

This means that the MCAUSER value on a channel definition might not display as the same string as DISPLAY CHSTATUS but they do refer to the same identity.

For example:

DEFINE CHL(SV1) CHLTYPE(SVRCONN) MCAUSER('cn=JohnDoe')
DEFINE CHL(SV2) CHLTYPE(SVRCONN) MCAUSER('jodoe')
DEFINE CHL(SV3) CHLTYPE(SVRCONN) MCAUSER('JohnDoe1@yourcompany.com')
Then DISPLAY CHSTATUS(*) ALL shows the SHORTUSR value, MCAUSER(jodoe) for all connections.