| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| How can I control security within a single cluster? |
« View previous topic :: View next topic » |
| Author |
Message
|
| shashivarungupta |
 Posted: Wed Sep 02, 2009 8:01 am Post subject: |
 |
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| Sam Uppu wrote: |
| .........What if we dont use the Capitalware's security exit?. |
There are certain standards(AFA MQ is concerned) that are being followed in the frameworks/products unanimously... and you can fetch those out of the manual easily. 
You can't implement capitalware security exit (even if you want..) until you are given some Licenses to use that product. 
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed Sep 02, 2009 8:19 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
Back to the original post:
The benefit of clusters is that cluster definitions are shared automatically to qmgrs throughout the cluster. The downside of clusters is exactly the same.
| Quote: |
Let me make it more clear.
I have three queue managers QM1 ,QM2 and QM3 in a cluster MQSERIES.
Now i define a cluster queue QM1.CLQ on QM1 , but I DO NOT want QM2 to access or even see QM1.CLQ , but QM3 should.
Is there anyway to do this? |
Creating a second overlapping (or is it underlapping?) cluster that excludes QM2 should do the trick. But, I suspect that you have other objects that you want QM2 to access. You will need to move those definitions to the new underlapping cluster.
Or am I once again completely misunderstanding the issue...
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Sep 02, 2009 8:35 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| bruce2359 wrote: |
Back to the original post:
.
.
.
Or am I once again completely misunderstanding the issue... |
I think what the poster is after is 'hiding' certain cluster queues from particular queue managers within the cluster, e.g. a queue on QM2 can be 'seen' by QM1, but not by QM2, but still wants all queue managers to be within the same cluster.
_________________
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 |
|
|
| sumit |
| Posted: Wed Sep 02, 2009 8:37 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| Quote: |
| ..but I DO NOT want QM2 to access or even see QM1.CLQ... |
Don't access the queue QM1.CLQ from QM2 and QM2 won't see it.
It's actually not the queue manager which will automatically put (if can see) the message in a queue. It's the responsibility of the application to direct message to a target queue. Use an alias queue for your application and direct messages to it. Use whatever suitable destq you want.
But if you strictly don't want to see the queue from QM2, use overlapped clusters, as bruce2359 and fjb_saper suggested.
_________________
Regards
Sumit |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Wed Sep 02, 2009 8:43 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
Hard time to paste the image of what I have drawn based on the prob. definition. (sry abt that).
Anyways..
I think.. It was like...
QM1 . got the local Q.
QM2. Dont have access to that local Q.
QM3. Has the access to the local Q. of QM1.
All are in the cluster.
* Local Q. on QM1 is clustered.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Sep 02, 2009 9:07 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
Where did the requirement come from that a qname be unknown. An auditor?
There is a vast difference between knowing the name of an object, and being able to use it.
Is the queue name obscene? Is the name something that violates copyright or other laws? Or is it named in such a way that its discovery would put your organization at risk? Like, DEF QL(A_MSG_PUT_HERE_WILL_WILL_SEND_YOU_ONE_MILLION_DOLLARS).
The usual way to keep a qmgr from learning of a definition from the cluster is to take the qmgr out of the cluster that has the definition.
If the actual name isn't a secret, then an in-elegant solution would be to create a non-clustered local definition of the queue with the same name, but put- and get-disable it. Or create a non-clustered alias with no target queue. Either way, the application will fail; but the real clustered queue will not be discovered.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 02, 2009 10:55 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| Where did the requirement come from that a qname be unknown. An auditor? |
The poster has a history of a) odd requirements b) seeing things in the documentation the rest of us can't find & c) believing the best way to use software is to use it differently to how it's intended. A cluster queue which can't be seen in the cluster is a prime example.
I shudder to think what business his client is in.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Sep 02, 2009 12:41 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| A cluster queue which can't be seen in the cluster is a prime example. |
Overlapping or intersecting clusters, both of which are well-documented (with pictures) in the WMQ Clusters manual, are tried and true methods of isolating clustered object definitions - they are available (visible) to qmgrs in the cluster, but not available (invisible) to qmgrs outside the cluster.
No argument about the odd posts. But they do stretch my gray-matter - what's left of it.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Sep 02, 2009 4:07 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Another possibility is to define a QALIAS object on QM2 and set OAM authorities so that it can't be accessed.
_________________
Glenn |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Sep 02, 2009 5:10 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| gbaddeley wrote: |
| Another possibility is to define a QALIAS object on QM2 and set OAM authorities so that it can't be accessed. |
Thank you! Finally, the correct solution. 
Who cares if QM1 can "see" the cluster queues on QM2? Guess what, QMs don't have eyes so they can't see anything.
QM1, QM2, QM3 are all in the same cluster.
It does not matter which if any are Full Repositories.
QM1 has clustered QUEUE1.
QM2 has clustered QUEUE2.
QM3 has clustered QUEUE3.
You need an app connected to QM3 to be able to put to QUEUE1? Then create a queue alias on QM3 called QUEUE1.ALIAS.ON.QM3, grant the application user ID access only to that one queue, and you are done. They can't "see" QUEUE1, QUEUE2, QUEUE3 or any other queue in the cluster.
"see" = use.
Is it a lot of alias definitions? Is it a lot of setmqaut commands? Yes, but no one ever said security was easy.
You will still want to use SSL and/or MQ Exits for other reasons on the channels.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Sep 02, 2009 5:17 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
Another possibility is to define a QALIAS object on QM2 and set OAM authorities so that it can't be accessed.
Thank you! Finally, the correct solution. |
I'll go as far as saying it's a good one-time, one-object 'correct solution;' but managing many (dozens, hundreds) of objects will be tedious. And if this is the pattern for managing other qmgrs in the cluster, then more and more tedious.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Sep 02, 2009 5:28 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| bruce2359 wrote: |
| Quote: |
Another possibility is to define a QALIAS object on QM2 and set OAM authorities so that it can't be accessed.
Thank you! Finally, the correct solution. |
I'll go as far as saying it's a good one-time, one-object 'correct solution;' but managing many (dozens, hundreds) of objects will be tedious. And if this is the pattern for managing other qmgrs in the cluster, then more and more tedious. |
More tedious than creating dozens or hunderds of overlapping clusters?
If you have 100 queues and need some apps to see 50 of them and other apps to only see the other 50, but any app can see all of its 50, then yes, overlapping or stacked clusters is easier. I read the requirement as keeping every queue "invisible" from every other app other than the one that needed to use it, probably a more typical requirement. If that's the case I don't think overlapping clusters is feasible and Alias queues + setmqaut, as tedious as they are, are easier.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Sep 02, 2009 5:48 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
Agreed. I'm pondering why someone would implement an application (that MQOPENs a queue) on a qmgr where the queue isn't? But I'm sure that will come up in a future post...
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Monk |
| Posted: Wed Sep 02, 2009 9:11 pm Post subject: |
|
|
Master
Joined: 21 Apr 2007
Posts: 282
|
Wow 
thanks for discussion, I will now have to convince my architect of some viable solution.
and btw exerk, it is not me who want this kind of requirements, but the people above me , sometimes its hard to explain them to use MQ the way its meant to be , rather than how they want to use it.
They think MQ is some kind of programming language or something and you can do whatever you want with it.
They need to learn to work within the boundaries of what MQ provides.
I may be wrong, but i blame the IBM marketing and client management for this.
Anyways thank you all for the discussion on this.
Much appreciated. 
_________________
Thimk |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Sep 02, 2009 10:26 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Monk wrote: |
| ...thanks for discussion, I will now have to convince my architect of some viable solution. |
If your architect is not WMQ-aware then perhaps the Solution Designer certification is the way to go, or for someone in your team to to become certified, and work with the architect. If all else fails, use a baseball bat! 
| Monk wrote: |
...and btw exerk, it is not me who want this kind of requirements, but the people above me , sometimes its hard to explain them to use MQ the way its meant to be , rather than how they want to use it.
They think MQ is some kind of programming language or something and you can do whatever you want with it.
They need to learn to work within the boundaries of what MQ provides. |
Been there, seen it, done it, and got the T-shirt. All you can hope for is to effect a culture change, and fight your corner.
| Monk wrote: |
| ...I may be wrong, but i blame the IBM marketing and client management for this. |
Marketing people have a different focus - they want to sell the product, and they may not be as technically aware as those at the coal-face using/configuring it.
What I try to explain is that a WMQ solution begins, and ends, with an application, that it is not just a piece of CAT 5 cable, and that while a customer may pay for my expertise (they haven't rumbled me yet  ), they are not obligated to use it.
_________________
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 |
|
|
|
|
|
|
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
|
|
|
|
