Profiles for queue security

If queue security is active, we must define profiles in the appropriate classes and permit the necessary groups or user IDs access to these profiles. Queue security profiles are named after the queue manager or queue sharing group, and the queue to be opened.

If queue security is active, we must:

  • Define profiles in the MQQUEUE or GMQQUEUE classes if using uppercase profiles.
  • Define profiles in the MXQUEUE or GMXQUEUE classes if using mixed case profiles.
  • Permit the necessary groups or user IDs access to these profiles, so that they can issue IBM MQ API requests that use queues.

Profiles for queue security take the form:

hlq.queuename

where hlq can be either qmgr-name (queue manager name) or qsg-name (queue sharing group name), and queuename is the name of the queue being opened, as specified in the object descriptor on the MQOPEN or MQPUT1 call.

A profile prefixed by the queue manager name controls access to a single queue on that queue manager. A profile prefixed by the queue sharing group name controls access to access to one or more queues with that queue name on all queue managers within the queue sharing group, or access to a shared queue by any queue manager within the group. This access can be overridden on an individual queue manager by defining a queue manager level profile for that queue 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.

If we are using shared queues, we are recommended to use queue sharing group level security.

For details of how queue security operates when the queue name is that of an alias or a model queue, see Considerations for alias queues and Considerations for model queues .

The RACF access required to open a queue depends on the MQOPEN or MQPUT1 options specified. If more than one of the MQOO_* and MQPMO_* options is coded, the queue security check is performed for the highest RACF authority required.

MQOPEN or MQPUT1 option RACF access level required to access hlq.queuename
MQOO_BROWSE READ
MQOO_INQUIRE READ
MQOO_BIND_* UPDATE
MQOO_INPUT_* UPDATE
MQOO_OUTPUT or MQPUT1 UPDATE
MQOO_PASS_ALL_CONTEXT MQPMO_PASS_ALL_CONTEXT UPDATE
MQOO_PASS_IDENTITY_CONTEXT MQPMO_PASS_IDENTITY_CONTEXT UPDATE
MQOO_SAVE_ALL_CONTEXT UPDATE
MQOO_SET_IDENTITY_CONTEXT MQPMO_SET_IDENTITY_CONTEXT UPDATE
MQOO_SET_ALL_CONTEXT MQPMO_SET_ALL_CONTEXT UPDATE
MQOO_SET ALTER
For example, on IBM MQ queue manager QM77, all user IDs in the RACF group PAYGRP are to be given access to get messages from or put messages to all queues with names beginning with 'PAY.'. We can do this using these RACF commands:
RDEFINE MQQUEUE QM77.PAY.** UACC(NONE)
PERMIT QM77.PAY.** CLASS(MQQUEUE) ID(PAYGRP) ACCESS(UPDATE)
Also, all user IDs in the PAYGRP group must have access to put messages on queues that do not follow the PAY naming convention. For example:
REQUEST_QUEUE_FOR_PAYROLL
SALARY.INCREASE.SERVER
REPLIES.FROM.SALARY.MODEL

We can do this by defining profiles for these queues in the GMQQUEUE class and giving access to that class as follows:

RDEFINE GMQQUEUE PAYROLL.EXTRAS UACC(NONE)
        ADDMEM(QM77.REQUEST_QUEUE_FOR_PAYROLL,
               QM77.SALARY.INCREASE.SERVER,
               QM77.REPLIES.FROM.SALARY.MODEL)
PERMIT PAYROLL.EXTRAS CLASS(GMQQUEUE) ID(PAYGRP) ACCESS(UPDATE)
Note:
  1. If the RACF access level that an application has to a queue security profile is changed, the changes only take effect for any new object handles obtained (that is, new MQOPEN s) for that queue. Those handles already in existence at the time of the change retain their existing access to the queue. If an application is required to use its changed access level to the queue rather than its existing access level, it must close and reopen the queue for each object handle that requires the change.
  2. In the example, the queue manager name QM77 could also be the name of a queue sharing group.

Other types of security checks might also occur at the time the queue is opened depending on the open options specified and the types of security that are active. See also Profiles for context security and Profiles for alternate user security. For a summary table showing the open options and the security authorization needed when queue, context, and alternate user security are all active, see Table 1. If we are using publish/subscribe we must consider the following. When an MQSUB request is processed a security check is performed to ensure that the user ID making the request has the required access to put messages to the target IBM MQ queue as well as the required access to subscribe to the IBM MQ topic.

MQSUB option RACF access level required to access hlq.queuename
MQSO_ALTER, MQSO_CREATE, and MQSO_RESUME UPDATE
Note:
  1. The hlq.queuename is the destination queue for publications. When this is a managed queue, we need access to the appropriate model queue to be used for the managed queue and the dynamic queue that are created.
  2. We can use a technique like this for the destination queue you provide on an MQSUB API call if we want to distinguish between the users making the subscriptions, and the users retrieving the publications from the destination queue.

  • Considerations for alias queues
    When we issue an MQOPEN or MQPUT1 call for an alias queue, IBM MQ makes a resource check against the queue name specified in the object descriptor (MQOD) on the call. It does not check if the user is allowed access to the target queue name.
  • Use alias queues to distinguish between MQGET and MQPUT requests
    The range of MQI calls available in one access level can cause a problem if we want to restrict access to a queue to allow only the MQPUT call or only the MQGET call. A queue can be protected by defining two aliases that resolve to that queue: one that enables applications to get messages from the queue, and one that enable applications to put messages on the queue.
  • Considerations for model queues
    To open a model queue, we must be able to open both the model queue itself and the dynamic queue to which it resolves. Define generic RACF profiles for dynamic queues, including dynamic queues used by IBM MQ utilities.
  • Close options on permanent dynamic queues
    If an application opens a permanent dynamic queue that was created by another application and then attempts to delete that queue with an MQCLOSE option, some extra security checks are applied when the attempt is made.
  • Security and remote queues
    When a message is put on a remote queue, the queue security that is implemented by the local queue manager depends on how the remote queue is specified when it is opened.
  • Dead-letter queue security
    Special considerations apply to the dead-letter queue, because many users must be able to put messages on it, but access to retrieve messages must be tightly restricted. We can achieve this by applying different RACF authorities to the dead-letter queue and an alias queue.
  • System queue security
    We must set up RACF access to allow certain user IDs access to particular system queues.
  • API-resource security access quick reference
    A summary of the MQOPEN, MQPUT1, MQSUB, and MQCLOSE options and the access required by the different resource security types.

Parent topic: Profiles used to control access to IBM MQ resources