A subject (the entity requesting access to operate on an object) consists of the combination of a DN (Distinguished Name) type and a DN. The valid DN types are: access-id, Group and Role.
The DN identifies a particular access-id, role or group. For example, a subject might be access-id: cn=personA, o=IBM or group: cn=deptXYZ, o=IBM.
Because the field delimiter is the colon ( : ), a DN containing colons must be surrounded by double-quotation marks ( "" ). If a DN already contains characters with double-quotation marks, these characters must be escaped with a backslash (\).
All directory groups can be used in access control.
Another DN type used within the access control model is role. While roles and groups are similar in implementation, conceptually they are different. When a user is assigned to a role, there is an implicit expectation that the necessary authority has already been set up to perform the job associated with that role. With group membership, there is no built in assumption about what permissions are gained (or denied) by being a member of that group.
Roles are similar to groups in that they are represented in the directory by an object. Additionally, roles contain a group of DNs. Roles that are used in access control must have an objectclass of AccessRole.
The LDAP directory contains several pseudo DNs. These are used to refer to large numbers of DNs which at bind time share a common characteristic, in relation to either the operation being performed, or the target object on which the operation is being performed.
Currently, three pseudo DNs are defined:
This parameter applies to filtered ACLs only. The string search filter as defined in RFC 2254, is used as the object filter format. Because the target object is already known, the string is not used to perform an actual search. Instead, a filter-based compare on the target object in question is performed to determine if a given set of ibm-filterAclEntry values apply to it.
Access rights can apply to an entire object or to attributes of the object. The LDAP access rights are discrete. One right does not imply another right. The rights can be combined together to provide the desired rights list following a set of rules discussed later. Rights can be of an unspecified value, which indicates that no access rights are granted to the subject on the target object. The rights consist of three parts:
The possible attribute permissions are: read ( r ), write ( w ), search ( s ), and compare ( c ). Additionally, object permissions apply to the entry as a whole. These permissions are add child entries ( a ) and delete this entry ( d ).
The following table summarizes the permissions needed to perform each of the LDAP operations.
| Operation | Permission Needed |
|---|---|
| ldapadd | add (on parent) |
| ldapdelete | delete (on object) |
| ldapmodify | write (on attributes being modified) |
| ldapsearch |
|
| ldapmodrdn | write (on RDN attributes) |
| ldapcompare | compare (on compared attribute) |
Attributes requiring similar permissions for access are grouped together in classes. Attributes are mapped to their attribute classes in the directory schema file. These classes are discrete; access to one class does not imply access to another class. Permissions are set with regard to the attribute access class as a whole. The permissions set on a particular attribute class apply to all attributes within that access class unless the individual attribute access permissions are specified.
IBM defines three attribute classes that are used in evaluation of access to user attributes: normal, sensitive, and critical. For example, attribute commonName falls into the normal class, and attribute userpassword belongs to the critical class. User defined attributes belong to the normal access class unless otherwise specified.
Two other access classes are also defined: system and restricted. The system class attributes are:
These are attributes maintained by the LDAP server and are read-only to the directory users. OwnerSource and aclSource are described in the Propagation section (seePropagation).
The restricted class of attributes that define the access control are:
All users have read access to the restricted attributes but only entryOwners can create, change, and delete these attributes.