Pub/Sub security

One of the recurring questions I receive is about the differences between queue security and pub/sub security. The email below is typical:

I have been trying to get ACF2 access rules in place to secure Pub Sub Topics but I cannot get it to work as documented. Based on the documentation, the call should be made to hlq.SUBSCRIBE.topicname and hlq.PUBLISH.topicname. I currently set the rules to prevent any access to the Topic EPUB with the following ACF2 entries:

SUBSCRIBE.SYSTEM.BASE.TOPIC UID(*) ALLOW
SUBSCRIBE.EPUB UID(*) PREVENT

Based on the above rules, I should not be able to run a process to subscribe to EPUB, but my process ran successfully. The SUBSCRIBE.EPUB UID(*) PREVENT entry should have given me a security violation (MQ 2035). When I look at the Master region initialization, I do see the following message:

20.49.59 STC04131 CSQH024I +MD9T CSQHINIT TOPIC security switch set ON,
356 profile ‘MD9T.NO.TOPIC.CHECKS’ not found

I am not sure, but it may be that either I am missing a profile or that ACF2 is not making the check for some reason.

My response to the email is pasted in below:

I think the problem here is that Pub/Sub authorizations don’t quite work the way you are expecting.  With profiles for queues, the most specific profile is resolved and a single check is made.  So if you have a profiles like this…

setmqaut -n ‘**’ +put +get +inq
setmqaut n ‘SYSTEM.**’ +inq
setmqaut -n SYSTEM.DEFAULT.LOCAL.QUEUE +put +get +inq

…you can open MY.QUEUE for put and get (it matches ‘**’), are restricted from opening most SYSTEM.* queues for anything but inquire, but CAN open SYSTEM.DEFAULT.LOCAL.QUEUE because its profile is more specific than the other two which also match.

With topics it works a bit different.  Suppose you have the following topic hierarchy:

Price/
Price/Fruit/
Price/Fruit/Apples
Price/Fruit/Oranges
Price/Vegetables/
Price/Vegetables/Kale
Price/Vegetables/Broccoli

Anyone authorized to publish on Price/Fruit is able to publish on Price/Fruit/Apples and Price/Fruit/Oranges because these are subtopics of Price/Fruit.  But they are NOT authorized to publish on Price/Vegetables based on the authorization at Price/Fruit.

Anyone that is allowed to publish on Price/ can by definition publish on any more specific topic, including Price/Fruit/ and Price/Vegetables.  This is because they are subtopics of Price/.

So the question is, what happens when two profiles match the same topic string? The closest analogy to your configuration is that we allow publication on Price/ but prevent it on Price/Fruit.

The answer lies in how the checks occur.  Suppose someone tries to publish or subscribe on Price/Fruit/Apples and there’s no topic definition at that level. The result is that the operation is by default denied at that level, and resolution restarts at the next highest level.  MQ finds the topic object at Price/Fruit and sees that it denies access. But resolution does not stop here because access at a higher level includes access at lower levels, therefore MQ needs to know if access is granted further up, so resolution starts again at the next higher level.

Checks continue up the topic hierarchy until either a) a topic is found at which access is granted; or b) MQ reaches SYSTEM.BASE.TOPIC without finding an access grant, at which point access is denied.  If you compare this to authorizing queues, it is kind of opposite – with topics, the *least* specific profile takes precedence.

Why is this? Well, for starters it is kind of intuitive that if you can publish on a topic, you should be able to dynamically invent subtopics within that topic.  But leaving that aside for a moment, imagine that in my hierarchy an app successfully subscribed at Price/Fruit but did not have access to Price/Fruit/Apples.  In order to enforce the restriction lower in the hierarchy, WMQ would be forced to perform an authorization check on EVERY message rather than once at the subscribe API call. That would be a performance nightmare.  Also, messages for Price/Fruit would be OK but the first message that showed up for Price/Fruit/Apples would cause a fatal authorization error. That would mean that an app that was in Production for years might fail suddenly when someone published to a new subtopic.  That would also be a nightmare.

In your case, you need to remove the authorization at SYSTEM.BASE.TOPIC.