|
Oracle® Internet Directory Administrator's Guide,
10g Release 2 (10.1.2) B14082-02 |
|
 Previous |
 Next |
|
Oracle® Internet Directory Administrator's Guide,
10g Release 2 (10.1.2) B14082-02 |
|
|
Previous |
Next |
This chapter provides conceptual descriptions of the basic elements of Oracle Internet Directory and discusses Oracle Internet Directory architecture.
This chapter contains these topics:
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.
Figure 2-1 shows the various directory server components and their relationships running on a single node.
Oracle Net Services is used for all connections between the Oracle database server and:
The object class
The Oracle directory server instance 1 non-SSL port 389
The Oracle directory server instance 2 SSL-enabled port 636
The OID Monitor
LDAP is used for connections between directory server instance 1 on non-SSL port 389 and:
Oracle Directory Manager
Oracle directory replication server
The two Oracle directory server instances and the Oracle directory replication server connect to OID Monitor by way of the operating system.
As shown in Figure 2-1, an Oracle Internet Directory node includes the following major components:
Table 2-1 Components of an Oracle Internet Directory Node
| Component | Description |
|---|---|
|
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, each 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 or not to configure the replication server. |
|
|
Stores the directory data. Oracle strongly recommends that you dedicate a database for use by the directory. The database can reside on the same node as the directory server instances. |
|
|
Oracle Process Manager and Notification Server (OPMN) |
Manages Oracle Internet Directory as an Oracle Application Server component. OPMN uses the directives in the OID component snippet in |
|
OID Monitor (OIDMON) |
Initiates, monitors, and terminates the LDAP server processes. If you elect to install a replication server, OID Monitor controls it. When you issue commands through OID Control Utility (OIDCTL) to start or stop directory server instances, your commands are interpreted by this process. OID Monitor executes the LDAP server instance startup and shutdown requests that you initiate from OID Control Utility. OID Monitor also monitors servers and restarts them if they have stopped running for abnormal reasons. When it starts a server instance, OID Monitor adds an entry into the directory instance registry and updates data in the process table. It also starts any servers that it finds in the process table. When it shuts down the directory server instance, it updates the process table. If OID Monitor restarts a server that has stopped abnormally, it updates the registry entry with the start time of the server. All OID Monitor activity is logged in the file OID Monitor checks the state of the servers through mechanisms provided by the operating system. |
|
OID Control Utility (OIDCTL) |
Communicates with OID Monitor by placing message data in Oracle Internet Directory server tables. This message data includes configuration parameters required to run each Oracle directory server instance. |
The Oracle directory replication server uses LDAP to communicate with an Oracle directory (LDAP) server instance. To communicate with the database, all components use OCI/Oracle Net Services. Oracle Directory Manager and the command-line tools communicate with the Oracle directory servers over LDAP.
Each Oracle directory server instance, also called an LDAP server instance, looks similar to what Figure 2-2 illustrates.
Figure 2-2 Oracle Directory Server Instance Architecture
One instance comprises one dispatcher process and one or more server processes. By default, there is one server process for each instance, but you can increase this number. Oracle Internet Directory dispatcher and server processes can use multiple threads to distribute the load.LDAP clients send LDAP requests to an Oracle Internet Directory listener/dispatcher process listening for LDAP commands at its port.
The Oracle Internet Directory listener/dispatcher sends the request to the Oracle directory server which, in turn creates server processes. A server process handles an LDAP operation request and connects to the Oracle database instance to access the directory store. The directory server handles the client request by generating one server process for each operation.
Multiple server processes enable Oracle Internet Directory to take advantage of multiple processor systems. The number of server processes created is determined by the configuration parameter ORCLSERVERPROCS. The default is 1 (one).
Database connections from each server process are spawned as needed, depending on the value set for the configuration parameter ORCLMAXCC. The number of database connections spawned by each server is equal to ORCLMAXCC + (ORCLMAXCC/2) + 1. The default value of ORCLMAXCC in configset0 is 2. The server processes communicate with the data server by way of Oracle Net Services. an Oracle Net Services Listener/Dispatcher relays the request to the Oracle Database.
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 runtime to process incoming LDAP operation requests.
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.
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.
The root DSE (DSA-Specific Entry) contains a number of 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 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
A special entry containing information about indexed attributes in the underlying database. The directory uses this information during directory search operations.
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 19, "Deployment of Oracle Identity Management 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. This information is described in Chapter 26, " Oracle Internet Directory Plug-in Framework".
A special entry containing information about the encryption and verifier attribute types. This information is described in Chapter 16, " Directory Storage of Password Verifiers".
A special entry containing information about the policies enforced by the directory server for the user password credentials. The directory server uses this information during runtime to enforce the password policies.
The configuration parameters for each Oracle directory server instance are stored in an entry called a configuration set entry, or configset. When you start an instance of a server by using the OID Control Utility, the start-command you enter contains a reference to one of these configuration set entries and uses the information it contains.
The Oracle directory server is installed with a default configuration set entry (configset0) so that you can run the directory server immediately. You can create customized configuration set entries with parameters to meet your specific needs.
You can view, add, and modify configuration set entries by using either Oracle Directory Manager or the appropriate command-line tool.
|
See Also:
|
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".
If the user or client issues the command by using Oracle Directory Manager, then the latter invokes a query function in the Java Native Interface which, in turn, invokes a function in the C API. If the user or client uses a command-line tool, then the tool directly invokes a C function in the C API.
The C API, using the LDAP protocol, sends a request to a directory server instance to connect to the directory.
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 directory server converts the search request from LDAP to Oracle Call Interface (OCI)/Oracle Net Services and sends it to the Oracle Database.
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.
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 2-3.
The DIT in Figure 2-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 2-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.
|
Note: In Oracle Internet Directory 10g Release 2 (10.1.2), you can use entry caching only in the case of a single server, single instance Oracle Internet Directory node. |
In a typical telephone directory, an entry for a person contains such information items as an address and a phone number. In an online directory, such an information item is called an attribute. Attributes in a typical employee entry can include, for example, a job title, an e-mail address, or a phone number.
For example, in Figure 2-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 2-4 is also an entry with attributes, although the attributes for each are not shown.
Figure 2-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:
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.
Operational 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.
To enhance your ability to search for entries, Oracle Internet Directory automatically creates several system operational attributes when you add an entry to the directory. These include:
Table 2-2 Attributes Created with Each New Entry
| Attribute | Description |
|---|---|
|
Name of the person creating the entry |
|
|
Time of entry creation in UTC (Coordinated Universal Time) |
|
|
Name of person modifying the entry |
|
|
Time of entry creation in UTC |
Moreover, when a user modifies an entry, Oracle Internet Directory automatically updates the modifiersName and modifyTimestamp attributes to, respectively, the name of the person modifying the entry, and the time of the entry modification in UTC.
|
See Also: "Setting System Operational Attributes" for instructions on configuring system operational 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 2-3.
Table 2-3 Common LDAP Attributes
| Attribute Type | Attribute String | Description |
|---|---|---|
|
|
Common name of an entry—for example, |
|
|
domainComponent |
|
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, |
|
|
owner |
|
Distinguished name of the person who owns the entry, for example, |
|
|
Last name of a person—for example, |
|
|
telephoneNumber |
|
Telephone number—for example, |
|
See Also: "Oracle Identity Management LDAP Attribute Reference" in Oracle Identity Management User Reference 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.
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.
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.
|
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:
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.
There are three types of object classes:
Structural
Auxiliary
Abstract
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.
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.
The top object class includes the mandatory attribute objectClass as well as several optional attributes. The optional attributes in top are:
orclGuid—Global identification which remains constant if the entry is moved
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:
|
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 2-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 2-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 either Oracle Directory Manager or ldapmodify.
Oracle Internet Directory is a key element of the Oracle Identity Management Infrastructure. This enables you to deploy multiple Oracle components to work against a shared instance of Oracle Internet Directory and associated infrastructure pieces. 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.
These security features within Oracle Internet Directory itself include:
Data integrity: Ensuring that data is not tampered with during transmission
Data privacy: Ensuring that data is not inappropriately observed during transmission between Oracle Internet Directory and other components in the network.
Authentication: Ensuring that the identities of users, hosts, and clients are correctly validated
Authorization: Ensuring that a user reads or updates only the information for which that user has privileges
Password policies: Establishing and enforcing rules for how passwords are defined and used
Password protection: Ensuring that passwords are not easily discovered by others
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.
|
See Also:
|
Oracle Internet Directory follows LDAP Version 3 internationalization (I18N) standards. These standards require that the database storing directory data use UTF-8 (Unicode Transformation Format 8-bit) 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), Oracle directory replication server (OIDREPLD), and Oracle directory integration and provisioning server (ODISRV)—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, be sure 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 Manager, a Java-based tool, internally uses Unicode (UTF-16—that is, fixed-width 16-bit Unicode). It can support internationalized character sets.
|
See Also:
|
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. Some features of replication are:
It improves performance by providing more servers to handle queries, and reliability by eliminating risks associated with a single point of failure.
Full replication involves propagating the entire DIT to another node.
Partial replication involves propagating one or more subtrees, rather than the entire DIT, to another node.
Each copy of a naming context contained within a server is called a replica. Replicas can be read-only, updatable, or both. Servers that hold updatable replicas are called suppliers. Their changes are propagated to other servers called consumers.
The directory servers that participate in the replication of a given naming context form what is called a directory replication group (DRG). The relationship among the directory servers in a DRG is represented on each node by a special directory entry called a replication agreement. In a DRG, the protocol for transferring data between nodes can be based on either Oracle Database Advanced Replication or LDAP.
A DRG can be either single-master, multimaster, or fan-out.
A single-master replication group has only one supplier replicating changes to one or more consumers. Only the supplier can be updated, and consumers are read-only.
Multimaster replication, also called peer-to-peer or n-way replication, enables multiple sites, acting as equals, to manage groups of replicated data. In a multimaster replication environment, each node is both a supplier and a consumer node, and the entire directory is replicated on each node.
A fan-out replication group, also called a point-to-point replication group, has a supplier replicating directly to a consumer. That consumer can then replicate to one or more other consumers. The replication can be either full or partial.
Figure 2-6 shows a replicated directory.
|
Note: Although there are no Internet standards for directory replication yet, such standards are being developed by the IETF. Oracle Internet Directory replication adheres to the IETF standard proposal for representing directory change information in change logs. It can use standard LDAP as a transport for transmitting these change logs between Oracle Internet Directory replicas. |
|
See Also: Chapter 24, " Oracle Internet DirectoryReplication Concepts" for a more detailed discussion of replication, including: Oracle Database Advanced Replication architecture, LDAP-based replication, change log purging, conflict resolution, and the replication process |
Partitioning, in which each directory server stores one or more unique, non-overlapping naming contexts, is another way of distributing directory information.
Figure 2-7 shows a partitioned directory in which some naming contexts reside on different servers.
In Figure 2-7, 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 reference to locate information that is requested of Server B, but that resides on Server A. It passes this information to a client in the form of a referral.
A knowledge reference provides the names and addresses of the various naming contexts held in another partition. For example, in Figure 2-7, 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 2-8, Server B holds four naming contexts, two of which are superior to the others. These two superior naming contexts use subordinate knowledge references to point to their subordinate naming contexts. Conversely, the naming context on Server A has an immediate superior residing on Server B. Server A therefore uses a superior knowledge reference to point to its parent on Server B.
Naming contexts that start at the top of the DIT obviously cannot have a knowledge reference to a superior naming context.
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.
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.
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.
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 and Provisioning 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 OracleAS Portal) that need to be notified whenever changes are applied to Oracle Internet Directory.
Based on the nature of integration, Oracle Directory Integration and Provisioning 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
Identity management is the process of managing the complete security life cycle for network entities in an organization. Because Oracle Internet Directory is a key element of the Oracle Identity Management infrastructure, it enables you to simplify security management across all applications. To do this, you deploy multiple Oracle components against a shared instance of Oracle Internet Directory. Matching the deployment of Oracle Internet Directory with the security needs of your enterprise requires careful planning.
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 needs to 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 infrastructure enables 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
Oracle Identity Management is an integrated infrastructure that Oracle products rely on for distributed security. It is part of the infrastructure of the Oracle Application Server and for other Oracle products as well. Figure 2-9 illustrates the components of the Oracle Identity Management infrastructure and how various Oracle and third-party products rely on it.
As shown in Figure 2-9, the Oracle Identity Management infrastructure includes the following components and capabilities:
Oracle Internet Directory, a scalable, robust LDAP Version 3-compliant directory service implemented on the Oracle Database.
Oracle Directory Integration and Provisioning, which permits synchronization between Oracle Internet Directory and other directories and user repositories and automatic provisioning services for Oracle components and applications and, through standard interfaces, third-party applications.
Oracle Delegated Administration Services, which provides trusted proxy-based administration of directory information by users and application administrators.
Oracle Application Server Single Sign-On, which provides single sign-on access to Oracle and third party web applications.
Oracle Application Server Certificate Authority, which generates and publishes X.509 V3 PKI certificates to support strong authentication methods.
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 a number of 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 Provisioning Integration Service enables you to provision third-party applications and integrate the Oracle environment with other provisioning systems.
Oracle Application Server Single Sign-On provides APIs for developing and deploying partner applications that share a single sign-on session with other Oracle Web applications.
JAZN, Oracle's implementation of the JAAS standard, enables applications developed for the Web using Oracle's J2EE environment to leverage the Oracle Identity Management infrastructure for authentication and authorization.
In addition, Oracle works with third-party application vendors to ensure that their applications can leverage Oracle Identity Management out of the box.
|
See Also: Oracle Identity Management Concepts and Deployment Planning Guide for more information about the Oracle Identity Management infrastructure |
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. This enables 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.
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". |
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
Once 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 by means of a unique single sign-on user name.
Figure 2-10 shows where resource information is located in the DIT.
As Figure 2-10 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, 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:
|
