Setting the message access authorization level

For security considerations, you can use IBM MQ Monitoring Agent to control the level of user access to IBM MQ messages with the MSGACCESS parameter.

Before you begin

If you are unfamiliar with how to change monitoring options for an agent instance, review the steps in Changing monitoring options. If you are unfamiliar with the monitoring options used, review the descriptions of the options in Monitoring options.

About this task

IBM MQ Monitoring Agent can be configured to set message access authorization level when one of the following accounts is used:
  • The Tivoli Enterprise Portal user ID as the account (default setting).
  • The account of the IBM MQ Monitoring Agent.
  • The predefined account.

Do the following steps to set message access authorization level:

Procedure

  1. Open the monitoring file of the agent instance that you want to configure.
  2. Modify the MSGACCESS parameter in the SET MANAGER statement for a queue manager as needed, to specify the message manipulation authorization level.
    If not specified, this setting for the applicable SET GROUP statement is used.
    • If you specify the MSGACCESS parameter as NONE, DESC, RETRY, DATA, or DELETE, the SET QACCESS statement is ignored, and the message manipulation account is the same as the user ID from the user interface.
    • If you specify the value of USEQACCESS on the MSGACCESS parameter, the message manipulation account is defined on the SET QACCESS statement. If you do not specify the SET QACCESS statement, or if the SET QACCESS statement does not accommodate the specified user ID from the user interface for the specified queue name, the user ID from the user interface has the default message manipulation right of NONE; the specified user ID from the user interface cannot perform any message manipulation on the specified queue.
    1. Use the SET QACCESS statement to define multiple rules so that different user IDs from the user interface can have different message manipulation authorization levels. In this case, the message manipulation account can be specified.
      Table 1 shows the outcomes when a user attempts to manipulate a message on a specified queue name. (These outcomes assume that the specified queue name passes the NAME parameter value check that is defined in SET QACCESS statement).
      Table 1. Message manipulation on a specified queue name

      This table shows the rule results (fail or success) of different MSGACCOUNT values depending on whether the Tivoli Enterprise Portal user ID matches the MSGAUTHUSERS value.
      MSGACCOUNT value User ID from the user interface matches the MSGAUTHUSERS parameter value? Rule result Message Manipulation Account
      UIUSER YES SUCCESS User ID from the user interface
      NO FAIL N/A
      MQAGENT YES SUCCESS monitoring agent Account
      NO FAIL N/A
      USER=user-id YES SUCCESS user ID
      NO FAIL N/A
      If the rule result in the above table is FAIL, the given SET QACCESS settings are ignored for the current request, and other SET QACCESS settings are checked. If none apply (all result in FAIL), the resultant access is NONE.
    2. Optional: Use multiple SET QACCESS statements to impose the strictest rules on a particular Tivoli Enterprise Portal user for a particular queue.
      If you issue multiple SET QACCESS commands that specify different manipulation access settings, and more than one of the access settings applies to a given Tivoli Enterprise Portal user, IBM MQ Monitoring Agent assigns the lowest manipulation access to that user. The order of manipulation access settings from lowest to highest is: NONE, DESC, RETRY, DATA, DELETE.
  3. Save your settings.

Example

Note: When you set these message access authorization levels, the key issue is that the agent first finds the best match for User ID for a given queue name, and the best match is used, even if this allows more access. When those matches are equal across multiple SET QACCESS statements, The agent takes the lower access level; however, if the user ID is a better match for one, that user ID will be used. In particular, you can have a DEFAULT(YES) specification for a SET QACCESS statement for NAME MSGAUTHUSERS that provides no access with MSGACCESS(NONE). This will literally match every queue and every user. But as long as the given user matches a more specific statement, that statement will be used.

If you set the monitoring options as follows, the user SYSADMIN potentially has manipulation access to DESC: 

SET GROUP NAME(GROUP1) DEFAULT(YES) COMMAND(YES) MSGACCESS(DATA)
SET MANAGER NAME(QM1) MSGACCESS(USEQACCESS)
SET QACCESS NAME(DEMO*) MSGAUTHUSERS(*) MSGACCOUNT(MQAGENT) MSGACCESS(DELETE)
    MGRNAME(QM1)
SET QACCESS NAME(D*) MSGAUTHUSERS(SYS*) MSGACCOUNT(USER=DEMOUSER) MSGACCESS(DESC)
    MGRNAME(QM1)
SET QACCESS NAME(D*) MSGAUTHUSERS(SYS*) MSGACCOUNT(UIUSER) MSGACCESS(RETRY)
MGRNAME(QM1)

Assume that the Tivoli Enterprise Portal user SYSADMIN wants to manipulate messages on the DEMO.QUEUE1 queue. The first manipulation access that applies to this user is DELETE, and the message manipulation account is the agent account (MQAGENT). However, the manipulation access of DESC also applies to this user, and the message manipulation account is DEMOUSER. IBM MQ Monitoring agent assigns the message manipulation access of DESC to this user, because that is the lowest manipulation access that applies. If this Tivoli Enterprise Portal user attempts to delete a message, the following message is displayed: (KMQW008E) Not allowed By MSGACCESS. The IBM MQ Monitoring agent prevents the user from deleting the message. If this user attempts to display message descriptors, the agent will allow it, but the request will still have to pass through queue manager security settings, and in this case the user ID DEMOUSER will be passed as the alternate user ID, and must have access to browse messages on the queue.