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
  • where,
  • aclEntry_value :- [access-id:|group:|role:] subject_DN [granted_rights]
  • or,
  • aclEntry_value :- aclFilter:filter: operation [granted_rights]
  • 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 serverCompatLevel {3 | 4 | 5 | 6 | 7| 8} 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 that is 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 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 that are 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 that are 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. 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. 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.