Summary of access control keywords
This section provides an overview of the supported keywords in the server access control implementation.
Targets
A target expression specifies the set of entries and attributes to which an access control rule applies.
A target expression has three components:
- Keyword
-
The keyword specifies the type of target element.
- Expression
-
The expression specifies the items that are targeted by the access control rule.
- Operator
-
The operator is either equal,
=
, or not-equal,!=
.
You cannot use the |
For specific examples of each target keyword, see Working with targets.
(keyword[=\|\|!=]expression)
You can use the following keywords in the target portion of ACIs:
Target Keyword | Description | Wildcards |
---|---|---|
|
Specifies the OIDs for any extended operations to which the access control rule should apply. |
No |
|
Determines whether an access control rule applies to an operation based on whether that operation matches a given request criteria definition. If present in an access control rule, the operator must be either "=" or "!=". The value must be enclosed in quotation marks and it must be the name or full DN of the configuration object that defines the desired request criteria. For example, let’s say that you want to allow members of the dsconfig create-request-criteria \ --criteria-name "Requests Targeting Sales Employees" \ --type simple \ --set "any-included-target-entry-group-dn:cn=Sales Employees,ou=Groups,dc=example,dc=com" With that request criteria defined, you can use a modification like the following to create the corresponding access control rule: dn: dc=example,dc=com changetype: modify add: aci aci: (targetattr="*")(requestcriteria="Requests Targeting Sales Employees")(version 3.0; acl "Allow sales administrators to manage sales employees"; allow (read,search,compare,write) groupdn="ldap:///cn=Sales Administrators,ou=Groups,dc=example,dc=com";) |
|
|
Specifies the set of entries, identified using LDAP URLs, to which the access control rule applies. |
Yes |
|
Identifies specific attribute values based on filters that can be added to or removed from entries to which the access control rule applies. |
Yes |
|
Specifies the set of attributes to which the access control rule should apply. |
Yes |
|
Specifies the OIDs for any request controls to which the access control rule should apply. |
No |
|
Specifies one or more search filters that can be used to indicate the set of entries to which the access control should apply. |
Yes |
|
Specifies the scope of entries, relative to the defined target entries or the entry containing the ACI if there is no target, to which the access control rule should apply. |
No |
Permissions
Permissions indicate the types of operations to which an access control rule could apply.
You can specify if the user or group of users are allowed or not allowed to carry out a specific operation. For example, you can grant read access to targeted entries using the allow (read)
permission. You can also deny access to the target entries and attributes using the deny (read)
permission. You can list multiple permissions as required in the ACI.
allow(permission1...,permission2,...permissionN)
deny(permission1...,permission2,...permissionN)
You can use the following keywords in the permissions portion of ACIs.
Keyword | Description |
---|---|
|
Indicates that the access control applies to |
|
Indicates that the access control applies to |
|
Indicates that the access control applies to |
|
Indicates that the access control applies only to For |
|
See the description for the |
|
Indicates that the access control rule applies to operations that attempt to use an alternate authorization identity, such as operations that include a proxied authorization request control, an intermediate client request control with an alternate authorization identity, or a client that has authenticated with a Simple Authentication and Security Layer (SASL) mechanism that allows an alternate authorization identify to be specified. |
|
Indicates that the access control rule applies to search result entries returned by the server. |
|
Indicates that the access control rule applies to |
|
Indicates that the access control rule applies to operations in which a user attempts to add or remove their own DN to the values for an attribute, such as users adding or removing themselves from groups. |
|
Indicates that the access control rule applies to |
|
An aggregate permission that includes all other permissions except |
Bind rules
The bind rules indicate whether an access control rule should apply to a given requester.
The syntax for the target keyword has three components:
- Keyword
-
The keyword specifies the type of target element.
- Expression
-
The expression specifies the items that are targeted by the access control rule.
- Operator
-
The operator is either equal,
=
, or not-equal,!=
.
You must use the semicolon delimiter symbol, ;
, after the end of the final bind rule.
keyword[=||!=]expression;
For added access control precision, you can combine multiple bind rules using the Boolean operations AND
, OR
, and NOT
. The standard Boolean rules for evaluation apply:
-
Innermost to outer parentheses first
-
Left to right expressions
-
NOT
beforeAND
orOR
For example, an access control instruction (ACI) with the following bind rule targets all users who are not uid=admin,dc=example,dc=com
and use simple authentication.
(userdn!="ldap:///uid=admin,dc=example,dc=com" and authmethod="simple");
The following bind rule targets users that are uid=admin,dc=example,dc=com
and authenticate using Simple Authentication and Security Layer (SASL) EXTERNAL or access the server from a loopback interface.
(userdn="ldap:///uid=admin,dc=example,dc=com and (authmethod="SSL" or ip="127.0.0.1"));
You can use the following keywords in the bind rule portion of ACIs.
Bind Rule Keyword | Description |
---|---|
|
Indicates that the requester’s authentication method is taken into account when determining whether the access control rule should apply to an operation. You cannot use wildcards in this expression. Use the syntax
The following example allows users who authenticate with an SSL/TLS certificate (for example, using SASL EXTERNAL) to update their own entries. aci: (targetattr="*") (version 3.0; acl "Allow users to update their own entries"; allow (write) (userdn="ldap:///self" and authmethod="ssl");) |
|
Allows or denies an operation based on whether the client connection matches a given connection criteria definition. If present in an access control rule, the operator must be either " For example, you can use a modification like the following to allow any client matching the "Root Users and Topology Administrators" connection criteria to have full read and write access to entries below dn: dc=example,dc=com changetype: modify add: aci aci: (targetattr="*")(version 3.0; acl "Full read and write access for administrators"; allow (read,search,compare,write) connectioncriteria="Root Users and Topology Administrators";) |
|
Indicates that the day of the week is taken into account when determining whether the access control rule should apply to an operation. You cannot use wildcards in this expression. You can separate multiple day of week values by commas. Use the following syntax. dayofweek = day1, day2, ... day is one of the following:
The following example allows users who authenticate on weekdays with an SSL/TLS certificate, such as SASL EXTERNAL, to update their own entries. aci: (targetattr="*") (version 3.0; acl "Allow users to update their own entries"; allow (write) (dayofweek!="sun,sat" and userdn="ldap:///self" and authmethod="ssl");) |
|
Indicates that the requester’s DNS-resolvable host name is taken into account when determining whether the access control rule should apply to an operation. You can use wildcards in this expression. You can separate multiple DNS patterns by commas. Use the following syntax. dns = dns-host-name The following example allows users on host name aci: (targetattr="*") (version 3.0; acl "Allow users to update their own entries"; allow (write) (dns="server.example.com" and userdn="ldap:///self");) |
|
Indicates that the requester’s group membership is taken into account when determining whether the access control rule should apply to any operation. You cannot use wildcards in this expression. groupdn [ = || != ] "ldap:///groupdn [ || ldap:///groupdn ] ..." The following example allows users in the managers group to update their own entries. aci: (targetattr="*") (version 3.0; acl "Allow users to update their own entries"; allow (write) (groupdn="ldap:///cn=managers,ou=groups,dc=example,dc=com");) |
|
Indicates that the requester’s IP address is taken into account when determining whether the access control rule should apply to an operation. You can use wildcards in this expression. You can separate multiple IP address patterns by commas. Use the following syntax. ip [ = || != ] <ipAddressList> ipAddressList is one of the following:
The following example allows users on 10.130.10.2 and localhost to update their own entries. aci: (targetattr="*") (version 3.0; acl "Allow users to update their own entries"; allow (write) (ip="10.130.10.2,127.0.0.1" and userdn="ldap:///self");) |
|
Indicates that the scopes associated with any OAuth 2.0 access token presented by a SCIMv2 client is taken into account when determining whether the access control rule applies to an operation. Use the following syntax. oauthscope [ = || != ] "<scopeIdentifier>" scopeIdentifier is one of the following:
The following example grants all rights to any client that presented an OAuth 2.0 token that is associated with the aci: (targetattr="*") (version 3.0; acl "Full rights for users with the scim_admin OAuth 2.0 scope"; allow (all) oauthscope="scim_admin";) |
|
Allows or denies an operation based on whether the client is communicating with the server over a secure connection; for example, using LDAPS or StartTLS over LDAP. If present in an access control rule, the operator must be either "
For example, you can use a modification like the following to allow users below dn: dc=example,dc=com changetype: modify add: aci aci: (targetattr="userPassword")(version 3.0; acl "Allow users to update their own passwords over a secure connection"; allow (write) userdn="ldap:///self" and secure="true";) |
|
Indicates that the time of day is taken into account when determining whether the access control rule should apply to an operation. You cannot use wildcards in this expression. Use the following syntax. timeofday [ = || != || >= || > || <= || < ] <time> time is one of the following:
The following example allows users to update their own entries if the request is received before 12 noon. aci: (targetattr="*") (version 3.0; acl "Allow users who authenticate before noon to update their own entries"; allow (write) (timeofday<1200 and userdn="ldap:///self" and authmethod="simple");) |
|
Indicates that the requester’s relation to the value of the specified attribute is taken into account when determining whether the access control rule should apply to an operation. Use the following syntax. userattr = <attrName># [ <bindType> || <attrValue> ] Where:
A bindType value of Any value other than The following example allows a manager to change employee’s entries. If the bind DN is specified in the manager attribute of the targeted entry, the bind rule is evaluated to aci: (targetattr="*") (version 3.0; acl "Allow a manager to change employee entries"; allow (write) userattr="manager#USERDN";) The following example allows any member of a group to change employee’s entries. If the bind DN is a member of the group specified in the aci: (targetattr="*") (version 3.0; acl "Allow allowEditors to change employee entries"; allow (write) userattr="allowEditors#GROUPDN";) The following example allows a user’s manager to edit that user’s entry and any entries below the user’s entry up to two levels deep. You can specify up to five levels ( aci: (targetattr="*") (version 3.0; acl "Allow managers to change employees entries two levels below"; allow (write) userattr="parent[0,1,2].manager#USERDN";) The following example allows any member of the engineering department to update any other member of the engineering department at or below the specified ACI. aci: (targetattr="*") (version 3.0; acl "Allow any member of Eng Dept to update any other member of the enginering department at or below the ACI"; allow (write) userattr="department#ENGINEERING";) The following example allows an entry to be updated by any user whose entry matches the criteria defined in the LDAP URL contained in the aci: (targetattr="*") (version 3.0; acl "Allow a user that matches the filter to change entries"; allow (write) userattr="allowedEditorCriteria#LDAPURL";) |
|
Indicates that the user’s DN is taken into account when determining whether the access control rule should apply to an operation. Use the following syntax.. userdn [ = || != ] "ldap:///<value> [ || "ldap:///<value> ..."] Where value is one of the following representations:
If the value provided is a DN, then that DN can include wildcard characters to define patterns. A single asterisk will match any content within the associated DN component, and two consecutive asterisks can be used to match zero or more DN components. The following example allows users to update their own entries. aci: (targetattr="*") (version 3.0; acl "Allow users to update their own entries"; allow (write) userdn="ldap:///self";) |