| Author |
Message
|
| kishi_25 |
 Posted: Fri Jul 19, 2013 12:52 pm Post subject: mq authorization through serverconn channel |
 |
|
Centurion
Joined: 19 Jul 2011
Posts: 100
|
hi,
1) I have a client application connecting using a serverconn channel TEST.SVRCONN defined on MQ server on windows. I have defined mcauser id "MCATEST" on TEST.SVRCONN and have given authorization to all related application queues TEST.QUEUES.* with id "MCATEST".
Now, if the application connects with userid "user A", it will be converted to "MCATEST" and based on priviliges given to MCATEST application can get access to related application queues.
Now, my question is when the application makes connection, whether the userid User A from application will be verified for authentication at OS level on MQServer ?.
I'm thinking before the userid "user A" gets converted to MCATEST on SVRCONN, it will be authenticated by OS, and if it's verified successful, the connection can make..else, the connection will fail..
is this true?
2) In Infocenter, it was specified as the authorization to MQ objects will be given for group ids except for windows ..why is it like this? why can't we give authorization to groups in windows also? |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri Jul 19, 2013 2:00 pm Post subject: Re: mq authorization through serverconn channel |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| kishi_25 wrote: |
I'm thinking before the userid "user A" gets converted to MCATEST on SVRCONN, it will be authenticated by OS, and if it's verified successful, the connection can make..else, the connection will fail..
is this true? |
There is no conversion. WMQ does not do authentication.
The channel attribute MCAUSER(MCATEST) gives the SVRCONN channel an identity that will be used (passed to OAM) to determine if a rule exists to grant authorization to the object.
If there is no security exit at either end of the MQI channel, AND if MCAUSER is non-blank, then the MCAUSER() value will be used. If MCAUSER is blank, then the flowed user ID will be used.
_________________
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.
Last edited by bruce2359 on Fri Jul 19, 2013 2:07 pm; edited 1 time in total |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jul 19, 2013 2:01 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Moved to Security forum.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Fri Jul 19, 2013 3:05 pm Post subject: Re: mq authorization through serverconn channel |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| kishi_25 wrote: |
hi,
2) In Infocenter, it was specified as the authorization to MQ objects will be given for group ids except for windows ..why is it like this? why can't we give authorization to groups in windows also? |
Provide the link that says you can't set MQ authorization on Windows. We'll need to get that documentation fixed.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| kishi_25 |
| Posted: Thu Aug 08, 2013 1:54 pm Post subject: |
|
|
Centurion
Joined: 19 Jul 2011
Posts: 100
|
hi Bruce,
Sorry I couldn't get back to you quickly.
Is my below understanding is correct,
If MCAUSER id is non-blanck (MCATEST ourcase), since it's local it will be authenticated and based on the authorizations the access will be granted.
If MCAUSER id is blank, authorization will be done against the flowed userid and for this case, there wont be authentication unless some security exit exists(since it's remote connection)
Peter,
I will check this link in infocenter and get back to you |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu Aug 08, 2013 3:26 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| kishi_25 wrote: |
| If MCAUSER id is non-blanck (MCATEST ourcase), since it's local it will be authenticated and based on the authorizations the access will be granted. |
The queue manager does NOT provide authentication - you must use a security exit.
1) If the MCAUSER is non-blank then the connection will use the UserID from the MCAUSER field and the authorization will be applied against it. (no authentication).
2) If the MCAUSER is blank and the client application has set a UserID then the connection will use the UserID from the client application and the authorization will be applied against it. (no authentication).
3) If the MCAUSER is blank and the client application has NOT set a UserID then the connection will use the queue manager's (MCA's) UserID and the authorization will be applied against it. (no authentication). This is the great big security hole that everyone should worry about. Basically, this means the client application gets full access to the queue manager because it is running under "mqm".
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu Aug 08, 2013 4:21 pm Post subject: Re: mq authorization through serverconn channel |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| kishi_25 wrote: |
hi,
2) In Infocenter, it was specified as the authorization to MQ objects will be given for group ids except for windows ..why is it like this? why can't we give authorization to groups in windows also? |
The Infocenter says that authorization to MQ objects on Windows can be given to userids, but authorization can also be given to groups.
I suggest that you should not use userid authorization on Windows. MQ actually stores the userid's SID in the OAM profile. If you delete the userid from Windows it leaves a orphan authorization profile that cannot be deleted. If you recreate the userid, you will need to reapply the authorization, as the userid will have a different SID.
_________________
Glenn |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Aug 09, 2013 4:57 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
|
| Back to top |
|
|
| exerk |
| Posted: Fri Aug 09, 2013 6:06 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Anybody else feel that IBM's use of the term CHANNEL AUTHENTICATION RECORD is further muddying the waters?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Aug 09, 2013 6:21 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| exerk wrote: |
| Anybody else feel that IBM's use of the term CHANNEL AUTHENTICATION RECORD is further muddying the waters? |
My initial annoyance was with calling them RECORD. RECORDs? Really?
I know that they are not objects. Rather, they are rules or policies or filters.
_________________
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.
Last edited by bruce2359 on Fri Aug 09, 2013 6:29 am; edited 1 time in total |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Aug 09, 2013 6:21 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| exerk wrote: |
| Anybody else feel that IBM's use of the term CHANNEL AUTHENTICATION RECORD is further muddying the waters? |
Oh boy, you had to go there....
But yes.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Aug 09, 2013 6:45 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| PeterPotkay wrote: |
| exerk wrote: |
| Anybody else feel that IBM's use of the term CHANNEL AUTHENTICATION RECORD is further muddying the waters? |
Oh boy, you had to go there....
But yes. |
I've never shrunk away from dropping the occasional hand-grenade, or being a social hand-grenade for that matter, ...
...and then running away like mad 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 09, 2013 8:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| I know that they are not objects. |
That's a meaningless academic distinction.
It's absolutely stupid to treat chl auth records as anything different than queues or chanenls, and it's twice as stupid to think that you should manage them in MQSC using SET rather than DEFINE/ALTER/DELETE.
There's simply no good reason to make this internal distinction visible to any user interface - and I promise that MQSC is a user interface.
It's not like they were in any danger of running out of allowable values for an MQLONG. |
|
| Back to top |
|
|
| hughson |
| Posted: Fri Aug 09, 2013 8:37 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
What a can a worms you opened there huh?
For the record, CHLAUTHs were model on AUTHRECs, hence the SET command.
This was so that you could have wildcard patterns in the primary keyword, e.g. SET CHLAUTH(*.SVRCONN). We contemplated DEFINE/ALTER etc commands, but since you'd need another name for each rule as well as the pattern for the channel, we thought that was a bit OTT. Also since it was related to security, making it match the other security config seemed appropriate. I'm sorry you don't like it.
Cheers
Morag
<Sits back and waits for onslaught>
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| kishi_25 |
| Posted: Fri Aug 09, 2013 8:47 am Post subject: |
|
|
Centurion
Joined: 19 Jul 2011
Posts: 100
|
hi Roger/Burce,
If MCAUSEr is non-blank, I'm thinking authentication will be done by OS, as specified below and related IBM doc is
Section 3.2.1 of
http://www.redbooks.ibm.com/redbooks/pdfs/sg248069.pdf
"The original design of WebSphere MQ was as a transport stack that was used by local programs. Since all connections to the queue manager originated locally, the identities in the operating system’s process table were the basis for authorization. WebSphere MQ did not
perform any authentication since any process requesting a connection must have been authenticated by the operating system. Queue manager connections that arrive over shared memory rather than the network are known as bindings mode connections. Current versions
of WebSphere MQ continue to support bindings mode connections and these connections rely on the local operating system’s process ID for authentication and identity"
What's your thoughts on this? |
|
| Back to top |
|
|
|
|
characters.
