| Oracle® Access Manager Configuration Manager Installation and Administration Guide 10g (10.1.4.0.1) Part Number B32392-01 |
|
|
View PDF |
| Oracle® Access Manager Configuration Manager Installation and Administration Guide 10g (10.1.4.0.1) Part Number B32392-01 |
|
|
View PDF |
Oracle Access Manager Configuration Manager is a standalone application that is available as part of the Oracle Access Manager 10g (10.1.4.0.1) release. It is a Java application that automates the process of managing and migrating Oracle Access Manager 10g (10.1.4.0.1), or Oracle COREid Release 7.0.4, configuration data. This chapter introduces this new application and includes the following topics:
Your enterprise may include more than one installation (deployment) of either Oracle Access Manager 10g (10.1.4.0.1) or Oracle COREid Release 7.0.4. Like many customers, you may have several software deployments in various settings:
Development deployments are ideally a sandbox-type setting where the dependency on the overall deployment is minimal
QA deployments are typically a smaller shared deployment used for testing
Pre-production deployments are typically a shared deployment used for testing with a wider audience
Production deployments are fully shared and available within your enterprise on a daily basis
Deployments in your enterprise may have different designations. You may even have multiple deployments of the same type. Oracle Access Manager Configuration Manager uses automated processing to streamline your data migration tasks, help eliminate errors, and reduce system downtime to a minimum. Using Configuration Manager, you easily migrate configuration data (push a copy) from one Oracle Access Manager 10g (10.1.4.0.1), or Oracle COREid Release 7.0.4, deployment to another. For example, if you defined and tested a new password policy in your QA deployment you can propagate the new policy to a production deployment of the same release.
For more information, see "About the Oracle Access Manager Configuration Manager".
Configuration management refers to the life-cycle management of specific Oracle Access Manager 10g (10.1.4.0.1), or Oracle COREid Release 7.0.4, configuration data. Oracle Access Manager Configuration Manager enables you to automate the task of pushing configuration data changes from a specified directory in one deployment (the source) to an associated directory in another deployment of the same release (the target).
Configuration data refers to product-specific Oracle Access Manager, or Oracle COREid, configuration and access policy data. This data is stored in the oblix tree of a Lightweight Directory Access Protocol (LDAP) directory within each Oracle Access Manager, or Oracle COREid, deployment. Oracle Access Manager migrates only LDAP data, not files, by connecting to the LDAP directory in each deployment. With Oracle Access Manager Configuration Manager, the term environment refers to an LDAP directory.
Note:
The process of pushing selected data to another environment is sometimes known as horizontal data migration, because you are copying configuration data changes for a specific release only.When you migrate data using Oracle Access Manager Configuration Manager (also known as the Configuration Manager), you select entries in the source configuration tree to be copied to the associated target. With Configuration Manager, you may migrate only data between only the following source and target environments:
A designated Oracle Access Manager 10g (10.1.4.0.1) source to an associated Oracle Access Manager 10g (10.1.4.0.1) target
A designated Oracle COREid Release 7.0.4 source to an associated Oracle COREid Release 7.0.4 target
As an example, suppose you have defined and tested a new password policy in an Oracle COREid Release 7.0.4 development deployment. Using Oracle Access Manager Configuration Manager, you can propagate the new password policy from this Oracle COREid Release 7.0.4 development deployment to your Oracle COREid Release 7.0.4 QA deployment as shown in Figure 1-1.
Figure 1-1 Migrating Data using Oracle Access Manager Configuration Manager
The deployments depicted in Figure 1-1 are only an example. Your deployments may differ. For example, your deployments may be Oracle Access Manager 10g (10.1.4.0.1). For more information, see Deployment Support and Interoperability.
Process overview: Preparing for and migrating data
Repository: After adding details about the repository to Oracle Access Manager Configuration Manager, information related to migration activities is stored in the repository.
For more information, see "Configuration Manager Repository".
Environments: After adding details about two different environments for Oracle COREid Release 7.0.4, environments, or two different environments for Oracle Access Manager 10g (10.1.4.0.1), environment information is stored in the repository and you can form an association to use for migration activities.
For more information, see "Environments" and Deployment Support and Interoperability.
Association: After defining an association, Configuration Manager connects to:
The source (the environment that contains the configuration data you want to migrate)
The target (the environment that you want to receive the configuration data changes)
For more information, see "Associations".
Migration: Using Configuration Manager, you perform the automated migration processes outlined here:
Create a snapshot of the target environment
Select entries in the configuration tree of the source environment
Compare details of selected entries between the source and target
Customize entries on the target, if desired,
Preview the data to confirm this is what you want to migrate
Migrate the selected configuration data
The selected configuration data is copied from the source to the target. A transaction record is created in the repository that includes details about the migrated data.
For more information, see "Supported Data Types for Migration", "Physical Entries and Logical Objects", "Migration Transactions", and "About Snapshots".
Note:
You may export selected configuration data to a Lightweight Directory Interchange Format (LDIF) file. LDIF files are ASCII format files that you can use to exchange and synchronize data between Lightweight Directory Access Protocol (LDAP) serves using an external tool. For more information, see "LDIF Files for Offline Data Importation".After migrating data, Oracle recommends that you test the changes in the live target deployment to validate that things are operating as expected.
For more information about validating migration success, see Chapter 4.
Oracle Access Manager Configuration Manager requires its own data store known as a repository. The Configuration Manager supports only the Oracle Database Server as its repository. The repository must be independent of any Oracle Access Manager 10g (10.1.4.0.1), or Oracle COREid Release 7.0.4, deployment.
The Oracle Database that you install for use as the Oracle Access Manager Configuration Manager repository is where migration information is stored. Table 1-1 lists the information that is stored in the repository.
For more information, see "Installing and Setting up the Oracle Database Repository".
The term environment refers to an LDAP directory server that is installed and configured to operate within a specific Oracle Access Manager 10g (10.1.4.0.1), or Oracle COREid Release 7.0.4, deployment. The LDAP directory (environment) includes Oracle Access Manager, or Oracle COREid, configuration data in the oblix tree.
Oracle Access Manager Configuration Manager does not require that the DIT (DN suffix) structure on each environment be exactly the same. For example, you may have one environment with a configuration DN of o=Oblix, ou=Config, ou=Dev, o=Root1 and another with a configuration DN of o=Oblix, ou=Config, ou=QA, o=Root2.
You add details about individual environments to Oracle Access Manager Configuration Manager. Environment details are stored in the Configuration Manager repository and are available within the Configuration Manager. For more information, see "Adding and Managing Environment Details in the Configuration Manager".
After you have defined at least two environments within the Configuration Manager, you can form an association as described next.
An association consists of a pair of environments that you define within the Configuration Manager. Each association includes a designated source environment from which data objects are selected, and a designated target to which the data is copied. For example, you may want to define associations to push data:
From Development to QA
From QA to Pre-production
From Pre-production to Production
You may form an association between any two defined environments in the Configuration Manager. Both environments in an association are presumed to belong to deployments of the same release (either 10g (10.1.4.0.1) or release 7.0.4.
Any environment may be designated as either a source or a target. A single environment may be a source in one association as well as a target in another association.
You may define and use multiple associations. However, only one association is used during each migration operation. All the history related to a specific migration between the designated source and target belongs to the association.
For more information, see "Creating and Managing Associations".
Caution:
You may not use the Oracle Access Manager Configuration Manager to migrate data from a release 7.0.4 deployment to a release 10g (10.1.4.0.1) deployment nor vice versa. For more information, see Deployment Support and InteroperabilityThis discussion outlines the types of configuration and runtime data that you can migrate using Oracle Access Manager Configuration Manager.
Oracle Access Manager migrates only LDAP data for migration, not files. This data includes product-specific Oracle Access Manager, or Oracle COREid, configuration and access policy data like res-ops for access control policies, DB profiles and instances, and other items. The data is stored in the oblix tree of an LDAP directory (environment) within your Oracle Access Manager, or Oracle COREid, deployments.
Table 1-2 outlines the configuration data types that you can migrate, for both the Identity and Access System.
Table 1-2 Configuration Data Types Supported for Migration
| Identity System Configuration Data | Access System Configuration Data |
|---|---|
|
Table 1-3 identifies the types of runtime data that are supported for migration using the Oracle Access Manager Configuration Manager.
Table 1-3 Runtime Data Types Supported for Migration
As stated earlier, Oracle Access Manager Configuration Manager migrates only data in the LDAP directory of a deployment. It does not migrate any files.
Table 1-4 outlines the types of data that are not supported for migration using Oracle Access Manager Configuration Manager. To migrate data listed in Table 1-4, you may have (or know of) other code management products that can be used for check in, check out, and deployment. Migrating data types in Table 1-4 is outside the scope of this manual.
In an LDAP directory, information is stored as physical entities. Many times, a group of physical entities are logically related so tightly that an individual physical entity may not make much sense with respect to the application. For example, workflow participants do not make much sense as a single entity. Such physical entities can be grouped together in Oracle Access Manager Configuration Manager under the name of one object known as a logical object. A logical object may also be a one-to-one mapping with a physical entity.
One logical object may have dependencies on other logical objects. For example, in Oracle Access Manager, and Oracle COREid, Workflow Definition consists of configuration information that can be considered as a logical object with dependencies on workflow steps which in turn have dependencies on workflow participants as shown in Figure 1-2. If you choose to migrate the workflow step to the target deployment, the Configuration Manager identifies dependent objects such as participants, mail notifees, and the like. A dependent logical object is a child logical object that does not exist as a separate logical object on its own. As an example, a workflow target subflow is a dependent logical object that is not a logical object on its own.
Figure 1-2 Logical Objects and Dependents
When migrating data using the Oracle Access Manager Configuration Manager, all dependent logical objects are migrated along with respective parent logical objects. You cannot clear a dependent logical object.
A related logical object is a child that exists as a separate logical object on its own. For example a lost password policy is both a logical object and a child (related) logical object of a password policy. The password policy is a logical object. Figure 1-3 illustrates a workflow definition. Here, a sub flow is both a logical object and a related logical object. When migrating data using the Oracle Access Manager Configuration Manager, you can either select or clear a related logical object for migration.
Figure 1-3 Logical Objects and Related Logical Objects
Using Oracle Access Manager Configuration Manager, you can select any number of displayed logical object types, or specific logical objects, to migrate, as described in "About Selecting Logical Objects to Migrate". After selecting logical object types or specific objects, and before migrating the data, you have the opportunity to compare differences between the source and target in a navigation tree within the Configuration Manager as shown in Figure 1-4.
Figure 1-4 Logical Objects Presented in a Navigation Tree Structure
On the Compare and Migrate page, you may expand items to see details about attributes and dependents. Symbols beside logical object names indicate differences between the source and target before migration. For more information about the symbols, see "About Comparing Data Before Migration".
Some attributes include system- or environment-specific settings such as hostnames, IP addresses, and domain names. You may apply changes to customize settings and attributes before, during, or after migration:
After creating an association and before migrating data, you may create an optional transformation rule for the directory association that will be applied automatically during migration. On the Customize page, you can view logical objects as they are before the rule is applied (Before Migration) and as they are after the rule is applied (After Migration). For more information, see "Adding and Managing Optional Transformation Rules".
During the migration, on the Customize page, you may select and customize attributes manually. After manual edits, you can view the logical object as it is before the change is applied (Before Migration) and as it will be after the change is applied (After Migration). For more information, see "About Customizing the Target".
After migration, you can make attribute value changes using either of the following methods:
On the Rollback Transaction, Customize page, you may edit attributes manually much as you did if you changed attributes manually during migration. For more information, see "Rolling Back Changes Made During a Specific Transaction".
Directly in the target Oracle Access Manager 10g (10.1.4.0.1), or Oracle COREid Release 7.0.4, deployment as described in the book introduced in "Related Documents".
For more information, see "About Customizing the Target".
A transaction record is created automatically each time you migrate configuration data from a source to a target using Oracle Access Manager Configuration Manager. Each transaction record includes the entire group of logical objects and dependents, and selected related objects, that were migrated from the source to the target in an association.
A list of all transactions is available within Oracle Access Manager Configuration Manager. You may choose a particular transaction and view the changes made during that migration. You may also select a transaction and roll back the changes to return the logical objects on the target to the state they were in before that particular migration.
For more information about transactions and rolling back changes, see Chapter 5.
In addition to using automated Oracle Access Manager Configuration Manager processes to migrate configuration data, you may use the Configuration Manager to export selected configuration data that you want to migrate to an LDIF file. You may want to export transaction data to an LDIF file.
Exporting to an LDIF file enables you to use Oracle Access Manager Configuration Manager with directory environments that do not provide write access to the target directory, for example, a production deployment. You may choose to use the Export to LDIF option when:
You want to modify the LDIF file, then import the data using an external tool.You want to upload the LDIF file at a scheduled time (off peak time, for example).You want to get the approval from a manager before changing the target environment.
This method employs Oracle Access Manager Configuration Manager to add environments and to form and select an association. You then select, compare, and customize logical object types on the target, and export the selections to an LDIF file using the Configuration Manager. Oracle recommends that you take a snapshot of the target environment using the Configuration Manager just before importing the data. You import the data using an external tool; this topic is outside the scope of this manual.
If you import data using the LDIF file and external tool, a transaction record is not created because the actual migration occurs offline (outside of the Oracle Access Manager Configuration Manager).
Note:
You cannot use the Configuration Manager to import data from an LDIF file. External tools are outside the scope of this manual.For more information, see "About Exporting Data to an LDIF File (Optional)".
This discussion provides a very high level introduction to the sequence of tasks that you must perform when migrating data. This is only a starting point in your planning. Figure 1-5 outlines the migration tasks that you and your team will complete when pushing configuration data changes from one Oracle Access Manager 10g (10.1.4.0.1), or Oracle COREid Release 7.0.4, deployment to another.
Task overview: Migrating data with Oracle Access Manager Configuration Manager
Review this chapter to learn about the Oracle Access Manager Configuration Manager, as well as:
Use Chapter 2 as a guide as you install and setup required components before data migration, which includes:
Installing and Setting up the Oracle Database Repository for use with the Configuration Manager
Assigning Configuration Manager Administrator and User Roles
Use Chapter 3 as a guide to prepare and migrate configuration data from one a source environment to a target environment in a Oracle Access Manager 10g (10.1.4.0.1), or Oracle COREid Release 7.0.4, deployment. This includes:
Notifying Other Administrators before and after migration
Adding and Managing Environment Details in the Configuration Manager: Create, view, modify and delete directory details for existing Oracle Access Manager 10g (10.1.4.0.1), or Oracle COREid Release 7.0.4, deployments
Creating and Managing Associations: Create new associations, view settings, enable/disable, and delete associations
Adding and Managing Optional Transformation Rules that will be applied to all logical attributes in the directory association during migration
Making and Managing Snapshots to make a backup copy of the oblix tree of the target before migrating data; you may restore the snapshot to return the target to its condition before migration, if needed
Migrating Data from the Source to the Target: selecting an association; selecting logical object types; comparing selected objects on the source with those on the target; customizing selected objects; previewing changes; adding a transaction description; and migrating data
During the operation you may choose to export data to an LDIF file, then import the data offline using an external tool. For more information, see About Exporting Data to an LDIF File (Optional).
Restarting Servers After Migration is required to flush their caches and update the servers with the latest configuration data from the target environment
Use Chapter 4 for Validating Migration Success. It includes suggestions about validating migrated data in a live target deployment. Oracle recommends that you create your own tests to validate data changes in both the source deployment before migrating data and the target deployment after migrating data.
Review Troubleshooting Configuration Manager Issues in Appendix B if needed.
Planning and preparation are key components of any successful data migration strategy. This section discusses the planning considerations and inventory items that you and your team need to create to ensure your success.
Planning and Notifications: Before starting any data migration using Oracle Access Manager Configuration Manager, Oracle strongly recommends that you and your team become familiar with all topics suggested in Figure 1-5 and the task overview that follows the figure. Oracle recommends that you schedule specific migration windows and that you notify other administrators about planned activities in any deployment for which they are responsible.
Deployment Inventories: Before starting any migration activities, Oracle recommends that you take inventory of your existing Oracle Access Manager 10g (10.1.4.0.1), or Oracle COREid Release 7.0.4, deployments. Table 1-5 identifies the details that you need to collect for each deployment that will be involved in the migration. Details can be gathered from existing installation (or upgrade) worksheets and records or you can gather fresh information directly from the deployment.
Table 1-5 Details Needed for Each Installed Deployment
| Component | Specific Details Needed |
|---|---|
|
Worksheet for Directory Instances Directory server type, version, patch level DNS hostname, port, Directory server security mode Root bind DN and password for Oracle Access Manager or Oracle COREid Searchbase (and Disjoint Searchbase, if applicable) Master/replica configuration details, if applicable Directory Server Profile names Type of data stored:User, Configuration, Policy data |
|
|
DIT and Object Definitions, Workflows, and Access Control Lists |
Worksheet for DIT and Object Definition Details |
|
Worksheet for Directory Server Profiles |
|
|
Worksheet for Database Instance Profiles |
|
|
Worksheet for Identity Servers |
|
|
Policy Manager Details (also known as the Access Manager in Oracle COREid Release 7.0.4) |
Worksheet for Policy Manager (release 7.0.4 Access Manager) Instances |
|
Identity Servers |
|
|
Workflows and Access Control Lists |
|
Test Development: To help ensure data correctness before migration, Oracle recommends that you develop specific tests that evaluate configuration data changes in the source deployment. After migration, you can use these same tests in the target deployment to ensure that everything is working as expected.
For more information about planning, see "Planning for Configuration Manager Deployment".
The Oracle Access Manager Configuration Manager provides several ways to help you back up data before migration, and restore the backup after migration if needed:
Oracle Access Manager Configuration Manager provides a SnapShot function that enables you to create a backup copy of the entire oblix tree in the selected environment (LDAP directory). A snapshot includes only the logical objects in the configuration tree. For example, workflow definitions are part of the snapshot but workflow instances are not.
If you are migrating data using the Configuration Manager, Oracle recommends that you create a snapshot of the target just before migration. If you export configuration data to an LDIF file, Oracle recommends that you create a snapshot of the target just before importing the LDIF file.
Using the Configuration Manager, you may restore a snapshot to revert all changes that were made since the snapshot was captured. This restores the logical objects in the directory to the state they were in at the time the snapshot was made.
When you restore a snapshot, the entire oblix tree is restored to the directory. As a result of the restoration, all changes to the entire oblix tree are revoked. Revoked changes include both migration changes made using the Configuration Manager, as well as changes made outside the Configuration Manager.
Caution:
Restoring a snapshot reverts all changes made after the snapshot was taken. snapshot restoration returns the directory to the state it was in at the time the snapshot was made.When you restore the content of a snapshot, a new snapshot is created automatically to capture the current state of the environment. Using the new snapshot, you may undo the restoration.
For more information, see "Making and Managing Snapshots".
Oracle Access Manager Configuration Manager crates a transaction record each time you migrate data. Each transaction record includes the entire group of logical objects, related objects, and dependents that were migrated.
Note:
No transaction record is created during data migration using an external tool. For example, no transaction record is created if you export data to an LDIF file using the Configuration Manager, then import the data using an external tool.You may view details of transaction records for a selected association. In addition, you may choose a particular transaction record and:
View the changes made during a specific migration transaction.
Roll back the changes made during the selected transaction.
Rolling back a transaction, reverts only the changes made to logical objects during the migration transaction. During the rollback operation, a new transaction record is created.
For more information about transactions and rolling back changes, see Chapter 5.
You change configuration data for Oracle Access Manager 10g (10.1.4.0.1), or Oracle COREid Release 7.0.4, directly using the Identity (COREid) or Access System Consoles. Your changes are automatically written to the directory directly from the deployment. In this case, appropriate entries in the server cache are flushed immediately and the server is updated with the latest configuration data. To migrate those changes to another deployment without the Configuration Manager, you repeat the manual process.
Note:
Manually altering data in one deployment to match data in another deployment is a time consuming and error-prone task.Using Oracle Access Manager Configuration Manager, you can push changes for supported logical object types from the source environment to an associated target. The automated processes are performed fairly quickly and eliminate the unintentional introduction of errors.
Oracle Access Manager Configuration Manager migrates a single logical object in approximately 100 milliseconds. Your total actual migration time will depend on the number of logical objects selected for migration, as well as number of related objects and dependents. For example, it may take more time to migrate one policy domain with many host identifiers and authentication schemes than to migrate 50 or more password policies.
Note:
The speed and capacity of computers hosting critical components (source and target environments, OC4J, Oracle Database repository, and Oracle Access Manager Configuration Manager) will also impact the speed and duration of migration operations.After migrating data using the Configuration Manager, you must manually restart Identity Servers and Access Servers in the target deployment to flush their caches and update the servers with the latest configuration data from the target directory. For more information, see "Restarting Servers After Migration".
You may use Configuration Manager functions to roll back a transaction. A rollback takes as long to complete as the original migration. If needed, you may restore an environment snapshot to revert all changes made to the oblix tree. The time it takes to restore a snapshot depends on the amount of configuration data that was backed up. For more information about managing transactions and rolling back changes, see Chapter 5.
When you migrate data, all selected entries in the oblix configuration tree are copied from the source environment to the target in an association. Using Oracle Access Manager Configuration Manager you may migrate data only between:
A designated source environment for Oracle Access Manager 10g (10.1.4.0.1) to an associated target within an Oracle Access Manager 10g (10.1.4.0.1) deployment
For more information about Oracle Access Manager 10g (10.1.4.0.1), see the manuals for this release as described in "Related Documents".
From a designated source environment for Oracle COREid Release 7.0.4 to an associated target within an Oracle COREid Release 7.0.4 deployment
For more information about Oracle COREid Release 7.0.4, see the manuals for the release as described in "Related Documents".
Note:
You do not need to upgrade Oracle COREid Release 7.0.4 to Oracle Access Manager 10g (10.1.4.0.1). Also, Oracle Access Manager Configuration Manager does not perform an upgrade.As shown in Table 1-6, both deployments represented in an association are presumed to be of the same release (either both 10g (10.1.4.0.1) or both release 7.0.4). Oracle Access Manager Configuration Manager operates equally with homogeneous deployments for either release.
Table 1-6 Oracle Access Manager Configuration Manager Interoperability Matrix
Caution:
You may not use the Oracle Access Manager Configuration Manager to migrate data from a release 7.0.4 deployment to a release 10g (10.1.4.0.1) deployment nor vice versa.Oracle Access Manager Configuration Manager is a Java Application hosted on OC4J. One or more instances of the Oracle Access Manager Configuration Manager deployed as an OC4J application will interoperate with the following additional components:
Oracle Containers for J2EE (OC4J): One instance of the OC4J in either a standalone configuration or installed as a managed component of Oracle Application Server
Multiple environments to use as a source and target must be installed independently for Oracle Access Manager 10g (10.1.4.0.1) deployments
Multiple environments to use as a source and target must be installed independently for Oracle COREid Release 7.0.4 deployments
For information about deploying and setting up the Configuration Manager, see Chapter 2.
