2
Concepts and Architecture

This chapter provides conceptual descriptions of the basic elements of Oracle Internet Directory and discusses Oracle Internet Directory architecture.

This chapter contains these topics:

• Entries
• Attributes
• Object Classes
• Naming Contexts
• The Directory Schema
• Security
• Globalization Support
• Oracle Internet Directory Architecture
• Example: How Oracle Internet Directory Works
• Distributed Directories
• The Oracle Directory Integration Platform

  See Also: "Related Documentation" for suggestions on further reading about LDAP-compliant directories

Entries

In a directory, each collection of information about an object is called an entry. For example, a typical telephone directory includes entries for people, and a library card catalog contains entries for books. Similarly, an online directory might include entries for employees, conference rooms, e-commerce partners, or shared network resources such as printers.

Each entry in an online directory is uniquely identified by a distinguished name (DN). The distinguished name tells you exactly where the entry resides in the directory hierarchy. This hierarchy is represented by a directory information tree (DIT).

To understand the relation between a distinguished name and a directory information tree, look at Figure 2-1.

Figure 2-1 A Directory Information Tree

Text description of the illustration oidag025.gif

The DIT in Figure 2-1 diagrammatically represents entries for two employees of Acme Corporation who are both named Anne Smith. It is structured along geographical and organizational lines. The Anne Smith represented by the left branch works in the Sales division in the United States, while the other works in the Server Development division in the United Kingdom.

The Anne Smith represented by the right branch has the common name (cn) Anne Smith. She works in an organizational unit (ou) named Server Development, in the country (c) of Great Britain (uk), in the organization (o) Acme.

The DN for this "Anne Smith" entry is:

cn=Anne Smith,ou=Server Development,c=uk,o=acme

Note that the conventional format of a distinguished name places the lowest DIT component at the left, then follows it with the next highest component, moving progressively up to the root.

Within a distinguished name, the lowest component is called the relative distinguished name (RDN). For example, in the previous entry for Anne Smith, the RDN is cn=Anne Smith. Similarly, the RDN for the entry immediately above Anne Smith's RDN is ou=Server Development, the RDN for the entry immediately above ou=Server Development is c=uk, and so on. A DN is thus a sequence of RDNs separated by commas.

To locate a particular entry within the overall DIT, a client uniquely identifies that entry by using the full DN--not simply the RDN--of that entry. For example, within the global organization in Figure 2-1, to avoid confusion between the two Anne Smiths, you would use each one's full DN. (If there are potentially two employees with the same name in the same organizational unit, you could use additional mechanisms, such as identifying each employee with a unique identification number.)

To make operations on entries quick and efficient, Oracle Internet Directory assigns a unique identifier to each entry, then stores a specified number of those identifiers in cache memory. When a user performs an operation on an entry, the directory server looks in the cache for the entry identifier, then retrieves the corresponding entry from the directory. This method, called entry caching, enhances Oracle Internet Directory performance, and is especially useful in smaller and medium-sized enterprises.

Attributes

In a typical telephone directory, an entry for a person contains such information items as an address and a phone number. In an online directory, such an information item is called an attribute. Attributes in a typical employee entry can include, for example, a job title, an e-mail address, or a phone number.

For example, in Figure 2-2, the entry for Anne Smith in Great Britain (uk) has several attributes, each providing specific information about her. These are listed in the balloon to the right of the tree, and they include emailaddrs, printername, jpegPhoto, and app preferences. Moreover, each bullet in Figure 2-2 is also an entry with attributes, although the attributes for each are not shown.

Figure 2-2 Attributes of the Entry for Anne Smith

Text description of the illustration concepta.gif

Each attribute consists of an attribute type and one or more attribute values. The attribute type is the kind of information that the attribute contains--for example, jobTitle. The attribute value is the particular occurrence of information appearing in that entry. For example, the value for the jobTitle attribute could be manager.

This section contains these topics:

• Kinds of Attribute Information
• Single-Valued and Multivalued Attributes
• Attribute Options
• Common LDAP Attributes
• Attribute Syntax
• Attribute Matching Rules

Kinds of Attribute Information

Attributes contain two kinds of information.

• Application Information

  This information is maintained and retrieved by the directory clients and is unimportant to the operation of the directory. A telephone number, for example, is application information.

• Operational Information

  This information pertains to the operation of the directory itself. Some operational information is specified by the directory to control the server--for example, the time stamp for the creation or modification of an entry, or the name of the user who creates or modifies an entry. Other operational information, such as access information, is defined by administrators and is used by the directory program in its processing. Operational information is stored in the root directory specific entry.

Any given attribute can hold either application information, or operational information, but not both.

To enhance your ability to search for entries, Oracle Internet Directory automatically creates several system operational attributes when you add an entry to the directory. These include:

Attribute	Description
creatorsName	Name of the person creating the entry
createTimestamp	Time of entry creation in UTC (Coordinated Universal Time)
modifiersName	Name of person creating the entry
modifyTimestamp	Time of entry creation in UTC

Moreover, when a user modifies an entry, Oracle Internet Directory automatically updates the modifiersName and modifyTimestamp attributes to, respectively, the name of the person modifying the entry, and the time of the entry modification in UTC.

Single-Valued and Multivalued Attributes

Attributes can be either single-valued or multivalued. Single-valued attributes carry only one value in the attribute, whereas multivalued attributes can have several. An example of a multivalued attribute is a group membership list with names of everyone in the group.

Common LDAP Attributes

Oracle Internet Directory implements all of the standard LDAP attributes. Table 2-1 shows some of the more common LDAP attributes.

Table 2-1  Common LDAP Attributes

Attribute Type	Attribute String	Description
commonName	cn	Common name of an entry--for example, Anne Smith
domainComponent	dc	The DN of the component in a Domain Name System (DNS)--for example, dc=uk,dc=acme,dc=com
jpegPhoto	jpegPhoto	Photographic image in JPEG format. The path and file name of the JPEG image you want to include as an entry attribute--for example, /photo/audrey.jpg
organization	o	Name of an organization--for example, my_company.
organizationalUnitName	ou	Name of a unit within an organization--for example, Server Development
owner	owner	Distinguished name of the person who owns the entry, for example, cn=Anne Smith, ou=Server Development, o= Acme, c=uk
surname, sn	sn	Last name of a person--for example, Smith
telephoneNumber	telephoneNumber	Telephone number--for example, (650) 123-4567 or 6501234567

Attribute Syntax

Attribute syntax is the format of the data that can be loaded into each attribute. For example, the syntax of the telephoneNumber attribute might require a telephone number to be a string of numbers containing spaces and hyphens. However, the syntax for another attribute might require specifying whether the data has to be in the form of a date, or whether the data can consist of numbers only. Each attribute must have one and only one syntax attached to it.

Oracle Internet Directory recognizes most of the syntax specified in RFC 2252, allowing you to associate most of the syntax described in that document with an attribute. In addition to recognizing the syntax in RFC 2252, Oracle Internet Directory also enforces some LDAP syntax. You cannot add new syntaxes beyond those already supported by Oracle Internet Directory.

Attribute Matching Rules

In response to most incoming client requests, the directory server performs search and compare operations. During these operations, the directory server consults the relevant matching rule to determine equality between the attribute value sought and the attribute value stored. For example, matching rules associated with the telephoneNumber attribute could cause "(650) 123-4567" to be matched with either "(650) 123-4567" or "6501234567" or both. When you create an attribute, you associate a matching rule with it.

Oracle Internet Directory implements all the standard LDAP matching rules. You cannot add new matching rules beyond those already supported by Oracle Internet Directory.

Attribute Options

An attribute type can have various options that enable you to specify how the value for that attribute is made available in a search or a compare operation. For example, suppose that an employee has two addresses, one in London, the other in New York. Options for that employee's address attribute could allow you to store both addresses.

Moreover, attribute options can include language codes. For example, options for John Doe's givenName attribute could enable you to store his given name in both French and Japanese.

For clarity, we can distinguish between an attribute with an option and its base attribute, which is the same attribute without an option. For example, in the case of cn;lang-fr=Jean, the base attribute is cn; the French value for that base attribute is cn;lang-fr=Jean.

An attribute with one or more options inherits the properties--for example, matching rules and syntax-- of its base attribute. To continue the previous example, the attribute with the option cn;lang-fr=Jean inherits the properties of cn.

Object Classes

An object class is a group of attributes that define the structure of an entry. When you define a directory entry, you assign one or more object classes to it. Some of the attributes in these object classes are mandatory, others are optional.

For example, the organizationalPerson object class includes the mandatory attributes commonName (cn) and surname (sn), and the optional attributes telephoneNumber, uid, streetAddress, and userPassword. When you define an entry by using the organizationalPerson object class, you must specify values for commonName (cn) and surname (sn). You do not need to provide values for telephoneNumber, uid, streetAddress, and userPassword.

At installation, Oracle Internet Directory provides standard LDAP object classes, as well as several proprietary object classes. You cannot add mandatory attributes to the sets of attributes belonging to these predefined object classes. If a given object class does not contain all the attributes that you want for an entry, then you can do one of the following:

• Add optional attributes to an existing object class
• Define a new (base) object class
• Define an object subclass

  See Also: Appendix C, "Schema Elements" for a list of object classes in the schema installed with Oracle Internet Directory

This section contains these topics:

• Subclasses, Superclasses, and Inheritance
• Object Class Types

Subclasses, Superclasses, and Inheritance

A subclass is an object class derived from another object class. The object class from which it is derived is called its superclass. For example, the object class organizationalPerson is a subclass of the object class person. Conversely, the object class person is the superclass of the object class organizationalPerson.

Subclasses inherit all of the attributes belonging to their superclasses. For example, the subclass organizationalPerson inherits the attributes of its superclass, person. Entries may inherit the attributes defined by multiple object classes.

One special object class, called top, has no superclasses. It is one of the superclasses of every structural object class in the directory, and its attributes are inherited by every entry.

Object Class Types

There are three types of object classes:

• Abstract
• Structural
• Auxiliary

Abstract Object Classes

An abstract object class is a virtual object class. It is used only for convenience when specifying the highest levels of the object class hierarchy. It cannot be the only object class for an entry. For example, the object class top is an abstract object class. It is required as a superclass for all structural object classes, but it cannot be used alone.

The top object class includes the mandatory attribute objectClass as well as several optional attributes. The optional attributes in top are:

• orclGuid--Global identification which remains constant if the entry is moved
• creatorsName--Name of the creator of the object class
• createTimestamp--Time when the object class was created
• modifiersName--Name of the last person to modify the object class
• modifyTimestamp--Time when the object class was last modified
• orclACI--access control list (ACL) directives that apply to all entries in the subtree below the access control policy point where this attribute is defined
• orclEntryLevelACI--Access control policy pertaining to only a specific entity--for example, a special user

  See Also: "Globalization Support" for more information on access control policies and ACLs.

Structural Object Classes

These object classes use structure rules to place restrictions on the kinds of object classes you can create under any given object class. For example, a structure rule might require all objects below the organization (o) object class to be organizational units (ou). Following this rule, you could not enter person objects directly below an organization object class. Similarly, a structure rule might disallow you from placing an organizational unit (ou) object below a person object.

Auxiliary Object Classes

Auxiliary object classes are groupings of attributes that expand the existing list of attributes in an entry. For example, suppose you have defined an entry as a member of two object classes, and you want to assign to that entry additional attributes that do not belong to either of those two object classes. You can create a new auxiliary object class containing the extra attributes, and then associate that auxiliary object class with the entry. This is an alternative to redefining existing object classes.

Unlike structural object classes, auxiliary classes do not place restrictions on where an entry may be stored.

Naming Contexts

A naming context is a subtree that resides entirely on one server. It must be contiguous, that is, it must begin at an entry that serves as the top of the subtree, and extend downward to either leaf entries or references to subordinate naming contexts. It can range in size from a single entry to the entire DIT.

Figure 2-3 illustrates valid and invalid naming contexts. Notice that the correct ones on the left are contiguous, and the incorrect ones on the right are not.

Figure 2-3 Valid and Invalid Naming Contexts

Text description of the illustration oidag019.gif

To enable users to search for specific naming contexts, you can publish those naming contexts by using either Oracle Directory Manager or ldapmodify.

The Directory Schema

The directory schema contains all information about how data is organized in the DIT--that is, metadata such as that for an object class, an attribute, a matching rule, and syntax. The directory schema stores this information in a special class of entry called a subentry. Oracle Internet Directory, following LDAP Version 3 standards, holds schema definitions in the subentry called subSchemaSubentry.

You can add new object classes and objects by modifying subSchemaSubentry. You cannot, however, add new matching rules and syntaxes beyond those already supported by Oracle Internet Directory.

Security

Oracle Internet Directory provides many powerful features for protecting information. These include:

• Data integrity: Ensuring that data is not modified during transmission
• Data privacy: Ensuring that data is not inappropriately detected during transmission
• Authentication: Ensuring that the identities of users, hosts, and clients are correctly validated
• Authorization: Ensuring that a user reads or updates only the information for which that user has privileges
• Password policies: Establishing and enforcing rules for how passwords are defined and used
• Password protection: Ensuring the security of passwords.

More significantly, in an enterprise or hosted environment, you can use all these features to control access to application metadata--the information governing how applications behave and who can access them. To do this, you deploy the directory for administrative delegation. This deployment allows, for example, a global administrator to delegate to department administrators access to the metadata of applications in their departments. These department administrators can then control access to their department applications.

Globalization Support

Oracle Internet Directory follows LDAP Version 3 internationalization (I18N) standards. These standards require that the database storing directory data use the UTF-8 (Unicode Transformation Format 8-bit) character set. (The Oracle character set name is AL32UTF8.) This allows Oracle Internet Directory to store the character data of almost any language supported by Oracle Globalization Support. Moreover, although several different application program interfaces (APIs) are involved in the Oracle Internet Directory implementation, Oracle Internet Directory ensures that the correct character encoding is used with each API.

Globalization Support uses both single-byte and multibyte characters. A single-byte character is represented by one byte of memory. ASCII text, for example, uses single-byte characters. By contrast, a multibyte character can be represented by more than one byte. Simplified Chinese, for example, uses multibyte characters. A directory entry in simplified Chinese might look like this:

dn: o=\274\327\271\307\316\304,c=\303\300\271\372
objectclass: top
objectclass: organization
o: \274\327\271\307\316\304

where the attribute values correspond to character strings in the simplified Chinese character set.

By default, the main Oracle Internet Directory components--OID Monitor (OIDMON), OID Control Utility (OIDCTL), Oracle directory server (OIDLDAPD), Oracle directory replication server (OIDREPLD), and Oracle directory integration server (ODISRV)--always use the UTF-8 character set (The Oracle character set name is AL32UTF8).

Oracle Directory Manager, a Java-based tool, internally uses Unicode (UTF-16--that is, fixed-width 16-bit Unicode). In Java, UCS-2 is the easiest way to handle characters--including English characters. The Java client uses standard Java packages to convert both to and from UCS-2 and UTF-8. This enables Oracle Directory Manager to handle the LDAP Version 3 protocol using UTF-8.

Oracle Internet Directory Architecture

This section contains these topics:

• An Oracle Internet Directory Node
• An Oracle Directory Server Instance
• Configuration Set Entries

An Oracle Internet Directory Node

Figure 2-4 shows the various directory server components and their relationships running on a single node.

Oracle Net Services is used for all connections between the Oracle database server and:

• The OID Control Utility
• The Oracle directory server instance 1 non-SSL port 389
• The Oracle directory server instance 2 SSL-enabled port 636
• The OID Monitor

LDAP is used for connections between directory server instance 1 on non-SSL port 389 and:

• Oracle Directory Manager
• Oracle directory replication server

The two Oracle directory server instances and the Oracle directory replication server connect to OID Monitor by way of the operating system.

Figure 2-4 A Typical Oracle Internet Directory Node

Text description of the illustration oidag005.gif

An Oracle Internet Directory node (Figure 2-4) includes the following major components:

Table 2-2  Components of an Oracle Internet Directory Node

Component	Description
Oracle directory server instance	Also called either an LDAP server instance or a directory server instance. A directory server instance services directory requests through a single Oracle Internet Directory dispatcher process listening at specific TCP/IP ports. There can be more than one directory server instance on a node, each listening on different ports. One instance comprises one dispatcher process and one or more server processes. By default, there is one server process for each instance, but you can increase this number. Oracle Internet Directory dispatcher and server processes can use multiple threads to distribute the load.
Oracle directory replication server	Also called a replication server. It tracks and sends changes to replication servers in another Oracle Internet Directory system. There can be only one replication server on a node. You can choose whether or not to install and use the replication server.
Oracle9i database	Stores the directory data. Oracle Corporation strongly recommends that you dedicate a database for use by the directory. The database can reside on the same node as the servers or on a separate node.
OID Monitor (OIDMON)	Initiates, monitors, and terminates the LDAP server processes. If you elect to install a replication server, OID Monitor controls it. When you issue commands through OID Control Utility (OIDCTL) to start or stop directory server instances, your commands are interpreted by this process. OID Monitor executes the LDAP server instance startup and shutdown requests that you initiate from OID Control Utility. OID Monitor also monitors servers and restarts them if they have stopped running for abnormal reasons. When it starts a server instance, OID Monitor adds an entry into the directory instance registry and updates data in a process table. When it shuts down the directory server instance, it deletes the registry entry as well as the data corresponding to that particular instance from the process table. If OID Monitor restarts a server that has stopped abnormally, it updates the registry entry with the start time of the server. All OID Monitor activity is logged in the file ORACLE_HOME/ldap/log/oidmon.log. This file is on the Oracle Internet Directory server file system. OID Monitor checks the state of the servers through mechanisms provided by the operating system.
OID Control Utility (OIDCTL)	Communicates with OID Monitor by placing message data in Oracle Internet Directory server tables. This message data includes configuration parameters required to run each Oracle directory server instance.

The Oracle directory replication server uses LDAP to communicate with an Oracle directory (LDAP) server instance. To communicate with the database, all components use OCI/Oracle Net Services. Oracle Directory Manager and the command-line tools communicate with the Oracle directory servers over LDAP.

An Oracle Directory Server Instance

Each Oracle directory server instance, also called an LDAP server instance, looks similar to what Figure 2-5 illustrates.

Figure 2-5 Oracle Directory Server Instance Architecture

Text description of the illustration oidag006.gif

LDAP clients send LDAP requests to an Oracle Internet Directory listener/dispatcher process listening for LDAP commands at its port.

The OID listener/dispatcher sends the request to the Oracle directory server which, in turn creates server processes. Multiple server processes enable Oracle Internet Directory to take advantage of multiple processor systems. The number of server processes created is determined by the configuration parameter ORCLSERVERPROCS. The default is 1 (one). A worker thread for each operation processes the client request.

Database connections from each server process are spawned as needed, depending on the value set for the configuration parameter ORCLMAXCC. The default value for this parameter is 10. The server processes communicate with the data server by way of Oracle Net Services. A Oracle Net Services Listener/Dispatcher relays the request to the Oracle9i database server.

Configuration Set Entries

The configuration parameters for each Oracle directory server instance are stored in a directory entry called a configuration set entry, or configset. A configuration set entry holds the configuration parameters for a specific instance of the directory server. When you start an instance of a server by using the OID Control Utility, the start-command you enter contains a reference to one of these configsets and uses the information it contains.

The Oracle directory server is installed with a default configuration set entry (configset0) so that you can run the directory server immediately. You can create customized configuration set entries by adding new ones that change specific parameters to meet your needs. You can view, add, and modify these entries by using either Oracle Directory Manager or the appropriate command-line tool.

Example: How Oracle Internet Directory Works

This example shows you how Oracle Internet Directory processes a search request.

1. The user or client enters a search request that is conditioned by one or more of the following options:
   • SSL: The client and server can establish a session that uses SSL encryption and authentication, or SSL encryption only. If SSL is not used, the client's message is sent in clear text.
   • Type of user: The user can seek access to the directory either as a particular user or as an anonymous user, depending on which of the two has the necessary privileges to perform the desired function.
   • Filters: The user can narrow the search by using one or more search filters, including those that use the Boolean conditions "and," "or," and "not," and those that use other operators such as "greater than, "equal to," and "less than".
2. If the user or client issues the command by using Oracle Directory Manager, then the latter invokes a query function in the Java Native Interface which, in turn, invokes a function in the C API. If the user or client uses a command-line tool, then the tool directly invokes a C function in the C API.
3. The C API, using the LDAP protocol, sends a request to a directory server instance to connect to the directory.
4. The directory server authenticates the user, a process called binding. The directory server also checks the Access Control Lists (ACLs) to verify that the user is authorized to perform the requested search.
5. The directory server converts the search request from LDAP to Oracle Call Interface (OCI)/Oracle Net Services and sends it to the Oracle9i database.
6. The Oracle9i database retrieves the information and passes it back through the chain--to the directory server, then to the C API, and, finally, to the client.

Distributed Directories

Although an online directory is logically centralized, it can physically distribute its data onto several servers. This reduces the work a single server would otherwise have to do, and enables the directory to accommodate a larger number of entries.

A distributed directory can be either replicated or partitioned. When information is replicated, the same naming contexts are stored by more than one server. When information is partitioned, each directory server stores one or more unique, non-overlapping naming contexts. In a distributed directory, some information may be partitioned and some may be replicated.

This section contains these topics:

• Replication
• Partitioning

Replication

Replication, in which the same naming contexts are stored by more than one server, improves performance by providing more servers to handle queries. It improves reliability by eliminating risks associated with a single point of failure.

Figure 2-6 shows a replicated directory.

Figure 2-6 A Replicated Directory

Text description of the illustration oidag009.gif

Each copy of a naming context that is contained within a server is called a replica. A directory server can hold both read-only and updatable replicas. Servers that hold updatable replicas are called suppliers. Their changes are propagated to other servers called consumers.

At times, the replication process may be unable to apply a change. For example, suppose that Supplier Node A sends the consumer a change, and, immediately after that, Supplier Node B sends it an update to the same entry. Then, suppose that a problem delays the transmission of the entry from Supplier Node A, but that no such problem delays transmission of the update from Supplier Node B. The result can be that the update from Supplier Node B arrives at the consumer ahead of the entry it is modifying. In this case, the replication server makes a specified number of retries to apply the change. If it fails to apply the change once that number is reached, then it moves the change to the human intervention queue, and attempts to apply the change at regular, less frequent intervals that you specify.

Partitioning

Partitioning, in which each directory server stores one or more unique, non-overlapping naming contexts, is another way of distributing directory information.

Figure 2-7 shows a partitioned directory in which some naming contexts reside on different servers.

Figure 2-7 A Partitioned Directory

Text description of the illustration oidag010.gif

In Figure 2-7, four naming contexts reside on Server A:

• dc=acme,dc=com
• c=us
• c=uk
• c=au

Two naming contexts on Server A are replicated on Server B:

• dc=acme,dc=com
• c=au

The directory uses one or more knowledge reference to locate information that is requested of Server B, but that resides on Server A. It passes this information to a client in the form of a referral.

About Knowledge References and Referrals

A knowledge reference provides the names and addresses of the various naming contexts held in another partition. In Figure 2-7, Server B uses knowledge references to point to the c=us and c=uk naming contexts on Server A. When clients request from Server B the information residing on Server A, then Server B provides them with one or more referrals to Server A. Clients can then use these referrals to contact Server A.

Typically, each directory server contains both superior and subordinate knowledge references. Superior knowledge references point upward in the DIT toward the root. They tie the partitioned naming context to its parent. Subordinate knowledge references point downward in the DIT to other partitions.

For example, in Figure 2-8, Server B holds four naming contexts, two of which are superior to the others. These two superior naming contexts use subordinate knowledge references to point to their subordinate naming contexts. Conversely, the naming context on Server A has an immediate superior residing on Server B. Server A therefore uses a superior knowledge reference to point to its parent on Server B.

Figure 2-8 Using Knowledge References to Point to Naming Contexts

Text description of the illustration oidag002.gif

Naming contexts that start at the top of the DIT obviously cannot have a knowledge reference to a superior naming context.

Kinds of Referrals

There are two kinds of referrals:

• Smart referral

  Returned to the client when the knowledge reference entry is in the scope of the search. It points the client to the server that stores the requested information.

  For example, suppose that:

  • Server A holds the naming context
    ou=server development,c=us,o=acme, and has a knowledge reference to Server B
  • Server B holds the naming context ou=sales,c=us,o=acme

  When a client sends a request to Server A for information in ou=sales,c=us,o=acme, Server A provides the user with a referral to Server B.

• Default referral

  Returned when the base object is not in the directory, and the operation is performed in a naming context on another server. A default referral typically sends the client to a server that has more knowledge about the directory partitioning arrangement.

  For example, suppose that Server A holds:

  • The naming context c=us,o=acme
  • A knowledge reference to Server PQR that has more knowledge about the overall directory partitioning arrangement

  Now suppose that a client requests information on c=uk,o=acme. When Server A finds that it does not have the c=uk,o=acme naming context, it provides the client with a referral to Server PQR. From there, the client can find the server holding the requested naming context.

  See Also: "Managing Knowledge References and Referrals"

The Oracle Directory Integration Platform

The Oracle Directory Integration Platform enables you to synchronize various directories with Oracle Internet Directory. It also makes it easier for third party metadirectory vendors and developers to develop and deploy their own connectivity agents.

This section contains these topics:

• About Metadirectories
• About the Oracle Directory Integration Platform Environment

About Metadirectories

Enterprises today often deploy multiple directories to store information for applications such as ERP systems, database applications, messaging systems, and Network Operating Systems (NOS). Managing so many different directories has many drawbacks, including:

• Increased cost--Multiple administrators must maintain essentially the same information in many different places.
• Inconsistent data--Updated information in one directory is not available to all the other directories.

A metadirectory solves these problems by synchronizing information between all enterprise directories, forming one virtual directory. It centralizes administration, thereby reducing administrative costs, and ensures that data is consistent and up-to-date across the enterprise.

For example, in a metadirectory environment, you can create a global directory entry for each employee. You can populate this entry with data from various synchronized directories--for example, Human Resources applications, messaging systems, or NOS databases. Users can then access this global entry, knowing that the data it contains is up-to-date and synchronized with each connected directory.

You can also ensure that the synchronization process respects all existing data ownership policies. For example, you can grant to only the Human Resources department the privilege to change the value of an employee's salary attribute.

About the Oracle Directory Integration Platform Environment

The Oracle Directory Integration Platform enables an enterprise to integrate its applications and other directories with Oracle Internet Directory. This platform provides all the interfaces and infrastructure necessary to keep the data in Oracle Internet Directory consistent with the data in enterprise applications and connected directories.

For example, an enterprise might want employee records in its HR database to be synchronized with Oracle Internet Directory. In addition, the enterprise may deploy certain LDAP-enabled applications (such as Oracle9iAS Portal) that need to be notified whenever changes are applied to Oracle Internet Directory. This service is called provisioning, and the Oracle Directory Integration Platform provides such applications with the necessary notifications.

Based on the nature of integration, the Oracle Directory Integration Platform provides two distinct services:

• The synchronization integration service, which keeps connected directories consistent with the central Oracle Internet Directory
• The provisioning integration service, which sends notifications to target applications periodically to reflect changes made to a user's status or information

  See Also: Part VIII: "The Oracle Directory Integration Platform"

Oracle Components and Oracle Internet Directory

Oracle Internet Directory enables Oracle components to:

• Maintain for each user a single, global identity across the application environment
• Store and administer configuration information for components in a central place

There are two general types of environment:

• Hosted--In a hosted environment, one enterprise--for example, an application service provider--makes Oracle components available to multiple other enterprises and stores information for them. In such hosted environments, the enterprise performing the hosting is called the default subscriber, and the enterprises that are hosted are called subscribers. A global administrator performs activities that span the entire directory. Another type of administrator--called a delegated administrator--may exercise roles in specific subscriber domains, or for specific applications.
• Non-hosted--In a non-hosted environment, in which there are no subscribers, the enterprise installing Oracle Internet Directory for use with Oracle components is called the default subscriber.

To make it easy for you to start using Oracle components that use Oracle Internet Directory, Oracle Universal Installer creates a default schema and directory information tree (DIT) during Oracle Internet Directory installation. This default DIT framework is the same for both hosted and non-hosted environments. It is flexible; you can modify it to suit the needs of your deployment.

During Oracle Internet Directory installation, the Oracle Universal Installer creates:

• Base schema elements--that is, attributes and object classes--some of which are defined by the Internet Engineering Task Force (IETF), and some of which are specific to Oracle components
• The root Oracle context, a directory container of information common to all Oracle components in the entire site
• Default subscriber Oracle context containing information common to all Oracle components in the subscriber's subtree
• Subscriber Oracle context containing information common to all Oracle components in the subscriber's subtree
• A default password policy for each subscriber. This password policy will then apply to all users in the subscriber user base.

  See Also: Chapter 14, "Oracle Components and Oracle Internet Directory" for a fuller discussion of the way Oracle components use Oracle Internet Directory and the default schema and DIT "Task 3: Reset the Default Security Configuration" for a discussion of the security configuration--including that for an environment with Oracle components--installed with Oracle Internet Directory