Profiles for topic security

If topic security is active, you must define profiles in the appropriate classes and permit the necessary groups or user IDs access to those profiles.

The concept of topic security within a topic tree is described in Publish/subscribe security.

If topic security is active, you must perform the following actions:

  • Define profiles in the MXTOPIC or GMXTOPIC classes.
  • Permit the necessary groups or user IDs access to these profiles, so that they can issue IBM MQ API requests that use topics.
Profiles for topic security take the form: 
hlq.SUBSCRIBE.topicname
hlq.PUBLISH.topicname
where

  • hlq is either qmgr-name (queue manager name) or qsg-name (queue sharing group name).
  • topicname is the name of the topic administration node in the topic tree, associated either with the topic being subscribed to through an MQSUB call, or being published to through an MQOPEN call.

A profile prefixed by the queue manager name controls access to a single topic on that queue manager. A profile prefixed by the queue sharing group name controls access to one or more topics with that topic name on all queue managers within the queue sharing group. This access can be overridden on an individual queue manager by defining a queue manager level profile for that topic on that queue manager.

If your queue manager is a member of a queue sharing group and you are using both queue manager and queue sharing group level security, IBM MQ checks for a profile prefixed by the queue manager name first. If it does not find one, it looks for a profile prefixed by the queue sharing group name.


Subscribe

To subscribe to a topic, you need access to both the topic you are trying to subscribe to, and the target queue for the publications.

When you issue an MQSUB request, the following security checks take place:

  • Whether we have the appropriate level of access to subscribe to that topic, and also that the target queue (if specified) is opened for output
  • Whether we have the appropriate level of access to that target queue.
Table 1. Access level required for topic security to subscribe
Action Access level required
MQSUB to a topic RACF® access required to hlq.SUBSCRIBE.topicname profile in MXTOPIC class
MQSO_CREATE and MQSO_ALTER ALTER
MQSO_RESUME READ
MQSUB - additional authority to non-managed destination queues. RACF access required to hlq.CONTEXT.queuename profile in MQADMIN or MXADMIN class
MQSO_CREATE, MQSO_ALTER, and MQSO_RESUME UPDATE
  RACF access required to hlq.queuename profile in MQQUEUE or MXQUEUE class
MQSO_CREATE and MQSO_ALTER UPDATE
  RACF access required to hlq.ALTERNATE.USER.alternateuserid profile in MQADMIN or MXADMIN class
MQSO_ALTERNATE_USER_AUTHORITY UPDATE


Considerations for managed queues for subscriptions

A security check is carried out to see if you are allowed to subscribe to the topic. However, no security checks are carried out when the managed queue is created, or to determine if we have access to put messages to this destination queue.

We cannot close delete a managed queue.

The model queues used are: SYSTEM.DURABLE.MODEL.QUEUE and SYSTEM.NDURABLE.MODEL.QUEUE.

The managed queues created from these model queues are of the form SYSTEM.MANAGED.DURABLE.A346EF00367849A0 and SYSTEM.MANAGED.NDURABLE.A346EF0036785EA0 where the last qualifier is unpredictable.

Do not give any user access to these queues. The queues can be protected using generic profiles of the form SYSTEM.MANAGED.DURABLE.* and SYSTEM.MANAGED.NDURABLE.* with no authorities granted.

Messages can be retrieved from these queues using the handle returned on the MQSUB request.

If you explicitly issue an MQCLOSE call for a subscription with the MQCO_REMOVE_SUB option specified, and you did not create the subscription you are closing under this handle, a security check is performed at the time of closure to ensure that we have the correct authority to perform the operation.
Table 2. Access level required to profiles for topic security for closure of a subscribe operation
Action Access level required
MQCLOSE (of a subscription) RACF access required to hlq.SUBSCRIBE.topicname profile in MXTOPIC class
MQCO_REMOVE_SUB ALTER


Publish

To publish on a topic you need access to the topic and, if you are using alias queues, to the alias queue as well.
Table 3. Access level required to profiles for topic security for a publish operation
Action Access level required
MQOPEN (of a topic) RACF access required to hlq.PUBLISH.topicname profile in MXTOPIC class
MQOO_OUTPUT or MQPUT1 UPDATE
MQOPEN (Alias queue to topic) RACF access required to hlq.queuename profile in MQQUEUE or MXQUEUE class for the alias queue
MQOO_OUTPUT or MQPUT1 UPDATE
For details of how topic security operates when an alias queue that resolves to a topic name is opened for publish, see Considerations for alias queues that resolve to topics for a publish operation.

When you consider alias queues used for destination queues for PUT or GET restrictions, see Considerations for alias queues.

If the RACF access level that an application has to a topic security profile is changed, the changes take effect only for any new object handles obtained (that is, a new MQSUB or MQOPEN) for that topic. Those handles already in existence at the time of the change retain their existing access to the topic. Also, existing subscribers retain their access to any subscriptions that they have already made.


Considerations for alias queues that resolve to topics for a publish operation

When you issue an MQOPEN or MQPUT1 call for an alias queue that resolves to a topic, IBM MQ makes two resource checks:

  • The first one against the alias queue name specified in the object descriptor (MQOD) on the MQOPEN or MQPUT1 call.
  • The second against the topic to which the alias queue resolves
You must be aware that this behavior is different from the behavior you get when alias queues resolve to other queues. You need the correct access to both profiles in order for the publish action to proceed.


System topic security

Many of the system topics are accessed by the ancillary parts of IBM MQ, for example the channel initiator address space.

The user IDs under which this runs must be given RACF access to these queues, as shown in Table 4.

Table 4. Access required to the SYSTEM topics
SYSTEM topic Profile Channel Initiator for Distributed queuing
SYSTEM.BROKER.ADMIN.STREAM PUBLISH.topicname UPDATE
SYSTEM.BROKER.ADMIN.STREAM SUBSCRIBE.topicname ALTER