Directory Access Control, 3 of 5

How ACL Evaluation Works

When a user tries to perform an operation on a given object, the directory server determines whether that user has the appropriate access to perform that operation on that object. If the object is an entry, it evaluates the access systematically for the entry and each of its attributes.

Evaluating access to an object--including an attribute of an entry--can involve examining all the ACI directives for that object. This is because of the hierarchical nature of ACPs and the inheritance of policies from superior ACPs to subordinate ACPs.

The directory server first examines the ACI directives in the entry-level ACI, orclEntryLevelACI. It proceeds to the nearest ACP, then considers each superior ACP in succession until the evaluation is complete.

During ACL evaluation, an attribute is said to be in one of the following states:

Table 14-3 Attribute States During ACL Evaluation

State	Description
Resolved with permission	The required access for the attribute has been granted in the ACI.
Resolved with denial	The required access for the attribute has been explicitly denied in the ACI.
Unresolved	No applicable ACI has yet been encountered for the attribute in question.

In all operations except search, the evaluation stops if:

Access to the entry itself is denied
Any of the attributes reach the resolved with denial state.

In this case the operation would fail and the directory server would return an error to the client.

In a search operation, the evaluation continues until all the attributes reach the resolved state. Attributes that are resolved with denial are not returned.

This section contains these topics:

Precedence Rules Used in ACL Evaluation

An LDAP operation requires the BindDN, or subject, of the LDAP session to have certain permissions to perform operations on the objects--including the entry itself and the individual attributes of the entry.

Typically, there could be a hierarchy of access control administration authorities, starting from the root of a naming context down to successive administrative points (or access control policy points). An ACP is any entry which has a defined value for the orclACI attribute. Additionally, the access information specific to a single entry can also be represented within the entry itself (orclEntryLevelACI).

ACL evaluation involves determining whether a subject has sufficient permissions to perform an LDAP operation. Typically an orclentryLevelACI or orclACI might not contain all the necessary information for ACL evaluation. Hence, all available ACL information is processed in a certain order until the evaluation is fully resolved.

That order of processing follows these rules:

The entry level ACI is examined first. ACIs in the orclACI are examined starting with the ACP closest to the target entry and then its superior ACP and so on.
At any point, if all the necessary permissions have been determined, the evaluation stops; otherwise, the evaluation continues.
Within a single ACI, if the entity associated with the session DN matches more than one item identified in the by clause, the effective access evaluates to:
- The union of all the granted permissions in the matching by clause items
  
  ANDed with
- The union of all the denied permissions in the matching by clause items

Precedence at the Entry Level

ACIs at the entry level are evaluated in the following order:

With a filter. For example:

access to entry filter=(cn=p*)

by group1 (browse, add, delete)

Without a filter. For example:

access to entry

by group1 (browse, add, delete)

Precedence at the Attribute Level

At the attribute level, specified ACIs have precedence over unspecified ACIs.

ACIs for specified attributes are evaluated in the following order:
1. Those with a filter. For example:
```
access to attr=(salary) filter=(salary > 10000)
by group1 (read)
```
2. Those without a filter. For example:
```
access to attr=(salary)
by group1 (search, read)
```
ACIs for unspecified attributes are evaluated in the following order:
1. With a filter. For example:
```
access to attr=(*) filter (cn=p*)
by group1 (read, write)
```
2. Without a filter. For example:
```
access to attr=(*)
by group1 (read, write)
```

Use of More Than One ACI for the Same Object

Beginning with Release 9.0.4, Oracle Internet Directory, enables you to define more than one ACI in the ACP of an object. Oracle Internet Directory processes the ACIs associated with that object and stores them as a single ACI in its internal ACP cache. It then applies all the relevant policies in the multiple ACIs specified in the ACP.

The following example of an ACP illustrates how tis works.

Access to entry by dn="cn=john" (browse,noadd,nodelete)
Access to entry by group="cn=admingroup" (browse,add,nodelete)
Access to entry by dn=".*,c=us" (browse,noadd,nodelete)

In this ACP, there are three ACIs for the object entry. When it loads this ACP, Oracle Internet Directory merges these three ACIs as one ACI in its internal ACP cache.

The ACI syntax is:

Access to <OBJECT> by <SUBJECT> <ACCESSLIST>
<OBJECT> = [ entry |  attr [EQ-OR-NEQ] ( * | <ATTRLIST> ) ]
[ filter = ( <LDAFILTER> ) ]

This syntax makes possible the following types of objects:

Entry
Entry + filter = ( LDAPFILTER )
Attr = ( ATTRLIST )
Attr = ( ATTRLIST) + filter = ( LDAPFILTER )
Attr != ( ATTRLIST )
Attr != ( ATTRLIST ) + filter = ( LDAPFILTER )
Attr = ( * )
Attr = ( * ) + filter = ( LDAPFILTER )

You can define multiple ACIs for any of the above types of objects. During initial loading of the ACP, the directory server merges the ACIs based on which of these object types are defined. The matching criterion is the exact string comparison of the object strings in the ACIs.

If one ACI specifies ATTR=(ATTRLIST) and another ATTR!=(ATTRLIST), then ATTR=(*) must not be specified as an ACI in the entry. Also, if an ACI specifies ATTR=(ATTRLIST), then, to specify the access rights to attributes not in ATTRLIST, ATTR=(*) must be used and not ATTR!=(ATTRLIST). ATTR=(*) implies all attributes other than those specified in ATTRLIST.

Exclusionary Access to Directory Objects

If an ACI exists for a given object, you can specify access to all other objects except that one. You do this either by granting access to all the objects, or by denying access to the one object.

In the following example, access is granted to all attributes:

access to attr=(*) 

by group2 (read)

In the following example, access is denied to the userpassword attribute:

access to attr!=(userpassword)

by group2 (read)

ACL Evaluation For Groups

If an operation on an attribute or the entry itself is explicitly denied at an ACP low in the DIT, then, typically, the ACL evaluation for that object is considered "Resolved with Denial." However, if the user of the session (bindDN) is a member of a group object, then the evaluation continues as if it is still unresolved. If permissions are granted to the user of the session at an ACP higher in the tree through a group subject selector, then such grants have precedence over any denials lower in the DIT.

This scenario is the only case in which an ACL policy at a higher level ACP has precedence over an ACP policy lower in the DIT.