Page Operations
Browse Space
Access Control Scheme Operational Attribute: accessControlScheme
Below is a snipet from X.501 which talks about an accessControlScheme attribute:
The Directory provides a means for the access control scheme in force in a particular portion of the DIB to be identified through the use of the operational attribute accessControlScheme. The scope of such a scheme is defined by an Access Control Specific Area (ACSA), which is a specific administrative area that is the responsibility of the corresponding Security Authority. This attribute is placed in the Administrative Entry for the corresponding Administrative Point. Only administrative entries for Access Control Specific Points are allowed to contain an accessControlScheme attribute.
This translates to having an operational attribute, accessControlScheme, within the entry at the administrative point. This value of this attribute is an OID. The ASN.1 for the attribute is defined below within section 17.2.2. We specifically need an LDAP attributeType specification for this ASN.1 definition for the attribute so we can add it to the Administrative Point.
accessControlScheme ATTRIBUTE ::= {
WITH SYNTAX OBJECT IDENTIFIER
EQUALITY MATCHING RULE objectIdentifierMatch
SINGLE VALUE TRUE
USAGE directoryOperation
ID id-aca-accessControlScheme }
For basic access control the X.501 attribute will contains the value basic-access-control. However for LDAP we can represent the value as basicAccessControl and assign it an OID to specifically identify this value. Below is the definition for the LDAP attributeType:
attributetype ( 1.2.6.1.4.1.18060.1.1.1.3.14 NAME 'accessControlScheme' DESC 'Access control scheme in force for a ACSA' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE directoryOperation )
Protected Items
| Protected Items |
|---|
| Entries |
| Attributes |
| Attribute Values |
| Names |
Aspects of permission categories
- All operations except delete and modifyDn operations need both entry and attribute level access.
- To perform Directory operations that require access to attributes or attribute values, it is necessary to have entry access permission to the entry or entries that contain those attributes or values. Note the removal of an entry or an attribute does not require access to the values of an attribute.
- Without an explicit grant access is denied. Everything is closed from the start. Denials override grants if precedence is the same.
Permission Categories for Entry Access
Subentry Access Control: subentryACI
The subentryACI operational attribute would reside within entries of administrative points and applies only to immediately subordinate subentries. This is specified within section 18.5.3 of X.501.
Conversely perscriptiveACIs in subentries never apply to subentries of the same administrative point however they may apply to the subentries of inner areas. See section 18.5.3 of X.501. This section is small enough to include here:
Subentry ACI attributes are defined as operational attributes of administrative entries, and provide access control information that applies to each of the subentries of the corresponding administrative point. Prescriptive ACI within the subentries of a particular administrative point never applies to the same or any other subentry of that administrative point, but can be applicable to the subentries of subordinate administrative points. Subentry ACI attributes are contained only in administrative points and do not affect any element of the DIT other than immediately subordinate subentries.
In evaluating access control for a specific subentry, the ACI that shall be considered is:
- the entryACI within the subentry itself (if any);
- the subentryACI within the associated administrative entry (if any);
- prescriptiveACI associated with other relevant administrative points within the same access control specific area (if any).
subentryACI ATTRIBUTE ::= {
WITH SYNTAX ACIItem
EQUALITY MATCHING RULE directoryStringFirstComponentMatch
USAGE directoryOperation
ID id-aca-subentryACI }
What this means is we have to process access controls differently for subentries. So for a subentry we apply the entryACI as we do with other entry types. Then we need to apply the subentyACI within the parent which is the administrative point entry.
Now how we apply perscriptiveACI to subentries is a bit ambiguous. The subentry subsystem does not inject operational attributes into subentries as it does for regular entries. Regular entries included by the subtree specification of subentries have the operational attributes associated with administrativeRoles added to the included entry. These opattrs hold a DN to the including subentry. This will not occur for entries that are subentries. At a cursory glance imposes some problems.
First of all, we cannot link a subentry A in an outter administrative point to a target subentry B included by the subtreeSpecification of the first subentry A. This however may not really be necesary to do. This is why the X.501 spec is somewhat ambiguous when things boil down to an implementation. Technically a subentry is at the same context as its superior administrative point. If that is the case, then all subentries including the administrative point also includes the subentries. Effectively for our implementation, this means that subentries can use the accessControlSubentries operational attribute (if present) within the administrative entry to discover perscriptiveACI's effecting subentries.