| Author |
Message
|
| fjb_saper |
 Posted: Wed Sep 02, 2009 5:46 am Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
| Monk wrote: |
How will creating alias queues and pointing them to clusters queue help my requirements?.
QM2 can still see all the cluster queues locally defined on QM1 , irrespective of creating alias queues?
Am I missing something here? |
Overlapping clusters perhaps? 
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| shashivarungupta |
| Posted: Wed Sep 02, 2009 5:53 am Post subject: Re: How can I control security within a single cluster? |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| Monk wrote: |
Hi All,
How can I control security within a single cluster?....
.... but I need to control authorization for each parties queues.
|
HINT : Keep in mind Authorization(Y/N) of SYSTEM.CLUSTER.TRANSMIT.QUEUE.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Wed Sep 02, 2009 6:12 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
You will see the cluster queues in all of the cluster queue managers but you can restrict the access to that particular queue from applications.
If the application try to PUT a msg to a cluster queue by providing the QMgrName in the MQOD(sending msg to a particular cluster queue on a particular qmgr), then the PUTing application needs permissions to SCTQ otherwise defining Alias queue and providing the permissions to Alias queue will resolve the authorization.
In clustering the authorization is always on the destination QMgr/ queue side whereas in normal point to point communication the authorization is on sending side.
In clustering on the CLUSRCVR channel provide the low privileged user in MCAUSER and PUTAUT(DEF) will restrict access.
Thanks. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Sep 02, 2009 6:21 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| In clustering the authorization is always on the destination QMgr/ queue side whereas in normal point to point communication the authorization is on sending side. |
An odd statement.
Cluster channels are point-to-point channels. And, authorization takes place on both ends of point-to-point channels - at MQOPEN of the q definition on the sending end, and at theMQOPEN of the destination queue at the receiving 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 |
|
|
| exerk |
| Posted: Wed Sep 02, 2009 6:21 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Sam Uppu wrote: |
| You will see the cluster queues in all of the cluster queue managers but you can restrict the access to that particular queue from applications. |
No, you won't! Only in the FR's will you be able to do so, the PR's will have absolutely NO knowledge of cluster queues until such time they first reference them - again, think before posting!
_________________
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 |
|
|
| Sam Uppu |
| Posted: Wed Sep 02, 2009 6:28 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
Clustering request/ reply model – Security
1. Request:
On the request side, the app is not providing the QMgr name in the MQOD.
An Alias queue needs to be created on the source qmgr by specifying the targetq being the request queue(service provider) and provide the permissions to the source application id to the Alias queue.
On the service provider side, set the local user id of the service provider in the MCAUSER of cluster receiver channel and provide +setall permissions. The PUTAUT(DEF) and not the CTX.
2. Reply:
When the service provider replies to the ReplyToQueue by specifying the ReplyToQMgr, then the service provider app id needs permissions(+put) to SCTQ on the service provider qmgr.
On the service requester side, mention the local user id in MCAUSER of cluster receiver channel and PUTAUT(DEF) which is a default. Don’t use PUTAUT(CTX).
Provide the permissions(+setall) to the local user id to the queues/ qmgr.
Note: When the application wants to PUT a msg to a particular cluster queue to a selected qmgr within the cluster by providing the qmgr name in its MQOD, that application id needs permissions(+put) to SCTQ.
We need to set the local user id(low privileged user id) on the cluster receiver’s MCAUSER and provide the permissions to that user on the qmgr and queues. Don’t forget to provide the permissions(+setall) for the user on the qmgr and queue objects.
References:
http://www.mqseries.net/phpBB2/viewtopic.php?t=48209&postdays=0&postorder=asc&start=0
http://t-rob.net/2008/07/08/websphere-mq-security-heats-up/
Qmgr name resolution table(IBM website) |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Wed Sep 02, 2009 6:33 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| exerk wrote: |
| Sam Uppu wrote: |
| You will see the cluster queues in all of the cluster queue managers but you can restrict the access to that particular queue from applications. |
No, you won't! Only in the FR's will you be able to do so, the PR's will have absolutely NO knowledge of cluster queues until such time they first reference them - again, think before posting! |
I agree with your statements. In the QM!, QM2, QM# qmgrs we dont know which is FR and which PR. It could be FR where he doesn't want to have the cluster queue not to show up. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Wed Sep 02, 2009 6:36 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| bruce2359 wrote: |
| Quote: |
| In clustering the authorization is always on the destination QMgr/ queue side whereas in normal point to point communication the authorization is on sending side. |
An odd statement.
Cluster channels are point-to-point channels. And, authorization takes place on both ends of point-to-point channels - at MQOPEN of the q definition on the sending end, and at theMQOPEN of the destination queue at the receiving end. |
Sorry for not being clear in my description, On the source side we DO need permissions to SCTQ if the app is providing the QMgr name in MQOD. At the same time we have to provide the low privileged user in MCAUSER of the CLUSRCVR channel with PUTAUT(DEF).
If the app is not providing the QMgr name in MQOD then an Alias or remote queue locally for a cluster queue and providing the permissions to Alias/ remote queue would work. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Sep 02, 2009 6:39 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Sam Uppu wrote: |
| I agree with your statements... |
Good start, then:
| Sam Uppu wrote: |
| ...In the QM!, QM2, QM# qmgrs we dont know which is FR and which PR. It could be FR where he doesn't want to have the cluster queue not to show up. |
Do you even read documentation? To help you understand the concepts of clustering, remember the following:
"Full Repository queue managers know all about the cluster all of the time, but Partial Repository queue managers only know what they need to know, when they need to know it, and then remember"
Now, just how on this earth could a Full Repository queue manager function as such if it didn't know about all the objects? 
_________________
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 |
|
|
| Sam Uppu |
| Posted: Wed Sep 02, 2009 6:53 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
Exerk,
I know what an FR and a PR is and I agree with your statements.
Monk was asking not to show up the cluster queue on some of the queue managers. All I was saying if it is a FR, we can't restrict the cluster queue not to show up in FR and PR the cluster queue wont show up until there is some activity happens with that queue. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Wed Sep 02, 2009 7:43 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| bruce2359 wrote: |
| Quote: |
| In clustering the authorization is always on the destination QMgr/ queue side whereas in normal point to point communication the authorization is on sending side. |
Cluster channels are point-to-point channels. And, authorization takes place on both ends of point-to-point channels - at MQOPEN of the q definition on the sending end, and at theMQOPEN of the destination queue at the receiving end. |
As far as mq cluster security is concerned.....
There is a Message Channel Agent (MCA) at each end of the channel. The MCA is a component that handles the sending and receiving of messages between queue managers. Before the MCA can send and receive messages, the UserId and Password must be authenticated as detailed below:
*The MCA that is running the Cluster-Sender channel will call client-side security exit to send a security message that contains the UserId and Password across the channel to the Cluster-Receiver channel.
*The MCA that is running the Cluster-Receiver channel will call server-side security exit to authenticate the incoming UserId and Password.
Suggestion: You can have a look at Capitalware Manuals for the Cluster Security Exit for the Better and Clear Understanding.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Wed Sep 02, 2009 7:50 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| shashivarungupta wrote: |
| bruce2359 wrote: |
| Quote: |
| In clustering the authorization is always on the destination QMgr/ queue side whereas in normal point to point communication the authorization is on sending side. |
Cluster channels are point-to-point channels. And, authorization takes place on both ends of point-to-point channels - at MQOPEN of the q definition on the sending end, and at theMQOPEN of the destination queue at the receiving end. |
As far as mq cluster security is concerned.....
There is a Message Channel Agent (MCA) at each end of the channel. The MCA is a component that handles the sending and receiving of messages between queue managers. Before the MCA can send and receive messages, the UserId and Password must be authenticated as detailed below:
*The MCA that is running the Cluster-Sender channel will call client-side security exit to send a security message that contains the UserId and Password across the channel to the Cluster-Receiver channel.
*The MCA that is running the Cluster-Receiver channel will call server-side security exit to authenticate the incoming UserId and Password.
Suggestion: You can have a look at Capitalware Manuals for the Cluster Security Exit for the Better and Clear Understanding. |
What if we dont use the Capitalware's security exit?. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Sep 02, 2009 7:53 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Sam Uppu wrote: |
| ...What if we dont use the Capitalware's security exit?. |
Write an maintain your own...
_________________
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: Wed Sep 02, 2009 7:54 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
This presumes that there are security exits in place; and that userid/passwords are flowed across the network.
_________________
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 |
|
|
| shashivarungupta |
| Posted: Wed Sep 02, 2009 7:55 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| Sam Uppu wrote: |
| shashivarungupta wrote: |
| bruce2359 wrote: |
| Quote: |
| In clustering the authorization is always on the destination QMgr/ queue side whereas in normal point to point communication the authorization is on sending side. |
Cluster channels are point-to-point channels. And, authorization takes place on both ends of point-to-point channels - at MQOPEN of the q definition on the sending end, and at theMQOPEN of the destination queue at the receiving end. |
As far as mq cluster security is concerned.....
There is a Message Channel Agent (MCA) at each end of the channel. The MCA is a component that handles the sending and receiving of messages between queue managers. Before the MCA can send and receive messages, the UserId and Password must be authenticated as detailed below:
*The MCA that is running the Cluster-Sender channel will call client-side security exit to send a security message that contains the UserId and Password across the channel to the Cluster-Receiver channel.
*The MCA that is running the Cluster-Receiver channel will call server-side security exit to authenticate the incoming UserId and Password.
Suggestion: You can have a look at Capitalware Manuals for the Cluster Security Exit for the Better and Clear Understanding. |
What if we dont use the Capitalware's security exit?. |
I just said/suggested to have a look at their manual to check the way of implementation of security exit in the cluster...not to implement it forcefully. 
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
|
|
