I want to implement following security mechanism. I will have two user groups. I have a transaction thru which you can browse and optionally update data. I want to restrict update option to certain user group only.
I would define two transaction codes for the same transaction TRN1 for Browse and TRN2 for update. Both will point to same application program.
In the application program if user selects 'update ' option the program should check if the current user has acess to TRN2 and then only allow for update.
Is it possible to implement such mechanism and if so how?
I recommend use of the EXEC CICS QUERY SECURITY command descibed in the CICS application Programming Reference Manual. You can define your own resource class and make it mean what you want. In your case let's say the resource class is called TRANACCS ( for transaction access) and refers to 'access to the data used by a transaction'. Then a particular resource could be XXXX, the transaction code of the transaction that sometimes browses and sometimes updates. Users in group 1 will be given READ authority to resource XXXX in resource class TRANACCS, users in group 2 will be given UPDATE access.
Your application could issue a command something like:-
EXEC CICS QUERY SECURITY RESCLASS('TRANACCS') RESID('XXXX') RESIDLENGTH(4) UPDATE(cvda)
On completion of the command the cvda will be set to UPDATABLE for users in group 2 or NOTUPDATABLE for users in group 1.
This approach avoids the need to set up multiple transaction codes for the same application program and provides a general scheme if you need to do something similar for other transactions.
But you could use two transaction codes, one of them (TRN2 in your example) being a dummy that is NOT defined to CICS but is only defined to your external security manager. Users in group 1 are authorised to initiate (eg via a terminal) both transaction codes (TRN1 and TRN2). Users in group 2 are authorised only to the real transaction code (TRN1). The application then uses QUERY SECURITY to check if the user is authorised to initiate (RESTYPE('TRANSATTACH')) the dummy transaction code (RESID('TRN2')). One drawback of this approach compared to the general scheme I recommend, is that you must be careful not to define the dummy transaction code to CICS for some other purpose, now or in the future.
I strongly recommend you read the chapter in the "CICS RACF Security Guide" on security checking using the QUERY SECURITY command before attempting to use this function.
This was first published in March 2002