Channel authorization

When you send or receive a message through a channel, we need to provide access to various IBM MQ resources. Message Channel Agents (MCAs) are essentially IBM MQ applications that move messages between queue managers, and as such require access to various IBM MQ resources to operate correctly.

To receive messages at PUT time for MCAs, we can use either the user ID associated with the MCA, or the user ID associated with the message.

At CONNECT time we can map the asserted user ID to an alternative user, by using CHLAUTH channel authentication records.

In IBM MQ, channels can be protected by TLS support.

The user IDs associated with sending and receiving channels, excluding the sender channel where the MCAUSER attribute is unused, require access to the following resources:

  • The user ID associated with a sending channel requires access to the queue manager, the transmission queue, the dead-letter queue, and access to any other resources that are required by channel exits.
  • The MCAUSER user ID of a receiver channel needs +setall authority. The reason is that the receiver channel has to create the full MQMD, including all context fields, using the data it received from the remote sender channel. The queue manager therefore requires that the user performing this activity has the +setall authority. This +setall authority must be granted to the user for:

  • The MCAUSER user ID of a receiver channel where the originator requested a COA report message needs +passid authority on the transmission queue that returns the report message. Without this authority, AMQ8077 error messages are logged.
  • With the user ID associated with the receiving channel, we can open the target queues to put messages onto the queues. This involves the Message queuing Interface (MQI), so additional access control checks might need to be made if we are not using the IBM MQ Object Authority Manager (OAM). We can specify whether the authorization checks are made against the user ID associated with the MCA (as described in this topic), or against the user ID associated with the message (from the MQMD UserIdentifier field). For the channel types to which it applies, the PUTAUT parameter of a channel definition specifies which user ID is used for these checks.

    • The channel defaults to using the queue manager's service account, which has full administrative rights and requires no special authorizations.
    • In the case of server-connection channels, administrative connections are blocked by default by CHLAUTH rules and require explicit provisioning.
    • Channels of type receiver, requester, and cluster-receiver allow local administration by any adjacent queue manager, unless the administrator takes steps to restrict this access.
    • It is not necessary to grant dsp and ctrlx authority for the MCAUSER user ID of a receiver channel.
    • Before Version 8.0.0, Fix Pack 4, if we use a user ID that lacks IBM MQ administrative privileges, then we must grant dsp and ctrlx authority for the channel to that user ID for the channel to work.

      From Version 8.0.0, Fix Pack 4, there are no authority checks when a channel resynchronizes itself and corrects sequence numbers.

      However, issuing a RESET CHANNEL command manually does still require +dsp and +ctrlx at all releases.

      Attention: When a channel reset is needed for message batch confirmation, IBM MQ attempts to query the channel, which does require +dsp authority.
    • The MCAUSER attribute is unused for the SDR channel type.
    • If we use the user ID associated with the message, it is likely that the user ID is from a remote system. This remote system user ID must be recognized by the target system. The following commands are examples of the type of command that we can issue to grant authority to a user ID from a remote system: 

      • setmqaut -m QMgrName -t qmgr -g GroupName +connect +inq +setall 

      • setmqaut -m QMgrName -t chl -n Profile -g GroupName +dsp +ctrlx
        where Profile is a channel. 
      • setmqaut -m QMgrName -t q -n Profile -g GroupName +put +setall
        where Profile is a dead-letter queue, if set. 
      • setmqaut -m QMgrName -t q -n Profile -g GroupName +put +setall
        where Profile is a list of authorized queues.

      Attention: Exercise caution when authorizing a user ID to place messages onto the Command Queue or other sensitive system queues.

The user ID associated with the MCA depends on the type of MCA. There are two types of MCA:

    Caller MCA
    MCAs that initiate a channel. Caller MCAs can be started as individual processes, as threads of the channel initiator, or as threads of a process pool. The user ID used is the user ID associated with the parent process (the channel initiator), or the user ID associated with the process that starts the MCA.

    Responder MCA
    Responder MCAs are MCAs that are started as a result of a request by a caller MCA. Responder MCAs can be started as individual processes, as threads of the listener, or as threads of a process pool. The user ID can be any one of the following types (in this order of preference):
    1. On APPC, the caller MCA can indicate the user ID to be used for the responder MCA. This is called the network user ID and applies only to channels started as individual processes. Set the network user ID by using the USERID parameter of the channel definition.
    2. If the USERID parameter is not used, the channel definition of the responder MCA can specify the user ID that the MCA must use. Set the user ID by using the MCAUSER parameter of the channel definition.
    3. If the user ID has not been set by either of the previous (two) methods, the user ID of the process that starts the MCA or the user ID of the parent process (the listener) is used.

Parent topic: Plan security by topology


Related concepts


Related information