| Author |
Message
|
| fde |
 Posted: Tue Jul 20, 2010 6:38 am Post subject: OAM settings for cluster queues |
 |
|
Acolyte
Joined: 05 Jul 2007
Posts: 65
|
Hello,
we want to use OAM settings to restrict access to clusterqueues on MQ V6.0.
On QM1 we set up two clusterqueues Q1 and Q2.
Q1 has OAM settings on QM1 to allow user U1 to access this queue.
Q2 has no OAM settings.
On QM2, which is member of the same cluster as QM1, the user U1 wants to put messages on both clusterqueues.
U1 has +inq and +connect for QM2 and +put for the transmissionqueue to QM1.
Using this setup user U1 is able to put on both clusterqueues, although one of them has no OAM settings for U1.
Since OAM forbids access to the queue, I wonder why this is possible.
Is there no OAM check on the target queuemanager?
Or maybe there is an OAM check, but the userID to check is one (mqm?) which has global access?
One possibility to deal with this (MQV6 Clustering.pdf, chapter  is to create alias queues with matching OAM settings on QM2. Since the alias queues would be local, local OAMs would do the trick in this case.
Since this involves more artefacts to manage, we would prefer not to create additional alias queues.
During my research I encountered the PUTAUT attribut, but since I dont fully understand the OAM mechanism after the first local check, I am not sure if this could help.
_________________
Global warming is an unintentional side effect of SOA's hotness.
-- http://soafacts.com/
a business integration methodology |
|
| Back to top |
|
 |
| garyprmr |
| Posted: Tue Jul 20, 2010 6:42 am Post subject: |
|
|
Acolyte
Joined: 03 Sep 2005
Posts: 74
|
+put for the transmissionqueue to QM1.
Is application is putting directly to the XMITQ ? |
|
| Back to top |
|
|
| WBI_User21 |
| Posted: Tue Jul 20, 2010 6:49 am Post subject: |
|
|
Voyager
Joined: 12 Jun 2007
Posts: 98
|
| transmissionqueue would be SYSTEM.CLUSTER.TRANSMIT.QUEUE in case of clusters . |
|
| Back to top |
|
|
| fde |
| Posted: Tue Jul 20, 2010 6:52 am Post subject: |
|
|
Acolyte
Joined: 05 Jul 2007
Posts: 65
|
Hello,
the application connects to QM2 and is putting on the clusterqueue on QM1.
And yes, we gave +put on the transmissionqueue.
Without the +put, the application was not able to put on both queues.
_________________
Global warming is an unintentional side effect of SOA's hotness.
-- http://soafacts.com/
a business integration methodology |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jul 20, 2010 7:06 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| fde wrote: |
| ...we gave +put on the transmission queue... |
To paraphrase a large, well known organisation - where do you want to go in the cluster today? If you give an application the ability you have, it can put to any discoverable cluster resource, or, if the application specifies a queue manager name, and puts a message of the correct format, to the SYSTEM.ADMIN.COMMAND.QUEUE of the named queue manager shall we say...?
Clusters are not necessarily about reducing the number of objects to manage 
_________________
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 |
|
|
| zpat |
| Posted: Tue Jul 20, 2010 7:11 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I've never granted applications access to transmit queues directly.
Access to the remote queue is sufficient and protects the xmit queue (which after all may contain messages from other applications). |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Jul 20, 2010 4:07 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| zpat wrote: |
I've never granted applications access to transmit queues directly.
Access to the remote queue is sufficient and protects the xmit queue (which after all may contain messages from other applications). |
Or access to a local qalias of a clustered queue....
_________________
Glenn |
|
| Back to top |
|
|
| fde |
| Posted: Wed Jul 21, 2010 1:55 am Post subject: |
|
|
Acolyte
Joined: 05 Jul 2007
Posts: 65
|
Hello,
thank you for your answers.
So far I understand that it is a bad idea to grant access to a transmissionqueue directly.
Using aliasqueues for the clustered queues seem to be a good solution.
In that case we need alias queues only on queuemanagers from which the queues should be accessed and only for those clusterqueues which should be accessed. The number of additional artifacts is ok.
I still wonder, why OAM does not check on the target queue. For example, if i grant access to an alias queue which points to a clustered queue. The OAM settings of the target clusterqueue seem to be irrelevant.
Isn't that a security issue? Since gaining controll of a queuemanager in a cluster would grant full controll on the clusterobjects regardless of their OAM settings.
_________________
Global warming is an unintentional side effect of SOA's hotness.
-- http://soafacts.com/
a business integration methodology |
|
| Back to top |
|
|
|
|
