| Author |
Message
|
| Goodfellas |
 Posted: Thu Feb 26, 2009 11:44 am Post subject: Problem |
 |
|
Acolyte
Joined: 26 Feb 2009
Posts: 70
|
have
Last edited by Goodfellas on Tue May 28, 2013 12:11 pm; edited 1 time in total |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Feb 26, 2009 11:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Java does not pass the OS level process ID into the MQ connection, unless you are making a bindings connection.
This is because Java wants everything to be "native Java" rather than "os native", so you can run the same code on any JVM.
Consequently, Java passes a null user id value to the MQ connection. When MQ sees a null value, it uses the user id that is running the server connection channel - which is mqm in most cases.
If you wish to secure this connection, then a) set MCAUSER on all channels, b) enable SSL and give the user a certificate for "testuser" per the IBM MQ SSL manual, c) do not use SYSTEM.DEF.SVRCONN for anything, use an application specific channel with an application specific MCAUSER. |
|
| Back to top |
|
|
| Goodfellas |
| Posted: Thu Feb 26, 2009 3:59 pm Post subject: |
|
|
Acolyte
Joined: 26 Feb 2009
Posts: 70
|
Thanks...
Last edited by Goodfellas on Tue May 28, 2013 12:11 pm; edited 1 time in total |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Feb 26, 2009 4:11 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
Tow good references to read: WMQ Security, WMQ Using Java.
_________________
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: Thu Feb 26, 2009 10:25 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Setting mcauser on the channel has anybody connecting impersonating the stated mcauser. In order to keep it safe you want mcauser + SSL on any SVRCONN channel.
This still leaves open any access from any connected qmgr be it SSL encrypted channel or not...
Basically any connected qmgr needs all its SVRCONN SSL encrypted with mcauser for a totally secure qmgr.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Thu Feb 26, 2009 11:02 pm Post subject: RE |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
Hey
For the securing the channels you either can use the SecExit and SecData values to be populated on the channels.
You have to have MCA userid set and SSL parameter on the channel with SSL Authentication "Required".
I am not sure how you are passing the userid and password while making a connection request to the queue manager. That id has to have connect access on that QM. Use setmqaut command for that on the server where your MQ Objects belong i.e. your MQ Server.
Use following commands for setmqaut and dspmqaut:
For Queue:
setmqaut -m QM -n "Q" -t queue -p "ID" +browse +dsp +get +put +inq +passall +passid
For QM:
setmqaut -m QM -t qmgr -p "ID" +connect +dsp +inq -set -altusr -chg -setall
For Queue:
dspmqaut -m QM -n "Q" -t queue -p "ID"
For QM:
dspmqaut -m QM -t qmgr -p "ID"
You dont need to REFRESH SECURITY untill you do somthing related to SSL.
The UserID could be the member of mqm group. But its not hard and fast rule.
Thanks
-Varun  |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Sat Feb 28, 2009 3:54 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Goodfellas,
You need to separate the concepts of authentication and authorization. setmqaut provides a mechanism for authorization checking (ACL) but MQ does not have anything built in to do authentication.
Until you implement an authentication mechanism, security exit or SSL, then authorization is a mote point. (i.e. the barn door is wide-open by default in MQ.)
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Feb 28, 2009 4:10 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I have not given access to the qmgr & queue for the user id "testuser". This id is a basic userid on AIX where this Qmgr is existing. |
What group does testuser belong to? What authority does the group have?
_________________
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: Sat Feb 28, 2009 4:11 pm Post subject: Re: RE |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| shashivarungupta wrote: |
| ...The UserID could be the member of mqm group... |
Oh no it couldn't! That would be tantamount to not bothering at all with an MCAUSER, the idea of which is to restrict access to objects, not give 'god' rights.
_________________
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 |
|
|
| bruce2359 |
| Posted: Sat Feb 28, 2009 4:25 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
From the WMQ Security manual:
The OAM maintains an access control list (ACL) for each WebSphere MQ object it is controlling access to. On UNIX systems, only group IDs can appear in an ACL. This means that all members of a group have the same authorities. On i5/OS and on Windows systems, both user IDs and group IDs can appear in an ACL.
_________________
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 |
|
|
| shashivarungupta |
| Posted: Sun Mar 01, 2009 11:17 pm Post subject: Re: RE |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| exerk wrote: |
| shashivarungupta wrote: |
| ...The UserID could be the member of mqm group... |
Oh no it couldn't! That would be tantamount to not bothering at all with an MCAUSER, the idea of which is to restrict access to objects, not give 'god' rights. |
.
| Quote: |
| the idea of which is to restrict access to objects, not give 'god' rights. |
You are absolutely right. But then it depends on the application trust level to access the mq objects. That would be decided by the Security Group in the system.
Ya we must takecare of such things while OAM process. |
|
| Back to top |
|
|
| MQEnthu |
| Posted: Sun Mar 01, 2009 11:37 pm Post subject: |
|
|
Partisan
Joined: 06 Oct 2008
Posts: 329
Location: India
|
| Goodfellas wrote: |
| Now i gave the "testuser" id details in MCAUSER()...only he is able to put message ..other users getting 2035 error. .....here I have not given permission for testuser to this queue in the security file...I mean where we assign the permissions using setmqaut. |
"testuser" may member of any usergroup that has got the access...
_________________
-----------------------------------------------
It is good to remember the past,
but don't let past capture your future |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Mar 02, 2009 1:13 am Post subject: Re: RE |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| shashivarungupta wrote: |
| ...But then it depends on the application trust level to access the mq objects.... |
The trust level for an application is to its objects only, therefore no Administrator-level access should ever be granted.
| shashivarungupta wrote: |
| ...That would be decided by the Security Group in the system... |
That's your job as a WMQ Administrator because you understand queue manager security, whereas most of the security twonks I've met think that user access restriction, firewalls, and audit is good enough - but in their defence, they mostly know the big picture rather than the detail.
_________________
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 |
|
|
|
|
