Release 2 (9.2)
Part Number A96579-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle9i Directory Service Integration and Deployment Guide Release 2 (9.2) Part Number A96579-01 |
|
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 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. It provides the following solutions for a typical network configuration:
Once a network session is established, Oracle Net, a component of Oracle Net Services, acts as the data courier for the client application and the database server. It is responsible for initiating and maintaining the connection between the client application and database server, as well as exchanging messages between them. Oracle Net is able to perform these jobs because it is located on each computer in the network.
Features such as location transparency, centralized configuration, and quick out-of-the-box installation and configuration enable you to easily configure and manage network components.
With Oracle Net Services, you can maximize system resources and improve performance. Oracle's shared server architecture increases the scalability of applications and the number of clients simultaneously connected to the database.
Oracle Net Services uses Oracle Advanced Security and other database access control features to enhance network security.
This section covers the following topics:
Oracle Net Services uses Oracle Internet Directory as one of the primary methods for storing and resolving connect identifiers to connect descriptors, which are passed back to the client. This feature is called directory naming. A connect identifier is specified in several different ways. One of the most common ways is through the use of a net service name, another name for a database service.
In the following connect string, sales is a simple name for a database service 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 username/password@sales
Figure 4-1 shows a client resolving a connect identifier through a directory server.
|
Note: Java Database Connectivity (JDBC) Drivers support directory naming. See the Oracle9i JDBC Developer's Guide and Reference for further information. |
As Figure 4-2 shows, directory naming provides support for three kinds of connect identifiers in the directory:
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 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.
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 Services. 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 Oracle Internet Directory.
A net service alias is an alternative name for a database service or net service name. A net service alias entry does not have connect descriptor information. Instead, it only references the location of the entry for which it is an alias. When a client requests a directory lookup of a net service alias, the directory determines that the entry is a net service alias and completes the lookup as if it is the referenced entry.
These entries are created directly under the Oracle Context.
In Figure 4-3, the directory contains a database service entry of salesdb, a net service name entry of sales, and net service alias of salesdbalias for salesdb. The entries have the following distinguished names (DNs):
salesdb has a DN of cn=salesdb,cn=OracleContext,dc=acme,dc=com.sales has a DN of cn=sales,cn=OracleContext,dc=acme,dc=com.salesdbalias has a DN of cn=salesdbalias,cn=OracleContext,dc=acme,dc=com.When salesdbalias is used to connect to a database service, as in CONNECT username/password@salesdbalias, it will actually resolve to and use the connect descriptor information for salesdb.
During directory server usage configuration, you select a directory entry that contains an Oracle Context as the default place to locate and look up directory naming 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 username/password@sales
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:
CONNECTusername/password@cn=salesdb,cn=OracleContext,dc=comCONNECTusername/password@salesdb.com
Table 4-1 lists the object classes for database service, net service name, and net service alias entries.
Table 4-1 Oracle Net Services LDAP Main Object ClassesThe object classes orclNetService and orclDbServer use the object classes listed in Table 4-2.
These object classes use attributes that specify the contents of connect descriptors.
| See Also:
Appendix A, "Oracle-Specific LDAP Schema Extensions" |
Oracle Net Services grants read access to the anonymous directory user. This privilege enables any user to access directory naming entries and to use these entries to connect to the database.
While networking entries can be read by anyone, only members of the following groups can create or modify these entries:
cn=OracleDBCreators,cn=OracleContext...) or the OracleContextAdmins group (cn=OracleContextAdmins,cn=Groups,cn=OracleContext...) to create a database service entry with Database Configuration Assistantcn=OracleNetAdmins,cn=OracleContext...) or the OracleContextAdmins group to create net service names or net service aliases with Oracle Net ManagerOracle Net Configuration Assistant establishes these access rights for the groups during Oracle Context creation.
Before deploying directory naming, consider the following:
You can use multiple Oracle Contexts to logically distribute entries by geographic location or other criteria. Oracle Net Configuration Assistant gives clients default access to a specific Oracle Context, but clients can also access entries that lie under other Oracle Contexts.
tnsnames.ora file or an Oracle Names server to an Oracle Internet Directory server.
To export net service names stored in a tnsnames.ora file, use the Directory Server Migration Wizard, available within Oracle Net Manager. To export database services and net service names stored in an Oracle Names server to the directory server or to an LDIF file, use the Oracle Names Control utility.
Once data is exported, you can either configure clients to use directory naming or, if necessary, convert Oracle Names servers to Oracle Names LDAP Proxy servers to support clients which do not support directory naming. Oracle Names LDAP Proxy servers are Oracle Names servers that have been configured to proxy for directory servers. Upon startup, Oracle Names LDAP Proxy servers obtain network object information from the directory server. This provides a single point of definition for all data in the directory server and does not require that both Oracle Names server and directory server data be maintained separately and simultaneously.
If you are exporting data from an Oracle Names server with a domain tree to an equivalent directory information tree (DIT) structure, you will have to create an Oracle Context for each subdomain in the DIT.
If you plan to use Oracle Names LDAP Proxy servers that support multiple administrative regions, Oracle recommends mirroring the current Oracle Names structure in the DIT structure. Using a different structure may require modifying the topology defined for the Oracle Names LDAP Proxy servers. The tools for Oracle Net Services do not support topology modification.
Establish administrative privileges for directory naming entries for each Oracle Context. For example, if you want two different sets of administrators to have authority over different directory naming entries, then create two Oracle Contexts.
Use Oracle Net Manager to create net service name and net service alias entries, and use Database Configuration Assistant to create a database service entry.
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:
Oracle Advanced Security uses the directory for the following:
A user's database password is stored in the directory as an attribute of his or her user entry, instead of in each database.
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.
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.
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.
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.
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.
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.
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.
When deploying Oracle Advanced Security features with Oracle Internet Directory, be sure to do the following:
This feature revokes all of the user's privileges and minimizes the risk of retaining unintended privileges.
Directory administrators knowledgeable about security manage directory security and user roles and privileges. This relieves DBAs of the burden of performing these functions. The net result is better security.
Be aware that current user database links operate only between databases within a single enterprise domain. Exercise care when you assign databases to a domain, because password authentication for enterprise users is defined at the domain level. Enterprise roles, too, are defined at the domain level. If you want databases to share an enterprise role, make sure that they are members of the same domain.
| See Also:
Chapter 15, "Managing Enterprise User Security," in Oracle Advanced Security Administrator's Guide |
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:
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.
user1 in the database, using a DN to identify her as an enterprise user in the directory.HR, using a SQL command to implement a context package created using PL/SQL.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.user1 as an attribute to the entry Manager.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.
As Figure 4-6 illustrates, a centrally initialized application context stores four types of entries in the directory:
OracleDBAppContextHRTitleManagerThe 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.
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 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 section covers the following topics:
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.
As Figure 4-7 illustrates, Oracle Advanced Queuing stores entries for global topics directly below the database server entry to which they apply.
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.
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.
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.
Be sure to do the following before using Oracle Internet Directory with Oracle Advanced Queuing:
enterprise_aq_user_role.cn=orclDBSubscribers is appropriately populated by checking that the database and enterprise_aq_user_role are attributes of this entry.global_aq_user_role is an attribute of enterprise_aq_user_role.enterprise_aq_user_role is an attribute of cn=OracleDBAQUsers.global_aq_user_role from enterprise_aq_user_role in the old domain. Add it to enterprise_aq_user_role in the new domain.
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 enables 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:
Inside the Oracle Dynamic Services framework, SMTP can be used to generate system or business messages.
Results of service execution can be delivered to any mobile device.
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:
The Oracle Dynamic Services framework contains two registries, both directory based:
The service registry is the placeholder for all service definitions. Consumers can use the client library to query and update the service registry.
The application profile registry is the placeholder for all validated Dynamic Services engine (DSE) applications, which are considered to be DS consumers. The registry stores access policies and application properties.
Figure 4-8 shows how these two registries interact with other components within the Oracle Dynamic Services framework.
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.
"urn:com.yahoo:quote" and which falls into the service category "business, finance, stock."
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.
Oracle Dynamic Services stores the following entries in Oracle Internet Directory:
cn=OracleDynamicServicesSR
The service registry for Oracle Dynamic Services. All service categories and registered services created within the Oracle Dynamic Services framework are stored under this entry
cn=OracleDynamicServicesUPR
The application profile registry for Oracle Dynamic Services. Profiles for each valid Dynamic Services application are stored under this entry. These profiles contain information about service-specific properties and service access privileges
cn=OracleDynamicServicesDomain
The entry that defines the scope of a set of DSE instances. Each DSE is represented under this entry. The entry contains a full set of attributes that describe properties such as connection and security for each engine instance
cn=OracleDynsDocument
The subtree for service-related documents, such as service input schema and output schema. During the service registration process, a unique document ID is assigned to the document. At runtime, a document is retrieved by its document ID
cn=OracleDynsBinObject
The entry under which all service-related binary files are stored. One of these files is the jar file included in the service package
cn=OracleDynsSPOrganization
The subtree used to store organization profiles for service providers. Each profile includes entries for company name, company logo URL, and company Web site URL
cn=OracleDynsPeople
The entry under which all contact information, such as e-mail addresses and phone numbers, is stored
Figure 4-11 shows the structure of the directory subtree for Oracle Dynamic Services.
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.
Consider the following factors before using Oracle Internet Directory with Oracle Dynamic Services:
cn=US is designated as the default root.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.
|
 Copyright © 2002 Oracle Corporation. All Rights Reserved. |
|