Authorizations needed for non-mqm users to publish and subscribe to Topics in MQ

+++ Summary

+++ Test cases

A MQ queue manager is used in Linux: QM_VER.
The userid "rivera" belongs to the UNIX "mqm" group. Thus, it is an MQ Administrator and it has all the authorities.

The userid "elmimo" belongs to the UNIX "mqviewer" group, but not to "mqm". Thus, it is necessary to give userid "elmimo" explicit authorities.

The authorities can ONLY be given to a TOPIC OBJECT, which indirectly gives the authority to the associated TOPIC STRING. This is because there are no facilities to provide a direct authority to a TOPIC STRING.

Use runmqsc to create the following topic objects:
define topic(TESTTOPIC) topicstr(PUBSUBV7)
define topic(TESTTOPICSAMPLE) topicstr(PUBSUBV7/SAMPLE)

At this point, there are no additional authorities yet for the non-mqm userid for these TOPIC Objects.

This technote explores the errors that are encountered by the non-mqm userid and then how to overcome them.

The topic hierarchy is shown below, where SYSTEM.BASE.TOPIC is at the top of the hierarchy:

Objects                  Strings

SYSTEM.BASE.TOPIC        (null)
     |                     |
TESTTOPIC              PUBSUBV7
     |                     |
TESTTOPICSAMPLE          SAMPLE    

Thus, the topic string "PUBSUB1/SAMPLE" is a child of the parent topic string "PUBSUB1"

Scenario 1: userid belongs to "mqm"
This is a baseline scenario to show the proper expectation.
Login as userid "mqm", who belongs to the UNIX groupid "mqm" (this is known as the MQ Administrator).
Open 2 UNIX command prompts: one to publish, and the other to subscribe.

In this case, the error AMQ8077 indicates that the user does not have authority to even connect to the queue manager:

AMQ8077: Entity 'elmimo' has insufficient authority to access object 'QM_VER'.
EXPLANATION:
The specified entity is not authorized to access the required object. The
following requested permissions are unauthorized: connect

To overcome this problem the MQ administrator needs to give the connect authority to the user or to the group id. To avoid doing a tedious analysis of each type of appropriate authority that is needed, the following command can be issued to allow the users of the UNIX group id enough authority to interact properly with the Queue Manager: +connect +inq +dsp

From the Window for the MQ Administrator:

$ setmqaut -m QM_VER -t qmgr -g mqviewer +connect +inq +dsp
The setmqaut command completed successfully.

Verify that the group id has now these basic authorities:

$ dspmqaut -m QM_VER -t qmgr -g mqviewer
Entity mqviewer has the following authorizations for object QM_VER:
        inq
        connect
        dsp

From the Window of the non-mqm user:

Now go back to the window that has the non-mqm user and enter again:

$ amqspub PUBSUBV7 QM_VER
Sample AMQSPUBA start
target topic is PUBSUBV7
MQOPEN ended with reason code 2035
unable to open topic for publish
Sample AMQSPUBA end

We got another reason code 2035, but this time we received another clue: the userid cannot open the topic for publish. That is, the first obstacle of connecting to the queue manager was overcome, but we have another obstacle.

Because the MQS_REPORT_NOAUTH has been set, let's check again the error log of the queue manager for more details:

06/29/2009 12:25:59 PM - Process(15095.22) User(rivera) Program(amqzlaa0)
AMQ8077: Entity 'elmimo ' has insufficient authority to access object
'SYSTEM.BASE.TOPIC'.
EXPLANATION:
The specified entity is not authorized to access the required object. The following requested permissions are unauthorized: pub

WARNING: It is NOT a good idea to give authorities for non-mqm users at the root node of the topic tree, which is SYSTEM.BASE.TOPIC, because the authorities are inherited but cannot be restricted, and thus, by giving authorities at this level, you are giving authorities to the whole tree. It is a best practice to give the authority at a lower topic in the hierarchy.

From the Window for the MQ Administrator:

The MQ administrator needs to give the authority "pub" to this user. However, based on the above "best practice", the authority will be given at the child node "

$ setmqaut -m QM_VER -n TESTTOPIC -t topic -g mqviewer +pub

Let's take advantage and give the following 2 authorities for subscribe: +sub +resume
The +resume is needed to resume durable subscriptions.

$ setmqaut -m QM_VER -n TESTTOPIC -t topic -g mqviewer +sub +resume

From the Window of the non-mqm user:
Let's try again to publish:

$ amqspub PUBSUBV7 QM_VER
Sample AMQSPUBA start
target topic is PUBSUBV7
TEST

Sample AMQSPUBA end

Now let's try to publish at the topic string PUBSUBV7/SAMPLE. Notice that we have NOT given any explicit authorities for it.

$ amqspub PUBSUBV7/SAMPLE QM_VER
Sample AMQSPUBA start
target topic is PUBSUBV7/SAMPLE
test

Sample AMQSPUBA end

The reason that it works, is that the authorities are inherited, and in this case the topic string "PUBSUBV7/SAMPLE" is inheriting the authorities from the topic object which is associated with "PUBSUBV7".


Scenario 3: Security given at parent nodes cannot be restricted in child nodes

Now, let's try to restrict the pub activity for the topic string "PUBSUBV7/SAMPLE". Remember that we need to manipulate a topic object, in this case "TESTTOPICSAMPLE".

Login as the MQ Administrator.
Open a window and issue the following command and specify: -pub

$ setmqaut -m QM_VER -n TESTTOPICSAMPLE -t topic -g mqviewer -pub
The setmqaut command completed successfully.

Login as a non-mqm user.
Open a window and issue the following to verify if this user can publish:

$ amqspub PUBSUBV7/SAMPLE QM_VER
Sample AMQSPUBA start
target topic is PUBSUBV7/SAMPLE
test

Sample AMQSPUBA end

Notice that the non-mqm user was able to publish, even though the authority -pub was provided in a setmqaut command.

The explanation is:

-pub and -sub clear the authority to publish and subscribe on the topic (they do NOT restrict it).
If a group has a +sub for a parent administration topic node and -sub for the child of this node, the -sub is ineffective. This holds true because the security attributes are delegated from the parent to the child administration nodes.

MQ has "positive" authorities, for example: +pub gives the authority to publish, and -pub removes that authority. That is, MQ does not have "negative" authorities, for example: if +pub is given at a higher node, there are no commands that will prohibit the user to publish at a lower nodes.

The above is mentioned in the Redbook shown in the next section: Reference

Reference

This section shows some referenced material from the following redbook:

WebSphere MQ V7.0 Features and Enhancements (SG24-7583)

4.2.4 Topic security
Nodes in the topic hierarchy that have a topic object associated with them are
known as administration nodes. The delegation model of inheriting attributes
from the nearest administration node in the topic hierarchy, as discussed in
previous sections, holds true for security as well. Nodes that are automatically
generated inherit the properties of the nearest parent administration node in the
topic hierarchy. Once an application is permitted to publish or subscribe at a
parent-level administration node, it cannot be denied publishing or subscribing
authorities on a child-level administration node.

9.1.9 Setting up topic security using setmqaut
The setmqaut control command is used to change the authorizations to a profile,
object, or class of objects. Authorizations can be granted to, or revoked from, any
number of principals or groups. The principals or groups to which the
authorizations apply must be specified, along with the queue manager, object
type, and the profile name that identifies the objects.
Example 9-2 demonstrates the use of setmqaut with the topic type. It also shows usage of the three new
kinds of authorities:
Pub
Sub
Resume
.
Example 9-2 Using setmqaut
To let the users in the group “editors” subscribe to topic “DELI” on
Queue Manager WMQ7:
setmqaut -m WMQ7 -n DELI -t topic -g editors +sub +resume
And to allow users in the group “journalists” to publish to the topic:
setmqaut -m WMQ7 -n DELI -t topic -g journalists +pub
.
Note: -pub and -sub clear the authority to publish and subscribe on the topic.
If a group has a +sub for a parent administration topic node and -sub for the
child of this node, the -sub is ineffective. This holds true because the security
attributes are delegated from the parent to the child administration nodes.


+++ Tutorials on JMS Pub/Sub

Configuring and running simple JMS P2P and Pub/Sub applications in MQ V7
IBM Techdoc: 7023212
The objective of this document is to provide step-by-step instructions for configuring and running simple standalone (not WAS) JMS Point-to-Point (P2P) and Pub/Sub applications in WebSphere MQ V7 for UNIX and Windows.
In UNIX, the JMSAdmin tool is used to populate the Java Naming and Directory Interface (JNDI) with the JMS Administrative objects that serve as a link between the JMS application and the physical queues and topics in the queue manager. This JNDI is in the form of a file named ".bindings".
In Windows and in Linux x86, in addition to the JMSAdmin tool, the GUI MQ Explorer tool can be used to populate the JNDI into a file named ".bindings".

Using WebSphere MQ V7 as JMS Provider for WebSphere Application Server V7, V8.0 and V8.5
IBM Techdoc: 7016505
Chapter 4: Additional scenarios: Topics (Pub/Sub)

+++ end +++