| Author |
Message
|
| Sam Uppu |
 Posted: Mon Mar 23, 2009 12:52 pm Post subject: MQ Security setup - design help needed |
 |
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
We are on MQ version 6 on Solaris.
We have request/ reply scenario.
Lets say Requesting app(service requestor) is connected to QM1 and putting the messages onto Request queue(cluster queue) defined on QM2.
In this case we can define an local Alias queue for remote request queue(cluster queue) on QM1 and provide the privileges to the app id for the locally defined Alias queue
DEFINE QALIAS(REQ) TARGQ(REQ) DEFBIND(NOTFIXED)
....This is working.
The source application id: "App1" is not part of mqm group and not provided with permissions to SYSTEM.CLUSTER.TRANSMIT.QUEUE.
The destination app(service provider) should respond to the same QMgr where the request is originated from as there are multiple QMgrs which contain the same response queue names. In this case the destination app should respond to the response queue defined on QM1(as there are many response queues defined with the same name on other QMgrs within the cluster). The destination app will come to know this information from MQMD of the request message(ReplyToQueue and ReplyToQMgr fields) where it has to respond to.
In this case the destination app(service provider) need to provide the QMgr name while responding:
Queue req_queue = qMgr.accessQueue("RSP", openOptions,"QM1", null, null);
Where RSP is a response queue(cluster queue) defined on QM1 QMgr(service requestor).
In this case creating an Alias queue for RSP queue on QM2 does not resolve the queue name by providing the queue manager name as QM1 along with Alias Queue(RSP) defined on QM2.
We tried with creating local Alias queue on QM2 for the RSP but the source Application is getting 2035 error.
Also tried with Alias QMgr and still getting 2035 error.
Can anybody let me know what do you guys suggest.
Thanks. |
|
| Back to top |
|
 |
| Sam Uppu |
| Posted: Mon Mar 23, 2009 1:01 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
I would like to allow the responding App connected to QM2(destination QMgr) to PUT it's reply message without giving it rights to put to the SYSTEM.CLUSTER.TRANSMIT.QUEUE.
Here QM1 is the source QMgr and QM2 is the destination QMgr. The request queue(cluster queue) is defined on QM2 and teh response queue(RSP) is defined on QM1.
Thanks for your time. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Mar 23, 2009 1:08 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Is this connected to this, and is the background in this post relevant?
_________________
Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Mon Mar 23, 2009 1:50 pm; edited 1 time in total |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Mar 23, 2009 1:16 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| You ignored the suggestion to add +inq permission. You might need +dsp as well. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Mon Mar 23, 2009 1:16 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| Vitor wrote: |
| Is this connected to [http://www.mqseries.net/phpBB2/viewtopic.php?t=48209]this[/url], and is the background in this post relevant? |
Yes Vitor. This is our current MQ architecture and we want to secure the MQ infrastructure and for that I need your thoughts/ suggestions/ feedback/ concerns etc..
Thanks. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Mon Mar 23, 2009 1:18 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| mqjeff wrote: |
| You ignored the suggestion to add +inq permission. You might need +dsp as well. |
No Jeff. Infact I provided the +all permissions on all objects and trying. Still 2035 error.
Thanks. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Mon Mar 23, 2009 1:24 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
We want to know how can the destination application(connecting to QM2) is able to access the cluster queue RSP defined on QM1?.
The source application wants to access a cluster queue defined on a specific QMgr by specifying the QMgr name in MQOD along with the queue name.
e.g., qMgr.accessQueue("RSP",
openOptions,"QM1", null, null);
1. We tried the above setup by creating an Alias queue-RSP on QM2 and provided permissions for the Application id"App2" on QM2.....still getting 2035 error
DEFINE QALIAS(RSP) TARGQ(RSP) DEFBIND(NOTFIXED)
Entity App2 has the following authorizations for object RSP:
get
browse
put
inq
set
dlt
chg
dsp
passid
passall
setid
setall
clr
2. We tried the above setup by creating an Alias QMgr-QM1 on QM2 and provided permissions for the Application id"App2" on QM2.....still getting 2035 error
DEFINE QREMOTE(QM1) TARGQ(' ') RQMNAME(QM1) CLUSTER(TEST)
Entity App2 has the following authorizations for object QM1:
get
browse
put
inq
set
dlt
chg
dsp
passid
passall
setid
setall
clr
Not sure whether OAM supports when the QMgr name is specified in MQ object descriptor(MQOD) along with the queue name(cluster queue). If so please direct me to the IBM document where it is stated...thanks. |
|
| Back to top |
|
|
| queuemanager |
| Posted: Fri Mar 27, 2009 12:42 am Post subject: |
|
|
Apprentice
Joined: 28 Nov 2006
Posts: 43
Location: Bangalore
|
| Did you give connect access to App2 on QM2???? |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Fri Mar 27, 2009 5:42 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| queuemanager wrote: |
| Did you give connect access to App2 on QM2???? |
Yes. Tried with +all permissions.
Let me know..thanks. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Fri Mar 27, 2009 4:28 pm Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| Sam Uppu wrote: |
| queuemanager wrote: |
| Did you give connect access to App2 on QM2???? |
Yes. Tried with +all permissions.
Let me know..thanks. |
If you are connected to qmgr A and your instance of the cluster queue is in qmgr B you cannot GET a message from that clustered queue.
You NEED to be connected to qmgr B to GET a message from said cluster queue.
However you will be able to PUT a message to the cluster queue while connected to qmgr A.
This is the same concept that works on the system cluster transmit queue.
You need to setmqaut on the cluster transmit queue.
As a suggestion, if you'll give setmqaut on the alias queue then application would be able to put the message on the target queue which is being pointed by alias queue. There is no need to give setmqaut on local queue.
But if you do that then there is no harm as well. (until you want your applications to give access to alias queues only, not to the local queues as per the security authorization level.) |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Mar 27, 2009 5:20 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| In this case creating an Alias queue for RSP queue on QM2 does not resolve the queue name by providing the queue manager name as QM1 along with Alias Queue(RSP) defined on QM2. |
The reply-to-queue name and reply-to-qmgr name are resolved on the requesting (sending) qmgr, and not the replying qmgr. If either name fail to resolve, the MQPUT fails in the requesting application.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Mar 28, 2009 2:43 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| Quote: |
| In this case creating an Alias queue for RSP queue on QM2 does not resolve the queue name by providing the queue manager name as QM1 along with Alias Queue(RSP) defined on QM2. |
The reply-to-queue name and reply-to-qmgr name are resolved on the requesting (sending) qmgr, and not the replying qmgr. If either name fail to resolve, the MQPUT fails in the requesting application. |
The ReplyToQ and ReplyToQmgr in the MQMD of the Request message is never ever resolved against anything by the Requester App or as part of transmitting the Request.
The only time any MQ name resolution takes place is during MQOPEN... Channel MCAs do not ever try to validate a route to the ReplyToQ/ReplyToQmgr destination as part of moving messages, either.
The Server App SHOULD cause a resolution of the address indicated by these fields when it wants to send the Reply message, and the resolution will take place on the qmgr that the server application is connected to. If it is following best practices and *Using* ReplyToQ and ReplyToQmgr fields to address the Reply Message. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Mar 29, 2009 9:00 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| The ReplyToQ and ReplyToQmgr in the MQMD of the Request message is never ever resolved against anything by the Requester App or as part of transmitting the Request. |
You are correct, as usual.
ReplyToQ and ReplyToQmgr will need to be resolved at the requesting qmgr when the reply message arrives AND the MCA looks at either/both fields.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Mon Mar 30, 2009 7:46 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| bruce2359 wrote: |
| Quote: |
| The ReplyToQ and ReplyToQmgr in the MQMD of the Request message is never ever resolved against anything by the Requester App or as part of transmitting the Request. |
You are correct, as usual.
ReplyToQ and ReplyToQmgr will need to be resolved at the requesting qmgr when the reply message arrives AND the MCA looks at either/both fields. |
As per the QMgr name resolution table(row 12), when the QMgrName is specified in MQOD, the responding app needs permissions to S.C.T.Q...Here is the link: http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/com.ibm.mq.csqzal.doc/fg12170_.htm.
This is what IBM support came up with.
Thanks. |
|
| Back to top |
|
|
|
|
