Choose between three modes of checking when an application puts messages to remote cluster queues. The modes are checking remotely against the cluster queue, checking locally against SYSTEM.CLUSTER.TRANSMIT.QUEUE, or checking against local profiles for the cluster queue, or cluster queue manager.
IBM® WebSphere® MQ gives you the choice of checking locally, or locally and remotely, that a user has permission to put a message to a remote queue. A typical IBM WebSphere MQ application uses local checking only, and relies on the remote queue manager trusting the access checks made on the local queue manager. If remote checking is not used, the message is put to the target queue with the authority of the remote message channel process. To use remote checking you must set the put authority of the receiving channel to context security.
The local checks are made against the queue that the application opens. In distributed queueing, the application usually opens a remote queue definition, and access checks are made against the remote queue definition. If the message is put with a full routing header, the checks are made against the transmission queue. If an application opens a cluster queue that is not on the local queue manager, there is no local object to check. The access control checks are made against the cluster transmission queue, SYSTEM.CLUSTER.TRANSMIT.QUEUE. Even with multiple cluster transmission queues, from Version 7.5, local access control checks for remote cluster queues are made against SYSTEM.CLUSTER.TRANSMIT.QUEUE.
The choice of local or remote checking is a choice between two extremes. Checking remotely is fine-grained. Every user must have an access control profile on every queue manager in the cluster to put to any cluster queue. Checking locally is coarse-grained. Every user needs only one access control profile for the cluster transmission queue on the queue manager they are connected to. With that profile, they can put a message to any cluster queue on any queue manager in any cluster.
Since Version 7.1, administrators have another way to set up access control for cluster queues. You can create a security profile for a cluster queue on any queue manager in the cluster using the setmqaut command. The profile takes affect if you open a remote cluster queue locally, specifying only the queue name. You can also set up a profile for a remote queue manager. If you do so, the queue manager can check the profile of a user that opens a cluster queue by providing a fully qualified name.
The new profiles work only if you change the queue manager stanza, ClusterQueueAccessControl to RQMName. The default is Xmitq. You must create profiles for all the cluster queues existing applications use cluster queues. If you change the stanza to RQMName without creating profiles the applications are likely to fail.
ClusterQueueAccessControl usage and its implications
From MQ 7.1 onwards, there is a new option made available for the users who can access cluster queue even though they do not have access to SYSTEM.CLUSTER.TRANSMIT.QUEUE. This is made possible with the introduction of ClusterQueueAccessControl attribute in the Security stanza of the qm.ini file.
The ClusterQueueAccessControl attribute takes two values, Xmitq or RQMName. The default value is Xmitq and the behavior is same as seen in previous versions where the access to remote cluster queues gets resolved to the access of the SYSTEM.CLUSTER.TRANSMIT.QUEUE. By setting the ClusterQueueAccessControl to RQMName, the profiles of remote cluster queues will be resolved to locally defined profiles of named queues or named queue manager.
Consider two Qmgrs QM1 & QM2 are part of cluster CLUS1
Create a queue on QM2 and make it part of cluster CLUS1.
DEFINE QL(MYQ) CLUSTER(CLUS1)
A user who is part of a group called dev_group connects to Qmgr QM1 and wants to put a message to the cluster queue MYQ. By either creating a local named queue profile and giving the user put access on it or by creating a local named queue manager profile and then giving it the required access, the user will be able to put message to the remote cluster queue even though he does not have access over SYSTEM.CLUSTER.TRANSMIT.QUEUE.
1. By creating queue profile :
setmqaut -m QM1 -t queue -n MYQ -g dev_group +putamqsput MYQ QM1
2. By creating queue manager profile :
setmqaut -m QM1 -t rqmname -n QM2 -g dev_group +putamqsput MYQ QM1 8208 0 QM2
qm.ini:
Security: ClusterQueueAccessControl=RQMName
