A Transitioning OAM 11g from a Test to a Production Environment

This chapter describes how to move Oracle Access Manager 11g data from a test environment to a production environment. You can also use this approach for testing and rolling out upgrades.

This chapter includes the following topics:

Prerequisites
Introduction to Deployment Scenarios and Data Types
Introduction to Methods and Tools
Planning an OAM 11g Move from Test to Production
Backup and Recovery Strategies
Moving OAM 11g From Test to Production

Prerequisites

Install and configure target components, as described in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management

Introduction to Deployment Scenarios and Data Types

It is fairly common to develop and test applications in a smaller restricted environment, and then eventually roll out the test applications (and, optionally, test data) to a larger shared environment. You can use the information in this chapter to move Oracle Access Manager 11g data from a test deployment (the source) to a production deployment (the target). You can also use this approach for testing and rolling out upgrades.

Table A-1 describes the types of deployments that customers might have within their enterprise. Deployment types might be named differently in your enterprise.

Table A-1 Deployment Types

Deployment Type	Description
Development Deployment	Ideally a sandbox-type setting where the dependency on the overall deployment is minimal
QA Deployment	Typically a smaller shared deployment used for testing
Pre-production Deployment	Typically a shared deployment used for testing with a wider audience
Production Deployment	Fully shared and available within the enterprise on a daily basis

Within each deployment, OAM 11g configuration data is stored in files while OAM 11g policy data is stored in a database.

On the policy side, each application domain is constructed using the following shared components:

Authentication Module
Authentication Scheme (containing one authentication module)
Host-Identifiers
Resources

On the system configuration side, agents host resources or partner applications that must be protected. An agent can be an OAM Agent (WebGate or AccessGate) or OSSO agent. Each agent must be registered with OAM 11g to protect hosted resources. Registering an agent:

Defines the agent and its specific configuration parameters
Creates an application domain for the specified resources
Creates an authentication policy with the default authentication scheme for the partner application
Creates an authorization policy for the specified resources
Generates the symmetric key for the partner application

Transitioning policy and partner information from the test (source) environment to the production (target) environment is accomplished with MBean registered on the AdminServer of the OAM Server. WLST commands fetch the partner and policy information from the source server and applies this on the production server.

The following overview presents the general scope of tasks that must be performed to move OAM 11g policy and partner information from a test (source) environment to a production (target) environment.

Task overview: Moving OAM 11g from test to production

Perform planning activities, as described in Planning an OAM 11g Move from Test to Production.
Export data such as users and groups, the identity and policy stores, and credentials from the source and then Import data to the target as described in Moving OAM 11g From Test to Production.

To reuse source data in only the target system, you can re-register the agents within the target deployment after importing the source data to the target
Modify any information that is specific to the new environment such as host name or ports.
Deploy applications.

Introduction to Methods and Tools

This section provides a high-level overview of data migration approaches, methods, and tools for OAM 11g:

About New versus Existing Production Environments
About Methods to Move from Test to Production
About the WebLogic Scripting Tool Commands
About Conflict Resolution
About Building a Dependency Tree for Each Application Domain

About New versus Existing Production Environments

Oracle Access Manager and Oracle Identity Manager are components of Oracle Fusion Middleware 11g. All existing access technologies in the Oracle Identity Management stack converge in Oracle Access Manager 11g. The differences in the scope of tasks required to move an entire Identity Management environment from a test source to a production target are described in Table A-2.

Table A-2 Differences when Transferring Data to New versus Existing Target Environments

New Target Environment	Existing Target Environment
In this scenario you want to move existing Identity Management components in a test environment to a new environment that does not yet exist. This requires the following tasks. Task 8 is the subject of this chapter. All other tasks are described in the Oracle Fusion Middleware Administrator's Guide	In this scenario you want to move one or more applications from the source to a target in an existing environment, while retaining the source security-related configuration. This requires migrating application-specific data and incremental changes from the source to the target. Task 2 is the subject of this chapter. All other tasks are described in the Oracle Fusion Middleware Administrator's Guide
Copy the Database to a New Production Environment Move Oracle Internet Directory to a New Production Environment Move Oracle Virtual Directory to a New Production Environment Move Oracle Directory Integration Platform to a New Production System Move Oracle Identity Federation to a New Production Environment Move Oracle Identity Manager to a New Production Environment Move Oracle Identity Navigator to a New Production Environment Move Oracle Access Manager 11g to a New Production Environment, as described in "Moving OAM 11g From Test to Production" Move Oracle Access Manager 10g to a New Production Environment Move Oracle Adaptive Access Manager to a New Production Environment Move Audit Policies to a New Production Environment Move Oracle Platform Security to a New Production Environment Move Oracle Web Services Manager to a New Production Environment	Move Oracle Internet Directory to an Existing Production Environment Move Oracle Access Manager 11g to a New Production Environment, as described in "Moving OAM 11g From Test to Production" Move Oracle Access Manager 10g to a New Production Environment Move Oracle Adaptive Access Manager to a New Production Environment Move Oracle Identity Manager to a New Production Environment Move Oracle Identity Navigator to a New Production Environment Move Oracle Platform Security to a New Production Environment Move Oracle Web Services Manager to a New Production Environment

New Target Environment

Existing Target Environment

In this scenario you want to move existing Identity Management components in a test environment to a new environment that does not yet exist.

This requires the following tasks. Task 8 is the subject of this chapter. All other tasks are described in the Oracle Fusion Middleware Administrator's Guide

In this scenario you want to move one or more applications from the source to a target in an existing environment, while retaining the source security-related configuration.

This requires migrating application-specific data and incremental changes from the source to the target. Task 2 is the subject of this chapter. All other tasks are described in the Oracle Fusion Middleware Administrator's Guide

Copy the Database to a New Production Environment
Move Oracle Internet Directory to a New Production Environment
Move Oracle Virtual Directory to a New Production Environment
Move Oracle Directory Integration Platform to a New Production System
Move Oracle Identity Federation to a New Production Environment
Move Oracle Identity Manager to a New Production Environment
Move Oracle Identity Navigator to a New Production Environment
Move Oracle Access Manager 11g to a New Production Environment, as described in "Moving OAM 11g From Test to Production"
Move Oracle Access Manager 10g to a New Production Environment
Move Oracle Adaptive Access Manager to a New Production Environment
Move Audit Policies to a New Production Environment
Move Oracle Platform Security to a New Production Environment
Move Oracle Web Services Manager to a New Production Environment

Move Oracle Internet Directory to an Existing Production Environment
Move Oracle Access Manager 11g to a New Production Environment, as described in "Moving OAM 11g From Test to Production"
Move Oracle Access Manager 10g to a New Production Environment
Move Oracle Adaptive Access Manager to a New Production Environment
Move Oracle Identity Manager to a New Production Environment
Move Oracle Identity Navigator to a New Production Environment
Move Oracle Platform Security to a New Production Environment
Move Oracle Web Services Manager to a New Production Environment

About Methods to Move from Test to Production

When moving Oracle Access Manager 11g from test to production, you can use one of the methods described in:

Table A-3, "Full Replication"
Table A-4, "Golden Template"
Table A-5, "Delta-Replication"
Table A-6, "Application Re-association"

Table A-3 describes full replication. By performing manual and automated tasks, you can replicate the OAM test source setup to an OAM production target.

Table A-3 Full Replication

Requirements	Automated and Manual Tasks	Not Required or Processed
The user store is already configured for the target OAM Server. The same clients and partners that communicate with the source OAM Server also communicate with the target OAM Server.	The following WLST commands are used: Export: Replicate and export the source application domains and policies. Import: Imports the source configuration and conflict resolution profile to the target Replaces the schema in the target with the schema in the source. Removes application domains in the target system that are not present in the source. An Administrator must also: Replace the schema in the target system with the schema in the source system.	Partners Clients OAM Servers

Requirements

Automated and Manual Tasks

Not Required or Processed

The user store is already configured for the target OAM Server.
The same clients and partners that communicate with the source OAM Server also communicate with the target OAM Server.

The following WLST commands are used:

Export: Replicate and export the source application domains and policies.
Import:

Imports the source configuration and conflict resolution profile to the target

Replaces the schema in the target with the schema in the source.

Removes application domains in the target system that are not present in the source.

An Administrator must also:

Replace the schema in the target system with the schema in the source system.

Partners
Clients
OAM Servers

Table A-4 describes golden template processing. By performing manual and automated tasks, you can create a target OAM Server with the identical topology as the source.

Table A-4 Golden Template

Requirements	Manual and Automated Tasks	Not Required or Processed
The same clients and partners that communicate with the source also communicate with the target OAM Server. The target must be a clean environment; all configuration in the target is overwritten by the source.	The Administrator must manually: Set up the required target topology to match the existing source topology. Replace the schema in the target system with the schema in the source system, if there are changes in the user configuration. Register target OAM Servers using either the OAM Administration Console or remote registration commands for OAM. Use t2pClient commands to replicate the source on the target.	Any change in user configuration is an independent, manual step.
	The WLST commands clone the existing OAM test setup and: Configures the target user identity store to match the source user identity store (configureUserStore) Replicates and migrates partner data from the source to the target Exports the source configuration Imports the source configuration with a conflict resolution profile
If a source WebGate is configured with a list of primary/secondary OAM Server hosts and OAP ports that are not included in the target (production) environment, after the transition you might see empty fields or a subset of source primary or secondary servers listed in the target environment.	After running WLST commands, above, the Administrator must also edit target (production) agent registration pages to match actual hosts and ports:

Requirements

Manual and Automated Tasks

Not Required or Processed

The same clients and partners that communicate with the source also communicate with the target OAM Server.
The target must be a clean environment; all configuration in the target is overwritten by the source.

The Administrator must manually:

Set up the required target topology to match the existing source topology.
Replace the schema in the target system with the schema in the source system, if there are changes in the user configuration.
Register target OAM Servers using either the OAM Administration Console or remote registration commands for OAM.
Use t2pClient commands to replicate the source on the target.

Any change in user configuration is an independent, manual step.

The WLST commands clone the existing OAM test setup and:

Configures the target user identity store to match the source user identity store (configureUserStore)
Replicates and migrates partner data from the source to the target
Exports the source configuration
Imports the source configuration with a conflict resolution profile

If a source WebGate is configured with a list of primary/secondary OAM Server hosts and OAP ports that are not included in the target (production) environment, after the transition you might see empty fields or a subset of source primary or secondary servers listed in the target environment.

After running WLST commands, above, the Administrator must also edit target (production) agent registration pages to match actual hosts and ports:

Table A-5 describes requirements and processing for incremental transfer (known as delta replication). All incremental changes in the source are transferred to the target. Selective transfer is not required.

Table A-5 Delta-Replication

Requirements	Tasks	Not Required or Processed
The source OAM Server contains the "truth". Any conflicts between the source and the target are resolved based on the source.	The Administrator runs the WLST command with the "MigrateAll" flag set to "false" to move only the changes from the source to the target system.	Policy configuration that has not changed is not processed.

Table A-6 outlines requirements and tasks. By performing manual and automated tasks, you can re-associate source client applications to the target environment.

Table A-6 Application Re-association

Requirements	Automated and Manual Tasks	Not Required or Processes
Re-associates partners and clients from the source environment to the target.	The Administrator runs WLST commands to: Replicate and transfer OAM policies from the source to the target system. Create place holder host-identifiers and use these in target application domains.
	The Administrator uses the remote registration tool to: Register source partners with the target system. Add the agents to target host-identifiers created by WLST commands. Associate an agent with an existing application domain. Create a new policy in the target with the default authentication scheme for the partner application. Associate the partner application with the specified application domain and policy.

Requirements

Automated and Manual Tasks

Not Required or Processes

Re-associates partners and clients from the source environment to the target.

The Administrator runs WLST commands to:

Replicate and transfer OAM policies from the source to the target system.
Create place holder host-identifiers and use these in target application domains.

The Administrator uses the remote registration tool to:

Register source partners with the target system.
Add the agents to target host-identifiers created by WLST commands.
Associate an agent with an existing application domain.
Create a new policy in the target with the default authentication scheme for the partner application.
Associate the partner application with the specified application domain and policy.

About the WebLogic Scripting Tool Commands

Whether you are moving to a new target, or to an existing target, Oracle provides the WLST commands that use an MBean on the OAM 11g AdminServer and enable administrators to:

Configure the target user identity store to match the source user identity store, when needed.
Replicate and move application domain and policy data (for all or for only selected domains and policies).
Provide a conflict resolution profile that describes how ID conflicts between the source and target systems must be resolved.

Exporting replicates and exports application domains and partner information to a temporary dump file. To protect this sensitive information, a Keystore is generated with the dump file. The key in this Keystore is used to encrypt the dump file.

Table A-7 provides information on export mode commands, which you run on the test source OAM Server that is hosting the partner to be exported.

Table A-7 Export Commands

Command	Description	Example
exportPartners()	Exporting a partner creates an object with all partner information, along with the key for each of the partners. This command takes the path to the temporary oam-partners file as a parameter.	exportPartners(pathTempOAMPartnerFile=', <pathTempOAMPartnerFile>)
exportPolicy-	Exports application domain and policy data from the source. OAM application domains are exported with all dependencies. This command takes the path to the temporary oam-policy file as a parameter.	exportPolicy(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >')

Command

Description

Example

exportPartners()

Exporting a partner creates an object with all partner information, along with the key for each of the partners.

This command takes the path to the temporary oam-partners file as a parameter.

exportPartners(pathTempOAMPartnerFile=', <pathTempOAMPartnerFile>)

exportPolicy-

Exports application domain and policy data from the source. OAM application domains are exported with all dependencies.

This command takes the path to the temporary oam-policy file as a parameter.

exportPolicy(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >')

Importing decrypts the generated dump file using the key in the Keystore and imports the dump file contents to the target OAM Server. You can import partners, policies, or policy differences, as described in Table A-8. Import commands are run on the target OAM Server.

Table A-8 Import Commands

Command	Description	Example
importPartners()	Decrypts and imports partner data using the key in the Keystore. This command takes as input the path the temporary oam-partners file as a parameter that was created during the export operation.	importPartners (pathTempOAMPartnerFile=', <pathTempOAMPartnerFile>')
importPolicy-	Decrypts and imports application domain and policy data. Caution: This command overwrites all policy data on the target. This command takes as input the path the temporary oam-policy file that was created during the export operation.	importPolicy(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >')
importPolicyDelta-	Decrypts and only the changes from the source to the target OAM Server without overwriting unchanged policy data on the target. Note: This command writes only changed policy data to the target. This command takes as input the path the temporary oam-policy file that was created during the export operation.	importPolicyDelta(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >'

Command

Description

Example

importPartners()

Decrypts and imports partner data using the key in the Keystore.

This command takes as input the path the temporary oam-partners file as a parameter that was created during the export operation.

importPartners (pathTempOAMPartnerFile=', <pathTempOAMPartnerFile>')

importPolicy-

Decrypts and imports application domain and policy data.

Caution: This command overwrites all policy data on the target.

This command takes as input the path the temporary oam-policy file that was created during the export operation.

importPolicy(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >')

importPolicyDelta-

Decrypts and only the changes from the source to the target OAM Server without overwriting unchanged policy data on the target.

Note: This command writes only changed policy data to the target.

This command takes as input the path the temporary oam-policy file that was created during the export operation.

importPolicyDelta(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >'

Figure A-1 illustrates the processing that occurs between the source and target systems.

Figure A-1 Source and Target processing

Description of "Figure A-1 Source and Target processing"

About Conflict Resolution

The source system is presumed to be the single source of truth during data migration. Any conflicts that are detected between the source system and the target system must be resolved during processing. A sample of the conflict resolution template is shown here and described in Table A-9.

<Conflict-Resolution>
   <Authentication-Modules value="Use Existing/Error"/> 
   <Authentication-Schemes value="Reuse/Replace/Create New/Error"/> 
   <Host-Identifiers value="Add to Existing/Create New"/>  
   <Policy value="Reuse/Replace/Create New/Error"/>
   <Application-Domains value="Reuse/Replace/CreateNew/Error"/ > 
<Conflict-Resolution>/

Table A-9 Conflict Resolution

Element	Description
Authentication Modules Authentication-Modules value="Use Existing/Error"/>	The authentication modules are defined for each OAM system. These modules are configured during system configuration. So the migration will not create authentication modules if they are not present in the production system. If the authentication module in the production system does not match the test system, the administrator can choose to use existing authentication module or throw an exception and exit the migration process. The administrator records this choice in the conflict resolution profile.
Authentication Schemes <Authentication-Schemes value="Reuse/Replace/Create New/Error"/>	If authentication scheme with the same ID exists in test and production system, the conflict needs to be resolved before migrating. The Authentication scheme has the attributes - Name, Authentication level, Challenge method and Authentication module. All these attributes are used to match the authentication schemes in the test and production systems. If all these attributes match, the migration process will use the existing scheme. However, if any of these attributes don't match, the administrator can choose to create a new authentication scheme with a new unique ID. This choice recorded in the resolution profile.
Host-Identifiers Host-Identifiers value="Add to Existing/Create New"/>	A host can be addressed in multiple ways: host name with the domain name, host name without the domain name and the IP address. A host-identifier is used to group all these addressing methods so that requests matching any of these addressing methods are protected by the OAM Server. For instance, suppose that you need to resolve one of the following types of conflicts between the source system (the single source of truth) and the target system: Authentication Modules Authentication Schemes Host-Identifiers and hosts Host-identifiers are used as a part of the resources in application domains. While exporting the application domains from the test to the production system, the host-identifier conflicts will have to be resolved. If the host-identifier and all the hostnames in that host-identifier exactly match in the test and production systems match, then migration of the application domain continue. However, if the host-identifiers and hostnames do not match then conflict has to be resolved. Here are the situations where the host-identifiers do not match: Host identifier with the same name has a completely different set of hostnames in test and production system Host identifier with the same name in test system has a subset of hostnames in the production system Host identifier with the same name in the production system has a subset of hostnames in the test system Host identifier with the same hostnames has different names.

Element

Description

Authentication Modules

Authentication-Modules value="Use Existing/Error"/>

The authentication modules are defined for each OAM system. These modules are configured during system configuration. So the migration will not create authentication modules if they are not present in the production system. If the authentication module in the production system does not match the test system, the administrator can choose to use existing authentication module or throw an exception and exit the migration process. The administrator records this choice in the conflict resolution profile.

Authentication Schemes

<Authentication-Schemes value="Reuse/Replace/Create New/Error"/>

If authentication scheme with the same ID exists in test and production system, the conflict needs to be resolved before migrating. The Authentication scheme has the attributes - Name, Authentication level, Challenge method and Authentication module. All these attributes are used to match the authentication schemes in the test and production systems. If all these attributes match, the migration process will use the existing scheme. However, if any of these attributes don't match, the administrator can choose to create a new authentication scheme with a new unique ID. This choice recorded in the resolution profile.

Host-Identifiers

Host-Identifiers value="Add to Existing/Create New"/>

A host can be addressed in multiple ways: host name with the domain name, host name without the domain name and the IP address. A host-identifier is used to group all these addressing methods so that requests matching any of these addressing methods are protected by the OAM Server.

For instance, suppose that you need to resolve one of the following types of conflicts between the source system (the single source of truth) and the target system:

Authentication Modules
Authentication Schemes
Host-Identifiers and hosts

Host-identifiers are used as a part of the resources in application domains. While exporting the application domains from the test to the production system, the host-identifier conflicts will have to be resolved. If the host-identifier and all the hostnames in that host-identifier exactly match in the test and production systems match, then migration of the application domain continue. However, if the host-identifiers and hostnames do not match then conflict has to be resolved. Here are the situations where the host-identifiers do not match:

Host identifier with the same name has a completely different set of hostnames in test and production system

Host identifier with the same name in test system has a subset of hostnames in the production system

Host identifier with the same name in the production system has a subset of hostnames in the test system

Host identifier with the same hostnames has different names.

About Building a Dependency Tree for Each Application Domain

Before migrating an OAM 11g application domain, a dependency tree must be constructed for each of the application domains to be migrated.

The dependency tree can be represented as shown in Figure A-2.

Figure A-2 Dependency Tree for Each Application Domain

In the sample dependency tree shown in Figure A-2, the application domain consists of three authentication policies and two resources. Each authentication policy is configured with an authentication scheme and each of authentication scheme has an authentication module configured. This sample application domain applies to two resources (each resource is defined as a host identifier and a resource URL).

To migrate data for an application domain, the shared components (Modules, Schemes and Host-identifiers) must be migrated first, if they are not already migrated. Shared component data migration is followed by application domain data migration.

Planning an OAM 11g Move from Test to Production

Planning and preparation are key components of any successful data transfer strategy. This section discusses the planning considerations and inventory items that you and your team need to create to ensure your success:

Noting Differences Between Source and Target Environments
Developing Deployment Inventories
Developing Tests
Understanding Change Propagation
Scheduling and Notifications

Choose the Method

Review details in "About Methods to Move from Test to Production" and choose the method that best suits your needs as described in:

Table A-3, "Full Replication"
Table A-4, "Golden Template"
Table A-5, "Delta-Replication"
Table A-6, "Application Re-association"

Noting Differences Between Source and Target Environments

When transferring Oracle Access Manager configuration data from a source to a target, be sure to note the following types of differences between the two environments:

Names and implementation details of OAM Server instances
Names and implementation details of OAM Agents (WebGates, and AccessGates) including changing the OAM Server to which the Agent points.
Names and implementation details of OSSO Agents (mod_osso) including changing the OAM Server to which the Agent points
Definitions for Host Identifiers
Definitions for authentication schemes, including Challenge Redirect parameters.
Definitions for authorization policies, constraints, responses, and resources
Definitions for application domains, including all redirect URLs defined in authentication and authorization policies

Developing Deployment Inventories

Before starting any transfer activities, Oracle recommends that you take inventory of your existing Oracle Access Manager 11g Release 1 (11.1.1) deployment. You can gather details from existing installation records or you can gather fresh information directly from the deployment.

Developing Tests

To help ensure data correctness before transfer, Oracle recommends that you develop specific tests that evaluate configuration in the source deployment.

After transfer, you can use these same tests in the target deployment to ensure that everything is working as expected.

Understanding Change Propagation

All changes are reflected in the OAM Administration Console and are automatically propagated to every OAM Server in the cluster.

When you have a single OAM Server and a single OAM Administration Console running on different computers, changes are propagated to the managed run-time OAM Server.

Scheduling and Notifications

Before starting any move, Oracle strongly recommends that you and your team schedule specific transfer windows and that you notify other administrators about planned activities in any deployment for which they are responsible.

Backup and Recovery Strategies

Oracle recommends that you back up data before transfer, and restore the backup after transfer if needed.

Moving OAM 11g From Test to Production

This section is divided into the following based on your needs:

Exporting OAM 11g Data from Test (Source)
Importing OAM 11g to Production (Target)

Exporting OAM 11g Data from Test (Source)

Use steps in the following procedure as needed to export partner and policy data from the test source environment.

Prerequisites

Planning an OAM 11g Move from Test to Production

See:

"Introduction to Methods and Tools"
Appendix F, "Introduction to Custom WLST Commands for OAM Administrators"
Oracle Fusion Middleware Administrator's Guide for details about moving Oracle Access Manager 10g to a new (or an existing) production environment

To export data from the test source

Export Partner Data: On the source OAM Server hosting the OAM 11g partner run the following t2pClient command using the path to your own temporary OAM partners file. For example:
```
exportPartners(pathTempOAMPartnerFile=', <pathTempOAMPartnerFile>>') 
```
Export Policy Data: On the source OAM Server hosting the OAM 11g policy data, run the following t2pClient command using the path to your own temporary OAM policy file. For example:
```
exportPolicy(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >')
```
Repeat on each source OAM Server hosting partner and policy data.

Importing OAM 11g to Production (Target)

Use steps in the following procedure as needed to import partner and policy data from the test source environment.