Deploying to a Test Environment

6-10 Oracle Fusion Middleware Application Security Guide ■ 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 script 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 OPSS security store policy, credential, and key stores be reassociated to an LDAP-based Oracle Internet Directory; if the test policy and credential stores were also LDAP, the production LDAP is assumed to be distinct from the test LDAP; if the test policy store was file-based, verify that no grant has duplicate permissions; see note in Policy Management . For details on how to reassociate stores, see Section 8.5.1, Reassociating 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. Important Note: If the application is hot deployed, that is without stoping and restarting the server, the migration of data in the file jazn-data.xml to the domain 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 re-deployed that is, hot deployed for a second or later time, any changes introduced in the file jazn-data.xml are not migrated over the domain security store. Deploying Secure Applications 6-11 ■ 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 script 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.

6.5.2.1 Migrating Policies Manually

By default, the script 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 . Migrating policies manually with the script 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 policy sources in LDAP, DB, and XML storages, and of policy destinations in LDAP and DB storages: ?xml version=1.0 encoding=UTF-8 standalone=yes? jpsConfig xmlns=http:xmlns.oracle.comoracleasschema11jps-config-11_1.xsd 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. 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 21.4.1, Parameters Controlling Policy Migration.