Access evaluation

Edit online

Access for a particular operation is granted or denied based on the subject's bind DN for that operation on the target object. The processing stops as soon as access can be determined.

The checks for access are done by first finding the effective entryOwnership and ACI definition, checking for entry ownership, and then by evaluating the ACI values of the object.

Filter-based ACLs are accumulated from the lowest containing entry, upward along the ancestor entry chain, and to the highest containing entry in the DIT. The effective access is calculated as the union of the access rights that are granted, or denied, by the constituent ancestor entries. The existing set of specificity and combinatory rules evaluate effective access for filter-based ACLs.

Filter-based and non-filter-based attributes are mutually exclusive within a single containing directory entry. Placing both types of attributes into the same entry is not allowed and is a constraint violation. Operations that are associated with the creation of, or updates to a directory entry fails if this condition is detected.

When it calculates effective access, the first ACL type to be detected in the ancestor chain of the target object entry sets the mode of calculation. In filter-based mode, non-filter-based ACLs are ignored in effective access calculation. Likewise, in non-filter-based mode, filter-based ACLs are ignored in effective access calculation.

To limit the accumulation of filter-based ACLs in the calculation of effective access, an ibm-filterAclInherit attribute that is set to a value of false can be placed in any entry between the highest and lowest occurrence of ibm-filterAclEntry in subtree. This method causes the subset of ibm-filterAclEntry attributes above it in the target object's ancestor chain to be ignored.

To exclude the accumulation of filter-based ACLs in the calculation of effective access, an ibm-filterAclInherit attribute that is set to a value of false can be placed in any entry below the lowest occurrence of ibm-filterAclEntry in a subtree. This method causes all ibm-filterAclEntry attributes above it in the target object's ancestor chain to be ignored. The resulting access resolves to the default filter ACL value.

By default, the directory administrator, local administrative group members who are assigned the DirDataAdmin role, and the master server (or peer server for replication) get full access rights to all objects in the directory except write access to system attributes. Other entryOwners get full access rights to the objects under their ownership except write access to system attributes. By default all users have read-access rights to normal, system, and restricted attributes. If the requesting subject has entryOwnership, access is determined by the default settings and access processing stops.
Note: If explicit ACLs are set on an entry, but no explicit ACLs are set for system attributes, then the requester is automatically granted read, search, and compare permissions. To deny access, you must deny it explicitly. Access is not denied by default.
If the requesting subject is not an entryOwner, then the ACI values for the object entries are checked. The access rights as defined in the ACIs for the target object are calculated by the specificity and combinatory rules.
Specificity rule
The most specific aclEntry definitions are the ones that are used in the evaluation of permissions granted/denied to a user. The following levels are the levels of specificity:
  • Access-id is more specific than group or role. Groups and roles are on the same level.
  • Within the same dnType level, individual attribute level permissions are more specific than attribute class level permissions.
  • Within the same attribute or attribute class level, deny is more specific than grant.
Combinatory rule
Permissions that are granted to subjects of equal specificity are combined. If the access cannot be determined within the same specificity level, the access definitions of lesser specific level are used. If the access is not determined after all defined ACIs are applied, the access is denied.
Note: After a matching access-id level aclEntry is found in access evaluation, the group level aclEntries are not included in access calculation. The exception is that if the matching access-id level aclEntries are all defined under cn=this, then all matching group levelaclEntries are also combined in the evaluation.
In other words, within the object entry, if a defined ACI entry contains an access-id subject DN that matches the bind DN, then the permissions are first evaluated based on that aclEntry. Under the same subject DN, if the matching attribute level permissions are defined, they supersede any permissions that are defined under the attribute classes. Under the same attribute or attribute class level definition, if conflicting permissions are present, denied permissions override granted permissions.
Note: A defined null value permission prevents the inclusion of less specific permission definitions.
If access still cannot be determined and all found matching aclEntries are defined under cn=this, then group membership is evaluated. If a user belongs to more than one group, the user receives the combined permissions from these groups. Additionally, the user automatically belongs to the cn=Anybody group and possibly the cn=Authenticated group if the user did an authenticated bind. If permissions are defined for those groups, the user receives the specified permissions.
Note: Group and Role membership is determined at bind time and last until either another bind takes place, or until an unbind request is received. Nested groups and roles that is a group or role that is defined as a member of another group or role, are not resolved in membership determination nor in access evaluation.
For example, assume attribute1 is in the sensitive attribute class, and user cn=Person A, o=sample belongs to both group1 and group2 with the following aclEntries defined:
  1. aclEntry: access-id: cn=Person A, o=sample: at.attributel:grant:rsc:sensitive:deny:rsc
  2. aclEntry: group: cn=group1,o=sample:critical:deny:rwsc
  3. aclEntry: group: cn=group2, o=sample:critical:grant:r:normal:grant:rsc
This user gets:
  • Access of rsc to attribute1, (from 1. Attribute level definition supersedes attribute class level definition).
  • No access to other sensitive class attributes in the target object (from 1).
  • No other rights are granted (2 and 3 are NOT included in access evaluation).
For another example, with the following aclEntries:
  1. aclEntry: access-id: cn=this: sensitive
  2. aclEntry: group: cn=group1, o=sample:sensitive:grant:rsc:normal:grant:rsc
The user has:
  • No access to sensitive class attributes, (from 1. Null value that is defined under access-id prevents the inclusion of permissions to sensitive class attributes from group1).
  • And access of rsc to normal class attributes (from 2).