| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| How to authority check the q name, even if QM name provided |
« View previous topic :: View next topic » |
| Author |
Message
|
| PeterPotkay |
 Posted: Wed Oct 22, 2014 12:16 pm Post subject: How to authority check the q name, even if QM name provided |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
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
Keep Calm and MQ On |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Oct 22, 2014 8:43 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
No. The provider application is supposed to have that access. You could if the reply to queue is not dynamic authorize the queue but I don't believe that you'd be able to get away with the same authorization as for clustered queues. (after all the qmgr name is not blank...)
Why would you want to restrict so much the provider application on the reply to?
Think about a different scenario where the provider app only needs to send back to the broker and the broker sends back to the originator...
Should make authorities a little bit easier...
Have you tried a weird combination:
setmqauth -m qmgr -t rqmname -n rqmname -t q -n queuename
Does it protest if all is in one sentence? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Oct 23, 2014 4:49 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
No. The provider application is supposed to have that access.
|
Ah, 'no' back at ya!  Just because the app replies to request messages I'm supposed to grant it access to put to every queue on every other QM?
App1 1 is on QM1 and is the service provider.
AppPeter and AppFJ are connected to QM2.
AppPeter sends requests to App1, so I have to give App1 access to the QM2 XMITQ on QM1.
Now how happy is the AppFJ app that App1 can jam messages in its queues, if AppFJ has no relationship with App1?
| fjb_saper wrote: |
You could if the reply to queue is not dynamic authorize the queue but I don't believe that you'd be able to get away with the same authorization as for clustered queues. (after all the qmgr name is not blank...)
|
If the app specifies the Destination QM along with the destination Q when putting the Reply, its the XMITQ being opened and I can't figure anyway to make the local QM consider the Destination Q Name for authorizations in this case. I have to give the local app access to the XMITQ if the local app specifies a Destination QM, and at that point the queue name is completely ignored for authority checking, so the app can specify any queue name it wants and the local QM will shove that into the XMITQ and off to the other QM.
| fjb_saper wrote: |
| Does it protest if all is in one sentence? |
AMQ7094: You specified an object type that is not valid, or more than one
object type.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Oct 23, 2014 4:55 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Sounds like an RFE to me...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Oct 23, 2014 7:25 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Well, of course, this conundrum has led some people to create application specific clusters, such that all of the CLUSRCVrs have app-specific MCAUSERs.
You could/should/maybe be able to do this with CHLAUTH type(usermap) instead.
You could maybe just hack it with qaliases on each receiving qmgr. But then you have to make sure the requester app uses that as the replytoq. This is then authenticated against the mcauser (maybe being selected with a usermap).
But yes, this is a complicated problem. And no matter what, your CLUSRCVRs should have mcausers that block access to SYSTEM queues and other etcs. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Oct 23, 2014 8:53 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| mqjeff wrote: |
| Well, of course, this conundrum has led some people to create application specific clusters, such that all of the CLUSRCVrs have app-specific MCAUSERs. |
Hmmm, OK. Doesn't scale though.
| mqjeff wrote: |
You could/should/maybe be able to do this with CHLAUTH type(usermap) instead. |
I don't think this would work as CHLAUTH is only used on the initial connection, not on a per message basis.
| mqjeff wrote: |
But yes, this is a complicated problem. And no matter what, your CLUSRCVRs should have mcausers that block access to SYSTEM queues and other etcs. |
Agree. So worst case at least they won't be able to drop messages into the SYSTEM queues. Except for the SYSTEM.CLUSTER.COMMAND.QUEUE. On every QM they need to reply to....sigh.
I have reached out to my IBM Lab Advocate to talk this out and see if there is some trick I'm missing, or if this is worth an RFE, or if the only way ever to solve this is via PUTAUT=Context on the receiving channels and all the craziness that involves.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Oct 23, 2014 9:31 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| PeterPotkay wrote: |
| mqjeff wrote: |
| Well, of course, this conundrum has led some people to create application specific clusters, such that all of the CLUSRCVrs have app-specific MCAUSERs. |
Hmmm, OK. Doesn't scale though. |
I know some fairly large companies that have at least tried it. Whether they've stuck with it or not is a different point.
In theory, it does actually scale. You just have two dedicated FRs that use a CLUSNL to act as the FRs for as many clusters as you can fit, and then spread clusters across your existing qmgrs to match the application deployment pattern.
But particularly with shared cluster xmitqs (one per qmgr) it does get a bit... messy....
It's a workable solution, at least, albeit not a beautiful one.
One cluster per QOS is the generally recommended architecture instead of one cluster per Application. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 05, 2014 4:23 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| jcv |
| Posted: Thu Mar 05, 2015 9:43 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
Besides everything already mentioned here, the redbook authors of the document http://www.redbooks.ibm.com/redbooks/pdfs/sg248069.pdf suggested another, Fine-grained cluster security setup, based on CHLAUTH type(qmgrmap). Although that solution is not directly motivated by the problem discussed here, and is primarily focused on control of putting to system queues, it is not satisfactory generally (one cannot decide to which destination application queue a message may be put, based solely on the fact from which qmgr message arrives, unless of course if qmgrs are dedicated exclusively to certain applications), and there is a similarity with the solution that Jeff mentions, in the sense that instead of (or, in addition to) controlling the put operation on the originating qmgr (where the message producer is connected), put operation is controlled on the destination qmgr (where the message consumer is connected), which is not very intuitive or natural, it is natural to control get operation there. It is natural to control put operation there too in case when there is no other way to do that, and that is when a boundary between WMQ networks that belong to distinct organizations (administered by different teams) goes between originating and destination qmgr. Because obviously the administrator of the destination qmgr doesn't trust controls on the originating qmgr. That's the main reason for feeling of ugliness about any solution that doesn't take into account this fact (PUTAUT(CTX),fixing MCAUSER and creating application specific - otherwise unwanted and very numerous - clusters, qmgr mapping, or whatever someone may come up with when forced to find some solution). That's why in my opinion the RFE actually describes a request to solve a defect, and I voted for it a long time ago.
By the way, the point about qmgr mapping is not main here, I know that they meant to present how exactly the put access to system queues should be controlled on cluster receiver channel, and that control of putting to application queues should be additionally controlled on the originating qmgr. |
|
| Back to top |
|
|
| jcv |
| Posted: Fri Mar 06, 2015 9:31 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
So one point is that you would want to control the input of message at the point where it enters your area of responsibility. The other point is that there is no harm if you can setup layered defense, checking put on both origin and destination qmgr. Yet another point is that if you check put operation on destination qmgr as redbook setup suggests, you have to introduce the third category of entities (separate security role), which are neither mq admin, nor application entities, so that you can map them to cluster receiver channels and grant them permissions for adequate system queues, and for adequate subset of application queues. Which is not clean solution and hardly explicable to anyone who is not an mq administrator. It would be natural that mq admin doesn't have to request (someone else) creation of such entities on each server that is involved, and that only already existing application users and groups are authorized for application queues according to understandable requirements created by application managers, plus WMQ admins who have their authorizations which are also not under question, and situation would be clean.
It would also be less annoying if WMQ admin was able to create his own WMQ users, in his own repository, which, as we all know is not possible. The fact that this users are created without login privilege doesn't make it less annoying (you still have to explain what's that user and group for). |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Mar 06, 2015 11:03 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| jcv wrote: |
It would also be less annoying if WMQ admin was able to create his own WMQ users, in his own repository, which, as we all know is not possible. The fact that this users are created without login privilege doesn't make it less annoying (you still have to explain what's that user and group for). |
In my experience that is the easy bit. What is very hard is to get the security bods to accept that in some cases having a password expire is a huge No-No and could literally break the bank.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Mar 06, 2015 11:47 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Isn't there a new feature in MQ v8 relating to remote queue authorities?
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| jcv |
| Posted: Tue Mar 10, 2015 8:23 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
Yes, achieving not expiring password for these users is an issue too.
There is no new feature in MQ v8 relating to remote queue authorities yet, RFE is still not "Delivered". However, although replyToQmgr found its way to MQMD a long time ago, there is an architectural campaign going on, that avoids its usage. If there is a redundant qmgr that hosts a redundant reply cluster queue instance, only replyToQueue can be used by reply producer. Unless reply consumer waits synchronously in the thread in which it put request a few moments ago, unwilling to connect to the other qmgr to check there for reply. I read in some RFEs there are plans to deal with that, at least for applications deployed on WAS.
By the way, there is also a solution in 8.0.0.2 for LDAP authorization, so that there's no need for local users on each unix server. |
|
| Back to top |
|
|
| jcv |
| Posted: Thu Mar 12, 2015 8:46 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
Another point is that introducing additional architecural elements for reasons that declaratively are not envisaged as a proper reason to introduce them, is a main reason why that particular solution (application specific clusters) is not beautiful.
The third category of users is not specific to Fine-grained cluster security setup, putaut(context) requires them too, see http://www.mqseries.net/phpBB2/viewtopic.php?t=68012&postdays=0&postorder=asc&start=15. In putaut(context) setup, separate security role user is to be granted altusr permission, while in Fine-grained qmgr mapping setup that user is to be granted put permission to a subset of application queues that is actually a union of sets of queues to which applications connected to a certain remote qmgr should be able to put, besides SYSTEM.CLUSTER.COMMAND.QUEUE and DLQ. In fact, reconsidering a bit, putaut(context) seems like the best option among these three, if that RFE that Morag asked for, gets implemented. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
