| Author |
Message
|
| murdeep |
 Posted: Thu Sep 22, 2011 12:13 pm Post subject: MQMD UserIdentifier value when using Java Client |
 |
|
Master
Joined: 03 Nov 2004
Posts: 211
|
Hello, running WMQ V7.0.1.1 windows client connecting to V7.0.1.1 Windows server.
I define a svrconn channel with a blank MCAUSER. When I put a message with the sample app amqsputc the MQMD.UserIdentifier is set to my windows userid as expected. When I connect with a Java client the MQMD.UserIdentifier gets set to the userid the WMQ server is running under, not what I would expect. If I set the MCAUSER on the svrconn channel to a value then that value gets set as the UserIdentifier, as expected.
Is this normal behavior? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu Sep 22, 2011 12:17 pm Post subject: Re: MQMD UserIdentifier value when using Java Client |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| murdeep wrote: |
Hello, running WMQ V7.0.1.1 windows client connecting to V7.0.1.1 Windows server.
I define a svrconn channel with a blank MCAUSER. When I put a message with the sample app amqsputc the MQMD.UserIdentifier is set to my windows userid as expected. When I connect with a Java client the MQMD.UserIdentifier gets set to the userid the WMQ server is running under, not what I would expect. If I set the MCAUSER on the svrconn channel to a value then that value gets set as the UserIdentifier, as expected.
Is this normal behavior? |
You are running at a version that is labeled pre GA. GA is V 7.0.1.3.
Please upgrade to V 7.0.1.6 and see if you still have the problem. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| murdeep |
| Posted: Thu Sep 22, 2011 12:52 pm Post subject: |
|
|
Master
Joined: 03 Nov 2004
Posts: 211
|
Turns out my server is actually 7.0.1.3. Are you saying this is NOT expected and that there is a fix that addresses this? If so, can you cite the APAR for me? I looked and didn't see anything that jumped out at me.
I can upgrade the client (in the process of doing this now) but unfortunately I won't be able to upgrade the server without justification or proof that a particular APAR will address this. |
|
| Back to top |
|
|
| murdeep |
| Posted: Thu Sep 22, 2011 1:03 pm Post subject: |
|
|
Master
Joined: 03 Nov 2004
Posts: 211
|
| Ok, upgraded my client to 7.0.1.6 with server still at 7.0.1.3 and I get the same results. I suspect this may be normal behavior but would like someone to confirm one way or the other. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu Sep 22, 2011 3:38 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
The default install of MQ has very weak security. If you leave it blank and the queue manager's channel's (i.e. SYSTEM.DEF.SVRCONN) MCAUSER field is blank then you automatically get FULL and unrestricted access. Or you can simply put "mqm" for Unix/Linux queue managers or "MUSR_MQADMIN" for Windows queue managers.
I've done a number of write-ups on the weak security that a default install of MQ has:
Here's a description for Java apps:
http://www.mqseries.net/phpBB2/viewtopic.php?t=17842
Here's a description for native (C/C++/COBOL/VB) apps:
http://www.mqseries.net/phpBB2/viewtopic.php?t=21782
Anybody with a some knowledge of MQ can steal data from MQ or insert fraudulent messages into a company's system because there is no real security in a default install of MQ.
Full disclosure: Capitalware is a software vendor that sells MQ security products.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| murdeep |
| Posted: Thu Sep 22, 2011 3:49 pm Post subject: |
|
|
Master
Joined: 03 Nov 2004
Posts: 211
|
| I am aware of the inherent security holes with WMQ and will be creating application specific client channels that utilize SSL and both the MCAUSER and SSLPEER attributes and restricting the access of the MCAUSER. I'm just wondering why the Java client doesn't propagate the windows user when the svrconn MCAUSER is blank. It caught me off guard since I have not read or heard that it is supposed to work this way - which is different than the non Java client. So my question remains - is this normal behavior for a Java client? |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu Sep 22, 2011 3:56 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| murdeep wrote: |
| is this normal behavior for a Java client? |
Yes. And I'm pretty sure that it is documented in the WMQ Using Java manual. For both Java and Java/JMS applications, the developers must explicitly set the UserID, the MQ Client library will not auto set the field.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| murdeep |
| Posted: Thu Sep 22, 2011 3:58 pm Post subject: |
|
|
Master
Joined: 03 Nov 2004
Posts: 211
|
| BTW, I read that the Java client will use the userid of the listener process if MQEnvironment.userId in not set but my testing seems to invalidate this. I started the listener with a different userid than the userid that started my queue manager service and it still grabbed the userid of the service not the userid of the listener. I think this is working as designed but just want to verify. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Sep 23, 2011 1:28 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Right, so one of the original marketing points for the Java language was that it was "Write Once, Run Anywhere" - that you could compile a java class on any machine and it would run on any JVM of the same level, regardless of what platform that JVM was on.
This means that Java has a hard time of making it possible for Java programs to access things that appear to be basic in other languages - like platform specific security constructs (that is, the OS-level user that is executing the JVM).
In order for the MQ Libraries to have access to the OS-level user, they need to be running in a condition that allows them to run JNI/native code.
I believe it is correct, and still documented, that this only happens when you establish a BINDINGS connection, rather than a CLIENT connection. But I also have some vague hints of memories that there are some command line switches you can set that help this.
As Roger has said, you should be digging into the Using Java manaul here for more guidance. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Sep 23, 2011 3:13 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
This is regular issue that I see - blank ids from Java programs.
It is possible to pass a connection id on the MQCONN call. It is also possible to get WAS to pass an identity value for it's connections.
So no real reason to accept blanks ids, and we block them with BlockIP2 exit or very rarely map them to an id based on a known IP address. |
|
| Back to top |
|
|
|
|
