This chapter describes how to migrate Oracle Access Manager 10g to Oracle Access Management Access Manager (Access Manager) 11g Release 2 (11.1.2.1.0).
This chapter contains the following sections:
Section 11.5, "Installing Oracle Identity and Access Management 11.1.2.1.0"
Section 11.6, "Configuring Oracle Access Management Access Manager 11.1.2.1.0"
Section 11.7, "Configuring Transport Security Mode for Access Manager 11.1.2.1.0 Server"
Section 11.8, "Starting Administration Server and Access Manager 11.1.2.1.0 Managed Servers"
Section 11.13, "Migrating the Artifacts of Oracle Access Manager 10g to Access Manager 11.1.2.1.0"
Section 11.14, "Configuring Centralized Logout for 10g WebGates with Access Manager 11.1.2.1.0"
Section 11.15, "Associating the WebGates with Access Manager 11.1.2.1.0 Server"
The procedure described in this chapter can be used to migrate the following artifacts of Oracle Access Manager 10g to Access Manager 11.1.2.1.0.
Host identifiers
Agents
Data stores
Authentication schemes
Resource types
Policy domains
During this migration, you must install Access Manager 11g Release 2 (11.1.2.1.0), create a new Oracle Home (IAM_HOME)
, and migrate the policy data from the Oracle Access Manager 10g installation to the new Access Manager 11g Release 2 (11.1.2.1.0) Oracle Home.
This section contains the following topics:
The following are the three modes of migration that you can perform using the procedure described in this chapter:
This mode of migration migrates all artifacts of Oracle Access Manager 10g, which are compatible with 11.1.2.1.0, to Access Manager 11.1.2.1.0. You can perform complete migration only once. You can perform delta migration after performing complete migration, whereas incremental migration is not supported after complete migration.
Incremental migration is a mode of migration where the selected agents, policy domains and their related artifacts like host identifiers, resource types of the resources, and authentication schemes of Oracle Access Manager 10g are migrated to Access Manager 11.1.2.1.0. While migrating selected policy domains in incremental migration, the migration utility checks for any dependant artifacts, such as authentication schemes, host identifiers, and resource types; and migrates them first. This migration is followed by the migration of the associated policy domain.
You can migrate the artifacts that are not present in the Access Manager 11.1.2.1.0 environment. If an artifact that you wish to migrate is already present in the Access Manager 11.1.2.1.0 environment, the artifact is ignored and is not migrated.
You can perform incremental migration for more than once. You can also perform complete migration after incremental migration, or you can migrate all artifacts by performing incremental migration multiple times.
The incremental migration procedure is the same as the complete migration procedure. In addition, you must complete the additional steps required for incremental migration, as described in Additional Steps for Incremental Migration.
Delta migration can be performed only after complete migration. Delta migration refers to the migration of changes (referred to as delta) that you make to the 10g artifacts after the complete migration.
When you perform delta migration, changes made in the policy domains are migrated along with their corresponding changes in the dependent artifacts. For example, after complete migration, if you add a new resource which uses a newly created host identifier, the next delta migration migrates the newly created host identifier first, and then the resource.
Newly added resource types and agents are not migrated as part of the delta migration. To migrate the resource types, you must associate them with any of the policy domains.
Delta migration migrates 'add' or 'modify' types of changes. This means that, if you add any new artifacts or modify any artifacts (except for resource types and agents) in the 10g deployment, you can migrate those changes using delta migration. Delta migration does not migrate the 'deletions', which means, if you delete any artifact in the 10g deployment, you cannot get the same artifact deleted in the 11g deployment using delta migration. Migration tool ensures that it maintains the integrity of the existing data in Access Manager 11g if it cannot migrate any particular changes.
You cannot perform complete migration or incremental migration after delta migration. However, you can perform delta migration multiple times.
Note:
Oracle Access Manager 10g to Access Manager 11.1.2.1.0 delta migration depends on the availability of the changes made to the Oracle Access Manager 10g deployment. Oracle Access Manager 10g keeps track of the changes made to the 10g deployment using Sync Records
. Sync Records
are created only if you select the check box Update Cache that is available on the policy administration webpage, when you modify any policy related artifact using the Oracle Access Manager 10g Policy Manager console.
Table 11-1 summarizes the artifacts of Oracle Access Manager 10g that can be migrated to Access Manager 11.1.2.1.0:
Table 11-1 Compatibility of Artifacts
Artifact | Description |
---|---|
Host Identifiers |
|
Agents |
|
Data Stores |
|
Authentication Schemes |
|
Resource Types |
|
Policy Domains |
|
Figure 11-1 compares the topologies of Oracle Access Manager 10g and Access Manager 11.1.2.1.0.
Figure 11-1 Comparison of Oracle Access Manager 10g and Access Manager 11.1.2.1.0 Topologies
Table 11-2 lists the steps to migrate Oracle Access Manager 10g to Access Manager 11.1.2.1.0.
Task No | Task | For More Information |
---|---|---|
1 |
Complete the prerequisites. |
|
2 |
Install Oracle Identity and Access Management 11g Release 2 (11.1.2.1.0). |
See, Installing Oracle Identity and Access Management 11.1.2.1.0 |
3 |
Configure Access Manager 11.1.2.1.0. |
See, Configuring Oracle Access Management Access Manager 11.1.2.1.0 |
4 |
Configure the security mode of the Access Manager 11.1.2.1.0 server instance and the WebGates, so that the Access Manager 11.1.2.1.0 server accepts connections from the agents when WebGates start communicating with Access Manager 11.1.2.1.0 after migration. |
See, Configuring Transport Security Mode for Access Manager 11.1.2.1.0 Server |
5 |
Start the Administration Server and the Access Manager 11.1.2.1.0 Managed Servers. |
See, Starting Administration Server and Access Manager 11.1.2.1.0 Managed Servers |
6 |
Create a properties file with the LDAP details and the required information. |
|
7 |
Generate the assessment report, and analyze what agents and artifacts can be migrated to Access Manager 11.1.2.1.0. You can perform this task multiple times before you migrate your Oracle Access Manager 10g environment. |
|
8 |
Restart the Administration Server for the domain that has Access Manager 11.1.2.1.0. |
|
9 |
If you wish to perform incremental migration, complete the additional steps (for example, creating an input file). Ignore this task if you wish to perform complete migration. |
|
10 |
Migrate Oracle Access Manager 10g to Access Manager 11.1.2.1.0. |
See, Migrating the Artifacts of Oracle Access Manager 10g to Access Manager 11.1.2.1.0 |
11 |
If you are using 10g WebGates with Access Manager 11.1.2.1.0, you must configure the centralized logout for 10g WebGates to work with Access Manager 11.1.2.1.0 server. |
See, Configuring Centralized Logout for 10g WebGates with Access Manager 11.1.2.1.0 |
12 |
Associate the migrated WebGates with the Oracle Access Management 11.1.2.1.0 Server. |
See, Associating the WebGates with Access Manager 11.1.2.1.0 Server |
13 |
Verify the migration. |
You must complete the following prerequisites for migrating Oracle Access Manager 10g to Access Manager 11.1.2.1.0:
Read the Oracle Fusion Middleware System Requirements and Specifications document to ensure that your environment meets the minimum requirements for the products you are installing, upgrading, and migrating.
Note:
For information about Oracle Fusion Middleware concepts and directory structure, see "Understanding Oracle Fusion Middleware Concepts and Directory Structure" in the Oracle Fusion Middleware Installation Planning Guide for Oracle Identity and Access Management.
Verify that the Oracle Access Manager 10g version that you are using is supported for migration. For information about supported starting points for Oracle Access Manager 10g migration, see Section 10.1, "Supported Starting Points for Oracle Access Manager 10g Migration".
Make sure that all the user stores configured in your Oracle Access Manager 10g deployment are running.
Note:
The migration utility does not support connections with the configuration store over SSL port.
As part of the migration process, you must install Oracle Identity and Access Management 11g Release 2 (11.1.2.1.0). Oracle Identity and Access Management is a suite that contains Oracle Access Management Access Manager 11.1.2.1.0. This installation can be on the same machine where Oracle Access Manager 10g is installed, or on a different machine.
For more information about installing Oracle Identity and Access Management 11.1.2.1.0, see "Installing Oracle Identity and Access Management (11.1.2.1.0)" in the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.
After installing Oracle Identity and Access Management 11.1.2.1.0, you must configure Access Manager 11.1.2.1.0, and create a domain.
For information about configuring Access Manager 11.1.2.1.0, see "Configuring Oracle Access Management" in the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.
You must configure the security mode of the Access Manager 11.1.2.1.0 Server, so that the migrated WebGates communicate with the Access Manager 11.1.2.1.0 Server after migration. The following are the security modes listed in the increasing order of their security level:
Open
Simple
Cert
Open
is the least secured mode, and Cert
is the most secured mode. Open
is the default security mode. The security mode in which the Access Manager 11.1.2.1.0 server must be configured depends on the security modes of the Oracle Access Manager 10g WebGates that you wish to migrate.
This section contains the following topics:
Deciding the Security Mode of Access Manager 11.1.2.1.0 Server
Configuring Cert Mode Communication for Access Manager 11.1.2.1.0 Server
Configuring Simple Mode Communication for Access Manager 11.1.2.1.0 Server
If all the WebGates that you migrate have the same security mode, you must configure the Access Manager 11.1.2.1.0 Server in the respective modes. If you have mix of migrated WebGates configured in different security modes, you must configure the Access Manager 11.1.2.1.0 Server in the mode with the lower security level. Table 11-3 lists the various use cases and the security mode in which you must configure the Access Manager 11.1.2.1.0 Server.
Table 11-3 Choosing the Security Mode for Access Manager 11.1.2.1.0 Server
Transport Security Mode of Oracle Access Manager 10g WebGates | Security Mode to be Configured for Access Manager 11.1.2.1.0 Instance | Configuration Procedure |
---|---|---|
Some or all |
|
|
All |
|
See Configuring Cert Mode Communication for Access Manager 11.1.2.1.0 Server. |
All |
|
See Configuring Simple Mode Communication for Access Manager 11.1.2.1.0 Server. |
Mix of |
|
|
Mix of |
|
See Configuring Simple Mode Communication for Access Manager 11.1.2.1.0 Server. |
To configure Cert
mode communication for Access Manager 11.1.2.1.0, complete the following tasks in section "Configuring Cert Mode Communication for Access Manager" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management:
Reviewing "Introduction to Securing Communication Between OAM Servers and Webgates", and "About Cert Mode Encryption and Files"
Complete all of the steps described in this task.
"Generating a Certificate Request and Private Key for OAM Server"
Complete all of the steps described in this task.
"Retrieving the OAM Keystore Alias and Password"
Complete all of the steps described in this task.
"Importing the Trusted, Signed Certificate Chain Into the Keystore"
In this task, you import the Certificate Authority (CA) certificate used to issue the Cert
mode certificate for WebGate. If this CA certificate is different from the certificate that is already trusted by the Access Manager 11.1.2.1.0 Server, perform the following steps under this task. Otherwise, ignore these tasks.
"aaa_chain.pem: Using a text editor, modify the aaa_chain.pem file to remove all data except that which is contained within the CERTIFICATE blocks, then save the file"
"Import the trusted certificate chain using the following command with details for your environment"
"When prompted to trust this certificate, type yes"
"Adding Certificate Details to Access Manager Settings"
Ignore the step "Open the OAM Server registration page, click the Proxy tab, change the Proxy mode to Cert, and click Apply" under this task.
If the root certificate authority (CA) used for the Cert
mode certificate of the Access Manager 11.1.2.1.0 Server is different from the CA certificate present in aaa_chain.pem
file on the WebGate side, you must update the aaa_chain.pem
file with the root CA certificate used to issue the server Cert
mode certificates. To do this, complete the following steps:
Obtain the CA certificate in PEM format that was used to generate Cert
mode certificates for the Access Manager 11.1.2.1.0 Server instance.
Open this CA certificate in any text editor, copy the content from this file, including the BEGIN, END markers. For example:
----BEGIN CERTIFICATE-----
...
CERTIFICATE
...
-----END CERTIFICATE-----
Open the aaa_chain.pem
file from the location OHS_INSTANCE_HOME
/config/OHS/ohs2/webgate/config
using any text editor, and paste the content of server CA certification base 64 encoded contents to the end of the aaa_chain.pem
file.
Save the file, and close.
To configure Simple
mode communication for the Access Manager 11.1.2.1.0 Server, complete the following steps:
Log in to the Oracle Access Management 11.1.2.1.0 Administration console, using the following URL:
http://<host>:<port>/oamconsole
where <host>
is the machine on which Access Manager 11.1.2.1.0 is running, and <port>
is the port number.
Go to the System Configuration tab.
Expand Access Manager, and double-click Access Manager Settings.
Expand the Access Protocol section.
Set Global Passphrase to the same value used in your Oracle Access Manager 10g deployment.
Before you start migrating Oracle Access Manager 10g to Access Manager 11.1.2.1.0, make sure that the WebLogic Administration Server and the Access Manager 11.1.2.1.0 Managed Servers are up and running before you start migrating Oracle Access Manager 10g. If you have not started the WebLogic Administration Server and the Access Manager 11.1.2.1.0 Managed Servers, start them using the following procedure:
Starting Administration Server
To start the Administration Server, do the following:
On UNIX:
Move from your present working directory to the directory MW_HOME
/user_projects/domains/
domain_name
/bin
using the command:
cd MW_HOME/user_projects/domains/domain_name/bin/
Run the following command:
./startWebLogic.sh
When prompted, enter the WebLogic Administration Server username and password.
On Windows:
Move from your present working directory to the directory MW_HOME
\user_projects\domains\
domain_name
\bin
using the following command on the command line:
cd MW_HOME\user_projects\domains\domain_name\bin\
Run the following command:
startWebLogic.cmd
When prompted, enter the WebLogic Administration Server username and password.
Starting Access Manager 11.1.2.1.0 Managed Servers
To start a Access Manager 11.1.2.1.0 Managed Server, do the following:
On UNIX:
Move from your present working directory to the directory MW_HOME
/user_projects/domains/
domain_name
/bin
using the command:
cd MW_HOME/user_projects/domains/domain_name/bin/
Run the following command:
./startManagedWebLogic.sh oam_managed_server admin_url
In this command,
oam_managed_server
is the name of the Access Manager 11.1.2.1.0 Managed Server to be started.
admin_url
is the URL of the WebLogic administration console. It must be specified in the format http://
host
:
port
/console
.
When prompted, enter the WebLogic Administration Server username and password
On Windows:
Move from your present working directory to the directory MW_HOME
\user_projects\domains\
domain_name
\bin
using the following command on the command line:
cd MW_HOME\user_projects\domains\domain_name\bin\
Run the following command:
startManagedWebLogic.cmd oam_managed_server admin_url
In this command,
oam_managed_server
is the name of the Access Manager 11.1.2.1.0 Managed Server to be started.
admin_url
is the URL of the administration console. It must be specified in the format http://
host
:
port
/console
.
When prompted, enter the WebLogic Administration Server username and password.
Create a properties file in any accessible location. For example, create an oam_migration.properties
file.
The content of the properties file should be the following:
## Configuration store details ## If the configuration store is SSL enabled, the LDAP url should begin with 'ldaps'. config_store_ldap_url=ldap://<Host Name>:<Port>/ config_store_ldap_base=<Configuration store ldap base> config_store_principal=<Configuration store LDAP Principal> config_store_password=<Configuration store OAM 10g encrypted password> config_store_initial_context_factory=com.sun.jndi.ldap.LdapCtxFactory ## Policy store details ## If the policy store is SSL enabled, the LDAP url should begin with 'ldaps'. policy_store_ldap_url=ldap://<Host Name>:<Port>/ policy_store_ldap_base=<Policy store ldap base> policy_store_principal=<Policy store LDAP Principal> policy_store_password=<Policy store OAM 10g encrypted password> policy_store_initial_context_factory=com.sun.jndi.ldap.LdapCtxFactory ## This property indicates the path of trust store file which is a collective ## store of CA certs of all directory serves viz. policy store, config store, ## identity store. ldap_trust_store=<path to ldap trust-store> ## This property is required if client authentication in directory ## server is enabled and it contains the path of file having client ## certificates client_keystore=<path to ketstore file in jks format> ## If ldap_trust_store_password and client_keystore_password are left empty, ## then wlst commandline prompts for these passwords after migration utility ## is run. ldap_trust_store_password=<plain text password of trust store file> client_keystore_password=<plain text password of keystore file> ## migration_mode indicates what type of migration does the administrator intends ## to perform. ## 1. COMPLETE : A full migration will be performed. Ideal for a new OAM 11g ## environment with a clean database. ## 2. INCREMENTAL: Incremental mode can be used to migrate selective artifacts ## from 10g enviroment. Incremental mode will be dictated by the ## include and exclude file properties. Incremental Migration ## cannot be performed after Complete Migration. ## 3. DELTA : When the administrator intends to migrate the changes performed to the 10g artifacts ## then delta migration can be performed. This will include all the artifacts depending upon ## the GSN number. ## Defaults to COMPLETE if not specified. migration_mode=COMPLETE ## The include filename property indicates the absolute filename that would ## contain the list of artifacts that the administration wishes to selectively ## migrate to the 11g environment in incremental mode. For migration modes other ## than incremental, this property will be directly ignored. include_file=<include input filename> ## The exclude filename property indicates the absolute filename that would ## contain the list of artifacts that the administration wishes to selectively ## exclude from migrating to the 11g environment in incremental mode. For ## migration modes other than incremental, this property will be directly ignored. ## In incremental mode migration, if the administrator specifies both the include ## and exclude files then the include file wiil take precedence and exclude file ## will be ignored. exclude_file=<exclude input filename> ## This flag denotes whether the preview file should be created or not. If true, ## then preview report will be created irrespective of the value of the ## evaluate_only flag. If set to false, then preview report will not be created. ## Defaults to TRUE if not specified. preview_enabled=true ## Parameter to filter out preview report file based on the compatibility of an ## artifact. It can take values as COMPATIBLE, INCOMPATIBLE and ALL. ## If set to INCOMPATIBLE, it will include records with compatibility as ## INCOMPATIBLE,INCOMPATIBLE_WITH_LESS_FEATURES and IGNORE. If set to COMPATIBLE, ## it will include records with compatibility as COMPATIBLE. If set to ALL, ## it will include all types of record. ## Defaults to INCOMPATIBLE if not specified. preview_level=ALL ## Indicates the absolute path and filename of the evaluation preview record file. ## If not specified, defaults to ## <MW_Home>/user_projects/domains/base_domain/MigrationPreviewFile.txt evaluate_filename=<Preview report filename> ## Flag indicating whether the migration utility runs in evalute mode. If true, ## only preview records will be generated and actual migration to 11g environment ## will be skipped. If false, then actual migration will take place. ## Defaults to FALSE if not specified. evaluate_only=false ## Parameter for indicating the threashold limit for the artifacts processed in ## memory. Can be used on machines with less memory. If not provided, then ## defaults to 5000. If the migration utility is being used in 'evaluate only' ## mode, this value will be ignored. ## If you feel that the memory will not prove to be insufficient for the amount ## of data that is being migrated, set the value to "MAX". artifact_queue_limit=3000 ## Parameter to provide mode of an agent while migration. It will migrate all the ## agents in the mode specified here. The values can be, OPEN, SIMPLE, CERT ## and RETAIN_EXISTING. Defualt value will be RETAIN_EXISTING. This value will ## migrate agent in its existing mode. agent_mode_to_override=RETAIN_EXISTING
Table 11-4 describes the values you must provide for each of the properties in the properties file.
Table 11-4 Property File Values
Property | Description |
---|---|
|
Specify the LDAP host and the port of the configuration store used in Oracle Access Manager 10g deployment in the format: If the configuration store is SSL enabled, the LDAP URL should begin with ' |
|
Specify the LDAP search base for the configuration store of the Oracle Access Manager 10g deployment. This is the same search base that you provided during the installation of Oracle Access Manager 10g. To get this value, do the following:
|
|
Specify the LDAP DN of the administrator for the configuration store. |
|
Specify the encrypted password of the Oracle Access Manager 10g configuration LDAP store. To get the encrypted password, do the following:
|
|
The value of this property must be |
|
Specify the LDAP host and the port of the policy store used in Oracle Access Manager 10g deployment in the format: If the policy store is SSL enabled, the LDAP URL should begin with ' |
|
Specify the LDAP search base for the policy store of the Oracle Access Manager 10g deployment. This is the same search base that you provided during the installation of Oracle Access Manager 10g. To get this value, do the following:
|
|
Specify the LDAP DN of the administrator for the policy store. |
|
Specify the encrypted password of the Oracle Access Manager 10g policy LDAP store. To get the encrypted password, do the following:
|
|
The value of this property must be |
|
Specify the path to the trust store file in |
|
Specify the path to the keystore file in |
|
Specify the plain text password for the trust store file that you specified for the property If the value of this property is empty, the WLST command line prompts for password when you run the migration utility. |
|
Specify the plain text password for the keystore file that you specified for the property This property is required only if you have specified the path of the keystore file for the If the value of this property is empty, the WLST command line prompts for password when you run the migration utility. |
|
This property indicates the mode of migration you wish to perform. Set one of the following values:
For more information about the modes of migration, see "Modes of Migration". |
|
If you wish to perform incremental migration and migrate some of the artifacts to Access Manager 11.1.2.1.0, you must use the The value of the If you wish to perform incremental migration with the If you specify both For complete migration, this property is ignored. |
|
If you wish to perform incremental migration and exclude some of the artifacts from the migration, you must use the The value of the If you wish to perform incremental migration with the If you specify both For complete migration, this property is ignored. |
|
This property indicates whether the assessment report should be created. If the value of this property is set to If the value of the If you do not specify any value, the default value |
|
This property filters the data in the assessment report based on the compatibility of an artifact. You can provide one of the following values for this property:
If the value of this property is set to If the value of this property is set to If the value of this property is set to For more information about the artifacts that are incompatible, and compatible with less features, see Table 11-6. |
|
You must provide the absolute path and the filename for the assessment report file that you wish to generate. The default path is |
|
This properties indicates if the migration utility is run in evaluate mode. If the value of this property is set to If the value of this property is set to If you do not specify any value to this property, the default value |
|
This property indicates the threshold limit for the artifacts processed in memory. This property can be specified when you are using machines with less memory for the migration process. If the amount of data that is migrated is more, and the memory is sufficient, set the value of this property to The default value of this property is |
|
This property indicates the mode in which all agents are migrated. You can specify one of the following values to this property:
The default value is |
Note:
The value for the config_store_password
property must be encrypted. You can obtain the encrypted password from 10g_Installation_Directory
/Access/oblix/config/ldap/ConfigDB.xml
file.
The value for the policy_store_password
property must be encrypted. You can obtain the encrypted password from 10g_Installation_Directory
/Access/oblix/config/ldap/WebResrcDB.xml
file.
You should generate an assessment report before you can migrate the Oracle Access Manager 10g artifacts to Access Manager 11.1.2.1.0.
An assessment report is a text file generated when you run the migration utility by setting the appropriate properties in the properties file. The assessment report is generated at the location specified for the property evaluate_filename
in the properties file.
This report contains the information about all the artifacts in Oracle Access Manager 10g along with the information about their compatibility in Access Manager 11.1.2.1.0.
This report contains three sections of data:
Notes about how to analyze the report, and some generic information about the compatibility of the artifacts.
Number of artifacts that are compatible, incompatible, compatible with less features, and ignored in Access Manager 11.1.2.1.0
Detailed information about all the artifacts of Oracle Access Manager 10g in a tabular format.
Table 11-5 lists the columns of the table, which displays information about the artifacts of Oracle Access Manager 10g:
Table 11-5 Assessment Report Content
ColumnNo | Column | Description |
---|---|---|
1 |
ARTIFACT TYPE |
This column displays the type of the artifact in Oracle Access Manager 10g. The following are the types of artifacts:
|
2 |
ARTIFACT |
This column lists the names of all the artifacts of Oracle Access Manager 10g. The name of the policy domain is divided into two parts. The first part indicates the name of the policy domain, and the second part indicates the content of the policy domain. |
3 |
DETAILS |
This column displays information about each of the artifacts.
|
4 |
COMPATIBILITY |
This column displays information about the compatibility of artifacts in Access Manager 11.1.2.1.0.if the artifact is compatible with Access Manager 11.1.2.1.0 or not. The value for every artifact in this column can be one of the following:
|
5 |
MESSAGE |
This column displays any message relevant to the migration of the respective artifact. |
6 |
ACTION REQUIRED |
This column displays the action required by the user, if any. |
Note:
The level of data generated by the assessment report is determined by the property preview_level
in the properties file.
You can generate the assessment report multiple times before you can actually migrate the artifacts of Oracle Access Manager 10g to Access Manager 11.1.2.1.0.
Table 11-6 shows the types of artifacts of Oracle Access Manager 10g that are incompatible and compatible with less features in Access Manager 11.1.2.1.0.
Table 11-6 Assessment Reports Summary
Artifacts | Description |
---|---|
INCOMPATIBLE |
|
COMPATIBLE_WITH_LESS_FEATURES |
|
To generate the assessment report, do the following:
Edit the properties file that you created in Section 11.9, "Creating the Properties File" as follows:
Set the value of the migration_mode
property to COMPLETE
.
Set the value of the preview_enabled
property to true
.
Set the value of the evaluate_only
property to true
.
Make sure that you have set the absolute path of the assessment report file to the evaluate_filename
property.
Save the properties file, and close.
Perform step-2 to step-6 in the Section 11.13, "Migrating the Artifacts of Oracle Access Manager 10g to Access Manager 11.1.2.1.0".
This generates the assessment report at the location specified by the evaluate_filename
property in the properties file that you created. You can also open this report in Microsoft Excel. The records included in the assessment report are according to the value set for the preview_level
property in the properties file.
Since the evaluate_only
property in the properties file is set to true
, the migration utility only generates the assessment report, and it does not migrate the Oracle Access Manager 10g artifacts.
Note:
You can analyze the evaluation report, and make any necessary changes to the Oracle Access Manager 10g environment before proceeding with the migration.
If you wish to generate the assessment report and migrate the Oracle Access Manager 10g artifacts, set the value for evaluate_only
property to false
, and follow the steps described in Section 11.13, "Migrating the Artifacts of Oracle Access Manager 10g to Access Manager 11.1.2.1.0".
Note:
When you generate the assessment report, the migration utility also generates a text file called IncludeFile.txt
at the same location where the assessment report is generated. This file can be used to specify the artifacts that you wish to migrate while performing incremental migration. For more information about using the IncludeFile.txt
for incremental migration, see "Additional Steps for Incremental Migration".
Restart the WebLogic Administration Server for the domain with Access Manager 11.1.2.1.0 as follows:
Stopping Administration Server
To stop the Administration Server, do the following:
On UNIX:
Move from the present working directory to the directory MW_HOME
/user_projects/domains/
domain_name
/bin
using the command:
cd MW_HOME/user_projects/domains/domain_name/bin/
Run the following command:
./stopWebLogic.sh admin_username admin_password admin_url
In this command,
admin_username
is the username of the WebLogic Administration Server.
admin_password
is the password of the WebLogic Administration Server.
admin_url
is the URL of the administration console. It must be specified in the format http://
host
:
port
/console
.
On Windows:
Move from your present working directory to the directory MW_HOME
\user_projects\domains\
domain_name
\bin
using the following command on the command line:
cd MW_HOME\user_projects\domains\domain_name\bin\
Run the following command:
stopWebLogic.cmd
When prompted, enter the Administration Server username and password.
Starting Administration Server
To start the WebLogic Administration Server, do the following:
On UNIX:
Move from your present working directory to the directory MW_HOME
/user_projects/domains/
domain_name
/bin
using the command:
cd MW_HOME/user_projects/domains/domain_name/bin/
Run the following command:
./startWebLogic.sh
When prompted, enter the WebLogic Administration Server username and password.
On Windows:
Move from your present working directory to the directory MW_HOME
\user_projects\domains\
domain_name
\bin
using the following command on the command line:
cd MW_HOME\user_projects\domains\domain_name\bin\
Run the following command:
startWebLogic.cmd
When prompted, enter the WebLogic Administration Server username and password.
Complete the following steps only if you wish to perform incremental migration:
Set the property migration_mode
to INCREMENTAL
in the properties file (Section 11.9, "Creating the Properties File") that you create during the migration process.
When you generate the assessment report (as described in Generating the Assessment Report), an input file called IncludeFile.txt
is generated at the same location where the assessment report is generated. This text file contains agents and application domains of Oracle Access Manager 10g deployment. The agents and application domains are listed in the IncludeFile.txt
as shown in the following example:
AGENT##ag_one_12752##ag_one_12752##N AGENT##temp##temp##N APPLICATION_DOMAIN##20120304T01055680323##my_domain##N APPLICATION_DOMAIN##20120306T03491413638##Finance##N APPLICATION_DOMAIN##20120306T04155393859##HR##N APPLICATION_DOMAIN##20120319T0255014722##Domain With Resources Only##N APPLICATION_DOMAIN##20120319T03241993733##Domain with Policy##N APPLICATION_DOMAIN##20120319T03300047441##Domain with policy and authn rule##N APPLICATION_DOMAIN##20120319T03324669347##domain with policy and authz rule##N
To perform incremental migration, you must specify either a list of artifacts (agents and application domains) that you wish to migrate, or a list of artifacts (agents and application domains) that you wish to exclude from the migration. Therefore, you must create one of the following files:
include file: This is a text file that contains the list of agents and application domains that you wish to migrate. You can either use the auto-generated IncludeFile.txt
as the include
file by marking the agents and application domains that you wish to migrate as Y
, or manually create a new include
file. However, it is recommended that you use the IncludeFile.txt
to create the include
file.
To create the include
file using the IncludeFile.txt
, do the following:
a. Copy the IncludeFile.txt
to any accessible location, and rename it to include.txt
, if required.
b. Mark the agents and application domains that you wish to migrate as Y
. Y
indicates that the artifact is selected for incremental migration.
c. Set the property include_file
in the properties file (oam_migration.properties
) to the absolute path to the include
file.
Note:
If you wish to manually create the include
file, specify the agents and application domains that you wish to migrate in the format specified in the following example:
AGENT##temp##temp##Y
APPLICATION_DOMAIN##20120304T01055680323##my_domain##Y
exclude file: This is a text file that contains the list of agents and application domains that you wish to exclude from migration. You can either use the auto-generated IncludeFile.txt
as the exclude
file by marking the agents and application domains that you wish to exclude from migration as Y
, or manually create a new exclude
file. However, it is recommended that you use the IncludeFile.txt
to create the exclude
file.
To create the exclude
file using the IncludeFile.txt
, do the following:
a. Copy the IncludeFile.txt
to any accessible location, and rename it to exclude.txt
, if required.
b. Mark the agents and application domains that you wish to exclude from migration as Y
. Y
indicates that the artifact is not selected for incremental migration.
c. Set the property exclude_file
in the properties file (oam_migration.properties
) to the absolute path to the exclude
file.
Note:
If you wish to manually create the exclude
file, specify the agents and application domains that you wish to exclude from the incremental migration in the format specified in the following example:
AGENT##temp##temp##Y
APPLICATION_DOMAIN##20120304T01055680323##my_domain##Y
Note:
If you create both the include file and the exclude file, and specify paths to both the files in the properties file, then the include
file takes precedence, and the exclude file will be ignored.
If you do not specify any of these input files in the properties file, the migration will be aborted.
You can perform incremental migration more than once.
Before you migrate Oracle Access Manager 10g to Access Manager 11.1.2.1.0, it is recommended that you generate an assessment report (as described in Section 14.9, "Generating the Assessment Report"), and analyze what artifacts are compatible and incompatible in Access Manager 11.1.2.1.0.
Note:
If you decide to migrate Oracle Access Manager 10g to Access Manager 11.1.2.1.0 after analyzing the assessment report, perform the steps 1 to 6 described in this section.
If you wish to perform incremental migration, make sure that you have set the property migration_mode
to INCREMENTAL
in the properties file. Also, ensure that you have completed the additional steps described in Section 11.12, "Additional Steps for Incremental Migration" before you follow the steps described in this section.
If you wish to perform complete migration, make sure that you have set the property migration_mode
to COMPLETE
in the properties file.
Complete the following steps to perform complete migration or incremental migration:
Set the value of evaluate_only
property to false
in the properties file that you created in Creating the Properties File. Save the file and close.
Run the following command to launch the WebLogic Scripting Tool (WLST):
On UNIX:
Move from your present working directory to the IAM_HOME
/common/bin
directory by running the following command on the command line:
cd
IAM_HOME
/common/bin
Run the following command to launch the WebLogic Scripting Tool (WLST):
./wlst.sh
On Windows:
Move from your present working directory to the IAM_HOME
\common\bin
directory by running the following command on the command line:
cd
IAM_HOME
\common\bin
Run the following command to launch the WebLogic Scripting Tool (WLST):
wlst.cmd
Run the following command to connect WLST to the WebLogic Server instance:
connect('wls_admin_username','wls_admin_password','t3://hostname:port');
In this command,
wls_admin_username
is the username of the WebLogic Administration Server.
wls_admin_password
is the password of the WebLogic Administration Server.
hostname
is the host on which WebLogic Administration Server is running.
port
is the port of the WebLogic Administration Server.
For example:
connect('weblogic','password','t3://localhost:7001');
Run the following command:
domainRuntime();
Run the following command:
setLogLevel(logger="oracle.oam",level="TRACE:32",persist="0",target="AdminServer");
Run the following command to migrate the artifacts of Oracle Access Manager 10g to Access Manager 11.1.2.1.0:
oamMigrate(oamMigrateType="OAM10g",pathMigrationPropertiesFile="absolute_path_of_properties_file");
where
absolute_path_of_properties_file
is the absolute path of the properties file that you created in Creating the Properties File. For example:
On UNIX: oamMigrate(oamMigrateType="OAM10g",pathMigrationPropertiesFile="
abc
/
def
/oam_migration.properties
"
On Windows: oamMigrate(oamMigrateType="OAM10g",pathMigrationPropertiesFile="
abc
\\
def
\\oam_migration.properties"
When the migration is complete, the WLST console displays a message that indicates the result of the migration. The log files are generated at the following location:
On UNIX: MW_HOME
/user_projects/domains/base_domain/servers/AdminServer/logs/
Adminserver-diagnostic*.log
On Windows: MW_HOME
\user_projects\domains/base_domain\servers\AdminServer\logs/
Adminserver-diagnostic*.log
In case of any errors during the migration process, refer to the log files.
If you are using 10g WebGates with Access Manager 11.1.2.1.0, you must configure the centralized logout settings for 10g WebGates to work with Access Manager 11.1.2.1.0 server, after migrating Oracle Access Manager 10g to Access Manager 11.1.2.1.0.
For more information about configuring centralized logout for 10g WebGates, see "Configuring Centralized Logout for 10g Webgate with 11g OAM Servers" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.
Note:
Skip this step if you are not using 10g WebGates with Access Manager 11.1.2.1.0.
After you migrate Oracle Access Manager 10g to Access Manager 11.1.2.1.0, you must associate all of the migrated WebGates with the Access Manager 11.1.2.1.0 Server. To do this, complete the following steps:
Create a new server profile on Oracle Access Manager 10g Access System console with the hostname and port details of the Access Manager 11.1.2.1.0 Server instance, by doing the following:
Log in to the Oracle Access Manager 10g Access System console.
Go to the Access System Configuration tab.
Click Access Server Configuration on the left navigation pane.
Click Add to create a new server profile.
Specify the following details:
Name: Specify a name for this server.
Hostname: Specify the hostname of the machine on which Access Manager 11.1.2.1.0 Server instance is running.
Port: Specify the proxy port for Access Manager 11.1.2.1.0 Server instance. The default proxy port for Access Manager 11.1.2.1.0 is 5575
.
Transport Security: Specify the same transport security mode as that of the Access Manager 11.1.2.1.0 Server instance.
Keep the default values for other parameters.
Click Save.
Set the value of MAX Connections
parameter of the WebGate (AccessGate) in the WebGate profile such that the WebGate does not establish connection with the Access Manager 11.1.2.1.0 Server after association.
If all of the Oracle Access Manager 10g primary servers are up, set the value of MAX Connections
equal to the sum of the number of connections to all the primary Oracle Access Manager 10g servers.
For more information about modifying a WebGate profile, see "Modifying an AccessGate" in the Oracle Access Manager Access Administration Guide for release 10g (10.1.4.3).
Associate each of the WebGates with the Access Manager 11.1.2.1.0 Server as one or more primary servers, by retaining the existing Oracle Access Manager 10g server. Set the number of connections to the Access Manager 11.1.2.1.0 server as 1
or more.
After the inactive reconfiguration period, the WebGate is updated with the new list of servers.
Optional: For each WebGate, make sure that the file ObAccessClient.xml
at the location webgate_installation_directory
/oblix/lib/ObAccessClient.xml
is updated with the host and port of the Access Manager 11.1.2.1.0 Server in the list of primary servers. To do this, open the ObAccessClient.xml
file and look for the list of primary servers.
Point the WebGate to the Access Manager 11.1.2.1.0 server by performing one of the following tasks:
Stop all the Oracle Access Manager 10g Servers. If the number of connections to Oracle Access Manager 10g servers is high, WebGate takes a few minutes to start talking to the Access Manager 11.1.2.1.0 Server. If you restart the web server that hosts the WebGate, WebGate starts talking to the Access Manager 11.1.2.1.0 server immediately.
Increase the value of the parameter MAX Connections
by one, so that the WebGate establishes the connection with Access Manager 11.1.2.1.0 server. If the load on WebGate is more, it takes less time to connect to the Access Manager 11.1.2.1.0 Server.
WebGate now gets the new configuration information from the Access Manager 11.1.2.1.0 Server, which has only one primary server. Thus, the WebGate communicates only with the Access Manager 11.1.2.1.0 server. Once this is done, you can reduce the value of MAX Connections
as there is only one server.
To verify the migration, do the following:
The message "Migration completed successfully" is displayed on the WLST console if the migration is successful.
Verify the migration details like upgraded status, type of migration, timestamp and so on, in the oam-config.xml
file that is generated in the following directory:
On UNIX:
MW_HOME
/user_projects/domains/
Domain_Name
/config/fmwconfig/
On Windows:
MW_HOME
\user_projects\domains\
Domain_Name
\config\fmwconfig\
Log in to the Oracle Access Management console using the following URL:
http://host:port/oamconsole
In this URL, host
is the machine on which Access Manager 11.1.2.1.0 is running, and port
is the port number.
Verify that the Oracle Access Manager 10g artifacts are migrated to Access Manager 11.1.2.1.0.
Note:
This completes the migration. For more information on managing the Oracle Access Management Access Manager 11.1.2.1.0, see Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.
This section describes solutions to the common problems that you might encounter when migration Oracle Access Manager 10g to Access Manager 11.1.2.1.0. It contains the following topics:
If the size of the log file is too small, the migration data might get lost when the logs files are rotated. To overcome this, you must increase the size of the log file in the WebLogic console by doing the following:
Log in to the WebLogic Administration console using the following URL:
http://host:port/console
In this URL, host
is the hostname of the machine hosting WebLogic Administration Server, and port
is the port number of the Administration Server.
Under Domain Structure on the left navigation pane, expand Environment under the respective domain name.
Click Servers.
On the Summary of Servers page, go to the Configuration tab, and click on the name of the Administration Server (For example, AdminServer(admin)).
Go to the Logging tab, and click the General tab.
Specify the right values for the following fields:
Rotation file size: Specify the size of the log file in KiloBytes. The maximum value that can be specified is 65535 KB.
Files to retain: Specify the number of rotated log files you wish to retain.
Click Save.
If the Oracle Access Manager 10g policy data is large in terms of number of various policy related artifacts, the migration tool may need large memory for processing. If the WebLogic Administration Server has small heap size, you can increase it by doing the following:
On UNIX:
Open the setDomainEnv.sh
file in any text editor, from the directory MW_HOME
/user_projects/domains/
Domain_Name
/bin/
.
Search for the following line:
if [ "${USER_MEM_ARGS}" != "" ]
Add the following lines just before the line identified in the previous step.
USER_MEM_ARGS="new_heap_size"
export USER_MEM_ARGS
where, new_heap_size
is the new heap size of the WebLogic Administration Server in MegaBytes.
For example, if you wish to increase the heap size of the WebLogic Administration Server to 2GB, specify as shown below:
USER_MEM_ARGS="-Xms2048m -Xmx2048m" export USER_MEM_ARGS
On Windows:
Open the setDomainEnv.cmd
file in any text editor, from the directory MW_HOME
\user_projects\domains\
Domain_Name
\bin\
.
Search for the following line:
if NOT "%USER_MEM_ARGS%"=="" (
Add the following line just before the line identified in the previous step.
set USER_MEM_ARGS="new_heap_size"
where, new_heap_size
is the new heap size of the WebLogic Administration Server in MegaBytes.
For example, if you wish to increase the heap size of the WebLogic Administration Server to 2GB, specify as shown below:
set USER_MEM_ARGS=-Xms2048m -Xmx2048m