The first principle is that information in the Directory is not present (from a user's perspective) unless a user has permission to access it. This means that before anyone is able to access anything i.e. perform any Directory operation, they must first be given access rights to the information via the appropriate access control items. This is discussed in more detail in § 8.5.
The second principle is one of precedence. There may be several access control items in a list that apply to a particular user trying to access the Directory. Each access control item is given a precedence when it is first created, and high precedence items overrule low precedence items. Thus if one access control item, having a precedence of 50, states that everyone is denied read access to a particular attribute, and another access control item with a precedence of 75, says that Bill can read this particular attribute, then the second item will take precedence over the first item, and Bill will be granted read access to the attribute. Coupled to this principle, is one that states that a denied access overrules a granted access, if both have the same precedence and specificity.
The next principle is one of specificity, and this states that specific access control items overrule less specific access control items of the same precedence. Thus if one access control item, of precedence 50, says that Bill is denied read access to all attributes, but another item, of precedence 50, says that Bill can read the telephone number attribute, then Bill will have read access to the telephone number attribute.
The precise details of how the access rights of a user are determined from the complete set of access control items that are stored in the Directory, are described in § 8.9.
The Access Control scheme consists of a number of different components. Firstly we have the application of the administrative model of the DIT to the provision of security within the separate administrative areas. This allows an administrator to apply different access controls to different parts of their administrative area. For example, an administration might impose a policy that states that everyone from the external XYZ Corporation is allowed to read the telephone numbers of all the organisational people within the local administrative area. Another part of the policy might be that people from the Pharmaceuticals division can read all the attributes of the organisational people in the Plastics division. Access control policies are stored as access control lists in the subentries of an administrative area. It will be a function of the administrator interface to map these easily understood policies into the actual operational attributes that are stored in the Directory. The administrative model was first introduced in Chapter 2, and its application to access controls will be reviewed again in § 8.2.
An access control list essentially defines the pieces of information that are being protected (the protected items), and whom they are being protected against (the user classes). A list also contains the types of user access, or permissions, that the information is being protected against. So for example, we could have an access control list that states that Bill, Fred and Hanna have Read, Modify and Browse permissions to a particular entry and all of its attributes. Access control items in a list may be given a precedence, and it is also possible to indicate the type of authentication (authentication level) that users must have undergone, in order for an access control list to grant them or not deny them access (§ 8.1.3). A detailed description of access control lists is presented in § 8.4.
Because a user can appear in several different access control lists, and in the same list several different times, an algorithm needs to be defined to say how the different occurrences are combined together. This is the Access Control Decision Function described in § 8.9.
Finally, because each Directory operation potentially involves accessing lots of different data items, the complete set of permissions that a user must have, in order to successfully perform a given Directory operation, needs to be described (§ 8.5). And if the user is missing one or more of these permissions, what result or error diagnostic should be returned to him? This is described in some detail in § 8.5.1 onwards.
In addition, each access control list holds an indication of the type or level of authentication that the user must have undergone if an access control item is to give him or not deny him permission to access some information. If the access control item grants some permission to the user, then the user must have been authenticated to at least the level specified in order to be granted the permission. For example, suppose an access control item grants Fred permission to modify an entry if he has been strongly authenticated. Now if Fred Binds to the Directory and only quotes his password (i.e. simple authentication) he will not have been granted permission to update the entry. If an access control item denies a user some permission, then all users will have to have been authenticated to at least the level specified, if the access control item is not to deny them access. For example, suppose an access control item denies Fred permission to modify an entry, and it requires strong authentication. Now if Mary Binds to the Directory and quotes her password, she will also be denied permission to modify the entry because she did not authenticate herself sufficiently to prove that she was not Fred.
However, what happens when the home DSA authenticating the user is not the DSA evaluating the operation? In this case the evaluating DSA would still like to know what type of authentication was performed by the home DSA. A field in the Chaining Arguments (authentication level - see § 9.13.13) allows the home DSA to inform the evaluating DSA to what level the user was authenticated. Of course, the evaluating DSA will need to trust the home DSA and all intermediate DSAs in the chain, if it is to believe the home DSA (§ 7.4.4). The exact syntax of the 'authentication level' parameter is described in § 8.4.
Fig. 8.1 An Autonomous Administrative Area divided into several Access Control Specific Areas.
Fig. 8.2 An Access Control Specific Area containing several Access Control Inner Areas.
An access control specific administrative area, or ACSA, may have nested areas within it, to which partial security administration is delegated. A nested area is termed an Access Control Inner Administrative Area (ACIA). ACIAs may themselves contain other nested ACIAs. The access controls that apply within an ACIA are a combination of those specified within the inner area itself, and those specified in the enclosing specific area and other enclosing inner areas (if any). Referring back to the conglomerate company, if head office wished to retain overall control of access to the information in the operating divisions, it could make each division an ACIA, as shown in Fig. 8.2, rather than an ACSA. Each operating division would then only partially control access to its information, as delegated by head office. A division could also delegate partial security control to units within itself. For example, in Fig. 8.2, the R&D unit has been delegated this privilege. The degree of security administration delegated to the inner areas would be a local matter, to be resolved between head office and the operating divisions, and between an operating division and its units. Typically, head office might specify default access control policies, whilst the operating divisions might specify further restrictions to some of the attributes and entries. For example, head office might define an access control policy (stored in a subentry below the O=Chemical Conglomerate Inc AAP) which specifies that everyone (i.e. the public) can have read access to common names, telephone numbers, and
Email addresses of all entries in the AAA, and that employees can have read access to all attributes in all entries. The Plastics division might further limit this by its own policy (stored in a subentry below the OU=Plastics IAP) which states that everyone is denied read access to the Email address attribute within its division. Further, the R&D unit might, as a matter of policy, deny everyone read access to all entries in the R&D unit. Joe Public would then only be able to read the Email addresses of people in the Pharmaceuticals and Agri divisions, and would not be able to read anything from the R&D unit. On the other hand (assuming each policy had the same precedence) Mr Employee would still have access to everything, due to the principle of specificity (employees are more specific than everyone - see § 8.9).
However, it is recognised that within any given access control area (ACIA or ACSA), the application of an access control policy will not always want to be uniform, i.e. all the entries in the access control area have the same access control list applied to them. Therefore an access control area can be split up into arbitrary overlapping collections of entries, called Directory Access Control Domains (DACD), to which a uniform application of an access control policy can be applied. For example, an access control domain could be made for each of the following groups of entries : all employees, some middle managers, all OSI applications, network management applications etc., and different access control policies can be applied to each of them.
Directory access control domains are specified using the familiar subtree specification technique (§ 2.12.1). Directory Access Control Domain is therefore just another term for a DIT subtree or subtree refinement! Below a given access control administrative entry (specific or inner), there can be any number of subentries, each describing the same or different collections of entries within the access control area. Each subentry describes just one DACD, since it only contains one subtree specification attribute. The subtree specification is explicit, in that it specifies where the domain starts within the access control area, and where it ends. It also specifies which class of entry within the defined area is to be included in the domain (via the specification filter).
An access control domain can never stray outside the bounds of its enclosing
access control area. For example, in Fig. 8.3 there is one access control
specific area containing one access control inner area, and DACD2 is entirely
within the bounds of its access control inner area, and DACD1 and DACD3
are entirely within the bounds of their access control specific area. An
access control domain can, however, include entries that are within the
boundaries of a subordinate inner area, e.g. in Fig. 8.3, DACD1 includes
entries from the contained (subordinate) inner area.
Note. Whilst it would be syntactically possible to include part of another access control area in an access control domain, for example, where an ACSA has another ACSA below it in the DIT, but the access control domain specification in the higher ACSA omitted to include a chop specification that cut off the lower ACSA; in practice it would have no effect since the retrieval of the access control lists in the lower ACSA would never locate the access control lists held in the DACD of the higher ACSA (§ 8.2.2).
Of course, a given access control domain can often be defined in more than one way, since it may be defined by different administrators. Take for example DACD2 in Fig. 8.3. In the diagram this has been defined in a subentry below an access control inner administrative point, and so may have been defined by the administrator of that organisational unit. DACD2 could also have been defined in a subentry below the access control specific administrative point (as a sister to the DACD1 and DACD3 subentries), and in this case it might have been defined by the administrator of the organisation. In both cases the access control policy would apply to the same set of entries, it would just have been a different administrator who created the policy. Technically the difference between the two definitions would be in the base component of the subtree specification, since the base component always references the start of the DACD in relative terms from its immediately superior administrative point.
Access control policies that govern all the entries in an access control domain, are stored along with the subtree specification in the subentry. They are stored as PrescriptiveACI operational attributes (§ 8.3). In this way it is possible to have blanket access controls that apply to large portions of the DIT, in accordance with the local security policy.
Fig. 8.3 Directory Access Control Domains.
PrescriptiveACI attributes are Directory operational attributes that can only be held in subentries. They control access to the entries (and their attributes) that are within the scope of the subtree specification of the subentry i.e. the access control domain. They thus hold the access control policies that apply to the domain. PrescriptiveACI do not protect the attributes held in the subentry itself. EntryACI or SubentryACI have to be used for this. (Protecting the PrescriptiveACI attributes is described more fully in § 8.8.)
PrescriptiveACI attributes are administered in just the same way that collective attributes are administered (§ 2.11.1). When a subentry is both a collective attribute and an access control subentry, i.e. the subentry contains both collective attributes and PrescriptiveACI, then the PrescriptiveACI attribute can be used to govern read type accesses to the collective attributes throughout the entire area defined by the subtree specification.
SubentryACI attributes are Directory operational attributes that can only be held in administrative entries. They control access to the subentries immediately below the administrative entry in which they reside. (They actually control access to the subentries and to the operational and user attributes held in the subentries.) SubentryACI can thus be used to protect PrescriptiveACI, and this is described more fully in § 8.8. They can also be used to protect collective attributes from being modified, since collective attributes are only actually held in subentries. (Note that they cannot protect collective attributes from being read in the entries that are within the scope of the subtree specification. EntryACI or PrescriptiveACI have to be used for this.)
An ACI item is syntactically quite complex and consists of:
Table 8.1 The Protected Items
|Protected Item||How it is specified in ASN.1|
|Attribute Value||As a list of attribute values|
|Self Value||As a list of attribute types|
|All Attribute Values||As a list of attribute types|
|Attribute Type||As a list of attribute types|
|All User Attribute Types||NULL|
|All User Attribute Types and Values||NULL|
The smallest component of information held in the Directory is an attribute value, and users can be allowed or forbidden to access one or more particular attribute values (attributeValue). Taken to the extreme, each attribute value in the Directory could be protected against different types of access by different users. However, the degree of control will normally want to be much broader than this, and so protected items may be grouped together as described below.
Some multi-valued attributes, such as those which hold mailing lists (i.e. the member attribute type), have values which are distinguished names. In order to let members of the group update their own values in the list, the protected item self value (selfValue) is defined. Self value allows a user to access only that attribute value which matches her (authenticated) distinguished name. In this way, an Add permission for a self value item, would allow users to add their names to a mailing list, and a Remove permission would allow users to remove their names from the mailing list.
Attribute values can be grouped together for protection purposes so that a user can be given permission to access all the values (allAttributeValues) in one or more attributes. With this protected item it is not necessary to enumerate the values. If it was wished to allow a user to read all the values of an attribute except one, then the access controls would need to be set up to grant the user read access to all attribute values, and to deny read access to the one specific attribute value. (One of the guiding principles is that specific grants or denials override generic ones at the same precedence level; see § 8.1.1 and § 8.9.)
Next we have the attribute type (attributeType) protected item. Attribute types, excluding any of their values, are access controllable. If access is not allowed to an attribute type, then the attribute values are usually also not accessible to that user. If access is allowed to an attribute type, then the user may be allowed access to the (enclosed) values. The exception to this is the Remove permission, where remove access to the values is not needed in order to be able to remove the attribute type (and all its values). Conversely, Remove permission to the attribute type is not needed in order to be able to remove a single value.
At the next level of granularity are all the user attributes in an entry (allUserAttributeTypes and allUserAttributeTypesAndValues). User attributes may be collectively grouped together as one item, for protection purposes, because as a general rule it is only user attributes that are visible to users of the Directory. Access may be offered to just the types, or to the types and their values. Operational attributes are not grouped together, or grouped with user attributes, because generally these will only be accessed by special users of the Directory, such as administrators. Operational attributes must all be individually granted access by explicitly naming them, either by type or value or both.
Finally, entries may be protected as a whole (entry). For most operations, a user must have access to the entry before he can gain access to its attributes. Without permission to access the entry, operation evaluation cannot usually proceed. (The only exceptions to this are the List and Search operations, since the entry whose subordinates are to be listed or searched, need not itself be accessed.)
Inclusion of any of the above protected items in an EntryACI attribute, will protect the items in that entry only. They will not affect any other entry in the DIT.
Groups of entries are not protected explicitly as a protected item. In order to protect a collection of entries, an access control domain is created as described in § 8.2.1. If a PrescriptiveACI attribute value is added to the subentry, with a protected item of entry, this will grant or deny permission to access all of the entries in the domain. Another PrescriptiveACI attribute value with a protected item of, say, attribute type will protect all the attributes of that type in all the entries of the domain.
Finally, we need to consider protecting the distinguished names of the entries in the DIT, since users can be forbidden access to these. This latter mechanism protects unauthorised users from seeing the structure of the DIT. Protection of distinguished names is mechanistically dealt with in a different manner from protection of the other information in the Directory, and so is not directly listed as a protected item. See § 8.6 for more details.
Table 8.2 The User Classes
|Name||The distinguished name of a user|
|This Entry||The user whose name matches that of the entry being accessed|
|User Group||The distinguished name of a 'Group of Names' entry|
|Subtree||The distinguished name of a (non-leaf) node in the DIT plus optionally a Chop specification|
|All Users||Public access|
The most obvious use of an access control list is to specify a single user, via his distinguished name (name). In this way individual users of the Directory, be they people or applications, can be given or denied specific access rights to specific protected items. A fine degree of control can then be exercised.
However, in many cases, such fine tuning is not really necessary. A coarser granularity of control can be exercised via the mechanisms defined in the Standard for specifying sets of users. One way is to specify a non-leaf node in the DIT (subtree), and to allow all names that start with this prefix to be controlled by this access control item. This would be particularly useful for say, allowing all the employees of an organisation, or of a department, to have access to some protected item. In this case, the distinguished name of the organisation, or of the organisational unit, respectively, would be quoted as the subtree. The subtree user class is actually more complex than this, in that it allows any subtree of the DIT to be specified, so that only a subset of the names below a non-leaf node are included. This is achieved by having a chop specification (§ 2.12.1) built into the subtree definition, the purpose of which is to chop off (exclude) identifiable subtrees below the one in question. Names residing in the chopped portion of the subtree are then excluded from the set of names. This would be useful for say, including all the employees of an organisation, but excluding the sales and marketing staff. In this case, the distinguished name of the organisation would be given as the subtree, with the sales and marketing organisational unit being included in the chop specification.
An alternative way of specifying a group of users (userGroup), is by quoting the distinguished name of an entry in the DIT, which contains a list of distinguished names e.g. a mailing list entry. The entry has to be an instance of the GroupOfNames (or similar) object class, and the list of distinguished names is held in the member attribute of the entry. An example of this would be a mailing list (but not unfortunately a MHS distribution list, since this does not have a member attribute - see w/w 10.3). The distinguished names contained in the member attribute are usually unrelated to each other with respect to the DIT, and are unrelated to the name of the entry. Thus it is not possible to know if a user's name is present in a GroupOfNames entry, without having full access to the entry. The Standard thus cautions against the use of the userGroup user class if the DSA doesn't have local access to the GroupOfNames entry. Without local access to the entry, a DSA has to assume, when evaluating the access rights of a user, that he is not present in the group, if access is being granted to the group, and that he is present in the group, if access is being denied to the group. Of course, a DSA may always be implemented to either shadow a remote GroupOfNames entry, and thus keep a local copy of it, or to invoke a Compare operation to check on the presence of a user in a remote group. But beware, there are implications in terms of currency of information or of performance with either of these solutions.
The widest group of users that may be given access to the Directory is the set of all users (allUsers). This is used in granting or denying public access to pieces of information. This user class may often be used with such attributes as the telephone number of the organisation.
Finally, we have an access control user class that is used to give the owner of an entry access to some or all of it (thisEntry). The semantics of this user class is that the authenticated name of the user (after any local mapping) must be the same as the distinguished name of the entry that she is trying to access. This user class is particularly useful when specified in a PrescriptiveACI that covers a portion of the DIT. It allows all the users within an access control domain to access their own entry only.
Re-use of Distinguished Names
The user classes above were described in terms of distinguished names. But what happens if an employee leaves an organisation, and sometime later another employee, who has the same name as the previous one, starts to work for the organisation? They could both have been given the same distinguished name, although there would have been an intervening time when the distinguished name was not in use. However, there might be some access control information in the Directory that is still present from the time of the previous employee, that would now be inherited by the new employee. Clearly the new employee was not the intended beneficiary of the old access controls. The work on access controls has recognised that distinguished names might be re-used by Directory administrators, that old ACI items may not be purged immediately, and that this is a potential security loophole. Consequently, in most places where distinguished name can occur in an access control list, this has been supplemented with an optional additional component, UniqueIdentifier. This allows distinguished names to be uniquely tagged, so that if re-used, different tags can be allocated each time. In this way, a re-use of a distinguished name will not inherit access controls left over from a previous use of the name.
The unique identifier is allocated by the home DSA when the user's entry is first created. When the user subsequently Binds to the home DSA, the DSA looks up the unique identifier and attaches it to the distinguished name, so that the user supposedly doesn't need to know about it. It is not known at the time of writing whether implementors or administrators will use this feature or not. If they do the full implications of using unique identifiers will have to be developed, probably by the functional standards groups, by supplementing the information available in the '93 Standard.
Table 8.3 The permissions, and the Items that they can protect
|Permissions for Entry Protected Items only||Permissions for all Protected Items except Entry||Permissions for all Protected Items|
The set of permissions needed to perform each Directory operation is given in Table 8.4. The complete set of permissions are listed in Table 8.3, together with the protected items to which they can be applied e.g. Export permission cannot be granted to an attribute type, only to an entry. A full description of the actual permissions required for each operation will be dealt with operation by operation in § 8.5.
Table 8.4 The permissions that are needed for each Directory operation
|Directory Operation||Permissions Required for 'Entry' Protected Item||Permissions Required for Attribute Type and Attribute Value Protected Items|
|Compare||Read||Compare for attribute type
Compare for each attribute value being compared
ReturnDN (only if an alias name is not available)
|Read for each attribute type returned
Read for each attribute value returned
|List||Browse and ReturnDN for each subordinate||None|
|Search||Browse for each entry in scope of Search
ReturnDN for each entry (only if an alias name is not available)
|FilterMatch for each attribute type and value used to evaluate
Read for each attribute type returned
Read for each attribute value returned
|AddEntry||Add||Add for each attribute type
Add for each attribute value
|ModifyEntry||Modify||Add for all attribute types added
Add for all attribute values added
Remove for all attribute types removed
Remove for all attribute values removed
|ModifyDN||Rename if operation only modifies RDN else
Export at old name and Import at new name
Fig. 8.4 The Guiding Principle for responses
given by the Directory to a user with and without permission to access