Oracle Internet Directory Administrator's Guide
Release 3.0.1

Part Number A90151-01
Go To Documentation Library
Home
Go To Product List
Book List
Go To Table Of Contents
Contents
Go To Index
Index

Master Index

Feedback

Go to previous page Go to next page

11
About Security in Oracle Internet Directory

This chapter describes the security features available with Oracle Internet Directory, and explains how to deploy the directory for administrative delegation. It contains these topics:

Security Features of Oracle Internet Directory

This section describes each Oracle Internet Directory security feature. It contains these topics:

Data Integrity

Oracle Internet Directory ensures that data has not been modified, deleted, or replayed during transmission by using Secure Sockets Layer (SSL). This SSL feature generates a cryptographically secure message digest--through cryptographic checksums using either the MD5 algorithm or the Secure Hash Algorithm (SHA)--and includes it with each packet sent across the network.

See Also:

Chapter 12, "Managing Secure Sockets Layer (SSL)" for more information about SSL 

Data Privacy

Oracle Internet Directory ensures that data is not disclosed during transmission by using public-key encryption available with SSL. In public-key encryption, the sender of a message encrypts the message with the public key of the recipient. Upon delivery, the recipient decrypts the message using the recipient's private key. Specifically, Oracle Internet Directory supports two levels of encryption available through SSL:

Authentication

Authentication is the process by which the directory server establishes the true identity of the user connecting to the directory. It occurs when an LDAP session is established by means of the ldapbind operation. Thus every session has an associated user identity.

To verify the identities of users, hosts, and clients, Oracle Internet Directory provides four authentication options:

Anonymous Authentication

When users authenticate anonymously, they simply leave the user name and password fields blank when they log in. Each anonymous user then exercises whatever privileges are specified for anonymous users.

Simple Authentication

When using simple authentication, the client identifies itself to the server by means of a DN and a password that are not encrypted when sent over the network.

Secure Sockets Layer (SSL) Authentication

This involves the exchange of certificates issued by trusted certificate authorities.

Authentication Through a Middle Tier

Authentication through a middle tier, such as a RADIUS server or an LDAP self-service servlet, involves a proxy user that performs directory operations on the end user's behalf. Authentication through a middle tier takes place as follows:

  1. The end user authenticates to the middle tier.

  2. The middle tier binds to the directory as a proxy user.

  3. The proxy user performs a second bind, this time using the DN of the end user. It does not need to enter the end user's password.

  4. The directory server recognizes this second bind as an attempt by the proxy user to switch to the end user's identity. The directory server trusts the authentication granted to the end user by the middle tier and allows this second bind to succeed.

The access controls that the Oracle directory server uses throughout the rest of the session are those it would use if the end user were performing those operations.

For example, suppose you have a proxy user whose DN is cn=ProxyUser. The middle tier service authenticates the end user. The middle tier service then binds to the directory as cn=ProxyUser. The proxy user then performs another bind, this time using the DN of the end user--let's call it cn=EndUser. The Oracle directory server recognizes this second bind as an attempt by the proxy user to switch its identity to cn=EndUser for the duration of the session. Because Oracle directory server trusts the proxy user, it allows this second bind to succeed; it does not require any further validation of the end-user DN, such as a password. For the rest of the session, all LDAP operations are access controlled as if cn=EndUser were performing them.

Authorization

Authorization is the process of ensuring that a user reads or updates only the information for which that user has privileges. When directory operations are attempted within a directory session, the directory server ensures that the user has the requisite permissions to perform those operations. If the user does not have the requisite permissions, then the directory server disallows the operation. Through this mechanism, the directory server protects directory data from unauthorized operations by directory users. This mechanism is called access control.

Access control information is the directory metadata that captures the administrative policies relating to access control. This information is stored in Oracle Internet Directory as user-modifiable operational attributes, each of which is called an access control item (ACI).

Typically, a list of these ACI attribute values, called an access control list (ACL), is associated with directory objects. The attribute values on that list govern the access policies for those directory objects.

Access control information associated with a directory object represents the permissions on the given object that various directory user entities (or subjects) have. Thus, an ACI consists of:

Access control policies can be prescriptive, that is, their security directives can be set to apply downward to all entries at lower positions in the directory information tree (DIT). The points from which such access control policies apply are called access control policy points (ACPs).

ACIs are represented and stored as text strings in the directory. These strings must conform to a well defined format, called the ACI directive format. Each valid value of an ACI attribute represents a distinct access control policy.

The following features of directory access control can be used by applications running in a hosted environment.

Prescriptive access control

Enables the service provider to specify access control lists (ACLs) for a collection of directory objects, instead of having to state the policies for each individual object. This feature simplifies the administration of access control, especially in large directories where many objects are governed by identical or similar policies.

Hierarchical access control administration model

Enables the service provider to delegate directory administration to subscribers. The subscriber could in turn delegate further if necessary.

Administrative override control for delegated domains

Enables the service provider to perform diagnosis and recovery from unintentional account lockout or accidental security exposure.

Dynamic evaluation of access control entities

Enables subtree administrators to identify both subjects and objects in terms of their namespace and their association with other objects in the directory. For example, the administrator of one subscriber subtree can allow only a user's manager to update that user's salary attribute. The administrator of another subscriber subtree can establish and enforce a different policy regarding salary attributes.

Password Protection

Oracle Internet Directory can protect passwords by storing them in the userPassword attribute as one-way hashed values. You select the hashing algorithm you want to use. Storing passwords as one-way hashed values--rather than as encrypted values--more fully secures them because a malicious user can neither read nor decrypt them.

During authentication to a directory server, a user enters a password in clear text. The directory server hashes this user password by using the specified hashing algorithm, then verifies it against the hashed password stored in the userPassword attribute. If the hashed password values match, then the server authenticates the user. If they do not match, then the server sends the user an Invalid Credentials error message.

You can specify one of the following hashing schemes:

The hashing algorithm value you specify is stored in the orclCryptoScheme attribute in the root DSE. This attribute is single-valued.

See Also:

"Managing Password Protection" 

Password Policies

A password policy is a set of rules governing how passwords are used. When a user attempts to bind to the directory, the directory server ensures that the password meets the various requirements set in the password policy.

When you establish a password policy, you set the following types of rules, to mention just a few:

Directory-Based Application Security

Because directory access control policies are stored as LDAP attributes, you can set metapolicies controlling who can modify them. This enables a global administrator to assign privileges to administrators of specific subtrees--for example, to administrators of applications in a hosted environment. Similarly, a global administrator can delegate to departmental administrators access to the metadata of applications in their departments. Department administrators can then control access to their department applications.

Thus, you can implement access control on two levels:

Authorization of users

In this case, the directory stores access control policies that external applications then read and enforce. When a user tries to perform an operation by using an application, the application verifies that the user has the correct authorization to perform the operation.

Authorization of administrators

In this case, the directory serves as the trusted point of administration for all application-specific access control polices. To govern who can administer the access control policies of specific applications, you set access control policies at the directory level for these applications. Then, when a user attempts to change an application-specific access control policy, the directory verifies that the user has the correct authorization to make that change.

Figure 11-1 shows the relationship between directory access control and the application-specific access control mechanisms in a hosted environment.

Figure 11-1 Directory Access Control and Application-Specific Access Control


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

Figure 11-2 illustrates the various domains and the roles associated with them in the directory.

Figure 11-2 Directory Domains and Roles in a Hosted Environment


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

In Figure 11-2, each triangle represents a portion of a DIT.

Figure 11-2 shows only a single subscriber represented in the directory. In reality there are multiple subscribers, each with its own domain requiring protection from the others.

Some of the protection domains in this model are:

These protection domains are supported by the following roles, which enable the service provider or subscriber to customize access control.

Global Administrative Roles

These roles have rights to perform activities that span the entire directory.

Subscriber-Specific Roles

These roles are limited to the directory trees specific to the subscribers.

Application-Specific Roles

When hosting directory-enabled applications, it is not necessary to represent all application-specific roles in the directory. However, it is better that applications, when representing roles that directly affect their directory footprint, follow the delegation model recommendations described earlier. This enables applications to leverage the directory-based delegation model when granting directory-specific privileges to users.


Go to previous page Go to next page
Oracle
Copyright © 1996-2001, Oracle Corporation.

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

Master Index

Feedback