How can we set up a Security Exit in UFO?
UFO provides an exit point that can be called before executing a UFO application. The security exit is passed the name of the 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 UFO system (CICS region), the security exit must have access to a list or table of 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, UFO will execute the application. If not, UFO will return an error message, the user will be denied access, and UFO will not execute the application.
Writing a UFO Security Exit
Work Area Layout
Byte | Contents |
1 | Resource type code passed by UFO identifying the UFO component type. Valid codes are:
|
2 | Authorization code, as returned by the security exit. Valid codes are:
|
3-8 | Reserved |
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
GBLB &DFHEIPL
&DFHEIPL SETB 1
PRINT ON
UFOSCBAR EQU 5
UFOSCBDS DSECT
USING *,UFOSCBAR
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
SECEXIT CSECT
USING SECEXIT,10
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
*
MVI UFOSAC,UFOSAY
GOBACK EQU *
END
Enabling the Security Exit
The security exit must be defined to the CICS region:
The RDO definition for the security exit should look like the following:
DEFINE PROGRAM(security-name) GROUP(group-name)
RESIDENT(YES) LANGUAGE(language-type)
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.
In order for the security exit to be known to 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:
UFMAINIT TYPE=ENTRY,
OPSYS='Z/OS',
SECEXIT=security-name,
STAGE=P,
SYSTEM=P,
TYPSTO=SYST,
USCSPCE=USRIOX,
USFSPCE=USFIOX,
STGSPCE=$$VSAM,
STGNAME=UFOSTG
UFMAINIT TYPE=FINAL
END
If you need to make changes to the security exit while CICS is running, the UFO command NEWCOP can be issued to enable a new version of the security exit:
UFO NEWCOP security-name