Oracle9i Directory Service Integration and Deployment Guide
Release 1 (9.0.1)

Part Number A90153-01
Go To Documentation Library
Go To Product List
Book List
Go To Table Of Contents
Go To Index

Master Index


Go to previous page Go to next page

Deploying Oracle Products with Oracle Internet Directory

This chapter takes an in-depth look at how Oracle9i products interact with Oracle Internet Directory. It describes how each product uses the directory, where under the Oracle Context the product stores its entries, and how the product protects these objects from unauthorized access. Where appropriate, the chapter talks about deployment factors that you should be aware of before using Oracle Internet Directory.

The chapter covers the following products:

Oracle Net Services

Oracle Net Services provides enterprise-wide connectivity solutions in distributed, heterogeneous computing environments. Oracle Net Services eases the complexities of network configuration and management, maximizes performance, and improves network diagnostic capabilities. Oracle Net Services provides the following solutions for a typical network configuration:

This section covers the following topics:

How Oracle Net Services Uses Oracle Internet Directory

Oracle Net Services uses Oracle Internet Directory as one of the primary methods for storing and resolving database services and the simple names that can be used to represent them. These simple names are called net service names. In client connect strings, they serve as connect identifiers. The directory server resolves these connect identifiers to connect descriptors, which are passed back to the client. This feature is called directory naming.

In the following connect string, sales is a simple name for a database that is resolved to connection information that is used to access the database. Instead of storing this information in a tnsnames.ora file, you can store it in the directory server.

CONNECT scott/tiger@sales

Figure 4-1 shows a client resolving a connect identifier through a directory server.

  1. The client contacts the directory server to resolve a simple name to a connect descriptor.

  2. The directory server resolves the simple name and retrieves the connect descriptor for the client.

  3. The client sends the connection request to the listener using the connect descriptor.

Figure 4-1 Client Using a Directory Server to Resolve a Connect Identifier

Text description of dirig005.gif follows
Text description of the illustration dirig005.gif

Oracle Net Services Entries Under the Oracle Context

Oracle Net Services stores two kinds of entries in the directory: net service names and database services.

A net service name is a simple name for a database that resolves to a connect descriptor. A connect descriptor provides the location of the database and the name of the database service. A net service entry contains attributes that constitute the connect descriptor. You create net service name entries with Oracle Net Manager, a graphical user interface tool for configuring and managing Oracle Net. The Directory Server Migration Wizard, available within Oracle Net Manager, enables you to export net service names stored in an existing tnsnames.ora file to an Oracle Internet Directory server.

A database service entry contains the actual name of the database, as well as several attributes, including those that constitute the connect descriptor. You create a database service entry when you create the database, using Oracle Database Configuration Assistant. The name of the entry matches the database name specified at time of creation. Clients configured to access the directory server can use this entry in their connect strings to connect to the database without any additional configuration.

As Figure 4-2 shows, net service name and database service entries are created directly under the Oracle Context (cn=OracleContext).

Figure 4-2 Networking Entries

Text description of dirig002.gif follows
Text description of the illustration dirig002.gif

In Figure 4-3, the directory contains a database service entry of salesdb and a net service name entry of sales. The entry salesdb has a distinguished name (DN) of cn=salesdb,cn=OracleContext,dc=acme,dc=com. The entry sales has a DN of cn=sales,cn=OracleContext,dc=acme,dc=com.

Figure 4-3 Example of Networking Entries

Text description of dirig004.gif follows
Text description of the illustration dirig004.gif

During directory server usage configuration, you select a directory entry that contains an Oracle Context (cn=OracleContext) as the default place to locate and look up net service name and database service entries in the directory server. You can use Oracle Net Configuration Assistant to configure directory server usage during or after installation.

If a directory entry lies within the default Oracle Context, you can use a relative path name to gain access to it. In Figure 4-4, the entry salesdb has a DN of cn=salesdb,cn=OracleContext,dc=acme,dc=com and the entry sales has a DN of cn=sales,cn=OracleContext,dc=acme,dc=com. If a client needs to access the sales entry more frequently than the salesdb entry, you would configure dc=acme,dc=com as the default directory entry from which to perform lookups. This would enable the client to make an Oracle9i database connection with the following connect string:

CONNECT scott/tiger@sales

Figure 4-4 Directory Structure with Two Oracle Contexts

Text description of dirig003.gif follows
Text description of the illustration dirig003.gif

In the case where a directory entry that you specify does not lie within the default Oracle Context, you specify the entry's complete name or its absolute name in the client connect string. An absolute name includes the name of the object and its location in the directory server, much the way an absolute path is specified. A client connecting to an Oracle9i database with salesdb would use one of the following connect strings:

CONNECT scott/tiger@cn=salesdb,cn=OracleContext,dc=com
CONNECT scott/

Net service name and database service entries use the object classes listed in Table 4-1.

Table 4-1 Oracle Net LDAP Main Object Classes
Object Class  Description 


Defines the attributes for net service name entries 


Defines the attributes for database service entries 

The object classes orclNetService and orclDbServer use the object classes listed in Table 4-2.

Table 4-2 Oracle Net LDAP Derived Object Classes
Object Class  Description 


Defines a listener protocol address 


Defines a list of addresses 


Specifies a connect descriptor, containing the listener address for the database and the connect information to the service 


Defines a list of connect descriptors 

These object classes use attributes that specify the contents of connect descriptors.

See Also:

Appendix A, "Oracle-Specific LDAP Schema Extensions" 

Security Measures for Oracle Net Services Entries

Oracle Net Services grants read access to the anonymous directory user. This privilege enables any user to access entries for database service names and net service names and to use these entries to connect to the database.

While networking entries can be read by anyone, only members of the OracleNetAdmins and OracleDBCreators groups can create or modify these entries:

Oracle Net Configuration Assistant establishes these access rights for the two groups during Oracle Context creation.

Directory Deployment Factors for Oracle Net Services

Before deploying directory naming, consider the following:

Oracle Advanced Security

Oracle Advanced Security is a term used to describe a number of Oracle features. These features address the administrative and security challenges posed by multiple user accounts on different databases. All rely on the central storage and management of user-related information, such as enterprise roles, in Oracle Internet Directory. For example, when an employee changes jobs, an administrator need only modify information in one location, the directory. This centralization not only lowers administrative costs, it improves enterprise security.

This section covers the following topics:

How Oracle Advanced Security Uses Oracle Internet Directory

Oracle Advanced Security uses the directory for the following:

Central Management of User Authentication Credentials

A user's database password is stored in the directory as an attribute of his or her user entry, instead of in each database.

Central Management of User Authorizations

Oracle Advanced Security uses directory entries called enterprise roles to determine what privileges a given enterprise user has within a given schema, shared or owned. Enterprise roles are containers for database-specific global roles. User Claire Stevens, for example, might be assigned the enterprise role clerk, which might contain the global role hrclerk and its attendant privileges on the human resources database and the global role analyst and its attendant privileges on the payroll database.

Mappings to Shared Schemas

Oracle Advanced Security uses mappings, directory entries that point an enterprise user to shared application schema on the database instead of to an individual account. For example, you might map several enterprise users to the schema sales_application instead of to separate accounts in their names.

Single Password Authentication

In Oracle 9i, the Oracle Advanced Security option allows enterprise users to authenticate to multiple databases using a single, centrally managed password. The password is stored in the directory as an attribute of the user's entry and is protected by encryption and access control lists. This feature eliminates the overhead associated with setting up Secure Sockets Layer (SSL) on clients and frees users from having to remember multiple passwords.

Single Sign-On

The alternative to authenticating using a centrally managed password is to use PKI-based single sign-on through SSL. Like single password authentication, this feature requires a user entry in the directory. In addition, a user's wallet must be stored as an attribute of his or her entry.

Central Storage of PKI Credentials

For Oracle 9i, user wallets can be stored in the directory as an attribute of the user's entry. This feature enables mobile users to retrieve and open their wallets using Enterprise Login Assistant. While the wallet is open, authentication is transparent--that is, users can access any database on which they own or share a schema without having to authenticate again.

Oracle Advanced Security Entries Under the Oracle Context

The product subtree for Oracle Advanced Security uses the container cn=OracleDBSecurity to store entries for enterprise roles, user-to-schema mappings, and enterprise domains. Under each domain is the entry cn=OracleDomainAdmins, which specifies the administrators for the domain.

An enterprise domain is essentially a collection of databases, enterprise roles, and user-to-schema mappings. One of these domains is cn=OracleDefaultDomain, which is created when the Oracle Context is created. This domain can be used in lieu of an administrator-defined domain.

Figure 4-5 shows all entries relevant to Oracle Advanced Security.

Figure 4-5 Directory Entries Relevant to Oracle Advanced Security

Text description of dirig021.gif follows
Text description of the illustration dirig021.gif

Security Measures for Oracle Advanced Security Entries

Oracle Advanced Security uses ACLs at many points in the directory to protect entries relevant to database security. Most of these ACLs grant privileges to members of the groups whose functions are described in Table 4-3.

Table 4-3 Administrative Groups for Oracle Advanced Security
Administrative Group  Function 


Full privileges for objects in the container OracleDBSecurity. The initial member of this group is the context creator 


Full privileges for a given domain. The initial member is the person creating or updating the domain. If a new 9i context and OracleDefaultDomain is created, the initial member will be the context creator  

OracleUserSecurity Admins 

Special privileges for user entries. This group has read and write privileges for wallet password hints and passwords. The initial member is the person who creates the Oracle Context  


The enterprise domains trusted to read the database password verifier of users, so that users can log in as password-authenticated global users. The initial (dummy) member is OracleDBSecurityAdmins 


Privileges to add new database entries under an Oracle Context. The first member of this group is the context creator 


Full privileges for a given database and its subtree 

Directory Deployment Factors for Oracle Advanced Security

When deploying Oracle Advanced Security features with Oracle Internet Directory, be sure to do the following:

Application Context

Application Context is a database security feature that enables you to develop applications that are based on a user's session information. It provides a way to define, set, and access attributes that an application can use to enforce access control. Of the four types of Application Context--global, local, external, and centralized--the last, the context that is created using the "initialized globally" clause, uses Oracle Internet Directory

This section covers the following topics:

How Application Context Uses Oracle Internet Directory

The user of an application context can have the attributes for an initial context, in the form of entries, set up for her in Oracle Internet Directory. If she successfully authenticates using Oracle Advanced Security, her global roles are retrieved from the directory; then her global application context is retrieved. By the time she logs on to the database, her global roles and initial application context are set up.

To understand how Application Context uses Oracle Internet Directory, consider the steps involved in setting up the hypothetical application context HR. Suppose that the application administrator would like to use this context to allow the user access to an application module called HR, which includes a personnel table. This user's information is stored in the directory, not in the personnel table. Nevertheless, the administrator will allow her restrictive access to the personnel table, using a PL/SQL procedure called GetPersonnelData to call the HR context.

  1. The administrator creates a global user called user1 in the database, using a DN to identify her as an enterprise user in the directory.

  2. The administrator creates an application context in the database for the application HR, using a SQL command to implement a context package created using PL/SQL.

  3. The administrator creates the directory entry HR, using an LDIF script. He assigns the subentries Title and Manager to the entry HR. He stores all of these entries within the domain MyDomain, which is located in the container OracleDBAppContext.

  4. The administrator assigns the global user name user1 as an attribute to the entry Manager.

  5. The administrator writes a PL/SQL procedure--in this case, GetPersonnelData--that uses the application context to retrieve only those records with values matching the context.

When user1 connects to a database belonging to the domain myDomain, her title is set to Manager, and any other information relating to her is retrieved from the LDAP directory. For instance, if her user entry contains the object class inetOrgPerson, attributes for this object class are retrieved.

When she executes the command GetPersonnelData, the user retrieves records only for persons whose title is Manager.

Application Context Entries Under the Oracle Context

As Figure 4-6 illustrates, a centrally initialized application context stores four types of entries in the directory:

The values of the application context belong to the object class orclDBApplicationContext, which is a subclass of groupOfUniqueNames. Note that entries for Application Context are located within the container OracleDBSecurity under the enterprise domain to which the application context applies--in this case, MyDomain.

Figure 4-6 Directory Information Tree for Application Context, Showing Attributes for the Context Value

Text description of dirig010.gif follows
Text description of the illustration dirig010.gif

Security Measures for Application Context Entries

Directory entries for a centrally initialized Application Context are protected by Access Control Lists (ACLs) at two levels: at the level of the container OracleDBSecurity and at the level of the enterprise domain. At the first level, OracleDBSecurityAdmins have complete access to all enterprise domains and their subtrees. At the second level, OracleDomainAdmins have full access to application context values for their domain. For a context to work, all databases belonging to a domain must be able to read values belonging to contexts in that domain.

See Also:

"Application Context Initialized Globally," in Chapter 12 of Oracle9i Application Developer's Guide - Fundamentals 

Oracle Advanced Queuing

Oracle Advanced Queuing is a feature that combines a message queuing system with the Oracle database, using queue tables to store information about messages. This model facilitates persistent storage and message propagation between queues on different machines and databases.

Oracle Advanced Queuing uses different programmatic environments to provide two modes of message dissemination: point-to-point and publish-subscribe. In the first mode, senders and receivers use a common queue to exchange messages that have only one recipient. In the second, a message might be received by multiple recipients, called subscribers, who may subscribe to multiple queues located on different databases. These multi-consumer queues are called global topics.

This chapter covers the following topics:

How Oracle Advanced Queuing Uses Oracle Internet Directory

Oracle Advanced Queuing uses Oracle Internet Directory as a repository for the metadata of global topics and as a registry for database event notifications. In the first instance, connection factories and destinations for Java Messaging Service can be stored in a namespace accessible to Java Native Directory Interface (JNDI). In the second instance, clients can perform "open registration"--that is, they can use a single directory entry to register for multiple databases.

When a queue, queue table, or subscriber is created in a database, the database automatically creates directory entries that contain object metadata. For example, directory entries for queues contain information that references particular queue tables and indicates whether the corresponding queues are multiple consumer queues.

Using PL/SQL or Java interfaces, you can also add directory entries for aliases and JMS connection factories. The latter consist of the configuration parameters needed to establish a connection with a database.

Oracle Advanced Queuing Entries Under the Oracle Context

As Figure 4-7 illustrates, Oracle Advanced Queuing stores entries for global topics directly below the database server entry to which they apply.

Figure 4-7 Directory Information Tree for Oracle Advanced Queuing

Text description of dirig012.gif follows
Text description of the illustration dirig012.gif

It uses five containers for this purpose, one for each of the object types needed to support global subscriptions. Aliases, too, are stored directly below database server entries. Table 4-4 describes the contents of these five containers.

Table 4-4 Containers for Global Topics Entries
Container  Contents 


Database agents 


Queues. Subscribers of queues are placed under corresponding queue entries  


Queue tables 


Connection factories 


JMS subscribers. Contains detailed information about queue subscribers as well as links to subscriber entries  

Client registrations for database event notifications have a container of their own, cn=OracleDBRegistration, which is located directly beneath the products container. Below cn=OracleDBRegistration is the entry cn=OracleDBSubscribers. This entry defines the LDAP users who are authorized to add, modify, and delete registration entries.

Security Measures for Oracle Advanced Queuing Entries

Everyone can read entries related to global topics, but only the database server that created these entries can modify them. For LDAP registration of event notifications, users who are granted the global role global_aq_user_role can add, modify, and delete registration entries.

Because global roles are implemented as privilege groups in Oracle9i, everyone granted an enterprise role that includes the global role global_aq_user_role is included in the privilege group cn=OracleDBSubscribers. Each database server is also a member of cn=OracleDBSubscribers.

Note that a registration entry can contain an ACI to ensure that only the entry creator and the database server can alter it.

Directory Deployment Factors for Oracle Advanced Queuing

Be sure to do the following before using Oracle Internet Directory with Oracle Advanced Queuing:

Oracle Dynamic Services

Oracle Dynamic Services offers a programmatic framework for e-businesses to register and reuse existing Internet, Intranet, and database information services. It enables e-businesses to transform these services and tailor them to meet their own requirements.

The Oracle Dynamic Services framework allows creation and aggregation of services from a variety of content sources on the Internet. Oracle Dynamic Services supports content access from:

The Oracle Dynamic Services framework supports service deployment anywhere over any protocol, including the following:

E-businesses can use Oracle Dynamic Services in their database applications, hosted applications, online exchanges, and portals (B2B, B2C, B2M).

This section covers the following topics:

How Oracle Dynamic Services Uses Oracle Internet Directory

The Oracle Dynamic Services framework contains two registries, both directory based:

Figure 4-8 shows how these two registries interact with other components within the Oracle Dynamic Services framework.

Figure 4-8 LDAP Server Within Oracle Dynamic Services Framework Architecture

Text description of dirig009.gif follows
Text description of the illustration dirig009.gif

The Oracle Dynamic Services framework uses Oracle Internet Directory to store and manage service definitions and consumer profiles.

To avoid bottlenecking the directory and to increase performance, a DSE instance handles operations on the local registry cache first. The DSE instance notifies the directory server only if these operations modify the registry. Such modification might, for example, involve removing a service entry.

To ensure consistency between the registry cache and the central registries in the directory, the DSE instance updates the cache only after the directory performs the same action. This feature also ensures consistency between DSE instances.

Figure 4-9 shows the synchronization process that occurs when an administrator registers the YahooQuote service, a new service for Oracle Dynamic Services, through one DSE instance.

  1. The administrator connects to one DSE instance and registers the YahooQuote service, which has the unique service ID "" and which falls into the service category "business, finance, stock."

  2. The DSE instance processes the service registration request, pre-registering the service package in its local service registry. If the pre-registration process is error free, the DSE instance sends the YahooQuote service package to the directory server for registration.

  3. Oracle Internet Directory registers the YahooQuote package.

  4. After the directory registers the YahooQuote service, it notifies the DSE instance. The DSE instance updates the local registry cache and informs the administrator that registration has been completed.

Figure 4-9 YahooQuote Service Registration

Text description of dirig008.gif follows
Text description of the illustration dirig008.gif

Figure 4-10 shows the synchronization process that occurs when the administrator starts a new DSE instance. During bootstrapping, this instance connects with the directory and synchronizes with the central registries.

Figure 4-10 Registry Synchronization Process for a New Dynamic Services Engine Instance

Text description of dirig007.gif follows
Text description of the illustration dirig007.gif

Oracle Dynamic Services Entries Under the Oracle Context

Oracle Dynamic Services stores the following entries in Oracle Internet Directory:

Figure 4-11 shows the structure of the directory subtree for Oracle Dynamic Services.

Figure 4-11 Directory Information Tree for Oracle Dynamic Services, Showing Attribute Types for One Service, Currency

Text description of dirig022.gif follows
Text description of the illustration dirig022.gif

Security Measures for Oracle Dynamic Services Entries

Oracle Dynamic Services grants full access (read/write) to the DSAdmin group, the users who have administrative privileges. Anonymous directory users have no access to the service and application profile registries.

Directory Deployment Factors for Oracle Dynamic Services

Consider the following factors before using Oracle Internet Directory with Oracle Dynamic Services:

Oracle Dynamic Services is certified to use Oracle Internet Directory--that is, its registry structure is compatible with this directory service. Oracle's LDAP Schema Council carefully reviews object classes and attributes for the product.

See Also:

Oracle Dynamic Services User's and Administrator's Guide 

Go to previous page Go to next page
Copyright © 1996-2001, Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Go To Product List
Book List
Go To Table Of Contents
Go To Index

Master Index