Skip Navigation Links | |
Exit Print View | |
Oracle Fusion Middleware Architecture Reference for Oracle Unified Directory 11g Release 1 (11.1.1) |
2. The Directory Server Access Control Model
Access Control and Replication
To Target an Entry and Attributes
To Target Entries or Attributes Using LDAP Filters
To Target Attribute Values Using LDAP Filters
To Target a Single Directory Entry
To Specify the Scope of an ACI
To Target LDAP Extended Operations
Rights Required for LDAP Operations
Defining User Access (userdn Keyword)
Defining General Access (all Keyword)
Defining Anonymous Access (anyone Keyword)
Defining Self Access (self Keyword)
Defining Parent Access (parent Keyword)
Specifying Users With LDAP URLs
Specifying Users With Wildcards
Specifying Users With a Logical OR of LDAP URLs
Defining Group Access (groupdn Keyword)
Specifying a Group With a Single LDAP URL
Specifying a Group With a Logical OR of LDAP URLs
Defining Access Based on Value Matching (userattr Keyword)
Defining Access From a Specific IP Address (ip Keyword)
Defining Access From a Specific Domain (dns Keyword)
Defining Access at a Specific Time of Day or Day of Week (timeofday and dayofweek Keywords)
Defining Access Based on Authentication Method (authmethod Keyword)
Authentication Method Examples
Defining Access Based on a Connection's Security Strength Factor (ssf Keyword)
DIGEST-MD5 QOP Key Size Mapping
Compatibility With the Oracle Directory Server Enterprise Edition Access Control Model
All Attributes targetattr Rule (targetattr="*")
3. Understanding the Directory Server Schema
4. Directory Server Index Databases
5. Directory Server Replication
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 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.
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 || *").
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"
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 differs from Oracle Directory Server Enterprise Edition by including a new scope:
Restricts the ACI to the subtree below the target resource only.
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.
There is no support for macros in ACIs.
Roles are not supported in Oracle Unified Directory, so the roledn keyword should not be used. Equivalent functionality can be achieved by using groups.