| Author |
Message
|
| Umarul Farooq |
 Posted: Mon Mar 05, 2012 7:40 pm Post subject: Restrict to access Queues under same Queue Manager |
 |
|
Novice
Joined: 15 Jan 2012
Posts: 14
|
Hi All,
We have defined one queue manager which is having two queues (ex. Q.A and Q.B) these two queues are going to get messages from two different applications.
How to restrict the access/visibility of the queues from other applications.
We need 'Application A' to have access only Q.A and 'Application B' should have only Q.B
Could you please suggest how to restrcit it ? |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Mar 05, 2012 7:48 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Presuming that you are UNIX/Windows, look at the setmqaut control command for granting authority. The InfoCenter and WMQ System Administration manual are excellent sources of information.
_________________
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 |
|
|
| Umarul Farooq |
| Posted: Fri Mar 09, 2012 10:47 pm Post subject: |
|
|
Novice
Joined: 15 Jan 2012
Posts: 14
|
Thank you Bruce..
Both Application.A and Application.B are ran by same user (it is the batch process running by same user).
If it is same user, How could restrict the accessability of queues.
Thanking you. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Mar 09, 2012 11:37 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
It's the user on the queue manager that matters.
Does the application connect directly (bindings mode) or over a client channel to the QM? |
|
| Back to top |
|
|
| exerk |
| Posted: Sat Mar 10, 2012 6:35 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Umarul Farooq wrote: |
Thank you Bruce..
Both Application.A and Application.B are ran by same user (it is the batch process running by same user).
If it is same user, How could restrict the accessability of queues.
Thanking you. |
A roundabout way of doing it would be to create two groups, each including the same user, and set authorities on the queue manager and each queue pertinent to the group, e.g. Application A group has the relevant authorities to connect to the queue manager and for Application A queue. Even though the same user is firing off both applications the applications themselves are restricted by the authorities set.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Sat Mar 10, 2012 11:21 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| exerk wrote: |
| Umarul Farooq wrote: |
Thank you Bruce..
Both Application.A and Application.B are ran by same user (it is the batch process running by same user).
If it is same user, How could restrict the accessability of queues.
Thanking you. |
A roundabout way of doing it would be to create two groups, each including the same user, and set authorities on the queue manager and each queue pertinent to the group, e.g. Application A group has the relevant authorities to connect to the queue manager and for Application A queue. Even though the same user is firing off both applications the applications themselves are restricted by the authorities set. |
I don't see how that would help.
MQ Authorities are based on what permissions a User ID has, which more than likely is actually set at the user's group level.
If 1, 2 or 1,000 different applications connect to the QM using that same ID, all will have the exact same authorities to all the same exact queues.
If App A and App B are connecting in client mode to the QM, then you can give each a separate client channel, tag each with a unique MCAUSER value that does not have to be related to the actually ID that App A and B really run with on their end, and then protect each channel with SSL or a security exit like MQAUSX. If you can insure the credentials used by App A to authenticate over its channel will never be shared with App B, then you have accomplished your mission.
App A running under MyID connects over CHANNEL.A, and is seen to the QM as UserA (because of the MCAUSER value), and only has access to what UserA has access to.
App B running under MyID connects over CHANNEL.B, and is seen to the QM as UserB (because of the MCAUSER value), and only has access to what UserB has access to.
But if MyID has access to both SSL certificates or to both ID/Password combos used to authenticate via the exit, then this buys you nothing.
You could also "authenticate" by the source IP address using MQ 7.1's new filtering by IP address features, if you were able to insure App A only runs on IP Address #1 and App B only runs on IP Address #2.
If you are running in bindings mode local to the QM for both apps, you have no options if they both run under the same ID. Well, I suppose you could code some custom API exit. Eck. Just get a separate ID for App A and App B in this case.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| exerk |
| Posted: Sat Mar 10, 2012 11:29 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| PeterPotkay wrote: |
| exerk wrote: |
| Umarul Farooq wrote: |
Thank you Bruce..
Both Application.A and Application.B are ran by same user (it is the batch process running by same user).
If it is same user, How could restrict the accessability of queues.
Thanking you. |
A roundabout way of doing it would be to create two groups, each including the same user, and set authorities on the queue manager and each queue pertinent to the group, e.g. Application A group has the relevant authorities to connect to the queue manager and for Application A queue. Even though the same user is firing off both applications the applications themselves are restricted by the authorities set. |
I don't see how that would help.
MQ Authorities are based on what permissions a User ID has, which more than likely is actually set at the user's group level.
If 1, 2 or 1,000 different applications connect to the QM using that same ID, all will have the exact same authorities to all the same exact queues. |
It is my understanding that authorities are set at group level, and as long as the principal is not granted authorisation, then a measure of granulation is possible (and I know Windows is slightly different) - always happy to be re-educated though...
_________________
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 |
|
|
| PeterPotkay |
| Posted: Sat Mar 10, 2012 11:35 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If User1 is in GroupA and GroupB, and these 2 groups have different permissions, and App A / User1 connects to the QM, and then App B / User1 also connects, both App A and B have the exact same authority to the QM.
Whether it's GroupA's, GroupB's, some combination of both, or GroupC's if that is the primary group I don't know 100%. Its probably whatever the primary group has. It's been years since I tried putting one ID used to connect to MQ in multiple groups and tried various group settings. But its gotta be either consistent each and every time whether its App A, B or Z using that ID, or random each time in which case its even worse.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| exerk |
| Posted: Sat Mar 10, 2012 12:57 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
I'm with you on this. Either I force separation with channels, or insist on disparate applications starting under an identifiable, and different, user.
_________________
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 |
|
|
| bruce2359 |
| Posted: Sat Mar 10, 2012 1:23 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Moved to Security forum.
_________________
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 |
|
|
| bruce2359 |
| Posted: Sat Mar 10, 2012 1:35 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I believe this functionality (application access to objects) is offered in WebSphere Advanced Message Security product.
_________________
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 |
|
|
| mqjeff |
| Posted: Sun Mar 11, 2012 11:01 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Even in the base 7.1, you can use various criteria to map different applications connecting over the same channel into different roles. |
|
| Back to top |
|
|
|
|
