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

White paper


Abstract

The purpose of this note is to document the error messages that are issued when a non mqm userid (a user not a member of the UNIX "mqm" group) tries to publish, subscribe or resume a Topic in WebSphere MQ V7.

Content

+++ Summary

If you want to let the users in the groups "editors" and "journalists" connect to the queue manager WMQ7:
setmqaut -m WMQ7 -t qmgr -g editors +connect +inq +dsp
setmqaut -m WMQ7 -t qmgr -g journalists +connect +inq +dsp

If you want to let the users in the group "editors" subscribe to topic “DELI” on Queue Manager WMQ7 and to resume durable subscriptions:
setmqaut -m WMQ7 -n DELI -t topic -g editors +sub +resume

If you want to allow users in the group "journalists" to publish to the topic:
setmqaut -m WMQ7 -n DELI -t topic -g journalists +pub


+++ Test cases

A MQ V7 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 "PUBSUBV7/SAMPLE" is a child of the parent topic string "PUBSUBV7"

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.

    • Window 1: Subscribe to the topic string.
      The amqssub waits for 30 seconds for a message. If one is received then it resets the 30 seconds timer. If not, then it terminates.

      $ amqssub PUBSUBV7/SAMPLE QM_VER
    • Window 2: Publish to the topic string
      Enter a brief text, such as: TEST followed by pressing Enter twice. The first Enter is to provide the TEST string, the second is to exit.

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

      Sample AMQSPUBA end
      Expected output
      In the Window 1 you should see:

      Sample AMQSSUBA start
      Calling MQGET : 30 seconds wait time
      message <TEST>
      Calling MQGET : 30 seconds wait time
      no more messages
      Sample AMQSSUBA end


Scenario 2: userid does not belong to "mqm" and does not have any authorities on the topics
Login as userid "elmimo", who belongs to the UNIX groupid "mqviewer". and is NOT an MQ Administrator.
Notice that there are no additional authorities for the groupid "mqviewer" (and subsequently for the userid "elmimo").
$ dspmqaut -m QM_VER -t qmgr -g mqviewer
 Entity mqviewer has the following authorizations for object QM_VER:


Open 2 UNIX command prompts: one to subscribe, and the other to publish.
  • Window 1: Subscribe to the topic string.

    $ amqssub PUBSUBV7 QM_VER
    Sample AMQSSUBA start
    MQCONN ended with reason code 2035
  • Window 2: Publish to the topic string

    $ amqspub PUBSUBV7 QM_VER
    Sample AMQSPUBA start
    MQCONN ended with reason code 2035

    Note: The MQ reason code of 2035 means: MQRC_NOT_AUTHORIZED

Unfortunately, the output of amqspub or amqssub commands do not provide more details, such as which particular authority is required. One possible way to find out, is to capture the MQ trace, but this is cumbersome. Instead, a more feasible solution is to follow the recommendations from this technote:

The MQS_REPORT_NOAUTH environment variable can be used to better diagnose return code 2035 (MQRC_NOT_AUTHORIZED)

The important steps are:
  1. Open a new window for the MQ Administrator.
  2. Login as the MQ administrator.
  3. Export the environment variable: "export MQS_REPORT_NOAUTH=TRUE".
  4. Re start the queue manager.
  5. Recreate the authorization failure.
  6. Browse the queue manager error log, looking for AMQ8077.

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
http://www.ibm.com/support/docview.wss?rs=171&uid=swg27023212
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
http://www.ibm.com/support/docview.wss?rs=171&uid=swg27016505
Chapter 4: Additional scenarios: Topics (Pub/Sub)

Product Alias/Synonym

WebSphere MQ WMQ

Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

WebSphere MQ
PubSub

Software version:

7.0, 7.0.1, 7.1, 7.5

Operating system(s):

AIX, HP Itanium, Linux, Solaris, Windows

Reference #:

7016153

Modified date:

2013-12-04

Translate my page

Machine Translation

Content navigation