Compatibility With the Oracle Directory Server Enterprise Edition Access Control Model

The following sections describe how the Oracle Unified Directory access control model differs from the access control model provided with Oracle Directory Server Enterprise Edition.

Global ACI
All Attributes targetattr Rule (targetattr="*")
Distinguished Name (DN) Wildcard Matching
Privilege Subsystem Impact
The targetscope Keyword
LDAP Modify Increment
Macro Support
The roledn Keyword

Global ACI

Global ACI configuration differs from the Oracle Directory Server Enterprise Edition global ACI implementation in two ways:

The ds-config-global-aci attribute specifies a global ACI in the cn=Access Control Handler,cn=config entry (see Access Control Principles) rather than placing the ACI in the root DSE entry.

The scope of the global ACI can be narrowed by specifying a target keyword in the ACI. For example, the following global ACI restricts anonymous read access to entries under the suffix dc=example,dc=com:

ds-cfg-global-aci: (target="dc=example,dc=com")
(targetattr!="userPassword||authPassword")
(version 3.0; acl "Anonymous read access only under dc=example,dc=com suffix";
allow (read,search,compare) userdn="ldap:///anyone";)

Removing the (target="dc=example,dc=com") expression would make the ACI global to all entries in Oracle Unified Directory.

All Attributes `targetattr` Rule `(targetattr="*")`

The all attributes targetattr rule only applies to non-operational attributes. Operational attributes must be explicitly specified in a targetattr ACI statement. This differs from Oracle Directory Server Enterprise Edition behavior, which allows the all attributes targetattr rule to apply to both operational and non-operational attributes.

It is also illegal to use a not-equal operator when an operational attribute is specified in a targetattr rule. For example, the targetattr rule below is invalid because the operational attribute aclRights is used with a not-equal operator:

(targetattr != aclRights)

Note - A non-equal operator in a targetattr rule specifying non-operational attributes is valid, but the rule is restricted to applying to other non-operational attributes only.

It is illegal to specify both operational and non-operational attributes in the same targetattr statement.

It is illegal to specify both the all attributes targetattr rule and an attribute in the same expression (for example, targetattr="cn || *").

Distinguished Name (DN) Wildcard Matching

The ACI DN wildcard matching implementation supports the following usage:

Any number of wildcards can appear in Relative Distinguished Name (RDN) attribute values, where they match zero or more characters (similar to substring filters). For example, the bind rule matches the following DNs: uid=bob jensen,dc=example,dc=com and uid=bjensen,dc=example,dc=com:
```
userdn="ldap:///uid=b*jensen*,dc=example,dc=com"
```
It does not match the DN cn=bill jensen,dc=example,dc=com because the attribute type of the first RDN does not match.
A single wildcard can also be used to match any RDN attribute type. (The wildcard in this case can be omitted as a shorthand). For example, these two bind rules behave exactly the same:
```
userdn="ldap:///*=bjensen, dc=example, dc=com"
userdn="ldap:///bjensen, dc=example, dc=com"
```
They both match the following DNs: uid=bjensen,dc=example,dc=com and cn=bjensen,dc=example,dc=com.
A single wildcard can be used to match exactly one RDN component, which can be single or multivalued). For example, the following bind rule matches the DNs uid=jensen,dc=example,dc=com and cn=smith,dc=example,dc=com:
```
userdn="ldap:///*,dc=example,dc=com"
```
A double wildcard can be used to match one or more RDN components. For example, the following bind rule matches the DNs uid=jensen,ou=people,dc=example,dc=com and uid=jensen,ou=sales,ou=people,dc=example,dc=com:
```
userdn="ldap:///uid=bjensen,**,dc=example,dc=com"
```

Privilege Subsystem Impact

Oracle Directory Server Enterprise Edition has no support for privileges. The privilege subsystem (discussed in Chapter 6, Directory Server Root Users and the Privilege Subsystem) impacts ACIs in two ways:

Users with ds-privilege-name: bypass-acl privileges can bypass access control evaluation.
Users needing to modify access control rules need the ds-privilege-name: modify-acl privilege.

Note - Use of the Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control requires the bind user to have the ds-privilege-name: proxied-auth privilege. When the proxied authorization control is used, evaluation of the ds-privilege-name: bypass-acl privilege is performed using the bind user, not the proxied user.

In general, a user should not have both the ds-privilege-name: proxied-auth and ds-privilege-name: bypass-acl privileges simultaneously since this allows a proxied user to bypass ACI access evaluation.

The `targetscope` Keyword

The targetscope keyword differs from Oracle Directory Server Enterprise Edition by including a new scope:

subordinate: Restricts the ACI to the subtree below the target resource only.

LDAP Modify Increment

Oracle Unified Directory supports the LDAP Modify-Increment Extension. This extension is not supported in Oracle Directory Server Enterprise Edition. Attributes that are to be incremented must have write permissions.

Macro Support

There is no support for macros in ACIs.

The `roledn` Keyword

Roles are not supported in Oracle Unified Directory, so the roledn keyword should not be used. Equivalent functionality can be achieved by using groups.

Skip Navigation Links
Exit Print View
	Oracle Fusion Middleware Architecture Reference for Oracle Unified Directory 11g Release 1 (11.1.1)