MVSFORUMS.com

[haqshaik]

Hi,
At my shop the messages will be passed from the MQ on the UNIX box, to a queue on the Mainframe. The local queue on the mainframe is associated with a trigger mechanism , so that as soon as the message arrives on the queue, CKTI will trigger a program A. Program A links to Program B. In Program B i am making database calls. As i am not passing any userid from the message on the unix box, the cicsregion name is being replaced as the user id and it was failing while making the database calls, as such userid does not exists. I have asked my sytem people to create a user id and put a DB2 entry for authid as the created userid rather than authtype = userid. Its working now. Is there any way in which you can replace the default userid in my case cicsregion name being picked, when the application is triggered?. I am not sure how to pass the userid from with messaged that is being sent from the unix box.
What is the usual Industry standard procedure to implement the security?

Anythoughts will be helpful..

Thanks,
Salauddin

[Manas Biswal]

haqshaik,
did u try the method that I had suggested on your earlier thread. Using the SET CURRENT SQLID to set the database auth id.

Regards,
Manas
_________________
There is no path to peace. Peace is the path.
- Mahatma Gandhi (1869-1948)

[kolusu]

[haqshaik]

Hi Kolusu and Manas,
First of all thanks for your valuable suggestions. I have try to use as Manas said by setting the current SQLID. I just added code to get to the userid which is being used to invoke the transaction when it is being triggerd from the MQ. The userid that is running the transaction in CICS region.
EXEC CICS ASSIGN
USERID(WS_USER_ID)
END_EXEC.
I have writen the WS-USER-ID in a TSQ and the value for WS-USER-ID shows the cicsregion name. Let the CICS region name is CICSXXXX. The the userid shown is CICSXXXX. As the transaction is running under the control of CICSXXXX, this is the userid which is being picked to do any database calls. As there is no such user id exists, even I am trying to do an set current sqlid it is failing.

As kolusu said, the userid will be there in the MQMD structure in field user identifier. But this is userid is not the one underwhich the transaction is being invoked, under which the database calls are being made. This user id will be popluated from the environment underwhich the message is contructed.
I wrote a bacth Job to put a message from a falt file into the loacl queue and enabled the trigger. Still the userid that is invokng the transacation is shown as CICSXXXX. But this time my tso userid got populated inthe user identifier field.
when I disbled the triggerand run the transacetion from the terminal, my userid is being refelectd and as my userid has got the authority to do the databse calls, its working fine.
what is my concern is the user id which is comming in the MQMD, should be able to run the transaction that is being triggered from the CKTI transacation rather than by the userid CICSXXXX.

if the user id comming in theMQMD structure as AAAA, the same user id should be able to run the tranacation xxxx, that is being triggered by the CKTI trnasaction. On the Minaframe, we can create a userid XXXX, which will have access to the database calls, so that the database calls work fine.

My other conecrn is how to make the userid AAAA, be able to run the trnasaction that is being triggered by the CKTI, by keeping the trigger enabled. Once the trigger is enabled, I do not have nay control to change the userid. even if I have i can not set to AAAA, to the already strated transaction by the userid CICSXXXX.

Hope I am clear ..

Thanks,
Salauddin

[haqshaik]

Further adding to my post, if we have such a dedicated userid, then any resources can be accsessed. Like if I have to access any VSAM files or other rssources on the mainframe can be accessed.

Thanks,
Salauddin

[Manas Biswal]

haqshaik,
My apologies. I am an ass. You are correct. In my hurry to provide you with a solution, I forgot the basics of DB2 authorizations. I did not realize that any particular primary authorization id (unless that id has SYSADM or Inst. SYSADM access) can only set the SQLID to one of its own RACF defined secondary authorization ids. Since, in your case, the primary authorization id is CICS defined and does not have a secondary RACF authorization id, it cannot set the SQLID to the id that you want.
OK, now you can do the following to get this SQLID solution to work out - Let us suppose following are your ids -
IDX - The CICS defined user id (CIC****)
IDY - The ID or RACF group that you want to use to access DB2 and has all the necessary DB2 privileges.
First of all get the IDX defined to RACF but need not grant the DB2 privileges to it. Now, make the IDY as the secondary authorization id for IDX. Your RACF people would be able to help you with that. If IDY is a RACF group, then add IDX to that group.
Now, when your transaction is invoked using IDX, you set the current sqlid to IDY in your code. (You should be able to do it now). And you should be able to access DB2.
This way, you have restricted DB2 access to only IDY. IDX will be able to access DB2 only through IDY. Suppose, further down the line, another ID - IDZ (from some other system or source) has to access DB2, you don't have to grant explicit DB2 privileges to IDZ. You simply have to add IDZ to the RACF group IDY. Your CICS code will also be untouched.

HTH....Regards,
Manas
_________________
There is no path to peace. Peace is the path.
- Mahatma Gandhi (1869-1948)

[haqshaik]

Manas , Thanks for your inputs. Currently the solution what we follwoed is merely falls on the lines you have indicated with subtle diffrences. I spoke to the RACF people and they were not willing to create a RACF id with the region name, in the sited example it is IDX. As the userid IDY is being populated in the useridentifier field of MQMD structure when the message comes from the midtier or solaries box, if here is a provision to invoke the triggered transaction by the CICS adapter (CKTI) to pick the userid IDY as the userid to run the triggered transaction from the moitoring transacation CKTI. If this provision can be made, then we do not have to put the authid option in the db2 entry. In your proposed solution, if the RACF people accept, we can take off the authid part in the DB2 entry and set the SQLID to the created userid IDY.

In the solution of AUTHID option, it is clear that if some one knows the userid or the way that has been implemented, are able to missoperate the system.
if i combinde the solutions provided by you and kolusu, as follows
lets assume that the userid that is comming from the midtier in the useridentifier filed as IDY. This user id has been created alsready. Add this to the SYSADM group. Pass the userid from the useridentifier field to the linking program through the commarea. In the linked program set the user SQLID to the userid IDY before making any database calls. In this case no where the userid is being visible to the other users. But in this case as well we need to have the IDX created and add IDY as the secondary authorization ID.

For me the Ideal solution looks like is to make the transaction primary authorization id as the userid that is being populated in the useridentifier give this id database access and no where we do not have to do anything.

It looks like to me it is do something at the MQ level, but for the security or RACF is a balck box.

Hope I am clear..

Any inputs will be of great help..

Thanks,
Salauddin