Authority to work with WebSphere MQ objects

 

Overview

Queue managers, queues, processes, namelists, and authentication information objects are all accessed from applications that use MQI calls or PCF commands. These resources are all protected by MQ, and applications need to be given permission to access them. The entity making the request might be a user, an application program that issues an MQI call, or an administration program that issues a PCF command. The identifier of the requester is referred to as the principal.

Different groups of principals can be granted different types of access authority to the same object. For example, for a specific queue, one group might be allowed to perform both put and get operations; another group might be allowed only to browse the queue (MQGET with browse option). Similarly, some groups might have put and get authority to a queue, but not be allowed to alter attributes of the queue or delete it.

Some operations are particularly sensitive and should be limited to privileged users. For example:

Full control permission for all objects is automatically given to the user ID that creates the object and to members of the mqm group.

 

When security checks are made

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

  1. Connecting to the queue manager

    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. 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 MQ; MQ assumes that users have signed on to the underlying operating system and have been authenticated by that.

  2. Opening the object

    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).

    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 you 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.

    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.

  3. Putting and getting messages

    No access control checks are performed.

  4. Closing the object

    Access control checks are performed, unless the MQCLOSE will result in a dynamic queue being deleted. In this case, there is a check that the user ID is authorized to delete the queue.

 

How access control is implemented by MQ

MQ uses the security services provided by the underlying operating system. An access control interface called the Authorization Service Interface is part of MQ. MQ supplies an implementation of an access control manager (conforming to the Authorization Service Interface) known as the Object Authority Manager (OAM). This is automatically installed and enabled for each queue manager you create, unless you specify otherwise.

The OAM can be replaced by any user or vendor written component that conforms to the Authorization Service Interface.

The OAM exploits the security features of the underlying operating system, using operating system user and group IDs. Users can access MQ objects only if they have the correct authority.

The OAM maintains an access control list (ACL) for each resource that it controls, stored in a local queue named SYSTEM.AUTH.DATA.QUEUE. Do not update this queue manually. Always use the proper MQ command.

MQ passes the OAM a request containing a principal, a resource name, and an access type. The OAM grants or rejects access based on the ACL that it maintains. MQ follows the decision of the OAM; if the OAM cannot make a decision, MQ does not allow access.

 

Identifying the user ID

The OAM needs to be able to identify who is requesting access to a particular resource. MQ uses the term principal to refer to this identifier. The principal is established when the application first connects to the queue manager; it is determined by the queue manager from the user ID associated with the connecting application. (If the application is running in a transaction monitor environment, the connection is through the X/Open XA interface, which does not provide a mechanism for passing user IDs, so MQ assumes a default user name.)

On UNIX systems, the authorization routines check the real (logged-in) user ID.

MQ propagates the user ID received from the system in the message header MQMD(structure) of each message as identification of the user. This identifier is part of the message context information. Applications cannot alter this information unless they have been authorized to change context information.

 

Principals and groups

Principals can belong to groups. You can grant access to a particular resource to groups rather than to individuals, to reduce the amount of administration required. For example, you might define a group consisting of users who want to run a particular application. Other users can be given access to all the resources they require simply by adding their user ID to the appropriate group.

A principal can belong to more than one group (its group set) and has the aggregate of all the authorities granted to each group in its group set. These authorities are cached, so any changes you make to the principal's group membership are not recognized until the queue manager is restarted, unless you issue the MQSC command REFRESH SECURITY (or the PCF equivalent).

All ACLs are based on groups. When a user is granted access to a particular resource, the user ID's primary group is included in the ACL, not the individual user ID, and authority is granted to all members of that group. Because of this, be aware that you could inadvertently change the authority of a principal by changing the authority of another principal in the same group.

All users are nominally assigned to the default user group nobody and by default, no authorizations are given to this group. You can change the authorization in the nobody group to grant access to MQ resources to users without specific authorizations.

 

Alternate-user authority

You can specify that a user ID can use the authority of another user when accessing a MQ object. This is called alternate user authority, and you can use it on any MQ object.

Alternate-user authority is essential where a server receives requests from a program and wants to ensure that the program has the required authority for the request. The server might have the required authority, but it needs to know whether the program has the authority for the actions it has requested.

For example, assume that a server program running under user ID PAYSERV retrieves a request message from a queue that was put on the queue by user ID USER1. When the server program gets the request message, it processes the request and puts the reply back into the reply-to queue specified with the request message. Instead of using its own user ID (PAYSERV) to authorize opening the reply-to queue, the server can specify a different user ID, in this case, USER1. In this example, you can use alternate-user authority to control whether PAYSERV is allowed to specify USER1 as an alternate-user ID when it opens the reply-to queue.

The alternate-user ID is specified on the AlternateUserId field of the object descriptor.

 

Context authority

Context is information that applies to a particular message and is contained in the message descriptor, MQMD, which is part of the message. The context information comes in two sections:

Identity section
Who the message came from. It consists of the UserIdentifier, AccountingToken, and ApplIdentityData fields.

Origin section
Where the message came from, and when it was put onto the queue. It consists of the PutApplType, PutApplName, PutDate, PutTime, and ApplOriginData fields.

Applications can specify the context data when either an MQOPEN or MQPUT call is made. This data might be generated by the application, passed on from another message, or generated by the queue manager by default. For example, context data can be used by server programs to check the identity of the requester, testing whether the message came from an application running under an authorized user ID.

A server program can use the UserIdentifier to determine the user ID of an alternate user. You use context authorization to control whether the user can specify any of the context options on any MQOPEN or MQPUT1 call.

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.