Author |
Message
|
Sam Uppu |
Posted: Tue Sep 15, 2009 7:55 am Post subject: MQ Security: MCAUSER on SVRCONN channel |
|
|
 Yatiri
Joined: 11 Nov 2008 Posts: 610
|
Hi Guys,
I always confuse with the MCAUSER settings on SVRCONN channels. The below are my understandings. Please correct me if I am wrong anywhere...thanks.
I. Defined a SVRCONN channel with blank MCAUSER
1. If the client app(whatever may be..java/C/Cobol etc) provides the application id in the MQMD of the msg and we(MQ admin) provide the setmqaut permissions for the qmgr and queues, the app will be able to access the qmgr and its queues.
2. If the app doesn't provide the application id in the userid field of MQMD of the incoming msgs, the MQListener process will assign its own UserId for connecting application.. i.e., mqm on UNIX, 'MUSR_MQADMIN' on windows, 'QMQM' for AS/400 etc.
II. Defined a SVRCONN channel with MCAUSER filled with application id 'App1'
1. Whether client application provide the userId or not in the incoming msg, the UserId will be replaced/ overwritten by MQ with the 'App1' for all the incoming messages.
Please correct me if I am wrong anywhere in my understandings.
Thanks. |
|
Back to top |
|
 |
WMBDEV1 |
Posted: Tue Sep 15, 2009 8:01 am Post subject: Re: MQ Security: MCAUSER on SVRCONN channel |
|
|
Sentinel
Joined: 05 Mar 2009 Posts: 888 Location: UK
|
I'm not so sure about this point....
Sam Uppu wrote: |
2. If the app doesn't provide the application id in the userid field of MQMD of the incoming msgs, the MQListener process will assign its own UserId for connecting application.. i.e., mqm on UNIX, 'MUSR_MQADMIN' on windows, 'QMQM' for AS/400 etc.
|
If the application code doesnt specify the field then (from memory) for the Java and .Net languages (and maybe others); it uses the username of the person running the process rather than the MQListener process just making it run as mqm.
The rest looks ok though |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Sep 15, 2009 8:04 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Sam, everything you wrote is correct. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Sep 15, 2009 8:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
The channel receiver process has no access to the user name running the MQ application that put the message on the xmitq.
If a message is given to a channel receiver process (the MCA) that has a NULL userid in the message, then the message is put with the ID that is running the MCA. This is almost always the mqm/MUSR_MQADMIN id. |
|
Back to top |
|
 |
Sam Uppu |
Posted: Tue Sep 15, 2009 8:22 am Post subject: |
|
|
 Yatiri
Joined: 11 Nov 2008 Posts: 610
|
Thanks for confirming my understandings.
Now,
Lets say we are using the 'App1' in the MCAUSER of SVRCONN channel and provided +connect on Qmgr, put/get/browse permissions on queues for 'App1' id(OAM)
Any malicious application can also access the Qmgr and its queues(put/get/browse) if that app knows the QMgr and its queue names, correct?. To avoid this SSL is only the option or do we have any alternative?. Do we have any security exits from IBM(cost free) which I am not aware of?.
I just wanted to know how you are securing the MQ in your organizations.
Thanks. |
|
Back to top |
|
 |
WMBDEV1 |
Posted: Tue Sep 15, 2009 8:25 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009 Posts: 888 Location: UK
|
mqjeff wrote: |
The channel receiver process has no access to the user name running the MQ application that put the message on the xmitq.
|
I agree with this statement, but I thought that the client libraries (at least in the case of Java and .Net) put it in for you if you did not specify it. I thought (again from memory though) that my messages put from the Java app inherited my userid rather than that used by the channel.
If you tell me i'm still wrong then ill go away and convince myself one way or the other 
Last edited by WMBDEV1 on Tue Sep 15, 2009 8:26 am; edited 1 time in total |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Sep 15, 2009 8:26 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Sam Uppu wrote: |
Lets say we are using the 'App1' in the MCAUSER of SVRCONN channel and provided +connect on Qmgr, put/get/browse permissions on queues for 'App1' id(OAM) |
*Every* app, malicious or not, that can successfully connect to that Channel will ONLY be AUTHORIZED as 'App1'. |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Sep 15, 2009 8:28 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
WMBDEV1 wrote: |
mqjeff wrote: |
The channel receiver process has no access to the user name running the MQ application that put the message on the xmitq.
|
I agree with this statement, but I thought that the client libraries (at least in the case of Java and .Net) put it in for you if you did not specify it. I thought (again from memory though) that my messages put from the Java app inherited my userid rather than that used by the channel.
If you tell me i'm still wrong then ill go away and convince myself one way or the other  |
Newer releases of the Java libraries will populate this if they are capable of doing so.
.NET has always done this, afaik. There's never been a way to set the user id to NULL in .NET. It's funny, but .NET has none of the concerns about accessing OS native libraries that Java always had. I can't imagine why. |
|
Back to top |
|
 |
WMBDEV1 |
Posted: Tue Sep 15, 2009 10:32 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009 Posts: 888 Location: UK
|
thanks for the response jeff. I think that backs up the point I was trying to make about the ops point 2.
There may be a subtlety with what is meant by "the app" with one view being just the app code, and the other being the app code + mq client libraries. I was of course referring to the app code alone.
Your point about .net is correct also. I seem to remember getting a 2059 if you tried to explicity set the user Id. |
|
Back to top |
|
 |
Sam Uppu |
Posted: Tue Sep 15, 2009 12:48 pm Post subject: |
|
|
 Yatiri
Joined: 11 Nov 2008 Posts: 610
|
We tested the below scenario in our development environment but the developer is getting 2035 error.
1. Created a qmgr - QM1 and a queue - LOCAL.QUEUE in it.
2. Defined a JAVA.SVRCONN channel and provided 'App1' application id in the MCAUSER.
Here are the permissions provided to the QMgr and queue:
Entity App1 has the following authorizations for object LOCAL.QUEUE:
get
browse
put
inq
Entity App1 has the following authorizations for object QM1:
inq
connect
A developer was trying to access this queue to put/get from his desktop and he is getting 2035 error.
Can you guys share your thoughts on this..why the developer is getting 2035 though I provided the perms to QMgr/ queue for the App id 'App1'?.
Thanks. |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Sep 15, 2009 12:52 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Sam Uppu wrote: |
We tested the below scenario in our development environment but the developer is getting 2035 error.
1. Created a qmgr - QM1 and a queue - LOCAL.QUEUE in it.
2. Defined a JAVA.SVRCONN channel and provided 'App1' application id in the MCAUSER.
Here are the permissions provided to the QMgr and queue:
Entity App1 has the following authorizations for object LOCAL.QUEUE:
get
browse
put
inq
Entity App1 has the following authorizations for object QM1:
inq
connect
A developer was trying to access this queue to put/get from his desktop and he is getting 2035 error.
Can you guys share your thoughts on this..why the developer is getting 2035 though I provided the perms to QMgr/ queue for the App id 'App1'?.
Thanks. |
When in doubt try refresh security...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Sam Uppu |
Posted: Tue Sep 15, 2009 12:58 pm Post subject: |
|
|
 Yatiri
Joined: 11 Nov 2008 Posts: 610
|
FJ,
That didn't help. Still getting 2035 error.
Any further thoughts?. |
|
Back to top |
|
 |
Sam Uppu |
Posted: Tue Sep 15, 2009 1:32 pm Post subject: |
|
|
 Yatiri
Joined: 11 Nov 2008 Posts: 610
|
When I try to connect and send a msg from my java client program on my desktop, I am able to send the msg.
My id is part of mqm group. But that should not matter as we are setting the MCAUSER with 'App1' and provided perms to qmgr/queue for the App1 id which should also work for him(developer).
Why the developer is getting 2035 from his desktop?. Not sure what the hell he is doing.. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Sep 15, 2009 2:41 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Sam Uppu wrote: |
Why the developer is getting 2035 from his desktop?. Not sure what the hell he is doing.. |
We don't have a crystal ball either. So turn on Authority Events at the QM and see exactly what is missing. Obviously his app is using an option that you have not allowed, like +set or +passall. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
bruce2359 |
Posted: Wed Sep 16, 2009 5:26 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
What do error logs on both qmgr and client reveal? _________________ 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 |
|
 |
|