Modernising Identity in IBM MQ: Long User IDs in MQ 9.4.3 CD


As long-time IBM MQ users know, identity is central to how MQ operates. Whether it's authenticating a connection, determining access rights, or tagging a message with its sender, user IDs are everywhere in MQ.

Traditionally, MQ has limited user identities to just 12 characters - a constraint born from historical platform limitations. But in 2025, the landscape looks very different. With the rise of external authentication systems like LDAP and token-based mechanisms, identities are no longer bound by OS-level constraints. Instead, they often take the shape of email addresses or more complex identifiers.

To keep pace with modern security practices and enterprise requirements, the MQ 9.4.3 CD release introduces longer user ID support, marking a significant evolution in how identities are handled in IBM MQ.

Raising the Limit: 1024-character User IDs

In MQ 9.4.3 CD, the maximum length for user IDs has been extended from 12 characters to 1024 characters in supported contexts. This allows for more descriptive identities - such as full email addresses or federated login strings - and brings MQ in line with modern authentication approaches.

Work has also been done to expand the range of allowable characters in user IDs, accommodating diverse identity formats from various authentication providers.

Platform Support and Enabling the Feature

The long user identity support is initially available on Unix platforms only - AIX, Linux (all supported architectures), and the IBM MQ Appliance
.

This capability is opt-in and must be explicitly enabled on a per queue manager basis via the AllowLongUID setting in the IBM MQ qm.ini configuration file. This design helps protect legacy applications and environments that might not yet be ready to securely handle longer identities.

The good news is: for most messaging applications, no code changes will be required. Application interfaces like MQCSP will continue to work as expected, even with the longer user identities. However, there is an important detail to keep in mind - longer identities must be explicitly provided by the application. This can be done in several ways, for example via the JMS connection factory, a valid JWT token, or using an MQCSP structure in a CONNX call.


Its important to mention that if your application relies on the automatically asserted operating system process user, the old 12-character limit still applies.

Let's Give It a Try

Here’s a quick demo showcasing how to use long user IDs in IBM MQ 9.4.3 CD. In this example, we’ll begin by creating long user IDs and their associated groups. Next, we’ll configure the queue manager to support long user ID functionality. Once the setup is complete, we’ll send a message to a local queue using one of the newly created long user IDs. To wrap up, we’ll inspect the message.


1. Begin by creating a queue manager. To enable long userid support, update the Service stanza in the qm.ini file by adding a new AllowLongUID=Y entry.
   
   

   Service:
        Name=...
        EntryPoints=...
        AllowLongUID=Y

2. Start the queue manager. The AllowLongUID=Y entry is now picked up, and the queue manager is enabled for long userid support. Define a local queue that we will later use to put a message.
   
   
3. Now let’s define a long group and a long user for us to use to put a message to the queue. On Unix, we can do this simply as:
   
   

   sudo groupadd ThisIsALongUserGroup
   sudo useradd  -m -N -g ThisIsALongUserGroup ThisIsALongUserId
   passwd ThisisAlongUserId
   

4. With the group and user created, we need to give them the necessary permissions. The setmqaut has been updated to accept long userid’s if the queue manager is configured to support them (otherwise, you will receive a helpful error message). Set the necessary permissions for our new user for the queue manager and for the queue.
   
   

   setmqaut -m QM1 -t qmgr -p ThisIsALongUserId +all
   setmqaut -m QM1 -t queue -n Q1 -p ThisIsALongUserId +all

   
   If you prefer to use RUNMQSC rather than setmqaut, the equivalent of the above would be:
   
   

   SET AUTHREC OBJTYPE(QMGR)   PRINCIPAL('ThisIsALongUserId’) AUTHADD(ALL)
   SET AUTHREC OBJTYPE(QUEUE) PROFILE(Q1)  PRINCIPAL('ThisIsALongUserId’ ) AUTHADD(ALL)

   
   
   
5. With the permissions correctly set, we can now try putting a message to the queue as our long user. Let’s do this via the amqsput sample; don’t forget to set the MQSAMP_USER_ID environment variable to your long user, so the long user id is used for the connection authentication. 
   
   

   export MQSAMP_USER_ID = 'ThisIsALongUserId'
   amsqput Q1 QM1

   
   
   
6. Once we’ve put a message on the queue, let’s inspect it via the amqsbcg command.
   
   

   amqsbcg Q1 QM1

   
   

   

Notice that although the message has been placed with authorisation checks based on the long userid, in the MQMD UserIdentifier field we see that the long userid has been truncated to 12 characters (11 chars and a +).

This leads us to the current limitations in this release…

Limitations and Considerations

There are a few caveats to be aware of:

• The MQMD UserIdentifier field is not expanded. It continues to reflect a truncated version of the user ID if a long identity is in use.
• This means long-form identities are not suitable for use cases that rely on the MQMD’s identity context!

To reiterate, if you have such a use case / you're building such tools / have workflows that inspect the MQMD.UserIdentifier, be cautious about assuming the identity will be complete when long IDs are in use.

So What's Next?

This release is just the start. There’s a broad roadmap for extending long identity support across more contexts and platforms in future MQ versions. IBM is actively seeking feedback to help prioritise where to go next.


We’re particularly interested in hearing about:

1. Your key identity-related use cases
2. Applications that depend on MQMD identity context
3. Any blockers to enabling long IDs in your environment


You can reach out via the Early Access program, submit Ideas through the IBM Ideas Portal, or if you're not sure where to start - just drop me (vasily.shcherbinin@ibm.com) or my colleague Anthony (abeards@uk.ibm.com) an email.