Authority to work with IBM MQ objects on IBM i , UNIX, Linux, and Windows systems

The authorization service component provided with IBM® MQ is called the object authority manager (OAM). It provides access control via authentication and authorization checks.

Authentication.

The authentication check performed by the OAM provided with IBM MQ is basic, and is only performed in specific circumstances. It is not intended to meet the strict requirements expected in a highly secure environment.

The OAM performs its authentication check when an application connects to a queue manager, and the following conditions are true:

• If an MQCSP structure has been supplied by the connecting application, and
• The AuthenticationType attribute in the MQCSP structure is given the value MQCSP_AUTH_USER_ID_AND_PWD, and
• The CHCKLOCL or CHKCCLNT value on the configured AUTHINFO object is not 'NONE'

The authentication steps in the OAM validate the password using operating system services, which might have been configured to perform additional checks, such as ensuring the username has not had too many incorrect password test attempts.

It is possible for alternative authentication mechanisms to be used if you write a new authorization service component, or obtain one from a vendor.

Authorization.

The authorization checks are comprehensive, and are intended to meet most normal requirements.

Authorization checks are performed when an application issues an MQI call to access a queue manager, queue, process, topic, or namelist. They are also performed at other times, for example, when a command is being performed by the Command Server.

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

On Windows , the OAM gives members of the Administrators group the authority to access all IBM MQ objects, even when UAC is enabled. Additionally, on Windows systems, the SYSTEM account has full access to IBM MQ resources.

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

On IBM i , unless the user is a member of the QMQMADM group or has *ALLOBJ authority, the authorization service also provides authority checks when a user issues a CL command in Group 2 that operates on any of these IBM MQ objects or an authentication information object.

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 IBM MQ products.

The authorization service component provided with IBM 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 IBM MQ object it is controlling access to. On UNIX and Linux systems, only group IDs can appear in an ACL. This means that all members of a group have the same authorities. On IBM i and on Windows systems, both user IDs and group IDs can appear in an ACL. This means that authorities can be granted to individual users and groups.

A 12 character limitation applies to both the group and the user ID. UNIX platforms generally restrict the length of a user ID to 12 characters. AIX® and Linux have raised this limit but IBM MQ continues to observe a 12 character restriction on all UNIX platforms. If you use a user ID of greater than 12 characters, IBM MQ replaces it with the value UNKNOWN. Do not define a user ID with a value of UNKNOWN.

The OAM can authenticate a user and change appropriate identity context fields. You enable this by specifying a connection security parameters structure (MQCSP) on an MQCONNX call. The structure is passed to the OAM Authenticate User function (MQZ_AUTHENTICATE_USER), which sets appropriate identity context fields. If an MQCONNX connection from an IBM MQ client, the information in the MQCSP is flowed to the queue manager to which the client is connecting over the client-connection and server-connection channel. If security exits are defined on that channel, the MQCSP is passed into each security exit and can be altered by the exit. Security exits can also create the MQCSP. For more details of the use of security exits in this context, see Channel security exit programs.

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

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

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

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.

On IBM i, an administrator uses the CL command GRTMQMAUT to grant authorities and the CL command RVKMQMAUT to revoke authorities. Generic profiles can be used as well. For example, the CL command:

GRTMQMAUT MQMNAME(JUPITER) OBJTYPE(*Q) OBJ('MOON.*') USER(VOYAGER) AUT(*PUT)

provides the same function as the previous example of a setmqaut command; it allows the members of the group VOYAGER to put messages on any queue with a name that commences with the characters MOON.

The CL command DSPMQMAUT displays the current authorities that user or group has for a specified object. The CL commands WRKMQMAUT and WRKMQMAUTD are also available to work with the current authorities associated with objects and generic profiles.

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