3 Understanding Oracle Internet Directory Concepts and Architecture

This chapter provides a description of Oracle Internet Directory architecture and conceptual descriptions of Oracle Internet Directory basic elements such as directory entities, attributes, object classes, naming contexts, and security management.

This chapter includes the following sections:

3.1 Oracle Internet Directory Architecture

This section contains these topics:

3.1.1 An Oracle Internet Directory Node

An Oracle Internet Directory node consists of one or more directory server instances connected to the same directory store. The directory store—that is, the repository of the directory data—is an Oracle Database.

Note:

All Oracle Internet Directory instances in the same domain connect to the same Oracle Database.

Figure 3-1 shows the various directory server elements and their relationships running on a single node.

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

  • The Oracle directory server non-SSL port (3060 by default)

  • The Oracle directory server SSL-enabled port (3131 by default)

  • The OID Monitor

LDAP is used for connections between directory server and:

  • Oracle Directory Services Manager

  • Oracle directory replication server

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

Note:

Beginning with Oracle Internet Directory 11g Release 1 (11.1.1.7.0), you can specify that Oracle Internet Directory server call OCIPing() to send keep alive messages to its Oracle Database. The frequency of these messages is determined by the new orclMaxTcpIdleConnTime attribute.

Setting this attribute to a value less than the timeout value of the firewall between Oracle Internet Directory server and the Oracle Database prevents the Database connection from being dropped.

For more information, see Section 9.1.4, "Attributes of the DSA Configuration Entry."

Figure 3-1 A Typical Oracle Internet Directory Node

This illustration is described in the text.

As shown in Figure 3-1, an Oracle Internet Directory node includes the following major elements:

Table 3-1 An Oracle Internet Directory Node

Element Description

Oracle directory server instance

Also called either an LDAP server instance or a directory server instance, it 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, listening on different ports.

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 to configure the replication server.

Oracle Database Server

Stores the directory data. The database can reside on the same node as the directory server instances.

Note: To meet the need of Oracle Internet Directory's potentially large data volume as customer data size grows and to achieve continuous optimized database query performance, Oracle strongly recommends that you dedicate a database for exclusive use by the directory.

Oracle Process Manager and Notification Server (OPMN)

Manages Oracle Internet Directory as an Oracle Fusion Middleware system component. OPMN uses the directives in the OID component snippet in ORACLE_INSTANCE/config/OPMN/opmn/opmn.xml and invokes OIDMON and OIDCTL as required. The command-line utility is ORACLE_INSTANCE/bin/opmnctl.

OID Monitor (OIDMON)

Initiates, monitors, and terminates the LDAP server and replication server processes. When you invoke process management commands, such as oidctl or opmnctl, or when you use Fusion Middleware Control to start or stop server instances, your commands are interpreted by this process.

OIDMON also monitors servers and restarts them if they have stopped running for abnormal reasons.

OIDMON starts a default instance of OIDLDAPD. If the default instance of OIDLDAPD is stopped using the OIDCTL command, then OIDMON stops the instance. However, when OIDMON is restarted by OPMN, OIDMON restarts the default instance.

All OID Monitor activity is logged in the file
ORACLE_INSTANCE/diagnostics/logs/OID/Component_Name/oidmon-xxxx.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. Normally used from the command line only to stop and start the replication server. OIDCTL is also used for checking the status of Oracle Internet Directory.

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 Services Manager and the command-line tools communicate with the Oracle directory servers over LDAP.

3.1.2 An Oracle Directory Server Instance

Figure 3-2 illustrates an Oracle directory server instance, also called an LDAP server instance.

Figure 3-2 Oracle Directory Server Instance Architecture

Description of Figure 3-2 follows
Description of ''Figure 3-2 Oracle Directory Server Instance Architecture''

One instance comprises one dispatcher process and one or more server processes. The Oracle Internet Directory dispatcher and server processes can use multiple threads to distribute the load. LDAP clients send LDAP requests to an Oracle Internet Directory listener/dispatcher process listening for LDAP commands at its port.

Oracle Internet Directory listener/dispatcher starts a configured number server process at startup time. The number of server processes is controlled by the orclserverprocs attribute in the instance-specific configuration entry. The default value for orclserverprocs is 1. Multiple server processes enable Oracle Internet Directory to take advantage of multiple processor systems.

The Oracle Internet Directory dispatcher process sends the LDAP connections to the Oracle Internet Directory server process in a round robin fashion. The maximum number of LDAP connections accepted by each server is 1024 by default. This number can be increased by changing the attribute orclmaxldapconns in the instance-specific configuration entry, which has a DN of the form:

cn=componentname,cn=osdldapd,cn=subconfigsubentry

3.1.3 Oracle Internet Directory Ports

An Oracle Internet Directory component can be created by Oracle Identity Management 11g Installer or by a command-line tool. The program that creates Oracle Internet Directory follows specific steps in assigning the SSL and non-SSL port. First, it attempts to use 3060 as the non-SSL port. If that port is unavailable, it tries ports in the range 3061 to 3070, then 13060 to 13070.

Similarly, the program that creates Oracle Internet Directory attempts to use 3131 as its SSL port, then ports in the range 3132 to 3141, then 13131 to 13141.

3.1.4 Directory Metadata

Directory metadata is the information used by the directory server during run time for processing LDAP requests. It is stored in the underlying data repository. During startup, the directory server reads this information and stores it in a local metadata cache. It then uses this cache during its run time to process incoming LDAP operation requests.

Note:

The metadata cache is a write-through cache. An LDAP operation first writes to the database and then invalidates the corresponding cache entry. A subsequent search of that entry causes the cache to be refreshed.

The directory server has the following types of metadata in its local metadata cache:

  • Directory Schema

    The definitions of object classes, attributes, and matching rules supported by the directory server. The directory server uses this information during creation and modification of directory objects. A directory object is a collection of object classes and their associated attributes and matching rules. See Chapter 21, "Managing Directory Schema."

  • Access control policy point (ACP)

    A directory administrative domain for defining and controlling access to the information in that domain. The directory server uses ACPs when determining whether to allow a certain LDAP operation performed by a user. See Chapter 30, "Managing Directory Access Control."

  • Root DSE entry

    The root DSE (Directory Service Agent-Specific Entry) contains several attributes that store information about the directory server itself. For example, these attributes contain the following information items, to mention just a few:

    • Naming contexts DNs

    • Sub Schema Subentry DN

    • Superior references (referrals) DNs

    • Special entry DNs like Oracle Internet Directory configuration and registry containers

    • Special Entry DNs like change log and change status containers

    • DN of replications agreement container

    See "Attributes of the DSE".

  • Privilege groups

    Groups that can be used in access control policies.

    The directory schema supports directory group objects through the standard groupofuniquenames and groupofnames object classes. These object classes hold information for such groups as distribution lists and mailing lists to mention just two.

    Oracle Internet Directory extends these standard group objects through an auxiliary object class called orclprivilegegroup. This object class, which supports privilege groups that can be used in access control policies, provides flexibility to grant or deny access to groups of users. The directory server uses this information during:

    • LDAP bind operations to find out the subscribed privileged groups for a given user

    • Access control policy evaluation if the policy has directives that grant or deny access to privileged groups

    See Also:

    Chapter 14, "Managing Dynamic and Static Groups"

  • Catalog entry

    A special entry containing information about indexed attributes in the underlying database. The directory uses this information during directory search operations. See "About Indexing Attributes".

  • Common entry

    A special entry containing information about hosted companies. A hosted company is an enterprise to which another enterprise provides services. The metadata in this entry includes the hosted company DN, user search base, nickname and other attributes, all of which are described in Chapter 34, "Planning, Deploying and Managing Realms".

  • Plug-in entry

    A special entry containing information about the kind of operation that triggers a plug-in event, and the point in the operation when that plug-in is to be triggered. Chapter 45, "Developing Plug-ins for the Oracle Internet Directory Server," describes this information.

  • Password verifier entry

    A special entry containing information about the encryption and verifier attribute types. Chapter 31, "Managing Password Verifiers," describes this information.

  • Password policy entry

    One or more special entries containing information about policies enforced by the directory server for the user password credentials. The directory server uses this information during run time to enforce the password policies. See Chapter 29, "Managing Password Policies".

3.2 How Oracle Internet Directory Processes a Search Request

This section describes the following search operations:

3.2.1 Standard LDAP Search Operations

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. The C API, using the LDAP protocol, sends a request to a directory server instance to connect to the directory.

  3. 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.

  4. The directory server converts the search request from LDAP to Oracle Call Interface (OCI)/Oracle Net Services and sends it to the Oracle Database.

  5. The Oracle 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.

Note:

The maximum number of attributes you can specify in a search filter is 255.

3.2.2 Persistent LDAP Search Operations

Beginning with Release 11gR1 (11.1.1.9), Oracle Internet Directory supports persistent search operations. A persistent search continues after the initial search results are returned by the Oracle Internet Directory server to the LDAP client. After the initial search is finished, the connection to the server is kept alive until the client unbinds or abandons the operation.

A persistent search operation allows a client to receive notifications if an entry in the search scope is modified. If an entry is modified, the server sends a new copy of the entry to the LDAP client along and, if requested, an Entry Change Notification control that describes the change.

A persistent search operation uses the following controls:

  • Persistent Search control - The LDAP client sends this control to the Oracle Internet Directory server with the persistent search request including specific options for returning the search results.

  • Entry Change Notification control - If requested by the client, the server returns this control to the client for each changed entry that matches the search criteria in the search request.

Persistent searches are not be supported on special entries such as configuration entries, referrals, and entry aliases.

Persistent searches need to keep connections from the LDAP client to the server alive. Therefore, if a large number of persistent searches are issued, the LDAP connection limit might be reached and new connections could not be established. To prevent this situation from occurring, the orclmaxpsearchconns instance-specific attribute determines the maximum number of connections allowed for an LDAP persistent search operation.

An LDAP persistent search operation for Oracle Internet Directory follows this sequence:

  1. The LDAP client authenticates to the Oracle Internet Directory server.

  2. The client issues a persistent search request with an attached Persistent Search control. This control specifies the following information:

    • changesOnly - If this field is FALSE, the server returns the initial set of results that match the search criteria. Or, if the field is TRUE, the server does not return these entries.

    • changeTypes - This field specifies the type of changes the client wants to track. If subsequent changes are made to entries that match the search criteria, the server returns these changed entries to the client.

      The changeTypes field is a logical OR of one or more of these values:

      • add: 1

      • delete: 2

      • modify: 4

      • moddn: 8

    • returnECs - If this field is TRUE, the server also returns an Entry Change Notification control along with each changed entry.

  3. The OID server processes the persistent search request using the options described in the previous step.

    The server does not return the SearchResultDone message to the client, because the connection must be kept alive until the client unbinds or abandons the operation.

  4. If the server returns search results, the client processes these results as required.

  5. The LDAP client ends the Persistent Search operation by sending an unbind or abandon request.

See Also:

3.3 Directory Entries

In an online directory, each collection of information about an object is called an entry. An entry can include, for example, information about an employee, a conference room, an e-commerce partner, or a shared network resource such as a printer.

This section contains these topics:

3.3.1 Distinguished Names (DNs) and Directory Information Trees (DITs)

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 3-3.

Figure 3-3 A Directory Information Tree

Description of Figure 3-3 follows
Description of ''Figure 3-3 A Directory Information Tree''

The DIT in Figure 3-3 includes entries for two employees of Acme Corporation who are both named Anne Smith. It is structured along geographical and organizational lines. The Anne Smith contained in 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 contained in 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 United Kingdom of Great Britain and Northern Ireland (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 concatenation of RDNs that reflects parent-child relationships in the DIT. Within the DN, RDNs are 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 3-3, 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—for example, you could identify each employee with a unique number.

3.3.2 Entry Caching

To make operations on entries quick and efficient, Oracle Internet Directory uses entry caching. When you enable this feature, 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.

Notes:

  • Beginning with Release 11gR1 (11.1.1.6), the entry cache resides in shared memory, so multiple Oracle Internet Directory server instances on the same host can share the same cache. Attributes for configuring the cache now reside in the DSA configuration entry.

  • The entry cache is a write-through cache. An LDAP operation first writes to the database and then invalidates the corresponding cache entry. A subsequent search of that entry causes the cache to be refreshed.

See Also:

3.4 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 3-4, 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 3-4 is also an entry with attributes, although the attributes for each are not shown.

Figure 3-4 Attributes of the Entry for Anne Smith

Description of Figure 3-4 follows
Description of ''Figure 3-4 Attributes of the Entry for Anne Smith''

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:

3.4.1 Kinds of Attribute Information

Attributes contain two kinds of information.

  • Application Attributes

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

  • System Configuration Attributes

    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.

    See Also:

    Chapter 9, "Managing System Configuration Attributes" for more information about system configuration attributes.

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

Table 3-2 Attributes Created with Each New Entry

Attribute Description

creatorsName

Name of the person creating the entry

createTimestamp

Time of entry creation in UTC (Coordinated Universal Time)

modifiersName

Name of person modifying the entry

modifyTimestamp

Time of last entry modification 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.

See Also:

Chapter 9, "Managing System Configuration Attributes" for instructions on configuring system configuration attributes.

3.4.2 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.

3.4.3 Common LDAP Attributes

Oracle Internet Directory implements all of the standard LDAP attributes. Some of the more common ones defined by RFC 2798 of the Internet Engineering Task Force (IETF) are shown in Table 3-3.

Table 3-3 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. This is stored in binary format.

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.

See Also:

"Oracle Identity Management LDAP Attribute Reference" in Oracle Fusion Middleware Reference for Oracle Identity Management for a list of several attributes Oracle Internet Directory provides.

3.4.4 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.

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

See Also:

"About LDAP Attribute Syntax" in Oracle Fusion Middleware Reference for Oracle Identity Management.

3.4.5 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.

See Also:

3.4.6 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 givenName;lang-fr=Jean, the base attribute is givenName; the French value for that base attribute is givenName;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.

Note:

You cannot use an attribute option within a DN. For example, the following DN is incorrect: cn;lang-fr=Jean, ou=sales,o=acme,c=uk.

See Also:

Chapter 13, "Managing Directory Entries."

3.5 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 and must have values, others are optional and can be empty.

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.

This section contains these topics:

3.5.1 Subclasses, Superclasses, and Inheritance

A subclass is an object class derived from another object class. The object class from which a subclass 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 also inherit attributes that their superclasses have inherited.

Note:

In itself, an object class contains no values. Only an instance of an object class—that is, an entry—contains values. When a subclass inherits attributes from a superclass, it inherits only the attribute definitions of the superclass.

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

3.5.2 Object Class Types

There are three types of object classes:

  • Structural

  • Auxiliary

  • Abstract

3.5.2.1 Structural Object Classes

Structural object classes describe the basic aspects of an object. Most of the object classes that you use are structural object classes, and every entry should belong to at least one structural object class. Examples of structural object classes are person and groupOfNames.

These object classes model real-world entities and their physical or logical attributes. Examples include people, printers, and database connections.

Structural object classes use structure rules to place restrictions on the kinds of objects 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.

3.5.2.2 Auxiliary Object Classes

Auxiliary object classes are groupings of optional attributes that expand the existing list of attributes in an entry. Unlike structural object classes, they do not place restrictions on where an entry may be stored, and you can attach them to any entry regardless of that entry's location in the DIT.

Note:

Oracle Internet Directory does not enforce structure rules. It therefore handles both structural and auxiliary object classes in the same way.

3.5.2.3 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 and 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 (ACP) where this attribute is defined

  • orclEntryLevelACI: Access control policy pertaining to only a specific entity, for example, a special user

    See Also:

3.6 Naming Contexts

A directory naming context is a subtree that resides entirely on one server. It must be a complete subtree, 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 directory information tree (DIT).

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

Figure 3-5 Correct and Incorrect Naming Contexts

Description of Figure 3-5 follows
Description of ''Figure 3-5 Correct and Incorrect Naming Contexts''

To enable users to discover specific naming contexts, you can publish those naming contexts in Oracle Internet Directory by using ldapmodify.

See Also:

Chapter 11, "Managing Naming Contexts" for instructions on how to publish a naming context

3.7 Security

Oracle Internet Directory is a key element of Oracle Identity Management. You can deploy multiple Oracle components to work against a shared instance of Oracle Internet Directory. This sharing allows an enterprise to simplify security management across all applications.

In addition to the role it plays in the Oracle Identity Management infrastructure, Oracle Internet Directory provides many powerful features for protecting information.

Security features within Oracle Internet Directory itself include:

  • The Secure Sockets layer: Ensuring that data is not modified, deleted, or replayed during transmission

  • Data privacy: Ensuring that data is not inappropriately observed while it is stored in Oracle Internet Directory

  • Password policies: Establishing and enforcing rules for how passwords are defined and used

  • Authorization: Ensuring that a user reads or updates only the information for which that user has privileges

  • Password protection: Ensuring that passwords are not easily discovered by others

  • Authentication: Ensuring that the identities of users, hosts, and clients are correctly validated

You can use all these features to enforce a uniform security policy for multiple applications enabled for Oracle Internet Directory, and do so in either an enterprise or hosted environment. You do this by deploying 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.

You can also use security features of the underlying Oracle Database, such as Transparent Data Encryption and Database Vault, to protect Oracle Internet Directory data.

See Also:

Part III, "Advanced Administration: Security"

3.8 Globalization Support

Oracle Internet Directory follows LDAP Version 3 internationalization (I18N) standards. These standards require that the database storing directory data use Unicode Transformation Format 8-bit (UTF-8) character set. With Oracle9i, Oracle added a new UTF-8 character set called AL32UTF8. This database character set supports the latest version of Unicode (3.2), including the latest supplementary characters. 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 are involved in the Oracle Internet Directory implementation, Oracle Internet Directory ensures that the correct character encoding is used with each API.

Globalization Support means support for 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. An ASCII representation of a simplified Chinese directory entry definition 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 an ASCII representation of a simplified Chinese directory entry definition.

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

The Oracle directory server and database tools are no longer restricted to run on a UTF8 database. However, you must ensure that all characters in the client character set are included in the database character set (with same or different character codes) if the database underlying the Oracle Internet Directory server is not AL32UTF8 or UTF8. Otherwise, there may be data loss during LDAP add, delete, modify, or modifydn operations if the client data cannot be mapped to the database character set.

Oracle Directory Services Manager uses Unicode (UTF-16—that is, fixed-width 16-bit Unicode). It can support internationalized character sets.

See Also:

3.9 Distributed Directories

Although an online directory is logically centralized, it can be physically distributed onto several servers. This distribution 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, one or more unique, non-overlapping naming contexts are stored on each directory server. In a distributed directory, some information may be partitioned and some may be replicated.

This section contains these topics:

3.9.1 Directory Replication

Replication is the process of copying and maintaining the same naming contexts on multiple directory servers. See Chapter 6, "Understanding Oracle Internet Directory Replication" for a discussion of replication concepts.

3.9.2 Directory Partitioning

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

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

Figure 3-6 A Partitioned Directory

Description of Figure 3-6 follows
Description of ''Figure 3-6 A Partitioned Directory''

In Figure 3-6, four naming contexts reside on Server A:

  • dc=acme,dc=com

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

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

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

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

  • dc=acme,dc=com

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

The directory uses one or more knowledge references 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.

3.10 Knowledge References and Referrals

A knowledge reference provides the names and addresses of the various naming contexts held in another partition. For example, in Figure 3-6, Server B uses knowledge references to point to the c=us and c=uk naming contexts on Server A. When Server B is asked for information residing on Server A, it sends back 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 3-7, 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 3-7 Using Knowledge References to Point to Naming Contexts

This illustration is described in the text.

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

Notes:

  • There are presently no Internet standards for enforcing the validity of knowledge references, and Oracle Internet Directory does not do so. It is up to the administrator to ensure consistency among knowledge references within an enterprise network.

  • Oracle recommends that permission for managing knowledge reference entries be restricted, as is the case with any other privileged administrative function such as schema or access control.

There are two kinds of referrals:

  • Smart referrals

    These are 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 referrals

    These are 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 detailed information 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:

    Chapter 20, "Managing Knowledge References and Referrals."

3.11 Oracle Delegated Administration Services and the Oracle Internet Directory Self-Service Console

Oracle Delegated Administration Services is a set of pre-defined, Web-based units for performing directory operations on behalf of a user. This set of services frees directory administrators from the routine tasks of directory management by enabling them to delegate specific functions to other administrators and to end users. It provides most of the functionality that directory-enabled applications require, such as creating a user entry, creating a group entry, searching for entries, changing user passwords, and other employee-specific data.

Note:

All references to Oracle Delegated Administration Services in this chapter refer to Oracle Delegated Administration Services 10g (10.1.4.3.0) or later.

You can use Oracle Delegated Administration Services to develop your own tools for administering application data in the directory. Or you can use the Oracle Internet Directory Self-Service Console, a tool based on Oracle Delegated Administration Services that comes ready-to-use with Oracle Internet Directory. This console is used by several Oracle components to provide delegated administration.

See Also:

Oracle Identity Management Guide to Delegated Administration in the 10g (10.1.4.0.1) library.

3.12 The Service Registry and Service to Service Authentication

The Service Registry and the Service to Service Authentication framework are Oracle Internet Directory features that facilitate integration between Oracle technology components that request services from one another. The Service Registry provides a place to store information, so that the components can discover each other. The Service to Service Authentication framework allows one component to authenticate to another and establishes trust among them.

The Service Registry is a container in Oracle Internet Directory (under cn=Services, Cn=OracleContext) where components store connectivity information, such as protocol, and other information, such as type of service. During installation, each OCS component registers its information in the Registry. At run-time the components discover information registered by other components. Service Registry objects are stored in the Oracle Internet Directory DIT in a component-specific Services container in the rootOracleContext.

Service to Service Authentication is a framework that allows one service to authenticate to another and establish trusts among the services. At install time, each of the client services is provisioned with a user name and password in Oracle Internet Directory. In addition, each target service defines an authorization role in Oracle Internet Directory to control which components should it trust. When a component requests services of another component, the requestor must authenticate to the target service like any other client, using its own identity and credentials. The requesting service must also be listed in the Target services Trusted Application group (Default Group: contrasted Applications, counterpoise, cn=OracleContext). The requesting service also must send the user's identity so that the target service can authenticate the user as well. The data is sent securely, using either Digest authentication or the target service's native secure authentication.

3.13 Oracle Directory Integration Platform

Oracle Directory Integration Platform enables an enterprise to integrate its applications and other directories with Oracle Internet Directory. It provides all the interfaces and infrastructure necessary to keep the data in Oracle Internet Directory consistent with that in enterprise applications and connected directories. It also makes it easier for third-party vendors and developers to develop and deploy their own connectivity agents.

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 Oracle Portal) that must be notified whenever changes are applied to Oracle Internet Directory.

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

3.14 Oracle Internet Directory and Identity Management

This section contains these topics:

3.14.1 About Identity Management

Identity management usually refers to the management of an organization's application users. Steps in their security life cycle include account creation, suspension, privilege modification, and account deletion. The managed entities may also include devices, processes, applications, or anything else that must interact in a networked environment. They may also include users outside of the organization, for example customers, trading partners, or Web services.

Identity management is important to IT deployments because it can reduce administrative costs while at the same time improving security.

The Oracle Identity Management products enable deployments to manage centrally and securely all enterprise identities and their access to various applications in the enterprise. Identity management comprises these tasks:

  • Creating enterprise identities and managing shared properties of these identities through a single enterprise-wide console

  • Creating groups of enterprise identities

  • Provisioning these identities in various services available in the enterprise. This includes:

    • Account creation

    • Account suspension

    • Account deletion

  • Managing policies associated with these identities. These include:

    • Authorization policies

    • Authentication Policies

    • Privileges delegated to existing identities

Note:

For complete information and additional resources for Oracle Identity Management, go to the Oracle Technology Network (OTN) web site at http://www.oracle.com/technetwork/index.html.

3.14.2 Identity Management Realms

An identity management realm defines an enterprise scope over which certain identity management policies are defined and enforced by the deployment. It comprises:

  • A well-scoped collection of enterprise identities—for example, all employees in the US domain.

  • A collection of identity management policies associated with these identities. An example of an identity management policy would be to require that all user passwords have at least one alphanumeric character.

  • A collection of groups—that is, aggregations of identities—that simplifies the setting of the identity management policies.

You can define multiple identity management realms within the same Oracle Identity Management infrastructure. Multiple realms enable you to isolate user populations and enforce a different identity management policy—for example, password policy, naming policy, self-modification policy—in each realm.

Each identity management realm is uniquely named to distinguish it from other realms. It also has a realm-specific administrator with complete administrative control over the realm.

3.14.2.1 Default Identity Management Realm

For all Oracle components to function, an identity management realm is required. One particular realm, created during installation of Oracle Internet Directory, is called the default identity management realm. It is where Oracle components expect to find users, groups, and associated policies whenever the name of a realm is not specified.

There can be only one default identity management realm in the directory. If a deployment requires multiple identity management realms, then one of them must be chosen as the default.

3.14.2.2 Identity Management Policies

The Oracle Identity Management infrastructure supports a flexible set of management policies which comprise:

  • Directory structure and naming policies that enable you to:

    • Customize the directory structure in Oracle Internet Directory for your deployment.

    • Specify where various identities are to be located and how they are uniquely identified.

  • Authentication policies that enable you to specify authentication methods and protocols supported by the Oracle Identity Management infrastructure

  • Identity management authorizations that enable you to control access to certain privileged services and delegate administration wherever necessary

    Note:

    In Oracle Internet Directory Release 9.0.2, the equivalent term for "identity management realm" was "subscriber."

3.15 TCP Keep-Alive

By default, Oracle Internet Directory supports TCP keep-alive as long as the TCP keep-alive mechanism is enabled at the operating system level. No specific Oracle Internet Directory configuration is required.

However, if Oracle Virtual Directory is configured with Oracle Internet Directory server, TCP keep-alive is split between Listeners (what LDAP clients connect to) and Adapters (Oracle Internet Directory or other LDAP server). For this scenario, the following configuration is required:

  • At the operating system level, enable the TCP keep-alive mechanism.

  • For Oracle Virtual Directory, set the vde.soTimeoutBackend JVM parameter to specify how long Oracle Virtual Directory should wait for a response from Oracle Internet Directory before closing the connection. In other words, this parameter tells Oracle Virtual Directory to close inactive sockets after the time specified by the parameter.

    The vde.soTimeoutBackend parameter, if configured, helps Oracle Virtual Directory detect and safely close orphan server connections caused by remote client or server failure This greatly enhances the performance of the server.

    The value of vde.soTimeoutBackend parameter is passed to the Socket that is created using the Java API as follows:

    public void setSoTimeout(int timeout) 
                throws SocketException

    The preceding method allows you to enable or disable SO_TIMEOUT with the specified timeout limit parameter, in milliseconds. With this option set to a non-zero timeout, a read() call on the InputStream associated with this Socket will block for only this amount of time. If the timeout expires, a java.net.SocketTimeoutException is raised, though the Socket is still valid. The option must be enabled prior to entering the blocking operation to have effect. The timeout must be greater than 0. A timeout of zero is interpreted as an infinite timeout.

3.16 Resource Information

To fulfill the requests of users, some Oracle components gather data from various repositories and services. To gather the data, these components require the following information:

  • Information specifying the type of resource from which the data is to be gathered. The type of resource could be, for example, an Oracle Database. This is called resource type information.

  • Information for connecting and authenticating users to the resources. This is called resource access information.

This section contains these topics:

3.16.1 Resource Type Information

Information about the resources that an application uses to service a user request is called resource type information. A resource type can be, for example, an Oracle Database or a Java Database Connectivity Pluggable Data Source. Resource type information includes such items as the class used to authenticate a user, the user identifier, and the password.

You specify resource type information by using the Oracle Internet Directory Self-Service Console.

3.16.2 Resource Access Information

Information for connecting and authenticating users to the databases is called resource access information. It is stored in an entry called a resource access descriptor (RAD) from which it can be retrieved and shared by various Oracle components.

For example, to service the request of a user for a sales report, Oracle Reports queries multiple databases. When it does this, it does the following:

  1. Retrieves the necessary connect information from the RAD

  2. Uses that information to connect to those databases and to authenticate the user requesting the data

After it has done this, it compiles the report.

You specify resource access information by using the Oracle Internet Directory Self-Service Console. You can specify resource access information for each individual user or commonly for all users. In the latter case, all users connecting to a given application use, by default, the same information to connect to the necessary databases. Oracle recommends defining default resource access information whenever an application has its own integrated account management—for example, where each user is defined within the application itself with a unique single sign-on user name.

3.16.3 Location of Resource Information in the DIT

Figure 3-8 shows where resource information is located in the DIT.

Figure 3-8 Placement of Resource Access and Resource Type Information in the DIT

This illustration is described in the text.

As Figure 3-8 shows, the resource access and resource type information is stored in the Oracle Context.

Resource access information for each user is stored in the cn=User Extensions node in the Oracle Context. In this example, the cn=User Extensions node contains resource access information for both the default user and for specific users. In the latter cases, the resource access information includes that needed for accessing both the Sales and the Bug databases.

Resource access information for each application is stored in the object identified by the application name—in this example, cn=Oracle Reports Services, cn=Products,cn=Oracle Context,dc=us,dc=acme,dc=com. This is the user information specific to that product.

Resource type information is stored in the container cn=resource types, cn=common,cn=products,cn=Oracle Context.

See Also:

  • The sections about managing your own resource information, creating user entries, configuring default resources, and creating new resource types in Oracle Identity Management Guide to Delegated Administration in the 10g (10.1.4.0.1) library for instructions for an end user to specify resource access information

  • "Plug-in Schema Elements" in Oracle Fusion Middleware Reference for Oracle Identity Management

  • Oracle Fusion Middleware Publishing Reports to the Web with Oracle Reports Services