| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Hub and spoke security |
« View previous topic :: View next topic » |
| Author |
Message
|
| billybong |
 Posted: Tue Nov 14, 2006 6:41 am Post subject: |
 |
|
Disciple
Joined: 22 Jul 2005
Posts: 150
Location: Stockholm, Sweden
|
I said that ALL incoming reciever channels on the hub are locked down with individual MCAUSERS. That means, if manager A is to connect to B trough hub H, the reciever channel on the hub has a MCAUSER = A. A is a user that can only put messages to XMITQ B, not i.e. C.
If neither user A, B or C are in the mqm group or are added as put-authorized to the command queue, there will be no way to send messages to H's command queue. No matter if you're mqm user by running on an unsecure server connection on either spoke.
Oh, and for the hub, no server connections except for one used by admin staff exists. That channel is locked with SSL with individual certs per administrator. For client applications, a separate hub is used as described earlier.
Thanks for your input though.
_________________
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Integration Developer V6.0
IBM Certified System Administrator - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere DataPower |
|
| Back to top |
|
 |
| RogerLacroix |
| Posted: Tue Nov 14, 2006 10:08 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
You appear to have some preconceived notions about how MQ security works and I can tell you flat out that they are wrong.
Have you tested what you described? Because I have many times and it does NOT work as you think it should.
| billybong wrote: |
| I said that ALL incoming reciever channels on the hub are locked down with individual MCAUSERS. That means, if manager A is to connect to B trough hub H, the reciever channel on the hub has a MCAUSER = A. A is a user that can only put messages to XMITQ B, not i.e. C. If neither user A, B or C are in the mqm group or are added as put-authorized to the command queue, there will be no way to send messages to H's command queue. No matter if you're mqm user by running on an unsecure server connection on either spoke. |
Incorrect assumption. Please go and try it. Also, you can try turning on Put Authority too (it won't help).
I'll even give you the setmqaut commands to do 'your' security of Spoke A at the hub QMgr. By your theory, the following is all that should be required for the Spoke A QMgr to put messages to the hub.
At the hub QMgr issue:
| Code: |
setmqaut -m <HubQMgrName> -t qmgr -g spokeA +connect +inq
setmqaut -m <HubQMgrName> -t queue -g spokeA -n SPOKE.A.Q +inq +dsp +put |
You can even try giving full access to the queue (bad idea):
| Code: |
| setmqaut -m <HubQMgrName> -t queue -g spokeA -n SPOKE.A.Q +allmqi |
And it still will not work.  
| billybong wrote: |
| Oh, and for the hub, no server connections except for one used by admin staff exists. That channel is locked with SSL with individual certs per administrator. For client applications, a separate hub is used as described earlier. |
Of course, that is assuming you can secure the Spoke QMgrs. Also, a QMgr can only have one certificate. So, if the keystore is on your PC then it is a no-brainer to steal it. But I would rather use a Spoke QMgr to create a cleint channel on the Hub QMgr (and delete it when I'm done - leave no foot prints).
| billybong wrote: |
| Thanks for your input though. |
After you have spent days or weeks trying to figure out why what you described does not work (most people give up and lie that they got it working), come back and I will explain how security for a MCA really works. It has some strange nuances.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| billybong |
| Posted: Tue Nov 14, 2006 4:19 pm Post subject: |
|
|
Disciple
Joined: 22 Jul 2005
Posts: 150
Location: Stockholm, Sweden
|
| RogerLacroix wrote: |
| And it still will not work. |
What will not work? To route the message in the hub to the other spoke?
We do exactly this as I write this and has had no problems. The spoke user is not a member of the mqm group but a group which only can put to the xmit queue. I'll send the setmqaut script when I get to work (I'm at home right now.., and no you wont get the real names  )
| RogerLacroix wrote: |
| QMgr can only have one certificate. So, if the keystore is on your PC then it is a no-brainer to steal it. But I would rather use a Spoke QMgr to create a cleint channel on the Hub QMgr (and delete it when I'm done - leave no foot prints). |
Assuming you are able to access the command queue as you tell me you will be, right?
And, the queue manager can only have one certificate yes, but it trusts all certificates signed by a certificate in its certificate chain. The administrators certificates are all signed by a root certificate. And they are not stored on the PC. On all our spokes, we only have one channel used by the mqm user/group. That channel is the administrative channel and they use the same SSL configuration as the hub.
| RogerLacroix wrote: |
After you have spent days or weeks trying to figure out why what you described does not work (most people give up and lie that they got it working), come back and I will explain how security for a MCA really works. It has some strange nuances. |
Please explain to me now if you can since I still fail to see the problem in the current configuration. Call me ignorant or stubborn, but you still haven't convinced me how my environment is easily breakable.
_________________
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Integration Developer V6.0
IBM Certified System Administrator - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere DataPower |
|
| Back to top |
|
|
| billybong |
| Posted: Wed Nov 15, 2006 5:54 am Post subject: |
|
|
Disciple
Joined: 22 Jul 2005
Posts: 150
Location: Stockholm, Sweden
|
| RogerLacroix wrote: |
At the hub QMgr issue:
| Code: |
setmqaut -m <HubQMgrName> -t qmgr -g spokeA +connect +inq
setmqaut -m <HubQMgrName> -t queue -g spokeA -n SPOKE.A.Q +inq +dsp +put |
|
Will work, if you add the usual +setall to both the queue and manager auths.
Why? Well, found out you've already asked that 
http://www.mail-archive.com/mqseries@listserv.meduniwien.ac.at/msg03584.html
As stated before, all channels to the hub are reciever channels, not svrconns.
Oh, and yes, the PUTAUT is default, not CTX on the channels.
_________________
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Integration Developer V6.0
IBM Certified System Administrator - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere DataPower |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Nov 15, 2006 8:24 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
First off, that link has nothing to do with your described problem. Its talking about SVRCONN channels and not Receiver channels. (Note: +allmqi INCLUDES +setall and as I stated, Receiver Channel will not work.)
Secondly, if you make statement "A", then I post an answer to your statement "A", you extract a piece of my reply and apply it to statement "C". This is called a circler argument and I do not wish to partake in it.
Sorry but I cannot help you any further via a text based medium. We cannot seem to connect so that I can get you to understand my concerns.
If you want I will give you a free 30-45 minute consultation call and we can go over point by point your 2 posting of: 10 Nov 2006 09:16 and 10 Nov 2006 10:28.
Send me an email and we can arrange something consequently, I will not be reading / participating in this thread any more.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| billybong |
| Posted: Wed Nov 15, 2006 1:17 pm Post subject: |
|
|
Disciple
Joined: 22 Jul 2005
Posts: 150
Location: Stockholm, Sweden
|
Hey Roger.
Now you're being a little bit too grumpy for your own good.
I've never wanted this thread to become heated and if I knew it would've been I would probably not have started it.
1) The link I included was about why RCVR and RQSTR channels needs the +setall authority when SVRCONN does not, and how the context is used in the different channels. So, its in fact about all three, but the part I was interested about was about the RCVR's.
2) Reciever channels do work. It's not such an advanced issue really, just basic message hopping. I dont know how to prove it except that me and my client know for sure that it does. All you have to set is +connect +setall on qmgr, and +put +setall on the xmit queue, for the channel MCAUSER. You HAVE to set +setall on the qmgr as well, not only on the queue as you did with the +allmqi script. If the qmgr is not +setall the queue +setall is for naught.
3) I thank you for your offer though I'm not particulary interested. You've been bragging in the thread and are short of calling me an idiot. I dont think I deserve that since I'm just trying to ask a simple question. I have never tried to insult you or your company in any way, and if you feel that way there must be a misunderstanding somewhere. If you still feel that you have some kind of issue with me, please pm me and we could probably work it out.
Anyway, I've gotten all my questions answered, so thank you all who has participated with your answers. That includes you, Roger.
_________________
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Integration Developer V6.0
IBM Certified System Administrator - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere DataPower |
|
| 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
|
|
|
|
