Personal identification

For technical and organizational reasons, it is often necessary to allow a number of different people access to a user ID. To do this it was usually necessary to inform all the authorized personnel of the password and account number. This procedure has the disadvantage that responsibility for the password is no longer vested in a single individual. In addition, the SAT entries can only be used to trace the source of an action to a group of people rather than to a specific individual.

The DIALOG-ACCESS operand in the /MODIFY-LOGON-PROTECTION command has been extended. This makes it possible to define further user IDs as being authorized users for a given user ID. A person-specific identification/authentication is performed during the interactive access check. The user ID specified as part of person-specific identification is taken over in the SAT entries. This means that it is possible to identify individuals as the source of specific actions even after the event.

The /SET-PERSONAL-ATTRIBUTES command is available for personal identification. It immediately follows the /SET-LOGON-PARAMETERS command and forces the user to enter a personal user ID together with a password. Specifying PERSONAL-LOGON= *YES in the /MODIFY-LOGON-PROTECTION command prompts the user to enter a personal identification.

The personal user ID is a normal user ID which can also be used as a logon user ID.

Only those privileges which are defined for the logon user ID are available to users who perform access by means of personal identification. The permissions for the personal user ID are evaluated only during the system access control check.

There is no underlying distinction between logon and personal user IDs in the user catalog. As a result, any user ID can be specified as the personal  user ID except the logon user ID itself (this is rejected with error SRM3206). 

The following measures are necessary in order to perform system access control  by means of personal identification:

• Create the personal user IDs. If the user ID is used only for the purposes of personal identification then it is enough to specify the name, password and account number.

• Specify PERSONAL-LOGON=*YES

• Set up a guard in which the access conditions and personal identifications or group names can be defined as authorized subjects.

• Use this guard to control interactive mode access of the user ID for which personal identification is active.

Interaction of the operands PERSONAL-LOGON, PASSWORD-CHECK and GUARD-NAME

The values of the operands PERSONAL-LOGON, PASSWORD-CHECK and GUARD-NAME (see the /SET- or /MODIFY-LOGON-PROTECTION commands) can be combined at will. In general, the following applies:

• The operand PASSWORD-CHECK (= *YES/*NO) determines whether or not the password of the logon user ID has to be specified.

• The operand PERSONAL-LOGON (= *YES/*NO) determines whether or not a personal identification is requested on access to this user ID (LOGON).

This results in the following possibilities:

• Default setting
  (PASSWORD-CHECK=*YES,GUARD-NAME=*NONE, PERSONAL-LOGON=*NO):

  Only interactive logon using the password of the logon user ID is permitted. The PASSWORD-CHECK operand determines whether or not the password of the logon user ID has to be specified.

• Interactive mode access control with GUARD and without personal identification(GUARD-NAME = <name>, PERSONAL-LOGON = * NO):

  The guard can be used to set time conditions for access in interactive mode. The subject which has to be specified in the guard must permit access by the logon user ID (name of the user ID, group specification, *OTHERS branch).

• Personal identification is  required
  (PERSONAL-LOGON=*YES):

  The personal identification and corresponding password must be entered (/SET-PERSONAL-ATTRIBUTES command). A guard can be used to restrict the number of user IDs permitted for a personal identification. These user IDs must be specified explicitly in the guard or must be defined as a subject by means of group names. If no guard is specified (GUARD-NAME=*NONE), then all user IDs are permitted.

  The password check is dependent on the PASSWORD-CHECK operand:

  • If PASSWORD-CHECK=*YES applies, both the password of the logon user ID and the password of the personal identification are checked.

  • If PASSWORD-CHECK=*NO applies, the password check consists entirely of the check of the password corresponding to the personal user ID.

    If the logon user ID possesses a password and this is specified on logon, then no additional personal identification is requested. The logon user ID is used implicitly for the personal identification.

    A particular advantage of this procedure is that applications which access the system via $DIALOG (for example, RFA) are able to access user IDs for which a personal identification has been declared without any modifications being necessary.

Attributes which are relevant for system access control

It should be noted that when user IDs are approved for personal identification purposes, the access attributes of these user IDs become effective. The following table indicates which attributes are checked during access control and are thus relevant for access to the logon user ID:

User ID	Logon	Personal
User ID locked	Yes	No
User ID expired	Yes	Yes
Interactive access locked	Yes	No
ACCOUNTNUMBER	Yes	No
Password	Yes	Yes
PASSWORD-CHECK	Yes	No
GUARD	Yes	No
TERMINALS	No	Yes
TERMINAL-SETS	No	Yes

Thus those attributes of the personal user ID which are required for the personal authentication of the person attempting access are used, independently of whether the user ID is locked or not. Moreover, it is assumed that access to the logon ID can only be performed from the terminal corresponding to the personal user ID

Personal identification examples

Example 1

The personal logon is declared for interactive access to the user ID ID USER0001. Every personal user ID should be permitted. It should not be necessary to know the logon password of USER0001.

/modify-logon-protection user-id=user0001, -
/       password=*p(logon-password='userpas1'), -
/       dialog-access=*yes(password-check=*no,personal-logon=*yes)

It is now necessary to distinguish between two cases for the initiation of a job:

1. The user does not specify a password at logon

   /set-logon-parameters user0001,useracc1

   %  SRM3205 PLEASE ENTER '/SET-PERSONAL-ATTRIBUTES' OR '?'

   /set-personal-attributes user0002,'userpas2'
%  JMS0066 JOB '(NONE)' ACCEPTED ON 2018-03-02 AT 14:57, TSN = 8NI9

   In this case, users must identify and authenticate themselves by specifying their own user ID and logon password.

2. The user enters the password of the user ID USER0001 at logon

   /set-logon-parameters user0001,useracc1,'userpas1'

   % JMS0066 JOB '(NONE)' ACCEPTED ON 2018-03-02 AT 14:58, TSN = 8NJ2

   The logon is implicitly evaluated as a personal identification. This means that the user has authenticated himself/herself as USER0001. No further check is performed.

Example 2

A personal identification is declared for interactive access to user ID USER0001. Only user IDs USER0002 and USER0003 should be authorized to perform access. They are defined in the guard GUARD003. It is necessary to know the logon password of USER0001.

To this end, the guard GUARD003 is set up for system-wide access. The authorized user IDs USER0002 and USER0003 are entered as subjects.

/create-guard guard003,scope=*host-system
/add-access-conditions guard003,subjects= -
/   *user((user0002,user0003)),admission=*yes

Next, it is declared that a personal identification will be requested for user ID USER0001 and that access will be controlled by the guard GUARD003.

/modify-logon-protection user-id=user0001, -
/       password=*p(logon-password='userpas1'), -
/       dialog-access=*yes(guard-name=guard003,personal-logon=*yes)

The logon password must be specified at logon. In addition, the user must personally identify and authenticate himself/herself.

/set-logon-parameters user0001,useracc1,'userpas1'
%  SRM3205 PLEASE ENTER '/SET-PERSONAL-ATTRIBUTES' OR '?'

/set-personal-attributes user0002,'userpas2'

%  JMS0066 JOB '(NONE)' ACCEPTED ON 2018-03-02 AT 14:59, TSN = 8NJ4