6 Deploying Secure Applications

An application can be deployed to an Oracle WebLogic Server using any of the following tools: the Oracle WebLogic Server Administration Console, Oracle Enterprise Manager Fusion Middleware Control, or Oracle JDeveloper.

The tool recommended to deploy it depends on the application type and whether the application is in the developing phase or in a post-development phase. The recommendations stated in this chapter apply to Oracle ADF applications and to JavaEE applications using OPSS.

During development, the application is typically deployed with Oracle JDeveloper to the embedded Oracle WebLogic Server. Once the application transitions to test or production environments, it is typically deployed with Fusion Middleware Control or the Oracle WebLogic Server Administration Console.

This chapter focuses on administrative tasks performed at deployment of an Oracle ADF or pure JavaEE application. The last section explains the packaging requirements to secure JavaEE applications, a topic relevant only when the application is packaged manually.

This chapter is divided into the following sections:

Additional Documentation

For further details about deployment, see Chapter 8, Deploying Applications, in Oracle Fusion Middleware Administrator's Guide.

For an overview of the entire security life-cycle of an application, from development to production, see Oracle Fusion Middleware Security Overview.

For details about securing an Oracle ADF application during development, see Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

For an overview of the development cycle, see Section 13.1.1, "The Development Cycle."

For details about the files in an EAR file relevant to application security management and configuration, such as web.xml and weblogic-application.xml, see Chapter 14, "Manually Configuring JavaEE Applications to Use OPSS."

6.1 Overview

The steps that lead to the deployment of an Oracle ADF application into a remote Oracle WebLogic Server are, typically, as follows:

  • Using Oracle JDeveloper, a developer develops an Oracle ADF application into which Oracle ADF security is included with the Oracle ADF Security Wizard.

  • Application users and groups, authorization policies, and credentials are copied by Oracle JDeveloper to the integrated WebLogic Server, into which the application is auto-deployed during the test cycles in that environment.

  • The developer creates an application EAR file which packs policies and credentials.

  • The domain administrator deploys the EAR file to a remote Oracle WebLogic Server using Fusion Middleware Control.

This flow is illustrated in the following graphic:

Surrounding text describes jisec014.gif.

6.2 Selecting the Tool for Deployment

The types of application we consider in this chapter are JavaEE applications, which are further categorized into pure JavaEE applications and Oracle Fusion Middleware ADF applications. The distinction of these two kinds of JavaEE applications is explained in sections Section 1.5.1, "Scenario 1: Securing a JavaEE Application," and Section 1.5.2, "Scenario 2: Securing an Oracle ADF Application."

Table 6-1 lists the tool used to deploy a developed application according to its type.

Table 6-1 Tools to Deploy Applications after Development

Application Type Tool to Use

Pure JavaEE Application

Oracle WebLogic Administration Console, Fusion Middleware Control, or WLST command. The recommended tool is Oracle WebLogic Administration Console.

Oracle ADF Application

Fusion Middleware Control or WLST command. The recommended tool is Fusion Middleware Control.


6.2.1 Deploying JavaEE and Oracle ADF Applications with Fusion Middleware Control

This section focuses on the security configurations available when deploying an application that uses Oracle ADF security or a JavaEE application that uses OPSS with Fusion Middleware Control, specifically, on the options you find in the page Configure Application Security at the third stage of the deploy settings.

The appearance of this page depends according to what is packaged in the EAR fie, as follows:

  • If the EAR file packages jazn-data.xml with application policies, the application policy migration section is shown.

  • If the EAR file packages credentials in cwallet.sso, the credential migration section is shown.

  • If the EAR file does not include any of the above, then the page displays the default Java EE security options.

This page, showing the policy migration sections, is partially illustrated in the following graphic:

Surrounding text describes emdeploy1.gif.

The settings in this page concern the migration of application policies and credentials (packed in application EAR file) to the corresponding domain store, and they are explained next.

Application Policy Migration Settings

These settings control of the policy migration in the following scenarios:

  • If you are deploying the application for the first time, you typically want application policies to be migrated to the domain policy store. Therefore, select Append in the Application Policy Migration area.

    If for some reason you do not want the migration to take place, select instead 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, you can choose Append, to merge the packed policies with the existing ones in the domain, or Ignore, to prevent policy migration.

    The option Ignore is typically selected when an application is redeployed and you want to leave the current application policies in the domain unchanged, that is, when you want to preserve changes to the policy store made during previous deployments.

  • When you choose Append, you can further specify which grants and roles should be migrated; the basic distinction is between ADF application roles and grants (needed in a production environment), and development-time only roles and grants (not needed in a production environment).

    To migrate ADF application roles and grants, and not to migrate development-time only security roles and grants, check the box Migrate only application roles and grants. Ignore identity store artifacts. Typically, this box is checked when deploying to a production environment. Note that when this box is checked, you will need to map application roles to enterprise groups once the application has been deployed.

  • When you choose Append, you can further specify a particular stripe (different from the default stripe, which is the application name) into which the application policies should be migrated, by entering the name of that stripe in the box Application Stripe Id.

    About Application Stripes:

    The domain policy store is logically partitioned in stripes, one for each application name specified in the file system-jazn-data.xml under the element <applications>. Each stripe identifies the subset of domain policies pertaining to a particular application.
  • I f nothing is specified, the default settings are Append (in deployment) and Ignore (in redeployment).

Application Credential Migration Settings

These settings control of the credential migration in the following scenarios:

  • If you are deploying the application for the first time, you typically want application credentials to be migrated to the domain credential store. Therefore, select Append in the Application Credential Migration area.

  • In any case (first or succeeding deployment), if for some reason you do not want the migration to take place, select instead Ignore.

    Note:

    Application code using credentials may not work if the credential migration is ignored. Typically, one would choose the Ignore option under the assumption that the credentials are manually created with the same map and key, but with different values.
  • The option Overwrite is supported only when the WebLogic server is running in development mode.

  • If nothing is entered, the default is Ignore.

6.3 Deploying Oracle ADF Applications to a Test Environment

An Oracle ADF application is a JavaEE application using JAAS authorization, and it is typically developed and tested using Oracle JDeveloper; this environment allows a developer to package the application and deploy it in the Embedded Oracle WebLogic Server integrated with the tool. When transitioning to a test or production environment, the application is deployed using Oracle Fusion Middleware Control to leverage all the Oracle ADF security features that the framework offers. For details, see Overview.

For step-by-step instructions on how to deploy an Oracle ADF application with Fusion Middleware Control, see:

  • Section Deploy an Application Using Fusion Middleware Control in the Oracle Fusion Middleware Control online help system.

  • Section 8.4, Deploying and Undeploying Oracle ADF Applications, in Oracle Fusion Middleware Administrator's Guide.

This section is divided into the following topics:

6.3.1 Deploying to a Test Environment

The security options available at deployment are explained in Deploying JavaEE and Oracle ADF Applications with Fusion Middleware Control.

When deploying an Oracle ADF application to a test environment with Fusion Middleware Control, the following operations take place:

Policy Management

  • Application-specific policies packed with the application are automatically migrated to the domain policy store when the application is deployed.

    Oracle JDeveloper automatically writes the necessary configuration for this migration to occur.

Credential Management

  • Application-specific credentials packed with the application are automatically migrated to the domain credential store when the application is deployed.

    Oracle JDeveloper automatically writes the necessary configuration for this migration to occur.

  • The bootstrap credentials necessary to access LDAP repositories during migration are automatically produced by Fusion Middleware Control. For details about a manual setup, see Section 14.4.7, "Specifying Bootstrap Credentials Manually."

Identity Management

Identities packed with the application are not migrated. The domain administrator must configure the domain authenticator (with the Administration Console), update identities (enterprise users and groups) in the environment, as appropriate, and map application roles to enterprise users and groups (with Fusion Middleware Control).

Other Considerations

  • When deploying to a domain with LDAP-based security stores and to preserve application data integrity, it is recommended that the application be deployed at the cluster level or, otherwise, to just one managed server.

  • When deploying an application to multiple managed servers, be sure to include the administration server so that data is migrated as expected.

  • The reassociation of domain stores is an infrequent operation and, typically, takes place when the domain is set up before applications are deployed. For procedure details, see Section 7.2.1, "Reassociating Domain Stores with Fusion Middleware Control."

6.3.1.1 Typical Administrative Tasks after Deployment in a Test Environment

At any time after an application is deployed in a test environment, an administrator can perform the following tasks using Fusion Middleware Control or the Administration Console:

Notes:

If the application is undeployed with Fusion Middleware Control from a server running in production mode, then the application-specific policies are automatically removed from the domain policy store. Otherwise, if you use any other tool to undeploy the application, then the removal of application-specific policies must be performed manually.

Credentials are not deleted upon an application undeployment. A credential may have started it life as being packaged with an application, but when the application is undeployed credentials are not removed.

6.4 Deploying Standard JavaEE Applications

There are two ways to secure JavaEE applications that do not use OPSS but that use standard Java authorization: administratively, with the Administration Console or a WLST script (command-line or script mode); or programmatically, with deployment descriptors.

A JavaEE application deployed to the Oracle WebLogic Server is a WebLogic resource. Therefore, an administrator would set security for the deployed application the same way that he would for any other resource.

For details about deployment procedures, see section 8.3, Deploying and Undeploying JavaEE Applications, in Oracle Fusion Middleware Administrator's Guide.

For details about deploying applications with the WLST commands, see section Deployment Commands in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

For an overview of WebLogic Server deployment features, see chapter Understanding WebLogic Server Deployment in Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server.

Related Documentation

Further information about securing application resources, can be found in the following documents:

In Oracle Fusion Middleware Securing Resources Using Roles and Policies for Oracle WebLogic Server

  • Section Application Resources

  • Section Options for Securing Web Application and EJB Resources

In Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help:

  • Section Use Roles and Policies to Secure Resources

In Oracle Fusion Middleware Securing WebLogic Web Services for Oracle WebLogic Server:

  • Section Overview of Web Services Security

In Oracle Fusion Middleware Programming Security for Oracle WebLogic Server:

  • Section Securing Web Applications. Particularly relevant is the subsection Using Declarative Security with Web Applications

  • Section Securing Enterprise JavaBeans (EJBs)

  • Section Using Java Security to Protect WebLogic Resources

6.5 Migrating from a Test to a Production Environment

The recommendations that follow apply only to JavaEE applications using JAAS authorization, such as Oracle Application Development Framework, Oracle SOA, and Oracle WebCenter applications, and they do not apply to JavaEE applications using standard authorization. For deploying the latter, see Deploying Standard JavaEE Applications.

The recommended tool to deploy applications is Fusion Middleware Control, and the user performing the operations described in the following sections must have the appropriate privileges, including the privilege to seed a schema in an LDAP repository.

It is assumed that a production has been set up as explained in Section 5.2.1, "Setting Up a Brand New Production Environment."

The migration to a new production environment is divided into three major portions: migrating providers other than policy or credential providers, migrating policy and credential providers, and migrating audit policies, as explained in the following sections:

6.5.1 Migrating Providers other than Policy and Credential Providers

The configuration of providers (other than policy and credential providers) in the production environment must be repeated as it was done in the test environment. This configuration may include:

  • The identity store configuration, including the provisioning of users (using the WebLogic Administrator Console).

  • A SAML configuration of the issuer's list.

  • Any particular provider configuration that you have performed in the test environment.

Note:

Oracle WebLogic Server provides several tools to facilitate the creation of domains, such as the pack and unpack commands. For details, see Oracle Fusion Middleware Creating Templates and Domains Using the Pack and Unpack Commands.

6.5.1.1 Migrating Identities Manually

Identity data can be migrated manually from a source repository to a target repository using the WLST command migrateSecurityStore. This migration is needed, for example, when transitioning from a test environment that uses a file-based identity store to a production environment that uses an LDAP-based identity store.

This command is offline, that is, it does not require a connection to a running server to operate; therefore, the configuration file passed to the argument configFile need not be an actual domain configuration file, but it can be assembled just to specify the source and destination repositories of the migration.

The commands listed below can be run in interactive mode or in script mode. In interactive mode, you enter the command at a command-line prompt and view the response immediately after. In script mode, you write commands in a text file (with a py file name extension) and run it without requiring input, much like the directives in a shell script.

Important:

Before invoking a security-related WLST command in a shell, you must run the script wlst.sh, as illustrated in the following sample:
> sh $ORACLE_HOME/common/bin/wlst.sh

This ensures that the required JARs are added to the class path. Failure to run the above script in a new shell renders the WLST commands unusable.

Before running an online command, connect to the server as follows:

>java weblogic.WLST
>connect('servername', 'password', 'localhost:portnum')

Script and Interactive Modes Syntaxes

To migrate identities, use the script (first) or interactive (second) syntaxes (arguments are written in separate lines for clarity):

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

The meaning of the arguments (all required except dstLdifFile) is as follows:

  • configFile specifies the location of a configuration file jps-config.xml relative to the directory where the command is run.

  • src specifies the name of a jps-context in the configuration file passed to the argument configFile, where the source store is specified.

  • dst specifies the name of another jps-context in the configuration file passed to the argument configFile, where the destination store is specified. The destination store can be XML-based or LDAP-based backed by an Oracle Internet Directory server. No other destination is supported.

  • dstLdifFile specifies the relative or absolute path to the LDIF file created. Required only if destination is an LDAP-based Oracle Internet Directory store. Notice that the LDIF file is not imported into the LDAP server.

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

After an LDIF file is generated, the next step typically involves manual editing this file to customize the attributes of the LDAP repository where the LDIF file would, eventually, be imported.

6.5.2 Migrating Policies and Credentials at Deployment

In a production environment, it is strongly recommended that the policy and credential stores be reassociated to an LDAP-based repository; if the test policy and credential stores were also LDAP, the production LDAP is assumed to be distinct from the test LDAP. For details on how to reassociate stores, see Section 7.2.1, "Reassociating Domain Stores with Fusion Middleware Control."

The migration of policies and credentials can take place in the following ways: automatically, when an application is deployed; or manually, before or after the application is deployed.

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

When deploying an application to a production environment, an administrator should know the answer the following question:

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

Assuming that you know the answer to the above question, to deploy an application to a production environment, proceed as follows:

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

    • If policies (application or system) have been modified in the test environment, then disable the option to migrate policies at deploy time by selecting the option Ignore under the Application Policy Migration area in Fusion Middleware Control's page Configuration Application Security; otherwise, select Append.

      Note:

      You can select Append (that is, to migrate application policies) in combination with checking the box Migrate only application roles and grants. Ignore identity store artifacts, even when application roles have been modified in the test environment to the extent of mapping them to test enterprise groups.

      Selecting this combination migrates application policies but disregards the maps to test enterprise groups. Later on, in step 3 below, 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 deploy time by selecting the option Ignore under the Application Credential Migration area in Fusion Middleware Control's page Configuration Application Security; otherwise, select Append.

  2. Use the command migrateSecurityStore to migrate modified data, as follows:

    • If you chose to Ignore application policy migration, then migrate application and system policies from the test to the production LDAP. See example in Migrating Policies Manually.

    • If you chose to Ignore application credential migration, then migrate credentials from the test to the production LDAP. See example in Migrating Credentials Manually.

  3. In any case, 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 necessary, modify the production data, as appropriate.

Note:

There is a way to configure the application so that, at deployment, the migration of policies preserves GUIDs (instead of recreating them).

This setting can only be configured manually. For details, see parameter jps.approle.preserveguid in Section 14.4.1, "Parameters Controlling Policy Migration."

6.5.2.1 Migrating Policies Manually

By default, the command migrateSecurityStore recreates GUIDs and may take a long time to migrate large volume of policies; for these reasons, during the transition from a test to a production environment, you may want to consider migrating policies and credentials with an alternate procedure that uses Oracle Internet Directory bulk operations. For details, see Migrating Large Volume Policy and Credential Stores. There is, however, a way to specify that the GUIDs be preserved by the migration. For details, see argument preserveAppRoleGuid in Section 7.3.2, "Migrating Policies with the Command migrateSecurityStore."

Migrating policies manually with the command migrateSecurityStore requires assembling a configuration file where the source and destination are specified.

Here is a complete sample of a configuration file, named t2p-policies.xml, illustrating the specification of sources for LDAP and XML policies, and of a destination for LDAP policies:

<?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>Bootstrap credential provider</description>
 </serviceProvider>
 
 <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-based 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-based 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>
 
 <!-- Destination LDAP-based policy store instance -->
 <serviceInstance provider="ldap.policystore.provider" name="policystore.ldap.destination">
<description>Replace: A. myDestDomain and myDestRootName to appropriate values according to your destination LDAP directory structure; B. OID with OVD, if your destination LDAP is OVD; C. ldap://myDestHost.com:3060 with the URL and port number of your destination 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>
 
<!-- Bootstrap credentials to access source and destination LDAPs -->
 <serviceInstance location="./bootstrap" provider="credstoressp" name="bootstrap.cred">
  <description>Replace location with the full path of the directory where the bootstrap file cwallet.sso is located; typically found in destinationDomain/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="LDAPdestinationContext">
 <serviceInstanceRef ref="policystore.ldap.destination"/>
 </jpsContext>
 
 <!-- Do not change the name of the next context -->
 <jpsContext name="bootstrap_credstore_context">
 <serviceInstanceRef ref="bootstrap.cred"/>
 </jpsContext>
 </jpsContexts>
</jpsConfig>

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

The following examples of use of the command migrateSecurityStore assume that:

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

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

Under these assumptions, to migrate policies from a test (or source) LDAP store to a production (or destination) LDAP store, invoke migrateSecurityStore in the target system as follows:

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

Similarly, to migrate policies from a test (or source) XML store to a production (or destination) LDAP store, invoke migrateSecurityStore in the target system as follows:

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

6.5.2.2 Migrating Credentials Manually

The command migrateSecurityStore recreates GUIDs and may take a long time to migrate large volume of credentials; for these reasons, during the transition from a test to a production environment, you may want to consider migrating policies and credentials with an alternate procedure that uses Oracle Internet Directory bulk operations. For details, see Migrating Large Volume Policy and Credential Stores.

Migrating credentials manually with the command migrateSecurityStore requires assembling a configuration file where the source and destination are specified.

Since the command migrateSecurityStore recreates GUIDs and takes a long time to migrate large volume of data, you may want to consider migrating stores with an alternate procedure that uses Oracle Internet Directory bulk operations. For details, see Migrating Large Volume Policy and Credential Stores.

Here is a complete sample of a configuration file, named t2p-credentials.xml, illustrating the specification of sources for LDAP and XML credentials, and of a destination for LDAP credentials:

<?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-based credential provider</description>
 </serviceProvider>
 
 <serviceProvider class="oracle.security.jps.internal.credstore.ldap.LdapCredentialStoreProvider" name="ldap.credentialstore.provider" type="CREDENTIAL_STORE">
 <description>LDAP-based credential provider</description>
 </serviceProvider>
</serviceProviders>
 
<serviceInstances>
 <!-- Source file-based 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-based source credential store cwallet.sso is located in the source file system; typically located in sourceDomain/config/fmwconfig/</description>
 </serviceInstance>
 
<!-- Source LDAP-based 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. 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="credstore.type"/>
 <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>
 
 <!-- Destination LDAP-based credential store instance -->
 <serviceInstance provider="ldap.credentialstore.provider" name="credential.ldap.destination">
<description>Replace: A. myDestDomain and myDestRootName to appropriate values according to your destination LDAP directory structure; B. OID with OVD, if your destination LDAP is OVD; C. ldap://myDestHost.com:3060 with the URL and port number of your destination LDAP</description>
 <property value="OID" name="credstore.type"/>
 <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>
 
<!-- Bootstrap credentials to access source and destination LDAPs -->
 <serviceInstance location="./bootstrap" provider="credstoressp" name="bootstrap.cred">
 <description>Replace location with the full path of the directory where the bootstrap file cwallet.sso is located; typically found in destinationDomain/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="LDAPdestinationContext">
 <serviceInstanceRef ref="credential.ldap.destination"/>
 </jpsContext>
 
 <!-- Do not change the name of the next context -->
 <jpsContext name="bootstrap_credstore_context">
 <serviceInstanceRef ref="bootstrap.cred"/>
 </jpsContext>
 </jpsContexts>
</jpsConfig>

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

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

Under that assumption, to migrate credentials from a test (or source) LDAP store to a production (or destination) LDAP store, invoke migrateSecurityStore in the target system as follows:

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

Similarly, to migrate credentials from a test (or source) XML store to a production (or destination) LDAP store, invoke migrateSecurityStore in the target system as follows:

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

6.5.2.3 Migrating Large Volume Policy and Credential Stores

Migrating stores with the alternate procedure explained in this section is suitable to preserve source GUIDs or for large volume stores (where migrating with the command migrateSecurityStore would take an unacceptable amount of time).

For illustration purpose, assume that the policy store LDAP to be migrated is configured in the file jps-config.xml with a service instance as in the following fragment:

<serviceInstance provider="ldap.policystore.provider" name="policystore.ldap">
 <property name="policystore.type" value="OID" />
 <property name="bootstrap.security.principal" value="bootstrap"/>
 <property  name="oracle.security.jps.farm.name" value="cn=base_domain"/>
 <property  name="oracle.security.jps.ldap.root.name" value="cn=mySrcRootName"/>
 <property  name="ldap.url" value="ldap://myCompany.com:7766"/>
</serviceInstance>

Important:

If you intend to use the procedure that follows with a destination Oracle Internet Directory version 10.1.4.3.0, then you must first apply a patch for bug number 8417224. To download this patch for your platform, visit Oracle Support at http://myoraclesupport.oracle.com.

To migrate a source Oracle Internet Directory store to a destination Oracle Internet Directory store using bulk commands, proceed as follows:

  1. In the system where the source Oracle Internet Directory is located, produce an LDIF file by running ldifwrite as illustrated in the following line:

    >ldifwrite connect="srcOidDbConnectStr" baseDN="cn=jpsnode, c=us" ldiffile="srcOid.ldif"
    

    This command writes all entries under the node cn=jpsnode, c=us to the file srcOid.ldif. Once generated, move this file, as appropriate, to the destination Oracle Internet Directory file system so it is available to the commands that follow.

  2. In the destination Oracle Internet Directory node, ensure that the JPS schema has been seeded.

  3. In the destination Oracle Internet Directory system, verify that there are no schema errors or bad entries by running bulkload as illustrated in the following line:

    >bulkload connect="dstOidDbConnectStr" check=true generate=true restore=true file="fullPath2SrcOidLdif"
    

    If duplicated DNs (common entries between the source and destination directories) are detected, review them to prevent unexpected results.

  4. Backup the destination DB. If the next steps fails (and corrupts the DB), the DB must be restored.

  5. Load data into the destination Oracle Internet Directory, by running bulkload as illustrated in the following line:

    >bulkload connect="dstOidDbConnectStr" load=true file="fullPath2SrcOidLdif"
    

For details about the above commands, see chapter 14, Performing Bulk Operations, in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

6.5.3 Migrating Audit Policies

To migrate audit policies, use the export and import operations as explained next.

First, export the audit configuration from a test environment to a file using one of the following tools:

  • Fusion Middleware Control: navigate to Domain > Security > Audit Policy, and then click Export.

  • The WLST command exportAuditConfig. For details, see Appendix C, "exportAuditConfig."

Then, import that file into the production environment using one of the following tools:

  • Fusion Middleware Control: navigate to Domain > Security > Audit Policy, and then click Import.

  • The WLST command importAuditConfig. For details, see Appendix C, "importAuditConfig."

The import/export operations above migrate audit policies only, and they do not migrate the audit data store settings. If you had configured an audit data source in your test environment, repeat the steps to configure a data source in the production environment. For details, see Section 11.2.2, "Set Up Audit Data Sources."

Normally, you would not want audit data records from a test environment to be migrated to production; however, to do so, use the database import/export utilities for that purpose. For details, see Section 11.5.5, "Importing and Exporting Data."