| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Clarification on MQ Client Authorization |
« View previous topic :: View next topic » |
| Author |
Message
|
| whydieanut |
 Posted: Mon Dec 24, 2012 3:52 am Post subject: Clarification on MQ Client Authorization |
 |
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
I have a QMgr (V 7.0.1.4) on AIX, to which about 10 different client applications need to connect, through client connections.
Each application should have access (put/get) to only specific queues.
What I currently have set up:
For each client system, I have created a user on AIX.
For each client system, I have a SVRCONN channel, with the MCAUSER set to the corresponding user.
Using setmqaut, I had given permissions for each user to be able to access only specific queues (get, put, inc etc.).
Just realized that, setmqaut on UNIX systems grants permissions to the user's primary group and not just to the user.
Given this, what is the approach that I should take?
Create a group for each client application.
Create a user for each client application and assign it to the corresponding group.
And then follow the approach I was using earlier.
Does this look like an acceptable solution? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Dec 24, 2012 4:36 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Looks like you got it all together. Proceed.
And by the way, it would have spared you the headache if you had authorized at group level also in windows. I've always said that individual authorization (principal) level was a bad decision... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| whydieanut |
| Posted: Mon Dec 24, 2012 4:49 am Post subject: |
|
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
Thanks a lot!
The thing is I have no control over the client applications.
They are from different vendor systems.
Just a small tip for for anyone facing issues with this.
I had initially just created users and assigned permissions to the user using setmqaut.
When I found out (from here - http://www.mqseries.net/phpBB/viewtopic.php?p=188941&sid=ae730f6c76b78c945dd46db55e713dfa) that the authorizations go to the group (staff, in my case), I tried removing the users I had created from the 'staff' group and assigning them to new groups I created for each user.
But still setmqaut seemed to be assigning permissions to the older staff group.
Tried a Security Refresh from MQ Explorer and that set everything alright! |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Dec 24, 2012 6:07 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
What about the other SVRCONN channels? Are they unsecured? Have you assigned userids to them?
_________________
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: Mon Dec 24, 2012 10:38 am Post subject: Re: Clarification on MQ Client Authorization |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| whydieanut wrote: |
What I currently have set up:
For each client system, I have created a user on AIX.
For each client system, I have a SVRCONN channel, with the MCAUSER set to the corresponding user.
Using setmqaut, I had given permissions for each user to be able to access only specific queues (get, put, inc etc.).
Just realized that, setmqaut on UNIX systems grants permissions to the user's primary group and not just to the user.
Given this, what is the approach that I should take?
Create a group for each client application.
Create a user for each client application and assign it to the corresponding group.
And then follow the approach I was using earlier.
Does this look like an acceptable solution? |
You then need to use SSL or a Security Exit to insure each channel can only be accessed by the intended client, other wise Client1 can connect to the QM via the channel you intended to only be used by Client2.
And then as bruce2359 says, you need to secure in a similar fashion all the other SVRCONN channels defined on this QM, or block them with a bogus ID if you intend no one to use those other channels ever.
Apply the same thought to the other incoming channel types (RCVR, RQSTR, CLUSRCVR) too.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| whydieanut |
| Posted: Tue Dec 25, 2012 11:04 pm Post subject: |
|
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
All the SVRCONN channels would be secured with a specific MCAUSER (ones not being used would have a fake id to protect access).
@Peter,
I am still looking at restricting access to specific SVRCONN channels to corresponding client applications, and am open to suggestions for the same.
Will look at BlockIP2.
Not too familiar with SSL, but will look at it too. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Dec 26, 2012 7:16 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| whydieanut wrote: |
All the SVRCONN channels would be secured with a specific MCAUSER (ones not being used would have a fake id to protect access).
@Peter,
I am still looking at restricting access to specific SVRCONN channels to corresponding client applications, and am open to suggestions for the same.
Will look at BlockIP2.
Not too familiar with SSL, but will look at it too. |
You will need to use SSLPEER. You can populate it with fields from the DN
ex:
SSLPEER('CN=xyz, O=mycompany.com, OU=mydivision')
_________________
MQ & Broker admin |
|
| 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
|
|
|
|
