| Oracle® Fusion Middleware Application Security Guide 11g Release 1 (11.1.1) Part Number E10043-09 |
|
|
View PDF |
| Oracle® Fusion Middleware Application Security Guide 11g Release 1 (11.1.1) Part Number E10043-09 |
|
|
View PDF |
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, Oracle JDeveloper, or the WebSphere Application Server console. An application can also be started by setting the its bits in a location known to the WebLogic server, without the need to restart the server; this kind of application start is known as 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. For example, in the post-development phase, typically, the appliction is started in a production environment by means of a hot deployment.
The recommendations stated in this chapter apply to Oracle ADF applications and to Java EE 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 or by a hot deployment.
This chapter focuses on administrative tasks performed at deployment of an Oracle ADF or pure Java EE application. The last section explains the packaging requirements to secure Java EE 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 19.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 21, "Manually Configuring Java EE Applications to Use OPSS."
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 Java EE applications, which are further categorized into pure Java EE applications and Oracle Fusion Middleware ADF applications. The distinction of these two kinds of Java EE applications is explained in sections Section 1.5.1, "Scenario 1: Enhancing Security in a Java EE 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 Java EE Application |
Oracle WebLogic Administration Console, Fusion Middleware Control, WebSphere Application Server Administrator Console, WebSphere Application Server WASAdmin commands. The recommended tool is Oracle WebLogic Administration Console. |
|
Oracle ADF Application |
Fusion Middleware Control or OPSS script. 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 Java EE application that uses OPSS with Fusion Middleware Control on the WebLogic server.
Specifically, it describes the options you find in the page Configure Application Security at the third stage of the deploy settings.
The appearance of this page varies 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:
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 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 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 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.
An Oracle ADF application is a Java EE 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 Java EE 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 policy store when the application is deployed.
Oracle JDeveloper automatically writes the necessary configuration for this migration to occur.
Note:
Before migrating a file-based policy store (that is, the filejazn-data.xml) to a production environment, verify that any grant contains no duplicate permissions. If a duplicate permission (one that has the same name and class) appears in a grant, the migration runs into an error and it is halted. In this case, manually edit the jazn-data.xml file to remove any duplicate permissions from a grant definition, and invoke the migration again.Application-specific credentials packed with the application are automatically migrated to the 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 21.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).
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 8.5.1, "Reassociating 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 9.2.2, "Managing Application Roles."
Create additional application roles or customize existing ones. For details, see Section 9.2.2, "Managing Application Roles."
Manage system policies. For procedure details, see Section 9.2.3, "Managing System Policies."
Manage credentials. For procedure details, see Section 10.2, "Managing the Credential Store."
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 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 Java EE applications that do not use OPSS but that use standard Java authorization: administratively, with the Administration Console or a OPSS script; or programmatically, with deployment descriptors.
A Java EE 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 Java EE Applications, in Oracle Fusion Middleware Administrator's Guide.
For details about deploying applications with 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
The recommendations that follow apply only to Java EE applications using JAAS authorization, such as Oracle Application Development Framework, Oracle SOA, and Oracle WebCenter applications, and they do not apply to Java EE applications using standard authorization. For deploying the latter, see Deploying Standard Java EE 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:
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 task may include:
The identity store configuration, including the provisioning of required users and groups using the WebLogic Administrator Console or the OPSS script configureIdentityStore. For details about this last command, see Migrating Identities Manually.
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 OPSS script 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 script 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.
This script can be run in interactive mode or in script mode. In interactive mode, you enter the script at a command-line prompt and view the response immediately after. In script mode, you write scripts in a text file (with a py file name extension) and run it without requiring input, much like the directives in a shell script.
For platform-specific requirements to run an OPSS script, see Important Note.
Script and Interactive Modes Syntaxes
To migrate identities on WebLogic, 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 migration of identities on WebSphere is accomplished with a similar script. For details, see Oracle Fusion Middleware Third-Party Application Server Guide.
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 script 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 must be an LDAP-based identity store. For list of supported types, see Section 3.1.1, "Supported LDAP Identity Store Types."
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.
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.
Important Note:
If the application is hot deployed, that is without stoping and restarting the server, the migration of data in the filejazn-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.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:
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 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.
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.
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."
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.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-based 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-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>
<!-- Source DB-based 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>
<!-- 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>
<!-- Destination DB-based policy store instance -->
<serviceInstance provider="db.policystore.provider" name="policystore.db.destination">
<description>Replace: myDestDomain and myDestRootName to appropriate values
according to your destination 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 destination 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 destination LDAPs or DBs-->
<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="DBsourceContext">
<serviceInstanceRef ref="policystore.db.source"/>
</jpsContext>
<jpsContext name="LDAPdestinationContext">
<serviceInstanceRef ref="policystore.ldap.destination"/>
</jpsContext>
<jpsContext name="DBdestinationContext">
<serviceInstanceRef ref="policystore.db.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 and DB stores, the file includes a jps-context named bootstrap_credstore_context that specifies the directory where the bootstrap credential file cwallet.sso is located. Furthermore, for each pair of map name and key name in the sample above, you must provide the corresponding bootstrap credentials using the WLST script addBootStrapCredential as illustrated in the following example:
wls:/offline> addBootStrapCredential(jpsConfigFile='jps-config.xml', map='myMapName', key='myKeyName', username='myUserName', password='myPassword')
where myUserName and myPassaword specify the user account name and password to access the target database.
The following examples of use of migrateSecurityStore assume that:
The file t2p-policies.xml is located on the target system in the directory where the script 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, before using the script, 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")
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")
To migrate policies from a test (or source) DB store to a production (or destination) DB store, invoke migrateSecurityStore in the target system as follows:
>migrateSecurityStore(type="policyStore",configFile="t2p-policies.xml",src="DBsourceContext",dst="DBdestinationContext")
The script 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 migrateSecurityStore requires assembling a configuration file where the source and destination are specified.
Since 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 credential sources in LDAP, DB, and XML storages, and of credential destinations in LDAP or DB storages:
<?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> <serviceProvider class="oracle.security.jps.internal.credstore.rdbms.DbmsCredentialStoreProvider" name="db.credentialstore.provider" type="CREDENTIAL_STORE"> <description>DB-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. 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-based 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> <!-- 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. ldap://myDestHost.com:3060 with the URL and port number of your destination 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> <!-- Destination DB-based credential store instance --> <serviceInstance provider="db.credentialstore.provider" name="credential.db.destination"> <description>Replace: myDestDomain and myDestRootName to appropriate values according to your destination 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 destination 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 destination LDAPs and DBs --> <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="DBsourceContext"> <serviceInstanceRef ref="credential.db.source"/> </jpsContext> <jpsContext name="LDAPdestinationContext"> <serviceInstanceRef ref="credential.ldap.destination"/> </jpsContext> <jpsContext name="DBdestinationContext"> <serviceInstanceRef ref="credential.db.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 and/or DB 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 migrateSecurityStore assume that the file t2p-credentials.xml is located on the target system in the directory where the script 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")
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")
To migrate credentials from a test (or source) DB store to a production (or destination) DB store, invoke migrateSecurityStore in the target system as follows:
>migrateSecurityStore(type="credStore",configFile="t2p-credentials.xml",src="DBSourceContext",dst="DBdestinationContext")
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 script migrateSecurityStore would take an unacceptable amount of time).
Note:
Large volume migration of stores is supported for LDAP-based stores only. It is not supported for DB-based stores.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 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 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.
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 OPSS script 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 OPSS script 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."
|
 Copyright © 2003, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|