Release 2.0.6
A77230-01
 Library |
 Product |
 Contents |
 Index |
| Oracle Internet Directory Administrator's Guide Release 2.0.6 A77230-01 |
|
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.
|
See Also:
|
This chapter covers topics in the following sections:
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 any other tool that supports the standard LDAP modify operation.
This section discusses topics in the following subsections:
This section discusses topics in the following subsections:
orclACI is a user modifiable optional attribute that represents Access Control List (ACL) policy information for a subtree starting with the entry where that subtree is defined. Any entry in the directory can contain values for this attribute. Access to this attribute itself can be controlled the same way access to any other attribute is controlled.
Access Control Policy Points (ACPs) are entries in which the orclACI attribute value is set. The orclACI attribute value represents the access policies inherited by a subtree of entries starting with the ACP as the root of the subtree.
When a hierarchy of multiple ACPs exists in a directory subtree, the subordinate entries in that subtree inherit the access policies from all of the ACPs that are superior to the entry. 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 root entry for the HR department, and the Benefits, Payroll, and Insurance groups are entries within the HR department, any entry within those groups inherits the access rights specified in that HR root entry.
When there are conflicting policies represented among a hierarchy of ACPs, the directory applies well defined precedence rules while evaluating the aggregate policy.
The orclACI attribute contains ACL directives that are prescriptive in nature, that is, the directives apply to all entries in the subtree below the ACP where this attribute is defined. In addition, it is often convenient to maintain ACL directives specific to a single entry within that entry. Oracle Internet Directory enables you to do this through a user modifiable operational attribute called orclEntryLevelACI. Any directory entry can optionally carry a value for this attribute. This is accomplished in the Oracle Internet Directory base schema by extending 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.
It is possible to represent ACL directives specific to a single entry in the orclACI attribute. However, for administrative convenience and performance advantages, Oracle Corporation recommends using orclEntryLevelACI in such scenarios. 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.
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.
It is possible to specify access rights for a group of people or entities. Such groups are called privilege groups and are associated with the orclPrivilegeGroup object class.
To grant access rights to a group of users, you create a group entry in the usual way, then associate it with the orclPrivilegeGroup object class. You then specify the access policies applicable to that group.
Entries can have either direct memberships to groups, or indirect memberships to other 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 it.
Because Oracle Internet Directory evaluates for access control purposes only groups marked as privilege groups, it does not allow setting access policies for non-privilege groups. When a user binds with a specific DN, Oracle Internet Directory computes his or her direct membership in privilege 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 privilege groups. This process continues until there are no more nested groups to be evaluated.
It is imperative that all groups created for access control purposes, nested or otherwise, be marked as privilege groups by associating them with the orclPrivilegeGroup object class. A normal group will not be considered for access control purposes even though it may be a member of a privilege group.
For example, consider the following group of entries each of which, with the exception of group4, is marked as a privilege group. One can set access control policies such that they are applicable to the members of group1, group2, and group3.
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 associated with a directory object represents the permissions on the given object that various directory user entities (or subjects) have. Thus, semantically, an ACI is a tuple consisting of three components described in the following sections:
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 root. 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 not required nor syntactically allowed.
In the orclEntryLevelACI attribute, the entry DN component of the object of the ACL is implicitly that of entry itself. For example, if dc=oracle,dc=com has an entry level ACI associated with it, the entry governed by its ACI is exactly: dc=oracle, 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 select any entry, and is convenient shorthand for the equivalent dn=.* selector.
Attributes within an entry are selected by including a comma-separated list of attribute names in the object selector.
attr=(attribute_list)
Attributes within an entry are rejected by including a comma-separated list of attribute names in the object selector.
attr!=(attribute_list)
|
See Also:
|
This section describes the authentication mode, called the bind mode, used to verify the identity of the subject, also called the entity, to whom access is granted.
The bind mode specifies the method of authentication to be used by the subject. There are five modes:
Anonymous: No authentication (default mode)
Simple: Simple password-based authentication
SSLNoauth: For SSL-based clients with either anonymous or simple password based authentication
SSLOneway: For SSL-based clients with server authentication with either anonymous or password based authentication
SSLTwoway: For SSL-based clients with strong authentication through SSL.
The BindMode is optional in subject specification. When specified, the mode should match the mode specified in the ACI for the directive to be applicable.
The entity component identifies the entity or entities being granted access. Note that access is granted to entities, not entries.
Entities can be specified by:
dn=regex
dnattr=(dn-valued_attribute_name)
The dnattr specification is used to give access to a group entry to whomever is listed as the owner of the group entry.
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.
| Permissions for Entries: | Permissions for Attributes: |
|---|---|
|
Browse/nobrowse |
Compare/nocompare |
|
Add/noadd |
Search/nosearch |
|
Delete/nodelete |
Read/noread |
|
None |
Selfwrite/noselfwrite |
|
|
Write/nowrite |
|
|
None |
The entry level access directives are distinguished by the keyword ENTRY in the object component.
When processing a request, the access level granted to the requester has to be evaluated for each of the attributes involved in the request. This evaluation is done systematically for each attribute associated with every entry involved in an LDAP operation.
The process of evaluating access to any object (attribute in an entry) involves potentially examining all the ACI directives that are applicable for that object. This is because of the hierarchical nature of ACPs and the inheritance of policies from superior ACPs to subordinate ACPs. This process is described here.
The evaluation starts with examining ACI directives in the entry's entry level ACI, orclEntryLevelACI. Until the evaluation is complete, the ACP policies are successively considered, starting with the immediate ACP, followed by the chain of its superior ACPs.
The access evaluation is done for the entry and each of its attributes individually. Oracle Internet Directory evaluates entry level access permissions to see whether the given subject is allowed to perform the given operation. During ACL evaluation, an attribute is said to be in one of the following states:
For all operations except search, the evaluation stops either if access to the entry itself is denied or if any of the attributes reach the resolved with denial state. In this case the operation would fail.
For a search operation, the evaluation continues until all the attributes reach the resolved state. Attributes that are resolved with denial are not returned.
The remainder of this section covers the topics in the following subsections:
An LDAP operation requires the BindDN--that is, the subject--of the LDAP session to have certain permissions to the objects affected by the operation--including permissions on the entry itself and on 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 fully resolves:
orclACI are examined starting with the ACP closest to the target entry and then its superior ACP and so on.
ACIs at the entry level are evaluated in the following order:
access to entry filter=(cn=p*)
by group1 (browse,add,delete)
access to entry
by group1 (browse,add,delete)
At the attribute level, specified ACIs have precedence over unspecified ACIs.
Specified ACIs at the attribute level are evaluated in the following order:
access to attr=(salary) filter=(salary >10000)
by group1 (read)
access to attr=(salary)
by group1 (search,read)
Unspecified ACIs at the attribute level are evaluated in the following order:
access to attr=(*) filter (cn=p*)
by group1 (read,write)
access to attr=(*)
by group1 (read,write)
If there are two or more ACIs at the same ACP for the same object, then the first ACI that happens to be returned wins. All other ACIs are ignored. For example, suppose you have the following two ACIs at the same ACP for the same entry:
access to entry
by dn="cn=admin, dc=us,dc=acme,dc=com" (browse, add, delete)
access to entry
by dn="cn=manager,dc=us,dc=acme,dc=com" (search, read)
If ACI #2 happens to be returned first, it wins, and the access granted specifically to the administrator in ACI #1 is ignored. If an administrator should then seek access to the entry, that access could not be resolved at this level of the hierarchy. The evaluation would have to 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 entryby 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:
access to attr=(userpassword)
by dnattr=(".*,dc=us,dc=acme,dc=com) (none)
access to attr=(userpassword)
by self (read,write)
If ACI #1 happens to be returned first, it wins, and the access granted to self in ACI #2 is ignored. If a user then wishes to change his or her own password, 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)
If an ACI exists for a given object, and you want to specify access to all other objects excluding that one, you must be sure that the specified objects do not intersect. For example, suppose you have the following two ACIs:
access to attr=(userpassword)by group1 (read,write)
access to attr=(*)by group2 (read)
In this case, the two ACIs intersect, that is, both ACIs try to grant access to the userpassword attribute, but ACI #2 is unsuccessful. The reason is that, during the evaluation process, ACI #1 wins because it is specified (See the section "ACL Evaluation Precedence Rules"). But this means that anyone in group2 who tries to access the userpassword attribute could not be given access at this level of the hierarchy. The evaluation would have to move progressively up the hierarchy in search of resolution. If no resolution is found, all access is denied.
The solution is to use the following syntax for ACI #1 and ACI #2:
access to attr=(userpassword)by group1 (read,write)by group2 (read)
access to attr!=(userpassword)by group2 (read)
In the revised ACI #1, we give to group2 read access to the userpassword attribute.
In the revised ACI #2, we negate group2's access to the userpassword attribute, and we grant read access to all attributes except the userpassword attribute.
If an operation on an attribute or the entry itself is explicitly denied at an ACP low in the DIT, typically, the ACL evaluation for the attribute (or entry) is considered Resolved with Denial. But, if the user of the session (bindDN) is known to be a member of a group object, the evaluation will continue 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, such grants have higher precedence than any denials below in the tree.
This scenario is the only case in which ACL policy at a higher level ACP has a higher precedence than that of an ACP lower in the DIT.
The following table lists LDAP operations and the access required to perform each one.
You can view and modify access control information configured 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.
Instructions for managing access control by using Oracle Directory Manager are contained in the following sections:
ACPs are entries that contain 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.
This section discusses topics in the following subsections:
To view an ACP:
You can alternatively double-click an ACP in the right pane to display the data in its own window.
The three fields in the Subtree Access Management pane are:
| Field | Description |
|---|---|
|
Path to the Subtree Access Control Point |
The Path to Subtree Access 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 the Subtree Access Control Point field. If you are creating a new ACP, you must enter the path to it here. |
|
Structural Access Items (Entry Level Operations) |
Structural access items determine access to entries. Items listed in the Structural Access Items window identify an entry by the following categories:
For instructions on how to modify structural access items, see "Modifying Structural Access Items of an Existing ACP". |
|
Content Access Items (Attribute Level Operations) |
Items listed in the Content Access Items window are related to attributes within the entry or entries identified in the Entry Filter field. Fields in this window include By Whom, Bind Mode, as well as:
For instructions on how to modify content access items, see "Modifying Content Access Items of an Existing ACP" |
To add a structural access item to an existing ACP:
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, 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:
In the By Whom tab page, 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. However, 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.
There are five bind modes from which to select:
Also in the By Whom tab page, specify the entity or entities to whom you are granting access. Options are:
In the By Whom tab page, click OK.
In the Access Rights tab, select the appropriate radio buttons to specify the kinds of rights you want to grant: Browse, Add, or Delete.
In the Access Rights tab page, click OK to close the Structural Access Items dialog box and return to the main Oracle Directory Manager dialog box. The structural ACI you just set is listed in the Structural Access Items window of the main Oracle Directory Manager dialog box.
To add a content access item to an existing ACP:
This dialog box is similar to the Structural Access Items dialog box, but it has four tabs: Entry Filter, By Whom, Attribute, and Access Rights.
To modify a structural access item:
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, you do not need to use this tab page.
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, 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:
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.
In the By Whom tab, specify the entity or entities to whom you are granting access:
To modify a content access item of an existing ACP:
Each tab page contains items you can modify.
To create a new ACP:
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:
userpassword attribute by Everyone
userpassword attribute by the user himself
userpassword to Everyone
To set the access rights for an entry, click Create under the Structural Access Items field.
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.
The By Whom page appears:
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.
The Content Access Items dialog box appears:
It is similar to the Structural Access Items dialog box, but it has four tabs: Entry Filter, By Whom, Attribute, Access Rights.
This page has two fields.The first field has two choices: EQ (equals) and NEQ (not equals). The second field sets the attribute; select it from the menu.
You have completed one ACI.
Create another ACI that allows a user to read, write, search, and compare his own password.
This tab page has two fields.The first has two choices: EQ (equals) and NEQ (not equals). The second sets the attribute; select it from the menu.
You have now created two ACPs. One denies Everyone read, search, write, and compare access to the userPassword attribute. The second allows the owner of the password to read, search, and write it, as well as compare it.
The next ACI grants access to Everyone to Read, Search, and Compare all attributes except userPassword. It denies Write access.
This combination means that any attribute that is not equal to userpassword is the object of the permissions in this 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.
Consider other access restrictions you might want to implement. Your directory might contain many entries and attributes that should not be available to everyone.
To grant local access, or access to one entry, you can use either Oracle Directory Manager or command line tools. This section explains how to grant access using Oracle Directory Manager.
To grant entry-level access by using Oracle Directory Manager:
As described in the beginning of this chapter, directory access control policy information is represented as user modifiable operational attributes. Hence, one can manage directory access control by setting and altering values of these attributes using the ldapmodify command. Any tool, including the command line tools that support the ldapmodify operation, can be used for the purpose.
In order to directly edit the ACI, you should understand the format and semantics of the directory representation of the ACI. This section contains the formal specification of the ACI format and a description of the semantic issues necessary to manage the ACI using command line tools.
|
See Also:
|
This section provides several examples using command line tools. The examples are covered in the following sections:
This example sets up subtree access permissions in an orcACI at the Root DSE. Because this example refers to the orclACI attribute, this access directive governs all the entries in the DIT that are located below the entry in which this access directive resides. Specifically, this example replaces the values in orclACI.
Note the mandatory presence of the << EOF characters.
ldapmodify -v -h $1 -D "cn=Directory Manager, o=IMC, c=US" -w "controller" << EOF 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) EOF
The example in this section sets up entry-level access permissions in the orclEntryLevelACI attribute. Because this resides in the orclEntryLevelACI attribute, this ACL governs only the entry in which it resides. Note the mandatory presence of the << EOF characters.
ldapmodify -v -h $1 -D "cn=Directory Manager, o=IMC, c=US" -w "controller" << EOF 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) EOF
This section shows some advanced and typical examples of access control policies.
The following example is an illustration of the use of wild cards (*) in the object and subject parts:
orclACI attribute in the ACP at dc=com
access to entry by * (browse)
access to attr=(*) by * (search, read)
This access directive grants read access to Everyone. Note that, in order to allow reading the attributes, browse permissions are granted on the entries.
The following example shows the use of a regular expression to select the entries by DN in two access directives.
Read access is granted to entries under the dc=oracle,dc=com subtree, except for those entries under the dc=us,dc=oracle,dc=com, to which search access is granted.
orclACI attribute in the ACP at dc=oracle,dc=com:
access to entry by * (browse)
access to attr=(*) by * (search, read)
orclACI attribute in the ACP at dc=us,dc=oracle,dc=com:
access to entry by * (browse) access to attr=(*) by * (none)
The next 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=oracle,dc=com subtree. The policy enforced by this ACI can be described as follows:
userPassword attribute can be viewed and modified by oneself and the administrator. Others can compare.
homePhone attribute can be read and written by oneself and viewed by others.
orclACI attribute in the ACP at dc=us,dc=oracle,dc=com:
access to entry
by dn="cn=admin, dc=us,dc=oracle,dc=com" (browse, add, delete)
by dn=".*, dc=us,dc=oracle,dc=com" (browse)
by * (none) access to attr=(salary)
by dnattr=(manager) (search, read, write, compare)
by self (search, read, compare)
by * (none) access to attr=(userPassword)
by self (search, read, write, compare)
by dn="cn=admin, dc=us,dc=oracle,dc=com" (search,read, write, compare)
by * (compare) access to attr=(homePhone)
by self (search,read, write, compare)
by * (read) access to attr != (salary, userPassword, homePhone)
by dn="cn=admin, dc=us,dc=oracle,dc=com" (compare, search, read, write)
by * (compare, search, read)
Sometimes it is useful to permit a particular DN to add or remove itself from an attribute. For example, if you would like to create a group and allow people to add and remove only their own DN from the member attribute, you could accomplish it with an access directive like this:
access to attr=(member) by dnattr=(member) (selfwrite)
The dnattr=(subject) selector says that the access applies to entities listed in the member attribute. The (selfwrite) access selector says that such members can only add or delete their own DN from the attribute, not other values.
|
 Copyright © 1999 Oracle Corporation. All Rights Reserved. |
|