|Oracle® Fusion Middleware Administrator's Guide for Oracle Internet Directory
11g Release 1 (11.1.1)
Part Number E10029-02
This chapter contains these topics:
See Also:"Related Documents" for suggestions on further reading about LDAP-compliant directories
This section contains these topics:
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.
As shown in Figure 3-1, an Oracle Internet Directory node includes the following major elements:
Table 3-1 An Oracle Internet Directory Node
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.
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.
Manages Oracle Internet Directory as an Oracle Fusion Middleware system component. OPMN uses the directives in the OID component snippet in
Initiates, monitors, and terminates the LDAP server and replication server processes. When you invoke process management commands, such as
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
OID Monitor checks the state of the servers through mechanisms provided by the operating system.
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.
Figure 3-2 illustrates an Oracle directory server instance, also called an LDAP server instance.
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:
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.
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:
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 19, "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 28, "Managing Directory Access Control."
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
Groups that can be used in access control policies.
The directory schema supports directory group objects through the standard
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
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".
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 32, "Planning, Deploying and Managing Realms".
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 41, "Developing Plug-ins for the Oracle Internet Directory Server," describes this information.
A special entry containing information about the encryption and verifier attribute types. Chapter 29, "Managing Password Verifiers," describes this information.
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 27, "Managing Password Policies".
This example shows you how Oracle Internet Directory processes a search request.
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".
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.
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.
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:
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
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 (
The DN for this "Anne Smith" entry is:
cn=Anne Smith,ou=Server Development,c=uk,o=acme
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.
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. This method enhances Oracle Internet Directory performance, and is especially useful in smaller and medium-sized enterprises.
You can use entry caching only in the case of a single server, single instance Oracle Internet Directory node.
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.
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
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
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
This section contains these topics:
Attributes contain two kinds of information.
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.
Table 3-2 Attributes Created with Each New Entry
Name of the person creating the entry
Time of entry creation in UTC (Coordinated Universal Time)
Name of person modifying the entry
Time of last entry modification in UTC
Moreover, when a user modifies an entry, Oracle Internet Directory automatically updates the
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
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.
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|
Common name of an entry—for example,
The DN of the component in a Domain Name System (DNS)—for example,
Photographic image in JPEG format. This is stored in binary format.
Name of an organization—for example,
Name of a unit within an organization—for example,
Distinguished name of the person who owns the entry, for example,
Last name of a person—for example,
Telephone number—for example,
See Also:"Oracle Identity Management LDAP Attribute Reference" in Oracle Fusion Middleware User Reference for Oracle Identity Management for a list of several attributes Oracle Internet Directory provides.
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 User Reference for Oracle Identity Management
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.
Chapter 19, "Managing Directory Schema" for information on viewing matching rules.
"About LDAP Matching Rules" in Oracle Fusion Middleware User Reference for Oracle Identity Management
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.
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
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
Note:You cannot use an attribute option within a DN. For example, the following DN is incorrect:
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
sn), and the optional attributes
userPassword. When you define an entry by using the
organizationalPerson object class, you must specify values for
sn). You do not need to provide values for
This section contains these topics:
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
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.
There are three types of 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
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
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
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.
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.
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
See Also:Chapter 11, "Managing Naming Contexts" for instructions on how to publish a naming context
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
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.
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 Database Globalization Support Guide in the Oracle Database Documentation Library for a detailed discussion of Globalization Support
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:
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.
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
In Figure 3-6, four naming contexts reside on Server A:
Two naming contexts on Server A are replicated on Server B:
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.
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=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.
Naming contexts that start at the top of the DIT obviously cannot have a knowledge reference to a superior naming context.
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.
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
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.
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
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.
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.
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 username 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.
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:
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 to reflect changes made to a entries of interest, such as users and groups
This section contains these topics:
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:
Managing policies associated with these identities. These include:
Privileges delegated to existing identities
Oracle Internet Directory, a scalable, robust LDAP Version 3-compliant directory service implemented on the Oracle Database.
Oracle Virtual Directory, which provides access to multiple data sources without the need to synchronize or move data from its native location. Oracle Virtual Directory can provide multiple application-specific views of identity data and can also be used to secure data access to the application-specific sources and enhance high-availability to existing data-sources.
Oracle Directory Integration Platform, which permits synchronization between Oracle Internet Directory and other directories and user repositories.
Oracle Delegated Administration Services, which provides trusted proxy-based administration of directory information by users and application administrators. (Oracle Internet Directory 11g Release 1 (11.1.1) is compatible with Oracle Single Sign-On 10g (10.1.4.3.0) or later.)
Oracle Single Sign-On, which provides single sign-on access to Oracle and third party web applications. (Oracle Internet Directory 11g Release 1 (11.1.1) is compatible with Oracle Delegated Administration Services 10g (10.1.4.3.0) or later.)
Oracle Identity Federation, which provides a self-contained federation solution that combines the ease of use and portability of a standalone application with a scalable, standards-based proven interoperable architecture.
Oracle Identity Manager is a provisioning system for automatically granting and revoking access to enterprise applications and managed systems.
Oracle Role Manager is an enterprise-class application for managing business and organizational relationships, roles, and entitlements.
Oracle Enterprise Single Sign-On is an access management system for delivering enterprise authentication and single sign-on for mainframe, client/server and Web applications
Oracle Access Manager is a management system for configuring digital identities and controlling access to protected applications and content in heterogeneous environments, primarily on the Web.
Oracle Adaptive Access Manager is the solution for web access real-time fraud detection and multi-factor online authentication security for the enterprise.
Oracle Entitlements Server, which enables application developers to externalize and centralize fine-grained authorization policies that would previously have been embedded within applications.
Oracle Authentication Services for Operating Systems, which enables you to centralize storage, authentication, and management of user identities on Linux and UNIX systems using Oracle Internet Directory.
While Oracle Identity Management is designed to provide an enterprise infrastructure for Oracle products, it can also serve as a general-purpose identity management solution for user-written and third-party enterprise applications. It provides a robust and scalable enterprise-wide identity management platform for third-party applications, hardware, and network operating systems. Custom applications can leverage Oracle Identity Management through a set of documented and supported services and APIs, for example:
Oracle Internet Directory provides LDAP APIs for C, Java, and PL/SQL, and is compatible with other LDAP SDKs.
Oracle Delegated Administration Services provide a core self-service console that may be customized to support third-party applications. In addition, it provides several services for building customized administration interfaces that manipulate directory data.
The Oracle Directory Synchronization Service facilitates the development and deployment of custom solutions for synchronizing Oracle Internet Directory with third-party directories and other user repositories.
The Oracle Directory Integration Platform enables you to provision third-party applications and integrate the Oracle environment with other provisioning systems.
Oracle Single Sign-On provides APIs for developing and deploying partner applications that share a single sign-on session with other Oracle Web applications.
In addition, Oracle works with third-party application vendors to ensure that their applications can leverage Oracle Identity Management out of the box.
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.
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.
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".
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:
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.
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:
Retrieves the necessary connect information from the RAD
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.
Figure 3-8 shows where resource information is located in the DIT.
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.
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 User Reference for Oracle Identity Management
Oracle Fusion Middleware Publishing Reports to the Web with Oracle Reports Services