Security System Overview › Change Monitor Processing

Change Monitor Processing

Every change made by every user in either the dictionary or CCDB is seen by the CA Endevor/DB change monitor. For every change, the processing takes place in two phases:

1. Before the change is applied to the dictionary/CCDB, it is checked by the security system.
2. After the change occurs, it is logged in the CCDB.

The security checking is as follows:

• If the CCDB is offline, the update request is disallowed.
• If security or monitoring is turned off, no other security validations are performed, and the update request is allowed.
• If the dictionary descriptor for the dictionary indicates that the dictionary is locked, the update request is disallowed.
• If the dictionary descriptor for the dictionary indicates that monitoring is not required for this record type, no other security validations are performed, and the update request is allowed.
• If the change is being made in DERIVED CCID mode, the CCID validations which would be performed at signon time must be performed for each CCID which had been preauthorized to the entity with the DERIVE CCID option. As the associated CCIDs (the ones related to the entity through DE-CCID = Y preauthorization junctions) are scanned, locked CCIDs are skipped, as are PRIVATE CCIDs to which the user is not preauthorized. If the security permission flags indicate that the user is not allowed to process without a CCID, and there are no associated CCIDs, the update request is disallowed. The authorization flags for each derived CCID's security class are merged into a net set of permission flags. If the change is being made in the "normal" mode (not DERIVED CCID mode), the net set of permission flags were built in phase 2 of signon processing and this step is skipped.
• The security permission flags must indicate that the user is allowed to update this record type. If not, the update request is disallowed.
• If the entity is signed out to another user or a CCID, the update request is disallowed.
• If the A-OPT flag for this record type is set to Y, the update is allowed and the next two checks for FULL AUTH and LIM AUTH classifications are skipped.
• If the security permission flags indicate that the user is "FULL AUTH" classification and a preauthorization for either the user or associated CCIDs does not exist, the update request is disallowed. This rule implements the "Dangerous User" function described earlier in the Preauthorization section of this chapter.
• If the security permission flags indicate a user is "LIM AUTH" classification, and the entity is preauthorized to another user or CCID, but not this user or CCID, the update request is disallowed. This rule implements the "Sensitive Entity" function described earlier in the Preauthorization section of this chapter.

At this point, if all validations have been successfully completed by the security system, the update takes place. After the change has taken place, it is logged in the CCDB. The log processing is as follows:

No logging of the update will be done if any of the following conditions are true:

• The CCDB is not in update mode.
• Logging is turned off.
• If the dictionary descriptor for the dictionary indicates that monitoring for this record type is not required.

If the request is to be logged, CA Endevor/DB performs the following processing:

• If the entity does not already exist, it will be added to the CCDB.
• A Change Log Entry (CLE) will be created, which is linked to all associated CCIDs (either the user's signon or the derived CCIDs for the entity).