| Author |
Message
|
| friedl.otto |
 Posted: Fri Jul 06, 2007 4:35 am Post subject: Identification/Authorisation |
 |
|
Centurion
Joined: 06 Jul 2007
Posts: 116
|
Preamble
To avoid a can of whoop-ass being opened on me, I have perused the
IBM Redbook "WebSphere MQ V6 Fundamentals" as well as the Security
tree on http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0.
My Setup
I have an IBM Websphere MQ v6.0 queue-manager running on Solaris 9.
I am trying to allow less savvy users to use MQ Explorer on WinXP, but
not to allow them to abuse the power by accidentally doing stupid and/or
unauthorised things.
My Workaround
I wrote a simple little "read-only" browser in Java, but I'd rather be using
the built in security of MQ, instead of re-writing MQ Explorer, and having
to tweak and support it as opposed to doing my job.
My Question
How do I allow selective access (inquire, get, put, browse, delete, clear)
on say local queues, using MQ Explorer on Windows XP, connecting to a
Solaris 9 queue-manager? My big issue is the user/group authentication
issues between Windows and Solaris. How does that work?
Is this...
| Code: |
setmqaut -m my_qmgr -n my_queue -t queue -g novices +inq +browse
|
...part of my salvation?
Could someone point me to a decent example?
Last edited by friedl.otto on Fri Jul 06, 2007 4:40 am; edited 1 time in total |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Jul 06, 2007 4:39 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 06, 2007 4:40 am Post subject: Re: Identification/Authorisation |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| friedl.otto wrote: |
Is this...
| Code: |
setmqaut -m my_qmgr -n my_queue -t queue -g novices +inq +browse
|
...part of my salvation?
|
I'd say so, though for the permissions you want to grant you may find the +allapi option less typing.
Another option is for you to create a new SVRCONN channel with "novice" in the MCA User Id and get your people to client onto the box using that. You'll still need to authorise "novice" as above, but it would save you administering a group.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| friedl.otto |
| Posted: Fri Jul 06, 2007 5:00 am Post subject: |
|
|
Centurion
Joined: 06 Jul 2007
Posts: 116
|
First off ... thank you very much jefflowrey and Vitor for you quick response.
The "Using WebSphere MQ Explorer as a read-only viewer" article by Dale Lane
will soon be attempted on my test config, however, I'm still a tad confused
how MQ Explorer (Eclipse) on Win32 would communicate a domain user
"novice" to a Solaris 9 machine configured with a user of the same name and
know that they are indeed talking about the same user (passwords could
differ etc.) |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 06, 2007 5:11 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| friedl.otto wrote: |
I'm still a tad confused
how MQ Explorer (Eclipse) on Win32 would communicate a domain user
"novice" to a Solaris 9 machine configured with a user of the same name and
know that they are indeed talking about the same user (passwords could
differ etc.) |
MQ relies on the authentication of the host machine. Hence if Windows passes over a user id of "novice", MQ will assume that the user id has been validated and matches the user id with it's rules. For this reason case is significant as Windows user ids are case insensitve but Unix ones are not.
You'll have noticed this on both platforms as you don't need to sign onto the queue manager with a password, only the box running it. The queue manager picks up the credentials and uses them on the assumption the user has been correctly authenticated.
And the article is a variation of my suggestion. Or my suggestion is a variation of the article. Take your pick but it does work. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Fri Jul 06, 2007 5:26 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Fri Jul 06, 2007 8:52 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi friedl.otto,
Your security thinking is very linear. You are assuming that (1) everybody will follow the rules and (2) everybody will use MQ Explorer.
Since you are an MQAdmin, here is an easy back door. If people know your Solaris UserId (i.e. friedl) then since MQ Explorer is based on Eclipse (hence Java), they simply set the following JVM parameter -Duser.name=friedl . Voila, they are you!! 
Secondly, what if they don't use MQ Explorer but use MO71 or WMQTool or MQJExplorer or MQ Visual Edit, etc... Most of those programs allow the user to select their own MQ UserId. And for MO71, you can use the dummy exit here to get the 'mqm' access.
So, you will be spending a whole lot of time for not. MQ has very weak security. Therefore, unless you strongly secure the queue manager, then there is no real point in doing what has been suggested.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| Vitor |
| Posted: Sat Jul 07, 2007 6:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| RogerLacroix wrote: |
MQ has very weak security. Therefore, unless you strongly secure the queue manager, then there is no real point in doing what has been suggested.
|
It's enough to keep the proles away from the MQ objects; you can pull a few other pranks if the proles are imaginative / devious / cunning /lucky.
But Roger is quite right, if you want proper strong security you need SSL or similar. One way of acheiving this is Capitalware's fine product.
I am not now nor have I ever been associated wih Capitalware, any product purchasing decisions are the responsibility of the purchaser nd should only be made in accordance with their established procurement policy
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| friedl.otto |
| Posted: Mon Jul 09, 2007 5:54 am Post subject: |
|
|
Centurion
Joined: 06 Jul 2007
Posts: 116
|
Your security thinking is very linear. You are assuming that
(1) everybody will follow the rules and
(2) everybody will use MQ Explorer.
HeHeHe ... I never assumed anything ... I just found it flabbergasting that
Big Blue have such speccy security on industry standard technology. 
My aim however is to keep the proles put. 
Since you are an MQAdmin, here is an easy back door. If people know
your Solaris UserId (i.e. friedl) then since MQ Explorer is based on Eclipse
(hence Java), they simply set the following JVM parameter -Duser.name=friedl.
Voila, they are you!!
Secondly, what if they don't use MQ Explorer but use MO71 or WMQTool or
MQJExplorer or MQ Visual Edit, etc... Most of those programs allow the
user to select their own MQ UserId. And for MO71, you can use the
dummy exit here to get the 'mqm' access.
So, you will be spending a whole lot of time for not. MQ has very weak
security. Therefore, unless you strongly secure the queue manager, then
there is no real point in doing what has been suggested.
Gives ShoddySec gets a completely new meaning!
RogerLacroix ... you know of any MQ fortification tomes akin to
O'Reilly's "Hardening Cisco Routers"? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jul 09, 2007 11:07 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
There's an excellent article by T. Robb Wyatt on devWorks that's a must read for anyone considering securing their queue manager.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Mon Jul 09, 2007 12:56 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| friedl.otto wrote: |
RogerLacroix ... you know of any MQ fortification tomes akin to
O'Reilly's "Hardening Cisco Routers"? |
Hi,
Well, sense you asked...
(1) If you want server-side only verfication then have a look at:
- Capitalware's MQ Standard Security Exit
(2) SSL is a good node-to-node security method ONLY if the nodes are completely locked down.
(3) If you want proper end-to-end security for MQ then you have 3 choices:
- Capitalware's MQ Authenticate User Security Exit
- IBM's WebSphere MQ Extended Security Edition V6
- Primeur's Data Secure for WebSphere MQ
Hope that helps.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| friedl.otto |
| Posted: Fri Jul 13, 2007 4:32 am Post subject: |
|
|
Centurion
Joined: 06 Jul 2007
Posts: 116
|
IBM's WebSphere MQ Extended Security Edition V6
Is that any good ... if these scaly bastards could not even get it right in the first place? |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 13, 2007 5:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| friedl.otto wrote: |
IBM's WebSphere MQ Extended Security Edition V6
Is that any good ... if these scaly bastards could not even get it right in the first place? |
I'm sure there are those among us who would comment that one of the principle drivers behind base MQ security being a little less than robust is to encourage the purchase of the additional product to strengthen it.
For what it's worth (and accepting the can of whoop-ass you orginially feared is probably going to be opened in my direction) I've very seldom seen any additional security product in use in the wild. As I've commented before, the standard features keep the proles out of the objects and that's typically enough for most organisations. This does assume that you've followed the standard advice; blocking svrconn channels, actually using setmqaut to restrict access, not running application programs as mqm, the MQ equivalent of changing the router's admin password from "password".
MQ does not exist in a vacume. The queue managers will typically be being a number of layers of infrastructure and site security policies will aid and protect you.
But to deflect Roger's ire somewhat, things like the MO71 support pac will allow unauthorised access in the way he suggests. But anyone who knows enough to use MO71 in that way probably has enough MQ administrative knowledge to subvert anything you do, in the same way a properly qualified Unix admin can break into anything other than the most heavily protected box. No system is safe from it's administrators in the same way no bank is safe from it's security guards; it's the proceedures controling their activities that make it safe.
Who watches the watchers?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
