Skip Headers

Oracle Internet Directory Administrator's Guide
Release 9.0.2

Part Number A95192-01
Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Go to previous page Go to next page

13
Directory Access Control

This chapter provides an overview of access control policies and describes how to administer directory access control by using either Oracle Directory Manager or the command-line tool, ldapmodify.

This chapter contains these topics:

Overview of Access Control Policy Administration

You manage access control policies by configuring the values of the ACI attributes within appropriate entries. You can do this by using either Oracle Directory Manager or ldapmodify.

This section contains these topics:

Access Control Management Constructs

This section discusses the structures used for access control in Oracle Internet Directory. These include:

Access Control Policy Points (ACPs)

ACPs are entries in which the orclACI attribute has been given a value. The orclACI attribute value represents the access policies that are inherited by the subtree of entries starting with the ACP as the root of the subtree.

When a hierarchy of multiple ACPs exists in a directory subtree, a subordinate entry in that subtree inherits the access policies from all of the superior ACPs. The resulting policy is an aggregation of the policies within the ACP hierarchy above the entry.

For example, if an ACP is established in the HR department entry, and the Benefits, Payroll, and Insurance groups are entries within the HR department, then any entry within those groups inherits the access rights specified in the HR department entry.

When there are conflicting policies within a hierarchy of ACPs, the directory applies well-defined precedence rules in evaluating the aggregate policy.

See Also:

"How ACL Evaluation Works"

The orclACI Attribute for Prescriptive Access Control

The orclACI attribute contains access control list (ACL) directives that are prescriptive--that is, these directives apply to all entries in the subtree below the ACP where this attribute is defined. Any entry in the directory can contain values for this attribute. Access to this attribute itself is controlled in the same way as access to any other attribute.


Note:

It is possible to represent ACL directives specific to a single entry in the orclACI attribute. However, in such scenarios, for administrative convenience and performance advantages, Oracle Corporation recommends using orclEntryLevelACI--discussed in "The orclEntryLevelACI Attribute for Entry-Level Access Control". This is because the LDAP operational overhead increases with the number of directives represented through orclACI. You can reduce this overhead by moving entry specific directives from orclACI to orclEntryLevelACI.


The orclEntryLevelACI Attribute for Entry-Level Access Control

When a policy pertains only to a specific entity--for example, a special user--you can maintain, within a single entry, the ACL directives specific to that entry. Oracle Internet Directory enables you to do this through a user-modifiable operational attribute called orclEntryLevelACI. The orclEntryLevelACI attribute contains ACL directives that apply to only the entry with which it is associated.

Any directory entry can optionally carry a value for this attribute. This is because Oracle Internet Directory extends the abstract class top to include orclEntryLevelACI as an optional attribute.

The orclEntryLevelACI attribute is multi-valued and has a structure similar to that of orclACI. The structure definition is provided later in this chapter.

Access Control Groups

Group entries in Oracle Internet Directory are associated with either the groupOfNames or the groupOfUniqueNames object class. Membership in the group is specified as a value of the member or uniqueMember attribute respectively.

To specify access rights for a group of people or entities, you identify them in access control groups. There are two types of access control groups: ACP groups and privilege groups.

ACP groups

If an individual is a member of an ACP group, then the directory server simply grants to that individual the privileges associated with that ACP group.

Use ACP groups to resolve access at the level of an ACP. For example, suppose you want to give to several hundred users access to browse an entry. You could assign the browse privilege to each entry individually, but this could require considerable administrative overhead. Moreover, if you later decide to change that privilege, you would have to modify each entry individually. A more efficient solution is to assign the privilege collectively. To do this, you create a group entry, designate it as an ACP group, assign the desired privilege to that group, then assign users as members of that group. If you later change the access rights, you need to do it in one place, for the group, rather than for each individual user. Similarly, you can remove that privilege from multiple users by removing them from the group, rather than having to access multiple individual entries.

ACP groups are associated with the orclacpgroup object class.

Privilege groups

A privilege group is a higher-level access group. It is similar to an ACP group in that it lists users with similar rights. However, it also provides for additional checking beyond a single ACP, as follows: if an ACP denies access, an attribute in the user's entry tells the directory server whether the user being denied is in any privilege group. If so, then this user has additional rights at a higher administration level, and all higher administration levels in the DIT are checked. If the directory server finds a higher ACP that grants to the privilege group access to the requested object, then it overrides the denials by the subordinate ACP, and grants access to the user.

Normally, you would implement only ACP groups. The additional checking that privilege groups provide can degrade performance. Use privilege groups only when access control at higher levels needs the right to override standard controls at lower levels.

Use privilege groups to grant access to administrators who are not recognized by ACPs lower in the DIT. For example, suppose that the global administrator in a hosted environment must perform operations in a subscriber's subtree. Because the global administrator's identity is not recognized in the subscriber subtree, the directory server, relying only on the ACPs in that subtree, denies the necessary access. However, if the global administrator is a member of a privilege group, then the directory server looks higher in the DIT for an ACP that grants this privilege group access rights to that subtree. If it finds such an ACP, then the directory server overrides the denials by ACPs in the subscriber's subtree.

Privilege groups are associated with the orclPrivilegeGroup object class

Users in Both Types of Groups

If a user is a member of both an ACP group and a privilege group, then the directory server performs an evaluation for each type of group. It resolves access rights for the privilege group by looking to ACPs higher in the DIT.

Overview: Granting Access Rights to a Group

To grant access rights to a group of users, you:

  1. Create a group entry in the usual way.

  2. Associate the group entry with either the orclPrivilegeGroup object class or the orclACPgroup object class.

  3. Specify the access policies for that group.

  4. Assign members to the group.

How the Directory Server Computes Access Control Group Membership

Entries can have either direct memberships in groups, or indirect memberships in other ACP or privilege groups by means of nested groups, thus forming a forest of privilege groups. Access policies specified at a given level are applicable to all the members directly or indirectly below that level.

Because Oracle Internet Directory evaluates for access control purposes only access control groups, it does not allow setting access policies for other types of groups. When a user binds with a specific distinguished name (DN), Oracle Internet Directory computes the user's direct membership in access control groups. Once it knows the first level groups for the given DN, Oracle Internet Directory computes nesting of all these first level groups into other access control groups. This process continues until there are no more nested groups to be evaluated.

Each access control group, nested or otherwise, must be associated with an access control group object class--either orclACPgroup or orclPrivilegeGroup. Even if a group is a member of an access control group, the directory server does not consider it for access control purposes unless it is associated with an access control group object class. When it has determined the user's membership in access control groups, the directory server uses that information for the lifetime of the session.

Example: Computing Access Control Group Membership

For example, consider the following group of entries, each of which, with the exception of group4, is marked as a privilege group (objectclass:orclprivilegegroup). You can set access control policies that apply to the members of group1, group2, and group3.

Text description of accessa.gif follows
Text description of the illustration accessa.gif

Group cn=group3,c=us contains the following nested groups:

Access control policies for group3 are applicable to members of group3, group1, and group2 because each of them is marked as a privilege group. These same access control policies are not applicable to the members of group4 because group4 is not marked as a privilege group.

For example, suppose that the user binds to Oracle Internet Directory as a member of group 4 with the DN cn=john smith,c=uk. None of the access policies applicable to the members of group3 will apply to this user. This is because his only direct membership is to a non-privilege group. By contrast, if the user were to bind as cn=john smith,c=us--that is, as a member of group1 and group2--then his access rights will be governed by access policies set up for members of group1, group2, as well as group3 (in which group1 and group2 are nested). This is because all three groups are associated with the object class orclPrivilegeGroup.

Access Control Information Components

Access control information represents the permissions that various entities or subjects have to perform operations on a given object in the directory. Thus, an ACI consists of three components:

Object: To What Are You Granting Access?

The object part of the access control directive determines the entries and attributes to which the access control applies. It can be either an entry or an attribute.

Entry objects associated with an ACI are implicitly identified by the entry or the subtree where the ACI itself is defined. Any further qualification of objects at the level of attributes is specified explicitly in the ACL expressions.

In the orclACI attribute, the entry DN component of the object of the ACI is implicitly that of all entries within the subtree starting with the ACP as its topmost entry. For example, if dc=com is an ACP, then the directory area governed by its ACI is:

.*, dc=com.

However, since the directory area is implicit, the DN component is neither required nor syntactically allowed.

In the orclEntryLevelACI attribute, the entry DN component of the object of the ACL is implicitly that of the entry itself. For example, if dc=acme,dc=com has an entry level ACI associated with it, then the entry governed by its ACI is exactly: dc=acme,dc=com. Since it is implicit, the DN component is neither required nor syntactically allowed.

The object portion of the ACL allows entries to be optionally qualified by a filter matching some attribute(s) in the entry:

filter=(ldapFilter)

where ldapFilter is a string representation of an LDAP search filter. The special entry selector * is used to specify all entries.

Attributes within an entry are included in a policy by including a comma-separated list of attribute names in the object selector.

attr=(attribute_list)

Attributes within an entry are excluded from a policy by including a comma-separated list of attribute names in the object selector.

attr!=(attribute_list)


Note:

Access to the entry itself must be granted or denied by using the special object keyword ENTRY. Note that giving access to an attribute is not enough; access to the entry itself through the ENTRY keyword is necessary.


See Also:

Appendix B, "The Access Control Directive Format" for information about the format or syntax of ACIs

Subject: To Whom Are You Granting Access?

This section describes:

Entity

Access is granted to entities, not entries. The entity component identifies the entity or entities being granted access.

You can specify entities either directly or indirectly.

Directly specifying an entity--This method involves entering the actual value of the entity--for example group=managers. You can do this by using:

Indirectly specifying an entity--This is a dynamic way of specifying entities. It involves specifying a DN-valued attribute that is part of the entry to which you are granting access. There are three types of DN-valued attributes:

For example, suppose you want to specify that Anne Smith's manager can modify the salary attribute in her entry. Instead of specifying the manager DN directly, you specify the DN-valued attribute: dnattr=<manager>. Then, when John Doe seeks to modify Anne's salary attribute, the directory server:

Bind Mode

The bind mode specifies the method of authentication to be used by the subject. There are four modes:

Specifying the bind mode is optional. The directory server verifies that the bind mode of the user is compatible with that of the node with which the user is trying to communicate. The bind mode specified on one node must be compatible with that specified on the node with which it is communicating. For example, if you specify SSLTwoway authentication on one node, then the other node must also be configured for this type of authentication.

Added-Object-Constraint

When a parent entry has add access, it can add objects as entries lower in the hierarchy. The added-object-constraint can be used to limit that right by specifying an ldapfilter. (See Appendix B, "The Access Control Directive Format" and Appendix G, "The LDAP Filter Definition".)

Operations: What Access Are You Granting?

The kind of access granted can be one of the following:

Note that each access level can be independently granted or denied. The noxxx means xxx permission is denied.

Note that some access permissions are associated with entries and others with attributes.

Access Level Description Type of Object

Compare

Right to perform compare operation on the attribute value

Attributes

Read

Right to read attribute values. Even if read permission is available for an attribute, it cannot be returned unless there is browse permission on the entry itself.

Attributes

Search

Right to use an attribute in a search filter

Attributes

Selfwrite

Right to add oneself to, delete oneself from, or modify one's own entry in a list of DNs group entry attribute. Use this to allow members to maintain themselves on lists. For example, the following command allows people within a group to add or remove only their own DN from the member attribute:

access to attr=(member) by dnattr=(member) (selfwrite)

The dnattr selector indicates that the access applies to entities listed in the member attribute. The selfwrite access selector indicates that such members can add or delete only their own DN from the attribute.

Attributes

Write

Right to modify/add/delete the attributes of an entry.

Attributes

None

No access rights. The effect of granting no access rights to a subject-object pair is to make the directory appear to the subject as though the object were not present in the directory.

Both entries and attributes

Add

Right to add entries under a target directory entry

Entries

Browse

Permission to return the DNs in the search result. It is equivalent to the list permission in X.500. This permission is also required for a client to use an entry DN as the base DN in an ldapsearch operation.

Entries

Delete

Right to delete the target entry

Entries

The entry level access directives are distinguished by the keyword ENTRY in the object component.


Note:

The default access control policy grants the following to both entries and attributes: Everyone is given access to read, search, write, and compare all attributes in an entry, and selfwrite permissions are unspecified. If an entry is unspecified, access is determined at the next highest level in which access is specified.


Managing Access Control by Using Oracle Directory Manager

You can view and modify access control information within ACPs by using either Oracle Directory Manager or command-line tools. This section explains how to accomplish these tasks by using Oracle Directory Manager.


Note:

Immediately after installing Oracle Internet Directory, be sure to reset the default security configuration as described in "Task 3: Reset the Default Security Configuration"


This section contains these topics:

Configuring Oracle Directory Manager for Access Control Management

You can configure how Oracle Directory Manager displays ACPs, and how it performs searches for ACPs.

Configuring the Display of ACPs in Oracle Directory Manager

Oracle Directory Manager enables you to determine whether the navigator pane displays all ACPs automatically or only as the result of a search. If you have a large number of ACPs, you may want to display them only as the result of a search.

To configure the display of ACPs:

  1. In the navigator pane, expand Oracle Internet Directory Servers and select the server you want to configure.

  2. On the toolbar, click User Preferences. The User Preferences dialog box appears.

  3. Select the Configure Access Control Policy Management tab page.

  4. Select either:

    • Always display all ACPs

    • Only display ACPs based on search request

  5. Click OK.


    Note:

    To effect your changes, you must restart Oracle Directory Manager.


Configuring Searches for ACPs When Using Oracle Directory Manager

For ACP searches, Oracle Directory Manager enables you to specify:

To configure searches for ACP entries:

  1. In the navigator pane, expand Oracle Internet Directory Servers and select the directory_server_instance.

  2. On the toolbar, choose User Preferences. The User Preferences dialog box appears.

  3. Select the Configure Entry Management tab.

  4. In the field labeled Maximum number of one-level subtree entries, enter the number of entries you want ACP searches to retrieve.

  5. In the Search Time Limit field, enter the maximum number of seconds for the duration of the search.

  6. Click OK.

Viewing an ACP by Using Oracle Directory Manager

If you configured Oracle Directory Manager always to display ACPs, as described in "Configuring the Display of ACPs in Oracle Directory Manager", then you can locate and view an ACP as follows:

  1. In the navigator pane, expand Oracle Internet Directory Servers >
    directory_server_instance > Access Control Management. All of the defined ACPs appear both below Access Control Management in the navigator pane.

  2. In the navigator pane, under Access Control Management, select an ACP to display its information in the right pane.

The three fields in the Access Control Management pane are:

Field Description

Path to the Subtree Control Point

Contains the path defined by the ACP. If you have navigated down a tree to this point, the path to this point appears in this field. If you are creating a new ACP, you must enter the path to it here.

Structural Access Items (Entry Level Operations)

Lists access to entries. Items listed in the Structural Access Items box identify an entry by the following categories:

  • By Whom: To whom or what you are granting access (the subject)

  • Bind Mode: Whether bind mode (authentication) is used

  • Access rights: Browse, Add, Proxy, and Delete

See Also: "Task 2: Modify Structural Access Items" for instructions on how to modify structural access items

Content Access Items (Attribute Level Operations)

Lists access to attributes within the entry or entries identified in the Entry Filter column. Columns in this window include:

  • By Whom: To whom or what you are granting access (the subject)

  • Bind Mode: Whether bind mode (authentication) is used

  • Op: The matching operation to be performed against the attribute. Choices are EQ (=) and NEQ (!=)

  • Attribute: The specific attribute to which access is granted or denied (the object)

  • Access rights: Read, Search, Write, Selfwrite, or Compare access

See Also: "Task 3: Modify Content Access Items" for instructions on how to modify content access items.

If you configured Oracle Directory Manager to display ACPs only as the result of a search, as described in "Configuring the Display of ACPs in Oracle Directory Manager", then you can locate and view an ACP as follows:

  1. Expand Oracle Internet Directory Servers > directory_server_instance, then select Entry Management. Perform a search for the entry designated as an ACP. The search result appears in the Distinguished Name box in the lower half of the right pane.

  2. In the Distinguished Name box, double-click the entry. The corresponding Entry dialog box appears.

  3. To view subtree access controls for this ACP, select the Subtree Access tab.

    To view entry level access controls for this ACP, select the Local Access tab.

Adding an ACP by Using Oracle Directory Manager

ACPs are entries that contain prescriptive, that is, inheritable, access control information. This information affects the entry itself and all entries below it. You will most likely create ACPs to broadcast large-scale access control throughout a subtree.

Adding an ACP by using Oracle Directory Manager involves three tasks:

Task 1: Specify the Entry That Will Be the ACP

  1. If you configured Oracle Directory Manager always to display ACPs, as described in "Configuring the Display of ACPs in Oracle Directory Manager", then begin as follows:

    1. In the navigator pane, expand Oracle Internet Directory Servers > directory_server_instance.

    2. Select Access Control Management, and go to step 2.

    If you configured Oracle Directory Manager to display ACPs only as the result of a search, as described in "Configuring the Display of ACPs in Oracle Directory Manager", then begin as follows:

    1. In the navigator pane, expand Oracle Internet Directory Servers > directory_server_instance > Access Control Management.

    2. Select a node where you want the ACP to reside. If there are no ACPs yet configured, then you may select ACPs under "DSE Root".

  2. On the toolbar, click Create. A New Access Control Point dialog box appears.

  3. In the Path to Entry field, enter the distinguished name (DN) of the entry that will be the ACP. You can alternatively find the DN:

    • By clicking Browse to the right of the Path to Entry field.

    • By looking in the navigator pane under Entry Management

Task 2: Configure Structural Access Items

  1. To define structural access items, that is, ACIs that pertain to entries, just below the Structural Access Items window, click Create. The Structural Access Item dialog box appears. It has four tabs: Entry Filter, Added Object Filter, By Whom, and Access Rights.

  2. If you want all entries below the ACP to be governed by the ACP, then you do not need to enter anything on the Entry Filter tab page; simply proceed to the next step.

    In an ACP, the access rights defined apply to the entry and all its subentries unless other filters restrict access further. If appropriate, use the Entry Filters tab page to identify the entries to which you are specifying access.

    You might restrict access to an entry based on one or more of that entry's attributes. For example, you might choose to restrict access to all entries in which the title is manager and in which the organization unit is Americas.

    To identify an entry to which you are specifying access:

    1. From the menu at the left end of the Criteria bar, select an attribute type.

    2. From the menu in the middle of the bar, select one of the following filter options:

      Filter Description

      Begins With

      Searches by using only the first few characters of the attribute value

      Ends With

      Searches for an entry by using only the last few characters of the specified attribute value

      Contains

      Searches for an entry in which the attribute you specified includes, but is not necessarily limited to, the value you enter

      Exact Match

      Searches for an entry whose specified attribute is the same as the value you enter

      Greater or Equal

      Searches for an entry in which the specified attribute is numerically or alphabetically greater than or equal to the value you enter. An entry is alphabetically greater if it is closer to the beginning of the alphabet.

      Less or Equal

      Searches for entries in which the specified attribute is numerically or alphabetically less than or equal to the value you enter. An entry is alphabetically less if it is closer to the beginning of the alphabet.

      Present

      Determines if an entry with the specified attribute is present at that level of the tree. You do not need to enter a value to use this relationship. For example, the phrase cn Present retrieves all entries with a cn attribute value at that level of the tree.

    3. In the text box at the right end of the search criteria bar, type the value for the attribute you selected.

  3. Select the Added Object Filter tab page.

    You can specify ACIs to restrict the kind of entries a user can add. For example, you can specify an ACI in the DSE root entry that allows users to add only entries with objectclass=country. The directory server then verifies that any new entry complies with the constraints in this filter.

    To restrict the kind of entries a user can add:

    1. From the menu at the left end of the Criteria bar, select an attribute type.

    2. From the menu in the middle of the bar, select one of the following filter options:

      Filter Description

      Begins With

      Searches by using only the first few characters of the attribute value

      Ends With

      Searches for an entry by using only the last few characters of the specified attribute value

      Contains

      Searches for an entry in which the attribute you specified includes, but is not necessarily limited to, the value you enter

      Exact Match

      Searches for an entry whose specified attribute is the same as the value you enter

      Greater or Equal

      Searches for an entry in which the specified attribute is numerically or alphabetically greater than or equal to the value you enter. An entry is alphabetically greater if it is closer to the beginning of the alphabet.

      Less or Equal

      Searches for entries in which the specified attribute is numerically or alphabetically less than or equal to the value you enter. An entry is alphabetically less if it is closer to the beginning of the alphabet.

      Present

      Determines if an entry with the specified attribute is present at that level of the tree. You do not need to enter a value to use this relationship. For example, the phrase cn Present retrieves all entries with a cn attribute value at that level of the tree.

    3. In the text box at the right end of the search criteria bar, type the value for the attribute you selected.

  4. Select the By Whom tab page.

    1. From the Bind Mode list, select the type of authentication to be used by the subject (that is, the entity that seeks access). There are five bind modes from which to select:

      Bind Mode Description

      None

      No authentication

      SSL No Authentication

      Neither the client nor the server authenticates itself to the other. No certificates are sent or exchanged. In this case, only SSL encryption/decryption is used.

      SSL One Way

      Only the directory server authenticates itself to the client. The directory server sends the client a certificate verifying that the server is authentic.

      SSL Two Way

      Both client and server authenticate themselves to each other. They do this by sending certificates to each other.

      Simple

      The client identifies itself to the server by means of a DN and a password which are sent in the clear over the network. The server verifies that the DN and password sent by the client matches the DN and password stored in the directory.

      The bind mode is optional in subject specification. If you do not set an authentication method, any kind of authentication is accepted. The bind mode specified on one node should match the bind mode specified on the node with which it is communicating.

    2. Specify the entity or entities to whom you are granting access.

      Entity Description

      Everyone (*)

      All who try to access the entry

      A Specific Group

      A previously defined group name

      A Specific Entry

      A previously defined directory entry

      A Subtree

      An entire subtree in the directory, which you select

      When Session User's Distinguished Name (DN) Is Identified by Attribute

      Anyone whose DN is an attribute in the entry. For example, you might want to grant read access to a group entry to members of the group.

      When Session User's Unique ID (orclGUID) Is Identified by Attribute

      The global user identifier (orclGUID) of the entry to which you want to grant or deny access for this entry

      When Session User's Distinguished Name (DN) Matches the Accessed Entry

      Anyone who has correctly logged in as the entry specified

  5. Select the Access Rights tab page.

    1. Specify what kinds of rights are granted:

      • Browse--Allows the subject to see the entry

      • Add--Allows the subject to add other entries below this entry

      • Delete--Allows the subject to delete the entry

      • Proxy--Allows the subject to impersonate another user

    2. Click OK.

Task 3: Configure Content Access Items

  1. To define content access items, that is, ACIs that pertain to attributes, just below the Content Access Items window, click Create. The Content Access Item dialog box appears. Each tab page contains items you can modify.

  2. If you want all entries below the ACP to be governed by the ACP, then you do not need to enter anything on Entry Filter tab page; simply proceed to the next step.

    In an ACP, the access rights defined apply to the entry and all its subentries unless other filters restrict access further. If appropriate, use the Entry Filters tab page to identify the entries to which you are specifying access.

    You might restrict access to an entry based on one or more of that entry's attributes. For example, you might choose to restrict access to all entries in which the title is manager and in which the organization unit is Americas.

    To identify an entry to which you are specifying access:

    1. From the menu at the left end of the Criteria bar, select an attribute type.

    2. From the menu in the middle of the bar, select one of the following filter options:

      Filter Description

      Begins With

      Searches by using only the first few characters of the attribute value

      Ends With

      Searches for an entry by using only the last few characters of the specified attribute value

      Contains

      Searches for an entry in which the attribute you specified includes, but is not necessarily limited to, the value you enter

      Exact Match

      Searches for an entry whose specified attribute is the same as the value you enter

      Greater or Equal

      Searches for an entry in which the specified attribute is numerically or alphabetically greater than or equal to the value you enter. An entry is alphabetically greater if it is closer to the beginning of the alphabet.

      Less or Equal

      Searches for entries in which the specified attribute is numerically or alphabetically less than or equal to the value you enter. An entry is alphabetically less if it is closer to the beginning of the alphabet.

      Present

      Determines if an entry with the specified attribute is present at that level of the tree. You do not need to enter a value to use this relationship. For example, the phrase cn Present retrieves all entries with a cn attribute value at that level of the tree.

    3. In the text box at the right end of the search criteria bar, type the value for the attribute you selected.

  3. Select the By Whom tab page.

    1. From the Bind Mode list, select the type of authentication to be used by the subject (that is, the entity that seeks access). There are five bind modes from which to select:

      Bind Mode Description

      None

      No authentication

      SSL No Authentication

      Neither the client nor the server authenticates itself to the other. No certificates are sent or exchanged. In this case, only SSL encryption/decryption is used.

      SSL One Way

      Only the directory server authenticates itself to the client. The directory server sends the client a certificate verifying that the server is authentic.

      SSL Two Way

      Both client and server authenticate themselves to each other. They do this by sending certificates to each other.

      Simple

      The client identifies itself to the server by means of a DN and a password which are sent in the clear over the network. The server verifies that the DN and password sent by the client matches the DN and password stored in the directory.

      The bind mode is optional in subject specification. If you do not set an authentication method, any kind of authentication is accepted. The bind mode specified on one node should match the bind mode specified on the node with which it is communicating.

    2. Specify the entity or entities to whom you are granting access.

      Entity Description

      Everyone (*)

      All who try to access the entry

      A Specific Group

      A previously defined group name

      A Specific Entry

      A previously defined directory entry

      A Subtree

      An entire subtree in the directory, which you select

      When Session User's Distinguished Name (DN) Is Identified by Attribute

      Anyone whose DN is an attribute in the entry. For example, you might want to grant read access to a group entry to members of the group.

      When Session User's Unique ID (orclGUID) Is Identified by Attribute

      The global user identifier (orclGUID) of the entry to which you want to grant or deny access for this entry

      When Session User's Distinguished Name (DN) Matches the Accessed Entry

      Anyone who has correctly logged in as the entry specified

  4. Select the Attribute tab page.

    1. From the right menu, select the attribute to which you want to grant or deny access.

    2. From the left menu, select the matching operation to be performed against the attribute. Choices are EQ (Equal (=)) and NEQ (Not Equal (!=)).

      For example, if you select EQ and cn, then the access rights you grant apply to the cn attribute. If you select NEQ and cn, then the access rights you grant do not apply to the cn attribute.

  5. Select the Access Rights tab page and specify the items as described in Table 13-1.

    Table 13-1 Access Rights for Attributes
    Access Right Description

    Read

    Right to read attribute values. Even if read permission is available for an attribute, it cannot be returned unless there is browse permission on the entry itself.

    Search

    Right to use an attribute in a search filter

    Write

    Right to modify/add/delete the attributes of an entry.

    Selfwrite

    Right to add oneself to, delete oneself from, or modify one's own entry in a list of DNs group entry attribute. Use this to allow members to maintain themselves on lists. For example, the following command allows people within a group to add or remove only their own DN from the member attribute:

    access to attr=(member) by dnattr=(member) (selfwrite)
    

    The dnattr selector indicates that the access applies to entities listed in the member attribute. The selfwrite access selector indicates that such members can add or delete only their own DN from the attribute.

    Compare

    Right to perform compare operation on the attribute value

  6. Click OK to close this dialog box and return to the main Oracle Directory Manager dialog box.

Adding an ACP by Using the ACP Creation Wizard of Oracle Directory Manager

The ACP Creation Wizard guides you through the tasks involved in adding an ACP. These tasks are:

Task 1: Specify the Entry That Will Be the ACP

  1. If you configured Oracle Directory Manager always to display ACPs, as described in "Configuring the Display of ACPs in Oracle Directory Manager", then begin as follows:

    1. In the navigator pane, expand Oracle Internet Directory Servers > directory_server_instance.

    2. In the navigator pane, select Access Control Management, and go to step 2.

    If you configured Oracle Directory Manager to display ACPs only as the result of a search, as described in "Configuring the Display of ACPs in Oracle Directory Manager", then begin as follows:

    1. In the navigator pane, expand Oracle Internet Directory Servers > directory_server_instance > Access Control Management.

    2. In the navigator pane, select a node where you want the ACP to reside. If there are no ACPs yet configured, you may select ACPs under "DSE Root".

  2. On the toolbar, click Create. A New Access Control Point dialog box appears.

  3. In the Path to Entry field, enter the distinguished name (DN) of the entry that will be the ACP. You can alternatively find the DN by looking in the navigator pane under Entry Management or by clicking Browse.

Task 2: Configure Structural Access Items by Using the ACP Creation Wizard

  1. To define structural access items, that is, ACIs that pertain to entries, just below the Structural Access Items window, click Create via Wizard. The first Structural Access Item dialog box appears.

    In an ACP, the access rights defined apply either to the entry and all its subentries or to a specific entry only. The next sections tell you how to configure an ACP for either option.

    If you specify prescriptive structural access items, then all entries below the ACP are governed by that ACP. If you want prescriptive structural access items, then you do not need to enter anything on this first Structural Access Item dialog box.

  2. To identify an entry to which you are specifying access:

    1. From the menu at the left end of the Criteria bar, select an attribute type.

    2. From the menu in the middle of the bar, select one of the following filter options:

      Filter Description

      Begins With

      Searches by using only the first few characters of the attribute value

      Ends With

      Searches for an entry by using only the last few characters of the specified attribute value

      Contains

      Searches for an entry in which the attribute you specified includes, but is not necessarily limited to, the value you enter

      Exact Match

      Searches for an entry whose specified attribute is the same as the value you enter

      Greater or Equal

      Searches for an entry in which the specified attribute is numerically or alphabetically greater than or equal to the value you enter. An entry is alphabetically greater if it is closer to the beginning of the alphabet.

      Less or Equal

      Searches for entries in which the specified attribute is numerically or alphabetically less than or equal to the value you enter. An entry is alphabetically less if it is closer to the beginning of the alphabet.

      Present

      Determines if an entry with the specified attribute is present at that level of the tree. You do not need to enter a value to use this relationship. For example, the phrase cn Present retrieves all entries with a cn attribute value at that level of the tree.

    3. In the text box at the right end of the search criteria bar, type the value for the attribute you selected.

    4. Click Next. A second Structural Access Item dialog box prompts you to specify any ACI's to restrict the kind of entries a user can add.

  3. You can specify ACIs to restrict the kind of entries a user can add. For example, you can specify an ACI in the DSE root entry that allows users to add only entries with objectclass=country. The directory server then verifies that any new entry complies with the constraints in this filter.

    To restrict the kind of entries a user can add:

    1. From the menu at the left end of the Criteria bar, select an attribute type.

    2. From the menu in the middle of the bar, select one of the following filter options:

      Filter Description

      Begins With

      Searches by using only the first few characters of the attribute value

      Ends With

      Searches for an entry by using only the last few characters of the specified attribute value

      Contains

      Searches for an entry in which the attribute you specified includes, but is not necessarily limited to, the value you enter

      Exact Match

      Searches for an entry whose specified attribute is the same as the value you enter

      Greater or Equal

      Searches for an entry in which the specified attribute is numerically or alphabetically greater than or equal to the value you enter. An entry is alphabetically greater if it is closer to the beginning of the alphabet.

      Less or Equal

      Searches for entries in which the specified attribute is numerically or alphabetically less than or equal to the value you enter. An entry is alphabetically less if it is closer to the beginning of the alphabet.

      Present

      Determines if an entry with the specified attribute is present at that level of the tree. You do not need to enter a value to use this relationship. For example, the phrase cn Present retrieves all entries with a cn attribute value at that level of the tree.

    3. In the text box at the right end of the search criteria bar, type the value for the attribute you selected.

    4. Choose Next. The wizard prompts you to specify the type of authentication, called the bind mode, and the subject to whom you are granting access.

  4. The bind mode is optional in subject specification. If you do not set an authentication method, or choose None, any kind of authentication is accepted. The bind mode specified on one node should match the bind mode specified on the node with which it is communicating.

    1. To specify the type of authentication, or bind mode, from the Bind Mode list, select the type of authentication to be used by the subject (that is, the entity that seeks access). There are five bind modes from which to select:

    2. To specify the entity or entities to whom you are granting access, select one of the following.

      Entity Description

      Everyone (*)

      All who try to access the entry

      A Specific Group

      A previously defined group name

      A Specific Entry

      A previously defined directory entry

      A Subtree

      An entire subtree in the directory, which you select

      When Session User's Distinguished Name (DN) Is Identified by Attribute

      Anyone whose DN is an attribute in the entry. For example, you might want to grant read access to a group entry to members of the group.

      When Session User's Unique ID (orclGUID) Is Identified by Attribute

      The global user identifier (orclGUID) of the entry to which you want to grant or deny access for this entry

      When Session User's Distinguished Name (DN) Matches the Accessed Entry

      Anyone who has correctly logged in as the entry specified

  5. Click Next. A Structural Access Item dialog box prompts you for access rights information. Specify what kinds of rights are granted:

    • Browse: Allows the subject to see the entry

    • Add: Allows the subject to add other entries below this entry

    • Delete: Allows the subject to delete the entry

    • Proxy: Allows impersonating an entity without providing its password

  6. Click Finish.

Task 3: Configure Content Access Items by Using the ACP Creation Wizard

To define content access items, that is, ACIs that pertain to attributes, just below the Content Access Items window, click Create via Wizard. The first Content Access Item dialog box appears.

If you specify prescriptive content access items, then all entries below the ACP are governed by that ACP. If you want prescriptive content access items, then you do not need to enter anything on this first Content Access Item dialog box.

  1. To identify an attribute to which you are specifying access:

    1. From the menu at the left end of the Criteria bar, select an attribute type.

    2. From the menu in the middle of the bar, select one of the following filter options:

      Filter Description

      Begins With

      Searches by using only the first few characters of the attribute value

      Ends With

      Searches for an entry by using only the last few characters of the specified attribute value

      Contains

      Searches for an entry in which the attribute you specified includes, but is not necessarily limited to, the value you enter

      Exact Match

      Searches for an entry whose specified attribute is the same as the value you enter

      Greater or Equal

      Searches for an entry in which the specified attribute is numerically or alphabetically greater than or equal to the value you enter. An entry is alphabetically greater if it is closer to the beginning of the alphabet.

      Less or Equal

      Searches for entries in which the specified attribute is numerically or alphabetically less than or equal to the value you enter. An entry is alphabetically less if it is closer to the beginning of the alphabet.

      Present

      Determines if an entry with the specified attribute is present at that level of the tree. You do not need to enter a value to use this relationship. For example, the phrase cn Present retrieves all entries with a cn attribute value at that level of the tree.

    3. In the text box at the right end of the search criteria bar, type the value for the attribute you selected.

    4. Click Next. A second Content Access Item dialog box prompts you to specify to whom you are granting access.

  2. Specify the type of authentication--called bind mode--to be used by the subject (that is, the entity that seeks access).

    The bind mode is optional in subject specification. If you do not set an authentication method, or choose None, any kind of authentication is accepted. The bind mode specified on one node should match the bind mode specified on the node with which it is communicating.

    There are five bind modes from which to select:

    Bind Mode Description

    None

    No authentication

    SSL No Authentication

    Neither the client nor the server authenticates itself to the other. No certificates are sent or exchanged. In this case, only SSL encryption/decryption is used.

    SSL One Way

    Only the directory server authenticates itself to the client. The directory server sends the client a certificate verifying that the server is authentic.

    SSL Two Way

    Both client and server authenticate themselves to each other. They do this by sending certificates to each other.

    Simple

    The client identifies itself to the server by means of a DN and a password which are sent in the clear over the network. The server verifies that the DN and password sent by the client matches the DN and password stored in the directory.

  3. Specify the entity or entities to whom you are granting access.

    Entity Description

    Everyone (*)

    All who try to access the entry

    A Specific Group

    A previously defined group name

    A Specific Entry

    A previously defined directory entry

    A Subtree

    An entire subtree in the directory, which you select

    When Session User's Distinguished Name (DN) Is Identified by Attribute

    Anyone whose DN is an attribute in the entry. For example, you might want to grant read access to a group entry to members of the group.

    When Session User's Unique ID (orclGUID) Is Identified by Attribute

    The global user identifier (orclGUID) of the entry to which you want to grant or deny access for this entry

    When Session User's Distinguished Name (DN) Matches the Accessed Entry

    Anyone who has correctly logged in as the entry specified

  4. Click Next. A Content Access Item dialog box prompts you to select an attribute and the matching operation to be performed against it.

  5. To select an attribute and the matching operation to be performed against it:

    1. In the Attribute field of the Content Access Item dialog box, from the right list, select the attribute to which you want to grant or deny access.

    2. From the left list, select the matching operation to be performed against the attribute. Choices are EQ (Equal (=)) and NEQ (Not Equal (!=)).

    3. Click Next. A Content Access Item dialog box prompts you to specify access rights.

  6. Specify what kinds of rights are granted as described in Table 13-2.
    Table 13-2 Access Rights for Attributes
    Access Right Description

    Read

    Right to read attribute values. Even if read permission is available for an attribute, it cannot be returned unless there is browse permission on the entry itself.

    Search

    Right to use an attribute in a search filter

    Write

    Right to modify/add/delete the attributes of an entry.

    Selfwrite

    Right to add oneself to, delete oneself from, or modify one's own entry in a list of DNs group entry attribute. Use this to allow members to maintain themselves on lists. For example, the following command allows people within a group to add or remove only their own DN from the member attribute:

    access to attr=(member) by dnattr=(member) (selfwrite)
    

    The dnattr selector indicates that the access applies to entities listed in the member attribute. The selfwrite access selector indicates that such members can add or delete only their own DN from the attribute.

    Compare

    Right to perform compare operation on the attribute value

  7. Click Finish.

Modifying an ACP by Using Oracle Directory Manager

Modifying ACPs by using Oracle Directory Manager involves three tasks:

Task 1: Specify the Entry That You Want to Modify

  1. If you configured Oracle Directory Manager always to display ACPs, as described in "Configuring the Display of ACPs in Oracle Directory Manager", then begin as follows:

    1. In the navigator pane, expand Oracle Internet Directory Servers > directory_server_instance > Access Control Management. Select Access Control Management. All of the defined Access Control Policy Points (ACPs) appear in a list below Access Control Management in the navigator pane. They also appear in the right pane.

    2. Under Access Control Management, select the ACP you want to modify. The information for that ACP is displayed in the right pane. Alternatively, you can double-click an ACP in the right pane to display the data in a separate dialog box.

    If you configured Oracle Directory Manager to display ACPs only as the result of a search, as described in "Configuring the Display of ACPs in Oracle Directory Manager", then begin as follows:

    1. In the navigator pane, expand Oracle Internet Directory Servers > directory_server_instance > Access Control Management, and select the ACP you want to modify. The information for that ACP is displayed in the right pane.

    2. Click Edit. The Subtree Access Control Point dialog box appears.

Task 2: Modify Structural Access Items

You can add new structural access items, or modify existing ones.

See Also:

"Task 2: Configure Structural Access Items" for instructions about adding structural access items

To modify structural access items:

  1. In the Structural Access Items window, select the item you want to modify, and, just below the Structural Access Items window, click Edit. The Structural Access Item dialog box appears.

  2. Use the Entry Filters tab page to narrow the set of entries to which you are granting access. If you want all entries below the ACP to be governed by the ACP, proceed to the next step.

    You might choose an entry based on one or more attributes. For example, you might choose to search for all those whose title is secretary, or for all those whose title is manager and whose organization unit is Americas.

    In the Criteria window of the Entry Filters tab page, use the search criteria bar to select an attribute, enter a value for that attribute, and specify a filter for matching the specified attribute with the value you entered. To do this:

    1. From the menu at the left end of the bar, select an attribute.

    2. From the menu in the middle of the bar, select one of the following filter options:

      Filter Description

      Begins With

      Searches by using only the first few characters of the attribute value

      Ends With

      Searches for an entry by using only the last few characters of the specified attribute value

      Contains

      Searches for an entry in which the attribute you specified includes, but is not necessarily limited to, the value you enter

      Exact Match

      Searches for an entry whose specified attribute is the same as the value you enter

      Greater or Equal

      Searches for an entry in which the specified attribute is numerically or alphabetically greater than or equal to the value you enter. An entry is alphabetically greater if it is closer to the beginning of the alphabet.

      Less or Equal

      Searches for entries in which the specified attribute is numerically or alphabetically less than or equal to the value you enter. An entry is alphabetically less if it is closer to the beginning of the alphabet.

      Present

      Determines if an entry with the specified attribute is present at that level of the tree. You do not need to enter a value to use this relationship. For example, the phrase cn Present retrieves all entries with a cn attribute value at that level of the tree.

    3. In the text box at the right end of the search criteria bar, type the value for the attribute you selected.

  3. Use the Added Object Filter tab page to specify ACIs to restrict the kind of entries a user can add. For example, you can specify an ACI in the DSE root entry that allows users to add only entries with objectclass=country. The directory server then verifies that any new entry complies with the constraints in this filter.

    To restrict the kind of entries a user can add:

    1. From the menu at the left end of the Criteria bar, select an attribute type.

    2. From the menu in the middle of the bar, select one of the following filter options:

      Filter Description

      Begins With

      Searches by using only the first few characters of the attribute value

      Ends With

      Searches for an entry by using only the last few characters of the specified attribute value

      Contains

      Searches for an entry in which the attribute you specified includes, but is not necessarily limited to, the value you enter

      Exact Match

      Searches for an entry whose specified attribute is the same as the value you enter

      Greater or Equal

      Searches for an entry in which the specified attribute is numerically or alphabetically greater than or equal to the value you enter. An entry is alphabetically greater if it is closer to the beginning of the alphabet.

      Less or Equal

      Searches for entries in which the specified attribute is numerically or alphabetically less than or equal to the value you enter. An entry is alphabetically less if it is closer to the beginning of the alphabet.

      Present

      Determines if an entry with the specified attribute is present at that level of the tree. You do not need to enter a value to use this relationship. For example, the phrase cn Present retrieves all entries with a cn attribute value at that level of the tree.

    3. In the text box at the right end of the search criteria bar, type the value for the attribute you selected.

  4. Use the By Whom tab page to specify the subject of the ACI (that is, the entity that seeks access).

    1. Specify the type of authentication, called bind mode to be used by the subject. There are five bind modes from which to select:

      Bind Mode Description

      None

      No authentication

      SSL No Authentication

      Neither the client nor the server authenticates itself to the other. No certificates are sent or exchanged. In this case, only SSL encryption/decryption is used.

      SSL One Way

      Only the directory server authenticates itself to the client. The directory server sends the client a certificate verifying that the server is authentic.

      SSL Two Way

      Both client and server authenticate themselves to each other. They do this by sending certificates to each other.

      Simple

      The client identifies itself to the server by means of a DN and a password which are sent in the clear over the network. The server verifies that the DN and password sent by the client matches the DN and password stored in the directory.

      The bind mode is optional in subject specification. For the directive to be applicable, the bind mode specified on one node should match the bind mode specified on the node with which it is communicating.

    2. Specify the entity or entities to whom you are granting access.

      Entity Description

      Everyone (*)

      All who try to access the entry

      A Specific Group

      A previously defined group name

      A Specific Entry

      A previously defined directory entry

      A Subtree

      An entire subtree in the directory, which you select

      When Session User's Distinguished Name (DN) Is Identified by Attribute

      Anyone whose DN is an attribute in the entry. For example, you might want to grant read access to a group entry to members of the group.

      When Session User's Unique ID (orclGUID) Is Identified by Attribute

      The global user identifier (orclGUID) of the entry to which you want to grant or deny access for this entry

      When Session User's Distinguished Name (DN) Matches the Accessed Entry

      Anyone who has correctly logged in as the entry specified

  5. Select the Access Rights tab page.

    1. Determine what kinds of rights are granted: Browse, Add, Delete, or Proxy. If an entry is unspecified, then access is determined at the next highest level in which access is specified.

    2. Click OK.

Task 3: Modify Content Access Items

You can add new content access items, or modify existing ones.

See Also:

"Task 3: Configure Content Access Items" for instructions about adding new content access items

To modify content access items:

  1. In the Content Access Items box, select the content access item you want to modify, then, just below the Content Access Item window, click Edit. The Content Access Items dialog box appears. Each tab page contains items you can modify.

  2. If you want all entries below the ACP to be governed by the ACP, then you do not need to enter anything on Entry Filter tab page; simply proceed to the next step.

    In an ACP, the access rights defined apply to the entry and all its subentries unless other filters restrict access further. If appropriate, use the Entry Filters tab page to identify the entries to which you are specifying access.

    You might restrict access to an entry based on one or more of that entry's attributes. For example, you might choose to restrict access to all entries in which the title is manager and in which the organization unit is Americas.

    To identify an entry to which you are specifying access:

    1. From the menu at the left end of the Criteria bar, select an attribute type.

    2. From the menu in the middle of the bar, select one of the following filter options:

      Filter Description

      Begins With

      Searches by using only the first few characters of the attribute value

      Ends With

      Searches for an entry by using only the last few characters of the specified attribute value

      Contains

      Searches for an entry in which the attribute you specified includes, but is not necessarily limited to, the value you enter

      Exact Match

      Searches for an entry whose specified attribute is the same as the value you enter

      Greater or Equal

      Searches for an entry in which the specified attribute is numerically or alphabetically greater than or equal to the value you enter. An entry is alphabetically greater if it is closer to the beginning of the alphabet.

      Less or Equal

      Searches for entries in which the specified attribute is numerically or alphabetically less than or equal to the value you enter. An entry is alphabetically less if it is closer to the beginning of the alphabet.

      Present

      Determines if an entry with the specified attribute is present at that level of the tree. You do not need to enter a value to use this relationship. For example, the phrase cn Present retrieves all entries with a cn attribute value at that level of the tree.

    3. In the text box at the right end of the search criteria bar, type the value for the attribute you selected.

  3. Select the By Whom tab page.

    1. From the Bind Mode list, select the type of authentication to be used by the subject (that is, the entity that seeks access). There are five bind modes from which to select:

      Bind Mode Description

      None

      No authentication

      SSL No Authentication

      Neither the client nor the server authenticates itself to the other. No certificates are sent or exchanged. In this case, only SSL encryption/decryption is used.

      SSL One Way

      Only the directory server authenticates itself to the client. The directory server sends the client a certificate verifying that the server is authentic.

      SSL Two Way

      Both client and server authenticate themselves to each other. They do this by sending certificates to each other.

      Simple

      The client identifies itself to the server by means of a DN and a password which are sent in the clear over the network. The server verifies that the DN and password sent by the client matches the DN and password stored in the directory.

      The bind mode is optional in subject specification. If you do not set an authentication method, any kind of authentication is accepted. The bind mode specified on one node should match the bind mode specified on the node with which it is communicating.

    2. Specify the entity or entities to whom you are granting access.

      Entity Description

      Everyone (*)

      All who try to access the entry

      A Specific Group

      A previously defined group name

      A Specific Entry

      A previously defined directory entry

      A Subtree

      An entire subtree in the directory, which you select

      When Session User's Distinguished Name (DN) Is Identified by Attribute

      Anyone whose DN is an attribute in the entry. For example, you might want to grant read access to a group entry to members of the group.

      When Session User's Unique ID (orclGUID) Is Identified by Attribute

      The global user identifier (orclGUID) of the entry to which you want to grant or deny access for this entry

      When Session User's Distinguished Name (DN) Matches the Accessed Entry

      Anyone who has correctly logged in as the entry specified

  4. Select the Attribute tab page.

    1. From the right menu, select the attribute to which you want to grant or deny access.

    2. From the left menu, select the matching operation to be performed against the attribute. Choices are EQ (Equal (=)) and NEQ (Not Equal (!=)).

      For example, if you select EQ and cn, then the access rights you grant apply to the cn attribute. If you select NEQ and cn, then the access rights you grant do not apply to the cn attribute.

  5. Select the Access Rights tab page and specify the items as described in Table 13-1

    Table 13-3 Access Rights for Attributes
    Access Right Description

    Read

    Right to read attribute values. Even if read permission is available for an attribute, it cannot be returned unless there is browse permission on the entry itself.

    Search

    Right to use an attribute in a search filter

    Write

    Right to modify/add/delete the attributes of an entry.

    Selfwrite

    Right to add oneself to, delete oneself from, or modify one's own entry in a list of DNs group entry attribute. Use this to allow members to maintain themselves on lists. For example, the following command allows people within a group to add or remove only their own DN from the member attribute:

    access to attr=(member) by dnattr=(member) (selfwrite)
    

    The dnattr selector indicates that the access applies to entities listed in the member attribute. The selfwrite access selector indicates that such members can add or delete only their own DN from the attribute.

    Compare

    Right to perform compare operation on the attribute value

  6. Click OK.

Granting Entry-Level Access by Using Oracle Directory Manager

To grant entry-level access by using Oracle Directory Manager:

  1. In the navigator pane, expand Oracle Internet Directory Servers > directory_server_instance > Entry Management. You may either:

    • Select the entry to display its properties in the right pane

    • Use the search panel to find the entry, then double-click the entry to open the Entry dialog box.

  2. Select the Local Access tab page, then create and edit local ACIs in the Structural Access Item and Content Access Item boxes.

  3. Once you have made the changes, click Apply.


    Note:

    You must click Apply to send the information you just entered to the directory server. If you do not click Apply, the information you just entered is simply held in the Oracle Directory Manager cache.


Example: Managing ACPs by Using Oracle Directory Manager

This example illustrates how to use Oracle Directory Manager to create a new ACP that has ACIs within it. Suppose you are an administrator in a large company, and you want to limit access to user passwords, so that everyone can compare a password, but only the owner of each password, that is, the user, can read the password or modify it.

In this example, we create a new ACP and populate it with four ACIs that set the following permissions:

Create a New ACP

  1. In the navigator pane, expand Oracle Internet Directory Servers > directory_server_instance, and select Access Control Management. A list of ACPs appears in the right pane.

  2. Click Create at the bottom of the right pane. A New Access Control Point dialog box appears.

  3. In the Path to Entry field, enter the DN where you want the ACP. The ACIs within the ACP will apply to all entries below and including that DN.

Configure Structural Access Items

To set the access rights for an entry:

  1. Just below the Structural Access Items box, click Create. A Structural Access Items dialog box appears. It contains three tabs: Entry Filter, By Whom, and Access Rights.

    Because you want the ACIs to apply to all entries under the ACP, do not use the Entry Filter tab page.

  2. Select the By Whom tab page to define the subject of the ACI. From the Bind Mode list, select the authentication mode appropriate to your environment. To create access rights for everyone, select Everyone.

  3. Select the Access Rights tab page. By default, all rights--browse, add, and delete--are granted. Proxy is unspecified.

    1. Change the access rights so that Everyone can browse all entries, but cannot add or delete them.

    2. Click OK.

Configure Content Access Items

The four ACIs in this example use the same structural content item information. They differ only in the content access they allow. The rest of this section describes how to create the content access for the ACIs.

To define the content access items:

  1. Below the Content Access Items box, click Create. The Content Access Items dialog box appears.

    Because you want this ACI to apply to all entries under the ACP, do not use the Entry Filter tab page.

  2. Select the By Whom tab page, select Everyone.

  3. Select the Attribute tab page. This page has two fields. The first has two choices: EQ (equals) and NEQ (not equals). The second sets the attribute.

    Select EQ and select userPassword.

  4. Select the Access Rights tab page. By default, all permissions are granted. Change the permissions so that read, search, write, and compare are denied.

  5. Click OK.

    You have completed one ACI.

Create Another ACI

Create another ACI that allows a user to read, write, search, and compare his own password.

  1. Under the Content Access Items box, click Create. The Content Access Items dialog box appears.

  2. Select the By Whom tab page. Click When Session User's Distinguished Name (DN) Matches the Accessed Entry.

  3. Select the Attribute tab page. This tab page has two lists.The first has two choices: EQ (equals) and NEQ (not equals). The second sets the attribute.

    Select EQ and userPassword.

  4. Select the Access Rights tab page.

    Grant access to read, search, write, and compare. Leave selfwrite unspecified.

  5. Click OK.

You have now created two ACIs. One denies Everyone read, search, write, and compare access to the userPassword attribute. The second allows the owner of the password to read, search, write, and compare that attribute.

Create a Third ACI

The next ACI grants access to Everyone to read, search, and compare all attributes except userPassword. It denies write access.

  1. Under the Content Access Items field, click Create to display the Content Access Items.

  2. Select the By Whom tab page. Select Everyone.

  3. Select the Attribute tab page.

    Select NEQ and userPassword.

    This combination means that any attribute that is not equal to userpassword is the object of the permissions in this ACI.

  4. Select the Access Rights tab page.

    Grant access to read, search, and compare. Deny write access. Leave selfwrite unspecified.

  5. Click OK to apply these permissions and close the dialog box.

Create a Fourth ACI

The next ACI grants access to Self to read, browse, and write all attributes except userpassword. Including this ACI avoids any ambiguity about whether Self has the same access permissions as Everyone to attributes other than userPassword.

  1. Under the Content Access Items field, click Create to display the Content Access Items dialog box.

  2. Select the By Whom tab page.

    Click When Session User's Distinguished Name (DN) Matches the Accessed Entry.

  3. Select the Attribute tab page.

    From the lists, select NEQ and userPassword. This combination means that any attribute that is not equal to userPassword is the object of the permissions in this ACI.

  4. Press the Access Rights tab page.

    Grant access to read, search, and write. Leave Selfwrite unspecified.

  5. Click OK to apply these permissions and close the dialog box.

Consider other access restrictions you might want to implement. Your directory might contain many entries and attributes that should not be available to everyone.

Managing Access Control by Using Command-Line Tools

As described in "Overview of Access Control Policy Administration", directory access control policy information is represented as user-modifiable operational attributes. Hence, you can manage directory access control by using ldapmodify to set and alter values of these attributes. Any tool, including ldapmodify and ldapmodifymt, can be used for this purpose.

To directly edit the ACI, you should understand the format and semantics of the directory representation of the ACI as described in Appendix B, "The Access Control Directive Format".

See Also:

Example: Restricting the Kind of Entry a User Can Add

You can specify ACIs to restrict the kind of entries a user can add. For example, you can specify an ACI in the DSE root entry that allows users to add only entries with objectclass=country. To do this, you use the added_object_constraint filter. The directory server then verifies that any new entry complies with the constraints in this filter.

The following example specifies that:

Example: Setting Up an Inheritable ACP by Using ldapmodify

This example sets up subtree access permissions in an orclACI at the root DSE by using an LDIF file named my_ldif_file. Because this example refers to the orclACI attribute, this access directive governs all the entries in the DIT.

ldapmodify -v -h $1 -D "cn=Directory Manager, o=IMC, c=US" -w "controller" -f 
my_ldif_file

The LDIF file, my_ldif_file, contains the following:

dn:  
changetype: modify
replace: orclaci
orclaci: access to entry 

by dn="cn=directory manager, o=IMC, c=us" (browse, add, delete) 
by * (browse, noadd, nodelete)
orclaci: access to attr=(*)
by dn="cn=directory manager, o=IMC, c=us" (search, read, write, compare) 
by self (search, read, write, compare) 
by * (search, read, nowrite, nocompare)

Example: Setting Up Entry-Level ACIs by Using ldapmodify

This example sets up entry-level access permissions in the orclEntryLevelACI attribute by using an LDIF file named my_ldif_file. Because this example refers to the orclentrylevelACI attribute, this access directive governs only the entry in which it resides.

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -w "controller" 
-f my_ldif_file

The LDIF file, my_ldif_file, contains the following:

dn:  
changetype: modify
replace: orclentrylevelaci
orclentrylevelaci: access to entry 

by dn="cn=directory manager, o=IMC, c=us" (browse, add, delete) 
by * (browse, noadd, nodelete)
orclentrylevelaci: access to attr=(*)
by dn="cn=directory manager, o=IMC, c=us" (search, read, write, compare) 
by * (search, read, nowrite, nocompare)


Note:

In this example, no DN value is specified. This means that this ACI pertains to the root DSE and its attributes only.


Example: Using Wild Cards

This example shows the use of wild cards (*) in the object and subject specifiers. For all entries within the acme.com domain, it grants to everyone browse permission on all entries, as well as read and search permissions on all attributes.

orclACI attribute in the ACP at dc=com

access to entry by * (browse)
access to attr=(*) by * (search, read)

Note that, in order to allow reading the attributes, browse permissions must be granted on the entries in order for read permissions to be granted to the attributes of those entries.

Example: Selecting Entries by DN

This example shows the use of a regular expression to select the entries by DN in two access directives. It grants to everyone read-only access to the address book attributes under dc=acme,dc=com access.

orclACI attribute of dc=acme, dc=com:

access to entry by * (browse) 
access to attr=(cn, telephone, email) by * (search, read) 

orclACI attribute of dc=us, dc=acme, dc=com:

access to entry by * (browse) 
access to attr=(*) by dn=".*,dc=us,dc=acme,dc=com" (search, read) 

Example: Using Attribute and Subject Selectors

This example shows the use of an attribute selector to grant access to a specific attribute, and various subject selectors. The example applies to entries in the dc=us,dc=acme,dc=com subtree. The policy enforced by this ACI can be described as follows:

"orclACI" attribute of "dc=us, dc=acme, dc=com":

access to entry 
by dn="cn=admin, dc=us,dc=acme,dc=com" (browse, add, delete) 
by dn=".*, dc=us,dc=acme,dc=com" (browse) 
by * (none) 

access to attr=(salary) 
by dnattr=(manager) (read, write) 
by self (read) 
by * (none) 

access to attr=(userPassword) 
by self (search, read, write) 
by dn="cn=admin, dc=us,dc=acme,dc=com" (search, read, write) 
by * (compare) 

access to attr=(homePhone) 
by self (search, read, write) 
by * (read) 

access to attr != (salary, userPassword, homePhone) 
by dn="cn=admin, dc=us,dc=acme,dc=com" (compare, search, read, write) 
by * (compare, search, read) 

Example: Granting Read-Only Access

This example gives to everyone read-only access to address book attributes under dc=acme,dc=com. It also extends to everyone read access to all attributes within the dc=us,dc=acme,dc=com subtree only.

orclACI attribute of dc=acme, dc=com:

access to entry by * (browse)
access to attr=(cn, telephone, email) by * (search, read) 

orclACI attribute of dc=us, dc=acme, dc=com:

access to entry by * (browse) 
access to attr=(*) by dn=".*,dc=us,dc=acme,dc=com" (search, read)

Example: Granting Selfwrite Access to Group Entries

This example allows people within the US domain to add or remove only their own name (DN) to or from the member attribute of a particular group entry, for example, a mailing list.

orclEntryLevelACI attribute of the group entry in question:

access to attr=(member) 
by dn=".*, dc=us,dc=acme,dc=com" (selfwrite)

How ACL Evaluation Works

When a user tries to perform an operation on a given object, the directory server determines whether that user has the appropriate access to perform that operation on that object. If the object is an entry, it evaluates the access systematically for the entry and each of its attributes.

Evaluating access to an object--including an attribute of an entry--can involve examining all the ACI directives for that object. This is because of the hierarchical nature of ACPs and the inheritance of policies from superior ACPs to subordinate ACPs.

The directory server first examines the ACI directives in the entry-level ACI, orclEntryLevelACI. It proceeds to the nearest ACP, then considers each superior ACP in succession until the evaluation is complete.

During ACL evaluation, an attribute is said to be in one of the following states:

State Description

Resolved with permission

The required access for the attribute has been granted in the ACI.

Resolved with denial

The required access for the attribute has been explicitly denied in the ACI.

Unresolved

No applicable ACI has yet been encountered for the attribute in question.

In all operations except search, the evaluation stops if:

In this case the operation would fail and the directory server would return an error to the client.

In a search operation, the evaluation continues until all the attributes reach the resolved state. Attributes that are resolved with denial are not returned.

ACL Evaluation Precedence Rules

An LDAP operation requires the BindDN, or subject, of the LDAP session to have certain permissions to perform operations on the objects--including the entry itself and the individual attributes of the entry.

Typically, there could be a hierarchy of access control administration authorities, starting from the root of a naming context down to successive administrative points (or access control policy points). An ACP is any entry which has a defined value for the orclACI attribute. Additionally, the access information specific to a single entry can also be represented within the entry itself (orclEntryLevelACI).

ACL evaluation involves determining whether a subject has sufficient permissions to perform an LDAP operation. Typically an orclentryLevelACI or orclACI might not contain all the necessary information for ACL evaluation. Hence, all available ACL information is processed in a certain order until the evaluation is fully resolved.

That order of processing follows these rules:

Precedence at the Entry Level

ACIs at the entry level are evaluated in the following order:

  1. With a filter. For example:

    access to entry filter=(cn=p*)
    
    by group1 (browse, add, delete)
    
    
  2. Without a filter. For example:

    access to entry
    
    by group1 (browse, add, delete)
    
Precedence at the Attribute Level

At the attribute level, specified ACIs have precedence over unspecified ACIs.

  1. ACIs for specified attributes are evaluated in the following order:

    1. Those with a filter. For example:

      access to attr=(salary) filter=(salary > 10000)
      by group1 (read)
      
      
    2. Those without a filter. For example:

      access to attr=(salary)
      by group1 (search, read)
      
      
  2. ACIs for unspecified attributes are evaluated in the following order:

    1. With a filter. For example:

      access to attr=(*) filter (cn=p*)
      by group1 (read, write)
      
      
    2. Without a filter. For example:

      access to attr=(*)
      by group1 (read, write)
      

More Than One ACI for the Same Object

If there are two or more ACIs at the same ACP for the same object, then only one ACI is checked, and all other ACIs are ignored. For example, suppose you have the following two ACIs at the same ACP for the same entry:

If ACI #2 happens to be checked first, then the access granted specifically to the administrator in ACI #1 is ignored. If an administrator then seeks access to the entry, then that access is not be resolved at this level of the hierarchy. The evaluation must move progressively up the hierarchy in search of resolution. If no resolution is found, all access is denied.

The solution is to create only one ACI at the same ACP for this entry. For example:

access to entry

by dn="cn=admin, dc=us,dc=acme,dc=com" (browse, add, delete)
by dn="cn=manager,dc=us,dc=acme,dc=com" (search, read)

Similarly, at the attribute level, suppose you have the following two ACIs:

If ACI #1 happens to be returned first, then the access granted to self in ACI #2 is ignored. If a user then wishes to change his or her own password, then that access cannot be granted.

As with the ACIs for entries, the solution is to create only one ACI at the same ACP for this attribute. For example:

access to attr=(userpassword)

by dnattr=(".*,dc=us,dc=acme,dc=com) (none)
by self (read, write)

Granting Exclusionary Access to Objects

If an ACI exists for a given object, you can specify access to all other objects except that one. You do this either by granting access to all the objects, or by denying access to the one object.

In the following example, access is granted to all attributes:

access to attr=(*) 
by group2 (read)

In the following example, access is denied to the userpassword attribute:

access to attr!=(userpassword)
by group2 (read)

ACL Evaluation For Groups

If an operation on an attribute or the entry itself is explicitly denied at an ACP low in the DIT, then, typically, the ACL evaluation for the attribute (or entry) is considered "Resolved with Denial." However, if the user of the session (bindDN) is a member of a group object, then the evaluation continues as if it is still unresolved. If permissions are granted to the user of the session at an ACP higher in the tree through a group subject selector, then such grants have precedence over any denials lower in the tree.

This scenario is the only case in which an ACL policy at a higher level ACP has precedence over an ACP policy lower in the DIT.

Access Level Requirements for LDAP Operations

The following table lists LDAP operations and the access required to perform each one.

Operation Required Access

Create an object

Add access to the parent entry

Modify

Write access to the attributes that are being modified

ModifyDN

Delete access to the current parent and Add access to the new parent.

ModifyDN (RDN)

Write access to the naming attribute, that is, the RDN attribute

Remove an object

Delete access to the object being removed

Compare

Compare access to the attribute

Search

  • Search access on the filter attributes and browse access on the entry (if only the entry DN needs to be returned as a result)

  • Search access on the filter attributes, browse access on the entry, and read permission on the attributes (for all attributes whose values need to be returned as a result)


Go to previous page Go to next page
Oracle
Copyright © 1999, 2002 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index