Authority to work with WebSphere MQ objects

 

Overview

Applications can access the following WebSphere MQ objects by issuing MQI calls:

Applications can also use PCF commands to access these WebSphere MQ objects, and to access authentication information objects as well. These objects are protected by WebSphere MQ and the user IDs associated with the applications need authority to access them.

Applications that use the Application Messaging Interface (AMI), WebSphere MQ classes for Java, or WebSphere MQ classes for Java Message Service (JMS) still use the MQI indirectly.

MCAs also issue MQI calls and the user IDs associated with the MCAs need authority to access these WebSphere MQ objects. For more information about these user IDs and the authorities they require, see Channel security.

 

When authority checks are performed

Authority checks are performed when an application attempts to access a WebSphere MQ object that is a queue manager, queue, process, or namelist. The checks are performed in the following circumstances:

When an application connects to a queue manager using an MQCONN or MQCONNX call
The queue manager asks the operating system for the user ID associated with the application. The queue manager then checks that the user ID is authorized to connect to it and retains the user ID for future checks.

When an application opens a WebSphere MQ object using an MQOPEN or MQPUT1 call
All authority checks are performed when an object is opened, not when it is accessed subsequently. For example, authority checks are performed when an application opens a queue, but not when the application puts messages on the queue or gets messages from the queue.

When an application opens an object, it specifies the types of operation it needs to perform on the object. For example, an application might open a queue to browse the messages on it, get messages from it, but not to put messages on it. For each type of operation the application specifies, the queue manager checks that the user ID associated with the application has the authority to perform that operation.

When an application opens a queue, the authority checks are performed against the object named in the ObjectName field of the object descriptor used on the MQOPEN or MQPUT1 call. If the object is an alias queue or a remote queue definition, the authority checks are performed against the object itself, not the queue to which the alias queue or the remote queue definition resolves.

If an application references a remote queue explicitly by setting the ObjectName and ObjectQMgrName fields in the object descriptor to the names of the remote queue and the remote queue manager respectively, the authority checks are performed against the transmission queue with the same name as the remote queue manager. If an application references a cluster queue explicitly by setting the ObjectName field in the object descriptor to the name of the cluster queue, the authority checks are performed against the cluster transmission queue, SYSTEM.CLUSTER.TRANSMIT.QUEUE.

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.

When an application deletes a permanent dynamic queue using an MQCLOSE call
If the object handle specified on the MQCLOSE call is not the one returned by the MQOPEN call that created the permanent dynamic queue, the queue manager checks that the user ID associated with the application that issued the MQCLOSE call is authorized to delete the queue.

On OS/400, UNIX systems, and Windows systems, when a PCF command that operates on a WebSphere MQ object is processed by the command server
This includes the case where a PCF command operates on an authentication information object.

The user ID that is used for the authority checks is the one found in the UserIdentifier field in the message descriptor of the PCF command. This user ID must have the required authorities on the queue manager where the command is processed. The equivalent MQSC command encapsulated within an Escape PCF command is treated in the same way. For more information about the UserIdentifier field and how it is set, see Message context.

On OS/400, when a user issues a CL command in Group 2 that operates on a WebSphere MQ object
This includes the case where a CL command in Group 2 operates on an authentication information object.

Unless the user is a member of the QMQMADM group or has *ALLOBJ authority, checks are performed to determine whether the user has the authority to operate on a WebSphere MQ object associated with the command. The authority required depends on the type of operation that the command performs on the object. For example, the command CHGMQMQ, Change MQM Queue, requires the authority to change the attributes of the queue specified by the command. In contrast, the command DSPMQMQ, Display MQM Queue, requires the authority to display the attributes of the queue specified by the command.

Many commands operate on more than one object. For example, to issue the command DLTMQMQ, Delete MQM Queue, the following authorities are required:

  • The authority to connect to the queue manager specified by the command
  • The authority to delete the queue specified by the command

Some commands operate on no object at all. In this case, the user requires only OS/400 authority to issue one of these commands. STRMQMLSR, Start MQM Listener, is an example of such a command.

 

Alternate user authority

When an application opens an object, the application can supply a user ID on the MQOPEN or MQPUT1 call and ask the queue manager to use this user ID for authority checks instead of the one associated with the application. The application succeeds in opening the object only if both the following conditions are met:

  • The user ID associated with the application has the authority to supply a different user ID for authority checks. The application is said to have alternate user authority.

  • The user ID supplied by the application has the authority to open the object for the types of operation requested.

 

Message context

Message context information allows the application that retrieves a message to find out about the originator of the message. The information is held in fields in the message descriptor and the fields are divided into two categories: identity context and origin context.

The identity context fields contain information about the user of the application that put the message on the queue. The origin context fields contain information about the application itself and when the message was put on the queue.

When an application puts a message on a queue, the application can ask the queue manager to generate the context information in the message. This is the default action. Alternatively, it can specify that the context fields are to contain no information. The user ID associated with an application requires no special authority to do either of these.

An application can set the identity context fields in a message, allowing the queue manager to generate the origin context, or it can set all the context fields. An application can also pass the identity context fields from a message it has retrieved to a message it is putting on a queue, or it can pass all the context fields. However, the user ID associated with an application requires authority to set or pass context information. An application specifies that it intends to set or pass context information when it opens the queue on which it is about to put messages, and its authority is checked at this time.

Here is a brief description of each of the context fields:

Identity context

UserIdentifier
The user ID associated with the application that put the message. If the queue manager sets this field, it is set to the user ID obtained from the operating system when the application connects to the queue manager.

AccountingToken
Information that can be used to charge for the work done as a result of the message.

ApplIdentityData
If the user ID associated with an application has authority to set the identity context fields, or to set all the context fields, the application can set this field to any value related to identity. If the queue manager sets this field, it is set to blank.

Origin context

PutApplType
The type of the application that put the message; a CICS(R) transaction, for example.

PutApplName
The name of the application that put the message.

PutDate
The date when the message was put.

PutTime
The time when the message was put.

ApplOriginData
If the user ID associated with an application has authority to set all the context fields, the application can set this field to any value related to origin. If the queue manager sets this field, it is set to blank.

For a detailed description of each of the context fields, see the WebSphere MQ Application Programming Reference. For more information about how to use message context, see the WebSphere MQ Application Programming Guide.

 

Authority to work with WebSphere MQ objects on UNIX systems and Windows systems

On UNIX systems, and Windows systems, the authorization service provides the access control when an application issues an MQI call to access a WebSphere MQ object that is a queue manager, queue, process, or namelist. This includes checks for alternate user authority and the authority to set or pass context information.

The authorization service also provides authority checks when a PCF command operates on one of these WebSphere MQ objects or an authentication information object. The equivalent MQSC command encapsulated within an Escape PCF command is treated in the same way.

The authorization service is an installable service, which means that it is implemented by one or more installable service components. Each component is invoked using a documented interface. This enables users and vendors to provide components to augment or replace those provided by the WebSphere MQ products.

The authorization service component provided with WebSphere MQ is called the Object Authority Manager (OAM). The OAM is automatically enabled for each queue manager you create.

The OAM maintains an access control list (ACL) for each WebSphere MQ object it is controlling access to. On UNIX systems, only group IDs can appear in an ACL. This means that all members of a group have the same authorities.

On UNIX and Windows systems, the control command setmqaut grants and revokes authorities and is used to maintain the ACLs. For example, the command: 

setmqaut -m JUPITER -t queue -n MOON.EUROPA -g VOYAGER +browse +get

allows the members of the group VOYAGER to browse messages on the queue MOON.EUROPA that is owned by the queue manager JUPITER. It allows the members to get messages from the queue as well.

The command: 

setmqaut -m JUPITER -t queue -n MOON.* -g VOYAGER +put

allows the members of the group VOYAGER to put messages on any queue whose name commences with the characters MOON. . MOON.* is the name of a generic profile. A generic profile allows you to grant authorities for a set of objects using a single setmqaut command. Objects whose names match the profile name do not have to exist when the setmqaut command is issued. Using generic profiles, therefore, allows you to grant authorities for objects that you might create in the future.

The control command dspmqaut is available to display the current authorities that a user or group has for a specified object. The control command dmpmqaut is also available to display the current authorities associated with generic profiles.

If you do not want any authority checks, for example, in a test environment, you can disable the OAM.

 

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.