The channel initiator

If you are using resource security, you should consider the following if you are using distributed queuing:

System queues

The channel initiator address space needs RACF UPDATE access to these system queues:

  • SYSTEM.ADMIN.CHANNEL.EVENT

  • SYSTEM.CHANNEL.INITQ

  • SYSTEM.CHANNEL.SYNCQ

  • SYSTEM.COMMAND.INPUT

  • SYSTEM.COMMAND.REPLY.MODEL

  • SYSTEM.QSG.CHANNEL.SYNCQ

  • SYSTEM.QSG.TRANSMIT.QUEUE

and to all the user destination queues and the dead-letter queue (but see Dead-letter queue security).

Transmission queues

The channel initiator address space needs ALTER access to all the user transmission queues.

Context security

The channel user ID (and the MCA user ID if one has been specified) also need RACF CONTROL access to the hlq.CONTEXT.queuename profiles in the MQADMIN class. Depending on the RESLEVEL profile, the network-received user ID might also need CONTROL access to these profiles. See Profiles for context security RESLEVEL and channel initiator connections and User IDs for security checking for more information.

CSQINPX

If you are using the CSQINPX input data set, the channel initiator also needs READ access to CSQINPX, and UPDATE access to data set CSQOUTX and dynamic queues SYSTEM.CSQXCMD.*.

Connection security

The channel initiator address space connection requests use a connection type of CHIN, for which appropriate access security must be set, see Connection security profiles for the channel initiator.

Data sets

The channel initiator address space needs appropriate access to queue manager data sets, see Authorizing access to data sets.

Commands

The distributed queuing commands (for example, DEFINE CHANNEL, START CHINIT, START LISTENER, and so on) should have appropriate command security set, see Table 48.

If you are using a queue-sharing group, the channel initiator might issue various commands internally, so the user ID it uses must be authorized to issue such commands. These commands are START and STOP CHANNEL for every channel used with CHLDISP(SHARED).

Channel security

Channels, particularly receivers and server-connections, need appropriate security to be set up; see User IDs for security checking for more information.

We can also use the Secure Sockets Layer (SSL) protocol to provide security on channels. See theWebSphere MQ Security book for a detailed description of SSL.

See also the WebSphere MQ Clients manual for information about server-connection security.

User IDs

The user IDs described in User IDs used by the channel initiator and User IDs used by the intra-group queuing agent need the following:

  • RACF UPDATE access to the appropriate destination queues and the dead-letter queue

  • RACF CONTROL access to the

    hlq.CONTEXT.queuename profile if context checking is performed at the receiver

  • Appropriate access to the hlq.ALTERNATE.USER.userid profiles they might need to use.

  • For clients, the appropriate RACF access to the resources to be used.

APPC security

Set appropriate APPC security if you are using the LU 6.2 transmission protocol. (Use the APPCLU RACF class for example.) For information about setting up security for APPC, see the following manuals:

  • z/OS V1R2.0 MVS Planning: APPC Management

  • Multiplatform APPC Configuration Guide (redbook)

Outbound transmissions use the "SECURITY(SAME)" APPC option. This means that the user ID of the channel initiator address space and its default profile (RACF GROUP) are flowed across the network to the receiver with an indicator that the user ID has already been verified (ALREADYV).

If the receiving side is also z/OS, the user ID and profile are verified by APPC and the user ID is presented to the receiver channel and used as the channel user ID.

In an environment where the queue manager is using APPC to communicate with another queue manager on the same or another z/OS system, we need to ensure that either:

  • The VTAM definition for the communicating LU specifies SETACPT(ALREADYV)

  • There is a RACF APPCLU profile for the connection between LUs that specifies CONVSEC(ALREADYV)

Changing security settings

If the RACF access level that either the channel user ID or MCA user ID has to a destination queue is changed, this change will only take effect for new object handles (that is, new MQOPENs) for the destination queue. The times when MCAs open and close queues is variable; if a channel is already running when such an access change is made, the MCA can continue to put messages on the destination queue using the existing security access of the user ID(s) rather than the updated security access. To avoid this, you should stop and restart the channels to enforce the updated access level.

Automatic restart

If you are using the z/OS Automatic Restart Manager (ARM) to restart the channel initiator, the user ID associated with the XCFAS address space must be authorized to issue the WebSphere MQ START CHINIT command.