aclEntry attribute

aclEntry is a multi-valued attribute that contains information pertaining to the access allowed to the entry and each of its attributes. aclEntry lists the following types of information:

Who has rights to the entry (scope of the protection). Also called the subject.
What specific attributes and classes of attributes (attribute access classes) that the subject has access to.
What rights the subject has (permissions to specific attributes and classes of attributes).

Syntax

Following is the aclEntry attribute value syntax:

aclEntry: aclEntry_value¹
subject_DN :- valid DN, the object that privileges are granted to.
filter :- valid search filter, using the following attributes only: ibm-filterSubject, ibm-filterIP, ibm-filterTimeOfDay, ibm-filterDayOfWeek, ibm-filterBindMechanism, and ibm-filterConnectionEncrypted. See ACL filters for more information.
operation :- union | replace | intersect. See ACL filters for more information.
granted_rights :- object_rights | normal_rights | sensitive_rights | critical_rights | restricted_rights | system_rights | attr_rights
object_rights :- :object:[grant:|deny:]object_rights_list
object_rights_list :- [a|d]
normal_rights :- :normal:[grant:|deny:]attr_rights_list
sensitive_rights :- :sensitive:[grant:|deny:]attr_rights_list
critical_rights :- :critical:[grant:|deny:]attr_rights_list
restricted_rights :- :restricted:[grant:|deny:]attr_rights_list
system_rights :- :system:[grant:|deny:]attr_rights_list
attr_rights :- :at.attr_name:[grant:|deny:]attr_rights_list
attr_name:- any valid attribute name
attr_rights_list :- [r|w|s|c]

The subject_DN is any valid DN that represents the object (entry) to which privileges are being granted. The DN ends when the first granted rights keyword is detected.

The granted_rights is specified as follows where object_rights_list is one or more elements of the set [a|d], and attr_rights_list is one or more elements of the set [r|w|s|c].

See ACL filters for more information about the filter and operation values.

Multiple specifications for the same access class or attribute type within the same aclEntry attribute value are merged into a single specification. For example:

group:cn=Anybody:normal:rs:system:rsc:normal:c:normal:deny:w

results this merged access list

group:cn=Anybody:normal:rsc:normal:deny:w:system:rsc

Scope of protection

The scope of the protection is based on the following types of privilege attributes:

access-id: The distinguished name of an entry to set permissions for.
group: The distinguished name of the group entry to set permissions for.
role: The distinguished name of the group entry to set permissions for.
aclFilter: The aclEntry filter, that if evaluates to true, reduces, augments, or replaces the set of permissions. The server compatibility must be 6 or greater to use an aclFilter in an aclEntry attribute. See page serverCompatLevel {3 | 4 | 5 | 6 | 7} for more information about the server compatibility level.

Access control groups can be either static, dynamic, or nested groups. The following object classes are evaluated as group entries for the LDBM, TDBM, and CDBM backends: ibm-staticGroup, groupOfNames, groupOfUniqueNames, accessRole, accessGroup, ibm-dynamicGroup, groupOfUrls, and ibm-nestedGroup. See Static, dynamic, and nested groups for additional information about static, dynamic, and nested groups.

When specifying a user or group distinguished name in an aclEntry attribute value, the access-id, group, or role portions of the value are optional and are accepted for compatibility with older levels of the LDAP server. If replicating to non-z/OS IBM® TDS, one of these prefixes are required. The distinguished name that is used does not need to be the name of any entry in the directory. The distinguished name is the name that represents the user that has authenticated to the directory server or the group that the user is a member of.

The access control implementation supports several "pseudo-DNs". These are used to reference large numbers of subject 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:

group:cn=anybody 
group:cn=authenticated 
access-id:cn=this

The group:cn=anybody refers to all subjects, including those that are unauthenticated (considered anonymous users). All users belong to this group automatically. The group:cn=authenticated refers to any DN that is authenticated to the directory. The method of authentication is not considered when using distinguished names in the aclEntry attribute value.

The access-id:cn=this refers to the bind DN that matches the target object's DN on which the operation is performed.

If the server compatibility is 6 or greater, a search filter can be specified after the aclFilter component in an aclEntry attribute value. When the search filter evaluates to true, it reduces, augments, or replaces the set of permissions specified. See ACL filters for more information about the search filters that are allowed to be specified.

Examples:

In this example, the DN type is access-id and the DN itself is cn=personA, ou=deptXYZ, o=IBM, c=US:

access-id:cn=personA, ou=deptXYZ, o=IBM, c=US

In this example, the DN type is group and the DN itself is cn=deptXYZRegs, o=IBM, c=US:

group:cn=deptXYZRegs, o=IBM, c=US

This is an example of how to use a RACF® identity established with SDBM in an ACL:

access-id:racfid=YourID,profileType=user,sysplex=YourSysplex
group:racfid=YourGrp,profileType=group,sysplex=YourSysplex

Attribute access classes

Attributes requiring similar permission for access are grouped together in classes. Attributes are assigned to an attribute access class within the schema definitions. The IBMAttributeTypes attribute in the LDAP server schema entry holds the attribute types access class. The three attribute access classes are:

normal
sensitive
critical

Each of these attribute access classes is discrete. If a user has write permission to sensitive attributes, then the user does not automatically have write permission to normal attributes. This permission must be explicitly defined.

The default attribute access class for an attribute is normal. By default, all users have read access to normal attributes. There are two additional attribute access classes used internally by LDAP for system attributes. These attribute access classes are restricted and system. You can specify these access classes when granting permissions in ACLs.

For example, the name of a person is typically defined in the normal class. Perhaps a social security number is considered sensitive, and any password information for the user is considered critical. Following are some example definitions excerpted from the LDAP server schema. Note that the attribute userPassword is defined with access class critical.

attributetypes: (
  2.5.4.49
  NAME ( ’dn’  ’distinguishedName’  )
  EQUALITY distinguishedNameMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
  USAGE userApplications
  )
ibmattributetypes: (
  2.5.4.49
  ACCESS-CLASS normal
  )
 
attributetypes: (
  2.5.4.35
  NAME ’userPassword’
  DESC ’Defines the user password’
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
  USAGE userApplications
  )
ibmattributetypes: (
  2.5.4.35
  ACCESS-CLASS critical
  )

It is possible to specify access controls on individual attributes. However, when defining schema an access class is always defined for the attribute type. If not specified, that attribute type is defined to belong to the normal class.

Note: The restricted attributes are: aclEntry, aclPropagate, entryOwner, and ownerPropagate. In order to update access control information, you must have permissions to read and write these attributes. The system attributes include aclSource and ownerSource and other attributes for which the server controls the values. In order to update access control information, you must have permission to read and write these attributes. If the system keyword is not specified in an aclEntry attribute value, the system access is set to 'system:rsc'.

Access permissions

Following is the set of access permissions.

Table 1. Permissions that apply to an entire entry
Permission
Add	Add an entry below this entry
Delete	Delete this entry

Table 2. Permissions that apply to attribute access classes
Permission
Read	Read attribute values
Write	Write attribute values
Search	Search filter can contain attribute type
Compare	Compare attribute values

Following are some examples of valid aclEntry values:

access-id:cn=Tim, o=Your Company:normal:rwsc:sensitive:rsc:object:ad
 
role:cn=roleGroup, o=Your Company:object:ad:normal:rsc:sensitive:rsc
 
group:cn=group1, o=Your Company:system:csr:normal:sw
 
cn=Lisa, o=Your Company:normal:rwsc:sensitive:rwsc:critical:rwsc:restricted:rwsc:system:rwsc
 
cn=Ken, o=Your Company:normal:rsc

group:cn=group2,dc=yourcompany,dc=com:normal:rwsc:at.cn:deny:w:sensitive:grant:rsc

cn=Karen,dc=yourcompany,dc=com:at.cn:grant:rwsc:normal:deny:rwsc

cn=Mary,dc=yourcompany,dc=com:normal:rwsc:sensitive:rwsc:critical:deny:rwsc:at.userpassword:w

group:cn=anybody:normal:rsc

group:cn=authenticated:normal:rwsc:sensitive:rsc

access-id:cn=this:normal:rwsc:sensitive:rwsc:restricted:rwsc

aclFilter: (&(ibm-filterTimeOfDay>=09:00)(ibm-filterTimeOfDay<=17:00)(ibm-filterDayOfWeek>=1)
 (ibm-filterDayOfWeek<=5)):union:normal:w

aclFilter: (|(ibm-filterSubject=cn=Ken, o=Your Company)(ibm-filterIP=129.176.132.*))
 :replace:normal:rwsc:critical:rsc:sensitive:rwsc

See Access determination for information about how the aclEntry values are used to determine access.

The aclEntry attribute value is defined as a directory string.

When the aclFilter scope is not specified, a search using the aclEntry attribute matches against the distinguished name in the value. An aclEntry value in this format is normalized following the matching rules for a distinguished name. Two aclEntry attributes in this format are considered to be the same if they have the same distinguished name.

When the aclFilter scope is specified, a search using the aclEntry attribute matches against the scope, filter, and operation in the search filter. An aclEntry in this format is normalized by normalizing the scope, filter, and the operation. Two aclEntry attributes in this format are considered to be the same if they have the same filter and operation.