| Author |
Message
|
| Sam Uppu |
 Posted: Sun Mar 15, 2009 2:31 pm Post subject: MQ Security setup |
 |
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
Hi Guys,
I am on SunOS and version 6.
I have 2 QMgrs, QM.LONDON which is in London and QM.PARIS which is in Paris and both these QMgrs are in a cluster called CLUSTER1.
An application with application id: App1 is connecting to Qmgr, QM.LONDON and on the destination side, another application with application id: App2 is connected to QM.PARIS.
A cluster queue, CLUSTERQ is defined on QM.PARIS and the permissions are provided for the user, App2 for the queue, CLUSTERQ(put/get/browse) and for the QMgr, QM.PARIS(connect).
The application 1(Application id: App1) is trying to put the message onto CLUSTERQ on QM.PARIS.
As the user ids, App1 & App2 are not part of mqm group - an Alias queue named, ALIAS.CLUSTERQ(targetq: CLUSTERQ) is defined on QM.LONDON and provided permissions for the user, App1 for the queue ALIAS.CLUSTERQ(put) and for the QMgr, QM.LONDON(connect).
Now the Question:
Do I also need to set the MCAUSER and PUTAUT parameters of ClusterReceiver(CLUSRCVR) channel on QM.PARIS?. If so what do I need to set these parameters?.
I tried something like this:
MCAUSER(dummy) PUTAUT(CTX)....still the user App1 is able to put the message onto CLUSTERQ.
MCAUSER(dummy) PUTAUT(Def)....still the user App1 is able to put the message onto CLUSTERQ.
Note: The user: dummy doesn't exists on server where the Qmgr, QM.PARIS is running.
Please share your thoughts to close the security holes in my cluster.
Thanks. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Sun Mar 15, 2009 3:13 pm Post subject: Re: MQ Security setup |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam Uppu wrote: |
As the user ids, App1 & App2 are not part of mqm group - an Alias queue named, ALIAS.CLUSTERQ(targetq: CLUSTERQ) is defined on QM.LONDON and provided permissions for the user, App1 for the queue ALIAS.CLUSTERQ(put) and for the QMgr, QM.LONDON(connect).
|
Why an alias? Why not provide permissions for the underlying queue?
| Sam Uppu wrote: |
| Please share your thoughts to close the security holes in my cluster. |
Why do you think these are holes? Why are you trying to distinguish users like this?
Also remember that data doesn't pass over manually defiened cluster channels, and the rules for setting parameters differ.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Sun Mar 15, 2009 5:01 pm Post subject: Re: MQ Security setup |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| Vitor wrote: |
| Sam Uppu wrote: |
As the user ids, App1 & App2 are not part of mqm group - an Alias queue named, ALIAS.CLUSTERQ(targetq: CLUSTERQ) is defined on QM.LONDON and provided permissions for the user, App1 for the queue ALIAS.CLUSTERQ(put) and for the QMgr, QM.LONDON(connect).
|
Why an alias? Why not provide permissions for the underlying queue?
| Sam Uppu wrote: |
| Please share your thoughts to close the security holes in my cluster. |
Why do you think these are holes? Why are you trying to distinguish users like this?
Also remember that data doesn't pass over manually defiened cluster channels, and the rules for setting parameters differ. |
| Quote: |
| Why an alias? Why not provide permissions for the underlying queue? |
The applications are remote and used ids, App1 and App2 doesn't exist on remote application servers,
App1 resides only on server where QM.LONDON is running and App2 resides on server where QM.PARIS is running.
So I cant provide the permissions for the App1 user on the QMgr-QM.PARIS as the user doesn't exists on this server and the same case applies to App2 user.
Thanks. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Mar 16, 2009 12:34 am Post subject: Re: MQ Security setup |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam Uppu wrote: |
| So I cant provide the permissions for the App1 user on the QMgr-QM.PARIS as the user doesn't exists on this server and the same case applies to App2 user. |
Yes, granted, but what's the requirement to authenticate against the target queue? Why are you attempting that?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Mar 16, 2009 1:39 am Post subject: Re: MQ Security setup |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
| Sam Uppu wrote: |
As the user ids, App1 & App2 are not part of mqm group - an Alias queue named, ALIAS.CLUSTERQ(targetq: CLUSTERQ) is defined on QM.LONDON and provided permissions for the user, App1 for the queue ALIAS.CLUSTERQ(put) and for the QMgr, QM.LONDON(connect).
|
Why an alias? Why not provide permissions for the underlying queue? |
It is my understanding that permission for the application connected to QM.LONDON to PUT to the SYSTEM.CLUSTER.TRANSMIT.QUEUE would be needed, ergo security hole.
| Vitor wrote: |
| Sam Uppu wrote: |
| Please share your thoughts to close the security holes in my cluster. |
Why do you think these are holes? Why are you trying to distinguish users like this? |
_________________
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 |
|
|
| fjb_saper |
| Posted: Mon Mar 16, 2009 2:48 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Cluster security is a strange animal that is quite complicated.
- looking at your first example with cluster receiver channel mca...
Did you STOP the cluster receiver channel and restart it every time you changed the mcauser?
- you don't want to authorize the SYSTEM.CLUSTER.TRANSMIT.QUEUE so what are your alternatives?
You can declare a qremote on the qmgrs that don't have a local instance of the queue, but that are being connected to by the client, to serve as an alias for the clustered queue, and authorize that queue... ex:
def qr(myalias) qname(myclusterq) qmname('clusteralias')
def qr(clusteralias) qname(' ') qmname(' ') cluster(mycluster)
This will then give the poster authority to post to the qr which resolves to a clustered queue.
Make sure when using this technique that you have no message affinity.
Make sure to use the proper bindings (fixed|not fixed).
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Mar 16, 2009 4:23 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
def qr(myalias) qname(myclusterq) qmname('clusteralias')
def qr(clusteralias) qname(' ') qmname(' ') cluster(mycluster)
|
FJ, you define the clusteralias qr on the sending QM, or on the destination QM? Or on every QM in the cluster?
Instead of using the qr called myalias, which requires the qr clusteralias as well, could you not accomplish the same thing with only one Alias queue? If the local queue on the destination QM is called MY.APP.QUEUE and it is clustered, define this on the sending queue:
DEFINE QALIAS(THE.APP.QUEUE) TARGQ(MY.APP.QUEUE)
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Mon Mar 16, 2009 7:46 am Post subject: Re: MQ Security setup |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| Vitor wrote: |
| Sam Uppu wrote: |
As the user ids, App1 & App2 are not part of mqm group - an Alias queue named, ALIAS.CLUSTERQ(targetq: CLUSTERQ) is defined on QM.LONDON and provided permissions for the user, App1 for the queue ALIAS.CLUSTERQ(put) and for the QMgr, QM.LONDON(connect).
|
Why an alias? Why not provide permissions for the underlying queue?
| Sam Uppu wrote: |
| Please share your thoughts to close the security holes in my cluster. |
Why do you think these are holes? Why are you trying to distinguish users like this?
Also remember that data doesn't pass over manually defiened cluster channels, and the rules for setting parameters differ. |
| Quote: |
| Also remember that data doesn't pass over manually defiened cluster channels, and the rules for setting parameters differ |
Are you sure?. I thought the Cluster sender/receiver channels will be used for data transfer and also talking with other repositories in the cluster.
Let me know..thanks. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Mar 16, 2009 7:53 am Post subject: Re: MQ Security setup |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam Uppu wrote: |
| Are you sure?. I thought the Cluster sender/receiver channels will be used for data transfer and also talking with other repositories in the cluster. |
Manually defined channels connect partial repositories with full repositories (and of course full repositories with full repositories).
It's the auto-defined channels that carry data, linking source and target on request.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Mar 16, 2009 8:04 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Manually defined channels are more or less only actually run once, and basically just long enough to register the channels. Unless you run REFRESH CLUSTER a lot.
Autodefs are then created from the manual def after that, and carry all cluster traffic. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Mon Mar 16, 2009 11:40 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| PeterPotkay wrote: |
| fjb_saper wrote: |
def qr(myalias) qname(myclusterq) qmname('clusteralias')
def qr(clusteralias) qname(' ') qmname(' ') cluster(mycluster)
|
FJ, you define the clusteralias qr on the sending QM, or on the destination QM? Or on every QM in the cluster?
Instead of using the qr called myalias, which requires the qr clusteralias as well, could you not accomplish the same thing with only one Alias queue? If the local queue on the destination QM is called MY.APP.QUEUE and it is clustered, define this on the sending queue:
DEFINE QALIAS(THE.APP.QUEUE) TARGQ(MY.APP.QUEUE) |
I am also creating the Local Alias Queue for the remote cluster queue and not a remote queue. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Mon Mar 16, 2009 11:46 am Post subject: Re: MQ Security setup |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| Vitor wrote: |
| Sam Uppu wrote: |
| So I cant provide the permissions for the App1 user on the QMgr-QM.PARIS as the user doesn't exists on this server and the same case applies to App2 user. |
Yes, granted, but what's the requirement to authenticate against the target queue? Why are you attempting that? |
I have seen one of the IBM PPT:
| Quote: |
| Setting MCAUSER on an inbound MCA channel (RCVR, RQSTR or CLUSRCVR) to a low-privileged ID enables the ability to restrict that channel to accessing only specific queues. |
Thatswhy I was trying to fill in the MCAUSER of Cluster receiver channel on the QM.PARIS QMgr. I am planning to fill in this MCAUSER with App2 id as this id exists on the server where QM.PARIS is running and PUTAUT to be DEF.
Let me know your thoughts.
Thanks. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Mon Mar 16, 2009 12:00 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
If I define a cluster receiver channel with MCAUSER('dummy'), the channel is not starting and its always in inactive state. If I set the MCAUSER('') attribute to be empty, the channel is again starting. Not sure why IBM had this MCAUSER parameter when there is no need to use this attribute and channel goes into inactive state.
Please let me know your thoughts.
Thanks. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Mar 16, 2009 1:37 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
MCASUER is used on Cluster Receiver channels.
PUTAUT = CTX is a waste of time and false security.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Mar 16, 2009 2:43 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| If I define a cluster receiver channel with MCAUSER('dummy'), the channel is not starting and its always in inactive state. |
What did you find in the qmgr error logs that explained 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 |
|
|
|
|
