Using User ID and Password with a ‘C’ Application

Posted on by

“… but it works from MQ Explorer”

UserID and Password without V8It 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:-

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

Additional Resources

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.

2 thoughts on “Using User ID and Password with a ‘C’ Application”

  1. Hi Morag,

    Another important client environment is managed .NET client on Windows. While managed .NET client is very similar to Java client, it does not support compatibility mode.

    Capitalware’s MQAUSX product has client-side security exits for all 3 client environments (Java, C & .NET). From an implementation point of view, roughly 40% to 45% (of MQAUSX customers), do not and/or will not implement client-side security exit. They list a variety of reasons for not implementing a client-side security exit and getting them to implement it is (near) impossible. Hence, as you noted, MQAUSX is capable of accepting UserID and Passwords (in plain text) via either MQCSP structure and/or RemoteUserIdentifier and RemotePassword fields from the MQCD structure.

    A nice side benefit of MQ V8 is that when MQ V8 is implemented for both server-side and client-side, then MQ will encrypt the credentials as they flow between the client and server.

    Getting client applications to implement a UserID and Password or use a security exit is the real hard part but with IBM now pushing companies to implement UserID and Password in client applications, this is good news for MQ security. For Capitalware, yes MQ V8 has basic authentication and competes with MQAUSX but I believe that a rising tide (implementing more MQ security) will raise all boats. i.e. Customers will test out the basic authentication in MQ V8 and when they require a more robust solution, they we look at MQAUSX.

    Regards,
    Roger Lacroix
    Capitalware Inc.

    Like

    Reply ↓

    • Thanks Roger. You’re absolutely correct that Managed .Net is a third environment to consider. The post was written due to a number of questions from people getting the Java environment working and then wondering why it didn’t work with C. I guess in that case the Managed .Net would work like the Java environment.

      I too agree that more security is a good thing, and we’re seeing people looking to do user ID and password checking even though they’re not yet at IBM MQ V8. This will be good for vendors like yourself who can position your products as a stepping stone to IBM MQ V8 due to using MQCSP. Then you’ve just got to persuade them to stay due to superior functionality once they move to V8 🙂 I expect you might be doing a presentation on that topic in MQTC?

      Like

      Reply ↓

The team at MQGem would love to hear what you think. Leave your comments here.

This site uses Akismet to reduce spam. Learn how your comment data is processed.