Currently, IBM MQ supports SSL certificate-based authentication for client connections. While this method provides robust security, it introduces significant operational overhead for application teams, who must manage, distribute, and frequently renew certificates. As organizations modernize their application architectures and migrate workloads to cloud platforms such as AWS, there is a growing preference for token-based authentication mechanisms, specifically IDA IDAnyWhere (IDA).
Token-based authentication offers several advantages over traditional certificate-based approaches, including simplified credential management, improved scalability, and enhanced support for dynamic, cloud-native environments. Many modern applications, especially those running on cloud platforms, are designed to leverage IDA for authentication rather than SSL certificates. This shift is driven by the need for agility, automation, and reduced administrative burden.
A substantial number of applications that connect directly to mainframe systems are seeking to use IBM MQ on platforms where IDA is supported. However, the lack of token-based authentication support in IBM MQ is a significant barrier to adoption and modernization. Enabling IDA for MQ client/server connections would align IBM MQ with current industry best practices and support ongoing modernization initiatives across the enterprise.
Use Case:
A financial institution is migrating several mission-critical applications from on-premises infrastructure to AWS. These applications require secure, authenticated connections to IBM MQ running on z/OS and distributed platforms. The institution’s security architecture mandates the use of IDA IDAnyWhere for authentication, as it integrates seamlessly with their identity provider and supports dynamic, cloud-native workloads.
Currently, the application teams must manage SSL certificates for each client connection to MQ, which is time-consuming and error-prone. Certificate renewal cycles often lead to service disruptions and increased operational risk. By enabling token-based authentication (IDA), the institution can:
- Eliminate the need for certificate management and renewal.
- Automate authentication workflows using their existing identity provider.
- Improve developer productivity and reduce operational overhead.
- Accelerate cloud adoption and support hybrid/multi-cloud architectures.
- Enhance security posture by leveraging modern, standards-based authentication.
Request:
We request IBM to enhance IBM MQ to support token-based authentication using IDA IDAnyWhere for client/server connections. This feature should be available across all supported platforms, including z/OS and distributed environments. The implementation should allow applications to authenticate using IDA tokens, in addition to (or as an alternative to) SSL certificates.
This enhancement will:
- Align IBM MQ with modern authentication standards.
- Support enterprise modernization and cloud migration initiatives.
- Reduce operational complexity for application teams.
- Enable broader adoption of IBM MQ in cloud and hybrid environments.
We believe this feature will deliver significant value to IBM MQ customers and help maintain IBM MQ’s position as a leading enterprise messaging solution.
I see the 'Needs more information' flag is set, but I do not know what additional information is being requested. I will do my best to add some context:
Right now, at least for MQ on z/OS (mainframe), the only semi-modern authentication method available is via leveraging SSL certificates. This is an outdated, cumbersome, and inflexible way to authenticate connections into MQ on the mainframe, especially when compared with the token-based options out there.
Specifically, adding support for OIDC to authenticate and authorize an application to access MQ would represent a huge step forward for our application partners in terms of security and convenience. I believe SAML 2.0 is also an acceptable option.
OIDC/OAuth support within MQ on the mainframe for human authentication would also be welcome, but we would consider it of far lower priority than the app2app token support described above.