| Author |
Message
|
| NomadAU |
 Posted: Mon Apr 10, 2017 11:43 pm Post subject: MQRC_NOT_AUTHORIZED when writing to JMSReplyTo dest |
 |
|
Novice
Joined: 06 Feb 2017
Posts: 15
|
I am having trouble figuring out what security configuration is required in order for a JMS application to be able to send a response message to the destination passed in the JMSReplyTo field of the request message.
In this particular case, the reply destination is on a remote queue manager, so the content of the JMSReplyTo destination is something like queue://<remote QM name>/<queue name>.
What I don't want to do is create explicit setmqaut profiles for all possible reply queue names. Instead I want to authorise the JMS application userid so that it can write to ANY queue on the remote QM, based on the premise that the requesting application may choose a different reply to queue each time it makes a call, indeed it may even use temporary queues.
So clearly, providing an explicit authorisation for each queue is not practical, instead the component I wish to secure, and authorise the JMS application userid to connect to, is the remote QM itself.
I originally thought this would be a simple task to achieve, but I've been spinning my wheels for a few hours without success. Can anyone give me some pointers?
The environment is RHEL and MQ 8. |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Tue Apr 11, 2017 4:31 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Unfortunately you have to grant access to the transmission queue that leads to the remote server. This could be the SYSTEM.CLUSTER.TRANSMIT.QUEUE if MQ clustering is involved.
Please consider my RFE to make this better, and add your vote if you agree. The details of the RFE will help you understand what is going on in your use case too.
Option to force MQ authority checking against the queue name before its placed in the transmission queue
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=61701
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Apr 11, 2017 4:44 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You should be able to create a qmgr alias, and grant authorities to that?
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Apr 11, 2017 6:20 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
You don't state which version of MQ you are using but one thing to consider (version appropriate) is the ClusterQueueAccessControl setting in the qm.ini file.
_________________
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 |
|
|
| NomadAU |
| Posted: Tue Apr 11, 2017 4:31 pm Post subject: |
|
|
Novice
Joined: 06 Feb 2017
Posts: 15
|
Thanks for all the responses.
I've got it working now - a solution (maybe the only solution?) was to make the following changes:
In the QM hosting the server application...
- create a local queue manager alias to 'map' the ReplyToQMgr name (QMA) to QMA.GWY.
- grant PUT authority for the application userid to the SYSTEM.CLUSTER.TRANSMIT.QUEUE
In the (gateway) QM connected to the external client QM (which defines the reply queue)...
- create a clustered queue manager alias 'QMA.GWY' that maps to the QMA xmit queue name (QMA)
The responses then were able to be sent from the application, via the cluster to the gateway QM where normal Sdr/Reciever channels passed the message across to the target QM.
On reflection, this does seem like a poor solution to what I would expect is a common requirement, namely, implementing a Request/Response pattern on a QM that belongs to a cluster. Up until these changes, the MQ security in the solution was very tight. This has now been considerably weakened by opening up PUT auth on the SYSTEM.CLUSTER.TRANSMIT.QUEUE object.
I guess that's what Peter's RFE is about, although the link didn't work for me.
[/list] |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Apr 11, 2017 10:15 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
For the link to work, you need to be logged in to developerworks.com
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Apr 12, 2017 4:58 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| NomadAU wrote: |
Up until these changes, the MQ security in the solution was very tight. This has now been considerably weakened by opening up PUT auth on the SYSTEM.CLUSTER.TRANSMIT.QUEUE object.
I guess that's what Peter's RFE is about, although the link didn't work for me.
|
Yup.
Please vote for my RFE. Without it, properly securing a MQ cluster in the real world with multiple platforms, dozens of app and hundreds of IDs is very, very difficult. Its not realistic to run all your channels with PUTAUT=Context.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Apr 12, 2017 5:06 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| NomadAU |
| Posted: Wed Apr 12, 2017 10:40 pm Post subject: |
|
|
Novice
Joined: 06 Feb 2017
Posts: 15
|
Vote submitted Peter.
Thanks for the help. |
|
| Back to top |
|
|
|
|
