| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| c-sharp user security |
« View previous topic :: View next topic » |
| Author |
Message
|
| hallmark |
 Posted: Mon Sep 19, 2011 1:53 am Post subject: c-sharp user security |
 |
|
Voyager
Joined: 10 Mar 2005
Posts: 76
|
I am experiencing some unexpected results in my attempts to provide a workable security for some MQ unfrastructure.
Scenario
Using BlockIP2_v292 channel exit on SVRCONN channel
Connecting to MQ with a C-Sharp client
The client originally was connecting by specifying a userid in the qmgr connection string.
I am using blockIP to map connecting users to specific users with specific authorities on MQ objects.
I now (after reading) understand that the C# userid is not passed through to MQ (or at least used in the OAM security model) rather the service (logged on user id) is used. That's ok.
However when I do choose to enter userid text in the connection string, I more often than not end up with 2035 errors (even though all BlockIP detects is the process userid for every single connection and maps successfully to an MCA user of my choice).
process id: administrator
user with privileges : devapp
connection string : devapp
mca user on channel: NoBody
Result: Mapping from administrato -> devapp,connection Success, queue accessed
All fields as above apart from
connection string : no user specified
Result: Success as above
All fields as above apart from
connection string: mqm (or any other user)
Result: Mapping as above, Connection - FAIL (2035)
So, its fine for my situation (as fine as it can be without SSL) but I was wondering if anyone knows what is going on and should it.
Cheers (and thanks for getting this far!)
_________________
Rob |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Mon Sep 19, 2011 4:19 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The MCAUSER value overrides whatever the MQ Client may be sending for an ID. Since you have your MCAUSER set to "NoBody", as we assume that ID has no access to your MQ resources, the 2035 MQRC you are getting is expected.
You cannot trust the MQ Client to send you a valid ID.
You cannot trust the MQ CLient to not say its mqm and take over your QM.
Set the MCAUSER to a unique ID.
Assuming your QM is on Unix, stick that ID in a unique group, and make that group the primary group, then grant that group the bare minimum access it needs to your QM. On Windows you can skip the group and use the ID directly for granting rights.
Use an Exit or SSL to insure only the user(s) you intend to can use that channel.
Repeat over and over for however many channels you need to provide each group of users the specific access they need.
The MCAUSER defines *what* users of that channel can do.
SSL or an Exit determines *who* can use that channel.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Sep 19, 2011 4:41 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| PeterPotkay wrote: |
| The MCAUSER value overrides whatever the MQ Client may be sending for an ID. |
... and a security exit (eg. blockip2) can override that with whatever it wants. This may result in 2035 errors if the exit sets MCAUSER to a userid which does not exist or does not have authority to the objects which the client app attempts to access.[/quote]
_________________
Glenn |
|
| Back to top |
|
|
| hallmark |
| Posted: Tue Sep 20, 2011 12:29 am Post subject: |
|
|
Voyager
Joined: 10 Mar 2005
Posts: 76
|
Click! Thanks guys suddenly the light dawns.
So the approach you have indicated quite clearly is; on each QMgr specify an MCAUSER on the applicaiton client's channel which has the necessary privileges on that queue manager to perform its duties. i.e. a real user on the unix box with setmqauts applied. I would then use the blockIP exit (for now) to try as much as possible to only allow the users from certain IP addresses connect.
This isn't actually too far from my current setup. I use blockIP a little more elaborately to MAP the MCAUSER based on the connection IP address and username and achieve the same ends. Your method reduces the complexity of the BlockIP config file. And also means when I do move to SSL I can remove the need of an exit entirely.
It still doesn't answer my question about the unusual behaviour I appear to be seeing from the C# client where a consistent MCAUSER and successful mapping by blockIP yields different results based on the ID the app happens to pass. As far as I can see with my setup that ID being passed by C# should have absolutely no bearing on the authorisation on the queue manager. MCAUSER should be the overriding factor in all cases as you stated (but by my evidence its not!)
Thanks for the advice though, I will simplify my setup based on that and test.
_________________
Rob |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Sep 20, 2011 11:27 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| hallmark wrote: |
| ...Your method reduces the complexity of the BlockIP config file. And also means when I do move to SSL I can remove the need of an exit entirely... |
SSL only 'guarantees' that a connection will be achieved by the other end presenting a valid certificate. If your client key store is cloned, and the connection made from an 'unauthorised' machine, then a connection will be established. Just something to ponder...
_________________
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: Tue Sep 20, 2011 2:47 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| hallmark wrote: |
| on each QMgr specify an MCAUSER on the applicaiton client's channel which has the necessary privileges on that queue manager to perform its duties. i.e. a real user on the unix box with setmqauts applied |
Its not at the QM level, but at the individual channel level. So for every SVRCONN, RCVR, RQSTR and CUSRCVR channel you have on your QM that needs a unique level of access, you provide a unique ID in the MCAUSER. On Unix, that means a corresponding unique group. Yes, that could mean dozens of new users and groups, so plan accordingly! For the SYSTEM channels you don't want anyone to use, tag them with a unique bogus ID that has no access.
| hallmark wrote: |
It still doesn't answer my question about the unusual behaviour I appear to be seeing from the C# client where a consistent MCAUSER and successful mapping by blockIP yields different results based on the ID the app happens to pass. As far as I can see with my setup that ID being passed by C# should have absolutely no bearing on the authorisation on the queue manager. MCAUSER should be the overriding factor in all cases as you stated (but by my evidence its not!). |
Its possible your Exit is configured to pass the ID from the client and override the hard coded MCAUSER.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| 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
|
|
|
|
