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:
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 14.1.1, "The Development Cycle."
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:
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 2.5.1, "Scenario 1: Enhancing Security in a JavaEE Application," and Section 2.5.2, "Scenario 2: Securing an Oracle ADF Application."
Table 7-1 lists the tool used to deploy a developed application according to its type.
Table 7-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. |
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 both the policy and credential migration sections, is partially illustrated in the following graphic:
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 allow the 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.
If the application has been previously deployed, so that the migration of application policies has taken place before the current deployment, you can choose Append, to merge the packed policies with the existing ones in the domain, or Ignore, to prevent the migration and leave the current application domain policies unchanged.
In any case and when you choose Append, you have the choice to migrate just application roles and grants that do not refer to enterprise groups or to enterprise users by checking the box Migrate only application roles and grants; checking this box prevents the migration of any policy that is not entirely described within the application, that is, that refers to enterprise users or groups not defined in the packed policies.
Note:
The box Migrate only application roles and grants controls the behavior of the mapping of application roles to enterprise users and groups. Typically, this box if unchecked when deploying to a production environment.In any case and when you choose Append, to specify a particular stripe (different from the default stripe, which is identical to the application name) into which the application policies should be migrated, enter the name of that stripe in the box Application Id.
Note:
The domain policy store is logically partitioned in stripes, one for each application name specified in the filesystem-jazn-data.xml
under the element applications. Each stripe identifies the subset of domain policies pertaining to a particular application.Application Credential Migration Settings
These settings allow the 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.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:
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:
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.
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 15.4.7, "Specifying Bootstrap Credentials Manually."
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).
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 8.2.1, "Reassociating Domain Stores with Fusion Middleware Control."
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:
Map application roles to enterprise groups. Until this mapping is accomplished, security does not work as expected. For procedure details, see Section 8.4.1.1, "Managing Application Policies."
Create additional application roles or customize existing ones. For details, see Section 8.4.1.2, "Managing Application Roles."
Manage system policies. For procedure details, see Section 8.4.1.3, "Managing System Policies."
Manage credentials. For procedure details, see Section 9.5.1, "Managing Credentials with Fusion Middleware Control."
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.
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.
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
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 6.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:
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 thepack
and unpack
commands. For details, see Oracle Fusion Middleware Creating Templates and Domains Using the Pack and Unpack Commands.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, a command is entered at a command-line prompt and view the response immediately after. In script mode, commands are written in a text file (with a py file name extension) and run 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 scriptwlst.sh
, as illustrated in the following sample:
> sh $ORACLE_HOME/common/bin/wlst.sh
This ensures that the required JARs are added to the classpath. 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 location where the LDIF file is 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.
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 8.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.
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:
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.
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.
In any case, use Fusion Middleware Control to map application roles to production enterprise groups, as appropriate.
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.
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.
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")
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.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 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.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="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")
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="security.principal" value="cn=orcladmin"/>
<property name="oracle.security.jps.farm.name" value="cn=base_domain"/>
<property name="lasp.example.com" value="cn=jpsnode,c=us"/>
<property name="ldap.url" value="ldap://myCompany.com:7766"/>
</serviceInstance>
Note that the property ldap.example.com
identifies the base node of the store in the source Oracle Internet Directory repository.
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 athttp://myoraclesupport.oracle.com
.To migrate a source Oracle Internet Directory store to a destination Oracle Internet Directory store using bulk commands, proceed as follows:
In the system where the source Oracle Internet Directory is located, produce an LDIF file by running ldfiwrite
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.
In the destination Oracle Internet Directory node, ensure that the JPS schema has been seeded.
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.
Backup the destination DB. If the next steps fails (and corrupts the DB), the DB must be restored.
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.
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 12.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 12.5.5, "Importing and Exporting Data."