| Oracle® Access Manager Configuration Manager Installation and Administration Guide 10g (10.1.4.2.0) Part Number E10358-01 |
|
|
View PDF |
| Oracle® Access Manager Configuration Manager Installation and Administration Guide 10g (10.1.4.2.0) Part Number E10358-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. Oracle Access Manager Configuration Manager 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:
It is possible to have 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 might have several software deployments in various settings, including:
A development deployment is ideally a sandbox-type setting where the dependency on the overall deployment is minimal
A QA deployment is typically a smaller shared deployment used for testing
A pre-production deployment is typically a shared deployment used for testing with a wider audience
A production deployments is fully shared and available within your enterprise on a daily basis
You can even have multiple deployments of the same type. Deployments in your enterprise can have the same designations as those listed, or different designations.
Oracle Access Manager Configuration Manager provides automated processing to streamline your data migration tasks, help eliminate errors, and reduce system downtime to a minimum. Using the Configuration Manager, you can easily migrate configuration data (push a copy) from one deployment to another. For example if you have defined and tested a new password policy in your QA deployment, you can propagate the new policy to a production deployment.
The term 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).
The term 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 the Configuration Manager, you can migrate data only as follows:
From 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
From 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 can differ. For example, your deployments can 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 you add 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 you add details about two different environments for Oracle COREid Release 7.0.4, 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 you define an association, the 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 the 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 that 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.
See Also:
You can choose to export selected configuration data to a Lightweight Directory Interchange Format (LDIF) file. An LDIF file is an ASCII format file that you can use to exchange and synchronize data between Lightweight Directory Access Protocol (LDAP) servers 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 repository must be independent of any Oracle Access Manager 10g (10.1.4.0.1), or Oracle COREid Release 7.0.4, deployment.
Only Oracle Database Server 10g Release 2 (10.2) is supported for the Oracle Access Manager Configuration Manager repository. Table 1-1 lists the information that is stored in the repository.
Table 1-1 Configuration Manager Data Stored in the Repository
| Data in the Repository |
|---|
|
Transformation rules |
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 might have configuration data in one environment with a distinguished name (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 environment to which the data is copied. For example, you can define associations to push data:
From dvelopment to QA
From QA to preproduction
From preproduction to production
You can 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 can be designated as either a source or a target. A single environment can be a source in one association as well as a target in another association.
You can define and use multiple associations. However, only one association is used during each migration operation. All migration history related to a specific transaction between the designated source and target belongs to the association.
For more information, see "Creating and Managing Associations".
Caution:
You cannot use 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 Interoperability".This topic outlines the types of configuration and run-time 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 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 the Identity System. For an overview of the Identity System, see the Oracle Access Manager Introduction.
Table 1-2 Identity System Configuration Data Types Supported for Migration
| Migrate using Oracle Access Manager Configuration Manager | Migrate using Oracle Access Manager Configuration Manager |
|---|---|
|
Table 1-3 identifies the types of Identity System run-time data that you can migrate using Oracle Access Manager Configuration Manager.
Table 1-3 Identity System Run-time Data Supported for Migration
| Migrate using Oracle Access Manager Configuration Manager | Migrate using Oracle Access Manager Configuration Manager |
|---|---|
|
|
|
Searchbases |
Table 1-4 identifies the types of Access System configuration data that you can migrate using Oracle Access Manager Configuration Manager. For more information about the Access System, see the Oracle Access Manager Introduction guide.
Table 1-4 Access System Configuration Data Types Supported for Migration
| Migrate using Oracle Access Manager Configuration Manager | Migrate using Oracle Access Manager Configuration Manager |
|---|---|
|
Master auditing policy |
|
Access System Run-time Data: Policy domains are the only Access System run-time data that you can migrate using Oracle Access Manager Configuration Manager. For more information about data types that can be migrated, see "Physical Entries and Logical Objects". For specific details about each of the objects and attributes, see the Oracle Access Manager Schema Description guide "About Preparing Customized Data for Manual Migration".
As stated earlier, Oracle Access Manager Configuration Manager migrates only configuration and access policy data in the LDAP directory of an Oracle Access Manager deployment. It does not migrate any files. Also, Oracle Access Manager Configuration Manager does not automate data migration for all types of data. Customized data must be migrated from a source deployment to a target deployment manually.
Table 1-5 outlines the types of Identity System data that are not supported for migration using Oracle Access Manager Configuration Manager.
Table 1-6 outlines the Access System data types that are not supported for migration using Oracle Access Manager Configuration Manager.
Manually migrating the data types in Table 1-5 and Table 1-6 is outside the scope of this manual. You can use other code management products that you might know about to check in, check out, and deploy the types of data in Table 1-5 and Table 1-6.
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 because the participants depend on the overall workflow configuration. 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 can also be a one-to-one mapping with a physical entity.
One logical object can have dependencies on other logical objects. For example, in Oracle Access Manager (and Oracle COREid), Workflow Configuration 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 (those who are notified by mail after the completion of a step), 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 Oracle Access Manager Configuration Manager, all dependent logical objects are migrated along with respective parent logical objects. You cannot prevent the migration of 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 subflow is both a logical object and a related logical object. When migrating data using Oracle Access Manager Configuration Manager, you can either select a related logical object for migration or prevent the related logical object from being migrated by clearing the selection.
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 can 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 can expand items to see details about any attribute and dependent. 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-specific settings and environment-specific settings such as host names, IP addresses, and domain names. You can apply changes to customize settings and attributes before, during, or after migration:
After creating an association and before migrating data, you can 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 can 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 can 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 books 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 transaction records is available within Oracle Access Manager Configuration Manager. You can choose a particular transaction and view the changes made during that migration. You can 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.
Note:
No transaction record is created if you choose to export data to an LDIF file.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 automatically, you can use the Configuration Manager to export selected configuration data to an LDIF file. Later, you can use the LDIF file to import the selected configuration data using an external tool.
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 can 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 (an 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 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 section 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 Oracle Access Manager Configuration Manager, as well as:
Use Chapter 2 as a guide as you install and set up required components before data migration. These preparation steps include:
Use Chapter 3 as a guide to prepare and migrate configuration data from one source environment to a target environment in an Oracle Access Manager 10g (10.1.4.0.1), or Oracle COREid Release 7.0.4, deployment. This includes the following activities and topics:
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 can restore the snapshot to return the target to its condition before migration, if needed
Learning About Oracle Access Manager Data
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 can 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:
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.
When migrating Oracle Access Manager configuration data from one LDAP directory environment to another, be sure to note the following types of differences between the two:
Differences in the sharing of configuration information between the Access System and the Identity System
Differences in who is given administrative privileges, including the overall Master Administrator, Delegated Access Administrator, and Delegated Identity Administrator
Names and implementation details of the Identity Servers
Names and implementation details of the WebPass instances
Names and implementation details of the Access Servers
Names and implementation details of the WebGates, including changing what Access Server the WebGate points to
Definitions for Host Identifiers and ipValidationExceptions
Definitions for authentication schemes, including Challenge Redirect parameters.
Definitions for authorization schemes
Definitions for policy domains, including all redirect URLs defined in authentication and authorization actions
Directory details such as computer name and port number
Users and groups involved in policy domains
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. You can gather details from existing installation (or upgrade) worksheets and records or you can gather fresh information directly from the deployment. For more information, see "Taking Inventory and Testing Operations in Existing Deployments".
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.
Before you deploy Oracle Access Manager Configuration Manager, be sure to review the planning details in "Planning for Configuration Manager Deployment".
Oracle Access Manager Configuration Manager provides several ways to help you back up data before migration, and restore the backup after migration if needed. The following topics provide this information:
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 can restore a snapshot to revert all changes that were made since the snapshot was captured. This revoke changes to the logical objects in the directory and return these logical objects 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 revokes all changes made after the snapshot was taken. Snapshot restoration returns the entire
oblix tree in 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 can undo the restoration.
For more information, see "Making and Managing Snapshots".
Oracle Access Manager Configuration Manager creates 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 can view details of transaction records for a selected association. In addition, you can 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 revokes 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 managing transactions and rolling back changes, see Chapter 5.
You change configuration data directly for Oracle Access Manager 10g (10.1.4.0.1), or Oracle COREid Release 7.0.4, using the Identity (COREid) System Console or Access System Console. 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 using the Identity (COREid) System Console or Access System Console. These activities are outside the scope of this manual and are described in the administration guides for your deployment as outlined in "Related Documents".
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 migration time will depend on the number of logical objects selected for migration, as well as the 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 affect 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 can use the Configuration Manager functions to roll back a transaction. A rollback takes as long to complete as the original migration. If needed, you can restore an environment snapshot to revoke all changes made to the oblix tree. However, the changes you will revoke include those made during the migration as well as any made after the migration. 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 can 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:
Oracle Access Manager Configuration Manager performs automatic checks at strategic points to prohibit you from making a mistake.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-7, 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 well with homogeneous deployments for either release.
Table 1-7 Oracle Access Manager Configuration Manager Interoperability Matrix
Caution:
You cannot use 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 provides checks to ensure this does not occur.Oracle Access Manager Configuration Manager is a Java application hosted on Oracle Containers for J2EE (OC4J). Oracle Access Manager Configuration Manager deployed as an OC4J application, on one or more instances of the OC4J in either a standalone configuration or as a managed component of Oracle Application Server, will interoperate with the following additional components:
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.
