| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Confused about authorizations on an XMITQ |
« View previous topic :: View next topic » |
| Author |
Message
|
| rathnak |
 Posted: Mon Feb 10, 2014 6:13 pm Post subject: Confused about authorizations on an XMITQ |
 |
|
Newbie
Joined: 01 Feb 2014
Posts: 7
|
MQ Gurus,
An MQ expert asked me a question about 2035 RC.
The questions goes like this, an application id 'fruit' has connected successfully with a queue manager APPLE and it is trying to put a message on a queue APPLE.LOCAL on which the application id 'fruit' has got inq, put, browse and get permissions. But still the messages fails to reach APPLE.LOCAL with RC 2035. Everything is fine about the configuration, channel, id being used, host being accessed, IP, no firewall issues, etc.
I gave up on this question, and the answer goes like this..
Every ID that needs to send message through an XMIT must have permissions enabled on the XMITQ (in this case PUT). So the ID 'fruit' has no permissions enabled for the queue APPLE.LOCAL on APPLE, and this is the reason for RC 2035.
But as far as i know, mqm id would be given full permission and the mqm id will be used whenever xmitq is being accessed.
Am really a minnow before you all, and require your help in understanding this... |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Feb 10, 2014 6:37 pm Post subject: Re: Confused about authorizations on an XMITQ |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| rathnak wrote: |
I gave up on this question, and the answer goes like this..
Every ID that needs to send message through an XMIT must have permissions enabled on the XMITQ (in this case PUT). |
No. It is a bad practice and security exposure to grant an end-user id put authority to a xmitq.
End-user applications MQOPEN QRemote definitions, NOT xmitqs. The QRemote definition identifies (explicitly or implicitly) the xmitq. As a result of MQOPENing the QRemote definition, a transmission queue header (XQH) will be MQPUT to the xmitq, along with the MQMD and message data payload.
_________________
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 |
|
|
| exerk |
| Posted: Tue Feb 11, 2014 2:50 am Post subject: Re: Confused about authorizations on an XMITQ |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| rathnak wrote: |
| The questions goes like this, an application id 'fruit' has connected successfully with a queue manager APPLE and it is trying to put a message on a queue APPLE.LOCAL on which the application id 'fruit' has got inq, put, browse and get permissions... |
This implies that the application is either connecting in bindings mode or via a client connection...
| rathnak wrote: |
| ...But still the messages fails to reach APPLE.LOCAL with RC 2035. Everything is fine about the configuration, channel, id being used, host being accessed, IP, no firewall issues, etc. |
...but if client, userid 'apple' may have the required authorities but if an MCAUSER value is used within the channel it may be that that user does not.
| rathnak wrote: |
| Every ID that needs to send message through an XMIT must have permissions enabled on the XMITQ (in this case PUT). So the ID 'fruit' has no permissions enabled for the queue APPLE.LOCAL on APPLE, and this is the reason for RC 2035. |
This contradicts your first statement so please clarify just which queue manager your application is connecting to please.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Tue Feb 11, 2014 5:20 am Post subject: Re: Confused about authorizations on an XMITQ |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| bruce2359 wrote: |
| End-user applications MQOPEN QRemote definitions, NOT xmitqs. |
Except when they are replying to a request and sending the message to a ReplyToQ and ReplyToQM, in which case there won't be a predefined remote queue definition. And their MQOPEN resolves to.....the XMITQ.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| 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
|
|
|
|
