User identities in IBM MQ

What is a user identity? (also known as a user name, user, or user ID)

All operations in IBM MQ are performed under the context of a specific user identity. This identity is used in several important ways:

• It can be authenticated when connecting to the queue manager, for example by checking an operating system (OS) password, or calling out to an external repository. This check confirms that the connection is permitted to act as this user, and (closely related) that this user has authority to connect to the queue manager.
• It is used to check authority to perform actions. For example, is this user permitted to open a particular queue or topic and put messages? Authorities can be defined either against a specific user, or a 'group' that includes the user, depending on the type of authentication repository being used and the queue manager configuration.
• It is recorded in messages so that recipients can tell who sent a message, and potentially perform subsequent actions based on their authorizations.
• It is also recorded in events, error log messages and other such records that might form an important part of the audit trail, both for configuration changes and application messaging activity on the system.

These core principles apply for all connections to IBM MQ, whether on behalf of a messaging application or an IBM MQ administration tool such as runmqsc. However there are some specific restrictions and additional considerations to be aware of, depending on the application type and the API that is used to connect to the queue manager.

How does the source of the user ID affect the length of the ID?

When messages are sent on behalf of a connected application, the user identity is stored in the message in the MQMD. For compatibility with older application code, this field is limited to 12 characters. See User identity length limitations (MQMD and downstream authorization).

Authentication and authorization: Operating system (application process) user IDs

Traditionally, and by default, the user identity for an IBM MQ connection is that of the operating system process creating the connection. This is true both for locally bound applications running on the same host as the queue manager, and for remote (client) applications. However, the asserted identity flowed from an IBM MQ client application is vulnerable to malicious clients or manipulation on the network, so additional client authentication checks should usually be employed to ensure that the connecting application has the right to adopt this identity on the server.

Authentication and authorization: MQCSP supplied credentials

Rather than inheriting the default identity from the operating system or process, an application can explicitly supply a user ID and password or authentication token to IBM MQ at connection time using the MQCSP structure. The credentials supplied can be authenticated by the operating system on which the queue manager is running (see the IDPWOS information in Connection authentication: Configuration), by an LDAP repository (see the IDPWLDAP information in Connection authentication: User repositories), by cryptographic token verification (see Working with authentication tokens, or even by executing custom exit code.

If you use the MQCSP structure to pass credentials, the maximum length of a user ID is 1024 characters, although it is not always possible to adopt this full identity. See User identity length limitations (MQMD and downstream authorization).

In IBM MQ programming interfaces that use a connect(username, password) style, including the JMS and .NET libraries, the MQCSP is created on behalf of an application when these appropriate native connection methods are invoked.

User identity length limitations (MQMD and downstream authorization)

Usually, authority records must be defined against this short adopted user or a group to which it belongs (see Group versus user authority management). For example, if incoming client user MyApplicationUser has been mapped to a channel MCAUSER shortid, you issue setmqaut or SET AUTHREC to define authorities for shortid to access the queues and other system objects to which it needs access. An exception to this is in IDPWLDAP environments, in which authorities may be defined against either the long or short forms if these are unique to the user record in question. See Setting authorizations.

Whichever authentication mechanism is in use, a shortname is always required for inclusion in the MQMD, and if used for subsequent authority checks (on this or another queue manager) this shortname still needs to be resolved or authorized appropriately. It is also usually the short form of the user name that is visible in error log records and event messages that report activity on the queue manager.

From IBM MQ 9.4.3, a longer identity (up to 1024 characters) can be adopted for connections that are authenticated through IDPWOS password or token authentication, and the authority records for those users can be defined using the full longer identity. Note however that only a truncated form (11 characters suffixed with a '+' character) is stored in the MQMD for messages sent from this connection, and reported in any events and error log messages that are restricted to 12 character output. While suitable for simple messaging applications, longer identities are therefore not appropriate for applications that perform subsequent actions under the context of the MQMD user; for example administrative tooling that relies on PCF command authorization, or queue manager to queue manager channels that use PUTAUT(CTX). To prevent accidental use of long identities without consideration, this capability must be enabled in the queue manager qm.ini file. See AllowLongUID.

Group versus user authority management

On AIX and Linux systems, the default is that user IDs are used to authenticate and groups are used to authorize. However, you can configure these systems to authorize against user IDs. For more information, see OAM user-based permissions on AIX and Linux. On Windows systems, user IDs can be used for both authentication and authorization, and groups for authorization.

If you create service accounts, without paying attention to groups, and authorize all the user IDs differently, every user can access the information of every other user.

Reserved characters and identities

The user ID UNKNOWN and group NOBODY have special meanings to IBM MQ. Creating a user ID in the operating system called UNKNOWN or a group called NOBODY could have unintended results.

An IBM MQ for Windows server does not support the connection of an IBM MQ MQI client if the client is running under a user ID that contains the @ character; for example abc@d. The return code to the MQCONN call at the client is MQRC_NOT_AUTHORIZED. However, you can specify the user ID using two @ characters, for example abc@@d. Using the id@domain format is the preferred practice, to ensure that the user ID is resolved in the correct domain consistently; for example abc@@d@domain.

Stricter validation of IBM MQ User ID characters

From IBM MQ 9.4.3, IBM MQ performs more careful validation of the strings representing user identities when connecting to a queue manager. This is to help ensure that these strings do not cause problems when messages are transmitted between different systems that support different character sets.

If you are using operating system (IDPWOS) or LDAP (IDPWLDAP) authentication, existing common practices, together with platform and user repository validation, are usually enough to meet these more stringent requirements. So you are unlikely to encounter problems in existing deployments.

If the IBM-provided Object Authority Manager detects any authority records referring to unsuitable user identities at startup, a warning message AMQ5793 is reported once for each such record found.