“… but it works from MQ Explorer”
It seems that the introduction of User id and Password checking in IBM MQ V8 is prompting many people to start looking at using User id and Password checking, even though they are not yet at V8. I’m sure this is a positive trend – unless of course it’s because people are throwing out SSL/TLS in favour of passwords – but that’s a story for a different time.
We’ve seen lots of discussions on this topic recently, with one common statement, “… but it works from MQ Explorer”.
‘C’ Applications vs Java Applications in IBM MQ
In the releases prior to IBM MQ V8 there are patchy mechanisms for using User id and Password checking, which can give you the same support as you get built-in at IBM MQ V8; but you need to be careful because they don’t all work the same way.
|Used by||Delivery Protocol||QMgr-side Checks||Examples|
|Java Client||Historic FAP fields||Security Exit pulling fields from the MQCD structure, RemoteUserIdentifier and RemotePassword||CSQ4BCX3 Sample security exit shipped on z/OS
The MQAUSX Security Exit
|‘C’ Client||MQCSP across client channel||Security Exit pulling fields from the MQCSP structure||The MQAUSX Security Exit|
|Local Apps (dist)||MQCSP across IPC||Custom Authorization Service plug-in||I’m not sure any vendor made one of these|
|Local Apps (z/OS)||Nothing||Nothing||Nothing|
One issue with the above that catches a lot of people out, is that they get a solution that works for the Java Client, for example the MQ Explorer, and then they find it doesn’t work with any ‘C’ Client applications, for example MO71. The sample exit, CSQ4BCX3 that is shipped with WebSphere MQ for z/OS is one such example.
User ID and password checking with IBM MQ V8
Lots has been written about Connection Authentication in other blog posts so I won’t reiterate all that here. You can read more by following these links:-
- MQDev Blog Posts about Connection Authentication
- MQGem tools can use Connection Authentication
- Using CHCKLOCL (REQUIRED) on z/OS
What I wanted to put in this section was the same table as above, but with the IBM MQ V8 Support, showing some of reasons why the Connection Authentication feature was needed.
|Used by||Delivery Protocol||QMgr-side Checks|
|Java Client in Compatibility Mode||Historic FAP fields||Converted into MQCSP by the SVRCONN and driven through CONNAUTH|
|Java Client not in Compatibility Mode||MQCSP across client channel||MQCSP given to CONNAUTH|
|‘C’ Client||MQCSP across client channel||MQCSP given to CONNAUTH|
|Local Apps (dist)||MQCSP across IPC||MQCSP given to CONNAUTH|
|Local Apps (z/OS)||MQCSP across PC call||MQCSP given to CONNAUTH|
As you can see the local applications on z/OS get provision in V8 where there was no prior solution, and there is a common solution between Java Clients and ‘C’ clients removing all that confusion in earlier releases.
Common solution without IBM MQ V8 everywhere
As you may notice from the above table, the architected delivery protocol for user id and passwords that can be common everywhere is the MQCSP. The way to get a common solution that can work for both Java and ‘C’ clients, and also future-proof you for when you move up to IBM MQ V8 in the future, is to base your solution on MQCSP.
The MQCSP structure was introduced into WebSphere MQ V6, so as long as your client and queue manager have that level as a minimum you can take advantage of that.
So you need something at the client side which can send an MQCSP for you. Your choices are:-
- Use a WebSphere MQ V6 or above ‘C’ Client application
- Use an IBM MQ V8 Java Client application with Compatibility Mode turned off
- Use a client-side security exit, such as the mqccred exit shipped with IBM MQ V8 which you can use with older versions of the client. Some of the vendors that process MQCSP in a security exit on the queue manager side can also provide a client side exit to send an MQCSP – ask your vendor.
And you’ll also need something at the queue manager side which can receive and process an MQCSP for you. Your choices are:-
- An IBM MQ V8 Queue Manager
- One of the example Security Exits shown in the first table of this article, that process an MQCSP – so that rules out CSQ4BCX3, just to be clear.
You can mix and match these two lists as you need to.
Of course, there is one other thing to think about as you enable your user ID and password to flow from your client to your queue manager and that is to protect it as it flows across the network. Your choices are:-
- Have a fully trust-worthy network!
- Encrypt the connection, say with client-anonymous, one-way authenticated SSL/TLS
- Have a pair of exits both sending and processing the MQCSP which also encrypt what they send – some vendor solutions offer this capability
- Have IBM MQ V8 as the minimum at both ends, and the password will not be sent in the clear
- How to specify a userid and a password in MQ Explorer 8
- How to specify a userid and a password in MQGem tools
- How to specify a userid and a password in a number of other tools
If you’re an exit vendor and would like your security exits listed in the above table, please get in touch, or leave a comment below and I’ll add you in.