Author |
Message
|
ae06425 |
Posted: Mon Mar 29, 2010 1:51 pm Post subject: svrconn channel mcauser field with two userid or more |
|
|
Centurion
Joined: 02 Apr 2007 Posts: 100
|
It is possible to add 2 (two) or more user id on mcauser field of svrconn channel? if yes how?
thanks in advance |
|
Back to top |
|
 |
Vitor |
Posted: Mon Mar 29, 2010 1:53 pm Post subject: Re: svrconn channel mcauser field with two userid or more |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
ae06425 wrote: |
It is possible to add 2 (two) or more user id on mcauser field of svrconn channel? |
No. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
gbaddeley |
Posted: Mon Mar 29, 2010 2:57 pm Post subject: Re: svrconn channel mcauser field with two userid or more |
|
|
 Jedi Knight
Joined: 25 Mar 2003 Posts: 2538 Location: Melbourne, Australia
|
ae06425 wrote: |
It is possible to add 2 (two) or more user id on mcauser field of svrconn channel? if yes how?
thanks in advance |
You have been given the answer - No.
What were you hoping to achieve by doing that? There may be some other way to meet your security requirement... _________________ Glenn |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Mar 29, 2010 7:56 pm Post subject: Re: svrconn channel mcauser field with two userid or more |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
ae06425 wrote: |
It is possible to add 2 (two) or more user id on mcauser field of svrconn channel? if yes how?
thanks in advance |
If it is to bestow the same authorizations on both users, create a group and set the groupid on the mcauser. (Make sure you use SSL as well). If the users may connect locally (bindings mode) add them to the group.
If it is to bestow different authorizations depending on the user... do create a different channel for each set of authorizations.
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
ae06425 |
Posted: Tue Mar 30, 2010 6:21 am Post subject: |
|
|
Centurion
Joined: 02 Apr 2007 Posts: 100
|
there are 2 userids from 2 different apps wanting to access queue through svrconn. I think creating a group and making userids part of the group and putting group name in mcauser field of channel is a solution... thanks |
|
Back to top |
|
 |
ae06425 |
Posted: Tue Mar 30, 2010 6:23 am Post subject: |
|
|
Centurion
Joined: 02 Apr 2007 Posts: 100
|
I may add another svrconn channel but if adding group in mcauser field(making user ids part of group) is enough, that be good enough without creating enother svrconn for second user... |
|
Back to top |
|
 |
zpat |
Posted: Tue Mar 30, 2010 6:26 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Coding a mcauser on the channel bypasses security. You cannot code a group name.
Therefore it does not matter what userid is used on the connection, since you are overriding it. This mcauser value is not the id allowed, it is the id that will be used unconditionally.
To achieve what I think you are trying to do, you should leave the mcauser field blank, or better still use an exit like BlockIP2 to assign the incoming id to the mcauser.
Then you would make both the userids members of the same group, and grant the group access to the queues. |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Mar 30, 2010 6:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
zpat wrote: |
Coding a mcauser on the channel bypasses security. You cannot code a group name. |
MCAUSER takes a principle name.
On unix, the OAM authorizes *groups* not *users*. So you can code an MCA with a principle that is a user, but the user's primary *group* will be authorized and not the user itself.
Coding an MCAUSER doesn't *bypass* security. The MCAUSER is still authorized by the OAM.
But this is exactly the case
zpat wrote: |
This mcauser value is not the id allowed, it is the id that will be used unconditionally. |
.
MQ ONLY does *authorization*, it does absolutely no *authentication*.
NEVER EVER leave the MCAUSER blank, if you are attempting any kind of security.
The proper solution for ae06425 is to set a single MCAUSER value that is a principle on the qmgr system, and use setmqaut to grant the specific privileges for that application role.
And then both applications will be authorized into that role when they connect to that SVRCONN.
If ae06425 needs to *authenticate* users or applications into that role, then SSL or a security exit of some kind can be used. |
|
Back to top |
|
 |
ae06425 |
Posted: Tue Mar 30, 2010 7:50 am Post subject: |
|
|
Centurion
Joined: 02 Apr 2007 Posts: 100
|
Thanks to you all for good info. I do not use SSL or exits. But I use setmqaut. This is to merge 2 apps with 2 userids to use one svrconn.
my understanding MCA userid takes priority to connect to queues and must be authenticated to queues with setmqaut. That case, doesn't matter what app id is.
If I authenticate existing mcauser id to new queues(2nd app), even if the id that second app is using, since mcauser is authenticated for 2nd app queues, it must be good. Will test it. Thanks again. |
|
Back to top |
|
 |
zpat |
Posted: Tue Mar 30, 2010 9:20 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Coding a mcauser id bypasses security. In that anyone can connect to that channel with any client application or tool and get that id's access rights. |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Mar 30, 2010 10:04 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Perhaps I am splitting hairs, but "bypassing security" to me means "no checking is done at all".
The MCAUSER value is checked against the OAM. If that value is not blank but is set to a non-existent principal, then the OAM denies any access to anything. If the principal does exist, then only the authorities granted to that principal are allowed.
That's not "no checking is done at all".
Leaving an MCAUSER as a blank value exposes the channel to significantly more risk than setting it to a known value. It allows the connecting application to pass in any value it wants to for the connection user id, whether that value has been properly authenticated on the remote end or not. Certain specific MQ APIS do not allow the application to specify the user id with code, but that provides no real security.
In addition if that sending application passes in a null value, then the MCA will use it's *own* userid to authorize against the OAM. This is almost always the mqm principle, since it's very difficult to get the MCA to run as a non-mqm user. So it is a BAD idea to leave MCAUSER blank.
Again, MQ does not authenticate any principals at all. It merely provides a set of authorizations.
Yes, without additional measures, any application can connect to any specific channel, and yes the use of MCAUSER will automatically provide any application that does connect to that channel with a known fixed set of authorities.
SSL provides mechanisms for ensuring that only the right applications can connect to the right channels, through use of SSLPEER.
Channel security exits provide mechanisms for ensuring that only the right applications can connect to the right channels.
Channel security exits can ALSO provide additional mechanisms to map an application ID to the correct principal that is more flexible than using MCAUSER.
But neither SSL nor channel security exits can alter the authorizations granted to a specific principal by the OAM. |
|
Back to top |
|
 |
rconn2 |
Posted: Wed Jun 09, 2010 1:14 pm Post subject: |
|
|
Voyager
Joined: 09 Aug 2007 Posts: 79 Location: MD, USA
|
Excellent explanation Jeff. I Just did a google for mcauser and came across this thread and found what I needed. Thanks! |
|
Back to top |
|
 |
bkiran2020 |
Posted: Mon Jul 29, 2013 3:25 am Post subject: |
|
|
 Master
Joined: 20 Jan 2011 Posts: 243 Location: US
|
mqjeff wrote: |
Perhaps I am splitting hairs, but "bypassing security" to me means "no checking is done at all".
The MCAUSER value is checked against the OAM. If that value is not blank but is set to a non-existent principal, then the OAM denies any access to anything. If the principal does exist, then only the authorities granted to that principal are allowed.
That's not "no checking is done at all".
Leaving an MCAUSER as a blank value exposes the channel to significantly more risk than setting it to a known value. It allows the connecting application to pass in any value it wants to for the connection user id, whether that value has been properly authenticated on the remote end or not. Certain specific MQ APIS do not allow the application to specify the user id with code, but that provides no real security.
In addition if that sending application passes in a null value, then the MCA will use it's *own* userid to authorize against the OAM. This is almost always the mqm principle, since it's very difficult to get the MCA to run as a non-mqm user. So it is a BAD idea to leave MCAUSER blank.
Again, MQ does not authenticate any principals at all. It merely provides a set of authorizations.
Yes, without additional measures, any application can connect to any specific channel, and yes the use of MCAUSER will automatically provide any application that does connect to that channel with a known fixed set of authorities.
SSL provides mechanisms for ensuring that only the right applications can connect to the right channels, through use of SSLPEER.
Channel security exits provide mechanisms for ensuring that only the right applications can connect to the right channels.
Channel security exits can ALSO provide additional mechanisms to map an application ID to the correct principal that is more flexible than using MCAUSER.
But neither SSL nor channel security exits can alter the authorizations granted to a specific principal by the OAM. |
thanks for detail explanation..
Is the application user id should be part of any of the groups on the server? |
|
Back to top |
|
 |
hughson |
Posted: Tue Jul 30, 2013 5:58 am Post subject: |
|
|
 Padawan
Joined: 09 May 2013 Posts: 1959 Location: Bay of Plenty, New Zealand
|
ae06425 wrote: |
there are 2 userids from 2 different apps wanting to access queue through svrconn.
This is to merge 2 apps with 2 userids to use one svrconn. |
I assume that today you have two SVRCONNs something like this:-
Code: |
DEF CHL(SVRCONN.APP1) TYPE(SVRCONN) MCAUSER(USERAPP1)
DEF CHL(SVRCONN.APP2) TYPE(SVRCONN) MCAUSER(USERAPP2) |
Where Application 1 connects through SVRCONN.APP1 and only has access to the queues that user ID USERAPP1 is granted access to? Same for Application2? Thus today Application1 cannot use the queues for Application2 and vice versa?
Perhaps you also have some authentication of these connections before blindly assigning a user ID and perhaps you don't.
And now you want to have only one SVRCONN instead of two?
May I suggest:-
Code: |
DEF CHL(SVRCONN.APP.COMBINED) TYPE(SVRCONN) MCAUSER('rubbish')
SET CHLAUTH(SVRCONN.APP.COMBINED)
TYPE(ADDRESSMAP)
ADDRESS('IP-address of Application1 Client')
MCAUSER(USERAPP1)
SET CHLAUTH(SVRCONN.APP.COMBINED)
TYPE(ADDRESSMAP)
ADDRESS('IP-address of Application2 Client')
MCAUSER(USERAPP2) |
Doing this means you don't have to change anything in the permissions just in order to combine the SVRCONN channel.
Of course, you don't have to use the IP address as the way to choose which MCAUSER to assign to the remotely connected application if you already have some other way of authenticating them? I do suggest you think about authentication of some sort though.
Cheers
Morag _________________ Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Jul 30, 2013 8:48 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
ae06425 wrote: |
Thanks to you all for good info. I do not use SSL or exits. But I use setmqaut. This is to merge 2 apps with 2 userids to use one svrconn. |
You do realize that best practice says "one app, one channel" where svrconn channels are in play. Some even go as far as one app, one role, one svrconn channel...
Think of what happens if you need to stop access to app A but leave access to app B open...
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
|