This is part of an occasional series of small blog posts where I (Morag) will write about some of the quirks in IBM MQ, in the hope of invoking the response, "Well, I didn't know that!" Read other posts in this series.

Distributed Platform authorities

When an MQ application opens a resource, the queue manager checks that the user ID running the application has been granted the required authority. The "required authority" is determined based on the Open Options used as shown in the table below.

This table in itself is not 'quirky' but what you may not have realized is that each open option has a one-to-one mapping to an authority. This is probably obvious when you look at it laid out as above, but may not be quite so obvious when you think about it as some of the use cases below. And that is the point of today's blog post.

Example 1: Get and Browse

You might well imagine that if you are able to get a message from a queue, then you would also be able to browse the message. After all, browsing let's you see all the same data in the MQMD and message body, but without the ability to destructively remove the message from the queue.

However, if you look at the table above, you can see that the MQOO_BROWSE option and the MQOO_INPUT_* options, are covered by different authorities, and so you can have one without the other. You can grant a user ID access to get from a queue, but not to browse the queue, and vice versa. One does not imply the other.

Example 2: Passing Context

The Context fields are the following MQMD fields:-

As an application, you can, if needed, request to manipulate these fields. If you don't then the queue manager will fill them in with the information it knows about the application.

One type of application that should be handling these fields is an application that is dishing out messages, perhaps reading from a central queue and moving messages to one of several more targeted queues to be processed. This sort of application doesn't want the queue manager to fill in the MQMD fields with data identifying it, but instead to leave what was already there in the message identifying the original putter of the message. Such an application will use MQOO_PASS_IDENTITY_CONTEXT, or perhaps MQOO_PASS_ALL_CONTEXT.

You'll note there is no option called MQOO_PASS_ORIGIN_CONTEXT. If you want to manipulate the Origin Context fields, you are assumed to also want to manipulate the Identity Context fields. So, the MQOO_PASS_ALL_CONTEXT necessarily includes what the MQOO_PASS_IDENTITY_CONTEXT can do, but also passes the Origin fields too. However, the authority that goes with MQOO_PASS_ALL_CONTEXT does not grant you the ability to use the option MQOO_PASS_IDENTITY_CONTEXT. You need to be granted the exact authority that goes with the option you use.

Example 3: Setting Context

In exactly the same way that the two MQOO_PASS_*_CONTEXT options operate, so do the MQOO_SET_*_CONTEXT options. There is an MQOO_SET_IDENTITY_CONTEXT option which allows you to fill in the Identity Context fields on your message, and there is an MQOO_SET_ALL_CONTEXT option which allows you to fill in both the Identity Context fields and the Origin Context fields on your message. While one option includes the fields of the other, you must be granted the exact authority that goes with the option you use.

z/OS Platform authorities

Things are a little different when you look at IBM MQ on z/OS. On this platform there is no OAM. The z/OS platform has a security manager and so IBM MQ on z/OS uses that rather than providing it's own. This however means that instead of having an individual authority for each operation, the various authorities had to be "squeezed" into the smaller set of authorities that the SAF interface on z/OS provides. These are:-

Only four distinct access authorities to play with, and these are additive, that is, if you have UPDATE authority on a resource, it necessarily means you also have READ authority.

Here is the same table as shown above for distributed for the IBM MQ for z/OS product.

So there are a number of differences here.

• If you can get, you can also browse, since these are granted as UPDATE and READ respectively, on the same queue profile.
• If you can get, you can also put! These are both UPDATE on the queue profile. For this reason, some queue managers will have two alias queues defined to separate these actions. Read more about this trick here.
• If you can set, you can also inquire, since these are granted as ALTER and READ respectively, on the same queue profile.
• Two different profiles are used to manage the context manipulating actions. Both the standard queue profile and another separate profile with the name qmgr.CONTEXT.queuename.
• Passing either Identity or All Context requires the same level of authority.

So, while all the same options are available to an application making an MQOPEN call whether it is connected to a z/OS or distributed queue manager, the way the authorities are granted make the behaviour slightly different. On z/OS, you might be able to assume another Open Option will work for you with the same security settings, where on Distributed you cannot.

These are quirks of the way the authority manager (SAF vs OAM) are implemented, and don't, in my view, make either more or less secure. As always, you simply need to understand the system you are using.

I was prompted to write this post as a result of a question on the MQ List Server.