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, 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.

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.

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.

6.3 Deploying Oracle ADF Applications to a Test Environment

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.

6.3.1Deploying to a Test Environment

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 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 file jazn-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.

Credential Management

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.

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.

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.

6.4 Deploying Standard Java EE Applications

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.

6.5 Migrating from a Test to a Production Environment

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.

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.1Migrating 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 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.

6.5.1.1Migrating Identities Manually

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):

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.

6.5.2Migrating 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.

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 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.

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).

6.5.2.1Migrating 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:

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:

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:

6.5.2.2Migrating Credentials Manually

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:

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:

6.5.2.3Migrating 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 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:

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.

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:

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."

Scripting on this page enhances content navigation, but does not change the content in any way.