1. Securing Applications with Oracle Platform Security Services
  2. Basic OPSS Administration
  3. Deploying Secure Applications

6 Deploying Secure Applications

You typically deploy applications to Oracle WebLogic Server with Oracle WebLogic Remote Console or Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control). You can also start an application without restarting the server by setting its bits in a location known to WebLogic Server. This application start is known as hot deployment.

The recommendations in this chapter apply to Jakarta EE applications using OPSS.

This chapter includes the following sections:

See also:

Deploying Applications in Administering Oracle Fusion Middleware

Developing Fusion Web Applications with Oracle Application Development Framework

Securing Oracle ADF Applications

Configuring Jakarta EE Applications to Use OPSS

Parent topic: Basic OPSS Administration

Developing Oracle ADF Applications

When developing an Oracle Application Development Framework (Oracle ADF) application you:

  • Use JDeveloper to develop the application and Oracle ADF Wizard to configure security for the application.

  • Use JDeveloper to copy the application users, roles, policies, and credentials to the integrated WebLogic Server, into which you deploy the application during the test cycles.

  • Create the application Enterprise ARchive (EAR) file that packs application policies and credentials.

  • Deploy the EAR file to WebLogic Server using Fusion Middleware Control.

Figure 6-1 illustrates the workflow for developing an Oracle ADF application.

Figure 6-1 WorkFlow for Developing an Oracle ADF Application

Description of Figure 6-1 follows
Description of "Figure 6-1 WorkFlow for Developing an Oracle ADF Application"

During development, you deploy your application with Oracle JDeveloper to the embedded WebLogic Server. After the application transitions to test or production environments, you deploy it with Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control), Oracle WebLogic Remote Console, or by a hot deployment.

The recommended way to deploy an application depends on the platform, the application type, and whether the application is in the developing phase or in a post-development phase.

See also:

Deploying Secure Applications with Fusion Middleware Control

Parent topic: Deploying Secure Applications

Choosing the Tool for Deployment

Table 6-1 lists the tools you use to deploy Jakarta EE applications.

Table 6-1 Tools to Deploy Jakarta EE Applications

Jakarta EE Application Use

Non-Oracle ADF

Oracle WebLogic Remote Console, Fusion Middleware Control. The recommended tool is Oracle WebLogic Remote Console.

Oracle ADF

Fusion Middleware Control or WebLogic Scripting Tool (WLST). The recommended tool is Fusion Middleware Control.

See also:

Deploying Secure Applications with Fusion Middleware Control

Parent topic: Deploying Secure Applications

Deploying Secure Applications with Fusion Middleware Control

This section describes the security configurations available when you deploy a Jakarta EE application that uses OPSS with Fusion Middleware Control.

The content displayed on the Configure Application Security page varies according to what is packaged in the EAR file:

  • If the EAR file packages jazn-data.xml with application policies, then the page displays the policy migration section.

  • If the EAR file packages credentials in the cwallet.sso file, then the page displays the credential migration section.

  • If the EAR file does not include any of these files, then the page displays the default Jakarta EE security options.

The settings in this page control the migration of application policies and credentials (packed in application EAR file) to the security store.

Parent topic: Choosing the Tool for Deployment

Migrating Application Policies at Deployment

To migrate the packed application policies at deployment, deploy the application to just one WebLogic Server. If you deploy an application with packed policies to multiple Managed Servers, then your deployment must include the Administration Server, so that the domain system-jazn-data.xml file is updated with the packed policies.

  • If you are deploying the application for the first time, then you want to migrate application policies to the security store, so choose Append in the Application Policy Migration area.

    If for some reason you do not want the migration to take place, then choose Ignore. The option Overwrite is also supported.

  • If you are redeploying the application and assuming that the migration of application policies has taken place in a previous deployment, then choose Append to merge the packed policies with the ones in the domain, or Ignore to prevent policy migration.

    The option Ignore is chosen when redeploying an application or when you want to preserve changes made to the security store during previous deployments.

  • If you choose Append, then specify which grants and roles should be migrated. The basic distinction is between Oracle ADF application roles and grants and development-time only roles and grants.

    To migrate Oracle ADF application roles and grants, and not to migrate development-time only security roles and grants, check Migrate only application roles and grants. Ignore identity store artifacts. Check it when you are deploying to a production environment. Note that you must map application roles to enterprise groups after the application deployment.

  • When you choose Append, then specify a particular stripe (different from the default stripe, which is the application name) into which the application policies are migrated, by entering the name of that stripe in the text field Application Stripe ID.

  • If nothing is specified, then the default settings are Append (in deployments) and Ignore (in redeployments).

Migrating Application Credentials at Deployment

  • If you are deploying the application for the first time, then you want to migrate application credentials to the credential store. Therefore, choose Append in the Application Credential Migration area.

  • Choose Ignore (default value) to prevent credential migration.

    Note:

    Application code using credentials may not work if you ignore credential migration. Choose Ignore when the credentials were created with the same map and key, but with different values.

  • Overwrite is supported only when WebLogic Server is running in development mode.

Deploying Oracle ADF Applications to a New Environment

When an Oracle ADF application transitions to a test or production environment, you typically deploy it with Fusion Middleware Control to leverage all ADF security features that the framework offers.

The following sections explain the tasks involved when the application transitions to a new environment.

Parent topic: Deploying Secure Applications

Deploying to a Test Environment

Before deploying an application that uses a file security store, verify that grants contains no duplicate permissions. If a duplicate permission (one that has the same name and class) appears in a grant, then the migration reports and error and halts. To resolve, edit the jazn-data.xml file and remove duplicated permissions.

When you deploy an Oracle ADF application with Fusion Middleware Control, the following processes take place:

  • Application policies packed with the application are automatically migrated to the security store.

  • Application credentials packed with the application are automatically migrated to the credential store.

  • The bootstrap credentials needed to access LDAP repositories during migration are created.

Identities packed with the application are not migrated. You must configure an authentication provider (with Oracle WebLogic Remote Console), update identities, as appropriate, and map application roles to enterprise users and groups (with Fusion Middleware Control).

When you deploy to a domain with LDAP security stores and want to preserve application data integrity, Oracle recommends that you deploy the application at the cluster level or to just one Managed Server.

When you deploy an application to multiple Managed Servers, include the Administration Server so that data is migrated as expected.

See also:

Typical Administrative Tasks After Deployment

Parent topic: Deploying Oracle ADF Applications to a New Environment

Typical Administrative Tasks After Deployment

After deploying the application, use Fusion Middleware Control or Oracle WebLogic Remote Console to:

  • Manage security providers

  • Create and customize application policies

  • Create and customize application roles

  • Manage system policies

  • Manage credentials

  • Manage keystores

  • Manage audit data

When you undeploy an application with Fusion Middleware Control from a server running in production mode, the application policies are removed from the security store. If you use any other tool to undeploy the application, then those policies must be removed manually.

Credentials are not deleted when you undeploy the application.

See also:

Configuring Security Providers with Fusion Middleware Control

Managing Application Policies

Managing Application Roles

Managing System Policies

Managing Credentials with Fusion Middleware Control

Managing Keystores with Fusion Middleware Control

Managing the Audit Store

Deploying Standard Jakarta EE Applications

There are two ways to secure Jakarta EE applications that do not use OPSS but that use standard Java authorization: administratively, with Oracle WebLogic Remote Console or WLST commands, or programmatically, with deployment descriptors.

A Jakarta EE application deployed to WebLogic Server is a WebLogic resource, so you set security for the application the same way that you do for any other WebLogic resource.

See also:

Securing Resources Using Roles and Policies for Oracle WebLogic Server

Oracle WebLogic Remote Console Online Help:

Securing WebLogic Web Services for Oracle WebLogic Server:

Developing Applications with the WebLogic Security Service:

Parent topic: Deploying Secure Applications

Deploying Audit-Aware Applications

Audit-aware components refer to components integrated with Oracle Fusion Middleware Audit Framework, whose audit policies can be configured and whose events can be audited.

To use of this framework, you must register the application at deployment.

Registration

Configure audit registration parameters in the OPSS deployment descriptor file packaged with the application EAR file. Files are processed automatically by audit registration when you deploy the application.

Packaging Requirements

Package the following configuration files with the application EAR file:

  • The event definitions file describing the auditable events for the application

  • Translation files containing localizable elements

See also:

Migrating Audit Data

Creating Audit Definition Files

Registering the Application with the Audit Service

Introduction to Oracle Fusion Middleware Audit Framework

Parent topic: Deploying Secure Applications

Migrating from a Test to a Production Environment

The recommendations that follow apply to Jakarta EE applications that use Java Authorization and Authentication Services (JAAS) authorization, such as Oracle ADF, service-oriented architecture (SOA) applications, and Oracle WebCenter applications, and they do not apply to Jakarta EE applications that use standard authorization.

The recommended tool to deploy applications is Fusion Middleware Control, and the user must have the appropriate permissions, including the permission to seed a schema in an LDAP repository.

File security stores are not recommended in production environments.

Migrating to a production environment includes:

Parent topic: Deploying Secure Applications

Migrating Identities

The configuration of authentication providers in the test environment must be duplicated in the production environment. This task may include:

  • Using Oracle WebLogic Remote Console to configure authentication providers and to provision users and groups.

  • Setting in the production environment any particular provider configuration used in the test environment.

Parent topic: Migrating from a Test to a Production Environment

Migrating Identities with migrateSecurityStore

You migrate identity data from a source repository to a target repository with the migrateSecurityStore WLST command, for example, when moving from a test environment that uses a file identity store to a production environment that uses an LDAP identity store.

The command does not require a connection to a running server to operate. The configuration file you pass to the configFile argument need not be an actual domain configuration file, but it only specifies the source and target repositories of the migration.

To migrate identities, use one of the following: 

migrateSecurityStore -type idStore
                     -configFile jpsConfigFileLocation
                     -src srcJpsContext
                     -dst dstJpsContext
                     [-dstLdifFile LdifFileLocation]
                     [-overwrite trueOrfalse]

migrateSecurityStore(type="idStore", 
                     configFile="jpsConfigFileLocation", 
                     src="srcJpsContext", 
                     dst="dstJpsContext", 
                     [dstLdifFile="LdifFileLocation"]
                     [,overwrite="trueOrfalse"])

where:

  • configFile specifies the relative or absolute path of the jps-config.xml configuration file.

  • src specifies the name of a context in the configuration file passed to the configFile argument, where the source store is specified. The embedded LDAP server cannot be the source store.

  • dst specifies the name of another context in the configuration file passed to the configFile argument where the target store is specified. The target store must be LDAP. For list of supported types, see Identity Store Types and WebLogic Server Authentication Providers.

  • dstLdifFile specifies the relative or absolute path to the LDAP Data Interchange format (LDIF) file created. Applies only when the target store is LDAP. Notice that the LDIF file is not imported into the LDAP server and requires manual editing.

  • overwrite specifies whether to overwrite data in the target store. Set to true to overwrite target data. Set to false not to overwrite target data. Optional. If unspecified, it defaults to false.

The contexts passed to src and dst must be defined in the configuration file and have distinct names. From these two contexts, the command determines the locations of the source and the target repositories involved in the migration.

The passwords in the generated LDIF file are all set to the string weblogic, and in case the target is LDAP, they are set to the string change. Before importing the LDIF file into the target LDAP store, change these passwords to real ones.

Parent topic: Migrating Identities

Migrating Policies and Credentials

In a production environment, it is strongly recommended that you reassociate the security store to an LDAP or DB store.

This section explains how to migrate policies and credentials when you deploy the application. For information about migrating security data after deployment, see Migrating Policies with migrateSecurityStore and Migrating Credentials with migrateSecurityStore.

If the application is hot deployed, then the migration of data in the jazn-data.xml file to the security store is carried out provided the security store does not contain a stripe with the same name as the application. In particular, if the application is hot redeployed, then any changes introduced in the jazn-data.xml file are not migrated to the security store.

To disable migrating policies and credentials for all applications deployed on a WebLogic Server (regardless of the application migration particular settings), set the jps.deployment.handler.disabled system property to true.

To preserve GUIDs during migration, set the jps.approle.preserveguid parameter.

When you transition an application from a test to a production environment, it is critical that you know the answer to the following question:

Have policies or credentials packed in the application EAR file been modified in the test environment?

Then, to deploy an application to a production environment:

  1. Use Fusion Middleware Control to deploy the application EAR file to the production environment with the following options:

    • If policies (application or system) have been modified in the test environment, then disable the option to migrate policies at deployment by choosing Ignore under the Application Policy Migration area in Fusion Middleware Control's page Configuration Application Security. Otherwise, choose Append.

      You can choose both Append and check Migrate only application roles and grants. Ignore identity store artifacts, even when the mapping of application roles have been modified in the test environment. Note that choosing this combination migrates application policies but disregards the maps to test enterprise groups. Later on, you must remap application roles to production enterprise groups.

    • If credentials have been modified in the test environment, then disable the option to migrate credentials at deployment by choosing the option Ignore under the Application Credential Migration area in Fusion Middleware Control's page Configuration Application Security. Otherwise, choose Append.

  2. Use the migrateSecurityStore command to migrate modified data:

    • If you chose to Ignore application policy migration, then migrate application and system policies from the test to the production LDAP. For information about the procedure, see the example in Migrating Policies with migrateSecurityStore.

    • If you chose to Ignore application credential migration, then migrate credentials from the test to the production LDAP. For information about the procedure, see the example in Migrating Credentials with migrateSecurityStore.

  3. Use Fusion Middleware Control to map application roles to production enterprise groups, as appropriate.
  4. Use Fusion Middleware Control to verify that administrative credentials in the production environment are valid, in particular, test passwords versus production passwords. If it is necessary, then modify the production data, as appropriate.

Parent topic: Migrating from a Test to a Production Environment

Migrating Policies with migrateSecurityStore

By default, the migrateSecurityStore command re-creates GUIDs and it may take a long time to migrate a large number of policies. Therefore, when moving from a test to a production environment, consider migrating policies and credentials with an alternate procedure that uses bulk operations. For information about security store backup, see Backing Up and Recovering LDAP Security Stores.

To migrate policies with migrateSecurityStore, assemble a configuration file where the source and target are specified.

Here is a complete example of a configuration file, named t2p-policies.xml, illustrating the specification of policy sources in LDAP, database, and file repositories, and of policy targets in LDAP and DB repositories: 

<?xml version="1.0" encoding="UTF-8" standalone='yes'?>
<jpsConfig xmlns="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" schema-major-version="11" schema-minor-version="1">
 
<serviceProviders>
  <serviceProvider class="oracle.security.jps.internal.policystore.xml.XmlPolicyStoreProvider" name="policystore.xml.provider" type="POLICY_STORE">
 <description>XML-based policy store provider</description>
 </serviceProvider>
         
 <serviceProvider class="oracle.security.jps.internal.policystore.ldap.LdapPolicyStoreProvider" name="ldap.policystore.provider" type="POLICY_STORE">
 <property value="OID" name="policystore.type"/>
 <description>LDAP policy store provider</description>
 </serviceProvider>

 <serviceProvider class="oracle.security.jps.internal.policystore.ldap.LdapPolicyStoreProvider" name="db.policystore.provider" type="POLICY_STORE">
 <property value="DB_ORACLE" name="policystore.type"/>
 <description>DB policy store provider</description>
 </serviceProvider>
</serviceProviders>
 
<serviceInstances>
 <!-- Source XML-based policy store instance -->
 <serviceInstance location="./system-jazn-data.xml" provider="policystore.xml.provider" name="policystore.xml.source">
 <description>Replace location with the full path of the folder where the system-jazn-data.xml is located in the source file system </description>
 </serviceInstance>
 
<!-- Source LDAP policy store instance -->
<serviceInstance provider="ldap.policystore.provider" name="policystore.ldap.source">
 <description>Replace: A. mySourceDomain and mySourceRootName to appropriate
   values according to your source LDAP directory structure; B. OID with OVD, 
   if your source LDAP is OVD; C. ldap://mySourceHost.com:3060 with the URL 
   and port number of your source LDAP</description>
 <property value="OID" name="policystore.type"/>
 <property value="bootstrap" name="bootstrap.security.principal.key"/>
 <property value="cn=mySourceDomain" name="oracle.security.jps.farm.name"/>
 <property value="cn=mySourceRootName" name="oracle.security.jps.ldap.root.name"/>
 <property value="ldap://mySourceHost.com:3060" name="ldap.url"/>
</serviceInstance>
 
<!-- Source DB policy store instance -->
<serviceInstance provider="db.policystore.provider" name="policystore.db.source">
 <description>Replace: mySourceDomain and mySourceRootName to appropriate
   values according to your source DB policy store structure
 </description>
 <property value="DB_ORACLE" name="policystore.type"/>
 <property value="cn=mySourceDomain" name="oracle.security.jps.farm.name"/>
 <property value="cn=mySourceRootName" name="oracle.security.jps.ldap.root.name"/>
 <property value="jdbc:oracle:thin:@mySourceHost.com:1722:orcl" name="jdbc.url"/>
 <!-- the value of jdbc.url should be the value entered when the source 
      datasource was set up -->
 <property value="oracle.jdbc.driver.OracleDriver" name="jdbc.driver"/>
 <property name="bootstrap.security.principal.key" value="mySourceKeyName" />
 <property name="bootstrap.security.principal.map" value="mySourceMapName" />
 <!-- the values of bootstrap.security.principal.key and
      bootstratp.security.principal.map
      should be the values entered when the bootstrap credential was set up -->
</serviceInstance>

 <!-- target LDAP policy store instance -->
 <serviceInstance provider="ldap.policystore.provider" name="policystore.ldap.target">
<description>Replace: A. myDestDomain and myDestRootName to appropriate values according to your target LDAP directory structure; B. OID with OVD, if your target LDAP is OVD; C. ldap://myDestHost.com:3060 with the URL and port number of your target LDAP</description>
 <property value="OID" name="policystore.type"/>
 <property value="bootstrap" name="bootstrap.security.principal.key"/>
 <property value="cn=myDestDomain" name="oracle.security.jps.farm.name"/>
 <property value="cn=myDestRootName" name="oracle.security.jps.ldap.root.name"/>
 <property value="ldap://myDestHost.com:3060" name="ldap.url"/>
</serviceInstance>
 
<!-- target DB policy store instance -->
 <serviceInstance provider="db.policystore.provider" name="policystore.db.target">
<description>Replace: myDestDomain and myDestRootName to appropriate values
 according to your target DB policy store structure</description>
 <property value="DB_ORACLE" name="policystore.type"/>
 <property value="cn=myDestDomain" name="oracle.security.jps.farm.name"/>
 <property value="cn=myDestRootName" name="oracle.security.jps.ldap.root.name"/>
 <property value="jdbc:oracle:thin:@myDestHostcom:1722:orcl" name="jdbc.url"/>
 <!-- the value of jdbc.url should be the value entered when the target datasource was set up -->
 <property value="oracle.jdbc.driver.OracleDriver" name="jdbc.driver"/>
 <property name="bootstrap.security.principal.key" value="myDestKeyName" />
 <property name="bootstrap.security.principal.map" value="myDestMapName" />
 <!-- the value of bootstrap.security.principal.key and
      bootstratp.security.principal.map
      should be the value entered when the bootstrap credential was set up -->
</serviceInstance>

<!-- Bootstrap credentials to access source and target LDAPs or DBs-->
 <serviceInstance location="./bootstrap" provider="credstoressp" name="bootstrap.credstore">
  <description>Replace location with the full path of the directory where the cwallet.sso file is located; typically found in targetDomain/config/fmwconfig/</description>
 </serviceInstance>
 </serviceInstances>

 <jpsContexts>
 <jpsContext name="XMLsourceContext">
 <serviceInstanceRef ref="policystore.xml.source"/>
 </jpsContext>

 <jpsContext name="LDAPsourceContext">
 <serviceInstanceRef ref="policystore.ldap.source"/>
 </jpsContext>

<jpsContext name="DBsourceContext">
 <serviceInstanceRef ref="policystore.db.source"/>
 </jpsContext>

 <jpsContext name="LDAPtargetContext">
 <serviceInstanceRef ref="policystore.ldap.target"/>
 </jpsContext>
 
<jpsContext name="DBtargetContext">
 <serviceInstanceRef ref="policystore.db.target"/>
 </jpsContext>

 <!-- Do not change the name of the next context -->
 <jpsContext name="bootstrap_credstore_context">
 <serviceInstanceRef ref="bootstrap.credstore"/>
 </jpsContext>
 </jpsContexts>
</jpsConfig>

Note that because the migration involves LDAP and DB stores, the file includes a context named bootstrap_credstore_context that specifies the directory where the cwallet.sso bootstrap credential file is located. Furthermore, for each pair of map name and key name in the example, you must provide the corresponding bootstrap credentials with the addBootStrapCredential WLST command: 

wls:/offline> addBootStrapCredential(jpsConfigFile='jps-config.xml',
 map='myMapName', key='myKeyName', username='UserName',
 password='Password')

where UserName and Password specify the user account name and password to access the target database.

Examples for Migrating Policies with migrateSecurityStore

The following examples of use of migrateSecurityStore assume that:

  • The t2p-policies.xml file is located on the target system in the directory where the command is run.

  • The directory structure of LDAP or DB system policies in the test and production environments should be identical. If this is not the case, then before using the command, restructure manually the system policy directory in the production environment to match the corresponding structure in the test environment.

To migrate policies from a test (or source) LDAP store to a production (or target) LDAP store, call migrateSecurityStore in the target system: 

>migrateSecurityStore(type="policyStore",
                      configFile="t2p-policies.xml",
                      src="LDAPsourceContext",
                      dst="LDAPtargetContext")

To migrate policies from a test (or source) file store to a production (or target) LDAP store, call migrateSecurityStore in the target system: 

>migrateSecurityStore(type="policyStore",
                      configFile="t2p-policies.xml",
                      src="XMLsourceContext",
                      dst="LDAPtargetContext")

To migrate policies from a test (or source) DB store to a production (or target) DB store, call migrateSecurityStore in the target system: 

>migrateSecurityStore(type="policyStore",
                      configFile="t2p-policies.xml",
                      src="DBsourceContext",
                      dst="DBtargetContext")
Migrating Credentials with migrateSecurityStore

The migrateSecurityStore command re-creates GUIDs and it may take a long time to migrate a large number of credentials. Therefore, when moving from a test to a production environment, consider migrating policies and credentials with an alternate procedure that uses bulk operations. For information about store backup, see Backing Up and Recovering LDAP Security Stores.

To migrate credentials with migrateSecurityStore, assemble a configuration file where the source and target are specified.

Here is a complete example of a configuration file, named t2p-credentials.xml, illustrating the specification of credential sources in LDAP, DB, and file repositories, and of credential targets in LDAP and DB repositories: 

<?xml version="1.0" encoding="UTF-8" standalone='yes'?>
<jpsConfig xmlns="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" schema-major-version="11" schema-minor-version="1">
 
<serviceProviders>
 <serviceProvider class="oracle.security.jps.internal.credstore.ssp.SspCredentialStoreProvider" name="credstoressp" type="CREDENTIAL_STORE">
 <description>File credential provider</description>
 </serviceProvider>
 
 <serviceProvider class="oracle.security.jps.internal.credstore.ldap.LdapCredentialStoreProvider" name="ldap.credentialstore.provider" type="CREDENTIAL_STORE">
 <description>LDAP credential provider</description>
 </serviceProvider>

<serviceProvider class="oracle.security.jps.internal.credstore.rdbms.DbmsCredentialStoreProvider" name="db.credentialstore.provider" type="CREDENTIAL_STORE">
 <description>DB credential provider</description>
 </serviceProvider>

</serviceProviders>
 
<serviceInstances>
 <!-- Source file credential store instance -->
 <serviceInstance location="myFileBasedCredStoreLocation" provider="credstoressp" name="credential.file.source">
 <description>Replace location with the full path of the folder where the file source credential store cwallet.sso is located in the source file system; typically located in sourceDomain/config/fmwconfig/</description>
 </serviceInstance>
 
<!-- Source LDAP credential store instance -->
<serviceInstance provider="ldap.credentialstore.provider" name="credential.ldap.source">
 <description>Replace: A. mySourceDomain and mySourceRootName to appropriate
 values according to your source LDAP directory structure; B. ldap://mySourceHost.com:3060 with the URL and port number of your source LDAP</description>
 <property value="bootstrap" name="bootstrap.security.credential.key"/>
 <property value="cn=mySourceDomain" name="oracle.security.jps.farm.name"/>
 <property value="cn=mySourceRootName" name="oracle.security.jps.ldap.root.name"/>
 <property value="ldap://mySourceHost.com:3060" name="ldap.url"/>
</serviceInstance>
 

<!-- Source DB credential store instance -->
<serviceInstance provider="db.credentialstore.provider" name="credential.db.source">
 <description>Replace: A. mySourceDomain and mySourceRootName to appropriate
 values according to your source DB credential store</description>
 <property value="cn=mySourceDomain" name="oracle.security.jps.farm.name"/>
 <property value="cn=mySourceRootName" name="oracle.security.jps.ldap.root.name"/>
 <property value="jdbc:oracle:thin:@mySourceHost:1722:orcl" name="jdbc.url"/>
 <!-- the value of jdbc.url should be the value entered when the source datasource was set up -->
 <property value="oracle.jdbc.driver.OracleDriver" name="jdbc.driver"/>
 <property name="bootstrap.security.principal.key" value="mySourceKeyName" />
 <property name="bootstrap.security.principal.map" value="mySourceMapName" />
 <!-- the values of bootstrap.security.principal.key and
      bootstratp.security.principal.map
      should be the values entered when the bootstrap credential was set up -->
</serviceInstance>

 <!-- target LDAP credential store instance -->
 <serviceInstance provider="ldap.credentialstore.provider" name="credential.ldap.target">
<description>Replace: A. myDestDomain and myDestRootName to appropriate values according to your target LDAP directory structure; B. ldap://myDestHost.com:3060 with the URL and port number of your target LDAP</description>
 <property value="bootstrap" name="bootstrap.security.credential.key"/>
 <property value="cn=myDestDomain" name="oracle.security.jps.farm.name"/>
 <property value="cn=myDestRootName" name="oracle.security.jps.ldap.root.name"/>
 <property value="ldap://myDestHost.com:3060" name="ldap.url"/>
</serviceInstance>
 
<!-- target DB credential store instance -->
 <serviceInstance provider="db.credentialstore.provider" name="credential.db.target">
<description>Replace: myDestDomain and myDestRootName to appropriate values according to your target DB credential store</description>
 <property value="cn=myDestDomain" name="oracle.security.jps.farm.name"/>
 <property value="cn=myDestRootName" name="oracle.security.jps.ldap.root.name"/>
 <property value="jdbc:oracle:thin:@myDestHost.com:1722:orcl" name="jdbc.url"/>
 <!-- the value of jdbc.url should be the value entered when the target datasource was set up -->
 <property value="oracle.jdbc.driver.OracleDriver" name="jdbc.driver"/>
 <property name="bootstrap.security.principal.key" value="myDestKeyName" />
 <property name="bootstrap.security.principal.map" value="myDestMapName" />
 <!-- the values of bootstrap.security.principal.key and
      bootstratp.security.principal.map
      should be the values entered when the bootstrap credential was set up -->
</serviceInstance>

<!-- Bootstrap credentials to access source and target LDAPs and DBs -->
 <serviceInstance location="./bootstrap" provider="credstoressp" name="bootstrap.credstore">
 <description>Replace location with the full path of the directory where the bootstrap file cwallet.sso is located; typically found in targetDomain/config/fmwconfig/</description>
 </serviceInstance>
 </serviceInstances>

 <jpsContexts>
 <jpsContext name="FileSourceContext">
 <serviceInstanceRef ref="credential.file.source"/>
 </jpsContext>

 <jpsContext name="LDAPsourceContext">
 <serviceInstanceRef ref="credential.ldap.source"/>
 </jpsContext>

<jpsContext name="DBsourceContext">
 <serviceInstanceRef ref="credential.db.source"/>
 </jpsContext>

 <jpsContext name="LDAPtargetContext">
 <serviceInstanceRef ref="credential.ldap.target"/>
 </jpsContext>
 
<jpsContext name="DBtargetContext">
 <serviceInstanceRef ref="credential.db.target"/>
 </jpsContext>

 <!-- Do not change the name of the next context -->
 <jpsContext name="bootstrap_credstore_context">
 <serviceInstanceRef ref="bootstrap.credstore"/>
 </jpsContext>
 </jpsContexts>
</jpsConfig>

For command syntax in this scenario, see Migrating One Credential Map with migrateSecurityStore Across Domains.

Note that because the migration involves LDAP or DB stores, the file includes a context named bootstrap_credstore_context that specifies the directory where the cwallet.sso bootstrap credential file is located.

Examples for Migrating Credentials with migrateSecurityStore

The following examples of use of migrateSecurityStore assume that the t2p-credentials.xml file is located on the target system in the directory where the command is run.

To migrate credentials from a test (or source) LDAP store to a production (or target) LDAP store, call migrateSecurityStore in the target system: 

>migrateSecurityStore(type="credStore",
                      configFile="t2p-credentials.xml",
                      src="LDAPsourceContext",
                      dst="LDAPtargetContext")

To migrate credentials from a test (or source) file store to a production (or target) LDAP store, call migrateSecurityStore in the target system: 

>migrateSecurityStore(type="credStore",
                      configFile="t2p-credentials.xml",
                      src="FileSourceContext",
                      dst="LDAPtargetContext")

To migrate credentials from a test (or source) DB store to a production (or target) DB store, call migrateSecurityStore in the target system: 

>migrateSecurityStore(type="credStore",
                      configFile="t2p-credentials.xml",
                      src="DBSourceContext",
                      dst="DBtargetContext")

Migrating Audit Data

Audit data consists of component event definitions, attribute table mappings, and audit policies, and this information resides in the audit store.

Use the migrateSecurityStore WLST command with the following syntax to migrate audit data between source and target repositories: 

migrateSecurityStore(type="auditStore",
                     configFile="jps_config_file_location",
                     src="sourceContext",
                     dst="targetContext"
                     [,overWrite="{true|false}"])

where:

  • configFile specifies the absolute or relative location of a configuration file. This configuration file is created just for the migration and serves no other purpose. This file contains two contexts that specify the source and target stores.

  • src specifies the name of a context in the configuration file passed to the configFile argument. It is the source data store.

  • dst specifies the name of another context in the configuration file passed to the configFile argument. It is the target data store.

  • overWrite indicates whether to overwrite data in the target store. Set to true to always overwrite data. Set to false not to overwrite data unless specific conditions are met. Optional. If unspecified, it defaults to false. Note that:

    • System definitions are never overwritten regardless of the value of the flag.

    • If overwrite is true, then component definitions in the target store are replaced with the definitions in the source store.

    • If overwrite is false, then versions of the component definition in source and target store are compared. If they have the same major version and the minor version in the source component definition is higher, then the component definition in the target store is replaced with the definition in the source store. Otherwise, overwriting is skipped.

Parent topic: Migrating from a Test to a Production Environment

Migrating Keys and Certificates with migrateSecurityStore

Keys and certificates are migrated in two distinct scenarios:

  • When source and target keystores lie in the same domain: the source and target keystores use the same encryption key.

  • When source and target keystores lie in different domains: the source and target keystores use distinct encryption keys.

The following sections explain key migration in these scenarios:

Parent topic: Migrating from a Test to a Production Environment

Migrating Keys and Certificates in the Same Domain

To migrate keys and certificates with migrateSecurityStore when both stores reside in the same domain, create a configuration file to specify the source and target service instances, and then use migrateSecurityStore. Note that a single configuration file is sufficient to specify source and target contexts when the keystores reside in the same domain.

The following example illustrates how to specify keystore sources in LDAP, DB, and file stores, and keystore targets in LDAP and DB stores:

<?xml version="1.0" encoding="UTF-8" standalone='yes'?>
<jpsConfig xmlns="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" schema-major-version="11" schema-minor-version="1">
 
<serviceProviders>
<serviceProvider class="oracle.security.jps.internal.credstore.ssp.SspCredentialStoreProvider" name="credstoressp" type="CREDENTIAL_STORE">
 <description>File credential provider</description>
 </serviceProvider>
 
<!-- provider for file, LDAP, and DB keystores -->
<serviceProvider type="KEY_STORE" name="keystore.provider" class="oracle.security.jps.internal.keystore.KeyStoreProvider">
<description>PKI Based Keystore Provider</description>
</serviceProvider>
</serviceProviders>
<serviceInstances>

<!-- Source XML-based keystore instance -->
 <serviceInstance location="./" provider="keystore.provider" name="keystore.file.source">
<property name="keystore.provider.type" value="file"/>
<property name="keystore.file.path" value="./"/> 
<description>Replace keystore.file.path with the full path of the folder where the file source keystore keystores.xml is located in the source file system; typically located in sourceDomain/config/fmwconfig/</description>
 </serviceInstance>
 
<!-- Source LDAP keystore instance -->
<serviceInstance provider="keystore.provider" name="keystore.ldap.source">
 <description>Replace: A. mySourceDomain and mySourceRootName to appropriate
 values according to your source LDAP directory structure; B. ldap://mySourceHost.com:3060 with the URL and port number of your source LDAP</description>
 <property value="bootstrap" name="bootstrap.security.credential.key"/>
 <property value="cn=mySourceDomain" name="oracle.security.jps.farm.name"/>
 <property value="cn=mySourceRootName" name="oracle.security.jps.ldap.root.name"/>
 <property value="ldap://mySourceHost.com:3060" name="ldap.url"/>
<property name="keystore.provider.type" value="ldap"/>
</serviceInstance>
 
<!-- Source DB keystore instance -->
<serviceInstance provider="keystore.provider" name="keystore.db.source">
 <description>Replace: A. mySourceDomain and mySourceRootName to appropriate
 values according to your source DB </description>
 <property value="cn=mySourceDomain" name="oracle.security.jps.farm.name"/>
 <property value="cn=mySourceRootName" name="oracle.security.jps.ldap.root.name"/>
 <property value="jdbc:oracle:thin:@mySourceHost:1722:orcl" name="jdbc.url"/>
 <!-- the value of jdbc.url should be the value entered when the source datasource was set up -->
 <property value="oracle.jdbc.driver.OracleDriver" name="jdbc.driver"/>
 <property name="bootstrap.security.principal.key" value="mySourceKeyName" />
 <property name="bootstrap.security.principal.map" value="mySourceMapName" />
 <property name="keystore.provider.type" value="db"/>
 <!-- the values of bootstrap.security.principal.key and
      bootstratp.security.principal.map
      should be the values entered when the bootstrap credential was set up -->
</serviceInstance>

<!-- target LDAP keystore instance -->
 <serviceInstance provider="keystore.provider" name="keystore.ldap.target">
<description>Replace: A. myDestDomain and myDestRootName to appropriate values according to your target LDAP directory structure; B. ldap://myDestHost.com:3060 with the URL and port number of your target LDAP</description>
 <property value="bootstrap" name="bootstrap.security.credential.key"/>
 <property value="cn=myDestDomain" name="oracle.security.jps.farm.name"/>
 <property value="cn=myDestRootName" name="oracle.security.jps.ldap.root.name"/>
 <property value="ldap://myDestHost.com:3060" name="ldap.url"/>
 <property name="keystore.provider.type" value="ldap"/>
</serviceInstance>

<!-- target DB keystore instance -->
 <serviceInstance provider="keystore.provider" name="keystore.db.target">
<description>Replace: myDestDomain and myDestRootName to appropriate values according to your target DB </description>
 <property value="cn=myDestDomain" name="oracle.security.jps.farm.name"/>
 <property value="cn=myDestRootName" name="oracle.security.jps.ldap.root.name"/>
 <property value="jdbc:oracle:thin:@myDestHost.com:1722:orcl" name="jdbc.url"/>
 <!-- the value of jdbc.url should be the value entered when the target datasource was set up -->
 <property value="oracle.jdbc.driver.OracleDriver" name="jdbc.driver"/>
 <property name="bootstrap.security.principal.key" value="myDestKeyName" />
 <property name="bootstrap.security.principal.map" value="myDestMapName" />
 <property name="keystore.provider.type" value="db"/>
 <!-- the values of bootstrap.security.principal.key and
      bootstratp.security.principal.map
      should be the values entered when the bootstrap credential was set up -->
</serviceInstance>

<!-- Bootstrap credentials to access source and target LDAPs and DBs -->
 <serviceInstance location="./bootstrap" provider="credstoressp" name="bootstrap.credstore">
 <description>Replace location with the full path of the directory where the bootstrap file cwallet.sso is located; typically found in targetDomain/config/fmwconfig/bootstrap</description>
 </serviceInstance>
 </serviceInstances>
 
 <jpsContexts>
 <jpsContext name="FileSourceContext">
 <serviceInstanceRef ref="keystore.file.source"/>
 </jpsContext>
 
 <jpsContext name="LDAPsourceContext">
 <serviceInstanceRef ref="keystore.ldap.source"/>
 </jpsContext>
 
<jpsContext name="DBsourceContext">
 <serviceInstanceRef ref="keystore.db.source"/>
 </jpsContext>
 
 <jpsContext name="LDAPtargetContext">
 <serviceInstanceRef ref="keystore.ldap.target"/>
 </jpsContext>
 
<jpsContext name="DBtargetContext">
 <serviceInstanceRef ref="keystore.db.target"/>
 </jpsContext>
 
 <!-- Do not change the name of the next context -->
 <jpsContext name="bootstrap_credstore_context">
 <serviceInstanceRef ref="bootstrap.credstore"/>
 </jpsContext>
 </jpsContexts>
</jpsConfig>

Note that because the migration involves LDAP or DB stores, the file includes the bootstrap_credstore_context context that specifies the location of the cwallet.sso bootstrap credential file.

Examples for Migrating Keys and Certificates in the Same Domain

The following examples assume that the t2p-keys.xml file is located on the target system in the directory where the command is run.

To migrate all keys and certificates from a test (source) LDAP store to a production (target) LDAP store, call migrateSecurityStore in the target system: 

>migrateSecurityStore(type="keyStore",
                      configFile="t2p-keys.xml",
                      src="LDAPsourceContext",
                      dst="LDAPtargetContext")

To migrate all keys and certificates from a test (source) file store to a production (target) LDAP store, call migrateSecurityStore in the target system: 

>migrateSecurityStore(type="keyStore",
                      configFile="t2p-keys.xml",
                      src="FileSourceContext",
                      dst="LDAPtargetContext")

To migrate keys and certificates for a specific application stripe from a test (source) database store to a production (target) database store, call migrateSecurityStore in the target system: 

>migrateSecurityStore(type="stripeKeyStore",
                      configFile="t2p-keys.xml",
                      src="DBSourceContext",
                      dst="DBtargetContext", 
                      srcStripe="application1", 
                      dstStripe="application2")
Migrating Keys and Certificates across Different Domains

To migrate keystore data when source and target keystores are located in different domains, two different configuration files are required because the encryption keys used to encrypt the keystores are different. Therefore the bootstrap credential stores must be distinct.

When using the migrateSecurityStore WLST command, recall that:

  • The context of the source keystore in the configuration file is specified in the srcConfigFile parameter.

  • The context of the target keystore in the configuration file is specified in the configFile parameter.

Example

To migrate all keys and certificates from a test (source) LDAP store to a production (target) LDAP store, call migrateSecurityStore in the target system: 

>migrateSecurityStore(type="keyStore",
             srcConfigFile="/source_domain/config/fmwconfig/jps-config.xml",
             configFile="/target_domain/config/fmwconfig/jps-config.xml",
             src="ksSrc", 
             dst="ksDst")