| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| cluster doubt |
« View previous topic :: View next topic » |
| Author |
Message
|
| dev135 |
 Posted: Thu Aug 27, 2009 3:59 pm Post subject: cluster doubt |
 |
|
Apprentice
Joined: 21 Oct 2008
Posts: 44
|
Hi,
I am having an alias queue on QMGR1 having targq which is cluster local queue on QMGR2.
Note: QMGR1 and QMGR2 are in same cluster on different servers.
I had given put authorities for the alias queue on QMGR1 for a user id and not given any permissions on QMGR2.Now if i put a message using alias queue on QMGR1 its landing on QMGR2 (its target cluster local queue) . Even though i had not given permissions to the queue on QMGR2 for that user id , why its not throwing me not authorized error.
i know that authorization is taking place at the time of opening an object, but without giving any authorization on the queue of QMGR2, its putting the message.
Thanks,
SD. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu Aug 27, 2009 8:13 pm Post subject: Re: cluster doubt |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| dev135 wrote: |
Hi,
I am having an alias queue on QMGR1 having targq which is cluster local queue on QMGR2.
Note: QMGR1 and QMGR2 are in same cluster on different servers.
I had given put authorities for the alias queue on QMGR1 for a user id and not given any permissions on QMGR2.Now if i put a message using alias queue on QMGR1 its landing on QMGR2 (its target cluster local queue) . Even though i had not given permissions to the queue on QMGR2 for that user id , why its not throwing me not authorized error.
i know that authorization is taking place at the time of opening an object, but without giving any authorization on the queue of QMGR2, its putting the message.
Thanks,
SD. |
Well you gave authorization on QM1 for the alias queue. So the user is allowed to put. The destination resolution happens under the qmgr's authority. The channel agent which is running either as the mcauser or with the authority of the process of the channel initiator has all necessary permission to put the message to the queue.
Working as designed.  
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jeevan |
| Posted: Thu Aug 27, 2009 10:49 pm Post subject: Re: cluster doubt |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| fjb_saper wrote: |
| dev135 wrote: |
Hi,
I am having an alias queue on QMGR1 having targq which is cluster local queue on QMGR2.
Note: QMGR1 and QMGR2 are in same cluster on different servers.
I had given put authorities for the alias queue on QMGR1 for a user id and not given any permissions on QMGR2.Now if i put a message using alias queue on QMGR1 its landing on QMGR2 (its target cluster local queue) . Even though i had not given permissions to the queue on QMGR2 for that user id , why its not throwing me not authorized error.
i know that authorization is taking place at the time of opening an object, but without giving any authorization on the queue of QMGR2, its putting the message.
Thanks,
SD. |
Well you gave authorization on QM1 for the alias queue. So the user is allowed to put. The destination resolution happens under the qmgr's authority. The channel agent which is running either as the mcauser or with the authority of the process of the channel initiator has all necessary permission to put the message to the queue.
Working as designed. |
Our design is slightly different. The client connects to the qmgr1, and puts message to a cluster queue which resides on qmgr2 sitting on the different server. However, we need to authorise the cluster transmit queue as well. Why? would not authorisation to the cluster queue be enough according to you?
thanks for your comments |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Aug 28, 2009 12:16 am Post subject: Re: cluster doubt |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| jeevan wrote: |
Our design is slightly different. The client connects to the qmgr1, and puts message to a cluster queue which resides on qmgr2 sitting on the different server. However, we need to authorise the cluster transmit queue as well. Why? would not authorisation to the cluster queue be enough according to you?
thanks for your comments |
Your client ID is authorised to QMGR1, and any necessary objects, but that ID is not authorised to QMGR2 and any of its objects, which is why you have to authorise to the S.C.T.Q - it's the only 'destination' for the message to be put once the target queue has been resolved.
Try authorising the clustered queue, which is in another queue manager, and the queue manager knows it exists somewhere but that somewhere is not locally, therefore it cannot apply OAM to it.
Some sites cluster the local queue and set QA's in other queue managers to refer to them, others use clustered QA's in each queue manager that refer to non-clustered QL's in those same queue managers, but that again means that each application has to be authorised to the S.C.T.Q.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 28, 2009 3:03 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
There are complicated ways you can ensure that the id used on QMGR1 is also checked on QMGR2, when the message is processed by the MCA on QMGR2. They end up causing many more problems than the value received.
The Best Practice for Security in MQ Clusters is to create explicit aliases for all queues on any qmgr that has users connected to it, and provide explicit permissions to those explicit aliases.
It is also Best Practice to NEVER authorize the S.C.T.Q to application users, and to set an MCAUSER on *all* CLUSRCVRs. This prevents remote, anonymous, administration of your queue managers through the cluster channels (client apps can still administer remotely). |
|
| Back to top |
|
|
| jeevan |
| Posted: Fri Aug 28, 2009 6:19 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| mqjeff wrote: |
There are complicated ways you can ensure that the id used on QMGR1 is also checked on QMGR2, when the message is processed by the MCA on QMGR2. They end up causing many more problems than the value received.
The Best Practice for Security in MQ Clusters is to create explicit aliases for all queues on any qmgr that has users connected to it, and provide explicit permissions to those explicit aliases.
It is also Best Practice to NEVER authorize the S.C.T.Q to application users, and to set an MCAUSER on *all* CLUSRCVRs. This prevents remote, anonymous, administration of your queue managers through the cluster channels (client apps can still administer remotely). |
Our scenario is mixed. We have alias queue created for all sdr/rcvr communication. As our prod topology consists MF and non cluster queue manager for spcecial requiement such as credit auth. these arre connected to via sdr/rcvr connection. In this case, we have alias queue to remotequeue, to the destination queue.
but in case of cluster, app directly put message into them, but I am thinkng to change it making all the app connect to alias queue only.
Thanks for sharing |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
