New for 9.3.4!
What is this all about and why should I be interested?
If you’ve taken a look at what’s new in the recently announced IBM MQ CD release 9.3.4 you may have noticed it includes support for a new security feature – authentication using JSON Web Tokens
Token Based Authentication - commonly implemented using JSON Web Tokens, or JWT for short - is a modern approach to authenticating users and applications – often used in Web application and REST frameworks, but increasingly common in other environments. Instead of supplying credentials directly to a service (for example MQ), a client authenticates with an Authentication Server (more on these later) and retrieves a Token proving who they are. This token can then be provided to the service being accessed to establish identity and determine authorisation to access resources.
This might sound complicated on the surface, but centralising authentication in this way has several potential advantages over other approaches – among them
- 'Real’ credentials never need to be shared with other servers (only the authentication server ever sees e.g. usernames and passwords)
- Authentication mechanisms can be swapped out without affecting individual servers. For example you could introduce two factor authentication in future without MQ being aware
- Tokens can be, and usually are, short lived – enabling access to the service for the minimum amount of time needed, probably minutes (when the client needs to connect again, it simply fetches a new token)
- Importantly, the ‘end service’ does not need to contact the authentication server ‘live’ at any point during the process – token validation is performed using pre exchanged keys/certificates. This minimises points of failure/performance bottlenecks.
For these reasons (and likely others) Token Based Authentication is an increasingly common requirement in many enterprises - so if you hadn’t come across it before now, it was probably going to pop up soon!
What does that mean for MQ – and how do I use this?
IBM MQ 9.3.4 includes initial support for JWT authentication – as with any new feature it is likely that this will evolve and expand over subsequent releases. In a nutshell, to use JWT authentication from an application right now, you will need to:
Initially, only the ‘native’ MQI (essentially, the C interface and those wrappers built directly on top of it) have been updated to expose these concepts. Only client applications can authenticate using a token, and the queue manager must be running on a ‘Unix like’ platform (AIX or Linux on any supported architecture). The client application can be on any platform running the updated CD release.
But that sounds complicated!
I don’t want to do all that work/change my apps! And anyway, they don’t use the MQI in the first place!
Don’t panic! We understand that making application changes is time consuming and difficult, so we wanted to make sure that you can get going with JWT without updating every client application. For exactly this reason, from the outset the new token structures can be created, accessed, and modified using channel security exits (almost certainly client side). This includes exits called from applications using the IBM MQ Classes for JMS/Jakarta Messaging, whether those are platform native exits invoked via the JNI layer, or JMS specific exits written in Java (see 'setToken').
Furthermore we have provided example exits on GitHub which demonstrate how you might invoke a REST endpoint to retrieve a token and inject it during the MQ connect, without the application ever being aware. You can take these and use them right away, or more realistically tailor them to your needs (for example your particular authentication server might provide a slightly different type of token endpoint, or use a different type of credentials).
What’s all this about Authentication Servers? What is an Authentication server anyway? How do I know what Authentication server I should be using?
As JWT is a well established standard for authentication tokens, there are many services out there which implement this approach. It is quite likely your organisation already has a ‘favoured’ service which can now be integrated with MQ applications if desired. You may already know this service as an LDAP user repository, or single sign on service used by in-house web applications, so if you aren’t sure where to start then contacting teams that manage such services might be a good approach.
A popular open source product which provides these services is KeyCloak which we used as a target when testing the samples above – if you are looking for an authentication service to ‘play with’ it is very simple to stand up a sandbox developer instance of this and get going right away.
I’ve heard of OIDC and OAUTH – is this the same thing?
Not exactly.
The JWT specification defines the format of a token but not how it is obtained or used. OAuth and OIDC define protocols (communication flows between the various different clients and servers) for fetching Tokens, exchanging and renewing them in various ways, and presenting them to services. (It’s a simplification but roughly speaking, OAUTH builds on JWT to provide basic protocols to access a resource, OIDC builds in turn on OAUTH to provide identity, authentication, and authorisation flows).
As I mentioned above, many of these standards originate in the realm of Web Applications and therefore make certain assumptions about the ‘shape’ of a service and user (for example, there is usually a human ‘end user’ sat at a browser, and a Web Server sitting between them and any ‘back end’ services, with everything flowing from place to place over HTTP). Therefore, not all parts of these protocols make sense in the context of managing access to MQ.
That said, you are likely to find yourself using some parts of the OIDC specification as soon as you start integrating applications with MQ (for example the endpoint you retrieve a token from is likely to be an OIDC compliant URL), and we think other pieces of these specifications could make sense to directly integrate with MQ over time. Please let us know if there are particular aspects that you would like to see ‘natively’ supported by MQ.
What’s next?
We already have a number of ideas for ways we would like to simplify use of this feature both for application developers and MQ administrators, so watch this space for further news. And of course, we’re eager to hear from you through any of the usual channels as you get going with this about any problems you hit or enhancements you’d like to see in future. Hopefully this has given you a good place to start – please let us know how you get on!