Author |
Message
|
shogan2003 |
Posted: Fri May 14, 2004 3:20 am Post subject: security and clients |
|
|
Centurion
Joined: 03 Jul 2003 Posts: 133 Location: London
|
I am trying to restrict access to MQSeries clients putting and getting from queues on an MQSeries server. I wish to restrict user access to the channel and/or the queue.
Ideally I'd like to assign a separate server connection channel for each client performing a put or get based on logged-on user ID.
I have encountered a couple of issues. Some are down to my incompetence and others may be down to technical restrictions on MQSeries. I have researched MQSeries.net and note a similar query which attracted many replies, but they all suggested exits, which I really wish to avoid.
1. setmqaut, dspmqaut
--------------------------
I have experimented with setmqaut on Solaris & on NT; when I declare a queue as -put for a user, the command dspmaut still shows 'put' as one of the options available to that user for that queue. Also I can put to that queue.
But I thought security was on by default ?
I defined MQSNOAUT=no and restarted the NT machine
Still setmqaut & dspmaut have no effect.
2. DIY code
-----------
Environment : MQSeries 5.3 Solaris on client and server ; some future MQSeries clients will be Windows 2000.
The flat file adapter I have written on the MQSeries client machine inserts the logged-on user name into MQSeries header field UserId. Don't know if this is usable by MQSeries.
The value in userId is being ignored. Any value is accepted. I have varied the value of MCAUSER for the server connection channel SYSTEM.DEF.SVRCONN, using values '','mqm' and 'xyz'. The last value will give error code 2035, but that's only because xyz does not exist as a user on the server machine.
Many thanks in advance _________________ MQSI2 certified specialist
MQSeries certified specialist |
|
Back to top |
|
|
jefflowrey |
Posted: Fri May 14, 2004 5:02 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
There are a couple of things you may not understand about OAM security on NT and Solaris.
On Unix, OAM permissions apply to the group, not to the user.
Security manual wrote: |
The OAM maintains an access control list (ACL) for each WebSphere MQ object it is controlling access to. On UNIX systems, only group IDs can appear in an ACL. This means that all members of a group have the same authorities. |
On Windows, if the user is a member of the Administrators group, then they can do anything they want.
Security manual wrote: |
On Windows systems, members of the Administrators group also have access to all WebSphere MQ resources. |
This can get particularly sticky in domain and trust relationship environments.
On either platform, if the user is a member of the MQM group, then OAM security also does not apply.
Security manual wrote: |
All members of the mqm group have access to all WebSphere MQ resources on the system, including being able to administer any queue manager running on the system. This access can be revoked only by removing a user from the mqm group. |
_________________ I am *not* the model of the modern major general. |
|
Back to top |
|
|
shogan2003 |
Posted: Fri May 14, 2004 5:16 am Post subject: |
|
|
Centurion
Joined: 03 Jul 2003 Posts: 133 Location: London
|
Thankd for the reply.
I had assumed that any user had to be a member of mqm before it use the queue at all; then setmqaut would be used to cut down its permissions. _________________ MQSI2 certified specialist
MQSeries certified specialist |
|
Back to top |
|
|
JasonE |
Posted: Fri May 14, 2004 5:41 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003 Posts: 1220 Location: Hursley
|
fyi I think MQSNOAUT=no only takes effect when the qmgr is created... |
|
Back to top |
|
|
jefflowrey |
Posted: Fri May 14, 2004 5:45 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
You notice I quoted from the Security manual quite a bit, and that the answers I provided were all directly referenced in the security manual.
_________________ I am *not* the model of the modern major general. |
|
Back to top |
|
|
mqonnet |
Posted: Fri May 14, 2004 6:33 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
"I had assumed that any user had to be a member of mqm before it use the queue at all; then setmqaut would be used to cut down its permissions.
"
---Whoa!!! Never do this. If you are a memeber of the mqm group and revoke permissions on MQ objects on a qm for this user, the permissions are revoked for the entire mqm group. And there is no way you could grant back these permissions and the only way out is to Delete and recreate the qm.
Should probably take a detailed look at how authorities are granted, groups/users in the security manual.
Cheers
Kumar _________________ IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
Back to top |
|
|
JasonE |
Posted: Fri May 14, 2004 6:43 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003 Posts: 1220 Location: Hursley
|
Kumar, FYI On windows you cannot really remove authorizations from mqm - The code finds mqm membership then doesnt look in the oam for authorizations... |
|
Back to top |
|
|
mqonnet |
Posted: Fri May 14, 2004 6:48 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
"FYI On windows you cannot really remove authorizations from mqm - The code finds mqm membership then doesnt look in the oam for authorizations..."
---Cool. I should have probably mentioned the platforms. I believe all unix based versions behave the way i just mentioned.
Cheers
Kumar _________________ IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
Back to top |
|
|
shogan2003 |
Posted: Fri May 14, 2004 7:01 am Post subject: |
|
|
Centurion
Joined: 03 Jul 2003 Posts: 133 Location: London
|
Thanks to you all for your responses so far.
I'm still mulling over restricting access via channels...
So just to re-iterate...
A userID should not be a member of mqm....in which case security can be applied to that user...anyone logging on using that userID on the client machine it should be able to run the MQ client binaries ?
Do setmqaut & dspmqaut defined against a user have any effect on messages coming from a client with that userId defined (in the MQEnvironment class )? _________________ MQSI2 certified specialist
MQSeries certified specialist |
|
Back to top |
|
|
mqonnet |
Posted: Fri May 14, 2004 7:13 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
"A userID should not be a member of mqm....in which case security can be applied to that user"
---Right
"anyone logging on using that userID on the client machine it should be able to run the MQ client binaries ?
"
---MQ client libraries has nothing to do in this scenario, since the purpose you are going to server/achieve here is to authenticate the userid on the client system to access specific MQ objects on the MQ Server system.
"Do setmqaut & dspmqaut defined against a user have any effect on messages coming from a client with that userId defined (in the MQEnvironment class )?"
---Yes and no. All depends on how you configure stuff. If you have mcauser set to blank, then the authorities that you set for the userid defined/set in your application are used to authenticate any requests on the server side. You need to define a principal and assign auths on the server side. If you have set mcauser within the svrconn channel to a specific userid, then it doesnt matter what userid you set in your application. The one in the mcauser is always used to authenticate any requests from any client using this particular svrconn channel.
Cheers
Kumar _________________ IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
Back to top |
|
|
shogan2003 |
Posted: Fri May 14, 2004 7:39 am Post subject: |
|
|
Centurion
Joined: 03 Jul 2003 Posts: 133 Location: London
|
Gents
So this scenario is feasible ...? :
Client machine Server machine
----------------- -------------------
Flat file adapter (Java)
MQEnvironment.userID='user1' user : user1, grp : user1
MQEnvironment.userID='pwuser1'
Svrconn chl : CH.USER1
setmqaut
-----------
Only user1 has access to Q.USER1
Only user2 has access to Q.USER2, connected via channel CH.USER2 _________________ MQSI2 certified specialist
MQSeries certified specialist |
|
Back to top |
|
|
mqonnet |
Posted: Fri May 14, 2004 7:54 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
Well, if your sole purpose is to assign specific authorities to specific users for specific mq objects(queues), why dont you define principals/userids with the same name as their logon ids that they use on MQ Client systems on the MQ server system. And then leave the svrconn channel mcauser balnk. Assign authorities to these principles for specific objects. That way anybody coming in with their specific userid would be validated.
Unlike your design where you would need multiple svrconn channels with multiple userids in mcauser attribute, if i got it right.
Also search this forum for 2035, authorized, principal key words seperately and you would find a lots of threads. Just skim through them and most likely you would get all your queries answered.
Cheers
Kumar _________________ IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
Back to top |
|
|
shogan2003 |
Posted: Fri May 14, 2004 8:03 am Post subject: |
|
|
Centurion
Joined: 03 Jul 2003 Posts: 133 Location: London
|
Kumar
Thanks for that. I do regularly search using those key words. I shall implement your advice.
Do all you grand masters sort of look down on Earth like the Greek gods in that great Ray Harryhausen feature 'Jason and the Argonauts ? _________________ MQSI2 certified specialist
MQSeries certified specialist |
|
Back to top |
|
|
PeterPotkay |
Posted: Fri May 14, 2004 8:41 am Post subject: |
|
|
Poobah
Joined: 15 May 2001 Posts: 7717
|
Leaving an MCAUSER on a SVRCONN channel blank is like leaving the vault in a bank open and saying to yourself "Well, only the people that should go in there will."
You are going to go thru all the trouble of running setmqaut commands against all those IDs, and then some clown comes along, defines a user called mqm on their machine, and connects to your QM, completly circumventing your "security" measures.
The thing to do is create a SVRCONN channel for a particular group of peoples. Tag the MCAUSER with GROUP1, and then give GROUP1 setmqaut authority only for the queues it should have. If a new set of users comes along and they need different authorities, then create a new SVRCONN channel and set its MCAUSER to GROUP2, and run setmaaut commands for GROUP2. etc, etc, etc.
Now, you still got the problem of someone from GROUP1 connecting to the channel for GROUP2, and getting those rights. The only way to prevent that is exits, or use channel names so weird GROUP1 can't guess GROUP2's channel name, or use SSL.
Bottom line: A SVRCONN with no MCAUSER (and no exit) has ZERO security. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
|
shogan2003 |
Posted: Fri May 14, 2004 9:29 am Post subject: |
|
|
Centurion
Joined: 03 Jul 2003 Posts: 133 Location: London
|
Now THAT is what I call an answer.
Thank U v much _________________ MQSI2 certified specialist
MQSeries certified specialist |
|
Back to top |
|
|
|