Release 9.0.2
Part Number A95192-01
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle Internet Directory Administrator's Guide Release 9.0.2 Part Number A95192-01 |
|
This chapter provides conceptual descriptions of the basic elements of Oracle Internet Directory and discusses Oracle Internet Directory architecture.
This chapter contains these topics:
"Related Documentation" for suggestions on further reading about LDAP-compliant directories
See Also:
In a directory, each collection of information about an object is called an entry. For example, a typical telephone directory includes entries for people, and a library card catalog contains entries for books. Similarly, an online directory might include entries for employees, conference rooms, e-commerce partners, or shared network resources such as printers.
Each entry in an online directory is uniquely identified by a distinguished name (DN). The distinguished name tells you exactly where the entry resides in the directory hierarchy. This hierarchy is represented by a directory information tree (DIT).
To understand the relation between a distinguished name and a directory information tree, look at Figure 2-1.
The DIT in Figure 2-1 diagrammatically represents entries for two employees of Acme Corporation who are both named Anne Smith. It is structured along geographical and organizational lines. The Anne Smith represented by the left branch works in the Sales division in the United States, while the other works in the Server Development division in the United Kingdom.
The Anne Smith represented by the right branch has the common name (cn) Anne Smith. She works in an organizational unit (ou) named Server Development, in the country (c) of Great Britain (uk), in the organization (o) Acme.
The DN for this "Anne Smith" entry is:
cn=Anne Smith,ou=Server Development,c=uk,o=acme
Note that the conventional format of a distinguished name places the lowest DIT component at the left, then follows it with the next highest component, moving progressively up to the root.
Within a distinguished name, the lowest component is called the relative distinguished name (RDN). For example, in the above entry for Anne Smith, the RDN is cn=Anne Smith. Similarly, the RDN for the entry immediately above Anne Smith's RDN is ou=Server Development, the RDN for the entry immediately above ou=Server Development is c=uk, and so on. A DN is thus a sequence of RDNs separated by commas.
To locate a particular entry within the overall DIT, a client uniquely identifies that entry by using the full DN--not simply the RDN--of that entry. For example, within the global organization in Figure 2-1, to avoid confusion between the two Anne Smiths, you would use each one's full DN. (If there are potentially two employees with the same name in the same organizational unit, you could use additional mechanisms, such as identifying each employee with a unique identification number.)
To make operations on entries quick and efficient, Oracle Internet Directory assigns a unique identifier to each entry, then stores a specified number of those identifiers in cache memory. When a user performs an operation on an entry, the directory server looks in the cache for the entry identifier, then retrieves the corresponding entry from the directory. This method, called entry caching, enhances Oracle Internet Directory performance, and is especially useful in smaller and medium-sized enterprises.
In a typical telephone directory, an entry for a person contains such information items as an address and a phone number. In an online directory, such an information item is called an attribute. Attributes in a typical employee entry can include, for example, a job title, an e-mail address, or a phone number.
For example, in Figure 2-2, the entry for Anne Smith in Great Britain (uk) has several attributes, each providing specific information about her. These are listed in the balloon to the right of the tree, and they include emailaddrs, printername, jpegPhoto, and app preferences. Moreover, each bullet in Figure 2-2 is also an entry with attributes, although the attributes for each are not shown.
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.
This information is maintained and retrieved by the directory clients and is unimportant to the operation of the directory. A telephone number, for example, is application information.
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.
Any given attribute can hold either application information, or operational information, but not both.
To enhance your ability to search for entries, Oracle Internet Directory automatically creates several system operational attributes when you add an entry to the directory. These include:
| Attribute | Description |
|---|---|
|
|
Name of the person creating the entry |
|
|
|
|
|
Name of person creating 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. Table 2-1 shows some of the more common LDAP attributes.
|
See Also:
Appendix C, "Schema Elements" for a list of several proprietary 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 attached to it.
Oracle Internet Directory recognizes most of the syntax specified in RFC 2252, allowing you to associate most of the syntax described in that document with an attribute. In addition to recognizing the syntax in RFC 2252, Oracle Internet Directory also enforces some LDAP syntax. You cannot add new syntaxes beyond those already supported by Oracle Internet Directory.
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 cn;lang-fr=Jean, the base attribute is cn; the French value for that base attribute is cn;lang-fr=Jean.
An attribute with one or more options inherits the properties--for example, matching rules and syntax-- of its base attribute. To continue the previous example, the attribute with the option cn;lang-fr=Jean inherits the properties of cn.
An object class is a group of attributes that define the structure of an entry. When you define a directory entry, you assign one or more object classes to it. Some of the attributes in these object classes are mandatory, others are optional.
For example, the organizationalPerson object class includes the mandatory attributes commonName (cn) and surname (sn), and the optional attributes telephoneNumber, uid, streetAddress, and userPassword. When you define an entry by using the organizationalPerson object class, you must specify values for commonName (cn) and surname (sn). You do not need to provide values for telephoneNumber, uid, streetAddress, and userPassword.
At installation, Oracle Internet Directory provides standard LDAP object classes, as well as several proprietary object classes. You cannot add mandatory attributes to the sets of attributes belonging to these predefined object classes. If a given object class does not contain all the attributes that you want for an entry, then you can do one of the following:
Appendix C, "Schema Elements" for a list of object classes in the schema installed with Oracle Internet Directory
See Also:
This section contains these topics:
A subclass is an object class derived from another object class. The object class from which it is derived is called its superclass. For example, the object class organizationalPerson is a subclass of the object class person. Conversely, the object class person is the superclass of the object class organizationalPerson.
Subclasses inherit all of the attributes belonging to their superclasses. For example, the subclass organizationalPerson inherits the attributes of its superclass, person. Entries may inherit the attributes defined by multiple object classes.
One special object class, called top, has no superclasses. It is one of the superclasses of every structural object class in the directory, and its attributes are inherited by every entry.
There are three types of object classes:
An abstract object class is a virtual object class. It is used only for convenience when specifying the highest levels of the object class hierarchy. It cannot be the only object class for an entry. For example, the object class top is an abstract object class. It is required as a superclass for all structural object classes, but it cannot be used alone.
The top object class includes the mandatory attribute objectClass as well as several optional attributes. The optional attributes in top are:
orclGuid--Global identification which remains constant if the entry is moved
creatorsName--Name of the creator of the object class
createTimestamp--Time when the object class was created
modifiersName--Name of the last person to modify the object class
modifyTimestamp--Time when the object class was last modified
orclACI--access control list (ACL) directives that apply to all entries in the subtree below the access control policy point where this attribute is defined
orclEntryLevelACI--Access control policy pertaining to only a specific entity--for example, a special user
"Globalization Support" for more information on access control policies and ACLs.
See Also:
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 use structure rules to place restrictions on the kinds of object classes you can create under any given object class. For example, a structure rule might require all objects below the organization (o) object class to be organizational units (ou). Following this rule, you could not enter person objects directly below an organization object class. Similarly, a structure rule might disallow you from placing an organizational unit (ou) object below a person object.
Auxiliary object classes are groupings of attributes that expand the existing list of attributes in an entry. For example, suppose you have defined an entry as a member of two object classes, and you want to assign to that entry additional attributes that do not belong to either of those two object classes. You can create a new auxiliary object class containing the extra attributes, and then associate that auxiliary object class with the entry. This is an alternative to redefining existing object classes.
Unlike structural object classes, auxiliary classes do not place restrictions on where an entry may be stored.
A naming context is a subtree that resides entirely on one server. It must be contiguous, that is, it must begin at an entry that serves as the top of the subtree, and extend downward to either leaf entries or references to subordinate naming contexts. It can range in size from a single entry to the entire DIT.
Figure 2-3 illustrates valid and invalid naming contexts. Notice that the correct ones on the left are contiguous, and the incorrect ones on the right are not.
To enable users to search for specific naming contexts, you can publish those naming contexts by using either Oracle Directory Manager or ldapmodify.
|
See Also:
"Managing Naming Contexts" for instructions on how to publish a naming context |
The directory schema contains all information about how data is organized in the DIT--that is, metadata such as that for an object class, an attribute, a matching rule, and syntax. The directory schema stores this information in a special class of entry called a subentry. Oracle Internet Directory, following LDAP Version 3 standards, holds schema definitions in the subentry called subSchemaSubentry.
You can add new object classes and objects by modifying subSchemaSubentry. You cannot, however, add new matching rules and syntaxes beyond those already supported by Oracle Internet Directory.
|
See Also:
|
Oracle Internet Directory provides many powerful features for protecting information. These include:
More significantly, in an enterprise or hosted environment, you can use all these features to control access to application metadata--the information governing how applications behave and who can access them. To do this, you deploy the directory for administrative delegation. This deployment allows, for example, a global administrator to delegate to department administrators access to the metadata of applications in their departments. These department administrators can then control access to their department applications.
|
See Also:
Chapter 11, "Directory Security Concepts" for a fuller discussion of the security features of Oracle Internet Directory |
Oracle Internet Directory follows LDAP Version 3 internationalization (I18N) standards. These standards require that the database storing directory data use the UTF-8 (Unicode Transformation Format 8-bit) character set. This allows Oracle Internet Directory to store the character data of almost any language supported by Oracle Globalization Support. Moreover, although several different application program interfaces (APIs) are involved in the Oracle Internet Directory implementation, Oracle Internet Directory ensures that the correct character encoding is used with each API.
Globalization Support uses both single-byte and multibyte characters. A single-byte character is represented by one byte of memory. ASCII text, for example, uses single-byte characters. By contrast, a multibyte character can be represented by more than one byte. Simplified Chinese, for example, uses multibyte characters. A directory entry in simplified Chinese might look like this:
dn: o=\274\327\271\307\316\304,c=\303\300\271\372 objectclass: top objectclass: organization o: \274\327\271\307\316\304
where the attribute values correspond to character strings in the simplified Chinese character set.
The main Oracle Internet Directory components--OID Monitor (OIDMON), OID Control Utility (OIDCTL), Oracle directory server (OIDLDAPD), Oracle directory replication server (OIDREPLD), and the Oracle directory integration server (ODISRV)--always use the UTF-8 character set by default.
Oracle Directory Manager, a Java-based tool, internally uses Unicode (UCS-2--that is, fixed-width 16-bit Unicode). In Java, UCS-2 is the easiest way to handle characters--including English characters. The Java client uses standard Java packages to convert both to and from UCS-2 and UTF-8. This enables Oracle Directory Manager to handle the LDAP Version 3 protocol using UTF-8.
|
See Also:
|
This section contains these topics:
Figure 2-4 shows the various directory server components and their relationships running on a single node.
Oracle Net Services is used for all connections between the Oracle database server and:
LDAP is used for connections between directory server instance 1 on non-SSL port 389 and:
The two Oracle directory server instances and the Oracle directory replication server connect to OID Monitor by way of the operating system.
|
Note: In Figure 2-4, the database is on the same node as the directory server processes. However, because all connections with the database are through Oracle Call Interface (OCI) and Oracle Net Services, it is possible to use a database on a different server. |
An Oracle Internet Directory node (Figure 2-4) includes the following major components:
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-5 illustrates.
LDAP clients send LDAP requests to an Oracle Internet Directory listener/dispatcher process listening for LDAP commands at its port.
The OID listener/dispatcher sends the request to the Oracle directory server which, in turn creates server processes. Multiple server processes enable Oracle Internet Directory to take advantage of multiple processor systems. The number of server processes created is determined by the configuration parameter ORCLSERVERPROCS. The default is 1 (one). A worker thread for each operation processes the client request.
Database connections from each server process are spawned as needed, depending on the value set for the configuration parameter ORCLMAXCC. The default value for this parameter is 10. The server processes communicate with the data server by way of Oracle Net Services. A Oracle Net Services Listener/Dispatcher relays the request to the Oracle9i database server.
The configuration parameters for each Oracle directory server instance are stored in a directory entry called a configuration set entry, or configset. A configuration set entry holds the configuration parameters for a specific instance of the directory server. When you start an instance of a server by using the OID Control Utility, the start-command you enter contains a reference to one of these configsets and uses the information it contains.
The Oracle directory server is installed with a default configuration set entry (configset0) so that you can run the directory server immediately. You can create customized configuration set entries by adding new ones that change specific parameters to meet your needs. You can view, add, and modify these entries by using either Oracle Directory Manager or the appropriate command-line tool.
|
See Also:
|
This example shows you how Oracle Internet Directory processes a search request.
Although an online directory is logically centralized, it can physically distribute its data onto several servers. This reduces the work a single server would otherwise have to do, and enables the directory to accommodate a larger number of entries.
A distributed directory can be either replicated or partitioned. When information is replicated, the same naming contexts are stored by more than one server. When information is partitioned, each directory server stores one or more unique, non-overlapping naming contexts. In a distributed directory, some information may be partitioned and some may be replicated.
This section contains these topics:
Replication, in which the same naming contexts are stored by more than one server, improves performance by providing more servers to handle queries. It improves reliability by eliminating risks associated with a single point of failure.
Figure 2-6 shows a replicated directory.
Each copy of a naming context that is contained within a server is called a replica. A directory server can hold both read-only and updatable replicas. Servers that hold updatable replicas are called suppliers. Their changes are propagated to other servers called consumers.
At times, the replication process may be unable to apply a change. For example, suppose that Supplier Node A sends the consumer a change, and, immediately after that, Supplier Node B sends it an update to the same entry. Then, suppose that a problem delays the transmission of the entry from Supplier Node A, but that no such problem delays transmission of the update from Supplier Node B. The result can be that the update from Supplier Node B arrives at the consumer ahead of the entry it is modifying. In this case, the replication server makes a specified number of retries to apply the change. If it fails to apply the change once that number is reached, then it moves the change to the human intervention queue, and attempts to apply the change at regular, less frequent intervals that you specify.
|
See Also:
Chapter 22, "Directory Replication Concepts" for a more detailed discussion of replication, including: Oracle9i Replication architecture, 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:
Two naming contexts on Server A are replicated on Server B:
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. In Figure 2-7, Server B uses knowledge references to point to the c=us and c=uk naming contexts on Server A. When clients request from Server B the information residing on Server A, then Server B provides them with one or more referrals to Server A. Clients can then use these referrals to contact Server A.
Typically, each directory server contains both superior and subordinate knowledge references. Superior knowledge references point upward in the DIT toward the root. They tie the partitioned naming context to its parent. Subordinate knowledge references point downward in the DIT to other partitions.
For example, in Figure 2-8, Server B holds four naming contexts, two of which are superior to the others. These two superior naming contexts use subordinate knowledge references to point to their subordinate naming contexts. Conversely, the naming context on Server A has an immediate superior residing on Server B. Server A therefore uses a superior knowledge reference to point to its parent on Server B.
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:
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:
ou=server development,c=us,o=acme, and has a knowledge reference to Server B
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.
Returned when the base object is not in the directory, and the operation is performed in a naming context on another server. A default referral typically sends the client to a server that has more knowledge about the directory partitioning arrangement.
For example, suppose that Server A holds:
c=us,o=acme
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.
The Delegated Administration Service enables directory users to modify their own personal data--such as addresses, phone numbers, and photos--without the intervention of an administrator. It also enables users to search other parts of the directory to which they have access, thereby freeing administrators for other tasks in the enterprise.
The Delegated Administration Service relies on an Apache Web server enabled for small Java programs, called servlets, which do the following:
The Oracle Directory Integration platform enables you to synchronize various directories with Oracle Internet Directory. It also makes it easier for third party metadirectory vendors and developers to develop and deploy their own connectivity agents.
This section contains these topics:
Enterprises today often deploy multiple directories to store information for applications such as ERP systems, database applications, messaging systems, and Network Operating Systems (NOS). Managing so many different directories has many drawbacks, including:
A metadirectory solves these problems by synchronizing information between all enterprise directories, forming one virtual directory. It centralizes administration, thereby reducing administrative costs, and ensures that data is consistent and up-to-date across the enterprise.
For example, in a metadirectory environment, you can create a global directory entry for each employee. You can populate this entry with data from various synchronized directories--for example, Human Resources applications, messaging systems, or NOS databases. Users can then access this global entry, knowing that the data it contains is up-to-date and synchronized with each connected directory.
You can also ensure that the synchronization process respects all existing data ownership policies. For example, you can grant to only the Human Resources department the privilege to change the value of an employee's salary attribute.
The Oracle Directory Integration platform enables an enterprise to integrate its applications and other directories with Oracle Internet Directory. This platform provides all the interfaces and infrastructure necessary to keep the data in Oracle Internet Directory consistent with the data in enterprise applications and connected directories.
For example, an enterprise might want employee records in its HR database to be synchronized with Oracle Internet Directory. In addition, the enterprise may deploy certain LDAP-enabled applications (such as Oracle9iAS Portal) that need to be notified whenever changes are applied to Oracle Internet Directory. This service is called provisioning, and the Oracle Directory Integration platform provides such applications with the necessary notifications.
Based on the nature of integration, the Oracle Directory Integration platform provides two distinct services:
Part VIII: "The Oracle Directory Integration Platform"
See Also:
|
 Copyright © 1999, 2002 Oracle Corporation. All Rights Reserved. |
|