CA UFO provides an exit point that can be called before executing a CA UFO application. The security exit is passed the name of the CA UFO resource and the type of the resource that is being executed. The security exit can then use this information to determine if the execution of the application is permitted.
Since only one security exit is permitted for each CA UFO system (CICS region), the security exit must have access to a list or table of CA UFO applications to be checked along with any other desired criteria, such as a list or table of users that are authorized to access them. In the sample exit provided in this article, the table is a VSAM KSDS file.
If access to an application is attempted and the security exit permits it, CA UFO will execute the application. If not, CA UFO will return an error message, the user will be denied access, and CA UFO will not execute the application.
Writing an CA UFO Security Exit
- CA UFO loads the security exit and branches to the entry-point address of the security exit via an assembler BALR 14, 15 instruction.
- Register 1 contains a pointer to the work area (described below).
- Register 13 points to the register save area.
- The security exit is responsible for saving and restoring the registers passed by CA-UFO.
Work Area Layout
Resource type code passed by CA UFO identifying the CA UFO component type. Valid codes are:
A Indicating CA UFO ACB
D Indicating CA UFO DSD
P Indicating CA UFO PDS
Authorization code, as returned by the security exit. Valid codes are:
Y Access is authorized
N Access is not authorized
|9||Actual length of the resource name, minus one|
|10-17||Name of the resource to be checked|
Below is an example of a security exit that checks the parameters passed against a table in a VSAM KSDS file called "MYFILE". The PROLOG and EPILOG parameters that are passed to the CTS translator handle the saving and restoring of the registers for you. If the resource name is not found or the resource type is not "A", the authorization code is set to "N", and CA UFO issues the following error message to the user:
EX94 E Access DENIED due to attempted SECURITY VIOLATION
Sample Assembler Security Exit
*ASM CICS (SP PROLOG EPILOG
SECEXIT DFHEIENT CODEREG=10
&DFHEIPL SETB 1
UFOSCBAR EQU 5
UFOSRTC DS CL1 RESOURCE TYPE CODE
UFOSRTA EQU C'A' TYPE = APPLICATION
UFOSRTD EQU C'D' TYPE = DSD (FILE DEFINITION)
UFOSRTP EQU C'P' TYPE = PROCEDURE
UFOSAC DS CL1 AUTHORIZATION CODE
UFOSAY EQU C'Y' ACCESS IS AUTHORIZED
UFOSAN EQU C'N' ACCESS IS NOT AUTHORIZED
UFOSCBR1 DS X RESERVED
UFOSCBR2 DS X RESERVED
UFOSCSAA DS F RESERVED
UFOSRNL DS X RESOURCE NAME LENGTH (INTERNAL)
UFOSRN DS CL8 RESOURCE NAME
DFHEISTG DSECT WORKING STORAGE FOR EXIT
FILEREC DS CL80 RECORD LIST/TABLE TO BE CHECKED
LR UFOSCBAR,1 LOAD PARAMETER ADDR INTO R5
MVI UFOSAC,UFOSAN SET AUTHORITY TO NO
EXEC CICS HANDLE CONDITION NOTFND(GOBACK)
EXEC CICS READ FILE('MYFILE') RIDFLD(UFOSRN) INTO(FILEREC)
CLI UFOSRTC,C'A' TEST TO SEE IF IT IS AN ACB
BNE GOBACK IF NOT, THEN NOT AUTHORIZED
* add any desired additional checks here
GOBACK EQU *
Enabling the Security Exit
The security exit must be defined to the CICS region:
- Add a RDO definition for the module name of the security exit.
The RDO definition for the security exit should look like the following:
DEFINE PROGRAM(security-name) GROUP(group-name)
security-name the name of the security exit load module.
group-name the name of the group containing the RDO entry.
language-type the language the security exit is written in.
- Identify the security exit to the CA UFO INIT table
In order for the security exit to be known to CA UFO, you will need to update the SECEXIT parameter in the UFO INIT table (macro UFMAINIT, load module UFLAIN32).
Below is an example of a UFO INIT table with the SECEXIT parameter:
If you need to make changes to the security exit while CICS is running, the CA UFO command NEWCOP can be issued to enable a new version of the security exit:
UFO NEWCOP security-name