Profiles for topic security
If topic security is active, we 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, we 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.topicnamewhere
- 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 we 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, we need access to both the topic we are trying to subscribe to, and the target queue for the publications.
When we issue an MQSUB request, the following security checks take place:- Whether you have the appropriate level of access to subscribe to that topic, and also that the target queue (if specified) is opened for output
- Whether you have the appropriate level of access to that target queue.
| 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 we are allowed to subscribe to the topic. However, no security checks are carried out when the managed queue is created, or to determine if you 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 we 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.| 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 we need access to the topic and, if we are using alias queues, to the alias queue as well.| 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 |
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 we 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
We 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.
| SYSTEM topic | Profile | Channel Initiator for Distributed queuing |
|---|---|---|
| SYSTEM.BROKER.ADMIN.STREAM | PUBLISH.topicname | UPDATE |
| SYSTEM.BROKER.ADMIN.STREAM | SUBSCRIBE.topicname | ALTER |