5
Using and Deploying a Secure Directory

Many security advantages can be had by centralizing in a directory the storage and management of user information such as identity, credentials, and other attributes. This chapter describes how to protect a directory, and how access can be controlled using a directory.

• Introduction
• Centralizing Shared Information with LDAP
• Securing the Directory
• Directory-Based Application Security

Introduction

Administrators today must manage complex user information, keeping it current and secure. These tasks become all the more challenging with increased use of technology and a high user turnover in enterprises. For example, in a typical enterprise, each user can have multiple accounts on different databases. This means too many passwords for users to remember, and too many accounts for administrators to manage. Consequently, users write down their passwords, make them easy to remember (and easy for someone else to guess), or choose the same password for all accounts.

Administrators must manage multiple accounts for every user. As a result, they devote significant resources to user administration. Common information used by multiple applications--such as username, user's office location and phone number, and system privileges--is often fragmented across the enterprise, leading to data that is redundant, inconsistent, and expensive to manage.

There are security problems as well. For example, any time a user leaves a company or changes jobs, his privileges should change the same day in order to guard against misuse of his old or unused accounts and privileges. However, in a large enterprise, with user accounts and passwords distributed over multiple databases, an administrator may not be able make all the changes as expeditiously as good security requires.

Enterprise user security management must address these user, administration, and security challenges. The best way is to centralize storage and management of user-related information in an LDAP-compliant directory service such as Oracle Internet Directory. Then, when an employee changes jobs, the administrator needs to modify information in only one location--the directory. This centralization lowers the cost of administration and makes the enterprise more secure.

Centralizing Shared Information with LDAP

Today, network information is stored in multiple systems and in multiple directory formats. With new requirements for Internet computing and new e-business technologies, there is a growing need for a common repository infrastructure to serve as a foundation for management and configuration of all data and resources. Such a common infrastructure reduces the cost of managing and configuring resources in heterogeneous networks.

Lightweight Directory Access Protocol (LDAP) technology was initially developed at the University of Michigan. It is currently an industry-accepted standard and is available in a variety of implementations.

Support of LDAP-compliant directory servers provides a centralized vehicle for managing and configuring a distributed network. The directory can act as a central repository for all data on database network components, user and corporate policies, and user authentication and security, thus replacing client-side and server-side localized tnsnames.ora files.

An LDAP-compliant directory can provide many powerful features to protect information:

Table 5-1 Security Features of an LDAP-Compliant Directory

Feature	Purpose
Data Integrity	Ensures that data--including passwords--is not modified, deleted, or replayed during transmission
Data Privacy	Ensures that data is not inappropriately detected during transmission by using public-key encryption. 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 by using the recipient's private key
Password Protection	Stores passwords as hashed values, to ensure that intruders can neither read nor decrypt them
Password Policy Management	Enables directory to centralize policy management for its users and accounts.
Authentication	Ensures that the identities of users, hosts, and clients are correctly validated
Authorization	Ensures that a user reads or updates only the information for which that user has privileges

To gain all these advantages of security directory integration, you must first ensure that the directory itself is secure. This involves:

• Secure connections to the directory on the part of the user and the administrator
• Access controls on the directory itself

Once your directory has been secured, other applications in an enterprise or hosted environment can take advantage of all these features. They can use the directory for administrative delegation, and control access to application metadata.

Securing the Directory

This section describes how access can be controlled within the directory.

• Directory Access Controls and Authorization
• Password Protection in a Directory
• Directory Access Controls and Authorization

Directory Authentication of Users

Authentication is the process by which the directory server establishes the true identity of the user connecting to the directory. To verify the identities of users, hosts, and clients, the directory can provide various authentication options:

Table 5-2 Directory Authentication Options

Option	Description
Anonymous Authentication	Users simply leave blank the user name and password fields when they log in. Each anonymous user then exercises whatever privileges are specified for anonymous users.
Simple Authentication	The client identifies itself to the directory by means of a distinguished name and a password that are not encrypted when sent over the network.
Authentication Using Secure Sockets Layer (SSL)	Authentication can occur through the exchange of certificates issued by trusted certificate authorities.
Authentication Through a Middle Tier	Authentication can occur through a middle tier, such as a RADIUS server or an LDAP self-service servlet. This involves a proxy user that performs directory operations on the end user's behalf.

Password Protection in a Directory

Oracle Internet Directory can protect passwords by storing them as one-way hashed values. This approach secures passwords better than the approach of storing them as clear text or encrypted values, because a malicious user can neither read nor decrypt them if they are hashed.

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 that has been stored. If the hashed password values match, then the server authenticates the user.

You can specify one of the following hashing schemes:

Table 5-3 Hashing Algorithms

Hashing Scheme	Description
MD4	The default hashing scheme. MD4 is a one-way hash function that produces a 128-bit hash, or message digest.
MD5	An improved, and more complex, version of MD4
SHA	Secure Hash Algorithm, which produces a 160-bit hash, longer than MD5. The algorithm is slightly slower than MD5, but the larger message digest makes it more secure against brute-force collision and inversion attacks.
UNIX Crypt	The UNIX hashing algorithm
No Hashing	The password is not hashed.

Directory Access Controls and 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.

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

Table 5-4 Directory Access Control Features

Feature	Description
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.

Directory-Based Application Security

In an enterprise or hosted environment, you can use the features of an LDAP-compliant directory to control access to application metadata--the information governing how applications behave and who can access them.

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 department administrators access to the metadata of applications in their departments. Department administrators can then control access to their department applications. In this way, you can implement access control on two levels: users and administrators.

This section includes:

• Authorization of Users
• Authorization of Administrators
• Administrative Roles in the Directory

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 5-1 shows the relationship between directory access control and the application-specific access control mechanisms in a hosted environment.

Figure 5-1 Delegating Administration for Directory-Based Application Security

Text description of the illustration oid81037.gif

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

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

Text description of the illustration oid81041.gif

In Figure 5-2, each triangle represents a portion of a directory information tree (DIT).

• The outermost triangle represents the entire directory. The directory administrator has privileges extending across the entire directory.
• Immediately inside the outermost triangle lies another triangle, the service provider administrative domain. In this portion, privileges to add new entries are delegated to the service provider's administrators.
• Inside the service provide administrative domain, privileges can be further delegated based on the ownership of directory information. For example, the delegation can depend on whether the information is private to a specific subscriber or global to the service provider.

Figure 5-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:

• Entire directory
• Service provider administrative domain
• Service provider-specific directory information tree
• Subscriber-specific subtree
• Application-specific footprint in the directory
• User-specific information

Administrative Roles in the Directory

Three types of role support the protection domains listed in the previous section. These roles enable the service provider or subscriber to customize access control if required.

Table 5-5 Administrative Roles in the Directory

Role	Function
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.