| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| QMgr-to-QMgr security |
View previous topic :: View next topic |
| Author |
Message
|
| bruce2359 |
 Posted: Wed Aug 18, 2010 10:00 am Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
Try this: [all] security for mq is local - local to the qmgr where the application executes and creates the message.
At MQCONN, MQOPEN (or equivalents), and at other times, the qmgr passes to the external security manager (OAM, RACF, etc.) to determine if there is sufficient authority to access the local object (qmgr, xmit queue, etc.) in the intent specified.
If the message travels down a qmgr-qmgr channel, it has left the local qmgr. It is now on the remote qmgr. Authorization does not flow with the message.
So, the question becomes: on whose authority does the Message Channel Agent (MCA) at the receiving end of the channel put the message to the destination queue? The effective userid of the MCA or the Context fields in MQMD are possible usernames to determine if the MCA has authority to MQOPEN and MQPUT to the destination queue.
_________________
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 |
|
 |
| Api123 |
| Posted: Wed Aug 18, 2010 10:50 am Post subject: |
|
|
Apprentice
Joined: 26 May 2010
Posts: 31
|
| mqjeff wrote: |
| Api123 wrote: |
What does this mean? What is getting replaced and with what?
If ABC123 is the MCAUSER defined for a RCVR channel with PUTAUT(CTX). User ABC100 tries to put a message vi that channel what happens? Can you explain please? |
If PUTAUT is set to CTX, then whatever value is specified in the MQMD.UserId field is used to authorize the user to the specified resource.
You do not have any control over the sender of the message, so this means that anyone at all can create a message with a UserID of 'mqm', and have full authority to everything on your queue manager.
|
Let’s clarify this: in the sending application is MQMD.UserId field is the UserIdentifier field in MQMD (java) or [MessageObject] UserId in (.net) ?
| mqjeff wrote: |
I hope you understand that the above situation is bad.
|
Yes, if any member of mqm will have an access vi RCVR channel regardless of MCAUSER setting in that channel!
| mqjeff wrote: |
If PUTAUT is left at Default, and you have set MCAUSER(ABC123), then every message, regardless of what is put into it, will be authorized against whatever permissions the user ABC123 has.
This is limiting, in that it means every application on the sending side has access to all queues that the user ABC123 has access to. But it's significantly better and a significantly smaller set than EVERY QUEUE ON THE QMGR. |
With below channel definition only test_B is able to put messages. No mqm or administrator member is allowed. I'm sure I've tested this
unless the MQMD field is different than what I mentioned above.
If PUTAUT(DEF) any one with of course proper permission on the queues is allowed to put messages. In this case MACUSER setting is ineffective
***********************************
DEFINE CHANNEL ('TCP.MAP1.PCSQ01.001') CHLTYPE(RCVR) +
* ALTDATE (2010-08-17) +
* ALTTIME (10.01.04) +
TRPTYPE(TCP) +
BATCHSZ(50) +
DESCR(' ') +
HBINT(300) +
MAXMSGL(4194304) +
MCAUSER('test_B') +
MRDATA(' ') +
MREXIT(' ') +
MRRTY(10) +
MRTMR(1000) +
MSGDATA(' ') +
MSGEXIT(' ') +
NPMSPEED(FAST) +
PUTAUT(CTX) +
RCVDATA(' ') +
RCVEXIT(' ') +
SCYDATA(' ') +
SCYEXIT(' ') +
SENDDATA(' ') +
SENDEXIT(' ') +
SEQWRAP(999999999) +
SSLCAUTH(OPTIONAL) +
SSLCIPH(' ') +
SSLPEER(' ') +
KAINT(AUTO) +
MONCHL(QMGR) +
STATCHL(QMGR) +
COMPMSG(NONE) +
COMPHDR(NONE) +
REPLACE |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Aug 18, 2010 11:08 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
I strongly suggest that you refer to the WMQ INTERCOMMUNICATIONS manual, where PUTAUT and other channel attributes are explained.
_________________
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 |
|
|
| Api123 |
| Posted: Wed Aug 18, 2010 11:30 am Post subject: |
|
|
Apprentice
Joined: 26 May 2010
Posts: 31
|
| bruce2359 wrote: |
| I strongly suggest that you refer to the WMQ INTERCOMMUNICATIONS manual, where PUTAUT and other channel attributes are explained. |
Thanks. I thinks it's page 94 WebSphere MQ: Intercommunication |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Aug 18, 2010 11:38 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
The MCA is just another WMQ application - a process, a daemon. It uses the same MQI calls that any other application would use.
The MCA process needs an identity, a username/userid. It may take on the identity of the process that started it, like the listener process. It may take on the identity you specify in MCAUSER. It may take on CTX or MCAONLY, or some combination, as it does its daemon-like thing - acting as a channel agent.
The manual describes which possible identity/identities are 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. |
|
| Back to top |
|
|
| Api123 |
| Posted: Wed Aug 18, 2010 12:00 pm Post subject: |
|
|
Apprentice
Joined: 26 May 2010
Posts: 31
|
| bruce2359 wrote: |
The MCA is just another WMQ application - a process, a daemon. It uses the same MQI calls that any other application would use.
The MCA process needs an identity, a username/userid. It may take on the identity of the process that started it, like the listener process. It may take on the identity you specify in MCAUSER. It may take on CTX or MCAONLY, or some combination, as it does its daemon-like thing - acting as a channel agent.
The manual describes which possible identity/identities are will be used. |
Great.
let’s say a member of mqm group ABC123
In my application the value of UserIdentifier in the message descriptor set to ABC123
A RCVR channel with MCAUSER set to “SOMEONE” and PUTAUT(CTX). What would happen to put messages from my application? Would it succeed or fail? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Aug 18, 2010 12:26 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| let’s say a member of mqm group ABC123 |
I'm not sure exactly what you are saying.
| Quote: |
| A RCVR channel with MCAUSER set to “SOMEONE” and PUTAUT(CTX). What would happen to put messages from my application? Would it succeed or fail? |
Your application is on the sending end, not on the receiving end of the channel. RVCR channel definitions do not apply to SDR end applications.
At the receiving end of the channel two different security things are going on:
1) 'SOMEONE' must have authority for the MCA to MQCONN to the qmgr.
2) CTX tells the MCA to use the alternate userid ABC123 in the open options for the destination queue.
User and group membership behave differently on Win vs. UNIX. Which are you at the RCVR end? At the SDR end?
_________________
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 |
|
|
| Vitor |
| Posted: Wed Aug 18, 2010 12:52 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Api123 wrote: |
| let’s say a member of mqm group ABC123 |
This is tautological. You can't be a member of "mqm group ABC123" (aside from the fact WMQ doesn't have groups). You're either a member of group mqm or a member of group ABC123 or both. One of these group memberships (unless you're on Windows) will be used to determine authorities against the queue manager.
| Api123 wrote: |
| In my application the value of UserIdentifier in the message descriptor set to ABC123 |
See my comments above. Neither the UserIdentifier nor the MCAUser take a group name, but take an id.
| Api123 wrote: |
| A RCVR channel with MCAUSER set to “SOMEONE” and PUTAUT(CTX). What would happen to put messages from my application? Would it succeed or fail? |
Success or failure depends on what authorities the ABC123 user has once name & group resolution has been done at the receiving end.
If they specify mqm rather than ABC123 success is guaranteed. This (as my worthy associate pointed out earlier) is not a good thing.
Why are you still banging away at this? What, exactly, are you trying to secure? What scenario, exactly, are you trying to prevent?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Aug 18, 2010 1:12 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| This is limiting, in that it means every application on the sending side has access to all queues that the user ABC123 has access to. But it's significantly better and a significantly smaller set than EVERY QUEUE ON THE QMGR. |
Access to the xmit queue on the SDR end of the channel is controlled by the applications attempt to MQOPEN a QRemote definition (on the SDR qmgr) that resolves to the SDR channel xmit queue.
Once a message is on the xmit queue, it will be sent to the RCVR end of the channel.
_________________
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 |
|
|
| Api123 |
| Posted: Thu Aug 19, 2010 7:01 am Post subject: |
|
|
Apprentice
Joined: 26 May 2010
Posts: 31
|
The POC environment we testing on is Windows. In this post any time mqm was mentioned, it’s a Windows group that by default have higher set of privileges on WMQ objects. Any Time a user was mentioned it meant a Windows user ID that is member of mqm group or just Windows user.
The objective was to use MCAUSER attribute of the RCVR channel. To restrict who can and cannot put messages in a queue. This includes any user id who is a member of mqm group.
The reason is: With the default channel settings of PUTAUT(DEF)and MCAUSER(' '), messages arrive with full administrative authority.
Refrencing: http://www.ibm.com/developerworks/websphere/techjournal/0701_col_wyatt/0701_col_wyatt.html
All messages are put by MQI client application to a transition QM then routed vi SND channel to the RCVR channel.
To summaries, my issue was my lack of knowledge of how PUTAUT(CTX|DEF) works on RCVR channel. Defiantly it’s different than SVRCONN ”At least in my little head ”.
It’s all working now. Thanks for your continues help |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Aug 19, 2010 7:58 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| To summaries, my issue was my lack of knowledge of how PUTAUT(CTX|DEF) works on RCVR channel. |
This has been explained in replies to your post; and is further explained in the official IBM WMQ manuals.
You referenced a T-Rob post, but didn't indicate which paragraph or sentence you believe is relevant to this discussion.
SVRCONN channels are used by client-bound apps. The WMQ client software on the client platform ships the MQI call to the SVRCONN channel; and the SVRCONN channel acts as an agent, and executes the MQI call on behalf of the client app.
It makes no difference if the originating application is a client app or not. All MQI calls in a client app are executed on the qmgr the app MQCONNects to. This is really no different than a server-bound app.
_________________
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 |
|
|
| bruce2359 |
| Posted: Thu Aug 19, 2010 8:26 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| It’s all working now. |
What's all working now?
For the benefit of all that visit mqseries.net, please explain how you resolved this.
_________________
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 |
|
|
| Api123 |
| Posted: Thu Aug 19, 2010 9:41 am Post subject: |
|
|
Apprentice
Joined: 26 May 2010
Posts: 31
|
| bruce2359 wrote: |
| Quote: |
| It’s all working now. |
For the benefit of all that visit mqseries.net, please explain how you resolved this. |
Here it's:
Objective described:
Api123
Posted: Mon Aug 16, 2010 9:27 am Post subject: QMgr-to-QMgr security
Suggested resolution to the issue:
RogerLacroix
Posted: Mon Aug 16, 2010 2:38 pm Post subject: Re: QMgr-to-QMgr security
Solution acknowledged:
Api123
Posted: Tue Aug 17, 2010 6:23 am Post subject:
Valid concerns:
PeterPotkay
Posted: Wed Aug 18, 2010 3:40 am Post subject:
Objective and solution described again:
Api123
Posted: Thu Aug 19, 2010 7:01 am Post subject: |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Aug 19, 2010 10:43 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
Wow. You certainly went out of your way to make this difficult. You could have posted URLs or actually taken the time to answer my question with an actual answer.
Given the valuable time and effort we put in to helping you, I expected more.
I'll keep this in mind for your future posts.
_________________
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 |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
