9 Deploying Security Components

This chapter describes how to deploy the components of your portal application that relate to security. It contains the following sections:

• Section 9.1, "Deploying the Enterprise Archive File"

• Section 9.2, "Using the Propagation Utility"

For more detailed information on deployment and propagation, see the Oracle Fusion Middleware Production Operations Guide for Oracle WebLogic Portal.

9.1 Deploying the Enterprise Archive File

To bring your portal online in a production environment, it is first necessary to prepare your portal application. Typical preparation steps include modifying deployment descriptors for the product, building the enterprise archive (EAR) with all its pre-compiled classes, and deciding if you want to compress that EAR into an archive or leave it exploded.

Similar to any J2EE application, a portal application has a number of deployment descriptors that you may want to tune for your production environment.

9.1.1 Modifying Enterprise Application Deployment Descriptors

Deployment descriptors contain the settings for cache configuration, behavior tracking, and campaign information. If these values are different for your production environment than for your existing development settings, use a deployment plan, described in the Oracle Fusion Middleware Production Operations Guide for Oracle WebLogic Portal, to modify appropriately before building the portal application.

9.1.2 Modifying Web Application Deployment Descriptors

The portal application has a /WEB-INF directory that contains a number of deployment descriptors you may need to modify for your production environment.

A J2EE standard deployment descriptor is web.xml. Among other settings, it has a set of elements for configuring security for the web application. You must use J2EE security to restrict access to JSPs and page flows in your portal applications; otherwise, a user can access those resources directly by typing the URL to those resources. For information on how to secure the JSPs and page flows, see Chapter 4, "Preventing Direct Access to Portal Application Resources."

Note:

Page flows are a feature of Apache Beehive, which is an optional framework that you can integrate with WLP. See "Apache Beehive and Apache Struts Supported Configurations" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.

9.2 Using the Propagation Utility

WebLogic Portal supports the use of multiple authentication providers in a portal domain, which means that users in external providers can log in to your portal applications. It also means that in your code you potentially have access to multiple user stores.

Because the propagation utility does not propagate some portal resources from the source to the destination system, there might be cases where propagated data depends on other data that is not propagated. For example, delegated administration and visitor entitlement roles and policies are propagated to the destination but the related users and groups are not, so you must manually add those related users, user profiles, and groups on the destination system.

For more information about the propagation utility, including which resources are propagated and which are not, see the Oracle Fusion Middleware Production Operations Guide for Oracle WebLogic Portal