Potkay, Peter M (CTO Architecture + Engineering)
2014-10-22 20:14:26 UTC
So I'm going along, carefully granting setmqaut rules for the app's service account to only allow it the bare minimum it needs on QM1, the QM it connects to. Feeling pretty good, got this guy locked down tight. It can only get from its queues. It's a Service Provider, so it replies to incoming requests by responding to the Reply To Queue and Reply To Queue Manager of the request message. So now we just grant this app on QM1 put access only to the specific reply queues we will allow.
And, roadblock. I don't understand how to only allow this app on QM1 put access to the specific reply queues if its putting to a fully qualified Reply Q on Reply To QM. Its issuing an MQOPEN (MQPUT1) call that is providing the destination queue AND the destination QM.
The app will need to send replies to QM2, QM3......QM98, QM99. These QMs may be in the same MQ Cluster, or they may be reached via traditional SNDR/RCVR channels. In any event, the best I can do is restrict access for the app on QM1 to only being able to put to QM2, QM3......QM98, QM99 at the QM level, if I use ClusterQueueAccessControl=RQMName and setmqaut rules with -t rqmname, as described here:
http://www-01.ibm.com/support/docview.wss?uid=swg21586095
But that is pointless. I just allowed the app to put to every queue on every one of those QMs based on what the receiving channel on the destination QM to put to, which is every app queue on the destination QM. Why am I gonna kill myself restricting what apps queues the app can access on QM1 if I have to allow it access to every app queue on QM2 thru QM99?
Creating Alias Queue Definitions for the reply queues on QM1 won't work - since the replying app is fully qualifying the MQOPEN/MQPUT1 and specifying the destination QM, QM1 will not even consider the locally defined Alias queue. And the Reply Queue is going to be the same name on multiple QMs anyway, so a single Alias queue for that name on QM1 doesn't work anyway.
Now, I suppose I could change all my Receiver and Cluster Receiver channels to run with PUTAUT set to Context, so those channels do authority checking for each message as it arrives at the destination QM, and we go insane trying to manage profiles on every QM for every potential ID that may come across. No thanks. Let's get back to reality.
What I need is for QM1 to do authority checking against the queue name in the MQOPEN/MQPUT1 call whether the MQOPEN/MQPUT1 call specifies a destination QM or not. Is there any way to make this happen? MQ 7.5 by the way.
Peter Potkay
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
And, roadblock. I don't understand how to only allow this app on QM1 put access to the specific reply queues if its putting to a fully qualified Reply Q on Reply To QM. Its issuing an MQOPEN (MQPUT1) call that is providing the destination queue AND the destination QM.
The app will need to send replies to QM2, QM3......QM98, QM99. These QMs may be in the same MQ Cluster, or they may be reached via traditional SNDR/RCVR channels. In any event, the best I can do is restrict access for the app on QM1 to only being able to put to QM2, QM3......QM98, QM99 at the QM level, if I use ClusterQueueAccessControl=RQMName and setmqaut rules with -t rqmname, as described here:
http://www-01.ibm.com/support/docview.wss?uid=swg21586095
But that is pointless. I just allowed the app to put to every queue on every one of those QMs based on what the receiving channel on the destination QM to put to, which is every app queue on the destination QM. Why am I gonna kill myself restricting what apps queues the app can access on QM1 if I have to allow it access to every app queue on QM2 thru QM99?
Creating Alias Queue Definitions for the reply queues on QM1 won't work - since the replying app is fully qualifying the MQOPEN/MQPUT1 and specifying the destination QM, QM1 will not even consider the locally defined Alias queue. And the Reply Queue is going to be the same name on multiple QMs anyway, so a single Alias queue for that name on QM1 doesn't work anyway.
Now, I suppose I could change all my Receiver and Cluster Receiver channels to run with PUTAUT set to Context, so those channels do authority checking for each message as it arrives at the destination QM, and we go insane trying to manage profiles on every QM for every potential ID that may come across. No thanks. Let's get back to reality.
What I need is for QM1 to do authority checking against the queue name in the MQOPEN/MQPUT1 call whether the MQOPEN/MQPUT1 call specifies a destination QM or not. Is there any way to make this happen? MQ 7.5 by the way.
Peter Potkay
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html