| Author |
Message
|
| David.Partridge |
 Posted: Wed May 14, 2008 12:24 am Post subject: Locked down transmission queues |
 |
|
Master
Joined: 28 Jun 2001
Posts: 249
|
So you want to harden your QM by not granting PUT authority on the transmission queues because this would allow a user to put a message to any queue reachable through that transmission queue.
Because we are not running in a single authentication domain all channels are running with PUTAUT(DEF) or PUTAUT(ONLYMCA).
For a message PUT of a datagram or request, this is fine as you grant the PUT authority on to the QR.
If however this is a reply to a message specifying REPLYTOQ and REPLYTOQMGR, I can't see a general solution that allows this to work without granting PUT authority on the transmission queue.
Am I missing an obvious wrinkle with the use of qmgr alias or similar?
Is there a technique that will work in the general case?
_________________
Cheers,
David C. Partridge |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed May 14, 2008 2:23 am Post subject: Re: Locked down transmission queues |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| David.Partridge wrote: |
If however this is a reply to a message specifying REPLYTOQ and REPLYTOQMGR, I can't see a general solution that allows this to work without granting PUT authority on the transmission queue.
Am I missing an obvious wrinkle with the use of qmgr alias or similar?
Is there a technique that will work in the general case? |
Yes you are. You can use qmgr aliases to solve the authorization problems. But it makes the whole flow a lot more complicated as the request message needs to specify the qmgr alias for the replyto qmgr and not the qmgr name.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed May 14, 2008 5:08 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
F.J.,
If the QMGR alias maps to the XMITQ, and you grant access to the QM Alias, why can't the app still send to any queue on the other side of that QM Alias / XMITQ?
David, as an aside, you might want to set the MCAUSER on your RCVR channels to an ID that does not have access to queues you want to protect, like the command queue for instance. That will help.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed May 14, 2008 8:13 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
F.J.,
If the QMGR alias maps to the XMITQ, and you grant access to the QM Alias, why can't the app still send to any queue on the other side of that QM Alias / XMITQ?
David, as an aside, you might want to set the MCAUSER on your RCVR channels to an ID that does not have access to queues you want to protect, like the command queue for instance. That will help. |
You can post to any queue on the target... but who will know the right alias to use? It should only be the requesting app. If you are really restrictive you could force a p2p with an mcauser on the channel. This would restrict the queues you can post to.
A locked down xmitq especially in a cluster does not make much sense to me. I would advise to go for a lock down on the access points and a good configuration on the queues...
If I'm allowed to put on qmgr c (part of the cluster) to any queue ==> I can put to any clustered queue in the cluster.
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| David.Partridge |
| Posted: Thu May 15, 2008 6:55 am Post subject: |
|
|
Master
Joined: 28 Jun 2001
Posts: 249
|
F.J.
So you're talking specific QM Aliases for each application user/group.
Yes that makes sense to me, though I can see there will be a major proliferation of QMAs on the z/OS systems. On distributed the client has the luxury of having dedicated QMs on dedicated AIX for each application, so that shouldn't pose a problem, as there'll be a pretty limited set of possible replytoqmgr values.
SCTQ will be TOTALLY locked down else anyone can put to ANY queue in the whole set of clusters to which the QM belongs (except of course the local queue instances where the OAM or RACF will restrict).
Access to cluster queues not locally hosted will be via QA on local QM -> QC with permission on QA.
P.P.
Yes I thought of MCAUSERing the RCVRs but decided that we'd only do that where connection to external QMs is involved. The internal QMs will connect over SSL protected channels and probably also BlockIP2.
_________________
Cheers,
David C. Partridge |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu May 15, 2008 8:45 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
So to be clear, AppA will be given a specific QM Alias to use, that only they can use, but via it it can put to any queue in the cluster or destination QM in P2P? What does that buy you?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| David.Partridge |
| Posted: Thu May 15, 2008 11:40 pm Post subject: |
|
|
Master
Joined: 28 Jun 2001
Posts: 249
|
You beat me to it Peter. It buys nothing whatsoever which is what I realised not long after my last post (but after I'd gone home).
What I *think* will work is to use a cluster alias called (e.g.) THISQM, so you would put replytoqmgr=THISQM, and replytoq=name of QR/QA/QC as required. With permissions on the replytoq name granted to the application user to put messages.
A bit convoluted, buit I believe it will work. Now to put it to the acid test using the echo sample.
_________________
Cheers,
David C. Partridge |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri May 16, 2008 6:57 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| David.Partridge wrote: |
What I *think* will work is to use a cluster alias called (e.g.) THISQM, so you would put replytoqmgr=THISQM, and replytoq=name of QR/QA/QC as required. With permissions on the replytoq name granted to the application user to put messages.
|
When you specify both the q name and the destination QM name on the MQOPEN call, I beleive authorities are only checked on that QM name and the XMITQ it resolves to. Meaning if you give me rights to THISQM, I can send to SYSTEM.ADMIN.COMMAND.QUEUE on THISQM.
If your app is sending a reply to REPLY.QUEUE.DAVID, you could use ReplyTo aliases so the request message arrives with the MQMD ReplyToQueue filled in as REPLY.QUEUE.DAVID.ALIAS, and you grant the replying app access to REPLY.QUEUE.DAVID.ALIAS only. But the replying app has to know not to specify the QM name on the MQOPEN of the reply message. And that means you have to create a unique reply q and reply q alias for every QM in your cluster. And you can't use dynamic queues. I'm struggling to come up with a better solution.
Locking down clusters for apps that need to send replies to any number of queues on any specific QM in the cluster is tough. Impossible maybe?
Hope someone has an idea to post that works....
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri May 16, 2008 1:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If the reply to queue is unique and clustered you can give authorization to that queue on the sending qmgr and it "should" work (in other words check it out).
The problem arises when you have multiple instances of the queue in the cluster.
As for temporary queues, you'd have to cluster the MODEL queue and suppress the reply to qmgr? Not an easy feat in JMS...
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| David.Partridge |
| Posted: Mon May 19, 2008 11:39 pm Post subject: |
|
|
Master
Joined: 28 Jun 2001
Posts: 249
|
Testing using a non-authorised userid indicates that name resolution of the THISQM QR (which is a cluster alias - i.e. blank QMNAME, blank QNAME) takes place before any authority checking takes place, so the OAM check is made against the locally defined QA or QR or QL which is what I would expect.
So mquser who is a member of mqapp1 attempting to open THISQM/BOB can open the queue if there is an OAM entry permitting access by mqapp1 to queue BOB in the desired mode. If appropriate OAM permissions don't exist on queue BOB then the application gets an MQRC 2035 as expected.
Note that the THISQM QR does not need permissions to be set for group mqapp1 as it is only used for name resolution.
I agree that dynamic queues are a problem, as is the case where you want the reply to go a specific instance of a cluster queue. If anyone has some bright ideas on how to handle these, I'm all ears  .
_________________
Cheers,
David C. Partridge |
|
| Back to top |
|
|
|
|
