| Author |
Message
|
| camvdcs |
 Posted: Mon Jun 16, 2003 11:44 am Post subject: MQ Security - getting started. |
 |
|
Newbie
Joined: 16 Jun 2003
Posts: 6
|
We have been using MQ series for a number of years. Current version is 1.2 and migrating to 5.3.1. It's use has been confined to intercommunication between mid-tier servers and the mainframe applications. We are now considering offering it to our clients to connect to our applications. We would initally set it up to use link security with a Server Certificate. SSL would run on users coming in from the Internet and talking to a QMGR on a Solaris. The mainframe app would issue a GET to receive the message from the Solaris QMGR. As a starting point I'm wondering if there is a need secure which client can write or read a queue?
Our application is CICS. We normally call RACF to see if a user is authorized to a non-CICS resource. To do this you would need a terminal and when MQ triggers a task to start in CICS, there is no terminal facility. Has anyone tackled this problem yet? I figure we would have to build some kind of new security infrastructure.
Any comments would be greatly appreciated. Thanks.  |
|
| Back to top |
|
 |
| interactivechannel |
| Posted: Tue Jun 17, 2003 1:13 am Post subject: |
|
|
Voyager
Joined: 20 May 2003
Posts: 94
Location: uk
|
| WMQ 5.3 client for z/Os doesn't exist. Hence you can secure your internet users, assuming they are on a supported client, but you'll need to use a security exit on the mainframe connection or install WMQ 5.3 server. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jun 17, 2003 2:07 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You don't need a terminal to use RACF under CICS, you can simply issue EXEC CICS QUERY SECURITY calls.
You can also start transactions under any given RACF userid (EXEC CICS START TRAN) if you define surrogate RACF access rights for the CICS region.
Look at my article in the Oct 1999 issue of MQ Update. This is available free (for more recent issues you need to subscribe and can contact me for a 7.5% discount code).
www.xephon.com/mq |
|
| Back to top |
|
|
| camvdcs |
| Posted: Tue Jun 17, 2003 7:42 am Post subject: |
|
|
Newbie
Joined: 16 Jun 2003
Posts: 6
|
Your right zpat. I just tested calling QUERY SECURITY without a terminal and it uses the userid the task is running under to check the resource. We have a module that did the QUERY SECURITY but it also interogated the TCT areas. That's why I was let to believe the requirement of the terminal facility for RACF call. Thanks for the tip.  |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jun 17, 2003 8:23 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| On more recent levels of CICS I believe you can test the access for named userids. In many cases it is more useful to extract the user credentials from the message and check their access - and/or run the transaction under their userid, not the CICS region id. |
|
| Back to top |
|
|
| camvdcs |
| Posted: Tue Jun 17, 2003 8:37 am Post subject: |
|
|
Newbie
Joined: 16 Jun 2003
Posts: 6
|
When the MQ trigger starts the CICS task, it is running under the CICS default userid. I was thinking of retrieving the userid from the message and starting another task with the userid to check his authorization to do a specific business transaction.
Initially our Design team suggests that all clients do PUTS to the same MQ queue. I'm wondering if we should have separate input MQ queues for each client. I think I could QUERY SECURITY with their userid to see if they are authorized to write to the input queue name. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jun 17, 2003 9:33 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
What we do is run one (or more) central tasks which retreive messages from the (single) request queue, and then start transactions under the userid passed in the message (having verified the password) passing the message data (or a reference to a copy of a message if it's a long one) in the COMM area.
For performance reasons we assign security tokens in the reply message which can be used to avoid the overhead of repeated password checks for the next request from the same user (these tokens expire of course).
Again I mention my article in MQ update to save repeating it here. |
|
| Back to top |
|
|
|
|
