ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General Discussion » security and clients

Post new topic  Reply to topic Goto page 1, 2, 3, 4  Next
 security and clients « View previous topic :: View next topic » 
Author Message
shogan2003
PostPosted: Fri May 14, 2004 3:20 am    Post subject: security and clients Reply with quote

Centurion

Joined: 03 Jul 2003
Posts: 133
Location: London

I am trying to restrict access to MQSeries clients putting and getting from queues on an MQSeries server. I wish to restrict user access to the channel and/or the queue.

Ideally I'd like to assign a separate server connection channel for each client performing a put or get based on logged-on user ID.

I have encountered a couple of issues. Some are down to my incompetence and others may be down to technical restrictions on MQSeries. I have researched MQSeries.net and note a similar query which attracted many replies, but they all suggested exits, which I really wish to avoid.

1. setmqaut, dspmqaut
--------------------------
I have experimented with setmqaut on Solaris & on NT; when I declare a queue as -put for a user, the command dspmaut still shows 'put' as one of the options available to that user for that queue. Also I can put to that queue.

But I thought security was on by default ?

I defined MQSNOAUT=no and restarted the NT machine

Still setmqaut & dspmaut have no effect.


2. DIY code
-----------
Environment : MQSeries 5.3 Solaris on client and server ; some future MQSeries clients will be Windows 2000.

The flat file adapter I have written on the MQSeries client machine inserts the logged-on user name into MQSeries header field UserId. Don't know if this is usable by MQSeries.

The value in userId is being ignored. Any value is accepted. I have varied the value of MCAUSER for the server connection channel SYSTEM.DEF.SVRCONN, using values '','mqm' and 'xyz'. The last value will give error code 2035, but that's only because xyz does not exist as a user on the server machine.

Many thanks in advance
_________________
MQSI2 certified specialist
MQSeries certified specialist
Back to top
View user's profile Send private message Send e-mail
jefflowrey
PostPosted: Fri May 14, 2004 5:02 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

There are a couple of things you may not understand about OAM security on NT and Solaris.

On Unix, OAM permissions apply to the group, not to the user.
Security manual wrote:
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 Windows, if the user is a member of the Administrators group, then they can do anything they want.
Security manual wrote:
On Windows systems, members of the Administrators group also have access to all WebSphere MQ resources.

This can get particularly sticky in domain and trust relationship environments.

On either platform, if the user is a member of the MQM group, then OAM security also does not apply.

Security manual wrote:
All members of the mqm group have access to all WebSphere MQ resources on the system, including being able to administer any queue manager running on the system. This access can be revoked only by removing a user from the mqm group.

_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
shogan2003
PostPosted: Fri May 14, 2004 5:16 am    Post subject: Reply with quote

Centurion

Joined: 03 Jul 2003
Posts: 133
Location: London

Thankd for the reply.

I had assumed that any user had to be a member of mqm before it use the queue at all; then setmqaut would be used to cut down its permissions.
_________________
MQSI2 certified specialist
MQSeries certified specialist
Back to top
View user's profile Send private message Send e-mail
JasonE
PostPosted: Fri May 14, 2004 5:41 am    Post subject: Reply with quote

Grand Master

Joined: 03 Nov 2003
Posts: 1220
Location: Hursley

fyi I think MQSNOAUT=no only takes effect when the qmgr is created...
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Fri May 14, 2004 5:45 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

You notice I quoted from the Security manual quite a bit, and that the answers I provided were all directly referenced in the security manual.


_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
mqonnet
PostPosted: Fri May 14, 2004 6:33 am    Post subject: Reply with quote

Grand Master

Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.

"I had assumed that any user had to be a member of mqm before it use the queue at all; then setmqaut would be used to cut down its permissions.
"
---Whoa!!! Never do this. If you are a memeber of the mqm group and revoke permissions on MQ objects on a qm for this user, the permissions are revoked for the entire mqm group. And there is no way you could grant back these permissions and the only way out is to Delete and recreate the qm.

Should probably take a detailed look at how authorities are granted, groups/users in the security manual.

Cheers
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator
Back to top
View user's profile Send private message Send e-mail Visit poster's website
JasonE
PostPosted: Fri May 14, 2004 6:43 am    Post subject: Reply with quote

Grand Master

Joined: 03 Nov 2003
Posts: 1220
Location: Hursley

Kumar, FYI On windows you cannot really remove authorizations from mqm - The code finds mqm membership then doesnt look in the oam for authorizations...
Back to top
View user's profile Send private message
mqonnet
PostPosted: Fri May 14, 2004 6:48 am    Post subject: Reply with quote

Grand Master

Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.

"FYI On windows you cannot really remove authorizations from mqm - The code finds mqm membership then doesnt look in the oam for authorizations..."

---Cool. I should have probably mentioned the platforms. I believe all unix based versions behave the way i just mentioned.

Cheers
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator
Back to top
View user's profile Send private message Send e-mail Visit poster's website
shogan2003
PostPosted: Fri May 14, 2004 7:01 am    Post subject: Reply with quote

Centurion

Joined: 03 Jul 2003
Posts: 133
Location: London

Thanks to you all for your responses so far.
I'm still mulling over restricting access via channels...

So just to re-iterate...

A userID should not be a member of mqm....in which case security can be applied to that user...anyone logging on using that userID on the client machine it should be able to run the MQ client binaries ?

Do setmqaut & dspmqaut defined against a user have any effect on messages coming from a client with that userId defined (in the MQEnvironment class )?
_________________
MQSI2 certified specialist
MQSeries certified specialist
Back to top
View user's profile Send private message Send e-mail
mqonnet
PostPosted: Fri May 14, 2004 7:13 am    Post subject: Reply with quote

Grand Master

Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.

"A userID should not be a member of mqm....in which case security can be applied to that user"

---Right

"anyone logging on using that userID on the client machine it should be able to run the MQ client binaries ?
"
---MQ client libraries has nothing to do in this scenario, since the purpose you are going to server/achieve here is to authenticate the userid on the client system to access specific MQ objects on the MQ Server system.

"Do setmqaut & dspmqaut defined against a user have any effect on messages coming from a client with that userId defined (in the MQEnvironment class )?"

---Yes and no. All depends on how you configure stuff. If you have mcauser set to blank, then the authorities that you set for the userid defined/set in your application are used to authenticate any requests on the server side. You need to define a principal and assign auths on the server side. If you have set mcauser within the svrconn channel to a specific userid, then it doesnt matter what userid you set in your application. The one in the mcauser is always used to authenticate any requests from any client using this particular svrconn channel.

Cheers
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator
Back to top
View user's profile Send private message Send e-mail Visit poster's website
shogan2003
PostPosted: Fri May 14, 2004 7:39 am    Post subject: Reply with quote

Centurion

Joined: 03 Jul 2003
Posts: 133
Location: London

Gents
So this scenario is feasible ...? :

Client machine Server machine
----------------- -------------------
Flat file adapter (Java)
MQEnvironment.userID='user1' user : user1, grp : user1
MQEnvironment.userID='pwuser1'
Svrconn chl : CH.USER1

setmqaut
-----------
Only user1 has access to Q.USER1
Only user2 has access to Q.USER2, connected via channel CH.USER2
_________________
MQSI2 certified specialist
MQSeries certified specialist
Back to top
View user's profile Send private message Send e-mail
mqonnet
PostPosted: Fri May 14, 2004 7:54 am    Post subject: Reply with quote

Grand Master

Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.

Well, if your sole purpose is to assign specific authorities to specific users for specific mq objects(queues), why dont you define principals/userids with the same name as their logon ids that they use on MQ Client systems on the MQ server system. And then leave the svrconn channel mcauser balnk. Assign authorities to these principles for specific objects. That way anybody coming in with their specific userid would be validated.

Unlike your design where you would need multiple svrconn channels with multiple userids in mcauser attribute, if i got it right.

Also search this forum for 2035, authorized, principal key words seperately and you would find a lots of threads. Just skim through them and most likely you would get all your queries answered.


Cheers
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator
Back to top
View user's profile Send private message Send e-mail Visit poster's website
shogan2003
PostPosted: Fri May 14, 2004 8:03 am    Post subject: Reply with quote

Centurion

Joined: 03 Jul 2003
Posts: 133
Location: London

Kumar

Thanks for that. I do regularly search using those key words. I shall implement your advice.

Do all you grand masters sort of look down on Earth like the Greek gods in that great Ray Harryhausen feature 'Jason and the Argonauts ?
_________________
MQSI2 certified specialist
MQSeries certified specialist
Back to top
View user's profile Send private message Send e-mail
PeterPotkay
PostPosted: Fri May 14, 2004 8:41 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

Leaving an MCAUSER on a SVRCONN channel blank is like leaving the vault in a bank open and saying to yourself "Well, only the people that should go in there will."

You are going to go thru all the trouble of running setmqaut commands against all those IDs, and then some clown comes along, defines a user called mqm on their machine, and connects to your QM, completly circumventing your "security" measures.

The thing to do is create a SVRCONN channel for a particular group of peoples. Tag the MCAUSER with GROUP1, and then give GROUP1 setmqaut authority only for the queues it should have. If a new set of users comes along and they need different authorities, then create a new SVRCONN channel and set its MCAUSER to GROUP2, and run setmaaut commands for GROUP2. etc, etc, etc.

Now, you still got the problem of someone from GROUP1 connecting to the channel for GROUP2, and getting those rights. The only way to prevent that is exits, or use channel names so weird GROUP1 can't guess GROUP2's channel name, or use SSL.

Bottom line: A SVRCONN with no MCAUSER (and no exit) has ZERO security.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
shogan2003
PostPosted: Fri May 14, 2004 9:29 am    Post subject: Reply with quote

Centurion

Joined: 03 Jul 2003
Posts: 133
Location: London

Now THAT is what I call an answer.
Thank U v much
_________________
MQSI2 certified specialist
MQSeries certified specialist
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2, 3, 4  Next Page 1 of 4

MQSeries.net Forum Index » General Discussion » security and clients
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.