Author |
Message
|
tosaurav |
Posted: Mon Feb 11, 2008 7:02 am Post subject: C Client Failing |
|
|
Acolyte
Joined: 16 Jan 2007 Posts: 62
|
MQ C client on HP-Unix and MQ Server on Windows fail to communicate when C client runs with logged in Id. User-id on both environments are different so I tried to set the ID's from Client but failed. |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Feb 11, 2008 7:07 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Either a) change the id running on HP, or b) create the same id on Windows and authorize user, or c) Set MCAUSER on the SVRCONN.
option C is the best bet, when backed up with SSL and network security to ensure that only authorized people can connect to the channel. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
tosaurav |
Posted: Mon Feb 11, 2008 8:20 am Post subject: |
|
|
Acolyte
Joined: 16 Jan 2007 Posts: 62
|
Thanks Jeff, If i opt c and set MCAUSER at SVRCONN then also client needs to set and send the user id?
Actually I tried setting MCAUSER on SVRCONN but somehow it allowed all request from Client ,irrespective of what userid you are passing.This leads to me as if there isn't any security.May be I am wrong could you explain me. In what case this setting reject request means fail cases? |
|
Back to top |
|
 |
Vitor |
Posted: Mon Feb 11, 2008 8:25 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
tosaurav wrote: |
Thanks Jeff, If i opt c and set MCAUSER at SVRCONN then also client needs to set and send the user id?
Actually I tried setting MCAUSER on SVRCONN but somehow it allowed all request from Client ,irrespective of what userid you are passing.This leads to me as if there isn't any security.May be I am wrong could you explain me. In what case this setting reject request means fail cases? |
The MCAUser, if set, will be used for all access overriding the user id passed by the client - that's what it's for. You'll find this detailed in the Clients manual.
To restrict access further you need to a) ensure that the MCAUser set in the channel is given the minimum authorities necessary and b) is combined with other means to prevent unauthorised access to the channel (as my learned associated has pointed out) _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Feb 11, 2008 8:28 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
I said "MCAUSER + SSL". Not "MCAUSER".
MCAUSER replaces whatever the client sends.
The only way to change what ID a C client sends is to change what id is running the C program.
There's not any reliable way to control what ID a Java client sends.
If you need security with MQ, you likely need to hire a consultant.
Or spend a lot of time reading and researching. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Feb 11, 2008 10:22 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
or MCAUSER + MQ Security Exit. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
tosaurav |
Posted: Tue Feb 12, 2008 2:53 pm Post subject: |
|
|
Acolyte
Joined: 16 Jan 2007 Posts: 62
|
How MCAUSER + MQ SECURITY EXIT?
We have Secuirty exit define on Chnannel but some how not able to override Client logged in user id.
Is there anyway to control out-of-box means by setting?Why MQ API doesnt have support like Java based client where you can set anything? |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Feb 12, 2008 3:02 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
tosaurav wrote: |
How MCAUSER + MQ SECURITY EXIT?
We have Secuirty exit define on Chnannel but some how not able to override Client logged in user id. |
Does your Security Exit have this functionality built into it? Most good ones do. (like Capitalware's MQAUSX)
tosaurav wrote: |
Why MQ API doesnt have support like Java based client where you can set anything? |
The non Java MQ API doesn't let you set anything for your User ID because then you could set anything in your code. To bad the Java MQ API can't be like that also.
I suppose if you want your MQ client to be seen as user ABC you should define a user called ABC on your client server and run your app under that ID. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
Vitor |
Posted: Wed Feb 13, 2008 2:08 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
tosaurav wrote: |
Why MQ API doesnt have support like Java based client where you can set anything? |
Because the MQ API doesn't have a security hole you could drive a truck through like the Java one does?
(Bias warning - ex C/C++ developer AND an MQ admin who's found out about the Java "feature" the hard way!) _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Feb 13, 2008 2:55 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Sun decided that Java needed to be "Platform neutral", so it could "write once, run everywhere".
Sun also decided not to include "platform neutral" mechanisms for getting at the "platform specific" User ID.
IBM could therefore not require that Java code pass the platform specific User ID into the MQ client connection. Without breaking Java. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
Vitor |
Posted: Wed Feb 13, 2008 3:15 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
jefflowrey wrote: |
IBM could therefore not require that Java code pass the platform specific User ID into the MQ client connection. Without breaking Java. |
I'd like to emphasise that my previous rant was directed entirely at Java generally & the JMS in particular, and was in no way a criticism of the IBM implementation of same.
I offer into evidence a "MQ is losing my messages" scenario, where the missing messages turned up in the error logs of a completely different application to the intended target. After spending an enjoyable (!) afternoon checking remote queue definitions, the problem was traced to a Java app using the wrong queue name. I'd previously discounted this simple solution as I'd taken the precaution of setting security on the queues so application & queue would have to match.
Investigations revealed that the accepted solution in the Java team to an MQ Reason code of 2035 was to "code mqm as the user id" because "there's a bug in the MQ security and you have to run as administrator sometimes".
People wonder why I'm jaded.
slightly & I apologise for any inconvienience caused. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Feb 13, 2008 4:41 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Vitor wrote: |
I'd like to emphasise that my previous rant was directed entirely at Java generally & the JMS in particular, and was in no way a criticism of the IBM implementation of same. |
I'm just making sure that the information is clear.
Also, your problem app could just as easily been done with a C client, and 'fork("sudo -u mqm -c")' or etc. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
|