Security during Signon Command

When you execute a SIGNON command through the batch, interactive, or operator interface, security control points exist in the Sterling Connect:Direct® user region (or API) and the Sterling Connect:Direct DTF region.

The stage 1 signon security exit is the initial control point, as shown in the following figure. This optional control point is a user exit that gains control in the region of the user. The exit can inspect and modify the SIGNON command parameters.

The next control point occurs in the DTF region and can be a stage 2 security exit or the Sterling Connect:Direct Authorization Facility.

The following SIGNON command flow traces the security flow. The step numbers correspond to the steps in the illustration.

1. When you issue a SIGNON command, the API SIGNON command processor calls the stage 1 signon exit. If the stage 1 exit is not found, normal signon processing continues.

   When invoked, the stage 1 exit receives a pointer to the User Interface Control Block (UICB) that contains information regarding the signon attempt. For a listing of UICB fields, refer to the chapter on the application programming interface in IBM® Sterling Connect:Direct for z/OS® User Guide.

   If you specify a password on the SIGNON command, the stage 1 exit returns control to Sterling Connect:Direct without making any modifications to the UICB, and signon processing proceeds. The stage 2 exit verifies the USERID and PASSWORD that are coded on the SIGNON command for system entry validation and all subsequent security calls.

   If you do not specify a password on the SIGNON command, Sterling Connect:Direct extracts the USERID from the security system control block built for this address space (when the TSO user logged on to TSO or when the BATCH job began execution) and puts that USERID into the UICB.

   Note: Stage 1 exit keys off the password, not the user ID. So, if you do not specify a password but do specify a user ID, the stage 1 exit ignores that user ID and overlays it with the address space user ID that is picked up from the security system control block.

   When the user ID is moved to the UICB, the exit fills in a special password of IUI, BATCH, or STC, depending upon what environment the signon comes from (Sterling Connect:Direct cannot access the password for the address space user ID), and control returns to Sterling Connect:Direct.

   The benefit of running with a stage 1 signon exit is that Sterling Connect:Direct batch jobs do not need hardcoded passwords in their SYSIN data streams.

   The sample stage 1 exit is shipped with the dummy passwords of IUI, BATCH, and STC coded in the exit. Change these passwords for each installation to avoid the chance that another site is using the same dummy passwords. You can change these passwords by editing the source for DGACXSIG and the appropriate validation in the macro DGASECUR (for the stage 2 exit). If a user id has a security subsystem password that matches one of the dummy passwords, that user id will be unable to sign on to Sterling Connect:Direct under some circumstances until the password is changed.

2. If the stage 1 processing is successful, the API SIGNON command processor passes the SIGNON command to the DTF where the DTF SIGNON command processor is invoked.

3. The DTF SIGNON command processor calls the stage 2 security exit or the Sterling Connect:Direct Authorization Facility. The stage 2 exit recognizes special passwords of IUI, BATCH, and STC as being assigned by the stage 1 exit. All calls to the security system for verifications verify authorizations by user ID only.

Regardless of how your system is implemented, this processing flow verifies the authority of the requesting user to perform Sterling Connect:Direct functions by checking the ABM (Authorization Bit Mask) for this user. The ABM is built through the stage 2 security exit or through the Sterling Connect:Direct Authorization Facility at signon and Process start.