Writing Your Own User ID Security Exit

User ID Security Exit Support › Writing Your Own User ID Security Exit

Writing Your Own User ID Security Exit

The security exit is coded as an assembler language module, or suite of modules. These modules must be able to:

Accept the various parameter lists passed to it
Return the designated return codes associated with those parameter lists

When the exit has been written, you link it into a standalone load module. The name of this load module is arbitrary (for example, MYEXIT). The load module is placed in an APF authorized library or another library concatenated to the load library in the JCL STEPLIB DD statement. Change the JCL parameters to include SEC=name, where name identifies the load module (for example, SEC=MYEXIT).

Your region determines the type (partial or full security) of exit being provided. It does this by examining the data at the entry point of the exit load module.

The entry point of the security exit load module must look like this:

ENTRY  B    SKIP-ENTRY(,R15)   Skip descriptor
       DC   C'S'               Required, constant 'S'
       DC   AL1 (0)            Required, interface version,
       DC   AL1 (type)         Required, exit type,
                                         0: partial
                                         4: full
       DC   C'X'               Required, constant 'X'

The security exit can be AMODE 24 or 31, and RMODE 24 or ANY. All data areas and parameter lists passed to it are located in storage below 16M.

This diagram shows how a region loads and identifies a full security exit and how your region locates the entry point of the exit's code.

The block diagram shows the relationship between a region and the load module of a full security exit.

This diagram shows how a region loads and identifies a partial security exit and how your region locates the entry point of the exit's code.

The block diagram shows the relationship between a region and the load module of a partial security exit.

Exit Execution

The exit executes within an operating system subtask and can therefore issue WAITs or SVCs that suspend the task without affecting the primary task.

Note: In z/OS systems, the subtask is attached sharing subpool 50 with the main task. This allows other exits (which also use subpool 50) to share common storage areas with the security exit.

Calls to the exit are serialized across the system—if one call to the exit is in progress, any subsequent calls are queued and processed one-by-one, in request order. Serial request processing means that the exit does not have to be written as reentrant.

The exit is called for two reasons:

Information—to keep the security system informed of developments or system changes
Function request—to request that a function be performed
Important! If an abend occurs in the exit and the requested function cannot be performed it is regarded as a security exposure and the region terminates with the internal abend 268-01.

Supported Exit Calls

The following table lists the calls supported by the exit, their type, and their function codes:

Call	Type	Function Code
System Initialization	information	0
System Close Down	information	4
User Logon Request	function request	8
User Logoff Request	information	12
Logon Verification	function request	16
Change Password	function request	20
Return User ID Information	function request	24
Update User ID	function request	28
&SECCALL EXIT	function request	32
Return Sequential User ID Information	function request	36
Add User ID	function request	40
Delete User ID	function request	44

The following sections provide the parameter lists for each call.