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

11
Directory Security Concepts

This chapter describes the security features available with Oracle Internet Directory. 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, "Secure Sockets Layer (SSL) and the Directory" 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:

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 point from which such an access control policy applies is called an access control policy point (ACP).

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.

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 enables two general kinds of authentication: direct and indirect.

Direct Authentication

There are three direct authentication options:

Indirect Authentication

Indirect authentication occurs through any entity that has credentials in the directory--for example, an application such as the Delegated Administration Service, or a middle tier such as a firewall or a RADIUS server. The application or middle tier becomes a proxy user that impersonates an end user, performing directory operations on that end user's behalf.

Figure 11-1 and the accompanying text explain how indirect authentication takes place.

Figure 11-1 Indirect Authentication

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

Indirect authentication takes place as follows:

  1. The end user sends to the application or middle tier a request containing a query to Oracle Internet Directory. The application or middle tier authenticates the end user.

  2. The application or middle tier binds to the directory.

  3. The application or middle tier performs a second bind, this time using the DN of the end user. It does not enter the end user's password.

  4. The directory server recognizes this second bind as an attempt by the application or middle tier to switch to the end user's identity. It trusts the authentication granted to the end user by the application or middle tier, but must verify that the application or middle tier has the right to be the proxy for this user. It checks to see whether the ACP governing the end user entry gives this application or middle tier the proxy right for this end user.

    • If the application or middle tier does have the necessary proxy right, then the directory server changes the authorization identity to that of the end user. All subsequent operations occur as if that end user had connected directly to the server and had been directly authenticated.

    • If the application or middle tier does not have the necessary proxy right, then the directory server returns an error message, "Insufficient Access."

The directory server can, in the same session, authenticate and authorize other end users. It can also switch the session from that of the end user to that of the application or middle tier that opened the session.

To close the session, the application or middle tier sends an unbind request to the directory server.

For example, suppose you have:

When this end user sends to the application or middle tier a request containing a query to Oracle Internet Directory, the application or middle tier authenticates the end user. The middle tier service then binds to the directory by using its own identity cn=User1, then performs a second bind, this time by using only the DN of the end user, cn=User2. The Oracle directory server recognizes this second bind as an attempt by the proxy user to impersonate the end user. After the Oracle directory server verifies that cn=user1 has proxy access, it then 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=User2 were performing them.

If another user of such an application requests its services while a prior user is being serviced, the application can establish a new connection and proceed as above without disrupting that session. If, however, no prior user is still being serviced, the existing established connection can be re-used again and again without any need for a new connection.

Protection of User Passwords for Directory Authentication

Oracle Internet Directory can protect a user's directory password by storing it in the userPassword attribute as a one-way hashed value. 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.

See Also:

"Storing Password Verifiers for Authenticating to Oracle Internet Directory"

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:


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