| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| setmqaut authorities for JMS MQI SVRCONN application channel |
View previous topic :: View next topic |
| Author |
Message
|
| rickwatsonb |
 Posted: Fri Mar 04, 2011 6:35 am Post subject: setmqaut authorities for JMS MQI SVRCONN application channel |
 |
|
Voyager
Joined: 15 Aug 2006
Posts: 87
Location: USA: Mid-West
|
Hi,
As stated in a previous post: “We have a JMS application running in WAS on a UNIX server that connects to a UNIX MQ server via client mode on a SVRCONN channel with a MCAUSER(userapp1).”
This is my first time ever trying to add security and set up the proper OAM authorities for the SVRCONN application MQI channel. In my research I came across T. Rob Wyatt’s OAM templates at “A blog about securing and using WebSphere MQ”.
I am wondering if I am miss-understanding the purpose of the authorities (or the intended usage of the script) set in the OAM template for the MQI channel. Here are my questions regarding the script:
(1) In general, can the OAM authorities shown in the MQI template be applied to the WAS/JMS/SVRCONN scenario that we have implemented? In other words, is the intended usage of the script for a MQI SVRCONN channel connecting in client mode?
(2) The authorities set for the queues in the MQI template do NOT contain +put or +get. How can this “not otherwise restrict application users” as T. Rob states in the script description if +put and +get are omitted?
Here is the code excerpt from the MQI OAM template:
# Default allow-all to all queues
setmqaut -m QMNAME -g mqmmqi -n '**' -t queue -all +inq +browse +dsp
The above line of code differs from what was shown in the article “Websphere MQ security heats up” by T.Rob which he references in the link for the OAM templates.
Excerpt from the T. Rob “…security heats up” article for MQI channels:
#Default allow-all to all queues
setmqaut –m QMGR –g mqmmqi –n ‘**’ –t queue –all +allmqi +dsp
The above line of code includes +put and +get via the +allmqi. In T. Rob's examples why do the given authorities differ so much for the queues? Is it due to a difference in intended usage?
Thank you for your time and help. |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Fri Mar 04, 2011 6:51 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Can you provide links to the articles you are referring to, so we can look at the context of the permissions being suggested?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| rickwatsonb |
| Posted: Fri Mar 04, 2011 7:07 am Post subject: |
|
|
Voyager
Joined: 15 Aug 2006
Posts: 87
Location: USA: Mid-West
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Mar 04, 2011 7:29 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| (1) In general, can the OAM authorities shown in the MQI template be applied to the WAS/JMS/SVRCONN scenario that we have implemented? In other words, is the intended usage of the script for a MQI SVRCONN channel connecting in client mode? |
Briefly, WMQ is unaware (doesn't care) of the source of the connection. WMQ is WAS- and JMS-neutral - which means that WAS and JMS are just other applications that attempt to connect.
| Quote: |
#Default allow-all to all queues
setmqaut –m QMGR –g mqmmqi –n ‘**’ –t queue –all +allmqi +dsp
The above line of code includes +put and +get via the +allmqi. In T. Rob's examples why do the given authorities differ so much for the queues? Is it due to a difference in intended usage? |
+allmqi grants +put and +get, and all other MQI calls. +dsp grants admin authority (which are not MQI calls).
_________________
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 |
|
|
| fjb_saper |
| Posted: Fri Mar 04, 2011 7:50 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| bruce2359 wrote: |
+allmqi grants +put and +get, and all other MQI calls. +dsp grants admin authority (which are not MQI calls). |
Not quite. +alladmin or something like that grants admin authority.
+dsp grants display authority for pcf/admin commands issued against the objects, like display queue, display queue status, display ql curdepth etc...
You still cannot create or delete the queue which would also be part of admin... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Mar 04, 2011 8:02 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Sorry. I meant to distinguish between MQI auth and admin. +dsp is a display auth, an admin auth.
_________________
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 |
|
|
|
|
|
|
|
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
|
|
|
|
