| Author |
Message
|
| irony |
 Posted: Fri Jan 11, 2008 1:11 pm Post subject: Permissions to SYSTEM.CLUSTER.TRANSMIT.QUEUE |
 |
|
Apprentice
Joined: 18 Nov 2005
Posts: 35
Location: US
|
Situation:
We have 2 instances of application on 2 different physical servers on the front-end using REQUEST-REPLY design.
We have defined queue alias on front-end pointing to cluster queues on the broker servers. The broker(s) puts the processed message(s) on cluster queues defined locally on the back-end WAS servers.
After processing the messages, the back-end WAS server(s) puts the messages on local reply queues on the front-end. It reads the reply-to-queue & reply-to-queue manager fields from the input message and replies accordingly.
Concern:
Right now we have given permissions for the 'application id' to the SYSTEM.CLUSTER.TRANSMIT.QUEUE on back-end.
Creating queue manager alias on back-end did not work.
Is there an alternative way to accomplish this type of request-reply design?
Note: Just to point out again - we have multiple instances of front-end servers. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Jan 11, 2008 1:29 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You can use a QREMOTE and grant priviledges to that, or a QALIAS.
This would be for the unclustered reply-to-queue.
And would have to be done on each server that needed to send replies.
And it may seem like a lot of annoying work, but it does prevent your application from having wide-open access to every queue on every qmgr in the cluster, which put auth to S.C.T.Q gives.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| irony |
| Posted: Fri Jan 11, 2008 1:54 pm Post subject: |
|
|
Apprentice
Joined: 18 Nov 2005
Posts: 35
Location: US
|
thanks jefflowrey for the response.
But I foresee problems with QR/QA.
QR - I have multiple instance of reply queues (on different front end servers) and the front-end-servers do not share state info. So the reply has to go back to the requesting queue manager. And I cannot possibly create 2/3 QRs with the same name on a single back-end server.
QA - reply queues are not clustered. So i cannot possibly point the QA on back-end server to local reply queue on front-end.
So the solution i can see right now is;
Cluster the front-end reply queues and define QAs on back-end. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jan 11, 2008 2:20 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| irony wrote: |
So the solution i can see right now is;
Cluster the front-end reply queues and define QAs on back-end. |
The front end reply queues will have to be named differently on each front end QM, so each front end app will need to be aware of its unique Reply To Q name.
The back end server will have to be changed to only reply to the ReplyToQueue and not use the ReplyToQM, so that its MQOPEN resolves to its local queue alias for the specific reply q.
Is this acceptable?
If not, and you want the back end app to still reply to both the ReplyToQueue and ReplyToQM, and you want each instance of the front end to reference the same ReplyToQ name in their code, you can do it by using ReplyToQ Aliases. It would be a bit convoluted, but ReplyToQ aliases usually are. Sometimes its the best way.
One of the benefits of MQ clustering is reducing q definitions, but as soon as you want to restrict wide open access to the S.C.T.Q. you find yourself going nuts with Alias definitions all over the place.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| irony |
| Posted: Sat Jan 12, 2008 5:32 am Post subject: |
|
|
Apprentice
Joined: 18 Nov 2005
Posts: 35
Location: US
|
Thanks for your inputs, Peter.
I am afraid the first solution will not go well with the AO & WAS Admin. So I will try your ReplyToAliases solution. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Jan 12, 2008 9:45 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| PeterPotkay wrote: |
| One of the benefits of MQ clustering is reducing q definitions, but as soon as you want to restrict wide open access to the S.C.T.Q. you find yourself going nuts with Alias definitions all over the place. |
The two benefits of MQ Clustering are a) load-balancing, b) simplified channel administration.
I don't believe anyone has every said anything about MQ Clusters reducing q definitions...
One can achieve the same level of queue definition reduction in a non-clustered environment by using a Qmgr Alias to establish default routes.
And one gains the same "every queue on the other qmgr is now wide open" security complication.... That leads one to the same propagation of QREMOTEs or QALIASes.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Jan 12, 2008 4:34 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The Cluster manual is a little vague on this specifically. It says:
| Quote: |
| Establishing a network of queue managers in a cluster involves fewer definitions than establishing a network that is to use distributed queuing. With fewer definitions to make, you can set up or change your network more quickly and easily, and reduce the risk of making an error in your definitions. |
I read "definitions" as channels and queues.
In the example (How does the system administrator benefit?) they use to show how many definitions are saved, they do count the elimination of the remote q defs in the total count.
They don't consider security at all though.
| jefflowrey wrote: |
| And one gains the same "every queue on the other qmgr is now wide open" security complication.... That leads one to the same propagation of QREMOTEs or QALIASes. |
True.
I guess its as with all thing in life security related - if you want to lock things down its going to take more work and be more complex than if it was wide open.
To bad setmqaut isn't cluster aware. For example:
| Code: |
setmqaut -m MyLocalClusterQM - t queue -n SYSTEM.CLUSTER.TRANSMIT.QUEUE -g AppGroup -all
setmqaut -m MyLocalClusterQM - t queue -n REQUEST.QUEUE -g AppGroup +put |
(the above is not a valid working scenario, just a theoritical example)
where REQUEST.QUEUE is a local q on other QMs in the cluster. AppGroup connected to MyLocalClusterQM could now send messages to REQUEST.QUEUE, but nothing else, and there is no need for Alias defs. Alas, I suspect that would require wholesale changes to how MQ Auts and /or Name Resolution works. The bugger is that if the MQ API call resolves to an XMITQ that's what you need access to. If they just kept the security at the q level, even for queues not physically defined on the local QM, it would simplify MQ Security I think, for both clusters AND regular distributed queueing.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Jan 12, 2008 5:07 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You can also play with redirection:
Use a dummy for reply to qmgr (dummya).
On the service qmgr create a qmgr alias:
def qr(dummya) rqmname(qmgra)
Now you have authorized all queues on qmgra by authorizing a put to dummya....
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
