Moving from a Test to a Production Environment 21-19
– If you are using a custom SP engine, you do not need to change the Oracle
Identity Federation configuration, but you must redeploy the .war file that was deployed in the test environment to the production environment.
For more information, see Configure Oracle Identity Federation in SP Mode in the Oracle Fusion Middleware Integration Guide for Oracle Access Manager.
b.
Click Apply.
8.
In most cases, you do not need to change the Security and Trust, Federations, or Authentication Mechanisms. Note the following:
■
If you need to change or add partners, see Add Trusted Providers and Delete Trusted Providers in the Oracle Fusion Middleware Administrators
Guide for Oracle Identity Federation.
■
If you need to change the HTTP basic authentication, update the user name and password:
In Fusion Middleware Control, from the target menu on the OIF page, choose Administration,
then Federations. Select a Trusted Provider and click Edit. Update HTTP Authentication Username and HTTP Authentication
Password.
Then, confirm the password. Click Apply.
9.
Start the Managed Servers.
Task 8 Move Oracle Adaptive Access Manager to a New Production Environment To move Oracle Adaptive Access Manager to a new production environment:
1.
Export snapshots from the test environment. Use the Oracle Adaptive Access Manager Administration console to export the configuration to a zip file. See
System Snapshot ImportExport in the Oracle Fusion Middleware Administrators Guide for Oracle Adaptive Access Manager for more information.
You can export the following types of items:
■
Policies
■
Rule conditions
■
Patterns
■
Configurable actions
■
Transaction definitions
■
Entities
■
KBA questions
■
KBA validations
■
All group types, including alert and action groups, and black list and white list groups used in rules
2.
Import snapshots into the production environment. Use the Oracle Adaptive Access Manager Administration console to import the contents of the zip file
saved in step 1. See System Snapshot ImportExport in the Oracle Fusion Middleware Administrators Guide for Oracle Adaptive Access Manager for more
information.
3.
Manually update the production environment for the following items, when necessary:
21-20 Oracle Fusion Middleware Administrators Guide
a.
Because snapshot export and import only copies action and alert group types, you must export the group members from test environment and import them
into the production environment.
To export the groups, see Exporting a Group in the Oracle Fusion Middleware Administrators Guide for Oracle Adaptive Access Manager.
To import the groups into the production environment, see Importing a Group in the Oracle Fusion Middleware Administrators Guide for Oracle Adaptive
Access Manager.
b.
Use the oaam_extensions shared library to package the configurable actions jar.
c.
Manually copy any items customized in the OAAM server, such as headers, footers, cascading style sheets CSS, and JavaScript, from the test
environment to production environment. These items are located in the oaam_ extensions shared library.
d.
Manually re-create the KBA logic, OTP logic, and policy set overrides using the Oracle Adaptive Access Manager Administration Console. See the Oracle
Fusion Middleware Administrators Guide for Oracle Adaptive Access Manager.
e.
Copy the following from the test environment to the production environment: properties files, resource bundles, and end user JSP screens. These items are
located in the oaam_extensions shared library.
f.
Copy the VAD images, which are in a custom jar, from the test environment to the production environment.
4.
Validate that the move was successful:
a.
Log in to OAAM Admin console, as described in OAAM Admin Console and Controls in the Oracle Fusion Middleware Administrators Guide for Oracle
Adaptive Access Manager.
b.
Navigate to Policies and check that the rules and groups from the test environment exist in the production environment.
c.
Navigate to the KBA module and check that the challenge questions in the test environment exist in the production environment.
d.
Test the Web applications that have been configured for Oracle Adaptive Access Manager. The user should be redirected to registration and challenge
flow.
Task 9 Move Oracle Identity Navigator to a New Production Environment To move Oracle Identity Navigator to a new production environment:
1.
On the production system, configure a proxy, as described in Configuring a Proxy to Access News Feeds in the Oracle Fusion Middleware Administrators Guide
for Oracle Identity Navigator.
Task 10 Move Oracle Identity Manager to a New Production Environment You can use the Oracle Identity Manager Deployment Manager to move most
metadata from a test environment to a production environment. The following table lists the entities that you can move using Deployment Manager:
Entities Deployment Manager Category
Roles Role
Moving from a Test to a Production Environment 21-21
To move Oracle Identity Manager to a new production environment:
1.
On the test environment, use the Deployment Manager to export the metadata for the entities listed in the preceding table. In the wizard, select the entities children
and dependencies. See Exporting Deployments in the Oracle Fusion Middleware System Administrators Guide for Oracle Identity Manager for information about how
to export metadata.
The data is exported as .xml files.
2.
On the production environment, use the Deployment Manager to import the metadata for the entities listed in the preceding table. See Importing
Deployments in the Oracle Fusion Middleware System Administrators Guide for Oracle Identity Manager for information about how to import metadata.
Organizations Organization Access Policies
Access Policy Attestation Processes
Attestation Process Authorization Policies
Authorization Policy User Metadata
User Metadata Roles and Org Metadata
Roles and Org Metadata Scheduled Tasks
Scheduled Task Scheduled Jobs
Job IT Resources
IT Resource Resource Objects
Resource Lookup Definitions
Lookup Process Forms
Process Form Provisioning Workflows and Adapters
Process Resource Forms
Resource Form Data Object Definitions
Data Object Definition Rules Rule
Notification Templates Notification Template
GTC Providers GTC Provider
Error Codes Error Code
System Properties System Property
EmailDef Email Definition
EventHandler Event Handlers
PasswordPolicy Password Policy
GenericConnector Generic Connector
ITResourceDef IT Resource
Definition Request Templates
Request Template Request Datasets
Request Dataset Approval Policies
Approval Policy
Entities Deployment Manager Category
21-22 Oracle Fusion Middleware Administrators Guide
The Deployment Manager does not manage resource bundles, jars and plug-ins, and Custom Reconciliation Profiles.
3.
Move the Approval Workflows, which are SOA composite applications, using JDeveloper:
a.
Copy all of the files in the JDeveloper project from the test environment to the production environment, using any standard file transfer method.
b.
In the application, change any calls to external systems to point to the systems in the production environment. For example, if the workflow uses an LDAP
server in the test environment, change references to point to an LDAP server in the production environment.
c.
Use JDeveloper to build the sca jar file from the SOA composite.
d.
Deploy the SOA composite application on the production environment, using the SOA Deployment wizard in Fusion Middleware Control see
Section 10.5.1 or JDeveloper.
4.
In the test environment, export localization resource bundles, as well as the following sets of plug-in code from the test environment:
■
Scheduled Task jars
■
Adapter Java tasks
■
Third-party jars
■
Other plug-in code jars Take the following steps:
a.
Edit the following script, which exports the entities into a zip file:
UNIX OIM_ORACLE_HOMEserverbinexportMetadata.sh Windows OIM_ORACLE_HOME\server\bin\exportMetadata.bat
Edit the script to specify the following values:
– CONTEXT: The URL of the application. For example,
weblogic.jndi.WLInitialContextFactory.
– EXPORT_LOCATION: The full path to the directory where the zip file is
to be created.
– TEMP_LOCATION_TO_EXTRACT: The full path to a directory where the
files are to be stored temporarily before they are packaged into a zip file.
– CONTROL_FILE: An XML file that controls what needs to be exported.
You create the file, as described in Step b.
b.
Create a control file to specify the types of entities to be exported. The following example shows a sample control file that specifies that all custom
resource bundles, jar files, and plug-ins be exported:
?xml version=1.0 encoding=UTF-8? MigrationDetails Operation =Export
entityDetails EntityTypeCustomResourceBundlesEntityType
FilteringCriteria Attribute
NameResource_TypeName FilterFilter
Attribute FilteringCriteria
Moving from a Test to a Production Environment 21-23
entityDetails entityDetails
EntityTypeJarsEntityType FilteringCriteria
Attribute NameJar_TypeNameFilterFilter
Attribute FilteringCriteria
entityDetails entityDetails
EntityTypePluginsEntityType FilteringCriteria
Attribute NameTypeNameFilterFilter
Attribute FilteringCriteria
entityDetails MigrationDetails
c.
Execute the script, specifying the user name, password, and JNDI URL when prompted. The JNDI URL is the URL to connect to the application. For
example, t3:hostname:port.
The script creates a zip file named exportPackage_timestamp.zip, which is created in the directory exportPackage_timestamp.
5.
In the production environment, import localization resource bundles, as well as the sets of plug-in code from the test environment.
To import these entities, you use the importMetadata, which imports the entities into a zip file. Take the following steps:
a.
Edit the following script:
UNIX OIM_ORACLE_HOMEserverbinimportMetadata.sh Windows OIM_ORACLE_HOME\server\bin\importMetadata.bat
Edit the script to specify the following values:
–
CONTEXT: The URL of the application. For example, weblogic.jndi.WLInitialContextFactory.
–
IMPORT_LOCATION: The full path to the directory where the zip file created by the export operation is located.
–
TEMP_LOCATION_TO_EXTRACT: The full path to a directory where the files in the zip file are to be extracted before they are imported.
b.
Execute the script, specifying the user name, password, and JNDI URL when prompted. The JNDI URL is the URL to connect to the application. For
example, t3:hostname:port.
The script imports the data into the production environment.
6.
Move any custom reconciliation profiles, as described in Updating Reconciliation Profiles Manually in the Oracle Fusion Middleware System Administrators Guide for
Oracle Identity Manager.
a.
Use the WLST command exportMetadata to export the custom reconciliation profiles from the test environment:
connectusername,password,JNDI-URL exportMetadataapplication=OIM, server=server_name,
21-24 Oracle Fusion Middleware Administrators Guide
toLocation=directory, docs=path_to_reconciliation_profiles
b.
Copy the exported files to the production environment.
c.
Use the WLST command importMetadata to import the custom reconciliation profiles to the production environment:
connectusername,password,JNDI-URL importMetadataapplication=OIM, server=server_name,
fromLocation=directory, docs=
7.
For connectors, if there are any changes to the forms that need the older versions of these forms to be upgraded with the new definition on the production
environment, move the connectors, then run the Form Version Control FVC utility. For more information, see the section Upgrading the Connector of the
Connector Patch Readme file. The Readme file is located in the top-level directory of the connector distribution media.
Task 11 Move Audit Policies to a New Production Environment To move audit policies to a new production environment, see the following topics in
the Oracle Fusion Middleware Application Security Guide:
■
Migrating Audit Policies
■
Managing Audit Policies
Task 12 Move Oracle Platform Security to a New Production Environment To move Oracle Platform Security to a new production environment, you migrate the
policy store and credential store:
1.
If the policy store on the test environment is not file-based, migrate the policy store, using the WLST command migrateSecurityStore, as described in
Migrating Policies Manually in the Oracle Fusion Middleware Application Security Guide.
2.
If the credential store on the test environment is not file-based, migrate the credential store, using the WLST command migrateSecurityStore, as
described in Migrating Credentials Manually in the Oracle Fusion Middleware Application Security Guide.
3.
If you are using Oracle Web Services Manager, migrate audit policies, as described in Migrating Audit Policies in the Oracle Fusion Middleware Application Security
Guide.
Task 13 Move Oracle Web Services Manager to a New Production Environment
To move Oracle Web Services Manager to a new production environment:
1.
Move Oracle Platform Security to the production environment, as described in Task 12, Move Oracle Platform Security to a New Production Environment
. Oracle Web Services Manager depends on Oracle Platform Security and Oracle
Fusion Middleware Audit Framework. Oracle Web Services Manager uses Oracle Platform Security for the following:
■
Credential store: Oracle Web Services Manager stores client policy user name and password credentials and keystore passwords in the credential store.
■
Policy store: Oracle Web Services Manager permission-based authorization policies use Oracle Platform Security policy store to look up permissions.
Moving from a Test to a Production Environment 21-25
■
Login modules: Oracle Web Services Manager uses Oracle Platform Security login modules for all of its authentication.
■
Keystore configuration. However, the keystores in the test and production environments are typically different.
2.
Migrate audit policies, as described in Migrating Audit Policies in the Oracle Fusion Middleware Application Security Guide.
3.
Move policies that are not stored in the MDS Repository:
a.
If you have custom-built policies, move those by copying the jar files from the test to the production environment. The jar files are located in the following
directory:
DOMAIN_HOMElib
b.
For ADF BC and Oracle WebCenter policy attachments, migrate them, as described in Managing Application Migration Between Environments in the
Oracle Fusion Middleware Security and Administrators Guide for Web Services.
For other policy attachments, the attachments are moved with the application if you use the Oracle WebLogic Server cloning feature.
4.
Oracle WebLogic Server JAX-WS applications use policies stored in wsm-seed-policies.jar instead of in MDS. Move these policies by copying the
following file from the test environment to the production environment:
ORACLE_HOMEmodulesoracle.wsm.policies_11.1.1wsm-seed-policies.jar
5.
Move the keystore from the test environment to the production environment.
a.
Because private keys differ between test and production environments, you do not need to move them.
b.
Public keys, intermediate certificates, and root certificates can be moved. Use the Sun Microsystems java keytool export and import commands to move
them.
c.
After migration, review the certificates to see if they are applicable in the production environment based on the clients invoking the services.
d.
If the encryption key alias for the production keystore is different than the test environment keystore, then you must update the rcpt-key-alias for all the
policies that perform message protection in the policy configuration.
From Fusion Middleware Control, select the domain. Then, from the WebLogic Domain menu, choose Web Services, then Policies. Select the
policy and click Edit. Update the alias.
21.4.1.2 Moving Identity Management to an Existing Production Environment
In this scenario, you have installed Identity Management components, such as Oracle Internet Directory, Oracle Directory Integration Platform, and Oracle Web Services
Manager, in a test environment and you want to move them to a production environment that already exists.
On the existing production environment, you have installed and configured the components. You want to move an application from the test environment to the
production environment while retaining its security-related configuration. This
See Also:
Managing Horizontal Policy Migration in the Oracle Fusion Middleware Security and Administrators Guide for Web Services
21-26 Oracle Fusion Middleware Administrators Guide
requires migrating application-specific data from the test Identity Management environment to the production Identity Management environment.
To move Identity Management to an existing production environment, perform the following tasks:
■
Task 1, Move Oracle Internet Directory to an Existing Production Environment
■
Task 2, Move Oracle Access Manager 11g to an Existing Production Environment
■
Task 3, Move Oracle Access Manager 10g to an Existing Production Environment
■
Task 5, Move Oracle Adaptive Access Manager to an Existing Production Environment
■
Task 6, Move Oracle Identity Manager to an Existing Production Environment
■
Task 7, Move Oracle Identity Navigator to an Existing Production Environment
■
Task 8, Move Oracle Platform Security to an Existing Production Environment
■
Task 9, Move Oracle Web Services Manager to an Existing Production Environment
Task 1 Move Oracle Internet Directory to an Existing Production Environment To move Oracle Internet Directory to an existing production environment:
1.
You may have configured Oracle Platform Security to use the users and groups in the test environment. To move the users and groups from the test environment,
take the following steps:
a.
Identify the Default Subscriber for the test Oracle Internet Directory instance by running the following command from the test Oracle home:
ORACLE_HOMEbinldapsearch -h test_oid_host -p test_oid_port -D cn=orcladmin -w test_orcladmin_passwd
-b cn=Common,cn=Products,cn=OracleContext -s base objectclass= orcldefaultsubscriber
This query returns a value for the attribute orcldefaultSubscriber. The value is used in following steps as default_subscriber.
b.
Retrieve the users from the test Oracle Internet Directory instance by running the following command from the test Oracle home:
ORACLE_HOMEbinldapsearch -h test_oid_host -p test_oid_port -D cn=orcladmin -w test_orcladmin_passwd
-L -b cn=users, default_subscriber -s sub objectclass= orclguid ldif_filename
c.
Move the users into the production Oracle Internet Directory instance by running the following command from the production Oracle home:
ORACLE_HOMEbinldapaddmt -h production_oid_host -p production_oid_port -D cn=orcladmin
-w production_orcladmin_passwd -r -f ldif_filename
Specify the -r argument to move data and resolve conflicts. The ldif_filename is the file you obtained in the previous step.
2.
If the test environment is set up as a staging environment to mimic the production environment, Oracle recommends that you set up one-way replication from the
production Oracle Internet Directory to the test Oracle Internet Directory to ensure that any users or groups that exist in the production environment are available in
Moving from a Test to a Production Environment 21-27
the fan-out replica, which can be used to test applications. Fan-out replication also provides the capability to keep the test Oracle Internet Directory synchronized
with the production and to replicate any users or groups that are added into production on real-time basis.
For information about fan-out replication, see the following sections in the Oracle Fusion Middleware Administrators Guide for Oracle Internet Directory:
■
Understanding Oracle Internet Directory Replication
■
Setting Up a One-Way, Two-Way, or Multimaster LDAP-Based Replication Agreement by Using the Replication Wizard in Fusion Middleware Control
3.
If you use Oracle Forms Services or Oracle Reports, move Resource Access Descriptors RAD. This procedure assumes that you have moved the Default
Subscriber from the test environment to the production environment, as described in Step 1. It also assumes that the orclGUIDs of the users at the test Oracle Internet
Directory are identical to those in the production Oracle Internet Directory.
Take the following steps:
a.
Identify the Default Subscriber as described in Step 1a.
b.
Retrieve the RADs from the test Oracle Internet Directory instance using the following command:
ORACLE_HOMEbinldapsearch -h test_oid_host -w test_orcladmin_passwd -p test_oid_port -D cn=orcladmin
-L -b cn=Extended Properties,cn=OracleContext, default_subscriber -s sub objectclass= orclguid ldif_filename
c.
Move the RADs into the production Oracle Internet Directory instance using the following command:
ORACLE_HOMEbinldapaddmt -h production_oid_host -p production_oid_port -D cn=orcladmin
-w production_orcladmin_passwd -r -f ldif_filename
Specify the -r argument to move data and resolve conflicts. The ldif_filename is the file you obtained in the previous step.
Note that this command generates the file add.log in the directory where you run it. Check the add.log file for errors encountered during RADs migration. If
there are any errors, fix the errors and rerun the command.
Task 2 Move Oracle Access Manager 11g to an Existing Production Environment In this scenario, you move incremental changes that you have made in the test
environment to the production environment.
To replicate the policy configuration information from the test environment into the production environment:
1.
Set the environment variable JAVA_HOME and add JAVA_HOME to the PATH.
2.
Export the policies from the test environment, using the following WLST command:
exportPolicypathTempOAMPolicyFile=path_of_Temp_PolicyFile
Note: The Administration Servers in both the test environment and
the production environment must be started.
21-28 Oracle Fusion Middleware Administrators Guide
3.
Copy the policy file to the production environment.
4.
Import the policies into the production environment, using the following WLST command:
importPolicypathTempOAMPolicyFile=path_of_Temp_PolicyFile
5.
Export the partner information from the test environment, using the following WLST command:
exportPartnerspathTempOAMPartnerFile=path_of_Temp_PartnerFile
6.
Copy the partner file to the production environment.
7.
Import the partner information to the production environment, using the following WLST command:
importPartnerspathTempOAMPartnerFile=path_of_Temp_PartnerFile
Task 3 Move Oracle Access Manager 10g to an Existing Production Environment To move Oracle Access Manager 10g to an existing production environment:
1.
In the production environment, use the Oracle Access Manager OAMCfgTool to create the same policy domain for the application. Ensure that the following
specify values for the production environment:
web_domain The Host identifier is derived from this entry protected_uris=uri1,uri2,uri3
app_agent_password=password to be provisioned for the WebGate ldap_host=hostname_of_LDAP_server
ldap_port=port_of_LDAP_server ldap_userdn=DN_of_LDAP_Admin_User
ldap_userpassword=password_of_LDAP_Admin_User oam_aaa_host=host_of_OAM_server
oam_aaa_port=port_of_OAM_server
If you are using a uris_file to specify the protected and public URIs in a file, review the file to ensure that you are listed the corrected URIs.
2.
If you made other changes to the Oracle Access Manager entities, such as the policy domain, in the test environment, make the same types of changes in the
production environment.
Task 4 Move Oracle Identity Federation to an Existing Production Environment To move Oracle Identity Federation to an existing production environment:
1.
Set up the WLST environment on both the test and production environments as described in Setting up the WLST Environment in the Oracle Fusion Middleware
Administrators Guide for Oracle Identity Federation.
2.
On the test environment, extract the partner metadata and configuration properties by running the following script:
java weblogic.WLST extractPartnerMetadataAndProperties.py providerID outputFilePrefix
See Also: Delta-Replication in the Oracle Fusion Middleware
Administrators Guide for Oracle Access Manager with Oracle Security Token Service
Moving from a Test to a Production Environment 21-29
Two files are created: outputFilePrefix_metadata.xml and outputFilePrefix_ properties.txt.
3.
Copy the files to the production system.
4.
On the production environment, import the partner metadata and configuration properties by running the following script:
java weblogic.WLST setPartnerMetadataAndProperties.py outputFilePrefix_ metadata.xml
outputFilePrefix_properties.txt description
5.
If you have removed a partner from the test environment, remove it from the production environment, as described in Delete Trusted Providers in the Oracle
Fusion Middleware Administrators Guide for Oracle Identity Federation
6.
If you made any other configuration changes in the test environment that you want to replicate in the production environment, make those changes. See the
Oracle Fusion Middleware Administrators Guide for Oracle Identity Federation for more information.
Task 5 Move Oracle Adaptive Access Manager to an Existing Production Environment
To move Oracle Adaptive Access Manager to an existing production environment:
1.
Export the necessary delta data from the test environment to one or more zip files. You can export the following types of items: policies, rule conditions, patterns,
configurable actions, transactions, entities, KBA questions, KBA validations, all group types including alert and action groups, and black list and white list groups
used in rules. See Step 1 in
Task 8, Move Oracle Adaptive Access Manager to a New Production Environment
in Section 21.4.1.1
.
2.
Import the zip files created in Step 1 in the production environment. See Step 2 in Task 8, Move Oracle Adaptive Access Manager to a New Production
Environment in
Section 21.4.1.1 .
3.
Manually update the production environment for the following items, when necessary:
a.
Because snapshot export and import only copies action and alert group types, you must export the group members from the test environment and import
them into the production environment.
To export the groups, see Exporting a Group in the Oracle Fusion Middleware Administrators Guide for Oracle Adaptive Access Manager.
To import the groups into the production environment, see Importing a Group in the Oracle Fusion Middleware Administrators Guide for Oracle Adaptive
Access Manager.
b.
Use the oaam_extensions shared library to package the configurable actions jar.
c.
Manually copy any items customized in the OAAM server, such as headers, footers, cascading style sheets CSS, and JavaScript, from the test
environment to production environment. These items are located in the oaam_ extensions shared library.
d.
Manually re-create the KBA logic, OTP logic, and policy set overrides using the Oracle Adaptive Access Manager Admin Console. See the Oracle Fusion
Middleware Administrators Guide for Oracle Adaptive Access Manager.
21-30 Oracle Fusion Middleware Administrators Guide
e.
Copy the following from the test environment to the production environment: properties files, resource bundles, and end user JSP screens. These items are
located in the oaam_extensions shared library.
f.
Copy the VAD images, which are in a custom jar, from the test environment to the production environment.
g.
Copy the following from the test environment to the production environment: properties files, resource bundles, VAD images, and end user JSP screens.
4.
Validate that the move was successful:
a.
Login to OAAM Admin console, as described in OAAM Admin Console and Controls in the Oracle Fusion Middleware Administrators Guide for Oracle
Adaptive Access Manager.
b.
Navigate to Policies and check the existing group linking and check that newly added rules and groups from the test environment exist in the
production environment.
c.
Navigate to the KBA module and check that newly added challenge questions in the test environment exist in the production environment.
d.
Test the Web applications that have been configured for Oracle Adaptive Access Manager. The user should be redirected to registration and challenge
flow. The behavior should be the same as in the test environment.
Task 6 Move Oracle Identity Manager to an Existing Production Environment To move Oracle Identity Manager to an existing production environment, follow the
steps described in Section 21.4.1.1
, Task 10, Move Oracle Identity Manager to a New
Production Environment .
Task 7 Move Oracle Identity Navigator to an Existing Production Environment To move Oracle Identity Navigator to an existing production environment, perform
the tasks described in Managing Oracle Identity Navigator in the Oracle Fusion Middleware Administrators Guide for Oracle Identity Navigator. Note that you do not
need to configure the identity store and policy store if they have already been configured.
Task 8 Move Oracle Platform Security to an Existing Production Environment
You must move all of the Oracle Platform Security policy and credential store information from the test environment to an existing production environment:
1.
If the policy store on the test environment is not file-based, migrate the policy store, using the WLST command migrateSecurityStore, as described in
Migrating Policies with the Command migrateSecurityStore in the Oracle Fusion Middleware Application Security Guide.
2.
If the credential store on the test environment is not file-based, migrate the credential store, using the WLST command migrateSecurityStore, as
described in Migrating Credentials with the Command migrateSecurityStore in the Oracle Fusion Middleware Application Security Guide.
3.
Users and groups in the production LDAP may differ from that in the LDAP. There is a mapping between Oracle Platform Security application roles and LDAP
roles. While the application roles may remain the same, the mapping to LDAP groups can be changed to map to the corresponding LDAP group in the
production environment. See Managing Application Roles in the Oracle Fusion Middleware Application Security Guide.
Moving from a Test to a Production Environment 21-31
4.
If you are using Oracle Web Services Manager, migrate audit policies, as described in Migrating Audit Policies in the Oracle Fusion Middleware Application Security
Guide.
Task 9 Move Oracle Web Services Manager to an Existing Production Environment
To move Oracle Web Services Manager to an existing production environment:
1.
Move policies for SOA Composite applications, WebCenter, or ADF applications, which are stored in the MDS Repository.
To do so using Fusion Middleware Control:
a.
On the test environment, select the domain. Then, from the WebLogic Domain menu, choose Web Services, then Policies.
b.
Select a policy, then click Export to File.
The policy is copied to a file on the test environment.
c.
Click Save File, then OK.
d.
Navigate to the location on your local directory to which you want to save the file and update the file name as desired. Click Save.
e.
Copy the file to the production environment.
f.
On the production environment, select the domain. Then, from the WebLogic Domain menu, choose Web Services, then Policies.
g.
Click Import from File. Browse to the file and click OK.
h.
On test environment, select the domain. Then, from the WebLogic Domain menu, choose Web Services, then Policies.
i.
Click Web Services Assertion Templates in the upper right corner of the page.
j.
Click Export to File.
k.
Click Save File, then OK.
l.
Navigate to the location on your local directory to which you want to save the file and update the filename as desired. Click Save.
m.
On the production environment, select the domain. Then, from the WebLogic Domain menu, choose Web Services, then Policies.
n.
Click Import from File. Browse to the file and click OK.
o.
Click Web Services Assertion Templates in the upper right corner of the page.
p.
Click Import from File. Browse to the file and click OK.
To move policies using WLST:
a.
From the test environment, execute the following WLST commands:
exportMetadataapplication=wsm-pm,server=server_name, docs=assertiontemplatesassert_template_name,
toLocation=tmpowsmexport exportMetadataapplication=wsm-pm,server=server_name,
docs=policiespolicy_name,toLocation=tmpowsmexport
21-32 Oracle Fusion Middleware Administrators Guide
b.
Copy the tmpowsmexport directory from the test environment to the production environment.
c.
In the production environment, execute the following WLST commands:
importMetadataapplication=wsm-pm,server=server_name, docs=assertiontemplatesassert_template_name,
fromLocation=tmpowsmexport importMetadataapplication=wsm-pm,server=server_name,
docs=policiespolicy_name,fromLocation=tmpowsmexport
d.
If you have custom-built policies, move those by copying the jar files from the test to the production environment. The jar files are located in the following
directory:
DOMAIN_HOMElib
2.
Oracle WebLogic Server JAX-WS applications use policies stored in wsm-seed-policies.jar instead of in MDS. Move these policies by copying the
following file from the test environment to the production environment:
ORACLE_HOMEmodulesoracle.wsm.policies_11.1.1wsm-seed-policies.jar
You can also use the Oracle WebLogic Server Administration Console to move these policies.
3.
Move any policy attachments for a SOA, ADF, or WebCenter application if they have changed since the application was first deployed in the production
environment. For example, policy A was initially configured in the test environment with the BASIC 128 algorithm and attached to the HelloWorld
application. The application was deployed to the production environment. Then, on the test environment, you changed policy A to use the Basic 129 algorithm.
4.
Move any policy attachments for a JAX-WS application if they have changed since the application was first deployed.
21.4.2 Moving Oracle SOA Suite to a Production Environment
The following topics describe how to move Oracle SOA Suite from a test environment to a production environment:
■
Moving Oracle SOA Suite to a New Production Environment
■
Moving Oracle SOA Suite to an Existing Production Environment In both scenarios, you have performed the following in a test environment:
■
Installed Oracle WebLogic Server and created the Middleware home.
■
Created the required schemas in the test database using RCU.
■
Installed Oracle SOA Suite.
■
Configured Oracle SOA Suite using the Configuration Wizard.
■
If required for your environment, installed and configured Identity Management components, such as Oracle Internet Directory, Oracle Platform Security, and
Oracle Web Services Manager.
■
Configured security policies.
See Also: Managing Horizontal Policy Migration in the Oracle
Fusion Middleware Security and Administrators Guide for Web Services
Moving from a Test to a Production Environment 21-33
■
Deployed one or more applications or SOA Composite applications. The applications have internal and external references.
■
Changed some configuration settings. For example, you may have changed something in the config directory, in MDS, or another data source.
■
Optionally, configured Oracle WebLogic Server dependent artifacts for Oracle Business Activity Monitoring, such as:
– BAM Adapter
– Data sources for the database or JMS
■
Configured and populated the identity store for Oracle Business Activity Monitoring users.
■
Set up UMS and all required subcomponents, configured UMS drivers and user preferences in a test environment.
21.4.2.1 Moving Oracle SOA Suite to a New Production Environment
To move Oracle SOA Suite to a new production environment, perform the following tasks:
■
Task 1, Move the Database, Middleware Home and Perform the Initial Configuration
■
Task 3, Export JKS Certificates
■
Task 4, Move Human Workflow to the New Production Environment
■
Task 5, Move Oracle Business Activity Monitoring Data to the New Production Environment
■
Task 6, Move Oracle Business Process Management to the New Production Environment
■
Task 7, Move UMS-Related Details to the New Production Environment
■
Task 8, Enable SSL and Create Custom Keystores
Task 1 Move the Database, Middleware Home and Perform the Initial Configuration
To move the database and Middleware home and perform the initial configuration:
1.
Move or create the database and the schemas, as described in Section 21.3.2
.
2.
Move Identity Management components, as described in Section 21.4.1
.
Note:
The Oracle User Messaging Service UMS is used in SOA and BAM scenarios. The functionality and actions in both scenarios are
similar, but there are small differences. In particular, for BAM, only the e-mail driver is supported, so the reconfiguration steps for UMS
only apply to the e-mail driver. Also, BAM does not make use of the UMS User Preferences in this release. Hence, the userprefs migration
in UMS migration does not apply to BAM. See
Task 7 for details on
moving UMS from a test to a production environment.
See Also:
Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite for information about setting up an enterprise
deployment for Oracle SOA Suite
