The preceding discussion has primarily focused on a rather contrived situation in which there is only one security authority controlling the entire DIB. In this section we consider a more realistic world in which there are many security authorities, each exercising control over a well-defined part of the DIT. The single authority scenario is still entirely valid for parts of the DIT that are autonomously controlled by one authority who chooses not to delegate any part of that authority. In the more complicated world of multiple authorities, there are many autonomous authorities and there are various forms of delegation from autonomous authorities to subordinate authorities. This section describes administrative concepts used to accommodate multiple autonomous security authorities and delegation. Related parts of the standardized access control mechanisms are also discussed. Administration of the Directory is based on the central concept of a DIT Domain. A DIT Domain consists of one or more independent (i.e., non-overlapping) subtrees of the DIT which are under the control of a single organization. Each of the independent subtrees in a domain is referred to as an Autonomous Administrative Area or, more simply, an Autonomous Area (AA). Figure 12.12 illustrates a DIT Domain consisting of three AAs. Each of the triangles in figure 12.12 represents a complete subtree.
Figure 12.12: Example DIT Domain.
Access control decisions regarding the contents of an AA are based solely on ACLs appearing in that AA. An ACL that applies to more than one AA must be repeated in each of those AAs. The organization controlling a particular DIT Domain may choose to have separate security authorities for each AA, or more than one AA could be assigned to a single security authority. It is a matter for security policy to specify the relationship between AAs and security authorities.
Figure 12.13: Example of full delegation of authority.
Each AA can further be divided into sub-areas to accommodate delegation of authority. Two basic forms of delegation are supported: full delegation and partial delegation. Each instance of delegation must be defined in terms of a complete subtree of the AA for which the delegation applies. Figure 12.13 illustrates an AA which has been divided into two non-overlapping sub-areas to accommodate a full delegation of authority from the authority controlling the AA to a subordinate authority. In this case, each sub-area is called a Specific Administrative Area (SAA). Access control decisions regarding the contents of each SAA are based solely on ACLs appearing in that SAA. Even if an ACL was incorrectly given a scope of influence that exceeds the boundary of the SAA in which it is defined, the access control mechanisms would automatically ignore the invalid part of the ACL scope. When making an access decision, the automated guard first identifies which SAA the requested item is in and then only considers ACLs defined within that SAA, so any ACL from another SAA (regardless of its scope of influence) will be ignored.
Figure 12.13 also uses some basic terminology for the root entry of an administrative area. The root entry for an AA is called an Autonomous Administrative Point (AAP) while the root of an SAA is called a Specific Administrative Point (SAP).
Figure 12.14 illustrates an instance of partial delegation of authority. The partially delegated area is called an Inner Administrative Area (IAA), its root entry is called an Inner Administrative Point (IAP). Figure 12.14 shows the two administrative areas overlapping to indicate that the authority for the SAA may define ACLs that affect decisions about the contents of the IAA. IAAs are the only type of administrative area allowed to overlap another administrative area. Additional nested IAAs could be defined inside the IAA in figure 12.14 to reflect lower levels of partial delegation. Security policy should address the need for IAAs and nested IAAs. Security policy should also specify that the authority controlling an IAA shall not create an SAP within the IAA - this precludes the possibility of the delegated authority being able to contravene policy set by the superior authority. The superior authority may wish to enforce this policy fragment by specifying an ACL in the SAA such that the ACL's scope of influence includes the entire IAA and it denies ADD of a particular attribute value needed to build a new SAP.
Figure 12.14: Example of partial delegation of authority.
When a superior authority partially delegates to a subordinate authority, the superior is able to retain control over any aspect of ACL policy because:
Security policy defines the maximum precedence that may be used by each delegated authority. The authority for the SAA may then override any ACL defined by a subordinate authority by simply using a precedence that is higher than the maximum assigned to that subordinate. The assigning and enforcement of maximum precedence is outside the scope of the Directory standard; it is anticipated, however, that implementors will provide a way for the superior authority to specify and enforce the maximum precedence assigned to each subordinate authority.
A superior authority may also define ACLs with a precedence that is much lower than the maximum assigned to a subordinate. In this case, the superior is defining, in effect, default controls which may be overridden by the subordinate by using a higher precedence value.
Having discussed what full and partial delegation are, in the context of the standardized access control mechanisms, we can now emphasize the basic difference between the two mechanisms. One of the mechanisms, known as Basic Access Control (BAC), supports the full range of delegation relationships discussed above. The other mechanism, known as Simplified Access Control (SAC), supports full delegation only.