8.6 VISIBILITY OF THE DIT STRUCTURE

In a distributed environment, as name resolution progresses, it is not possible to check the access rights of users to each entry in the DIT, from the root of the tree to the base object of the operation. This is because in many cases, the DSAs holding the higher parts of the tree are never accessed, and the lower DSAs do not always know what access controls prevail in the higher DSAs. The decision was therefore made that access rights would not be checked until either the base object was reached, or an error had occurred, or an alias was encountered. Even if a user has permission to access the base object or one of its aliases, it is still not assumed that they have rights to know about the DIT structure. Therefore when a result is returned, the access control framework ensures that users are not returned the distinguished names of entries in the DIT, and hence are unable to see the structure of parts of the DIT, unless they have specifically been granted the appropriate permission (ReturnDN) to the entries.

Furthermore, the framework also ensures that users may not uncover the DIT structure, by trial and error, through trying out various names, in the hope that an error diagnostic will imply the existence of certain entries. Consequently, the interactions of the various permissions, and the actual results and errors returned to the user, need some explanation.

The number of errors that may be returned to a user who has no permissions are limited. Attribute Error cannot be used, since this returns the name of the entry. Most of the problem codes of Update Error return some implicit information about the DIT structure, as do some of those of Service Error. Even Security Error with problem Insufficient Access Rights tells the user implicitly that the entry exists, but that they do not have access to it. The most obvious error to return to the user with no permissions at all, is Name Error with problem No Such Object, which tells the user that the entry does not exist in the DIT (even if in reality it does). However, this error has an accompanying parameter matched, which gives the name of the next highest entry in the DIT that does exist (§ 5.18.2). If this was always returned truthfully, then users would be able, via trial and error, to discover much of the DIT structure without having access rights to anything. In order to close this security loophole, the matched component can always be set to 'null' i.e. to the name of the root of the DIT. As everyone knows that this exists, the user with no permissions is thus told nothing about the DIT structure.

For users who do have some legitimate reason for accessing a portion of the DIT, but for whom one particular entry is completely out of bounds, the matched name can be set to the name of the next superior in the tree to which the user has DiscloseOnError permission granted to the entry item. If DiscloseOnError is granted to the actual entry, then a Security Error is returned instead of a Name Error.

A further consideration has been made for the situation where it may be acceptable for a user to read some of an entry's attributes, and to access the entry via an alias name, but not to know the distinguished name of the entry, or the structure of this part of the DIT. This might be because it is not desirable for external people to know about the internal structure of an organisation, which might be reflected in the DIT structure. The ReturnDN permission is for just such a case, and this permission needs to be granted before the distinguished name will be returned to anyone in an interrogation response.

If ReturnDN permission to the target entry has not been granted to the user, then the following actions take place. In the case of a Compare or List operation, a DSA may return the name of a known alias, or it may return no name at all, since the parameter is optional in the response. A similar consideration applies to the name of the base entry of the Search operation. Either an alias name or no name at all may be returned. The Read operation is somewhat different, in that a name must be returned in the response. If no valid alias name is available, then the user will receive a Name Error (no such object).

For all the entries within the scope of the Search operation, the Directory normally returns the distinguished names of all of those subordinates that pass the filter. If the ReturnDN permission has not been granted to any of these entries, then either the name of an alias of the entry will be returned (if the DSA knows of one), or the entry will be omitted from the Search result. Thus by not giving anyone ReturnDN permission to an entry, may be an effective way of stopping people searching for it.

Children of the target object of the List operation will only have their relative distinguished names returned if the user has ReturnDN permission for them. Otherwise they will be omitted from the set of results.
 

8.7 EXAMPLES OF ACI ITEMS

Perhaps a common use of access controls will be to make a portion of the DIT accessible to everyone. As an example, suppose an administrator wishes to give everyone read and search access to the telephone number, fax number, common name and object class attributes of an entry. Suppose he also allows the distinguished name of the entry to be returned to the inquisitor (grant ReturnDN), and is prepared to notify the enquirer that information is present if an error occurs (grant DiscloseOnError). A good user interface should guide the administrator through this allocation of permissions, and should map these into the ACIItem (or its equivalent) shown in Fig. 8.10. The administrator should not be expected to configure up individual ACI items.

PURPOSE: To allow everyone Read and Search access to the telephone number, fax number, common name, distinguished name and object class of one or more entries, and to return useful error diagnostics if the users have errors in their requests.

Tag: "Public access control"
Precedence: 10
Authentication Level: none
User Class: all users
Protected Items: Attribute Type {common name,
                                                    telephone number,
                                                    facsimile telephone number,
                                                    object class},
                             All Attribute Values {common name,
                                                             telephone number,
                                                             facsimile telephone number,
                                                             object class}
Permissions: grant read,
                      grant filterMatch,
                      grant discloseOnError

Protected Items: Entry
Permissions: grant browse,
                      grant read,
                      grant returnDN,
                      grant discloseOnError


Fig. 8.10 Granting public access to a selected set of attributes (user first syntax) in an entry.

If the administrator wanted to control access to a single entry, then the ACIItem in Fig. 8.10 would be stored in an EntryACI attribute in the entry. If the administrator wanted to specify a policy covering a portion of the DIT, then the ACIItem would be stored in a PrescriptiveACI attribute of a subentry.

Assuming that the ACI Item in Fig. 8.10 was placed in a PrescriptiveACI attribute covering a part of an organisation, it might soon be realised that this permission is too lax, since it allows anyone to do reverse telephone directory enquiries i.e. find out the person who has a specific telephone number. This facility is available because the FilterMatch permission was given to telephone and fax numbers. Whilst this might be desirable for employees of the organisation, it is not desirable for the general public. Addition of another ACI item that denies anyone outside of the organisation this privilege is shown in Fig. 8.11. The clever use of the subtree user class, ensures that all distinguished names except those of the employees of this organisation, are denied access. Furthermore, since this denial requires simple authentication, any user who is not simply authenticated will be denied the FilterMatch privilege (including this organisation's employees). Therefore only employees who have been password authenticated will be allowed the reverse directory enquiries service. Again, it would be a function of the administrator interface to extract the purpose from the administrator, and to map it into the ACI Item of Fig. 8.11.

PURPOSE: To stop everyone except employees from performing reverse directory enquiries on telephone and fax numbers, and to force employees to be password authenticated if they want to use this service.

Tag: "Public reverse enquiries denied"
Precedence: 20
Authentication Level: simple
User Class: subtree {root,
                    chop before {C=GB, O=This Organisation} }
Protected Items: Attribute Type {telephone number,
                                                     facsimile telephone number},
                            All Attribute Values {telephone number,
                                                           facsimile telephone number}
Permissions: deny filterMatch


Fig. 8.11 Denying non-employees the reverse directory enquiries service.
 

8.8 PROTECTING THE ACCESS CONTROL OPERATIONAL ATTRIBUTES

Not surprisingly, since access control information is held as operational attributes, these attributes can be used to protect themselves. The scheme works as follows. Each attribute value (ACIItem) has a unique tag that differentiates it from all the other values within the same attribute type. The equality matching rule (directoryStringFirstComponentMatch matching rule - see § 3.3.5) defined for the three access control attribute types only matches against the unique tags, ignoring all the remaining information in the attribute values. This makes it very easy to select a particular value. Since each entry or subentry can only have, at most, one multi-valued access control attribute of each type (e.g. EntryACI attribute type), it is possible to directly reference either a single attribute value, via the unique tag, or the attribute as a whole, via its object identifier.

Figure 8.12 gives an example of an EntryACI attribute that protects itself (although this would not be the normal thing to do). One of the attribute values (VE3) references and protects another value (VE2). Another of the attribute values (VE4) references the entire EntryACI attribute.

PURPOSE: To allow the user (whose entry this is) to delete the access rights given in the access control list called "VE2".

Tag: "VE3"
Precedence: 20
Authentication Level: simple
User Class: this entry
Protected Items: Attribute Value {EntryACI,"VE2"}
Permissions: grant remove
Protected Items: Entry
Permissions: grant modify

PURPOSE: To allow the user to read the access control lists stored in her entry.

Tag: "VE4"
Precedence: 20
Authentication Level: none
User Class: this entry
Protected Items: Entry,
                            Attribute Type {EntryACI},
                            All Attribute Values {EntryACI}
Permissions: grant read


Fig. 8.12 EntryACI protecting itself.

A better way to protect EntryACI access control attributes, is via a PrescriptiveACI attribute held in a controlling domain (DACD). Fig. 8.13 gives an example of a PrescriptiveACI which allows all users within the domain to manipulate their own EntryACIs, providing that they have been strongly authenticated first.

PURPOSE: To allow strongly authenticated users to update their own access control lists.

Tag: "Own Entry ACI Updates"
Precedence: 100
Authentication Level: strong
User Class: this entry
Protected Items: Attribute Type {EntryACI},
                            All Attribute Values {EntryACI}
Permissions: grant add,
                      grant remove
Protected Items: Entry
Permissions: grant modify


Fig. 8.13 Granting users the ability to update their own EntryACI attributes (user first syntax).

PrescriptiveACI attributes (held in subentries) can similarly be protected by the SubentryACI attribute held in the immediately superior administrative entry. Fig. 8.14 shows the access rights given to a super-user/administrator, that allow him, via the SubentryACI, to manipulate the subentries holding the access control policies for the administrative area. One of these policies (PrescriptiveACI), also shown in Fig. 8.14, gives the super-user/administrator control over the EntryACI operational attributes in all the entries of the domain.

Fig. 8.14 shows that PrescriptiveACI can allow EntryACI (and also entries) to be created and deleted, and that SubentryACI can allow subentries and PrescriptiveACI to be created and deleted, but what can allow autonomous administrative points (and SubentryACI) to be created and deleted? Remember that the default is to deny permission unless an ACI specifically grants permission, and there are no ACI that grant permission for an autonomous administrative point/entry to be created. The answer must be local policy. In other words, it is outside the scope of the Standard to say how autonomous administrative entries and their associated access control attributes are created. In practice this will probably be via some proprietary administrative interface provided by the DSA supplier. It is also important to note that this interface must be extremely secure, since access to the SubentryACI is the master key to controlling access to all the information in the administrative area.

THE SUBENTRY ACI
PURPOSE: To allow S.User to read and update the access control policies for the administrative area.

Tag: "Subentry Control"
Precedence: 100
Authentication Level: strong
User Class: User {C=US, O=ACME,OU=IS,CN=S.User}
                     Unique Identifier {12345}
Protected Items: Attribute Type {PrescriptiveACI,
                                                     SubtreeSpecification},
                            All Attribute Values {PrescriptiveACI,
                                                           SubtreeSpecification},
                            All User Attribute Types and Values
Permissions: grant add,
                      grant remove,
                      grant read,
                      grant filterMatch,
                      grant compare,
                      grant discloseOnError
Protected Items: Entry
Permissions: grant modify,
                      grant add,
                      grant read,
                      grant remove,
                      grant browse,
                      grant rename,
                      grant discloseOnError,
                      grant returnDN
 

THE PRESCRIPTIVE ACI
PURPOSE: To allow S.User to read and update all the entry access control lists held in all the entries of the domain.

Tag: "Entry Super User Control"
Precedence: 100
Authentication Level: strong
User Class: User {C=US, O=ACME,OU=IS,CN=S.User}
                    Unique Identifier {12345}
Protected Items: Attribute Type {EntryACI},
                             All Attribute Values {EntryACI},
Permissions: grant add,
                      grant remove,
                      grant read,
                      grant filterMatch,
                      grant compare,
                      grant discloseOnError
Protected Items: Entry
Permissions: grant modify,
                      grant read,
                      grant browse,
                      grant discloseOnError,
                      grant returnDN


Fig. 8.14 Super-user control of ACI.

Fig. 8.14 (Cont.) Super-user control of ACI.

8.9 THE ACCESS CONTROL DECISION FUNCTION (ACDF)

The purpose of the access control decision function is to decide, from the set of ACI items controlling access to an entry, whether or not a user is granted a particular permission to access a particular protected item. How the complete set of ACI items is determined was explained in § 8.2.2. The ACDF will be called a number of times for each operation, as shown by Table 8.4. The normal sequence of events will be to gain access to the entry, then to the attribute type, then to the attribute values. When a permission is granted, operation evaluation will continue as normal. When a permission is denied, the operation may be terminated and an error response sent to the user, or alternatively, some information may be omitted from the operation result, and the evaluation continued. This depends upon the particular operation and the permission being requested, as described in § 8.5.1-9. The inputs to and output from the ACDF are shown in Fig. 8.15.

Fig. 8.15 Input and output of the Access Control Decision Function.

The ACDF works according to the following principles.
Note.A tuple is one complete set of access control information, containing the precedence, authentication level, a single user class, single protected item and single permission; an ACI item on the other hand usually contains many tuples grouped together, e.g. as in Fig. 8.10.

  1. All non relevant access control tuples are discarded. This includes tuples that do not include the user, either directly or indirectly, in their user class, and tuples that do not include the desired protected item or the requested permission. This is slightly more complicated than it might at first seem to be, for example, tuples that grant access to the user, but which require a higher authentication level than that possessed by the user are discarded. Conversely tuples which do not deny access to the user, but which require a higher authentication level than that possessed by the user are kept (§ 8.1.3).
  2. Only keep those remaining tuples which have the highest precedence level.
  3. Keep the tuple(s) with the most specific user class, according to the precedence: name = thisEntry > userGroup > subtree > allUsers.
  4. Keep the tuple(s) with the most specific protected item, for example, attributeValue > allAttributeValues.
Access is granted only if all the remaining tuples grant access. If there are no tuples remaining, or at least one of them denies access, then access is denied. With the above algorithm in mind, it should now be relatively straightforward to code up the ACDF procedure.

8.10 THE SIMPLIFIED ACCESS CONTROL SCHEME

Now that the basic access control scheme has been described, one can be excused for thinking "this seems complicated to implement, or to administer or to compute for each operation". Consequently the standard's group has devised a simplified access control scheme that greatly reduces the computation needed to evaluate the user's access rights for each operation. The implementation effort is also somewhat reduced by this simplification, and the administrator's task is made slightly easier.

The simplified scheme works by ignoring the existence of EntryACI attributes and access control inner areas (ACIAs). This means that all entries in an administrative area are protected solely by the PrescriptiveACI attributes held in the subentries below their Administrative Point, and subentries are protected by the single SubentryACI attribute in their administrative entry. It thus becomes much simpler to evaluate the access rights of a user on a per operation basis, since only one set of ACI Items (the PrescriptiveACI) need to be evaluated, as compared with several sets (the EntryACI, the inner area PrescriptiveACI and the specific area PrescriptiveACI) of the basic scheme. Not only this, but the evaluation only needs to be performed once per administrative area with the simplified scheme. With the basic scheme, the computation needs to be performed once for each entry within the scope of a Directory operation. Consequently there should be a significant performance improvement for evaluating Search operations under the simplified access control scheme as compared to the basic scheme (and Search operations are by far the most common operation in the current pilot projects). I would guess that many implementations will initially opt for the simplified scheme. Of course, from an administrator's perspective, the real simplification comes from the user interface!

8.11 IDENTIFYING THE ACCESS CONTROL SCHEME IN USE

A Directory operational attribute, called appropriately the access control scheme attribute, has been defined in the '93 Standard. This attribute is stored in the administrative entry of the Access Control Specific Area, and it says which access control scheme is in operation in the area. The attribute is single valued, and its syntax is an object identifier. Two object identifier values have been standardised, one to signify the basic scheme and one to signify the simplified scheme.

If an implementation does not support either of these access control schemes e.g. an '88 implementation, then it has two options open to it. It may choose not to store the access control scheme attribute in its administrative entry, in which case it is a local matter how access controls are implemented in the ACSA, and remote DSAs will not be able to find out. Alternatively, an implementor or community of users may define their own access control scheme (many '88 implementations have done this), then assign an object identifier to this definition, and store that value in the access control scheme attribute. Remote DSAs will then be able to determine which access control scheme is in force in a particular ACSA. Remember that for shadowing to be implemented correctly, both the shadow supplier and shadow consumer must either implement the same access control scheme, or be able to map precisely between their two schemes.

WEIRD AND WONDERFUL

8.1 Almost every expert attending the access control subgroup meetings had their own view of "the best" access control scheme. Access controls were actually first defined as long ago as 1986, but no one could agree on the best scheme for the Directory. (The 1986 scheme was rejected as being too complex, but the 1993 scheme would appear to be just as, if not more, complex.) In truth there is no best scheme, just dozens of different schemes, each with their own strengths and weaknesses. For this reason, in the search for the access control 'holy grail', a number of different proposals were appraised, adapted and modified, before the final scheme was eventually agreed upon. As always the limiting factor was time!

8.2 In order to fully specify an attribute value, you have to quote its type as well as its value. (Attribute value 6 is not very meaningful. Is it my age, or my number of children? Value 6 of attribute type number of children is more meaningful.) In order to give someone access to a particular attribute value in your entry, you would expect to quote the value of the particular attribute that is to be accessed (e.g. grant Read to the specified attribute (type and) value). However, for read access, this would not actually allow that person to read the value! since you have not explicitly given him access to the attribute type as well. You would therefore have to give them read access to the attribute type as well as to the value (i.e. grant Read to the attribute type and grant Read to the attribute type and value). For read access, this leads to a duplication of access control protected items, since each attribute type must be quoted twice as a protected item, once as an attribute type, and once as the type of a particular value. Admittedly, the user interface can shield the user from having to explicitly do this, but it would have been better to have given the semantics 'this value and its associated type' to the protected items 'attribute value' and 'all attribute values', since this is actually what it is. It is hard to imagine a situation in which you would want to allow someone read access to an attribute value, but not to its object identifier type, since giving the former automatically gives the latter!
Permission to compare an attribute value has similarly to be given to the attribute type, and to the type and value.
The situation is made even more confusing, when Add and Remove permissions are being considered. In this case, you only need to give Add or Remove permission to an attribute (type and its) value, in order for it to be added to or removed from the set of values. In this case, specific attribute type permission is not needed. Indeed, permissions to add or to remove an attribute type have completely different meanings. In the case of permission to remove an attribute type, the user is allowed to remove the complete attribute, irrespective of their permissions on the individual attribute values. In the case of permission to add an attribute type, permission is also needed to add all of the individual attribute values, otherwise the attribute cannot be added.

8.3 Null and filters evaluate to True for all the entries that are present in the DIT, whereas filters containing filter items only evaluate to True for those entries which have the correct attributes present in them. I could allow people to read, say, my telephone number, but could stop them filtering on it, by denying FilterMatch permission to the telephone number attribute. (This would stop reverse directory enquiries.) However, the same people could circum-navigate this control by using a null and filter and reading my telephone number. They would thus be able to find out all the entries that were present in a certain part of the DIT, and retrieve the telephone numbers of all of them. Post processing of the output would then yield the desired result. The Standard does not have an access control mechanism to stop people filtering on 'entry present in the DIT?' (the null and filter). It would be a simple and logical addition to the Standard to stop the filtering on 'entry present in the DIT', by allowing the FilterMatch permission to be applied to entries. Denial of filterMatch on an entry, would make the entry not appear to be in the DIT, to users who used the null and filter. However, the only way that this sort of trawling can currently be curtailed is via non-standard management controls built into individual implementations. So make sure that your implementation has them.

8.4. The first guiding principle, outlined in § 8.1.1 and § 8.5, has not been rigorously adhered to. There is an inconsistency between adding an entry, adding an attribute, and adding an attribute value, when the user does not have any permissions. In the cases of entry and value, the user is told that the information does not exist - either Name Error (no such object) or Attribute Error (no such attribute or value). In the case of attribute, the user is told Security Error (insufficient access rights) - see Figs 8.6, 8.7 and 8.8. A defect report to this effect has been submitted.