Each fragment of security policy that is to be enforced by the standardized access control mechanisms must
be expressed in terms of an ACL. A basic ACL has three components: one identifies which user the policy
fragment applies to; another component identifies a particular access permission and whether that
permission is granted or denied; the last component identifies what part of the Directory the ACL protects.
A typical basic ACL, shown in figure 12.4,
specifies the following confidentiality policy fragment: The user
with surname ``Ransom'' is allowed to read (e.g., via the READ operation) all values of attribute type 
that are held in the entry with Distinguished Name 
.
In many cases it would be inconvenient, however, if security policy had to address each potential user and each protected item individually. To avoid these inconveniences, several types of collective controls are supported by the standardized access control mechanisms. More specifically, four levels of ``collective controls'' can be used to specify that a basic ACL applies to more than one user, more than one permission, and more than one protected item. The four levels of flexibility are:
The scope of influence of a particular ACL may be: a single entry; many entries that are related by virtue of their relative positions in the DIT and/or their object classes; or a dynamic ``area'' of the DIT that holds a subtree of existing entries and is allowed to grow via ADD-ENTRY and/or MODIFY-DISTINGUISHED-NAME.
The four levels of flexibility in defining collective controls may be used individually or may be arbitrarily
combined to conveniently state a particular access control policy fragment. Figure 12.5 is an
example of a more
flexible ACL that conveniently specifies the following confidentiality policy fragment: All users are
allowed to read (e.g., via the READ operation) attribute in any entry with object class within the DIT
subtree that begins at the entry with Distinguished Name 
.
Figure 12.5: ACL using collective controls.
The example ACLs shown in figures 12.4 and 12.5 are not actually sufficient to enforce
their respective
confidentiality policy fragments using the standardized access control mechanisms. They are insufficient
because for each query operation the standardized mechanisms first check to see if the requestor is allowed to
apply the operation to any part of an entry that must be accessed to fulfill the operation. If so, the
mechanisms then check to see if the requestor can access each specific attribute type needed to complete the
operation. The mechanisms also perform a separate check to see if the requestor can access each value
needed to complete the operation. The ACLs in figures 12.4 and 12.5 only specify
permissions for a specific
attribute type. They do not specify controls on the values of Attribute , and they do not specify controls
needed to allow the requestor to perform a query operation on any entry (regardless of what part of the entry
is being read).
Now consider figure 12.6. Each row in the figure is considered to be a separate ACL. The first row provides the permission needed to allow all users to perform a READ operation (independent of what attributes are accessed by any particular instance of a READ). Without this permission, users would not be allowed to perform a READ operation on any entry (regardless of what attributes they are trying to read or how attribute types and values are controlled). The reason for these ``entry-level'' permissions will become apparent in the next figure.
The second row in figure 12.6 allows the query operation result to disclose a particular attribute type (i.e., type
). This row does not control any of the values associated with an instance of an attribute of type ; it
only controls disclosure of the type information associated with the attribute.
The third row in figure 12.6 allows the query operation result to disclose any or all of the values contained in an
attribute of type . The standardized mechanisms also allow each individual value to be independently
controlled.
It should be noted that the ACL representation used in the standardized access control mechanisms allows all three rows of figure 12.6 to be collapsed into a single row in which the third column specifies all three protected items. Collapsing the rows is possible because they all have the same information in the first, second, and fourth columns.
Figure 12.6: A more realistic set of ACLs.
The first row of figure 12.6 is referred to as an ``entry-level'' control because the
Protected Item is the entry as a
whole. To illustrate the usefulness of entry-level controls, consider the following confidentiality policy
fragment: All users are allowed to read (via the READ or SEARCH operations) attribute in any entry
with object class within the DIT subtree that begins at the entry with Distinguished Name . Suppose
the policy fragment also states that attribute may not be used in SEARCH filter criteria. The ACLs
needed to enforce the policy fragment are shown in figure 12.7.
The only difference between figures 12.6 and 12.7 is the second row in figure 12.7 which grants an entry-level permission called ``Browse.'' This permission must be granted before any user is allowed to apply the SEARCH operation to any entry (regardless of controls on the attribute types and values for entries in the scope of a SEARCH). Note that the attribute type and value controls are the same for both READ and SEARCH; only the entry-level permissions are different.
Its interesting to analyze the policy differences between figures 12.6 and 12.7.
The policy for figure 12.6 allows
disclosure (to any user), via a READ operation result, of all the information associated with a particular
attribute when that attribute is present in an entry of a particular object class within a particular subtree of
the DIT. Since only the READ operation may be used, a user can only read attribute if he already knows
the name of an entry that contains attribute (and which satisfies the object class and subtree location
requirements). When requesting a READ operation, the user must specify a valid name for the entry to be
read.
Using a SEARCH operation, however, a user may read the contents of an entry for which that user does not
a priori know a valid name. In other words, the user may read entries that are not explicitly named in the
operation request. If attribute contains phone numbers, then the
policy in figure 12.7 would allow users to
read phone numbers without first knowing a valid Directory Name for the object associated with the phone
numbers (the object might be a person). Under the policy of
figure 12.6, the user would have to know such a
name before the phone numbers for that name could be read.
Figure 12.7: Allowing both READ and SEARCH.
Another interesting facet of the policy expressed in figure 12.7 is that users may obtain
attribute values in a
SEARCH result, but they are not allowed to use attribute in a filter criterion of the SEARCH request.
Use of attribute as a filter criterion is disallowed because there is no ACL that grants its use as a filter
item.
Disallowing the use of attribute in a filter criterion precludes a user from searching a range of entries in
an attempt to find the entry containing a specific value of attribute . If, for example, attribute contains
phone numbers then a user would not be allowed to search the Directory to find out what name is associated
with a given number. As mentioned above, there are independent confidentiality controls on what may be
used in a SEARCH filter criteria and what may be disclosed in a SEARCH operation result.
Figure 12.8 shows ACLs that enforce a policy that does allow inversion of telephone number information
(assume attribute is telephone number).
In figure 12.8, two additional rows have been added to allow attribute type and the values of an
instance of that
attribute to be used in filter criteria within a SEARCH operation request. ``FilterMatch'' is the name of the
permission category used by the standardized mechanisms to control what can be used in a SEARCH filter.
The differences between figures 12.7 and 12.8 also highlight an important principle that is always observed by the standardized access control mechanisms: the access control guard only grants access when there is an ACL that explicitly grants the required permission. Access is always denied when there is no ACL that explicitly grants the required permission; access is, of course, also denied when there is an ACL that explicitly denies the required permission.
The examples shown in figures 12.4 - 12.8 can be generalized into a taxonomy of access controls supported by the new Directory standardized access control mechanisms. The remainder of this section presents one such taxonomy. Each category in the taxonomy is shown in a box immediately preceding a description of the category. The statement of a particular policy fragment may freely utilize any useful combination of the categories.
Figure 12.8: Control of SEARCH filter.
As previously mentioned, each ACL is assigned a scope of influence that identifies the part of the DIT to which it applies. The smallest scope of influence is a single entry; it is used when an ACL expresses policy that is applicable to a single entry in the DIT. When a policy applies to every entry in a subtree, it is not necessary to repeat the ACL for each of the entries. For convenience, it is possible to specify an entire subtree as the scope of influence for an ACL. A policy fragment with a subtree scope applies equally to each entry in the subtree and may be referred to as a Subtree-dependent control. Figure 12.6 is an example of Subtree-dependent controls.
If an organization chooses to build its part of the DIT such that there is a subtree for each organizational unit, then policy that applies to an entire unit could be easily expressed using ACLs whose scope of influence is defined to be a subtree.
Another important use of Subtree-dependent controls is to enforce policy regarding how the DIT is allowed to grow and change in shape. The ADD operation allows it to grow; the MODIFY-DISTINGUISHED-NAME operation allows entire subtrees to, in effect, be moved from one parent entry to another. Both of these operations may be controlled using Subtree-dependent access controls. When an attempt is made to add a new entry, the Directory first checks to see if there is a subtree ACL whose scope of influence includes the proposed entry's name. If there is such an ACL and it grants entry-level permission for the ADD operation, the Directory continues with the operation by checking modification policy to see if each proposed attribute type and value are allowed to be placed in the new entry. The controls on adding each type and value are also specified in ACLs whose scope of influence include the name of the proposed entry. If any one of the modification checks fails, the ADD operation fails (completely).
Similarly, when a MODIFY-DISTINGUISHED-NAME operation has the effect of moving an entry to a new parent, the Directory first checks to see if there is a subtree ACL whose scope of influence contains the proposed new name of the entry to be moved. If there is such an ACL and it grants the appropriate entry-level permission to allow the operation to be applied, then the operation is allowed to succeed (subject to some additional checks described in the previous discussion of the MODIFY-DISTINGUISHED-NAME operation).
Finally, it should be noted that it is possible to define a scope of influence that excludes a specific branch of a subtree. For example, in figure 12.9, subtree 1 and subtree 2 are complete subtrees; the root of subtree 1 is entry a1 while the root of subtree 2 is entry b1. Entry a1 is also the root of the area labeled subtree with exclusion which is not a complete subtree because one of the branches (subtree 2) has been excluded. The ability to exclude specific branches from a subtree specification is an added dimension of flexibility in specifying ACL scope of influence.
Figure 12.9: Subtree specifications.
For convenience, the standardized mechanisms also facilitate specification of a policy that applies to entries (in a subtree) that have a particular object class. Each entry in the Directory contains an attribute that specifies what object class it represents; some examples of object class are: organization; organizational unit; person; and device. A single ACL could express a policy that applies to a particular subtree but only affects entries of object class person. More generally, a single ACL could express a policy that applies to a boolean combination of object classes - for example, suppose a particular policy applied equally to entries of object class organization and to entries of object class organizational unit. A single ACL could be used to express the policy by assigning a scope of influence that includes organization or organizational unit. Combinations of object classes may be specified using the boolean operators ( or, and, not) to build elaborate scopes of influence.
An ACL that has a scope of influence defined in terms of object classes may be referred to as Class-dependent controls.
Class-dependent controls which target object classes that are associated with resources other than information can also be regarded as being resource dependent. Examples of object classes that represent such resources include:
Any object class that is derived from such object classes could also be regarded as representing a xxx information resource. For example, a subclass of application entity could be defined to represent Message Transfer Agents for electronic mail services. Since these object classes might contain network addressing information, it is possible that the Directory could be made partly responsible for controlling the use of resources by controlling access to network addresses. Security policy applying to the use of such resources and control of related network addresses could be regarded as either confidentiality policy or as resource control policy; when it is the latter, the associated ACL(s) may be referred to as Resource-dependent controls.
The scope of influence for an ACL can also be defined to include only a subrange of the levels in a particular subtree of the DIT. Such controls may be referred to as Level-dependent controls. Subtree levels are illustrated in figure 12.10 where, for example, the entries labeled b1 and e5 occupy subtree level 1 while e3 and d5 occupy level 3. Policy which applies equally to each and every entry in a particular level or subrange of levels can be expressed easily using features of the standardized mechanisms that are used to define ACL scope of influence. All the levels in a valid subrange are contiguous (e.g., levels 1 and 3 do not form a subrange because level 2 is left out).
In the discussion of figures 12.6 and 12.7 it was pointed out that each type of operation (e.g., ADD-ENTRY, READ) is at least partially controlled by an ``entry-level'' permission (i.e., an ACL in which the protected item is ``entry''). The entry-level permissions facilitate policy expression in terms of specific Directory operations. These permissions are primarily designed to facilitate denials since denial of an entry-level permission causes the operation to fail regardless of permissions associated with attributes or Distinguished Names. Granting an operation, however, generally requires granting of both entry-level and attribute permissions (the only exception is REMOVE-ENTRY).
For the modify operations, except MODIFY-DISTINGUISHED-NAME, there is a separate entry-level permission for each operation so that denying the use of a particular modify operation is as simple as denying the entry-level permission associated with that operation. To discuss MODIFY-DISTINGUISHED-NAME, it is necessary, temporarily, to consider more than one authority. There are two cases to consider:
In the first case, the authority for the entry under its old name has complete denial control and may prevent the operation by denying one entry-level permission. In the second case, both cognizant authorities would have to grant independent permissions before the operation could succeed. Either authority can deny the operation by denying one entry-level permission.
For the query operations, entry-level permissions are grouped such that READ and COMPARE have the same entry-level permission (however, they do have independent attribute permissions). Denying that permission causes both the READ and COMPARE operations to fail for all entries in the scope of the ACL with the denial.
Similarly, LIST and SEARCH have the same entry-level permission so they can only be denied as a pair.
Entry-level controls may be referred to as Operation-dependent controls.
The ACLs in figures 12.4 - 12.8 illustrate controls applying to a specific attribute type (e.g., type = phone number). For convenience, the standardized access control mechanisms also facilitate the expression of policy that applies to all ``user attributes'' present in an entry. ``User attributes'' include all attributes that are intended to serve the needs of the Directory user community; they do not include attributes that exist for administrative purposes (e.g., ACLs).
A feature has been provided in the access control mechanisms to allow a single ACL to apply to all user attributes in any entry that falls in the scope of the ACL. The feature allows collective control over access to the type for each user attribute in an entry or over both type and value information for all user attributes in an entry. Such controls may be referred to as Type-dependent controls.
Figures 12.4 - 12.8 also illustrate controls applying to all values present in an attribute of a particular type. This is another convenience feature of the standardized access control mechanisms; it allows easy expression of a policy that equally applies to all the values present in an attribute of a specified type. It is also possible to specify an ACL that applies to one specified value of an attribute of a specified type.
Controls expressed in terms of all the values of a particular type or in terms of a specific value of a particular type may be referred to as Value-dependent controls.
Another convenience feature of the mechanisms is designed to cater to a special case of Value-dependent control. The standardized object classes for the Directory include one that is used to specify an entry that contains a group of Directory names. Such an entry could be used to hold a mailing list, an administrative grouping (see User-dependent controls), or any other useful list of Directory names.
Each entry representing a list of names has an attribute whose values are the names in the list. Controlling access to a name in a list can be achieved in the same ways used for any other attribute value. In addition, there is a feature applicable only to entries that contain lists of names. This feature facilitates the expression of policy that allows a person, whose name appears in a list, to self-administer his name with respect to that list. Self-administration might allow the person to change his name but not remove it or it might allow him to do both. It might instead allow him to remove it but not otherwise modify it. These kinds of policies are easy to express using the standardized access control mechanism.
Figures 12.4 - 12.8 illustrate ACLs associated with policy that is applicable to all users. It is also easy to express policy that is applicable to:
It is also easy to express policy that applies to any combination of particular users, lists of users, and users in the same subtree.
A list of users is a very flexible way of identifying a group of users for special consideration with regard to access control policy. The list can be built to include as many users as necessary; however,: it cannot contain the names of entries that represent additional lists of names. Users whose entries appear in the same subtree might all be members of the same organization or organizational unit. Policy that equally applies to an entire organization could be easily expressed using the definition of the DIT subtree representing that organization. Policy that distinguishes between organizational ``insiders'' (i.e., members of the organization) and ``outsiders'' could be easily expressed using organizational subtrees to distinguish between insiders and outsiders.
The standardized mechanisms are designed to provide an easy way to express policy that allows a Directory user to self-administer the entry in the DIT which represents that user. Self-administration could be used, for example, to allow a user to modify any of the attributes in her entry, including any ACL information. Self-administration could also be restricted to allow her to to administer only a subset of the attributes in her entry.
When a user is allowed to self-administer the ACL information controlling that user's entry, there is a minor difference between the standardized access control mechanisms. Recall that there are two mechanisms being standardized in the new edition of the Directory standard. The names for the two mechanisms are Basic Access Control (BAC) and Simplified Access Control (SAC). Self-administration of ACLs is possible under both mechanisms but it may be more convenient under BAC because it allows an ACL to be placed directly in an entry to which it applies. SAC requires each ACL to be placed outside of an entry it controls and therefore self-administration under SAC can be more complicated because the self-administered information is not collected in a single entry.
It is often convenient to express access control policy in terms of a general rule that applies to a wide range of users or protected items. Usually, however, there are exceptions to the rule that must be enforced. When policy is expressed in terms of a general rule with exceptions, the general rule can be thought of as a ``default'' control that applies unless one of the exceptions occurs.
The standardized access control mechanisms facilitate three kinds of default policies. The first is an application of Value-dependent controls, the second is an application of User-dependent controls, and the last is a very general feature whereby a precedence level is associated with each ACL. The precedence level is used to specify which ACLs prevail within a given scope of influence.
Value-dependent controls can be used to express default policy with exceptions because the access control
mechanisms are designed such that an ACL that applies to a particular attribute value is considered to be
``more specific'' than an ACL that applies to all values of that attribute. The automated guard that makes
access control decisions always favors more specific ACLs when all other decision criteria (such as
precedence) are equal. Hence default policy could be expressed as an ACL with Protected Item set to ``all
values of attribute type '' while an exception could be expressed as an ACL with Protected Item set to
``value of attribute type .''
Similarly, User-dependent controls can be utilized to express default policy because there is also an ordering of specificity with respect to the User Class in an ACL. The ordering, from most specific to least specific, is as follows:
Using this hierarchy of specificity, there are many strategies for expressing default ACLs and exception ACLs. An obvious strategy is to set User Class to ``all users'' for default controls and set it to a particular name for an exception. If the exception applies to more than one user, then the exception ACL could have User Class set to a list of users where the list contains the names to which the exception applies.
For an organization or organizational unit represented by a subtree in the DIT, the default policy for insiders could be expressed in an ACL where the User Class specifies all members of the organization's subtree; insider exceptions could be expressed in an ACL with User Class set to a list of names; outsider default policy could be expressed in an ACL where the User Class is ``all users.'' Insider exceptions, for example, could be specified for a group of systems administrators responsible for maintaining the information in the organization's subtree. The administrators would be able to perform modify operations and read administrative attributes that are not generally available to other insiders.
In addition to specificity of User Class and Protected Item, an ACL can be assigned a precedence level that defines its relationship to other ACLs with the same scope of influence. Precedence can also be useful when ACLs have different, but overlapping, scopes of influence (ACLs defined by a single authority are allowed to freely overlap in scope of influence). When scopes overlap, access control decisions for any entry in the intersection are influenced by the precedence level of each of the ACLs involved.
The precedence level is an integer in the range from 0 to 256. A higher level takes precedence over a lower one. Precedence can be used to determine which ACL prevails when two have the same level of specificity. An important design feature of the access control mechanisms is that denials always prevail when conflicting ACLs have the same scope of influence, same specificity, and same precedence.
In making access control decisions involving specificity and precedence, the access control mechanisms consider precedence first. The mechanisms, in effect, gather all the ACLs whose:
Having gathered all such ACLs into a set, the mechanisms examine each ACL to determine what the set's highest precedence level is; all ACLs below that level are discarded from the set. Next, the remaining ACLs are examined to determine what the set's most specific User Class is; all ACLs with a less specific User Class are discarded from the set.
If access is being requested to an attribute value, then the set is again examined to determine what the most specific Protected Item is; all ACLs with a less specific Protected Item are discarded. The access decision is based on the ACLs remaining in the set. If there are conflicting ACLs, then denials prevail. If there are no ACLs left in the set, then the access control mechanisms automatically deny access. The set could be empty because: there is no ACL whose scope of influence contained the requested item; or because there is no ACL whose User Class contains the requestor; or because there is no ACL for the particular Protected Item being requested.
