| Author |
Message
|
| sanjoo |
 Posted: Tue May 15, 2007 10:52 am Post subject: How to granularize authorization to MQ resources |
 |
|
Acolyte
Joined: 26 Oct 2005
Posts: 65
|
In our scenario an application connects to MQ server through app servers and by doing this user id becomes useless since identity of the requesting application is lost. And then it becomes very difficult to restrict access of MQ resources to only concerned applications.
For example, application AAA should have visibility to only AAA_REQ queue. But since application BBB also passes same generic user id, it can also access AAA_REQ which is meant for only application AAA and vice versa.
Is there any security solution which would meet this requirment?
Thanks in advance.
_________________
Sanjoo
Keep smiling
 |
|
| Back to top |
|
 |
| RogerLacroix |
| Posted: Tue May 15, 2007 11:19 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
Having 2 different applications use the same UserId to connect to MQ is a bad idea / design.
If you are looking for a commercial solution then there are 3 in the MQ marketplace:
1. Capitalware's MQ Authenticate User Security Exit
2. IBM's WebSphere MQ Extended Security Edition V6
3. Primeur's Data Secure for WebSphere MQ
Of course, I'm going to suggest that you have a look at MQAUSX. 
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| sanjoo |
| Posted: Tue May 15, 2007 1:56 pm Post subject: |
|
|
Acolyte
Joined: 26 Oct 2005
Posts: 65
|
Thanks Roger.
We are doing comparitive analysis between these products and trying to figure out which would be the best fit in our case.
I have gone thru some documentation for IBM's WebSphere MQ Extended Security Edition V6. They say you can granularize authorization but I am not sure what and how they achieve it.
As I mentioned in problem statement, does Capitalware's MQ Authenticate User Security Exit provide solution for this? Even though you have same user id, on what basis authorization will be granted by any of these tools?
Apprecite you help.
Thanks again.
_________________
Sanjoo
Keep smiling
|
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue May 15, 2007 2:47 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
The UserId and Password that is used with MQAUSX can be the same UserId as your application is running under or a different UserId.
In your case, I would suggest setting up an application UserId and Password. i.e. The same as you would if you were connecting to Oracle, DB2, etc...
Your client-side would provide the credentials in the setup of your connection and then server-side component would authenticate your credentials. If successful then the connection is allowed, otherwise the connection is terminated
After successful authentication, server-side component can be configured to use the incoming UserId, or the value in the MCAUSER field of the channel or some other UserId.
The ACL (Access Control List), the 'who can access what', would be done via the setmqaut command.
Hence, you would have full protection of your MQ resources.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue May 15, 2007 2:51 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If your app servers are making client connections to the qmgrs, then you can configure different QCFs for each app, to use different channels, that then have different MCA users set on them.
If your app servers are making bindings connections, then you can configure different instances of the app servers, to run under different actual user ids, to run different apps in each instance.
And fjb_saper would probably mutter something about JAAS authentication aliases.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue May 15, 2007 2:59 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| jefflowrey wrote: |
| to use different channels, that then have different MCA users set on them. |
Of course that means whoever connects to that particular channel, proper program or not, gets the same access to the queue. Not really security but rather obfuscation.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue May 15, 2007 3:50 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| RogerLacroix wrote: |
| jefflowrey wrote: |
| to use different channels, that then have different MCA users set on them. |
Of course that means whoever connects to that particular channel, proper program or not, gets the same access to the queue. Not really security but rather obfuscation. |
The point seemed to be granularity of control, not security.
And there's nothing that requires that the channels be accessible from anything other network address than the app server machine.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue May 15, 2007 6:29 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jefflowry wrote: |
| And fjb_saper would probably mutter something about JAAS authentication aliases. |
Good thinking Jeff. You beat me to it.!! 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue May 15, 2007 6:51 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| jefflowrey wrote: |
| And there's nothing that requires that the channels be accessible from anything other network address than the app server machine. |
True but also true, via the same channel:
- A a desktop PC can access the queues,
- Another web server can access the queues,
- Some consultant from their latpopt can access the queues,
- etc...
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| sanjoo |
| Posted: Wed May 16, 2007 6:07 am Post subject: |
|
|
Acolyte
Joined: 26 Oct 2005
Posts: 65
|
Thanks everybody. This really helps.
Just to clarify, here security is of primary importance.
One quick question Roger. You talked about how MQAUX could help to assign different user ids to applications. Does this involve any change from application side? (Please say no .....
If you have any documentation on MQAUX, can you please paste that link here?
_________________
Sanjoo
Keep smiling
|
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed May 16, 2007 6:45 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| sanjoo wrote: |
| One quick question Roger. You talked about how MQAUX could help to assign different user ids to applications. Does this involve any change from application side? (Please say no ..... |
No.
All of the MQAUSX manuals are at:
http://www.capitalware.biz/mqausx_manuals.html
The client-side setup is in the MQAUSX Client-side Configuration Manual.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| sanjoo |
| Posted: Wed May 16, 2007 6:46 am Post subject: |
|
|
Acolyte
Joined: 26 Oct 2005
Posts: 65
|
I got the manuals.... Thank you.
One thing I noticed about MQ Authenticate User Security Exit that is specifically created for the purpose of securing SVRCONN channels via fully authenticating (UserID & password) of the client
application.
But it doesn't encrypts /decrypts data? I think that may be a major security concern for link level security?
What say Roger?
_________________
Sanjoo
Keep smiling
|
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed May 16, 2007 6:52 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
MQAUSX is an authenticating MQ security solution. Hence, it encrypts the password and sends the UserId and encrypted password to the remote queue manager. Since MQAUSX provides for full authentication of a client then ACL rules can be created against that UserId there by securing the MQ resources.
It does not encrypt / decrpyt the message body. This is a totally different subject.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| sanjoo |
| Posted: Wed May 16, 2007 7:40 am Post subject: |
|
|
Acolyte
Joined: 26 Oct 2005
Posts: 65
|
hey Roger... just wanted to clarify one thing. In overview manual of MQAUSX -->
The client-side security exit has been tested with the following applications:
· IBM's MQ Explorer v5.2, v5.3 and v6.0
· SupportPac MO71 (MQMon)
· IBM's WBIMB Eclipse Tool Kit
· Mercury's SiteScope
· Capitalware's MQ Visual Edit
· Capitalware's MQ Visual Browse
· Capitalware's MQ Batch Toolkit
· Any program that uses Client Channel Tables (i.e. SupportPac MS03, WatchQ, etc.)
Is this tool tested for Java/VB/.NET apps which use property files or JNDI lookup?
One more question... can this be implemented even on mainframe QM and mainframe client apps?
Appreciate your help.
Thanks a lot.
_________________
Sanjoo
Keep smiling
|
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed May 16, 2007 8:22 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| sanjoo wrote: |
| Is this tool tested for Java/VB/.NET apps which use property files or JNDI lookup? |
Yes, it supports J2EE applications - see section 3.8 of the client manual.
Yes, it supports any Windows application that uses a Client Channel Table (see section 3.9) or has the ability to set the SCYEXIT field of the MQCONNX.
| sanjoo wrote: |
| One more question... can this be implemented even on mainframe QM and mainframe client apps? |
We are currently porting MQAUSX to z/OS.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
|
|
