10g (9.0.4)
Part Number B12118-01
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle® Internet Directory Administrator's Guide 10g (9.0.4) Part Number B12118-01 |
|
Directory Access Control, 2 of 5
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:
This section discusses the structures used for access control in Oracle Internet Directory. These include:
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.
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 |
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.
|
See Also:
"Object: To What Are You Granting Access?" for the structure definition of the |
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 security groups. There are two types of security groups: ACP groups and privilege 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.
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 realm. Because the global administrator's identity is not recognized in the realm of the hosted company, the directory server, relying only on the ACPs in that realm, 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 to this privilege group the access rights to that subtree. If it finds such an ACP, then the directory server overrides the denials by ACPs in the hosted company's realm.
Privilege groups are associated with the orclPrivilegeGroup object class.
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.
To grant access rights to a group of users, you do the following:
orclPrivilegeGroup object class or the orclACPgroup object class.
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 security 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 security 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 security groups. This process continues until there are no more nested groups to be evaluated.
Each security group, nested or otherwise, must be associated with an security group object class--either orclACPgroup or orclPrivilegeGroup. Even if a group is a member of an security group, the directory server does not consider it for access control purposes unless it is associated with an security group object class. When it has determined the user's membership in security groups, the directory server uses that information for the lifetime of the session.
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.
Group 3,c=us contains the following nested groups:
Access control policies for Group 3 are applicable to members of Group 3, Group 1, and Group 2 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 Group 3 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 Group 2--then his access rights will be governed by access policies set up for members of Group 1, Group 2, as well as Group 3 (in which Group 1 and Group 2 are nested). This is because all three groups are associated with the object class orclPrivilegeGroup.
|
See Also:
Either "Modifying Entries by Using Oracle Directory Manager" or "Example: Modifying a User Entry by Using ldapmodify" for instructions on how to modify a group entry to associate it with or disassociate it from either the |
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:
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-delimited list of attribute names in the object selector.
attr=(attribute_list)
Attributes within an entry are excluded from a policy by including a comma-delimited list of attribute names in the object selector.
attr!=(attribute_list)
|
See Also:
Appendix E, "The Access Control Directive Format" for information about the format or syntax of ACIs |
This section describes:
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:
The bind mode specifies the methods of authentication and of encryption to be used by the subject.
There are four authentication modes:
There are three encryption options:
Specifying the encryption mode is optional. If it is not specified, then no encryption is used--unless the selected authentication mode is PKCS12. Data transmitted by using PKCS12 is always encrypted.
There is a precedence rule among authentication choices, and it is as follows:
Anonymous < Proxy < Simple < MD5Digest < PKCS12
This rule means that:
The bind mode syntax is:
BINDMODE =(LDAP_AUTHENTICATION_CHOICE + [ LDAP_ENCRYPTION_CHOICE ] ) LDAP_AUTHENTICATION_CHOICE = Proxy | Simple | MD5Digest | PKCS12 LDAP_ENCRYPTION_CHOICE = SSLNoAuth | SSLOneway | SASL
The LDAP_ENCRYPTION_CHOICE is an optional parameter. If you do not specify it, then the directory server assumes that no encryption is to be used.
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.
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.
The entry level access directives are distinguished by the keyword ENTRY in the object component.
The following table lists LDAP operations and the access required to perform each one.
|
 Copyright © 1999, 2003 Oracle Corporation. All Rights Reserved. |
|