Relationship Between Security Authority and Schema Authority

This chapter has so far taken a narrow view of Directory management and policy by focusing on security policy aspects of Directory management. Another important part of Directory management is concerned with controlling aspects of DIT structure and content such as:

• rules defining the allowable DIT parent - child relationships in terms of object classes (e.g., a policy might specify that a parent entry of object class organization may only have children entries of object class person); and
• rules defining the mandatory and optional attributes for each object class.

Definition and enforcement of such rules is known as Schema Management. The general administrative model for the Directory defines schema authority and allows that authority to be separate from the security authority for a given autonomous area.

Security management using BAC or SAC is sometimes confused with schema management since the standardized access control mechanisms could, conceivably, be used to enforce certain simple DIT structure rules. For example, a hybrid of Class-dependent and Level-dependent controls could be used to enforce, in a limited way, the allowable parent - child object class relationships in the DIT.

There is no way, however, for an ACL to fully express a schema policy like: ``Entries of object class shall contain attributes , , and ; further, entries of object class may optionally contain attributes E and F (attributes other than , , , , and are not allowed in an entry of object class ).''

ACLs could prevent an ADD or MODIFY-ENTRY from placing an attribute other than , , , , or in an entry of object class ; but ACLs cannot enforce policy on mandatory attributes for a given object class. Mandatory attributes are attributes that must appear in each instance of the specified object class. ACLs can only keep attributes out of an entry, they cannot force certain attributes to be in an entry.

Because the schema authority may be different from the security authority, and because many schema policies cannot be expressed in ACLs, the mechanism that enforces schema policy is assumed to be completely independent of the mechanism used to enforce automated access control policy. Note that conflicts can arise between access control policy and schema management policy. For example, schema policy may specify that an entry of object class X shall contain attribute type A while access control policy denies the ability to add attribute type to an entry of object class . There is a need, therefore, for coordination between access control authorities and schema authorities.

A final point concerning schema rules is that they can be used to support management auditing procedures that may be part of monitoring the activity of security authorities. Specifically, schema rules can be expressed which require each entry to contain the following attribute types:

• createTimestamp: indicates the time of creation of an entry;
• modifyTimestamp: indicates when an entry was last modified;
• creatorsName: indicates the name of the user performing the ADD-ENTRY operation;
• modifiersName: indicates the name of the user performing the MODIFY-ENTRY operation.

These attributes are standardized in the new edition of the Directory standard. They are defined such that each is completely under the control of the DSA; no user modification is allowed. Theoretically, this means security authorities could not change their values. Also, note that the modifyTimestamp and modifiersName attributes do not really provide an audit trail since each modify operation causes the previous values of these attributes to be overwritten. They can only be used to monitor when the most recent modify was applied and who did it.