Signon Processing › What is Signon Processing?

What is Signon Processing?

Signon Processing Functions

The major function of signon processing is to identify and validate the user requesting CA IDMS services. In addition, signon processing will also cache user-related information such as the list of groups to which a user belongs and profile information.

Explicit Signon

From within a DC/UCF system, signon processing can be initiated explicitly by executing the SIGNON task code or by linking to RHDCSNON from within a user-written application. If CA IDMS/DC is directly controlling terminal access, then an explicit signon must be issued in order to identify the user accessing DC/UCF from an interactive terminal.

Automatic Signon

Signon processing occurs automatically under the following conditions:

• In local mode batch, signon processing occurs within the batch address space when the first security check is issued.
• Within the central version, system signon processing occurs when the first database request is issued from the externally executing application. This applies to applications executing in batch, CMS, TSO, or a front-end teleprocessing monitor such as DC or CICS.
• In UCF applications, signon processing occurs in the UCF back-end when the UCF connection is made from the front-end application.

General Processing Flow

The processing at each step of signon, and whether or not a particular step is actually executed, is based on a number of factors, such as the environment in which signon is occurring and how signon processing is controlled. These factors and their influence on signon processing are discussed later in this chapter.

Signon processing consists of the following steps:

1. Identify the user requesting CA IDMS services.
2. In DC/UCF:
   • If a user is already signed to the terminal, sign the user off.
   • If the user is signing on to an interactive terminal and is already signed on to another interactive terminal, deny the signon request unless multiple signon is allowed.
3. Validate the user and password. An asymmetric uni-directional non-unique hash routine is used to "encrypt" the password associated with a user id. When a user signs on, the password entered is processed using the hash routine and compared to the "encrypted" password value associated with the user id.
4. In DC/UCF, update the user's password if requested (explicit signon requests only).
5. Build the group list for the user.
6. Build the session profile from system and user profile information, subject to specifications on the initial #SECRTT.
7. If signon is the result of linking to RHDCSNON, invoke the CLIST identified by the CLIST attribute, if one exists in the session profile.