Skip Headers
Oracle® Access Manager Installation Guide
10g (10.1.4.3)

Part Number E12493-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

10 Setting Up Oracle Access Manager with Oracle Virtual Directory

This chapter focuses on implementing Oracle Access Manager with the Oracle Virtual Directory to enable Data Anywhere. It includes the following topics:

The Oracle Access Manager-Oracle Virtual Directory implementation uses only a subset of Oracle Virtual Directory functions. Therefore, not all of the information provided in the Oracle Virtual Directory documentation applies to the Oracle Access Manager-specific configurations described in this chapter.

This chapter should be used in conjunction with the following manuals:

10.1 About Oracle Access Manager Implementations with Oracle Virtual Directory

The Oracle Virtual Directory combines the user data from multiple data sources to create an aggregated, virtual directory.

From the point of view of Oracle Access Manager applications, the virtual directory looks and behaves just like any other LDAP directory, and the Oracle Access Manager user usually does not receive any obvious indications that the data retrieved by Oracle Access Manager has come from heterogeneous sources.

From the perspective of the target data store owners, the impact of Oracle Virtual Directory is minimal; the data store owners do not relinquish ownership of their data, Oracle Virtual Directory does not reformat the native data structures, and no permanent copies of the original data are maintained by Oracle Virtual Directory.

To enable certain Oracle Access Manager features, you must extend the schema of the target LDAP directories or add columns simulating Oracle Access Manager auxiliary user attributes to the primary database tables included in your virtual directory. For more information, see "About Schema Extension".

Note:

Oracle Access Manager implementations with Oracle Virtual Directory are intended for use with the user profile and group repository. However, the implementation does not support Oracle Access Manager metadata such as policy rules, workflows, and the like. This metadata must be stored in a certified LDAPv3 directory (Oracle Internet Directory, Sun, or Microsoft Active Directory, for example).

10.1.1 Key Terms and Features

To explain precisely the issues surrounding Oracle Access Manager-Oracle Virtual Directory implementations, this document uses the following terms in very specific fashion.

Terms

Virtual Directory: A logical, aggregated directory that presents user data drawn from multiple sources, just as if all that data came from a standard LDAP directory to which a customer-defined schema has been uniformly applied. For the purposes of the Oracle Access Manager implementation, Oracle Virtual Directory does not create permanent copies of user profiles outside the native data sources. Rather, Oracle Virtual Directory retrieves and transforms each user profile as it is requested by a Oracle Access Manager application.

You can configure your virtual directory as a single, contiguous searchbase or as multiple disjoint searchbases. For details, see "About Searchbase Options".

Super Directory: A special type of virtual directory that facilitates namespace mapping. It can contain any combination of federated LDAP directories, RDBMS databases, and embedded virtual data sources. The embedded virtual data sources can be split profiles, native RDBMS Joins, and native RDBMS Views. The super directory, which is the only supported method for producing a single, contiguous searchbase aggregated from multiple data stores, connects to Oracle Access Manager by means of a Oracle Virtual Directory local store adapter.

Federation: A method by which Oracle Virtual Directory makes a data source visible in the virtual directory it presents to Oracle Access Manager. All the data for a given user profile comes from a single data store such as an LDAP directory, a single-table database, or an embedded virtual data source.

Different user profiles can come from different federated data stores, which incorporate any combination of the following types of data sources:

  • Multiple, heterogeneous LDAP directories

  • Multiple relational databases that store all user data in a single table

  • Embedded virtual data sources, which fall into the following three categories:

  • Split profiles involving any combination of directories and databases

  • Native RDBMS Views involving multiple database tables

  • Native RDBMS Joins involving multiple database tables

For more information, see "Federated Data Stores".

Embedded Virtual Data Source: A virtual object that Oracle Virtual Directory "sees" as a target data store it can present to Oracle Access Manager or federate in a virtual directory, then present to Oracle Access Manager. Each embedded virtual data store aggregates two or more target data stores. The three types of embedded virtual data stores are:

  • Split profile

  • Native RDBMS Join

  • Native RDBMS View

In general, embedded virtual data stores are suitable for authentication and authorization activities only, because they necessarily involve secondary data sources, which are sometimes not available for the full range of identity management activities.

Split Profile: A special type of embedded virtual data source created from more than one data source. Split Profiles draw the user profile attributes for each user from multiple sources, including LDAP directories and multiple database tables.

Each data store contributes some of the attributes necessary to complete the full set of user profile attributes that gets mapped into the Oracle Virtual Directory virtual directory. These attributes can come from LDAP directories or database tables. All Oracle Access Manager user attributes must reside in the primary data store, because not all Oracle Access Manager operations can be performed on the attributes in the secondary stores. Oracle Virtual Directory can make a split profile visible to Oracle Access Manager as a standard LDAP directory. Alternatively, a split profile can be federated as part of a virtual directory.

For more information, see "Split Profiles" and Figure 10-8, "Oracle Virtual Directory Implementation Layers".

Single-Table Database: A single-table database does not necessarily refer to a database that contains just one table, but rather, a database that stores in just one table all the user profile attributes that get mapped into the top level virtual directory.

Multi-Table Database: A database that stores in more than one table the user profile attributes that get mapped into the virtual directory.

Virtual Directory Schema: This is the schema developed by the customer for use by the top-level directory that Oracle Virtual Directory makes visible to Oracle Access Manager. It must be extended with the Oracle Access Manager attributes. See "Virtual Directory Schema".

Optionally, you can further extend the virtual directory schema with customer attributes drawn from the target data sources. For details, see "Customer Schemas".

Features

Virtual directory technology enhances Oracle Access Manager capabilities with four major features:

  • Federated Data stores, mentioned earlier and discussed in more detail in "Federated Data Stores".

  • Split Profiles, mentioned earlier and discussed in more detail in "Split Profiles".

  • Aggregated Namespaces: Map target data stores and embedded virtual data sources to nodes in the super directory. You must install a local store adapter to create the super directory. For details, see "Aggregated Namespaces".

  • Schema Mapping: Transforms the data from all the target data stores according to the customer-defined schema in the top-level virtual directory. For details, see "Aggregated Schema Mapping".

For background discussion of the general advantages offered by virtual directories, see the Oracle Virtual Directory Product Manual

10.1.1.1 Federated Data Stores

Oracle Virtual Directory allows Oracle Access Manager users to access and manipulate user data from disparate, multiple sources, just as if all user accounts came from a single, uniformly "schematized" data store. It can incorporate user data from LDAP directories even if the host directory servers come from different vendors and use different schemaFigure 10-1 illustrates how Oracle Access Manager connects to multiple LDAP directories.

Figure 10-1 Oracle Virtual Directory Implementation with Federated LDAP Directories

OVD with federated directories
Description of "Figure 10-1 Oracle Virtual Directory Implementation with Federated LDAP Directories"

Figure 10-1 shows Oracle Access Manager "seeing" a single directory (Oracle Virtual Directory), which accesses any combination of supported LDAP v3 directory servers from Microsoft, Novell, Sun, Oracle Internet Directory, and IBM.

Your Oracle Virtual Directory virtual directory can also incorporate RDBMS databases that store all user data in a single table. For details on integrating databases that spread user data across multiple tables, see "Split-Profiles".

Figure 10-2 illustrates how Oracle Access Manager connects to multiple relational databases. See also "Database Connectivity Tips".

Figure 10-2 Oracle Virtual Directory Implementation Involving Federated RDBMS Applications

OVD with federated RDBMS applications
Description of "Figure 10-2 Oracle Virtual Directory Implementation Involving Federated RDBMS Applications"

Figure 10-2 shows Oracle Access Manager "seeing" the Oracle Virtual Directory directory, which is accessing Oracle, IBM DB2, and Microsoft SQL Server RDBMS applications. Full Identity and Access System functionality is available for federated databases that store all user profile attributes within a single table. Each member database contains a set of complete user profiles.

10.1.1.2 About Searchbase Options

Oracle Access Manager supports two options for federating target data stores through Oracle Virtual Directory:

  • Oracle Virtual Directory Disjoint Searchbases

  • Unified Searchbase

Disjoint Searchbases: You can configure your Oracle Virtual Directory implementation so that Oracle Access Manager "sees" each target data store as a distinct, disjoint searchbase within the virtual directory. Namespace aggregation is not possible for such a configuration. Also, each target data store resides behind a different top-level mapping adapter, so global directory searches across all the data sources are not possible.

Figure 10-3 illustrates a virtual directory configured for disjoint searchbases.

Figure 10-3 A Virtual Directory with Disjoint Searchbases

A virtual directory with disjoint search bases.
Description of "Figure 10-3 A Virtual Directory with Disjoint Searchbases"

Figure 10-3 shows Oracle Access Manager accessing the Oracle Virtual Directory virtual directory. The virtual directory is comprised of a set of target data stores, each being a mapping adapter and its LDAP or RDBMS. All target data stores map to the customer-defined schema of the virtual directory. Oracle Access Manager "sees" a disjoint searchbase representing each target data store. It cannot perform global searches across all the data stores.

Unified Searchbase: You can create a super directory by installing a Local Store Adapter at the top level, then creating nodes to which you map your target data stores. This option allows for both global directory searches and powerful namespace aggregation.

Figure 10-4 provides an illustration of super directory with a unified, contiguous searchbase.

Figure 10-4 A Super Directory with a Unified, Contiguous Searchbase

A super directory with unified, contiguous search bases.
Description of "Figure 10-4 A Super Directory with a Unified, Contiguous Searchbase"

Figure 10-4 shows Oracle Access Manager accessing a super directory that has a Local Store Adapter at the top. Each node in the super directory contains a mapping adapter and LDAP or RDBMS. They access Oracle Virtual Directory through the Local Store Adapter: Oracle Access Manager "sees" a single contiguous searchbase that performs global searches across all the target data stores. Note that UIDs must be unique across the target data stores.

10.1.1.3 Split Profiles

In addition to providing Oracle Access Manager users with access to federated data stores, Oracle Virtual Directory can provide access to virtualized split profile data sources which draw user profile attributes from multiple data sources, such as LDAP directories and relational database tables.

For example, you can store attributes such as user login password and office phone number in an Active Directory account maintained by Information Technology, while storing other attributes such as home phone number and health plan affiliation in a relational database account maintained by Human Resources.

Because this distribution of attributes across multiple data sources precludes the execution of certain identity management functions on secondary data stores, split profile configurations are suitable primarily for authentication and authorization (Access System) operations.

Figure 10-5 illustrates a simple implementation involving a split profile.

Figure 10-5 Oracle Access Manager-Oracle Virtual Directory Implementation for a Simple Split Profile

Implementation with a split profile
Description of "Figure 10-5 Oracle Access Manager-Oracle Virtual Directory Implementation for a Simple Split Profile"

Figure 10-5 shows a simple split profile. Oracle Access Manager accesses Oracle Virtual Directory, which in turn accesses a primary data source and a secondary data source by using a join view adapter. In this example, the primary data source provides an employee ID, employee name, and office phone; and the secondary data source provides data for a health place, retirement plan, and life insurance plan. Hence, these six attributes are concatenated and mapped into the virtual directory

The primary data source contains the Oracle Access Manager user branch schema attributes, while the secondary data sources usually contain customer attributes.

All Access System and Identity System operations can be performed on the attributes in the primary data source. All Access System operations can also be performed on the data in the secondary sources, but certain Identity System operations cannot be performed on attributes residing in the secondary data stores.

For more information, see "Implementation Limitations".

10.1.2 Aggregated Namespaces

When you create a super directory, you can specify a namespace hierarchy ideally suited to your identity management and policy management needs. This new hierarchy can differ from the native namespace hierarchies used by the constituent data stores in the virtual directory.

As Figure 10-6 illustrates, attributes can be reorganized and assigned to new levels.

Figure 10-6 Namespace Aggregation for a Simple Super Directory

Namespace aggregation for a super directory
Description of "Figure 10-6 Namespace Aggregation for a Simple Super Directory"

Figure 10-6 shows a super directory namespace accessing data in from a primary data source namespace and a secondary data source namespace. In this example, the primary data source namespace contains Active Directory One, which has Engineering, Marketing, and Sales attributes under a West Coast node. Similarly, the secondary data source namespace has Active Directory Two, with its Engineering, Marketing, and Sales attributes under an East Coast node. The super directory namespace reorganizes and assigns the attributes as follows: company, then Engineering, then attributes for either West Coast or East Coast.

In this example, organizations such as Sales, Marketing, and Human Resources can be filtered out if they are irrelevant to the Engineering-only policies. Previously, policies had to be defined separately for the East and West coasts. Now, the virtual directory allows for an "all-Engineering" policy to be defined just once, covering Engineering users on both the East Coast and West Coast.

10.1.3 Aggregated Schema Mapping

When you create your Oracle Virtual Directory virtual directory, you map the native schema used by the constituent data stores to the schema used by your virtual directory Figure 10-7 illustrates this mapping on a simple Oracle Virtual Directory system.

Figure 10-7 Aggregated Schema Mapping for a Simple Virtual Directory

Aggregated schema mapping for a virtual directory.
Description of "Figure 10-7 Aggregated Schema Mapping for a Simple Virtual Directory"

Figure 10-7 shows a virtual directory schema mapping to the following data sources:

  • Relational Database: An employee table with rows for the Employee ID, Employee Name, and employee's Office Phone number.

  • Active Directory: An object class called user that has attributes for the SAM Account Name, cn, and Phone number.

  • SunOne Directory Server: An object class called inetorgperson, with attributes for the UID (user ID), cn, and Telephone Number.

All attributes from the constituent data sources must use the data type of the corresponding attribute in the virtual directory. For example, the Telephone Number attribute in the virtual directory schema maps to Office Phone in the Employees table of the relational database, Phone in the user object class of Active Directory, and Telephone Number in the inetorgperson object class of Sun One Directory Server.

10.2 Implementation Limitations

Oracle Virtual Directory extends Oracle Access Manager functionality to multiple, heterogeneous directories and databases, but with certain limitations. When you deploy Oracle Access Manager with Oracle Virtual Directory, you must carefully observe the limitations stated in this document. Table 10-1 lists the virtual directory configurations subject to limitation and provides references to detailed discussions of these issues.

Table 10-1 Oracle Access Manager Feature Availability for Virtual Directory Configurations

DataSource
Oracle Access Manager Feature Availability
 

Access

System

Identity

System

Federated LDAP directory

Full

Full

Federated "single table" database

Full

Full

Federated "multi-table" database (using the native RDBMS Join feature)

Full

Full functionality for primary data stores. Add Modify, and Delete are also available for secondary data stores if the native RDBMS Join feature supports these functions

Federated "multi-table" database (using the native RDBMS View feature)

Full

Full functionality for primary data stores, but Add and Delete are not available for secondary data stores. (Modify is available for secondary data stores).

Split-Profile directory (using the Oracle Virtual Directory Join View adapter)

Full

Full functionality for primary data stores, but Add, Modify and Delete are not available for secondary data stores.


For more information, see:

10.2.1 About Limitations on Multi-Value Attributes

Individual attributes stored in standard LDAP directories can take multiple values. For instance, you can record each user's password history or assign multiple subscriptions to a user account stored in an LDAP directory.

By contrast, properly normalized data tables in SQL-compliant RDBMS applications cannot store multiple values for the same user attribute within a single table. Therefore, Oracle Access Manager-Oracle Virtual Directory implementations involving database tables support only limited functionality for multi-valued attributes. For details, consult Oracle customer care.

Note:

If your virtual directory incorporates LDAP directories exclusively, no restrictions apply to multi-valued attributes.

User profiles already stored in existing RDBMS databases are most likely to have been implemented entirely with single-value attributes, so no restrictions apply, as long as all the database tables you incorporate into your virtual directory contain single-value attributes only.

In rare situations where multi-valued attributes were used to implement the user accounts in a non-normalized RDBMS data store, you can incorporate the unsupported tables containing multi-valued attributes into your virtual directory as long as you carefully observe the following limitations on User and Group Manager operations:

  • The password history function is not supported

  • No more than one administrator can be configured for each group

  • No more than one subscription can be configured for each group

  • Either group subscription or unsubscription notification can be activated, but you cannot activate both simultaneously

  • No more than one dynamic filter can be configured for each group

  • No more than one group type can be configured for each group

  • No more than one subscription type can be configured for each group (The possible types are: Open, Close, Open with filter, and Controlled through workflow).

  • A database table in the virtual directory can contain no more than one multi-valued attribute.

  • If you are creating new data stores for your virtual directory, Oracle strongly recommends that you use LDAP directories whenever possible. This is because the limited ability of relational databases to handle multi-valued attributes restricts the functionality available in your identity management application. If you are working with existing user data stored in a relational database, please familiarize yourself thoroughly with the restrictions on multi-valued attribute handling within the virtual directory.

10.2.2 About Limitations on Embedded Virtual Data Sources

Table 10-2 lists the limitations on embedded virtual data sources involving multiple database tables.

Table 10-2 identity Management Function Availability for Multi-table Configurations

Identity ManagementFunction
Table Aggregation Method
 

Join View Adapter

(Split Profile)

Native RDBMS Join Feature

Native RDBMS View Feature

Modify

No

Yes, if supported by the native RDBMS Join feature

Yes

Add

No

Yes, if supported by the native RDBMS Join feature

No

Delete

No

Yes, if supported by the native RDBMS Join feature

No


10.3 Implementation Architecture

The Oracle Access Manager-Oracle Virtual Directory implementation consists of three layers, shown in Figure 10-8.

Figure 10-8 Oracle Virtual Directory Implementation Layers

OVD implementation layers
Description of "Figure 10-8 Oracle Virtual Directory Implementation Layers"

Figure 10-8 shows the three Oracle Virtual Directory integration layers:

To users and applications in the Oracle Access Manager layer, the Oracle Virtual Directory system appears to be a single LDAP directory that includes the standard schema, plus the extended Oracle Access Manager attributes.

Within the virtual directory layer, Oracle Virtual Directory accepts requests for user data from the Oracle Access Manager applications, retrieves the requested data from the constituent data stores, transforms that data so that it conforms to the Oracle Access Manager schema, then passes the processed data back to the requesting Oracle Access Manager application. Figure 10-9 illustrates the steps in this process.

Figure 10-9 Data Request Handling in a Simple Oracle Access Manager-Oracle Virtual Directory Implementation

OAM-OVD data request handling
Description of "Figure 10-9 Data Request Handling in a Simple Oracle Access Manager-Oracle Virtual Directory Implementation"

Figure 10-9 shows the data request handling steps as follows:

Process overview: Request Handling

  1. In the Oracle Access Manager layer, applications request information from the virtual directory server.

  2. In the virtual directory layer, Oracle Virtual Directory locates the adapter that can serve the request and convert data from the virtual directory schema to the schema used by the target data source.

  3. In the target data store layer, the data is retrieved from or written to the target data stores.

  4. In the virtual directory layer, Oracle Virtual Directory transforms the retrieved data by applying the schema used by the virtual directory.

  5. In the Oracle Access Manager layer, Oracle Virtual Directory passes the transformed data back to the requesting Oracle Access Manager application.

To the administrators of the directories and databases in the target data store layer, the Oracle Access Manager-Oracle Virtual Directory implementation appears to have minimal impact, because implementation does not require permanent alteration of the native namespaces or data structures for either directories or databases.

Note:

Depending on the features you wish to use, you may need to add certain Oracle Access Manager auxiliary attributes as columns in target database tables. You also must extend the target LDAP directory schema with the user branch of the Oracle Access Manager schema. For details, see "About Schema Extension"

Furthermore, the virtual directory does not require that the data be copied permanently to a location beyond the control of the original data owner. Finally, data security is maintained or even enhanced, because access to individual data stores and even individual user profiles can now be controlled through Identity System attribute access control.

10.3.1 About Oracle Virtual Directory Drivers and Adapters

Oracle Virtual Directory uses special drivers and adapters to connect to the data sources it incorporates in its virtual directory.

JNDI Driver: The JNDI driver is shipped as part of the Oracle Virtual Directory installation package. A JNDI driver connects Oracle Virtual Directory to the LDAP directories, and a JDBC driver connects Oracle Virtual Directory to the RDBMS sources. You install these drivers on the computer that hosts Oracle Virtual Directory.

JDBC Driver: You must install the appropriate version of the JDBC driver for each RDBMS application you use. See the Oracle Virtual Directory Product Manual and the Oracle Virtual Directory and Virtual Directory Manager Installation Guide for details. Oracle Virtual Directory Database Adapters support any database that provides a JDBC driver.

Adapters: In addition to installing the appropriate driver for each data source in your virtual directory, you must configure an LDAP or RDBMS adapter for each directory or relational database that connects to Oracle Virtual Directory. These adapters contain the mapping information Oracle Virtual Directory uses to transform user profile information from the native data stores with the virtual directory schema. For details, see "Creating Data Store Adapters".

10.3.2 About Oracle Access Manager-Specific Data

Oracle Access Manager user, policy, and configuration data each occupy an LDAP directory information tree (DIT) branch. The Oracle Virtual Directory implementation requires that each branch exist in a specific location. Table 10-3 lists these requirements.

Table 10-3 Required locations for the branches of the Oracle Access Manager directory

Branch Location

Policy

Configuration

These branches must reside on one or more directory servers within the Oracle Access Manager Layer. The host directories are native to Oracle Access Manager.

User Data

All user data stores appear to be part of the top-level directory, which resides on the computer hosting Oracle Virtual Directory within the Oracle Virtual Directory layer.


Figure 10-10 illustrates the policy and configuration branch location for a Oracle Virtual Directory implementation.

Figure 10-10 Policy and Configuration Branch Location for a Oracle Virtual Directory Implementation

Policy and configuration branches for OVD
Description of "Figure 10-10 Policy and Configuration Branch Location for a Oracle Virtual Directory Implementation"

Table 10-3 describes the contents of this diagram.

10.4 About Schema Extension

For proper functioning, you need certain Oracle Access Manager attributes like userid, userpassword, and others to be extended to your schema.

Regardless of the native schemas or table structures used by the data stores in the virtual directory, Oracle Access Manager "sees" only the schema used by the Oracle Virtual Directory virtual directory. This is because Oracle Virtual Directory automatically maps the native object classes and attributes used by the various data stores to the corresponding logical object classes and attributes used by the virtual directory.

Oracle Virtual Directory supplies a default virtual directory schema, which is quite similar to an industry-standard schema for LDAP directories. You can use this as a starting point when developing a virtual directory schema optimized for the needs of your enterprise.

The files required for schema extension are located in:

IdentityServer_install_dir\identity\oblix\tools\\DataAnyWhere\OblixUserSchema\
*.ldif

Figure 10-11 illustrates both the required and optional schema extension tasks involved with Oracle Access Manager-Oracle Virtual Directory implementation.

Figure 10-11 Schema Extension Tasks for Implementation

Schema extension tasks
Description of "Figure 10-11 Schema Extension Tasks for Implementation "

Figure 10-11 shows the following steps:

Table 10-4 lists the schema requirements for various components of the virtual directory.

Table 10-4 Schema Requirements for Components of this Implementation

Component Schema Requirements

The virtual directory

Must be extended with the Oracle Access Manager user schema.

Should also be extended with customer attributes.

LDAP directories connected to Oracle Virtual Directory as federated data sources

Must be extended with the Oracle Access Manager user schema.

Databases connected to Oracle Virtual Directory as federated data sources

Table columns must be added to the database tables serving as primary data stores. Each column represents a Oracle Access Manager auxiliary attribute that enables a feature you plan to use. For details on the specific Oracle Access Manager features enabled by each attribute in the user branch schema, see "Oracle Access Manager Auxiliary Attributes".

Split profile

The schema of the primary data store must be extended with the Oracle Access Manager user schema. If the primary data store is a database table, a column must be added for each auxiliary attribute that enables a Oracle Access Manager feature you plan to use. For details on the specific features enabled by each attribute in the Oracle Access Manager user branch schema, see "Oracle Access Manager Auxiliary Attributes".


For more information, see:

10.4.1 Virtual Directory Schema

To enable your virtual directory to connect to and make use of all Oracle Access Manager features, you must extend it with appropriate attributes. For example, Oracle Access Manager requires attributes assigned to the Full Name, Login, and Password semantic types for Person and Group object classes. This and other essential user data occupies a branch in each Oracle Access Manager-enabled user directory. For further discussion, see the section about object classes in the chapter on setting up the Identity System.

For a detailed listing of the Oracle Access Manager schema, see the Oracle Access Manager Schema Description. You can update the Oracle Virtual Directory schema with Oracle Access Manager user attributes in the following two ways:

  • Automatically: This occurs if you select the "Auto configure objectclass" checkbox during Identity System setup, as explained earlier.

  • Manually: For details, see the section on configuring attributes manually in "Configuring Attributes Manually".

10.4.2 Target Directory Schemas

Just as you extend the schema of your parent virtual directory, you must also extend the native schema used by the LDAP directories included in your virtual directory. You achieve this with the ldapmodify.exe utility. For details, see "Extending Directory Schemas".

Note:

The Oracle Access Manager attributes must also be added to the primary data stores in any split profile included in your virtual directory. For details, see Table 10-4, "Schema Requirements for Components of this Implementation".

10.4.3 About Adding Attributes to Target Database Tables

For any databases included in your virtual directory, you must add table columns to simulate the auxiliary attributes that enable Oracle Access Manager features you plan to use. This applies only to database tables used as primary data sources. For example, you add an Out of Office Indicator column to enable the Surrogate feature in Oracle Access Manager workflows.

Note:

SQL-compliant databases do not possess any means to implement LDAP object classes directly. However, you can simulate an object class by mapping, for example, all the rows (user accounts) in a primary database table to the person object class used by the virtual directory.

For a listing of the Oracle Access Manager auxiliary attributes that enable specific functions, see the following:

10.4.4 Customer Schemas

Optionally, you can further extend the default Oracle Virtual Directory schema by adding customer attributes from your native data stores. For example, the default Oracle Virtual Directory person object class is UID, but you can add InetOrgPerson, then specify InetOrgPerson as the Person object class when you run Identity System setup.

Note:

inetOrgPerson and groupOfUniqueNames are required for user and group object classes when Oracle Access Manager is configured for Oracle Virtual Directory.

For details on modifying the default Oracle Virtual Directory schema using the Oracle Virtual Directory Manager (VDM, formerly known as the DME) interface, see the section on schema configuration in the chapter on configurations and settings in the Oracle Virtual Directory Product Manual.

For details on specifying the person object class, see the section about object classes in "Specifying Person and Group Object Classes".

Note:

When a customer attribute exists on one target data store, but not in the others, Oracle Virtual Directory returns the user profiles from those other data stores with that supplementary attribute set to NULL. Figure 10-12 illustrates this situation.

Figure 10-12 Mapping Supplementary Attributes to a Simple Virtual Directory

Map supplemental attributes to a simple virtual directory
Description of "Figure 10-12 Mapping Supplementary Attributes to a Simple Virtual Directory"

Figure 10-12 shows the following supplementary attributes mapped to a simple virtual directory:

  • First Data Store: Contains attributes mapped to a basic attribute, an extended attribute, and a common customer attribute.

  • Second Data Store: Contains the same attributes as the first data store, but with an attribute mapped to a unique customer attribute.

Hence, the virtual directory contains the following attributes:

  • Oracle Access Manager basic attribute, mapped to both first and second data stores

  • Oracle Access Manager extended attribute, mapped to both first and second data stores

  • Common supplementary attribute (mapped to both first and second data stores)

  • Unique customer attribute, mapped to second data store only, since the first data store does not have this type of attribute

10.5 Implementation Scenarios and Limitations

This discussion introduces the three scenarios that are supported when implementing Oracle Access Manager with Oracle Virtual Directory. The following sections also explain the limitations you encounter with each scenario.

10.5.1 Heterogeneous LDAP Directories

The Oracle Access Manager-Oracle Virtual Directory implementation can connect to multiple LDAP v3 directories from one or more vendors. Each directory can use a different schema (attributes and object classes). Because Oracle Virtual Directory transforms data at run-time, Oracle Access Manager sees the aggregated directories as a single directory to which the Oracle Access Manager schema has been uniformly applied.

When Oracle Access Manager is connected to a Oracle Virtual Directory system that includes just LDAP directories (and no RDBMS data stores), all Access System and Identity System functionality is available. However, you should observe several restrictions when combining directories.

Restrictions:

  • Oracle Access Manager supports only a single Person object class and a single Group object class associated with each user profile. Therefore, the various (and possibly multiple) Person and Group object classes in the native directories must be mapped to just one Person object class and one Group object class in the virtual directory.

  • The native namespaces of the constituent directories can be identical, but those namespaces must map to different namespaces within the virtual directory.

  • The login IDs for all users supported by the virtual directory must be unique across all the included directories. Figure 10-13 illustrates this situation:

Figure 10-13 Mapping Identical Namespaces into a Simple Super Directory

Mapping identical name spaces into a super directory.
Description of "Figure 10-13 Mapping Identical Namespaces into a Simple Super Directory"

Figure 10-13 shows the mapping of two identical LDAP directory name spaces to a super directory. The first LDAP directory contains attributes for Engineering, Marketing, and Sales. The second LDAP directory contains mappings for Engineering, Marketing, and HR.

The super directory maps to the Engineering, Marketing, Sales, and HR attributes. Its Engineering and Marketing mappings add an extra attribute (for EastCoast and WestCoast) to avoid using the same super directory namespace. This super directory also has mappings for Sales and HR, but these do not require extra attributes because the two native directories are not competing for the same super directory namespace.

  • All the attributes mapped from the constituent directories to a given attribute in the virtual directory must use a common data type. For example, the ObOutOfOfficeIndicator attribute cannot be a binary value in one data source, but a date (indicating when the user will return) in another.

  • If a native directory enforces referential integrity, references such as Manager or Group Member can only come from the same native directory. If the native directory doesn't enforce referential integrity, and that native directory also supports external references, references can reside in other directories.

  • RDN (relative distinguished name) is not supported.

10.5.2 Multiple RDBMS Databases

Databases that include a single table that contributes all the user profile attributes mapped by Oracle Virtual Directory can be federated into the virtual directory and made visible to Oracle Access Manager. In situations where more than one data table contributes attributes to a given user profile, four options exist for joining the tables so as to create a virtual data source containing the complete set of user attributes.

For more details about these options and the limitations each entails, see "About Joining Database Tables in an Embedded Virtual Data Source". See also "Database Connectivity Tips".

10.5.2.1 About Joining Database Tables in an Embedded Virtual Data Source

When more than one data table contributes attributes to a given user profile, four options exist for joining the tables to create a virtual data source containing the complete set of user attributes:

  • The native RDBMS Join feature

  • The native RDBMS View feature

  • The Oracle Virtual Directory Join View adapter (split profile)

  • A custom joiner based on your preferences

Figure 10-14 illustrates the four methods for joining multiple database tables within one of the three supported types of embedded virtual data sources.

Figure 10-14 Methods for Joining Tables within a Virtual Directory

Methods for joining tables.
Description of "Figure 10-14 Methods for Joining Tables within a Virtual Directory"

Figure 10-14 provides the following detailed information about the four methods:

  • The native RDBMS join feature: This method shows an RDBMS join created by a primary table and a secondary table, each with its own mapping adapter. It cannot be federated within the Oracle Virtual Directory super directory. It is unsuitable for Identity System use because it does not support Add, Modify, and Delete operations.

  • The native RDBMS view feature: This method shows an RDBMS view created by a primary table and a secondary table, each with its own mapping adapter. It can be federated within the Oracle Virtual Directory super directory, and it is suitable for Identity System use if the RDBMS application supports Add, Modify, and Delete operations.

  • The Oracle Virtual Directory Join Viewer adapter (split profile): This method shows a split profile with its Oracle Virtual Directory join view adapter created from a primary table and a secondary table, each with its own mapping adapter. It cannot be connected to Oracle Access Manager through Oracle Virtual Directory or federated in a Oracle Virtual Directory super directory. It is unsuitable for Identity System use because it does not support Add, Modify, or Delete operations.

  • A custom joiner: Its design is based on user preference.

Table 10-5 lists the specific limitations associated with each method:

Table 10-5 Methods for Joining Database Tables within a Virtual Directory

Method Suitability and Limitations

The native Join feature of the host RDMS application

The resulting Join is then federated as part of the virtual directory

  • Suitable for Access System use, because Oracle Access Manager Read and Search operations are both supported.

  • Not suitable for Identity System use, because Oracle Access Manager Add, Modify and Delete operations are not supported.

The native View feature of the host RDBMS application

The resulting View is then federated as part of the virtual directory.

  • Suitable for Access System use, because Oracle Access Manager Add and Search operations are supported.

  • Suitable for Identity System use only if the native View feature of the RDBMS application supports Add, Modify, and Delete operations.

The Oracle Virtual Directory Join View adapter method

  • Each data source connects to the Join View adapter through an RDBMS adapter.

  • The result is a split profile, which can be connected to Oracle Access Manager through Oracle Virtual Directory or be federated as part of the virtual directory, which is then connected to Oracle Access Manager.

  • Suitable for Access System use, because Oracle Access Manager Add and Search operations are supported.

  • Suitable for Identity System use, but Subtype Search, Add, and Delete operations can be performed only on the primary table.

  • All limitations to LDAP directories joined with the Join View adapter also apply to databases joined with the Join View adapter. For details, see "Join View Adapter Requirements and Limitations".

A custom joiner method

You can write a custom joiner to overcome the limitations imposed by the standard Join View adapter or the native Join and View features of your RDBMS application.

This involves custom programming. For details, consult the section on joiners in Oracle Virtual Directory Product Manual.


10.5.3 Split-Profiles

Virtual directories which draw the attributes for each user profile from two or more data sources are known as split profiles. These data sources can include any combination of LDAP directories and relational databases.

One data store serves as the primary data source. The schema of this data store must be extended with the Oracle Access Manager-specific user data. For details, see "About Schema Extension"

All additional data stores are secondary data sources. Not all Identity System functionality is supported for these secondary data stores. See "Join View Adapter Requirements and Limitations"It is not necessary to extend the Oracle Access Manager user schema to secondary data stores.

You can join the data sources in a split profile either through the standard Oracle Virtual Directory Join View tool (recommended method), or through a custom joiner. For details on creating a custom joiner, consult the Oracle Virtual Directory Product Manual.

10.5.3.1 Join View Adapter Requirements and Limitations

The Join View adapter supports all Access System operations on attributes that reside in either the primary or secondary data stores. This includes authentication, authorization, auditing, and single sign-on.

Note:

Identity System operations are supported, with the following restrictions.

Restrictions

  • The user login ID attribute for the split directory must reside in the primary data store. The user login password and the user full name attribute must also reside in the primary data store

  • The Oracle Access Manager user schema must reside the in the primary data store.

  • Base-level searches are supported for both the primary and secondary data stores.

  • Sub-tree searches are supported only for the primary data store. By implication, the following restrictions apply:

  • Attributes residing in a secondary data store must not be configured as searchable.

  • Attributes residing in a secondary data store must not be configured for filter operations involving sub-tree searches. This includes:

  • domain filters

  • dynamic group filters

  • group subscription filters

  • Query Builder filters

  • Modify is supported for all attributes, without regard to the specific data store in which those attributes reside.

  • Users, groups, and other objects can be created only in the primary data store.

  • Only users, groups, and other objects in the primary data store can be deleted. (Oracle Access Manager applications cannot delete objects in the secondary data store. This can be accomplished only through the target RDBMS application or LDAP directory, which may lead to synchronization problems in real-time environments.)

  • A given attribute can be configured from only one data store. Join values are not supported.

10.6 Implementation Requirements

Oracle Access Manager connects to the virtual directory just as it connects to any other LDAP directory; therefore, most supported Oracle Access Manager configurations should integrate smoothly with Oracle Virtual Directory. The following sections list support and requirement details for various aspects of the Oracle Access Manager-Oracle Virtual Directory implementation.

Oracle Access Manager: The LDAP directory branches containing Oracle Access Manager configuration and policy data must reside on one or more directory servers native to Oracle Access Manager. In other words, the configuration and policy branches cannot reside anywhere in the virtual directory, which contains any and all user data visible to Oracle Access Manager.

You specify the locations of your configuration, policy, and user data during installation and setup of the Identity Server, Policy Manager, and Access Server, as explained earlier.

Oracle Virtual Directory: For the latest operating support details for the host computer on which you are installing Oracle Virtual Directory, see Oracle Technology Network (OTN) at the following site:

http://www.oracle.com/technology/products/id_mgmt/coreid_acc/pdf/oracle_access_manager_certification_10.1.4_r3_matrix.xls

In calendar year 2007, the effective dates for daylight savings time (DST) are going to change within the United States. As long as the Operating System of the host computer properly handles the new DST transitions, there is no impact to Oracle Virtual Directory. When the Operating System is DST 2007 ready, Oracle Virtual Directory is ready. For more information, see the following notes on My Oracle Support (formerly MetaLink):

To locate knowledge base articles on My Oracle Support (formerly MetaLink) Web site

  1. Go to My Oracle Support at https://metalink.oracle.com.

  2. Log in as directed.

  3. Click the Knowledge tab.

  4. From the Quick Find list, choose Knowledge Base, enter the number of the note, click the Go button.

  5. From the results list, click the name of the note you want to view.

Operating System: You can implement Oracle Virtual Directory with Oracle Access Manager components installed on host computers running any of the supported operating systems

The LDAP directories and RDBMS databases supported by your virtual directory can be installed on any of the host platforms supported by Oracle Virtual Directory.

Java Runtime Environment: The host computer on which you install Oracle Virtual Directory must have the Java Runtime Environment installed.

The Oracle Access Manager-Oracle Virtual Directory implementation has been tested with JRE v1.4.

JNDI Driver: Use the JNDI driver that comes with your supported Oracle Virtual Directory installation package.

JDBC Driver: On the computer that hosts Oracle Virtual Directory, you must install a version of the JDBC driver appropriate for the RDBMS application you connect to the virtual directory. You can obtain the proper driver from the vendor of your RDBMS application. Oracle Virtual Directory Database Adapters support any database that provides a JDBC driver

If your virtual directory includes databases from multiple vendors, you must install a JDBC driver for each vendor represented. See the Oracle Virtual Directory Product Manual for details.

Data Set: The Oracle Access Manager-Oracle Virtual Directory implementation uses the UTF-8 character set. Oracle Virtual Directory is localization ready; however, only English is supported explicitly.

Relational Database: In general, Oracle Access Manager can connect to any virtual directory that includes RDBMS databases supported by Oracle Virtual Directory. For more information, see Figure 10-2, "Oracle Virtual Directory Implementation Involving Federated RDBMS Applications" for a listing of RDBMS applications that are supported for the Oracle Access Manager-Oracle Virtual Directory implementation. See also "Database Connectivity Tips".

Directory Server: In general, Oracle Access Manager can connect to any LDAP directory server supported by Oracle Virtual Directory. Figure 10-1, "Oracle Virtual Directory Implementation with Federated LDAP Directories" lists the LDAP directory servers specifically supported for the Oracle Access Manager-Oracle Virtual Directory implementation.

Caching: Oracle Virtual Directory does not provide explicit caching support.

For additional details on Oracle Access Manager-Oracle Virtual Directory implementation requirements and support, see:

10.6.1 Security Connection Support

Open or SSL connections are supported between Oracle Access Manager and Oracle Virtual Directory and between Oracle Virtual Directory and the native data stores.

For Active Directory, ADSI is not supported. You must use SSL, if you want to change passwords within your Active Directory. Otherwise, you can use Open mode.

Note:

For best performance when connecting an Active Directory to Oracle Virtual Directory, specify Password Only SSL as the security connection mode. For this scenario, you will also need to create an Open connection between Oracle Virtual Directory and the Active Directory.

Figure 10-15 illustrates the protocols used by the connections within the Oracle Access Manager-Oracle Virtual Directory implementation.

Figure 10-15 Protocol support for a simple Oracle Access Manager-Oracle Virtual Directory Implementation

Protocol support for an OAM-OVD implementation
Description of "Figure 10-15 Protocol support for a simple Oracle Access Manager-Oracle Virtual Directory Implementation"

This diagram shows protocol support for the three layers discussed in detail under Figure 10-8. Under each is the following:

  • Oracle Access Manager Layer: Shows the identity system.

  • VDS Layer: Shows the Oracle Virtual Directory layer accessing the identity system in the Oracle Access Manager layer. In turn, this layer accesses the Active Directory and Sun in the Target Data Store layer.

  • Target Data Store Layer: Shows the Active Directory and Sun. The active directory accesses the Oracle Virtual Directory layer using LDAP SSL (password only) and LDAP over Open. Sun accesses Oracle Virtual Directory using LDAP over SSL or Open. The Active Directory cannot use ASDL. If you want to change passwords with the Active Directory, you must use SSL mode. Otherwise, you can use Open mode.

10.6.2 Authentication Support

Oracle Virtual Directory supports the following authentication methods:

  • Pass credential authentication

  • Pure proxy

10.6.2.1 About Pass Credential Authentication

If you use Pass Credential authentication for your Oracle Access Manager-Oracle Virtual Directory implementation, you must set Pass Credentials to "Always" (or Bind Only) to ensure that Oracle Virtual Directory passes the user distinguished name and password supplied by Oracle Access Manager to the proxied LDAP directory.

For background details, consult the section on directory namespace and attribute mapping in the chapter covering configurations and settings in the Oracle Virtual Directory Product Manual.

10.6.3 Access Control Support

Make sure that both Oracle Access Manager and Oracle Virtual Directory access control are turned on and the default settings are in effect for the connection between Oracle Access Manager and Oracle Virtual Directory. For background details, consult the chapter on security and access control in the Oracle Virtual Directory Product Manual.

For the connections between Oracle Virtual Directory and the target data stores, turn on the access control supported each target data store. (Because Oracle Virtual Directory is an LDAP client, it must use the access control implementation native to each target directory server.) For details, consult the section on access control and the LDAP adapter in the configuration and settings chapter of the Oracle Virtual Directory Product Manual.

10.6.4 Failover Support

The Oracle Access Manager-Oracle Virtual Directory implementation implements failover support using the existing failover capabilities in the Oracle Access Manager, Oracle Virtual Directory, directory server, and RDBMS applications. You can implement failover on the following three levels:

  • Oracle Access Manager failover

  • Oracle Virtual Directory target source failover

  • Target data store failover

Oracle Access Manager Failover: An Identity or Access Server can connect to one or more primary virtual directory instances and one or more secondary Oracle Virtual Directory instances.

Oracle Virtual Directory Target Source Failover: Oracle Virtual Directory can implement failover protection between your virtual directory and your target data stores. For details, see the section on fault-tolerant deployments in the chapter on virtual directory planning in the Oracle Virtual Directory Product Manual.

Target Data Store Failover: Often, RDBMS applications and LDAP directory servers support failover in the form of clustering at the target data store level. In general, the mechanisms that implement this capability operate automatically and are not visible to Oracle Virtual Directory or Oracle Access Manager. For details, consult the documentation for your RDBMS application or LDAP directory server.

Note:

This chapter does not provide any specific procedures for configuring failover for your environment. You can set up failover as you usually do, according to your product documentation.

Figure 10-16 illustrates the types of failover potentially available within a Oracle Access Manager-Oracle Virtual Directory implementation.

Figure 10-16 Failover Options for Oracle Access Manager-Oracle Virtual Directory Implementations

Failover options
Description of "Figure 10-16 Failover Options for Oracle Access Manager-Oracle Virtual Directory Implementations"

10.7 About the Implementation Process

This section describes the implementation process.

When you have not yet installed Oracle Access Manager, you need to complete the activities outlined to complete the implementation with Oracle Virtual Directory.

Task overview: Implementing Oracle Virtual Directory when Installing Oracle Access Manager includes

  1. "Preparing Your Environment"

  2. "Installing and Configuring Oracle Virtual Directory and Virtual Directory Manager"

  3. "Installing the First Identity Server"

  4. "Extending Directory Schemas"

  5. "Creating Mapping Files for Adapters"

  6. "Creating Data Store Adapters"

  7. "Customizing Adapters and Mapping Files"

  8. "Completing Identity System Installation and Setup"

  9. "Testing Your Implementation"

10.8 Preparing Your Environment

Preparing your environment so that Oracle Access Manager can be implemented with Oracle Virtual Directory (also known as Data Anywhere), includes the following activities.

Task overview: Preparing your environment includes

  1. "Identifying Factors for Designing Your Implementation".

  2. "Preparing Directory Servers for Implementation".

  3. "Preparing Relational Databases for Implementation".

10.8.1 Identifying Factors for Designing Your Implementation

Before you start the implementation, you need to collect information and make decisions to guide the design of your Oracle Access Manager-Oracle Virtual Directory implementation.

Consider and answer the following questions, performing background investigation, as necessary.

To identify factors for this implementation

  1. Determine the data stores do you want to access through Oracle Virtual Directory.

    You can federate LDAP directories and RDBMS databases within your virtual directory. You can also create and federate embedded virtual data sources such as split profiles, native RDBMS Joins, and native RDBMS Views.

    Qualifying LDAP Directories as Target Data Sources: The incorporation of LDAP directories is relatively straightforward, because Oracle Access Manager supplies both an adapter template and a schema mapping template for each of the LDAP directory servers Oracle Access Manager supports for Oracle Virtual Directory implementation. See "About DN Conversion Toolkit"

    The only major restriction is that two directories cannot occupy the same namespace in a super directory, but you can prevent this sort of collision by mapping the name spaces used by the native directories to unique name spaces within the super directory. For details, see "Aggregated Namespaces".

    Qualifying RDBMS Databases as Target Data Sources: For RDBMS databases, you must first determine whether all the essential information Oracle Access Manager needs to operate exists within a single table. This includes the database columns that are mapped to the following attributes:

    • UID (user login id)

    • User password

    • Full Name

    • Person object class, which is generally implicit through the name of the table in which the essential fields reside. For example, all the user accounts in the Employee table of a database can be mapped to the inetorgperson person object class in the virtual directory. If you have another table such as Consultants, you can also map all of its user accounts to inetorgperson, then use the native RDBMS Join or View features to concatenate the user accounts. The important principle to observe is that all user accounts must be associated with the single person object class specified by the virtual directory.

    • Whatever Oracle Access Manager user branch attributes are necessary to enable the specific features you plan to use. For instance, you can add a column labelled OOO (Out of Office) to the Employee table so that you can run workflows against the virtual directory.

    • If all essential information exists within a single table, you can federate the database as part of the virtual directory. If not all the essential information exists in the database, or that information is spread across more than one table, the database might not be suitable for inclusion in the virtual directory, or you may have to use one of three available methods to transform the database into an embedded virtual data source, which you then federate within the virtual directory.

    Oracle Virtual Directory RDBMS applications Native LDAP directory servers

  2. Determine the items of virtual directory information you want to make visible to Oracle Access Manager.

    To ensure that Oracle Access Manager can interact with the virtual directory, you must make the essential items listed in step 1 visible to Oracle Access Manager. You should also determine what customer attributes you want to make visible to Oracle Access Manager. For instance, you can make employee cell phone numbers or birthdays visible by adding those attributes to the virtual directory.

  3. Determine the best approach to mapping the object class and attributes.

    This depends on the native schema used by your target data stores. You are free to create virtually any schema you wish Oracle Virtual Directory to make visible to Oracle Access Manager, but you should keep in mind the following points:

    • Information from two different target data stores can never occupy the same namespace in a super directory

    • If your virtual directory includes any embedded virtual data stores, you should avoid workflows that create, delete, or otherwise modify user accounts, because you generally cannot change information in the secondary data stores

    • The secondary data stores in embedded virtual directories (split profiles, RDBMS Joins, and RDBMS Views) cannot be included in filters or sub-searches. In other words, embedded virtual data stores such as split profiles, RDBMS Joins, and RDBMS Views are suitable for Access system operations (authentication and authorization), but they are generally inappropriate for identity management operations, because key functionality such as Add, Delete, and Modify are often not available for data in the secondary data stores.

    • The Oracle Access Manager-Oracle Virtual Directory implementation does not simultaneously support attributes with multiple values and databases used as target data stores. You can use multi-valued attributes if your virtual directory contains LDAP directories exclusively.

    Note:

    If you must use multi-valued attributes in conjunction with a database, see "Oracle Access Manager-Oracle Virtual Directory Implementation Templates" and "Multi-Value Attribute Problems".
  4. Decide what operations you want Oracle Access Manager to perform on each piece of information in the virtual directory.

    If you want to use certain Oracle Access Manager features such as surrogates in workflows, then you have to add columns to the primary database tables in your embedded virtual data stores. For lists that correlate specific User Manager and Group Manager functions to auxiliary Oracle Access Manager user attributes which that must be added to the primary tables in databases serving as target data stores, see "About Adding Attributes to Target Database Tables" and "Oracle Access Manager Auxiliary Attributes"..

  5. From the standpoint of policy management and identity management, what is the optimal DIT hierarchy for your virtual directory?

    You can choose between disjoint searchbases or a unified searchbase. For details, see "About Searchbase Options".

    If you chose the super directory option, you can optimize namespace aggregation and schema mapping to fit the needs of your organization. For instance, the engineering directories of two companies can be aggregated following a corporate merger so that only one set of access policies has to be configured for all the engineers in the new corporation. See "Aggregated Namespaces" for a simple example of namespace mapping that handles such a scenario.

  6. Decide what computers will host components and where to install:

    • Oracle Access Manager

    • Oracle Virtual Directory

    • RDBMS applications

    • Native LDAP directory servers

  7. Continue with:

10.8.2 Preparing Directory Servers for Implementation

You need to install and configure any native directory servers that you plan to integrate into Oracle Virtual Directory. This you can accomplish now.

Note:

A second requirement, which you will perform later, is to extend the native schema of each back-end directory server with Oracle Access Manager-related user and group information so your Oracle Virtual Directory and native schemas include the same Oracle Access Manager attributes.

To prepare each directory server

  1. Review "Implementation Requirements".

  2. Install back-end directory servers according to vendor instructions.

    Later you will extend the native schema with Oracle Access Manager-related attributes.

  1. Proceed as follows, depending on your environment:

10.8.3 Preparing Relational Databases for Implementation

Before you continue, you must begin preparing each of your relational databases for inclusion in the directory. This procedure is a prerequisite for creating an RDBMS-specific adapter.

To prepare each relational database for implementation

  1. Install and configure your RDBMS according to vendor instructions.

  2. Verify that the database contains, in a single table, all the fields that must be mapped to the essential attributes in the Oracle Access Manager schema used by the virtual directory, which are the following:

    • UID

    • User Password

    • Full Name

  3. Consider the following:

    • If the database does not contain all essential fields, it may not be suitable for inclusion in the virtual directory.

    • If all the essential fields are not in the same table, you cannot include that table in the virtual directory (because the essential fields residing in secondary tables are not searchable). Optional, customer fields can reside the secondary tables.

    • If all the essential fields are in the same table, you might have to create an embedded virtual data store using one of the following methods:

      • The Join View adapter

      • The View feature native to your RDBMS application

      • The Join feature of your RDBMS application

        Note:

        The three methods for incorporating multi-table databases mentioned earlier, necessarily limit certain Identity System functionality.
  4. From the Web site of your RDBMS application vendor, download the necessary driver libraries.

    For example, for Oracle you need to download the Oracle JDBC thin driver: ojdbc14.jar (or newer).

  5. Install the driver according to your vendor instructions.

  6. Skip to "Installing and Configuring Oracle Virtual Directory and Virtual Directory Manager".

    Later you will be instructed to deploy the JDBC driver for your target database on the computer hosting Oracle Virtual Directory.

    See also Database Connectivity Tips.

10.9 Installing and Configuring Oracle Virtual Directory and Virtual Directory Manager

After you have selected an implementation configuration and prepared your data sources, you must install both the Oracle Access Manager and Oracle Virtual Directory software necessary for the implementation. The following task overview summarizes the procedures you need to complete.

Task overview: Installing and configuring Oracle Virtual Directory and Virtual Directory Manager includes

  1. "Installing Oracle Virtual Directory"

  2. "Installing Virtual Directory Manager".

  3. "Creating a Project Space and Server"

  4. "Obtaining/Updating Sample Adapter and Mapping Templates"

  5. RDBMS: "Deploying JDBC Driver Libraries for Your RDBMS"

  6. "Configuring the Oracle Virtual Directory SSL Listener (Optional)"

10.9.1 Installing Oracle Virtual Directory

You install the Oracle Virtual Directory as usual. There are no specific measures you need to take to facilitate implementation with Oracle Access Manager.

To install Oracle Virtual Directory

  1. Install and setup Oracle Virtual Directory following the instructions in the Oracle Virtual Directory and Virtual Directory Manager Installation Guide.

  2. Use the default settings provided in the Oracle Virtual Directory documentation.

  3. Record information about your Oracle Virtual Directory installation for use when you install the first Identity Server, including:

    • Host Name: The DNS host name of the computer hosting Oracle Virtual Directory.

    • Port Number--The Oracle Virtual Directory LDAP licensing port.

    • Bind DN for the user data directory server: The Oracle Virtual Directory virtual DN, which may be any part of the virtual tree.

    • Password: The password for the user data bind DN.

  4. Configure Oracle Virtual Directory as described in your Oracle Virtual Directory documentation.

    Note:

    If you want to configure an SSL connection between the Oracle Virtual Directory and Oracle Access Manager, see "Configuring the Oracle Virtual Directory SSL Listener (Optional)".
  5. Proceed with "Installing Virtual Directory Manager"

10.9.2 Installing Virtual Directory Manager

You install the Virtual Directory Manager as usual. There are no specific measures you need to take to facilitate implementation with Oracle Access Manager.

To install the Virtual Directory Manager

  1. Follow the instructions in the Oracle Virtual Directory and Virtual Directory Manager Installation Guide.

  2. Use the default settings provided in your Oracle Virtual Directory documentation.

  3. Configure the Virtual Directory Manager as described in your Oracle Virtual Directory documentation.

  4. Proceed with "Creating a Project Space and Server".

10.9.3 Creating a Project Space and Server

You create a project space and server using the Virtual Directory Manager, as you usually do. Some sample steps are provided here; however, these are not intended as a complete tutorial.

For additional information, see your Oracle Virtual Directory documentation.

To create a project space and server

  1. From Start click VDM.

  2. From the menu under the Server Navigator window, select Directory Management Project.

  3. Specify a unique project name.

  4. Right-click the project name, then select New > Server.

  5. Enter a unique server name.

  6. Click Finish.

  7. Proceed to "Obtaining/Updating Sample Adapter and Mapping Templates".

10.9.4 Obtaining/Updating Sample Adapter and Mapping Templates

Oracle Virtual Directory 10.1.4 and later provides sample Oracle Access Manager templates and mappings out-of-the-box in Oracle Virtual Directory Manager. Depending on the Oracle Virtual Directory release you are using, proceed as follows:

  • Skip this topic if you are using Oracle Virtual Directory 10.1.4 and later and proceed with all following topics as needed for your environment.

  • Continue with the information and steps in this topic if you are using a release of Oracle Virtual Directory before 10.1.4, or if you choose to use the sample adapter and mapping templates in the Oracle Access Manager distribution.

The Oracle Access Manager distribution provides two types of sample templates specific to each data store and also to a specific user-defined schema:

Sample Adapter Templates: Sample templates for vendor-specific adapter files that you can use as the basis for individual adapters that connect native data stores to Oracle Virtual Directory. Oracle provides sample adapter templates with the Oracle Virtual Directory installation. These are available automatically in the Adapter Template list within Oracle Virtual Directory. However, you can create your own templates from scratch if you like.

The Oracle-provided sample adapter template files are stored in:

IdentityServer_install_dir\identity\oblix\tools\DataAnyWhere\plugins\
 OracleAccessManagerOVIDTEmplates
 \adapter_templates

Sample Mapping Templates: Sample Mapping files that you can use so that Oracle Virtual Directory can transform the schema (or database fields) used by native data stores to the logical schema used by the aggregated virtual directory made visible to Oracle Access Manager. Oracle-provided sample mapping templates are provided in:

IdentityServer_install_dir\identity\oblix\tools\DataAnyWhere\plugins\
 \OracleAccessManagerOVIDTEmplates\mapping_templates

Note:

At this point you just obtain and update the sample templates. Later, you use these to configure each connector and perform the schema and the namespace mapping. For more information, see "Creating Mapping Files for Adapters" and "Creating Data Store Adapters".

To copy the sample templates to the Virtual Directory Manager

  1. Obtain the Oracle Access Manager-provided templates, if needed, as follows:

    1. Obtain the files from the DNConversionToolkit.

    2. Unzip the distributed zip file (for example, COREidFeatures_10.1.4.bin.dist.zip) to the Oracle Virtual Directory Manager directory. For example:

      VDM_install_dir\  for example 
      C:\Oracle\OViD Manager
      
    3. Restart the Oracle Virtual Directory Manager.

  2. Proceed to one of the discussions that follow, depending on your environment:

10.9.5 Deploying JDBC Driver Libraries for Your RDBMS

You complete this procedure only if your implementation will include an RDBMS.

After downloading and installing the JDBC driver libraries and completing the preceding steps, you need to complete the procedure that follows to deploy each library. For example, for Oracle you need to deploy the Oracle JDBC thin driver: ojdbc14.jar (or newer).

Again, the instructions here give you an idea of how to proceed. For more information, see your Oracle Virtual Directory documentation.

To deploy a JDBC driver library

  1. Complete activities in "Preparing Relational Databases for Implementation".

  2. Launch the Virtual Directory Manager, as usual, and navigate to the Server Navigator window.

  3. Right click Oracle Virtual Directory, then select Manage Server Libraries from the menu.

  4. Select the file menu.

  5. From the file menu select New, then select Deploy.

    The JDBC Driver files are stored in JDBC_Driver_install_dir/lib (for example, C:\Program Files\JDBC).

  6. Select the libraries for your environment.

    msbase.jar

    mssqlserver.jar

    msutil.jar

  7. Deploy as usual.

10.9.6 Configuring the Oracle Virtual Directory SSL Listener (Optional)

The procedure that follows is required only if you wish to set up an SSL connection between Oracle Access Manager and the Oracle Virtual Directory. Skip this section if you plan to use an Open connection.

To configure the Oracle Virtual Directory SSL listener

  1. Generate a private key, as follows:

    1. Right-click server and select Server-Manager Server keys.

    2. Click Generate Key.

    3. Fill in the key information.

      The Common Name you use must be exactly the host name you use in Oracle Access Manager later on.

  2. Generate a certificate request, as follows:.

    1. Select the key just generated from Key/Certificate window.

    2. Click Request Certificate.

  3. Sign the certificate request, as follows:

    1. Start MicroSoft certificate service using http://computer/certsrv

    2. Click the link Request a Certificate.

    3. Click the link Advanced Certificate Request.

    4. Click the link Submit a Certificate Request by Using Base64....

    5. In an editor, open the certificate request file generated in step 2.

    6. Copy the text and past it to the Base64-encoded window in the certificate service.

    7. In Certificate Template, select Web Server and then Submit.

    8. Download the CA certificate in Base64 encoded format.

  4. Import the signed certificate to Oracle Virtual Directory, as follows:

    1. On Virtual Directory Manager Key/Certificate window, click Import.

    2. Select the certificate file obtained in step 3.

    3. Provide the alias exactly the same as the alias given for the key in step 1.

    4. Once you Finish, you should see the Issuer of the key entry is updated to the CA.

  5. Configure LDAP listener with SSL, as described next:

    1. In Virtual Directory Manager Server Navigation Pane, right click Listeners and select New - Ldap Listener.

    2. Provide a port.

    3. In Server Key Alias, select the key entry created in 4.

    4. Save to Server.

  6. Install the certificate in Oracle Access Manager, according to the following conditions:

    • Identity Server Not Installed: In this case, you can install the certificate automatically during Identity Server installation. In this case, skip to "Installing the First Identity Server".

    • Identity Server Installed: In this case, complete the following steps to create and import the certificate.

  7. Create the cert8.db, if needed:

    1. Go to IdentityServer_install_dir\identity\oblix\tools\certutil.

    2. Run the following command:

      certutil -d IdentityServer_install_dir\identity\oblix\config -N -f
      
  8. Import the root CA to the Identity Server using the following command:

    certutil -d IdentityServer_install_dir\identity\oblix\config -A -n ldap -a -t "C,," -i root_ca_file
    

    Note:

    In the certutil command, the -t (trusted arguments) flag should be followed by the trust attributes that will be assigned to the certificate, enclosed in double-quotes.
  9. Reconfigure the Identity Server as follows:

    1. From the Identity System Console, select System Configuration, Directory Options.

    2. Locate the user profile and DB instance, as described in the Oracle Access Manager Identity and Common Administration Guide.

    3. Mark SSL, then enter the secure port of Oracle Virtual Directory.

    4. Restart the Identity Server.

    5. Repeat this for all the instances for which you want to use SSL.

    6. Rerun Identity System setup manually, as described in theOracle Access Manager Identity and Common Administration Guide.

10.10 Installing the First Identity Server

For successful implementation with Oracle Virtual Directory, you must complete Oracle Access Manager installation in stages. During this first phase you install only the first Identity Server. This installation provides the ldif files you need to extend the native schema of directory servers you plan to integrate with Oracle Virtual Directory.

During Identity Server installation for Oracle Virtual Directory, you must specify the following:

When you finish the procedure that follows, you can extend the schema of native directory servers you plan to integrate with Oracle Virtual Directory.

Note:

When you have multiple user directory server profiles, ensure that each distinguished name for a user entry is unique. Otherwise there could be confusion during authentication.

To install the first Identity Server

  1. Review installation prerequisites, requirements, options, and Identity Server installation considerations in Part I, "Installation Planning and Prerequisites".

  2. Start installing the first Identity Server, and proceed through defining directory server details, as described in Chapter 4, "Installing the Identity Server".

    Storing Oracle Access Manager configuration data separately is required. Later you are asked to provide details about both the user data directory server and configuration data directory server.

  3. When asked where data is to be stored, indicate that configuration data is to be stored separately.

    Configuration data stored separately

    Oracle recommends that you automatically extend the schema during installation of the first Identity Server. You update the schema only once. Either Yes response will result in questions about directory server type and specifications.

  4. When asked about updating the schema, select the Automatic schema update option for separate storage of user and configuration data.

  5. When asked about user data directory server details, specify the following for this implementation:

    1. User Data Directory Server: Data Anywhere.

    2. User Data Directory Server Details:

      Host name: The DNS host name of the computer hosting Oracle Virtual Directory.

      Port number: on which the directory server listens: Specify the Oracle Virtual Directory LDAP licensing port.

      Bind DN: For the user data directory server, specify the Oracle Virtual Directory virtual DN, which may be any part of the virtual tree. For example: o=ovd_data,o=us

      Password: Specify the password for the user data bind DN.

  6. When asked about configuration data directory server details, specify the following for this implementation:

    1. Configuration Data Directory Server: A native directory server type.

    2. Configuration Data Directory Server Details:

      Host name: The DNS host name of the computer hosting a native directory where you will store Oracle Access Manager configuration data.

      Port number: Specify the port on which the configuration data directory server listens.

      Bind DN: For the configuration data directory server.

      Password: The password of the configuration data bind DN.

  7. Finish installing the first Identity Server as usual.

  8. Proceed to the next topic, "Extending Directory Schemas" and continue through all topics.

Important:

Finishing the Identity Server installation and setup is the last thing you do to complete this implementation. If you do not complete all other activities first, your implementation with Oracle Virtual Directory might not be successful.

10.11 Extending Directory Schemas

The Identity System requires attributes assigned to the Full Name, Login, and Password semantic types for Person and Group object classes.

Before you continue, you need to complete the procedure that follows to ensure that you:

To extend directory schemas

  1. Locate the ldif files to use when you extend the schema of a back-end directory server you are preparing for inclusion in the virtual directory, as follows:

    IdentityServer_install_dir\identity\oblix\tools\DataAnyWhere\OblixUserSchema
    
  2. Use Table 10-6 as a guide to manually configure attributes for each specific back-end directory server you will include in the virtual directory.

    Note:

    If you do not find the appropriate *.ldif file in IdentityServer_install_dir\identity\oblix\tools\DataAnyWhere\OblixUserSchema, you may use the corresponding *.ldif located in IdentityServer_install_dir\identity\oblix\data\common.

    Table 10-6 Files and Commands to Extend Native Schemas with Oracle Access Manager Attributes

    Directory Server and ldif File Manual Schema Update Commands

    Active Directory

    ADUserSchema.ldif

    or

    ADAuxSchema.ldif

    depending on your environment

    ldifde -s host -t port -a bind-dn -w password -c fromDN toDN -i -f ADuserSchema.ldif

    ADAM

    ADAM_user_schema_add.ldif

    or

    ADAMAuxSchema.ldif

    depending on your environment

    ldifde -s host -t port -a bind-dn -w password -c fromDN toDN -i -f ADAM_user_schema_add.ldif

    SunONE

    • iplanet_user_schema_add.ldif

    • iplanet5_user_index_add.ldif

    ldapmodify -h host -p port -D bind-dn -w password -a -f iplanet_user_schema_add.ldif

    ldapmodify -h host -p port -D bind-dn -w password -a -f iplanet5_user_index_add.ldif

    eDirectory

    • NDS_user_schema_add.ldif

    • NDS_user_index_add.ldif

    ldapmodify -h host -p port -D bind-dn -w password -a -f NDS_user_schema_add.ldif

    ldapmodify -h host -p port -D bind-dn -w password -a -f NDS_user_index_add.ldif

    IBM

    • v3.user.ibm_at.ldif

    • v3.user.ibm_oc.ldif

    ldapmodify -h host -p port -D bind-dn -w password -a -f v3.user.ibm_at.ldif

    ldapmodify -h host -p port -D bind-dn -w password -a -f v3.user.ibm_oc.ldif

    Oracle Internet Directory

    • OID_user_schema_add.ldif

    • OID_user_index_add.ldif

    ldapmodify -h host -p port -D bind-dn -q -a -f OID_user_schema_add.ldif

    Please enter bind password: 
        bind successful 
    

    ldapmodify -h host -p port -D bind-dn -q -a -f OID_user_index_add.ldif

    Please enter bind password: 
        bind successful 
    

    With Oracle Internet Directory, Oracle recommends that you set the LDAP_PASSWORD_PROMPTONLY variable to TRUE or 1 to disable the less secure -w and -P password options whenever possible, and use the -q (or -Q) options, to prompt you for the user password (or wallet password).


  3. Repeat this procedure for each directory server in your installation.

    Important:

    If you are working with an existing Oracle Access Manager installation, you need to manually extend the Oracle Virtual Directory schema using the following step.
  4. Manually extend the Oracle Virtual Directory schema with Oracle Access Manager attributes using the VDE_user_schema_add.ldif file as follows:

    IdentityServer_install_dir\identity\oblix\tools\\DataAnyWhere\OblixUserSchema\V
    VDE_user_schema_add.ldif ldapmodify -h host -p port -D bind-dn -w password
    -a -f VDE_user_schema_add.ldif
    
  5. Extend your Oracle Virtual Directory schema to represent all your back-end data sources as follows:

    • Either add attributes from your back-end directory to the Oracle Virtual Directory schema:

      Active Directory Example: Update/add attributes from "inetOrgPerson" object class to Oracle Virtual Directory inetOrgPerson object class.

      Database Example: Add attributes from your Oracle Employees table to the inetOrgPerson object class.

    • Or create a new object class having all visible attributes from the native data store.

      Active Directory Example: Create a new object class (MyCompanyPerson) having all needed attributes from "user" or "inetOrgPerson" object class.

      Database Example: Create a new object class (MyCompanyPerson) having all visible attributes from your Oracle Employees table to the inetOrgPerson object class.

      Note:

      The schema extension can be done using the VDM user interface (VDM > Your_Project, Your_Server, Engine, Schema. When your extended schema is in an ldif file, use ldapmodify to load it into your Oracle Virtual Directory instance.

10.12 Creating Mapping Files for Adapters

You are ready to create the mapping files needed for the data store adapters you will develop later:

You can create your own mapping files from scratch or you can use the Oracle-provided sample files, which include several plug-ins. See "Oracle Access Manager-Oracle Virtual Directory Implementation Templates".

The steps that follow use the Oracle-provided samples, and are included here as a guide. The procedure is similar for both LDAP and RDBMS mapping files.

For details about using the VDM, see your Oracle Virtual Directory documentation.

To create a mapping file for a data store adapter

  1. Complete activities in "Obtaining/Updating Sample Adapter and Mapping Templates" so you have the sample mapping files provided by Oracle.

  2. In the VDM Server Navigator window, select your Oracle Virtual Directory server.

  3. From the Oracle Virtual Directory select Engine, from engine menu select Mapping.

  4. Right-click Mapping, then select New Mapping.

    In the New Mapping window that opens, a File list contains the names of the sample mapping templates you copied to the VDM earlier.

  5. Specify the information requested:

    • File Name: Enter a unique name for the version you will modify

    • Server: Specify the server containing your project.

    • File template: Choose the sample mapping template you want.

    You need to assign a new name so that your changes do not over write the sample template, which you should preserve for future use.

  6. In the Name field, enter a unique name for the version you will modify.

  7. Click Finish.

    The name appears in the window on the left.

  8. In the Virtual Directory Manager Server Navigator window, select the name of the file you just created to display it in the window on the right.

    Before you finish Identity System installation and setup you must customize your mapping file and add it to the data store adapter. You can customize the mapping file now, or later.

  9. Continue as follows:

    You can modify the mapping script for your needs now or after you create the data store adapter. See "Customizing Adapters and Mapping Files"When you customize the file and include it file in an adapter:

    • If you are not using the Oracle-provided sample file, you may need to create a dummy user (see "Unexpected Group Deletion Problem".)

    • If you are using the Oracle-provided sample, this occurs automatically.

10.13 Creating Data Store Adapters

You now need to create an adapter for each data store you want to connect:

You can create an adapter from scratch or use the sample templates provided by Oracle, which provide you with a quick start. When you use a sample adapter template provided by Oracle, you need to fill in connection and credential information, logical root, remote root, and so on, to create the adapter. You also need to modify and tailor the settings for each data store. Once the adapter is created, the information defined in the template will be set for this adapter.

For details about Oracle templates, see "Oracle Access Manager-Oracle Virtual Directory Implementation Templates" For details about modifying templates, see "Customizing Adapters and Mapping Files".

10.13.1 Creating Adapters for LDAP Directories

The procedure for creating an LDAP adapter is similar regardless of the host directory server. You first create the LDAP adapter, then add plug-ins such as your mapping file.

As described in the following discussion, ADAM and Active Directory adapters do include some requirements that other adapters do not:

About Active Directory and ADAM Adapters: Active Directory and ADAM require two adapters each: one for SSL that must be created first and a second for an open connection that must be created second. Oracle provides individual sample templates for each of these. Setting up this environment involves:

  • Creating an Active Directory or ADAM adapter for an SSL connection

  • Creating an Active Directory or ADAM adapter for an open connection

There are two plug-ins that Active Directory and ADAM adapters require. If you use the Oracle-provided sample templates, the following two plug-ins are already included. However, if you create your own templates, you must add the following two plug-ins manually.

  • Active Directory Password Plug-In: Active Directory and ADAM require the use of the secure mode to set or change a password.

    To address performance concerns, a Password Only SSL mode is supported so that while normal operations are going through the adapter with the Open connection, operations related to password change/set functions are redirected to the adapter with the SSL connection.

    Note:

    If you do not use the Oracle-provided sample templates, you need to add the SSL adapter you create as the Active Directory Password plug-in to the open-connection adapter you create, as described in "To create an adapter for LDAP"
  • Active Directory Ranged Attributes Plug-In: Active Directory and ADAM require the use of the Active Directory Ranged Attributes plug-in to handle the group page issue.

    This plug-in concatenates all the group pages returned by Active Directory/ADAM and returns the information to the Oracle Virtual Directory client as one result.

    Note:

    If you use the Oracle-provided sample templates, you simply edit the value. If you do not use the Oracle-provided sample templates, you must create and add the Active Directory Ranged Attributes plug-in to the open-connection adapter you create.

One generic procedure is given for all LDAP directories. This example includes steps to create two adapters for ADAM (assuming that you are not using an Oracle-provided example).

Note:

When you use Oracle-provided templates for Active Directory or ADAM, see step 17 for details about the open connector you need to create. The SSL connector is included in the Oracle template.

To create an adapter for LDAP

  1. Complete activities in "Customizing Adapters and Mapping Files" so you have the sample adapter templates provided by Oracle.

  2. In Virtual Directory Manager, navigate to Adapters and click New, LDAP Adapter to display the Adapter configuration screen.

  3. Select the appropriate adapter type from the Adapter Template list.

    For example:

    Adapter Template: OblixADAMSSLAdapterUsingMapper

  4. Enter a unique adapter name.

    For example:

    Adapter Name: CustomAdamSSLAdapter

  5. Fill in the server address, server proxy port, and server proxy bind DN for the LDAP Server to which you wish to connect.

  6. Supply a Proxy Password and Passthrough credentials.

    For example:

    Proxy Password: xxxxxxxx

    Passthrough credentials: Always

    Specifying "Always" may impact performance; however, using "Bind Only" or "Never" is less secure.

    Next you specify the connections options.

    Note:

    When you do not use Oracle-provided templates or ADAM or Active Directory, you create an SSL adapter to include as a plug-in to an open connection adapter.
  7. For Connection Options in an SSL version (not needed when using Oracle-provided templates), select:

    Connection Options: Secure SSL/TLS

    This step connects to the data store and downloads the certificate automatically.

  8. For Remote Base, click the button labeled with an ellipsis (...).

    A screen appears showing the searchbase (root DN) of the LDAP directory server you connected to.

    At this point, you need to map the physical namespace to the logical namespace.

  9. Select the remote physical namespace (searchbase) from the back-end data store. For example:

    ou=company,c=us,dc=intranet,dc=pspl,dc=co,dc=in
    
  10. In the Mapped Namespace field, enter the logical Oracle Virtual Directory namespace.

    For example, if your Oracle Virtual Directory root suffix is o=MyCompany,c=us, you can have a mapped namespace of:

    ou=ADAM,o=MyCompany,c=us
    
  11. Click Finish.

    You should see the newly created LDAP adapter in the Server Navigator window, under the Adapter list.

  12. Click the new Adapter name in the Server Navigator window:

    1. Click the Routing tab in the right pane.

    2. In General Settings, ensure that visibility is set to internal if this is an SSL adapter for Active Directory or ADAM.

      For example:

      General Settings

      Visibility: Internal

    3. Click Finish.

    For Oracle Access Manager to function properly, DN attributes used in the product (for example, manger, secretary, uniqueMembers, and so on) need to be converted to the logical view format when viewed then back to the physical format when stored.

  13. Optional: DN Attributes:

    1. Double click the adapter you created.

    2. In the right window, click the "Config" tab.

    3. Under Settings, specify DN Attributes in a comma separated list of Oracle Virtual Directory attributes for all object classes/tables.

  14. Right-click the adapter name in the Server Navigator window, then select Save to Server.

    You have completed your first adapter and need to repeat this procedure for each data store in your implementation.

    When, you need to repeat this procedure to create a second adapter for ADAM, this time with an open connection.

    Note:

    In the following step, only the differences between the SSL adapter you created earlier and the open connection adapter you need to create for ADAM and Active Directory are identified. All other specifications remain the same.
  15. ADAM/Active Directory Open Connection Adapters: Create the required open connection adapter by repeating the earlier procedure with the following differences. For example:

    Adapter Template: OblixADAMAdapterUsingMapper

    Adapter Name: CustomAdamOpenAdapter

    Port: open_port

    Connection Options: (Neither box should be checked)

    Searchbase: Same as the SSL adapter

    Visibility: Yes

  16. Optional: DN Attributes: For Active Directory or ADAM adapters created without the Oracle-supplied sample template, this should be the same list as used in the SSL adapter created earlier.

    1. Double click the Active Directory adapter you created.

    2. In the right window, click the "Config" tab.

    3. Under Settings, specify DN Attributes in a comma separated list of Oracle Virtual Directory attributes for all object classes/tables.

  17. Save and Deploy, as usual.

  18. Continue as follows:

10.13.2 Configuring a Database Adapter

You can skip this procedure if it is not relevant to your environment.

The following procedure is a generic example. Your environment will vary.

To configure a database adapter

  1. Complete activities in "Deploying JDBC Driver Libraries for Your RDBMS"

  2. In Virtual Directory Manager, navigate to Adapters > New > Database Adapter to display the Adapter configuration screen.

  3. Select the OblixDBAdapterUsingScript identified in "Database Template: OblixDBAdapterUsingScript".

  4. Enter a unique Adapter Name.

  5. Enter logical namespace DN for the mapping.

  6. Select "use predefined database".

  7. Select the Type of the database you plan to connect, such as MS SQL Server.

  8. Fill in the host, port, database name, username and password for the database server.

  9. Click Validate Connection to see if the connection information is correct, then click Next.

  10. Proceed as follows for your environment:

    • Other Templates: When you are not using Oracle-provided templates, complete steps 11, 12, 13, and 14 as indicated.

    • Oracle-Provided Templates: When using the Oracle-provided "Database Template: OblixDBAdapterUsingScript" during steps 11, 12, 13, and 14 you need only click Next.

  11. On the database adapter mapping Choose table screen, complete the following steps:

    1. Select the table you want to use from the left pane

    2. Click ">" to move it to right pane.

    3. Click Next.

  12. On database adapter mapping: Build Joins screen, click Next to skip it.

  13. On the database adapter mapping: map attributes screen, complete the following steps:

    1. Click the logical DN you specified before.

    2. Click Add to add the hierarchy.

    3. In the pop up window, complete the following activities:

      In object class, fill in the LDAP object class (such as inetorgperson) to which you want to map.

      In the RDN field, fill in the RDN attribute name (such as cn).

      Click OK.

  14. On database adapter mapping: map attributes screen, complete the following steps:

    1. Click the node you just created (for example, "cn= inetorgperson").

    2. Click Add.

    3. In the pop up window, select ldap attribute, table name, and table column.

      You can type in the LDAP attribute name (such as obuseraccountcontrol) if it is not on the list.

    4. Continue this until all the attributes that you want to map are mapped.

      Note:

      You need to map at least the cn, uid, password, and obuseraccountcontrol fields for Oracle Access Manager to work properly. Be sure that obuseraccountcontrol is Activated.
    5. Add password and obuseraccountcontrol columns to an existing table in the database if table does not contain those columns.

  15. Click Finish.

    You should now see the newly created DB adapter in the Server Navigator window, under the Adapter list.

  16. Right-click the Adapter name in the Server Navigator window, select Save to Server.

  17. Check the Client view in the Browser pane to verify the configuration.

  18. All: Continue as follows:

10.13.3 Creating a Split-Profile Adapter

A split profile is one where you have the same users with different attributes stored on different directory servers.

The primary data store contains essential attributes while secondary data stores provide optional attributes. For example, suppose you have two different directory server types and an RDBMS. In this case, you need to create a split-profile adapter to join the views together.

Before you can create a split-profile adapter, you need to have the individual data store adapters created. Each primary and secondary adapter must have "Visibility" set to "Internal" so that only Oracle Virtual Directory will see them.

While you create the split-profile adapter, you identify the primary adapter and bind to that primary adapter. After creating the split-profile adapter, you specify join rules to identify the primary adapter and the first secondary adapter to be joined. While you specify join rules, you can indicate that you want to join the primary adapters to many secondary adapters (one to many).

Note:

Oracle provides a Join View adapter template.

The searchbase (Oracle Virtual Directory refers to this as the root base) for a split-profile should be the same as that of the primary directory.

You need to ensure that the logical view of the split-profile adapter is the same as the primary data store. The split profile adapter does not map the values of DN attributes from Primary logical view to the split-profile logical view and vice versa.

The procedure that follows provides a general guide using the Join View method. For more information, see your Oracle Virtual Directory documentation. The adapters in this example include ADAM as the primary, and Sun as the secondary. In this case, you use the open-connection adapter you created for ADAM because it includes the appropriate plug-ins, including the SSL adapter. Your environment will vary.

To create a split-profile adapter

  1. Create an adapter for each data store you plan to join, as described in "Creating Adapters for LDAP Directories".

  2. In the Virtual Directory Manager Server Navigator window, select an Oracle Virtual Directory server, then select Engine.

  3. Right-click Adapters, then select New and then select the Join View Adapter.

  4. In the dialog box, Adapter Template, select a default Join View template.

  5. In the Adapter Name field, enter a unique name for your customized template.

    For example:

    Adapter Name: CustomJoinADAMSun

  6. In the Adapter Suffix/Namespace list, enter the same namespace (base DN) with the DN of the primary adapter.

    In this example, ADAM is the primary adapter. You must specify the name of the open-connection adapter, which includes the SSL adapter as a plug-in.

  7. In Primary Adapter field, select your primary adapter.

    For example:

    Primary Adapter: CustomAdamAdapter

  8. In the Binding Adapter list, select the same adapter.

    For example:

    Binding Adapter: CustomAdamAdapter

  9. Click Finish.

    The adapter name appears in the left pane and the Join View Primary Adapter Configuration window appears on the right.

  10. In the Join View Primary Adapter Configuration window, Settings area, enter settings for the primary and binding adapters.

    For example:

    Settings

    Primary Adapter: CustomAdamAdapter

    Binding Adapter: CustomAdamAdapter

  11. Beside Join Rules, click the New button to display the Enter Join Rules dialog.

  12. In the Enter Join Rules dialog, select the secondary adapter to join, then select a type class, and conditions for your environment.

    For example:

    Joined Adapter: CustomSunAdapter

    Type Class: One to Many Joiner

    Conditions: cn=cn

  13. Repeat step 12 to join another adapter; otherwise, skip this step.

  14. Right-click the adapter name in the Server Navigator window, select Save to Server.

  15. Confirm the new configuration in the Browser window, Client View.

10.13.4 Creating a Multiple-Directories Adapter

When you have multiple directory servers behind Oracle Virtual Directory, you need to create a local data store adapter entry within Oracle Virtual Directory, then add an entry for the Oracle Virtual Directory virtual root that is used as the searchbase for the Identity System, as outlined in the following.

Task overview: Creating a multiple-directories adapter

  1. Create an adapter for each data store you plan to include, as described in:

  2. Ensure that each directory server uses the same searchbase so the multiple-directories adapter will be the root.

  3. Complete activities in "Creating a Local Data Store Adapter".

  4. Complete activities in "Creating a Physical Node for the Virtual Root".

10.13.4.1 Creating a Local Data Store Adapter

The only time a local store adapter is needed with Oracle Access Manager is to create a virtual entry that is the parent of entries in multiple adapters so that it can appear as if a single contiguous tree exists.

For example, suppose you have two directories and want to create a directory tree with them:

Directory 1: ou=Marketing,o=Company

Directory 2: ou=Product,o=Company

In this case, to search from the o=Company level and have a search that covers both Directory 1 and Directory 2 you can use the local store adapter and create a single entry o=Company as its only entry. You would then have a full tree that looks like the following one:

o=Company: Oracle Access Manager can now search from here

/ \

ou=Marketing ou=Product

The local data store adapter is needed only when:

  • You want a unified searchbase for all individual data store adapters

  • All individual data store adapters have the same root searchbase

  • No duplicate entries exist in any data store (either remove the duplicate entries or filter them out)

The steps that follow are general. For more information, see your Oracle Virtual Directory documentation.

To create an adapter entry in Oracle Virtual Directory

  1. In Virtual Directory Manager, navigate to Adapters.

  2. Right-click Adapters.

  3. Select New, Local Store Adapter to display the Adapter configuration screen.

  4. Provide the adapter suffix (the common virtual root base for all the adapters).

  5. Save to the server, as usual.

  6. Proceed to "Creating a Physical Node for the Virtual Root".

10.13.4.2 Creating a Physical Node for the Virtual Root

After creating a local data store adapter entry for multiple directories, you need to create a physical node in the Oracle Virtual Directory directory because Identity System setup reads the configured node as the global searchbase. You create a physical node for the virtual root using the ldp utility, as usual.

For details about using the Virtual Directory Manager, see your Oracle Virtual Directory documentation.

To create a physical node for the virtual root

  1. Locate the ldp or ldapmodify utility.

  2. Add an entry for the Oracle Virtual Directory virtual root.

    For example, if your virtual root is o=Company, c=us, you add the entry:

    dn:o=Company,c=us

    Objectclass: organization

    o: Company

  3. Ensure that each directory server uses the same searchbase so the multiple-directories adapter will be the root.

  4. Proceed to "Customizing Adapters and Mapping Files".

10.14 Customizing Adapters and Mapping Files

The following discussions provide specifics related to use with Oracle Access Manager:

10.14.1 Customization Examples

As mentioned earlier, you can create your own templates from scratch or customize the samples provided by Oracle. The two types of samples that Oracle provides are:

Sample Adapter Templates: Sample templates for vendor-specific adapter files that you can use as the basis for individual adapters that connect native data stores to Oracle Virtual Directory.

Note:

Oracle-provided sample templates are specific to both a single data store and also to a specific user-defined schema. Your environment will vary.

Sample Mapping Files: Sample mapping files that you can use so that Oracle Virtual Directory can transform the schema (or database fields) used by native data stores to the logical schema used by the aggregated virtual directory made visible to Oracle Access Manager.

The following examples illustrate the type of modifications to Oracle-provided samples that you may want to make for your environment. The information contained in the examples, and the specific modifications made, are for illustration only. Your environment will vary.

10.14.2 Customized Mapping Script for Active Directory

The example in this discussion shows a customized version of the Active Directory directory server mapping file. The starting point for this example is the Oracle-provided sample template for the Active Directory directory server and a specific user-defined schema that is not included here.

Note:

The DN Conversion Toolkit is installed automatically as part of the Identity Server installation. See IdentityServer_install_dir\identity\oblix\tools\DataAnyWhere.

To see the types of mapping script changes made for Active Directory

  1. In your Virtual Directory Manager console, create a mapping file using the sample OblixADMapping file as a base (see "Creating Mapping Files for Adapters").

    IdentityServer_install_dir\identity\oblix\tools\DataAnyWhere\plugins\
    OracleAccessmanagerOViDTemplates\mapping_templates\OblixADMapping_mpy.xml
    
  2. Modify your mapping file for your environment and compare your customized version to the one for Active Directory shown under step 4.

  3. Save and deploy your mapping script, as usual.

  4. Save your mapping script as a template for future use:

    • Right click the new mapping template name, for example MyADMapping.

    • Select Save as template.

    <?xml version="1.0" encoding="UTF-8" ?> ...
    # Mapping template for: Custom Data sets
    #
    #   Target DS: AD  : - using static Auxiliary objectclass
    #   Target user objectclasses: User and group
    #   Target custom schema:
    #      AD_custom_schema_add.ldif
    #      AD.NET_custom_schema_add.ldif
    #    
    # Functions:
    #   a. maps AD user to inetOrgPerson
    #   b. maps AD group to groupofuniquenames
    #   c. filters out auxiliary class from objectclass in add/modify
    #   d. filter out AD system attributes
    #   e. set native flag useraccountcontrol when user is activated/deactivated
    #   f. set grouptype to 8
    #
    def inbound():
       #first rename the attributes
       renameAttribute({'uniqueMember':'member','owner':'managedby','uid':'samaccountname'}) 
       renameAttribute({'carlicense':'gencarlicense','departmentnumber':'gendepartmentnumber'})
       
       #temporary. 
       removeAttribute('nsaccountlock')
       
       #map object class names
       revalueAttribute('objectclass','groupofUniqueNames','group')
       revalueAttribute('objectClass','inetOrgPerson','user')
       
       #If static auxiliary class is used on AD, AD does not like to mention
       #the auxiliary classes in the objectclass attribute. If dynamic auxiliary
       #class is used on AD, comment these out.
       removeAttributeValue('objectclass','person')
       removeAttributeValue('objectclass','organizationalPerson')
       #removeAttributeValue('objectclass','inetOrgPerson')
       removeAttributeValue('objectclass','oblixOrgPerson')
       removeAttributeValue('objectclass','oblixpersonpwdpolicy')
       removeAttributeValue('objectclass','oblixadvancedgroup')
       removeAttributeValue('objectclass','oblixgroup')
       removeAttributeValue('objectclass','oblixAuxLocation')   
       #--- Remove custom data auxiliary object classes
       removeAttributeValue('objectclass','genAuxLocation')
       removeAttributeValue('objectclass','genAuxUserEquipment')
       removeAttributeValue('objectclass','genAuxUserNetwork')
       removeAttributeValue('objectclass','genAuxUserPersonal')
       removeAttributeValue('objectclass','genAuxUserSecurity')
       
       #If static auxiliary class is used in AD, remove the objectclass attribute 
       #during modify. AD does not like the mentioning of the auxiliary class.
       if operation == 'modify':
          removeAttribute('objectClass')
             
       #set the native flag useraccountcontrol based on the value of obuseraccountcontrol. 
       if haveAttribute('obuseraccountcontrol'):
          copyAttribute('obuseraccountcontrol','userAccountControl')
          #during modify, read the user entry first.
          if operation == 'modify':
             currentUser = getByName(name)
             val = int(`getAttributeValues(currentUser,'userAccountControl')[0]`)
          else:
             val = 546
          #Deactivate - set the 2nd bit
          revalueAttribute('userAccountControl','ObWfPendingActivate',`val | 0x0002`)
          revalueAttribute('userAccountControl','DEACTIVATED',`val | 0x0002`)
          revalueAttribute('userAccountControl','ObWfPendingDeactivate',`val | 0x0002`)
          #Activate - set the 2nd bit
          revalueAttribute('userAccountControl','ACTIVATED',`val & ~0x0002`)
          
       #when adding a group entry, add the grouptype and samaccountname. 
       #groupType is hard coded here. If multiple group types are to be supported,
       #configured grouptype in VDE for user to enter.
       if operation == 'add':
          if haveAttributeValue('objectClass','group'):
             addAttributeValue('groupType','8')
             if not haveAttribute('samaccountname'):
                copyAttribute('cn','samaccountname')
             #remove these attributes as they are not in AD group. It is better not
             #configure them in COREid if not used.
             #removeAttribute ('businessCategory')
             removeAttribute ('seeAlso')
             removeAttribute ('o')
          
          #if haveAttributeValue('objectClass','user'):
             #removeAttributeValue('objectclass','person')
             #removeAttributeValue('objectclass','organizationalPerson')
             #removeAttributeValue('objectclass','inetOrgPerson')
             
       if operation == 'modify':
          currentEntry = getByName(name)
          val = getAttributeValues(currentEntry,'objectclass')
          if DirectoryString('group') in val:
             #removeAttribute ('businessCategory')
             removeAttribute ('seeAlso')
             removeAttribute ('o')
                      
       #filter out obgroupcreator otherwise iplanet user cannot create ad group.
       if haveAttribute ('obgroupcreator'):
          removeAttribute ('obgroupcreator')
                               
       return
       
    def outbound():
       #first rename the attributes
       renameAttribute({'member':'uniqueMember','managedby':'owner','samaccountname':'uid'})
       renameAttribute({'gencarlicense':'carlicense','gendepartmentnumber':'departmentnumber'})   
       
       #map object class names
       revalueAttribute('objectClass','group','groupofUniqueNames')
       revalueAttribute('objectClass','user','inetOrgPerson')   
       
       #filter out AD system atrributes
       removeAttribute ('allowedAttributes')
       removeAttribute ('allowedAttributesEffective')
       removeAttribute ('allowedChildClasses')
       removeAttribute ('allowedChildClassesEffective')
       removeAttribute ('assistant')
       removeAttribute ('bridgeheadServerListBL')
       removeAttribute ('canonicalName')
       removeAttribute ('createTimeStamp')
       removeAttribute ('department')
       removeAttribute ('distinguishedName')
       removeAttribute ('dSASignature')
       removeAttribute ('dSCorePropagationData')
       removeAttribute ('extensionName')
       removeAttribute ('flags')
       removeAttribute ('fromEntry')
       removeAttribute ('frsComputerReferenceBL')
       removeAttribute ('fRSMemberReferenceBL')
       removeAttribute ('fSMORoleOwner')
       removeAttribute ('generationQualifier')
       removeAttribute ('instanceTyp')
       removeAttribute ('isCriticalSystemObject')
       removeAttribute ('isDeleted')
       removeAttribute ('isPrivilegeHolder')
       removeAttribute ('lastKnownParent')
       removeAttribute ('managedObjects')
       removeAttribute ('modifyTimeStamp')
       removeAttribute ('mS-DS-ConsistencyChildCount')
       removeAttribute ('mS-DS-ConsistencyGuid')
       removeAttribute ('name')
       removeAttribute ('netbootSCPBL')
       removeAttribute ('nonSecurityMemberBL')
       removeAttribute ('nTSecurityDescriptor')
       removeAttribute ('objectCategory')
       removeAttribute ('objectGUID')
       removeAttribute ('objectVersion')
       removeAttribute ('partialAttributeDeletionList')
       removeAttribute ('partialAttributeSet')
       removeAttribute ('possibleInferiors')
       removeAttribute ('queryPolicyBL')
       removeAttribute ('replPropertyMetaData')
       removeAttribute ('replUpToDateVector')
       removeAttribute ('revision')
       removeAttribute ('sDRightsEffective')
       removeAttribute ('serverReferenceBL')
       removeAttribute ('showInAdvancedViewOnly')
       removeAttribute ('siteObjectBL')
       removeAttribute ('subRefs')
       removeAttribute ('subSchemaSubEntry')
       removeAttribute ('systemFlags')
       removeAttribute ('uSNChanged')
       removeAttribute ('uSNCreated')
       removeAttribute ('uSNDSALastObjRemoved')
       removeAttribute ('USNIntersite')
       removeAttribute ('uSNLastObjRem')
       removeAttribute ('uSNSource')
       removeAttribute ('wbemPath')
       removeAttribute ('wellKnownObjects')
       removeAttribute ('whenChanged')
       removeAttribute ('whenCreated')
       removeAttribute ('instanceType')
       removeAttribute ('ms-sql-olapcube')
       removeAttribute ('ms-sql-database')
       removeAttribute ('ms-sql-server')
       removeAttribute ('ms-sql-sqlpublication')
       removeAttribute ('ms-sql-sqldatabase')
       removeAttribute ('ms-sql-sqlrepository')
       removeAttribute ('ms-sql-sqlserver')
       removeAttribute ('acpolity')
       removeAttribute ('acsubnet')
       removeAttribute ('msexchconfigurationcontainer')
       removeAttribute ('msmqconfiguration')
       removeAttribute ('msmqenterprisesettings')
       removeAttribute ('msmqmigrateduser')
       removeAttribute ('msmqqueue')
       removeAttribute ('msmqsettings')
       removeAttribute ('msmqsitelink')
       removeAttribute ('ntdsconnection')
       removeAttribute ('ntdsdsa')
       removeAttribute ('ntdsservice')
       removeAttribute ('ntdssitesettings')
       removeAttribute ('ntfrsmember')
       removeAttribute ('ntfrsreplicaset')
       removeAttribute ('ntfrssettings')
       removeAttribute ('ntfrssubscriber')
       removeAttribute ('ntfrssubscriptions')
       removeAttribute ('accountExpires')
       removeAttribute ('aCSPolicyName')
       removeAttribute ('adminCount')
       removeAttribute ('badPasswordTime')
       removeAttribute ('badPwdCount')
       removeAttribute ('codePage')
       removeAttribute ('controlAccessRights')
       removeAttribute ('dBCSPwd')
       removeAttribute ('defaultClassStore')
       removeAttribute ('desktopProfile')
       removeAttribute ('dynamicLDAPServer')
       removeAttribute ('groupMembershipSAM')
       removeAttribute ('groupPriority')
       removeAttribute ('groupsToIgnore')
       removeAttribute ('homeDirectory')
       removeAttribute ('homeDrive')
       removeAttribute ('lastLogoff')
       removeAttribute ('lastLogon')
       removeAttribute ('lmPwdHistory')
       removeAttribute ('localeID')
       removeAttribute ('lockoutTime')
       removeAttribute ('logonCount')
       removeAttribute ('logonHours')
       removeAttribute ('logonWorkstation')
       removeAttribute ('mSMQDigests')
       removeAttribute ('mSMQDigestsMig')
       removeAttribute ('mSMQSignCertificates')
       removeAttribute ('mSMQSignCertificatesMig')
       removeAttribute ('msNPAllowDialin')
       removeAttribute ('msNPCallingStationID')
       removeAttribute ('msNPSavedCallingStationID')
       removeAttribute ('msRADIUSCallbackNumber')
       removeAttribute ('msRADIUSFramedIPAddress')
       removeAttribute ('msRADIUSFramedRoute')
       removeAttribute ('msRADIUSServiceType')
       removeAttribute ('msRASSavedCallbackNumber')
       removeAttribute ('msRASSavedFramedIPAddress')
       removeAttribute ('msRASSavedFramedRoute')
       removeAttribute ('networkAddress')
       removeAttribute ('ntPwdHistory')
       removeAttribute ('operatorCount')
       removeAttribute ('otherLoginWorkstations')
       removeAttribute ('preferredOU')
       removeAttribute ('primaryGroupID')
       removeAttribute ('profilePath')
       removeAttribute ('pwdLastSet')
       removeAttribute ('scriptPath')
       removeAttribute ('servicePrincipalName')
       removeAttribute ('userAccountControl')
       removeAttribute ('userParameters')
       removeAttribute ('userSharedFolder')
       removeAttribute ('userSharedFolderOther')
       removeAttribute ('userSMIMECertificate')
       removeAttribute ('userWorkstations')
       removeAttribute ('masteredBy')
       removeAttribute ('maxStorage')
       removeAttribute ('userPrincipalName')
       removeAttribute ('objectSid')
       removeAttribute ('samaccounttype')
       removeAttribute ('badPasswordCount')
       removeAttribute ('sAMAccountControl')
       removeAttribute ('ADsPath')
       removeAttribute ('directReport')   
       
       return
    </ldap>
      </adapters>
    

10.14.2.1 Customized Mapping Script for Oracle Database

The example in this discussion shows the sample OblixDBMapping file as it looks after being customized for an Oracle database that uses the SQL server as a back end with a user-defined schema. The original sample is located in:

IdentityServer_install_dir\identity\oblix\tools\DataAnyWhere\plugins\
OracleAccessmanagerOViDTemplates\mapping_templates\OblixDBMapping_mpy.xml

Note:

The DN Conversion Toolkit is installed automatically as part of the Identity Server installation. See IdentityServer_install_dir\identity\oblix\tools\DataAnyWhere. Be sure to see the README file that comes with the toolkit.

You can compare the original Oracle-provided sample with the following one, to see the types of changes that are needed.

To see mapping script changes for the Oracle Database

  1. In your Virtual Directory Manager console, create a mapping file using the sample OblixDBMapping file as a base (see "Creating Mapping Files for Adapters").

  2. Modify the mapping file for your environment and include the work around shown in the example under "Unexpected Group Deletion Problem".

  3. Save and deploy your mapping script, as usual.

  4. Save your mapping script as a template for future use:

    • Right click the new mapping template name, for example MyOracleDBMapping.

    • Select Save as template.

  5. See also the customized adapter for the Oracle database next.

<?xml version="1.0" encoding="UTF-8"?>
<variables>
</variables>
<content>
def inbound():
   #These Oblix attributes are not being used. Remove them.
   removeAttribute('obver')
   removeAttribute('nsaccountlock')
   
   # More custom mapping
   # ....
   
   # If your user password is stored as character type, for example
   # NVARCHAR, CHAR, VARCHAR, etc, you need to map userPassword attribute
   # from binary syntax.
   mapSyntax('userPassword','IA5String')
   
   # This is a workaround ... for more information, see " "Unexpected Group Deletion Problem".
   # Need to prevent COREid from writing dummy user to backend database
   if haveAttributeValue('uniqueMember','cn=Dummy User'): 
      #removeAttributeValue('uniqueMember','cn=Dummy User')
      if operation != 'modify': 
         removeAttributeValue('uniqueMember','cn=Dummy User') 
      else: 
         change = removeAttribute('uniqueMember')[0] 
         change.values.remove(DistinguishedName('cn=Dummy User')) 
         addEntryChange(change) 
      
   #Filter out objectclass. Only mention the structure class during add.
   if operation == 'modify':
      removeAttribute('objectClass')
   if operation == 'add':
      newobj = ''
      if haveAttributeValue('objectClass','inetOrgPerson'):
         newobj = 'inetOrgPerson'
      if haveAttributeValue('objectClass','groupOfUniqueNames'):
         newobj = 'groupOfUniqueNames'
         removeAttribute ('businessCategory')
         removeAttribute ('seeAlso')
         removeAttribute ('o')
      if haveAttributeValue('objectClass','oblixlocation'):
         newobj = 'oblixlocation'
      if not newobj == '':
         removeAttribute('objectClass')
         addAttributeValue('objectClass',newobj)
      
   return
   
def outbound():
   #code here for handling outbound mapping
   # .....
   # This is a workaround to bug #18865
   if operation=='entry':
      # Add the following workaround for each multiple value DN attribute
      if haveAttribute('uniqueMember') and len(findFilters('uniqueMember')) > 0:
         addAttributeValue('uniqueMember','cn=Dummy User')
   return
</content>

10.14.2.2 Customized Adapter for Oracle Database

The following example shows a sample adapter after being customized for the Oracle Database. The Oracle-supplied sample template was used as a starting point.

<?xml version="1.0" encoding="UTF-8"?>
<adapters dirty="" version="0" 
  xmlns="http://www.octetstring.com/schemas/Adapters" xmlns:adapters="http:// www.w3.org/2001/XMLSchema-instance">
  <dataBase dirty="" id="DB Adapter Company Employees" version="0">
    <root>ou=Employees,o=MyCompanyDB,c=us</root>
    <active>true</active>
    <routing>
      <critical>true</critical>
      <priority>50</priority>
      <inclusionFilter/>
      <exclusionFilter/>
      <plugin/>
      <retrieve/>
      <store>
        <exclude>carlicense</exclude>
        <exclude>street</exclude>
        <exclude>employeeType</exclude>
      </store>
      <visible>Internal</visible>
      <levels>-1</levels>
      <bind>true</bind>
      <bind-adapters/>
      <views/>
      <dnpattern/>
    </routing>
    <pluginChains xmlns="http://www.octetstring.com/schemas/Plugins">
      <plugins>
        <plugin>
          <name>MyOracleDBMapping</name>
          <class>com.octetstring.VDE.chain.plugins.mapper.Mapper</class>
          <initParams>
            <param name="mapfile" value="MyOracleDBMapping.mpy"/>
          </initParams>
        </plugin>
        <plugin>
          <name>Dump after</name>
          <class>com.octetstring.VDE.chain.plugins.DumpTransactions.DumpTransactions</ class>
          <initParams>
            <param name="loglevel" value="info"/>
          </initParams>
        </plugin>
        <plugin>
          <name>Dump before</name>
          <class>com.octetstring.VDE.chain.plugins.DumpTransactions.DumpTransactions</ class>
          <initParams>
            <param name="loglevel" value="info"/>
          </initParams>
        </plugin>
      </plugins>
      <default>
        <plugin name="Dump before"/>
        <plugin name="MyOracleDBMapping"/>
        <plugin name="Dump after"/>
      </default>
    </pluginChains>
    <driver>oracle.jdbc.driver.OracleDriver</driver>
    <url>jdbc:oracle:thin:@127.0.0.1:1521:QA2</url>
    <user>CUSTDATA</user>
    <password>oblix</password>
    <ignoreObjectClassOnModify>false</ignoreObjectClassOnModify>
    <includeInheritedObjectClasses>true</includeInheritedObjectClasses>
    <maxConnections>10</maxConnections>
    <mapping>
      <joins/>
      <objectClass name="inetOrgPerson" rdn="cn">
        <attribute field="EMPLOYEE_ID" ldap="uid"
          table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
        <attribute field="NAME" ldap="cn" table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
        <attribute field="FIRST_NAME" ldap="givenName"
          table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
        <attribute field="LAST_NAME" ldap="sn"
          table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
        <attribute field="TITLE" ldap="title" table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
        <attribute field="USERPASSWORD" ldap="userPassword"
          table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
        <attribute field="PREFERREDLANGUAGE"
          ldap="PreferredLanguage" table="CUSTDATA.EMPLOYEES" type="CHAR"/>
        <attribute field="MAIL" ldap="mail" table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
        <attribute field="CHALLENGEPHRASE" ldap="ChallengePhrase"
          table="CUSTDATA.EMPLOYEES" type="CHAR"/>
        <attribute field="PHOTO" ldap="Photo"
          table="CUSTDATA.EMPLOYEES" type="BLOB"/>
        <attribute field="DESCRIPTION" ldap="Description"
          table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
        <attribute field="OBUSERACCOUNTCONTROL"
          ldap="OBUSERACCOUNTCONTROL" table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
        <attribute field="OBLOGINTRYCOUNT" ldap="oblogintrycount"
          table="CUSTDATA.EMPLOYEES" type="NUMERIC"/>
        <attribute field="OBPASSWORDCREATIONDATE"
          ldap="obpasswordcreationdate" table="CUSTDATA.EMPLOYEES" type="VARCHAR"/ >
        <attribute field="OBPASSWORDHISTORY" ldap="obpasswordhistory"
          table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
        <attribute field="OBPASSWORDCHANGEFLAG"
          ldap="obpasswordchangeflag" table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
        <attribute field="OBPASSWORDEXPMAIL" ldap="obpasswordexpmail"
          table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
        <attribute field="OBLOCKOUTTIME" ldap="oblockouttime"
          table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
        <attribute field="OBFIRSTLOGIN" ldap="obfirstlogin"
          table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
        <attribute field="OBRESPONSETRIES" ldap="obresponsetries"
          table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
        <attribute field="OBLASTLOGINATTEMPTDATE"
          ldap="oblastloginattemptdate" table="CUSTDATA.EMPLOYEES" type="VARCHAR"/ >
        <attribute field="OBLASTRESPONSEATTEMPTDATE"
          ldap="oblastresponseattemptdate" table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
        <attribute field="OBRESPONSETIMEOUT" ldap="obresponsetimeout"
          table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
        <attribute field="MANAGER_DN" ldap="Manager"
          table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
      </objectClass>
      <objectClass name="groupOfUniqueNames" rdn="cn">
        <attribute field="GROUP_NAME" ldap="cn"
          table="CUSTDATA.GROUPS" type="VARCHAR"/>
        <attribute field="OWNER_DN" ldap="owner"
          table="CUSTDATA.GROUPS" type="VARCHAR"/>
        <attribute field="MEMBER_DN" ldap="uniqueMember"
          table="CUSTDATA.GROUPS" type="VARCHAR"/>
        <attribute field="MAIL" ldap="mail" table="CUSTDATA.GROUPS" type="VARCHAR"/>
        <attribute field="OBGROUPCREATOR" ldap="obgroupcreator"
          table="CUSTDATA.GROUPS" type="VARCHAR"/>
        <attribute field="OBGROUPCREATIONDATE"
          ldap="obgroupcreationdate" table="CUSTDATA.GROUPS" type="VARCHAR"/>
        <attribute field="OBGROUPTYPE" ldap="obgrouptype"
          table="CUSTDATA.GROUPS" type="VARCHAR"/>
        <attribute field="OBSUBSCRIPTIONTYPES"
          ldap="obsubscriptiontypes" table="CUSTDATA.GROUPS" type="VARCHAR"/>
        <attribute field="OBVER" ldap="obver"
          table="CUSTDATA.GROUPS" type="VARCHAR"/>
        <attribute field="OBGROUPSUBSCRIPTIONTYPE"
          ldap="obgroupsubscriptiontype" table="CUSTDATA.GROUPS" type="VARCHAR"/>
        <attribute field="OBGROUPEXPANDEDDYNAMIC"
          ldap="obgroupexpandeddynamic" table="CUSTDATA.GROUPS" type="VARCHAR"/>
        <attribute field="OBGROUPPUREDYNAMIC" ldap="obgrouppuredynamic"
          table="CUSTDATA.GROUPS" type="VARCHAR"/>
        <attribute field="OBGROUPADMINISTRATOR"
          ldap="obgroupadministrator" table="CUSTDATA.GROUPS" type="VARCHAR"/>
        <attribute field="OBGROUPSUBSCRIBEMESSAGE"
          ldap="obgroupsubscribemessage" table="CUSTDATA.GROUPS" type="VARCHAR"/>
        <attribute field="OBGROUPUNSUBSCRIBEMESSAGE"
          ldap="obgroupunsubscribemessage" table="CUSTDATA.GROUPS" type="VARCHAR"/ >
        <attribute field="OBGROUPSUBSCRIPTIONFILTER"
          ldap="obgroupsubscriptionfilter" table="CUSTDATA.GROUPS" type="VARCHAR"/ >
        <attribute field="OBGROUPSUBSCRIBENOTIFICATION"
          ldap="obgroupsubscribenotification"
          table="CUSTDATA.GROUPS" type="VARCHAR"/>
        <attribute field="OBGROUPDYNAMICFILTER"
          ldap="obgroupdynamicfilter" table="CUSTDATA.GROUPS" type="VARCHAR"/>
        <attribute field="OBGROUPSIMPLIFIEDACCESSCONTROL"
          ldap="obgroupsimplifiedaccesscontrol "
          table="CUSTDATA.GROUPS" type="VARCHAR"/>
        <attribute field="GROUP_DESC" ldap="description"
          table="CUSTDATA.GROUPS" type="VARCHAR"/>
      </objectClass>
      <objectClass name="oblixlocation" rdn="obid">
        <attribute field="OBID" ldap="obid"
          table="CUSTDATA.OBLIXLOCATION" type="VARCHAR"/>
        <attribute field="OBLOCATIONNAME" ldap="oblocationname"
          table="CUSTDATA.OBLIXLOCATION" type="VARCHAR"/>
        <attribute field="OBLOCATIONTITLE" ldap="oblocationtitle"
          table="CUSTDATA.OBLIXLOCATION" type="VARCHAR"/>
        <attribute field="OBPARENTLOCATIONDN" ldap="obparentlocationdn"
          table="CUSTDATA.OBLIXLOCATION" type="VARCHAR"/>
        <attribute field="OBRECTANGLE" ldap="obrectangle"
          table="CUSTDATA.OBLIXLOCATION" type="VARCHAR"/>
        <attribute field="OBPHOTO" ldap="obphoto"
          table="CUSTDATA.OBLIXLOCATION" type="BLOB"/>
      </objectClass>
    </mapping>
  </dataBase>
</adapters>

10.14.3 Customizing General Settings for Oracle Access Manager

General adapter configuration and setup information is provided in the Oracle Virtual Directory/Virtual Directory Manager product manual. Once an adapter is created, default values are valid for most places. The following highlights are concerns with Oracle Access Manager:

  • DN attributes

  • Connection Information

DN Attributes:

  • DN attributes should be set with the attribute names that are in DN syntax.

    These DN attributes could exist in the customer schema, or could be introduced by Oracle Access Manager auxiliary classes. This tells Oracle Virtual Directory to store the values of these DNs in their native form instead of logical form.

  • The DN attributes are related to the object classes you are using:

    • For inetorgperson and groupofuniquenames, use

      uniquemember, manager, secretary, owner

    • For user and group, use

      member, memberOf, managedObjects, distinguishedname, objectcategory, manager, secretary, managedby

    • For Oracle Access Manager introduced auxiliary classes, use

      obgroupadministrator, obgroupcreator

    • In Pass-Through Mode, select

      Always

Connection Information: Set the following connection information in Oracle Virtual Directory based on the estimated workload:


Operation timeout
Max Pool Connection
Max Pool Wait
Max Pool Tries

To customize general settings for Oracle Access Manager

  1. Review the preceding information.

  2. In the Virtual Directory Manager Server Navigator window, select a server, then locate and select the name of the adapter.

  3. In the right pane, click the Routing tab.

  4. In General Settings, ensure that visibility is set to internal.

    For example:

    General Settings

    Visibility: Internal (for split profile adapters)

  5. Ensure that your adapter uses the settings discussed in this section.

  6. Click Finish.

  7. Right-click the adapter name in the Server Navigator window, then select Save to Server.

10.14.4 Customizing Routing Settings

If you are setting up an adapter that will be used by the Join View adapter, the visibility of the primary and secondary adapters should be set to "internal" so they are only invoked by the Join View adapter.

Once your adapters are working, you should observe the performance and evaluate the log to see if there is a pattern that an adapter is unnecessarily invoked by certain operation. If yes, you should try to use the following to filter block the unnecessary operation for that particular adapter. This step is very important to improve the overall performance:

  • Filter to include

  • Filter to exclude

  • DN matching

To customize routing settings

  1. Select the Adapter name in the Server Navigator window.

  2. Click the Routing tab in the right pane.

  3. Select the options for your environment:

    • Filter to include

    • Filter to exclude

    • DN matching

  4. Save to the server, as usual.

10.14.5 Editing an Adapter Plug-in to Refer to Your Mapping File

The Oracle-provided sample adapter templates include several plug-ins hooked in already, as discussed in "Oracle Access Manager-Oracle Virtual Directory Implementation Templates". There are two types of plug-ins:

  • Plug-in: A predefined plug-in that provides a parameter-based user interface for configuration.

  • Mapping Plug-in: A plug-in for a mapping script.

Keep the following in mind as you work:

  • If you use the Oracle-provided sample templates, you need only modify plug-ins.

  • If you do not use the Oracle-provided sample templates you need to add plug-ins to your adapter. For example:

As discussed earlier, Active Directory and ADAM adapters require two specific plug-ins, which are included in the Oracle-provided sample templates.

If you do not use the Oracle-provided sample templates, you need to add the SSL adapter you create as the Active Directory Password plug-in to the open-connection adapter you create and also add the Active Directory Ranged Attributes plug-in. Be sure to specify the same mapped namespace as the SSL adapter. See "Creating Adapters for LDAP Directories".

The following is an example only. For details about using Virtual Directory Manager, see your Oracle Virtual Directory documentation.

To edit an adapter plug-in to refer to your mapping file

  1. Complete activities in:

  2. In the Virtual Directory Manager Server Navigator window, select a project and server, then locate and select the name of the adapter to which you want to add or verify a plug-in.

  3. In the right pane, click the Plug-ins tab.

  4. On the Adapter Plug-ins screen:

    1. For ADAM or Active directory, you need the following plug-ins in the following order:

      Active Directory Ranged Attributes OblixADMapping (should be the mapping file you created earlier)

      Active Directory Password

    2. Arrange plug-ins for your environment using the up and down arrows.

    3. When the mapping file you created earlier is not listed:


      Select the current mapping, for example, OblixADMapping, then click the Edit button.

      In the Name field, change the name to your mapping file name (for example MyADMapping).

      In the Name field, change the name to your mapping file name (for example MyADMapping).
    4. When using non-Oracle templates for Active Directory or ADAM adapters, add the SSL adapter you created earlier to handle the password.


      Click the New Plug-in button.

      Click Select from Server, then select the Active Directory Password plug-in.

      Specify your SSL adapter name as the value of the parameter, for example: CustomAdamSSLAdapter.

      Select a parameter line, then click Edit.

      Specify your ADAM or Active Directory SSL adapter name as the value, for example: CustomAdamSSLAdapter
  5. Finish, save, and deploy as usual.

10.15 Completing Identity System Installation and Setup

Now that you have completed all other essential activities, described earlier, you are ready to complete Identity System installation and setup.

To complete Identity System installation and setup

  1. Complete all preceding tasks.

  2. WebPass: Install WebPass as described in Chapter 5, "Installing WebPass".

  3. Identity System Set Up: Set up the Identity System using the specifications that follow, then finish setup as you normally do:

    1. User Data Directory Server: Select Data Anywhere as the directory type.

    2. User Data ... Host: Specify the computer hosting Oracle Virtual Directory.

    3. User Data ... Port: Specify the Oracle Virtual Directory LDAP licensing port.

    4. Searchbase: Specify the Oracle Virtual Directory virtual DN, which may be any part of the virtual tree. For example: o=ovd_data,o=us

    5. Configuration Data Directory Server: Select the native directory you specified during Identity Server installation. Configuration (and policy data) must be stored outside the Oracle Virtual Directory virtual directory.

    6. Automatically Update Schema: Select Yes to automatically update the Oracle Virtual Directory schema with Oracle Access Manager auxiliary attributes.

    7. Specify Person and Group Object Classes: Select Yes to automatically update the Oracle Virtual Directory schema with Oracle Access Manager auxiliary attributes.

      User Object Class: Specify inetOrgPerson.

      Group Object Class: Specify groupOfUniqueNames.

    8. Automatically Configure Person and Group Object Classes: Choose Yes or No, as you normally do, to configure the Oracle Virtual Directory schema.

    Note:

    For details about manually configuring Person and Group object classes, see "Specifying Person and Group Object Classes".
  4. Policy Manager: Install and set up the Policy Manager as described in using specific details that follow, then complete setup as usual:

    1. Specify user data directory server details during setup, as described earlier.

    2. Specify the following during Policy Manager setup:


      Searchbase: Must be the same searchbase you specified during Identity System setup.

      Configuration DN: Must be the same configuration data DN you specified during Identity System setup.

      Policy Base: Must be the same policy data DN you specified during Access Manager installation.
  5. Access Server: Install the Access Server as described in Chapter 8, "Installing the Access Server" and:

    1. Provide information for the configuration data directory server.

    2. Identify where the Oracle Access Manager policy data is stored.

    3. Provide the following information when asked:


      Access Server ID
      Configuration DN Must be the same as specified earlier.
      Policy Base: Must be the same as specified earlier.
  6. WebGate: Install the WebGate as described in Chapter 9, "Installing the WebGate".

  7. Failover: Configure failover as described in:

10.16 Testing Your Implementation

To test your implementation, simply perform a Oracle Access Manager function that requires obtaining user data from a native directory.

If the operation works, the implementation is a success.

10.17 Reference Information

The following sections provide technical details related to several aspects of the Oracle Virtual Directory implementation for Oracle Access Manager.

10.17.1 Oracle Access Manager Auxiliary Attributes

Certain Oracle Access Manager functions require that specific attributes exist in the schema of both your top-level virtual directory and in the schema (or database equivalent) of each target data store.

  • You can extend your virtual directory schema automatically as follows:

    • When you install and set up the Identity System you have the opportunity to automatically (or manually) extend the Oracle Virtual Directory schema when you choose Data Anywhere as the user data directory server. For Identity System installation and setup, see Part II, "Identity System Installation and Setup".

    • After you upgrade an older installation to Oracle Access Manager 10g (10.1.4.3) you must manually extend the Oracle Virtual Directory schema using the ldapmodify utility as discussed in "Extending Directory Schemas".

  • You extend the target LDAP directory schemas by running the ldapmodify.exe utility with the appropriate ldif file, as described in "Extending Directory Schemas".

  • You simulate the object classes of your virtual directory by mapping all the user accounts in your primary database tables to the appropriate classes. See "About Adding Attributes to Target Database Tables".

  • You simulate the auxiliary user attributes that enable special Oracle Access Manager features by creating extra columns in your primary database tables. See "About Adding Attributes to Target Database Tables".

You use NVARCHAR with length of 1000 for all unbounded or user data, and VARCHAR with a length of 240 for all Oracle Access Manager-specific valued attributes.

Table 10-7 correlates the Oracle Access Manager auxiliary attributes required for specific User Manager functions.

Note:

The use of Oracle Virtual Directory does not support the Location object; therefore the User Location function is not supported for the User Manager application.

Table 10-7 Extended Attributes Required by User Manager Functions

User Manager Function Required Attributes Suggestions for Attribute Type and Length

User Add/Activate/Deactivate

Obuseraccountcontrol

VARCHAR (240)

Workflow Surrogate

oboutofofficeindicator

VARCHAR (240)

Password Change on Reset

obpasswordchangeflag

VARCHAR (240)

Password Number of login tries allowed

oblogintrycount

VARCHAR (240)

Password Validity period

obpasswordcreationdate

VARCHAR (240)

Password Expiry Notice Period

obpasswordcreationdate

VARCHAR (240)

Password Lockout Duration

oblockouttime

VARCHAR (240)

Password Login tries reset

oblastloginattemptdate

VARCHAR (240)

Password minimum age

obpasswordcreationdate

VARCHAR (240)

Password history

obpasswordhistory

password history support optional

NVARCHAR (1000)

Challenge Response

Customer attributes for Challenge phrase and response

NVARCHAR (1000)

Challenge Response Login tries reset

oblastresponseattemptdate

VARCHAR (240)

Challenge Response Lockout Duration

Obresponsetimeout

oblockouttime

VARCHAR (240)

VARCHAR (240)

Challenge Response Number of login tries allowed

obresponsetries

VARCHAR (240)


Table 10-8 correlates the Oracle Access Manager auxiliary attributes required for specific Group Manager functions.

Table 10-8 Extended Attributes Required by Group Manager Function

Group Manager Function Required Attributes Suggestions for Attribute Type and Length

Subscription type

obgroupsubscriptiontype

VARCHAR (240)

Group expansion

obgroupexpandeddynamic

VARCHAR (240)

Pure dynamic group

obgrouppuredynamic

VARCHAR (240)

Group administrators

obgroupadministrator

The virtual directory must support exactly one administrator for each group.

NPVARCHAR (1000)

Subscription message

obgroupsubscribemessage

NPVARCHAR (1000)

Unsubscription message

obgroupunsubscribemessage

NPVARCHAR (1000)

Subscription filters

obgroupsubscriptionfilter

NPVARCHAR (1000)

Subscription notification types

The virtual directory must support exactly one subscription for each group.

NPVARCHAR (1000)

Dynamic filters

obgroupsubscribenotification

Either subscription or unsubscription notification can be implemented, but both functions cannot be implemented simultaneously.

NPVARCHAR (1000)

Simplified access control

obgroupdynamicfilter

The virtual directory must support exactly one dynamic filter for each group

 

Group types

obgrouptype

The virtual directory must support exactly one group type for each group.

 

Selectable subscription types

obsubscriptiontypes

The virtual directory must support exactly one subscription type for each group. The possible subscription types are: Open, Close, Open with filter, and Controlled through workflow.

NPVARCHAR (1000)


10.17.2 About DN Conversion Toolkit

DN Conversion Toolkit is for use when you have an existing Oracle Access Manager installation and you want to integrate Oracle Virtual Directory. It will convert all the user data-related native DN suffixes in the configuration/policy tree to logical DN suffixes.

The DN Conversion Toolkit is installed automatically as part of the Identity Server installation for DataAnyWhere. Table 10-9 identifies the contents of the toolkit.

Table 10-9 Contents of the DN Conversion Toolkit for Oracle Access Manager

Directory Path from \identity\oblix File Components Description

\apps\common\bin\

globalparams.xml

A file that controls the scope of searches in the searchbase, among other things.

\lib

obxmlengine.dll (windows)

obxerces-c21.dll (windows)

msvci70.dll (windows)

msvci70d.dll (windows)

msvcr70.dll (windows)

msvcr70d.dll (windows)

libxmlengine.so (solaris)

libstdc++.so.5 (solaris)

libgcc_s.so.1 (solaris)

all required ldap sdk libraries for solaris

Libraries for Windows and Solaris.

\tools\DataAnyWhere

README

An overview of the content, runtime requirements, and simple usage examples for the components of the DN Conversion Toolkit.

\tools\DataAnyWhere

\conversion_tools

obmigrateDN.exe

Note: The LDIF that is created using obmigrateDN is stored in the following path:

C:\Program  Files\NetPoint\identity
\oblix\tools\migration_tools
\obmigratedata

obmigrateDNmsg.lst

The DNConversion binary and configuration file.

When you integrate Oracle Virtual Directory with existing Identity Server installations, obmigrateDN converts the user and group DN in the Oracle Access Manager configuration tree by internally calling obmigratedata for handling the Oracle Virtual Directory DN specific operations, which then refers to the ldapmodify executable.

\tools\DataAnywhere

\features\

\OracleAccessManagerOViDFeatures

feature.xml

 

\tools\DataAnyWhere

\OblixUserSchema

ADUserSchema.ldif

ADAuxSchema.ldif

ADAM_user_schema_add.ldif

ADAMAuxSchema.ldif f

iPlanet_user_schema_add.ldif

iPlanet_user_schema_delete.ldif

NDS_user_schema_add.ldif

NDS_user_schema_delete.ldif

v3.user.ibm_at.ldif

v3.user.ibm_oc.ldif

schema.oblix.xml

VDE_user_schema_add.ldif

VDE_user_schema_delete.ldif

Note: When possible, use the ldif files provided with your Identity Server installation.

schema.oblix.xml extends the Oracle Access Manager user schema into your virtual directory

VDE_user_schema_add.ldif extends the Oracle Virtual Directory schema with Oracle Access Manager attributes.

The other files extend the Oracle Access Manager user schema to the directory servers supported by the Oracle Access Manager-Oracle Virtual Directory implementation.

\tools\DataAnywhere

\plugins

\OracleAccessmanagerOViDTemplates

plugin.xml

 

\tools\DataAnywhere

\plugins

\OracleAccessmanagerOViDTemplates

\adapter_templates

OblixADAdapterUsingMapper_adapter_

template.xml

OblixADAdapterUsingScript_adapter_

template.xml

OblixADSSLAdapterUsingMapper_adapter_

template.xml

OblixADAMAdapterUsingMapper_adapter_

template.xml

OblixADAMAdapterUsingScript_adapter_

template.xml

OblixADAMSSLAdapterUsingMapper_a

dapter_template.xml

OblixSunOneAdapterUsingMapper_adapter_

template.xml

OblixSunOneAdapterUsingScript_adapter_

template.xml

For additional information, see

""Oracle Access Manager-Oracle Virtual Directory Implementation Templates".

Oracle Virtual Directory adapter templates for directory servers that require templates.

These can serve as a starting point for adapter creation.

Each includes basic settings, preconfigured data, plug-ins, and plug-in parameters.

See "Creating Data Store Adapters" .

\tools\DataAnywhere

\plugins

\OracleAccessmanagerOViDTemplates

\mapping_templates

OblixADAMMapping_mpy.xml

OblixADMapping_mpy.xml

OblixDBMapping_mpy.xml

OblixeDirectoryMapping_mpy.xml

OblixSunOneMapping_mpy.xml

Mapping script templates.

These sample mappings achieve the same configuration as those produced by the Object Class Mapper plug-in within the adapter template.

Mapping scripts are more flexible and can produce a fine level of adjustment not available through the plug-in.

See Creating Mapping Files for Adapters .

\tools

\ldap_tools

ldapmodify.exe

libobnspr4.dll

libobplc4.dll

libobplds4.dll

obnsldap32v50.dll

obnsldappr32v50.dll

obnsldapssl32v50.dll

obnss3.dll

obsoftokn3.dll

obsoftokn3.dll

The ldapmodify tool for use with the DN Conversion Toolkit.

Library files for Windows.

\tools

\migration_tools

\obmigratedata

at_DN_Conversion_map_osd_offline.lst

oc_DN_Conversion_map_osd_offline.lst

at_DN_Conversion_map_osd_online.lst

oc_DN_Conversion_map_osd_online.lst

obmigratedata.exe

obmigratedatamsg.lst

Files required by obmigratedata during runtime.

They have the objectclass and attribute details that need special handling.

This is similar to typical upgrades, except the DNConversion tool requires special handling in offline and online mode (as mentioned in the README file).


The conversion tool changes the native DNs in the configuration and policy branches of the Oracle Access Manager configuration and policy tree into logical (virtual) DNs that can be used by the virtual directory. The following tool is used:

IdentityServer_install_dir\identity\oblix\tools\DataAnyWhere\conversion_tools\

obmigrateDN.exe

10.17.2.1 Conditions

For the conversion to occur successfully, your Oracle Access Manager directory must meet the following two conditions:

  • Oracle Access Manager configuration and policy data resides in a native directory outside Oracle Virtual Directory.

  • Oracle Access Manager must see this configuration and policy data as belonging to a directory distinct from the Oracle Virtual Directory virtual directory, which contains all the user data seen by the product.

10.17.2.2 Requirements

  • A file containing the list of DN attributes to be converted

  • A mapping list you create, which correlates native DNs to logical DNs

  • Host name, Port number, Bind DN, Password, Directory type, Config DN, Oblix node, Install Dir, Native DN, Logical DN, Mode (online, offline, test)

10.17.2.3 Details

  • The tool only performs conversion when the domains differ in Oracle Virtual Directory. For example:

    If the DN on Oracle Access Manager is:

    o=company, c=us

    And the DN for iPlanet on Oracle Virtual Directory is:

    o=iPlanet, o=company,c=us

    Then the conversion takes place by referring to the mapping details given as input.

  • If only the attributes themselves differ, no mapping occurs. For example:

    cn=manisha, o=company, c= us

    cannot be mapped to Oracle Virtual Directory

    cn=manisha, o=iPlanet, o=company, c=us

  • You must run the tool at least once to convert each DN value.

    Note:

    If the configuration branch is not on the same directory server as the policy branch, you must run the tool twice for each DN value.
  • The tool does not support SSL.

  • Loading of the DSML version of the schema is not automated.

  • If you are upgrading an existing Oracle Access Manager installation, before re-running system setup you must manually remove the DBProfile branch from the directory being integrated.

    Note:

    Be sure to remove old DBProfiles manually before system setup; after setup the new DBProfiles are created automatically
  • The tool does not support Active Directory Services Interface (ADSI); you must use SSL instead, if you want a secure connection.

10.18 Oracle Access Manager-Oracle Virtual Directory Implementation Templates

Oracle provides adapter templates and script templates to assist you with quick setup of each directory and a database. When you configure an adapter, you can choose a template described later to complete schema mapping and special handling. Depending on the mapping criteria, these templates can be used as they are or they can provide a base for tailoring.

The provided templates are listed in Table 10-9, "Contents of the DN Conversion Toolkit for Oracle Access Manager" To fully understand what each template can achieve, see the following discussions:

For additional information, see "Creating Data Store Adapters" and "About DN Conversion Toolkit".

10.18.1 Templates for Active Directory

Oracle Access Manager provides three templates for use with Active Directory:

10.18.1.1 OblixADAdapterUsingMapper for Active Directory

This template defines an adapter that converts Active Directory user and group data to Oracle Virtual Directory inetorgperson and groupofuniquenames using the Object Mapper plug-in, which includes the following:

  1. A mechanism to set the DN attributes with all attributes that have DN syntax from inetorgperson, groupofuniquenames, and Oracle Access Manager user auxiliary classes to ensure these DNs are stored in the native DN format.

  2. A plug-in for Active Directory ranged attributes

    Active Directory returns the entry as xxx bytes chunks. This plug-in concatenates all the chunks into a single result entry.

  3. A plug-in for the ObjectClass Mapper, which provides a parameter-based user interface for object class and attribute mappings as described in Table 10-10 is also included.

    Table 10-10 OblixADAdapterUsingMapper, ObjectClass Mapper Plug-in Parameters

    Parameter Value Comment

    filterObjectClassOnModify

    true

    Assume Active Directory is configured as static auxiliary class.

    addAttribute-group

    samaccountname=%cn%

    If the object class is group, add attribute samaccountname and set the value to be equal to cn. This is because Active Directory requires samaccountname for group.

    addAttribute-group

    groupType=4

    If the object class is group, add attribute groupType and set the default value to 4. The value can be changed based on customer needs.

    mapAttribute

    uniqueMember= member

    Map Oracle Virtual Directory attribute uniqueMember to Active Directory attribute member.

    mapAttribute

    owner=managedBy

    Map Oracle Virtual Directory attribute owner to Active Directory attribute managedBy.

    mapAttribute

    uid=samaccountname

    Map Oracle Virtual Directory attribute uid to Active Directory attribute samaccountName.

    filterAttribute-group

    see Also,

    businessCategory

    If the object class is group, filter out these attributes. This is because Active Directory group does not support these three attributes.

    mapObjectClass

    groupofuniquenames=group

    Map Oracle Virtual Directory objectclass groupOfUniqueNames to Active Directory objectclass group.

    mapObjectClass

    inetorgperson=user

    Map Oracle Virtual Directory objectclass inetorgperson to Active Directory objectclass user.

    filterAttribute

    (list of system attributes)

    Filter out all the attributes in the list. Active Directory has a long list of system attributes that we don't want Oracle Access Manager to see.

    directoryType

    ActiveDirectory

    The directory type.

    activationAttribute

    obuseraccountcontrol

    The Oracle Access Manager attribute name that the Active Directory adapter should use to find for activation and deactivation. The Active Directory adapter then sets the native flag useraccountcontrol based on this.

    activationValue

    ACTIVATED

    The activation value of obuseraccountcontrol.

    deactivationValue

    DEACTIVATED

    ObWfPendingActivate

    ObWfPendingDeactivate

    The deactivation values of obuseraccountcontrol.

    filterAuxiliaryClass

    person,

    organizationalPerson

    OblixOrgPerson,

    oblixpersonpwdpolicy

    oblixadvancedgroup

    oblixgroup,

    oblixAuxLocation

    The auxiliary classes to be filtered out. This is based on the assumption that the Active Directory is configured as static auxiliary class.


  4. A plug-in for the Active Directory password, which requires the use of the SSL connection to set or change the user password using the parameters in Table 53, is included.

    Note:

    If the current adapter is using the open connection, this plug-in redirects password set/change to an adapter configured with an SSL connection.

    Table 10-11 Active Directory Password Plug-in Parameters and Values

    parameter value comment

    adapter

    AD SSL Adapter

    Redirect to the adapter defined in template OblixADSSLAdapterUsingMapper.

    mapPassword

    (not set. Default is true)

    Map password attribute from userPassword to unicodePwd.


10.18.1.2 OblixADAdapterUsingScript for Active Directory

This template (OblixADAdapterUsingScript) achieves exactly the same result as described earlier, and includes the same items described in 1, 2, and 4 of "OblixADAdapterUsingMapper for Active Directory".

The only difference when using the OblixADAdapterUsingScript is item 3, which in this case will be:

3. A plug-in script written in Python, defined in the mapping script template OblixADMapping,with the parameters in Table 10-10, "OblixADAdapterUsingMapper, ObjectClass Mapper Plug-in Parameters" acomplishes everything stated for the ObjectClass Mapper in item 3 of "OblixADAdapterUsingMapper for Active Directory".

10.18.1.3 OblixADSSLAdapterUsingMapper for Active Directory

This template defines an adapter that connects to the Active Directory through SSL. This is for the redirected adapter identified in item 4 of the preceding discussions. See:

10.18.2 Templates for ADAM

Three templates are provided for ADAM:

10.18.2.1 OblixADAMAdapterUsingMapper for ADAM

This template (OblixADAMAdapterUsingMapper) defines an adapter that converts ADAM user and group data to Oracle Virtual Directory inetorgperson and groupofuniquenames using the Object Mapper plug-in, which includes the following:

  1. A mechanism to set the DN attributes with all attributes that have DN syntax from inetorgperson, groupofuniquenames and Oracle Access Manager user auxiliary classes to ensure these DNs are stored in the native DN format.

  2. A plug-in for the Active Directory Ranged Attributes.

    ADAM also returns the entry as xxx bytes chunks. This plug-in concatenates all the chunks to a single-result entry.

  3. A plug-in for the ObjectClass Mapper, which provides a parameter-based user interface for object class and attribute mappings, as described in Table 10-12 is also included.

    Table 10-12 OblixADAMAdapterUsingMapper, ObjectClass Mapper Parameters and Values

    Parameter Value Comment

    filterObjectClassOnModify

    (not set. Default is false)

    Assume dynamic auxiliary class. Set it to true if ADAM is configured as static auxiliary class.

    addAttribute-group

    groupType=4

    If the object class is group, add attribute groupType and set the default value to 4. The value can be changed based on customer needs.

    mapAttribute

    uniqueMember=member

    Map Oracle Virtual Directory attribute uniqueMember to ADAM attribute member.

    mapAttribute

    owner=managedBy

    Map Oracle Virtual Directory attribute owner to ADAM attribute managedBy.

    mapAttribute

    uid=samaccountname

    Map Oracle Virtual Directory attribute uid to ADAM attribute samaccountName.

    filterAttribute-group

    seeAlso,businessCategory,o

    If the object class is group, filter out these attributes. This is because Active Directory group does not support these three attributes.

    mapObjectClass

    groupofuniquenames=group

    Map Oracle Virtual Directory objectclass groupOfUniqueNames to Active Directory objectclass group.

    mapObjectClass

    inetorgperson=user

    Map Oracle Virtual Directory objectclass inetorgperson to ADAM objectclass user.

    filterAttribute

    (list of system attributes)

    Filter out all the attributes in the list. ADAM has a long list of system attributes that we don't want Oracle Access Manager to see.

    directoryType

    ADAM

    The directory type.

    activationAttribute

    obuseraccountcontrol

    The Oracle Access Manager attribute name that the ADAM adapter should use to find for activation and deactivation. The ADAM adapter then sets the native flag useraccountcontrol based on this.

    activationValue

    ACTIVATED

    The activation value of obuseraccountcontrol.

    deactivationValue

    DEACTIVATED

    ObWfPendingActivate

    ObWfPendingDeactivate

    The deactivation values of obuseraccountcontrol

    filterAuxiliaryClass

    (not set)

    The auxiliary classes to be filtered out. This is based on the assumption that the ADAM is configured as dynamic auxiliary class. Give auxiliary class names for this parameter if ADAM is configured as static auxiliary class.


  4. A plug-in for the Active Directory password (ADAM requires the use of the SSL connection to set or change the user password using the parameters in Table 55), is included.

    Note:

    If the current adapter is using the open connection, this plug-in redirects password set/change to an adapter configured with an SSL connection .

Table 10-13 OblixADAMAdapterUsingMapper, ActiveDirectory Password Parameters

Parameter Value Comment

adapter

ADAM SSL Adapter

Redirect to the adapter defined in template OblixADAMSSLAdapterUsingMapper.

mapPassword

false

Do no map password attribute because ADAM uses attribute userPassword.


10.18.2.2 OblixADAMAdapterUsingScript for ADAM

This template (OblixADAMAdapterUsingScript) achieves exactly the same result as described earlier, and includes the same items described in 1, 2, and 4 of "OblixADAMAdapterUsingMapper for ADAM".

The only difference when using the OblixADAMAdapterUsingScript is item 3, which in this case will be:

3. A plug-in script written in Python, defined in template OblixADAMMapping, with the parameters in Table 10-12, "OblixADAMAdapterUsingMapper, ObjectClass Mapper Parameters and Values" accomplishes everything stated for the ObjectClass Mapper in item 3 in "OblixADAMSSLAdapterUsingMapper for ADAM".

10.18.2.3 OblixADAMSSLAdapterUsingMapper for ADAM

This template defines an adapter that connects to the ADAM directory through SSL. It is for the redirected adapter identified in item 4 of the preceding discussions. See:

10.18.3 Templates for Sun Directory Server

Two templates are provided for the Sun Directory Server:

10.18.3.1 OblixSunOneAdapterUsingMapper for SunOne

This template defines an adapter that converts Sun Directory Server (formerly SunOne) inetorgperson and groupofuniquenames to Oracle Virtual Directory inetorgperson and groupofuniquenames using the Object Mapper plug-in, which includes the following:

  1. A mechanism to set the DN attributes with all attributes that have DN syntax from inetorgperson, groupofuniquenames and Oracle Access Manager user auxiliary classes. This is to ensure these DNs are stored in the native DN format.

  2. A plug-in (ObjectClass Mapper), which provides a parameter based user interface for object class and attribute mappings as shown in Table 10-14 is also included.

Table 10-14 OblixSunOneAdapterUsingMapper, ObjectClass Mapper Parameters

Parameter Value Comment

directoryType

SunOne

The directory type.

activationAttribute

obuseraccountcontrol

The Oracle Access Manager attribute name that the SunOne adapter should use to find for activation and deactivation. The SunOne adapter then sets the native flag nsaccountlock based on this.

activationValue

ACTIVATED

The activation value of obuseraccountcontrol.

deactivationValue

DEACTIVATED,

ObWfPendingActivate,

ObWfPendingDeactivate

The deactivation values of obuseraccountcontrol.


10.18.3.2 OblixSunOneAdapterUsingScript for SunOne

This template (OblixSunOneAdapterUsingScript) achieves exactly the same result as described earlier, and includes the same item described in 1 of "OblixSunOneAdapterUsingMapper for SunOne".

The only difference when using the OblixSunOneAdapterUsingScript is item 2, which in this case will be:

2. A script written in Python, defined in template OblixSunOneMapping, with the parameters in Table 10-14, "OblixSunOneAdapterUsingMapper, ObjectClass Mapper Parameters". This table accomplishes everything stated for the ObjectClass Mapper in item 2 of "OblixSunOneAdapterUsingMapper for SunOne".

10.18.4 Templates for eDirectory

Two templates are provided for eDirectory:

10.18.4.1 OblixeDirectoryAdapterUsingMapper for eDirectory

This template defines an adapter that converts eDirectory inetorgperson and groupofuniquenames to Oracle Virtual Directory inetorgperson and groupofuniquenames using the Object Mapper plug-in, which includes the following:

  1. A mechanism to set the DN attributes with all attributes that have DN syntax from inetorgperson, groupofuniquenames and Oracle Access Manager user auxiliary classes. This is to ensure these DNs are stored in the native DN format.

  2. A plug-in (ObjectClass Mapper), which provides a parameter based user interface for object class and attribute mappings as shown in Table 10-15.

    Table 10-15 OblixeDirectoryAdapterUsingMapper for eDirectory

    Parameter Value Comment

    directoryType

    SunOne

    The directory type.

    activationAttribute

    obuseraccountcontrol

    The Oracle Access Manager attribute name that the eDirectory adapter should use to find for activation and deactivation. The eDirectory adapter then sets the native flag logindisabled.

    activationValue

    ACTIVATED

    The activation value of obuseraccountcontrol.

    deactivationValue

    DEACTIVATED, ObWfPendingActivate, ObWfPendingDeactivate

    The deactivation values of obuseraccountcontrol.


10.18.4.2 OblixeDirectoryAdapterUsingScript for eDirectory

This template (OblixeDirectoryAdapterUsingScript) achieves exactly the same result as stated earlier using OblixeDirectoryAdapterUsingMapper.

The only difference when using the OblixeDirectoryAdapterUsingScript is item 2, which in this case will be:

2. A script written in Python, defined in template OblixeDirectoryMapping, with the parameters in "OblixeDirectoryAdapterUsingMapper for eDirectory" accomplishes everything stated for the ObjectClass Mapper in item 2 of "OblixeDirectoryAdapterUsingMapper for eDirectory".

10.18.5 Database Template: OblixDBAdapterUsingScript

This template defines an adapter for a database. It does not include specific mapping but does call the OblixDBMapping script. The script, defined in the template OblixDBMapping, is written in Python and filters out the unnecessary mention of objectclass during the LDAP operation.

10.18.6 Schema Mapping Script Templates

The following mapping script templates are used by the adapter templates described earlier. These sample mappings achieve the same configuration as those produced by the Object Class Mapper plug-in within the adapter template. Mapping scripts are more flexible and can produce a fine level of adjustment not available through the plug-in

These mapping script templates provide a script alternative to accomplishing the schema mapping and special handling:

OblixADMapping: This mapping template performs the following:

  • Converts the Active Directory user and group to inetorgperson and groupofuniquenames, respectively

  • Sets the native flag when a user is activated or deactivated

  • Handles the static auxiliary objectclass

  • Sets grouptype to 4

  • Sets the useraccountname so that it is identical to cn.

OblixADAMMapping: This mapping template performs the following:

  • Converts Active Directory user and group to inetorgperson/groupofuniquenames, respectively

  • Sets the native flag when a user is activated or deactivated

  • Handles the static auxiliary object class

  • Sets grouptype to 4.

OblixeDirectoryMapping: Sets the native flag when a user is activated or deactivated

OblixSunOneMapping: Sets the native flag when a user is activated or deactivated

10.19 Tips

The following section provides miscellaneous information to guide your implementation with Oracle Virtual Directory. See also "Database Connectivity Tips".

Mapping DN: The mapped DN is the logical DN in Oracle Virtual Directory. However, there is no physical node for the mapped DN.

If the application (Identity System for example) needs to search the logical DN to detect that DNs existence or to retrieve its attributes, the entry needs to be added manually (using the ldp.exe utility, for example). For example, if the mapping DN is o=virtual company, the corresponding entry needs to be created through ldp.exe so that:

where organization is xxx, and virtual_company is xxx.

Reference DN in Configuration and Policy Data:The reference DN such as a UID used in policy data, is in its logical form. This means that it is stored as the DN of Oracle Virtual Directory, not the native directory. As a result, once the Oracle Virtual Directory namespace mapping is completed, that mapping should not be changed. Changing the namespace mapping will impact the reference DNs stored in the Oracle Access Manager configuration and policy data.

Schema Mapping: When mapping an attribute from logical to native, be sensitive to the syntax and whether it is multi-valued or single-valued.

Table 10-16 Oracle Virtual Directory to Database Mapping

LDAP Attribute Syntax MS SQL Data Type

1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary'

binary

1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String'

binary

1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean'

varchar

1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate'binary

binary

1.3.6.1.4.1.1466.115.121.1.9 DESC 'Certificate List'

binary

1.3.6.1.4.1.1466.115.121.1.10 DESC 'Certificate Pair'

binary

1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String'

varchar

1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN'

varchar

1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String'

varchar

1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number'

varchar

1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax'

tvarchar

1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time'

timestamp

1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String'

binary

1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER'

Numeric / int

1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG'

binary

1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address'

varchar

1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String'

varchar

1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID'

varchar

1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox'

varchar

1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address'

varchar

1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String'

varchar

1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number'

varchar

1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time'

timestamp


10.19.1 Database Connectivity Tips

Following are several database connectivity considerations:

  • Entry Name Formation

  • Multi-Table Writes

  • Multi-Value Attributes

  • Searches

  • Writes

  • Cascading Deletes

Entry Name Formation: All database fields that will be used as part of an entry's name (with the exception of the "base" part of the entry's name) must be contained in the rows that are mapped and returned to Oracle Virtual Directory through the database adapter.

For example, if a hierarchy is being created in which user objects will contain both a common name (cn) and an organizational unit (ou) in their name (cn=Joe User,ou=Marketing), both cn and ou must be part of the entry being created.

In pure LDAP, the ou attribute would not be required as it is part of the parent entry. Since databases are not hierarchical, this is the only reasonable way to support this functionality without requiring considerable new metadata be created and managed to define hierarchy.

Multi-Table Writes: Multi-table writes are not possible directly to a single database adapter. This is not a design limitation of Oracle Virtual Directory, but rather a practical database limitation. For example, views in most databases cannot be updated directly when they present multiple tables.

Oracle Virtual Directory gets around this limitation through the use of its own Join View implementation. By creating multiple database adapters (perhaps one for each table) and defining the relationship between them, it is possible to have Oracle Virtual Directory manage writes to entries that are constructed through multiple tables. Further information on creating Join Views can be found in Oracle Virtual Directory Product Manual.

Multi-Value Attributes: Databases typically do not allow for multiple values for a single field within a single table row. There are exceptions where an array type is supported, but these data types tend to be relatively limited. Some users put multiple values into a row by separating data (such as account flags) within a field using delimiters such as commas or pipes (|).

Traditional database design states that fields that would have multiple values should be normalized into an additional table. Databases that are part of a data warehouse may take a different approach in which every permutation of every field is placed into a denormalized table.

Oracle Virtual Directory can generally support either model. Oracle suggests using the "permutations in a denormalized table" method only as an absolute last resort. The normalized, secondary table approach probably won't return consistently accurate results for Oracle Access Manager searches.

For more information about multi-valued attributes, see:

Searches: Searches are supported to normalized or denormalized tables without doing anything other than configuring a database-level join as necessary.

The one consideration that should be kept in mind on searches is that due to the most popular use cases, the current design of the database adapter is that if a multi-value attribute is searched to only return the value that matched the search as part of the entry. This facilitates high performance large group searches. Oracle expects to make this configurable (to support doing a subselect to return all values) in a future version. An additional search can be performed in mapping to retrieve all attributes in the mean time.

Writes: Writes to normalized tables must be performed through a Join View that splits out attributes to each table based on the design of the database. This is required since while there are general guidelines for database design, every customer's database is different.

Most customers that use existing and important tables also use stored procedures as part of controlling updates to those tables. These are akin to API calls and are proprietary to each database in the way they are constructed and called, while the calls themselves are proprietary to the customer. Oracle supports stored procedures through the use of its plug-in system.

Oracle Virtual Directory can manage direct writes to denormalized tables that have each value for the field that will be used in the entry associated with the field used as the RDN for the entry. Add, Modify, and Delete are all supported.

Within the modify operation, it should be noted that the way the modify->replace works is to remove existing attribute values and add new ones. This translates into a SQL delete and a SQL insert rather than a complex set of SQL inserts, updates, and deletes. The potential issue here is with customers that have normalized tables in which the insert or delete will trigger other actions within the database. In such a plugin would need to be constructed that would handle the modify->replace operation.

Most customers do not run into this as they either are not using direct SQL access for changes, are using multiple values only for read, or are only using modify->add and modify->remove directly. For example, customers solving issues with big groups are storing groups in databases through Oracle Virtual Directory. Most group membership changes are adds and removes rather than replaces.

Cascading Deletes: Of the issues mentions in writes, the biggest thing to watch for in an existing database where Oracle Virtual Directory will be handling database writes directly is a customer database's use of cascading deletes. With cascading deletes it is possible that a modify->replace as documented in the previous section would trigger deletes outside of the table being directly affected.

This said, if the trigger is based on the normalized table, this is not an issue as when modifying the single-valued normalized table Oracle Virtual Directory will do an SQL update rather than a delete-insert sequence. This should eliminate the issue mentioned.

If in doubt about what will happen with a particular customer situation with a potentially dangerous setup involving Cascading Deletes, contact Oracle. You can also turn up the debug level on Oracle Virtual Directory and point it to a test database to see the SQL being generated by Oracle Virtual Directory for any sequence of LDAP operations.

10.20 Troubleshooting Implementations with Oracle Virtual Directory

For information, see "Issues with Oracle Virtual Directory Implementations".