Designing Access Control With ACIs

Access control enables you to specify that certain clients have access to particular information, while other clients do not. You implement access control using one or more access control lists (ACLs). ACLs consist of a series of access control instructions (ACIs) that either allow or deny permissions to specified entries and their attributes. Permissions include the ability to read, write, search, proxy, add, delete, compare, import and export.

By using an ACL, you can set permissions for the following:

• The entire directory

• A particular subtree of the directory

• Specific entries in the directory

• A specific set of entry attributes

• Any entry that matches a given LDAP search filter

In addition, you can set permissions for a specific user, for all users that belong to a group, or for all users of the directory. You can also define access for a network location, such as an IP address or a DNS name.

This section provides an overview of the Directory Server access control mechanism. For detailed information about configuring access control and ACIs, see Chapter 6, Directory Server Access Control, in Oracle Directory Server Enterprise Edition Administration Guide. For information about the architecture of the access control mechanism, see How Directory Server Provides Access Control in Oracle Directory Server Enterprise Edition Reference.

Default ACIs

The default behavior of Directory Server is to deny access unless there is a specific ACI that grants access. therefore, if no ACIs are defined, all access to the server is denied.

When you install Directory Server or when you add a new suffix, several default ACIs are defined automatically in the root DSE. These ACIs can be modified to suit your security requirements.

For details on the default ACIs and how to modify them, see How Directory Server Provides Access Control in Oracle Directory Server Enterprise Edition Reference.

ACI Scope

Starting with 6.x, Directory Server includes two major changes to ACI scope.

• Ability to specify the scope of an ACI. In Directory Server 5.2, you could not specify the scope of an ACI. ACIs automatically applied to the entry that contained the ACI and all of its subtree. Therefore, it was necessary to use deny ACIs in several cases. Deny ACIs can be difficult to manage, particularly when a deny ACI and an allow ACI apply to a single entry.

  Starting with Directory Server 6.x, you can specify the scope of an ACI, that is, you can use allow ACIs to control access. Although, deny-based access control might sometimes be unavoidable or simpler to configure, the use of deny ACIs is generally discouraged. For information about how to specify the scope of an ACI, see Chapter 6, Directory Server Access Control, in Oracle Directory Server Enterprise Edition Administration Guide.

• Root ACIs now apply to the root entry and its entire subtree. In Directory Server 5.2, ACIs located in the root DSE applied to the root entry only and not its children. ACIs placed in any other entry applied to the entry that contained the ACI and all of its subtree. In Directory Server Enterprise Edition ACIs placed in the root entry are treated like ACIs placed anywhere else.

  The new root ACIs have an obvious security advantage. Administrators no longer have to bind as the Directory Manager to perform certain operations. Administrators can now be forced to bind by using strong authentication such as SSL. When configuring ACIs that are intended to apply only to the root entry, the scope of the ACI must now specifically be set to base.

The change in ACI scope has implications for migration. If you are migrating to Directory Server 7.0 from a 5.2 version of Directory Server, see Changes to ACIs in Oracle Directory Server Enterprise Edition Upgrade and Migration Guide.

Obtaining Effective Rights Information

The access control model provided by Directory Server can grant access to users through many different mechanisms. However, this flexibility can make your security policy fairly complex. Several parameters can define the security context of a user, including IP address, machine name, time of day, and authentication method.

To simplify the security policy, Directory Server enables you to request and list the effective access rights that a given user has to specified directory entries and attributes. For more information, see Viewing Effective Rights in Oracle Directory Server Enterprise Edition Administration Guide.

Tips on Using ACIs

The following tips can simplify your directory security model and improve directory performance:

• Minimize the number of ACIs in your directory, and use macro ACIs where possible.

  Although Directory Server can evaluate over 50,000 ACIs, managing a large number of ACI statements can be difficult. Excessive ACIs can also have a negative impact on memory consumption.

• Balance allow and deny permissions.

  The default rule is to deny access to any user who has not been specifically granted access. However, you can reduce the number of ACIs by using one ACI that allows access close to the root of the tree and using a small number of deny ACIs close to the leaf entries. This approach can prevent excessive allow ACIs close to the leaf entries.

• Identify the smallest set of attributes on any given ACI.

  If you allow or deny access to a subset of attributes on an object, determine whether the smallest list is the set of attributes that are allowed or the set of attributes that are denied. Then express your ACI so that you are managing the smallest list.

  For example, the people object class contains dozens of attributes. To allow a user to update just a few attributes, write your ACI so that it allows write access for just those few attributes. To allow a user to update all but one or two attributes, create the ACI so that it denies write access for those one or two attributes.

• Use LDAP search filters cautiously.

  Search filters do not directly name the object for which you are managing access. Search filters can therefore result in unexpected results especially as your directory becomes more complex. If you use search filters in ACIs, run an ldapsearch operation with the same filter. This action will ensure that you know what the results of the changes mean to your directory.

• Do not duplicate ACIs in different parts of your directory tree.

  Look for overlapping ACIs. Imagine that you have an ACI at your directory root point that allows a group write access to the commonName and givenName attributes. Imagine also that you have another ACI that allows the same group write access to just the commonName attribute. In this scenario, consider reworking your ACIs so that only one attribute grants write access for the group.

  As your directory grows more complicated, accidental overlapping of ACIs becomes increasingly common. If you avoid ACI overlap, security management becomes easier and the total number of ACIs in your directory is reduced.

• Name your ACIs.

  While naming ACIs is optional, giving each ACI a short, meaningful name makes managing your security model easier.

• Use standard attributes in user entries to determine access rights.

  As far as possible, use information that is already part of standard user entries to define access rights. If you must create special attributes, consider creating the attributes as part of a role or Class of Service (CoS) definition. For more information about roles and CoS, see Chapter 11, Directory Server Groups and Roles, in Oracle Directory Server Enterprise Edition Reference and Chapter 12, Directory Server Class of Service, in Oracle Directory Server Enterprise Edition Reference.

• Group ACIs as closely together as possible.

  Limit ACI placement to your directory root point and to major directory branch points. If you organize ACIs into groups, the total list of ACIs is easier to manage and the total number of ACIs can be kept to a minimum.

• Avoid using double negatives, such as deny write if the bind DN is not equal to cn=Joe.

  Although this syntax is acceptable to the server, the syntax can be confusing for an administrator.