Security System Overview › Security Implementation › Entity Type Monitoring › Preauthorization

Preauthorization

The next five areas of concern are all addressed by the use of preauthorizations. They are:

• Dangerous Users - These dictionary users are to be restricted to only updating certain entities in the dictionary. For example, trainees would fit into this category. The restriction is specified through the use of the NO-AUTH, LIM-AUTH, and A-OPT flags in the appropriate SECURITY CLASS records. Set the flags in the SECURITY-CLASS record named in the USER descriptor for each "dangerous user" to:

  LIM-AUTH = N

  NO-AUTH = N

  Set the A-OPT flags in the same SECURITY-CLASS record to N for all entity types that are to be protected. Then establish a PREAUTHORIZATION junction between each "dangerous user" and all of the entities that the user is to be allowed to change.

• Sensitive Entities - These entities are to be updated by only certain users. For example, a disbursement dialog would fit into this category. This restriction is also specified through the use of the NO-AUTH, LIM-AUTH, and A-OPT flags in the SECURITY-CLASS records. Set the flags in every SECURITY-CLASS record to:

  LIM-AUTH = Y

  NO-AUTH = N

  Set the A-OPT flags in every SECURITY-CLASS record to N for those entity types that are to be protected. Then establish a PREAUTHORIZATION junction between each sensitive entity and each user that is to be allowed to modify that entity.

  Note: The protection requires at least one PREAUTHORIZATION junction for each sensitive entity. If an entity participates in NO PREAUTHORIZATION junctions, it is assumed by the system not to be sensitive.

• Derived CCID - In some shops, it may be infeasible to require that all users sign on to CA Endevor/DB each time they switch from one CCID to another. For example, if a unique CCID is established for every change for every DIALOG, programmers would be issuing CA Endevor/DB signons on a frequent basis. To circumvent this problem, the administrator can predefine the relationships between CCIDs and dictionary entities, and the programmers can run in "DERIVED CCID" mode. When doing so, they only signon to CA Endevor/DB to specify their userid. The CCID to which a given change is attributed will be determined by the presence of a PREAUTHORIZATION junction. This processing mode is also specified through the SECURITY-CLASS record. In the SECURITY-CLASS records named in each DERIVED CCID user descriptor record, set the DE-CCID flag to Y. Then establish a PREAUTHORIZATION junction between each entity to be changed and the CCID to which changes are to be attributed. In each of those PREAUTHORIZATION junctions, set the DE-CCID flag to Y.
• Private CCID - You may need to make CCIDs private for several reasons. Perhaps you have established security by CCID or you manage "Sensitive Entities" by CCID. In these (and other) cases, you will need to control which users are allowed to signon or make changes under a CCID. The restriction is specified by setting the TYPE of each restricted CCID to PRIVATE. Then establish a PREAUTHORIZATION junction between each USER that is to have access to a given CCID and the following entity:

  ENTITY NAME = ccid-name

  TYPE = CCID

  VERSION = 1

• Private Status - In promotion processing, the NDVRDSEL program EXCLUDE command will exclude any entity associated with a given STATUS. The ability to associate entities with the STATUSes used in your shop's promotion processing is therefore important. To control that ability, set the TYPE of each STATUS used in promotion processing to PRIVATE. Then establish a PREAUTHORIZATION junction between each USER that is to have the ability and the following entity:

  ENTITY NAME = status-name

  TYPE = STATUS

  VERSION = 1