When security checks are made on UNIX, Linux, and Windows

Security checks are typically made on connecting to a queue manager, opening or closing objects, and putting or getting messages.

The security checks made for a typical application are as follows:

    Connect to the queue manager (MQCONN or MQCONNX calls)
    This is the first time that the application is associated with a particular queue manager. The queue manager interrogates the operating environment to discover the user ID associated with the application. IBM MQ then verifies that the user ID is authorized to connect to the queue manager and retains the user ID for future checks.

    Users do not have to sign on to IBM MQ; IBM MQ assumes that users have signed on to the underlying operating system and have been authenticated by that.

    Opening the object (MQOPEN or MQPUT1 calls)
    IBM MQ objects are accessed by opening the object and issuing commands against it. All resource checks are performed when the object is opened, rather than when it is actually accessed. This means that the MQOPEN request must specify the type of access required (for example, whether the user wants only to browse the object or perform an update like putting messages onto a queue).

    IBM MQ checks the resource that is named in the MQOPEN request. For an alias or remote queue object, the authorization used is that of the object itself, not the queue to which the alias or remote queue resolves. This means that the user does not need permission to access it. Limit the authority to create queues to privileged users. If we do not, users might bypass the normal access control simply by creating an alias. If a remote queue is referred to explicitly with both the queue and queue manager names, the transmission queue associated with the remote queue manager is checked.

    The authority to a dynamic queue is based on that of the model queue from which it is derived, but is not necessarily the same. This is described in Note 1.

    The user ID used by the queue manager for access checks is the user ID obtained from the operating environment of the application connected to the queue manager. A suitably authorized application can issue an MQOPEN call specifying an alternative user ID; access control checks are then made on the alternative user ID. This does not change the user ID associated with the application, only that used for access control checks.

    Put and getting messages (MQPUT or MQGET calls)
    No access control checks are performed.

    Closing the object (MQCLOSE)
    No access control checks are performed, unless the MQCLOSE results in a dynamic queue being deleted. In this case, there is a check that the user ID is authorized to delete the queue.

    Subscribing to a topic (MQSUB)
    When an application subscribes to a topic, it specifies the type of operation that it needs to perform. It is either creating a new subscription, altering an existing subscription, or resuming an existing subscription without changing it. For each type of operation, the queue manager checks that the user ID that is associated with the application has the authority to perform the operation.
    When an application subscribes to a topic, the authority checks are performed against the topic objects that are found in the topic tree at or above the point in the topic tree at which the application subscribed. The authority checks might involve checks on more than one topic object.
    The user ID that the queue manager uses for the authority checks is the user ID obtained from the operating system when the application connects to the queue manager.
    The queue manager performs authority checks on subscriber queues but not on managed queues.

Parent topic: Authority to work with IBM MQ objects on UNIX, Linux, and Windows