6 Securing OracleAS Portal

6.1.3.4.1 Global Privileges

Table 6-7 describes the global object types and corresponding privilege codes that can be granted to users in the provideruiacls.xml file. When granting a privilege to the user, you should specify the numeric privilege code.

To add a privilege to a particular user, add an entry in the proper object type container, for example:

<objectType name="ALL_OBJECTS">
    <object name="ANY_PROVIDER" owner="providerui">
       <user name="jdoe" privilege="400"/>
        …
    </object>
</objectType>

For these global privileges, the objectType name is set to ALL_OBJECTS, the object owner is set to providerui, and the object name should be ANY_PROVIDER or ANY_PORTLET depending on the type of grant you are setting.

You then set the user name and privilege to the values corresponding to the OracleAS Single Sign-On user name of the grantee and the privilege code you wish to assign. This model does not support any grants to groups. It only supports grants directly to users.

6.1.3.4.2 Object Level Privileges

Table 6-8 describes the object level privileges that can be granted to users to give them privileges on specific object instances as referenced within the provideruiacl.xml XML file.

To add a privilege to a particular user, add an entry into the proper object type container, for example:

<objectType name="PORTLET">
    <object name="PORTLET_UNDER_TEST_PROVIDER" owner="TESTPROVIDER">
       <user name="jdoe" privilege="400"/>
        …
     </object>
</objectType>

For the object level privileges, the objectType name is set to PROVIDER or PORTLET, depending upon to which object instances you are providing access. The object name is set to the provider name or the portlet name, respectively. The object owner is set to providerui or the name of the associated provider, again respectively for providers and portlets.

Table 6-9 summarizes these rules:

6.1.7.2.1 Directory Entries in Oracle Internet Directory for OracleAS Portal

In order for security to function properly, OracleAS Portal requires the following entries in the directory's Directory Information Tree (DIT) structure:

• Default user accounts (cn=PUBLIC, cn=PORTAL, cn=PORTAL_ADMIN) are created in the identity management realm's user base (cn=Users,dc=MyCompany,dc=com^Foot 1 ). The PORTAL and PORTAL_ADMIN users are added to the DBA and PORTAL_ADMINISTRATORS groups, respectively. The PUBLIC user is created for unauthenticated users. Typically, the PUBLIC user entry is for granting viewing privileges on portal content that is accessible to any user, unrestricted.

• Group container is created within the identity management realm's group base (cn=Groups,dc=MyCompany,dc=com¹). OracleAS Portal can leverage any group in the directory, but groups are more easily accessed for display in a list of values if they are located within the OracleAS Portal group container.

  The name of the group container is derived from the following in OracleAS Portal:

  • OracleAS Portal schema name

  • Date and time when OracleAS Portal began to use Infrastructure Services

  The format of the name is:

  schema_name.yymmdd.hh24miss.ff
  

  
  

  Note: The name of the group container may have a different format for releases of OracleAS Portal older than 10g Release 1.

  
  

• Groups are created within the OracleAS Portal group container in the directory:

  • cn=AUTHENTICATED_USERS

  • cn=DBA

  • cn=PORTAL_ADMINISTRATORS

  • cn=PORTAL_DEVELOPERS

  • cn=PORTLET_PUBLISHERS

  • cn=RW_ADMINISTRATOR

  • cn=RW_DEVELOPER

  • cn=RW_POWER_USER

  • cn=RW_BASIC_USER

• Application entity (orclApplicationCommonName=application_name) is created in the root Oracle Context (cn=Portal,cn=Products,cn=OracleContext). The application password is randomly generated. OracleAS Portal uses this entity to bind to the directory when it needs to query it or perform actions against it (for example, adding a user) on behalf of the user. When OracleAS Portal binds to the directory for a user, it uses a proxy connection to connect as the user. This method ensures that the directory properly enforces the user's authorization restrictions. The OracleAS Portal application entity obtains the privileges to initiate proxy connections by its membership in the user proxy privileges group (cn=UserProxyPrivilege,cn=Groups,cn=OracleContext). The name of the application entity is derived from the schema and the time that OracleAS Portal began to use the Infrastructure Services. For example, the name of the application entity can be portal.040820.123756.096286000, where portal is the schema name and 040820.123756.096286000 is the timestamp in the yymmdd.hh24miss.ff format.

• Directory synchronization subscription A provisioning profile entry is created in the provisioning profiles node of the directory (cn=Provisioning Profiles,cn=changelog subscriber,cn=oracle internet directory). This entry indicates that the directory must notify OracleAS Portal when user or group privilege information has changed. It enables OracleAS Portal to keep its authorizations synchronized with the information stored in the directory.

  
  

  Note: When the provisioning profile is deleted from Oracle Internet Directory, the Enable directory synchronization and Send event notifications every n seconds, disappear from the Directory Synchronization section on the Global Settings page's SSO/OID tab. To navigate to the Global Settings page, in the Portal Builder, go to the Portal subtab on the Administer tab, and click the Global Settings link in the Services Portlet.

  
  

Figure 6-2 shows where the OracleAS Portal information is located in the directory's DIT structure.

Figure 6-2 OracleAS Portal DIT Structure

Description of "Figure 6-2 OracleAS Portal DIT Structure"

6.1.7.2.2 User Attributes Stored in Oracle Internet Directory

OracleAS Portal, like all other components of Oracle Application Server, relies upon the directory to store user information. All users in the directory are defined using the following object classes:

• The inetOrgPerson object class contains the entire user attributes defined by the Internet Engineering Task Force (IETF) Request for Comments (RFC) number 2798.

• The orclUser and orclUserV2 object classes contain a set of standard, additional attributes for Oracle products.

The subsequent tables show the various user attributes stored in Oracle Internet Directory. A complete list of these attributes is available in IETF RFC 2798.

6.1.7.2.3 Group Attributes Stored in Oracle Internet Directory

OracleAS Portal, like all other components of Oracle Application Server, relies upon the directory to store group information. All groups in the directory are defined using the following object classes:

• The groupOfUniqueNames object class contains all of the group attributes defined by IETF (RFC 2256).

• The orclGroup object class contains a set of standard, additional attributes for OracleAS Portal.

  
  

  Note: In OracleAS Portal 9.0.2 and subsequent releases, you cannot scope groups to a specific page group. This option was available only in OracleAS Portal 3.0.9.x and preceding releases.

  
  

Figure 6-3 shows where the OracleAS Portal information for groups is located in the directory's DIT structure.

Figure 6-3 DIT Structure for OracleAS Portal Groups

Description of "Figure 6-3 DIT Structure for OracleAS Portal Groups"

The subsequent tables show the various group attributes stored in Oracle Internet Directory.

6.1.7.2.4 Oracle Internet Directory Cache in OracleAS Portal

To improve performance, OracleAS Portal caches some directory information locally. In particular, OracleAS Portal caches the following:

• Directory connection information for OracleAS Portal

• URLs for Oracle Delegated Administration Services

• orclGUIDs of certain privilege groups for authorization checks on directory portlets (for example, the User and Group portlets)

• some Oracle Context information

• the locally selected group search and creation bases

• group memberships and default group for each user

The majority of the information cached by OracleAS Portal is fairly static (for example, directory connection information). For those items that are more dynamic, such as group memberships and default group, OracleAS Portal relies upon the Oracle Directory Integration and Provisioning agent for updates. OracleAS Portal maintains a directory synchronization subscription in the directory that flags the agent to notify it of any change events that affect OracleAS Portal security (for example, adding or deleting a user from a group).

6.1.7.2.5 User and Group Lists of Values in OracleAS Portal

The User, Group, Portal User Profile, and Portal Group Profile portlets include lists of values for users or groups. These lists of values must be populated with information stored in the directory. By default, the list of values displays the groups contained under the OracleAS Portal group container in the OracleAS Portal DIT structure. You can browse to any group in the tree, if you have the right access privileges.

The groups that are displayed in the list of values for groups depend on the privileges of the user viewing them. For example, if a user views the list of values from the Group portlet, the list only displays those groups that can be edited or deleted by that user. In OracleAS Portal 10g Release 2 (10.1.2), the implementation of the LOVs supports a callback method. This callback mechanism requires corresponding support in the Oracle Delegated Administration Services environment.

If you have upgraded from a release of OracleAS Portal earlier than 10g Release 2 (10.1.2), and if your Infrastructure and Application Server middle tier were separated onto different hosts or protocols, you may have performed additional user and group Lists of Values (LOVs) configuration to accommodate the JavaScript Origin Server Security policy.

There were two configuration options:

• Setting up of a common-domain by running the script secjsdom.sql.

• Deploying Oracle Delegated Administration Services on the middle tier.

If you have installed the appropriate Oracle Delegated Administration Services version in your environment, and have not previously implemented the configuration options mentioned in the preceding text, then no subsequent configuration steps are required in OracleAS Portal to support the LOVs on a separate host. However, if you used the configuration options mentioned previously, it is required to remove these steps. This can be done as follows:

1. If a common domain was defined, reset it by executing the secjsdom.sql script. Refer to Example C-2, "Resetting a Previously Defined Common Domain Using secjsdom.sql" for more information.

2. If OracleAS Portal has been configured to use a locally deployed Oracle Delegated Administration Services servlet, reconfigure it to point to the Infrastructure tier by running the secdaslc.sql script as follows:

   1. From the operating system prompt, go to the following directory:

      DESTINATION_MID_TIER_ORACLE_HOME/portal/admin/plsql/wwc
      
      

   2. Using SQL*Plus, connect to the OracleAS Portal schema as the owner and run the following commands:

      @secdaslc N
      commit;
      
      

If OracleAS Portal is used with an older release of Oracle Delegated Administration Services that does not support the callback method and the directory and OracleAS Portal servers reside on different domains, you have to install the required patch to the Oracle Delegated Administration Services environment to support the use of LOVs across domains.

If it is not possible, for operational purposes, to apply the patch, you can define a Common JavaScript Domain for Oracle Delegated Administration Services Lists of Values by using the secjsdom script. Refer to Section C.4, "Using the secjsdom.sql Script" for information about using this script.

6.1.7.3.1 Update Subscription Profiles for Groups Based on groupOfNames

By default, groups created in the Oracle Internet Directory by Oracle Delegated Administration Services are based on the IETF object class groupOfUniqueNames. However, there is now support for handling groups created with the object class groupOfNames as well. If your portal has an existing Oracle Directory Integration Platform subscription profile in the Oracle Internet Directory (from 9.0.2), then it would be subscribing to group modifications and deletions based on groups using groupOfUniqueNames. If any existing groups in Oracle Internet Directory are based on the groupOfNames object class you must update the Oracle Directory Integration Platform subscription profile to subscribe to the events for groups based on groupOfNames in addition to groupOfUniqueNames.

To create or update the subscription profile, run ptlconfig as follows:

ptlconfig -dad <dad> -dipreg 

This will create or update the provisioning profile and subscribe to changes for the uniqueMember and member attributes.By default, this provisioning profile is enabled.

6.1.7.4.1 Creating and updating information Stored in Oracle Internet Directory

The Oracle Delegated Administration Services provides a comprehensive interface for making updates to the directory. Authenticated users who have the appropriate privileges can access the delegated administration server through the User and Group portlets on the Administration tab in OracleAS Portal. To access these portlets, a user must be a member of the OracleDASCreateUser and OracleDASCreateGroup groups, respectively. The PORTAL and PORTAL_ADMIN users are members of both of these groups by default. AUTHENTICATED_USERS may also create groups by default.

6.1.7.4.2 Relationship Between Oracle Delegated Administration Services, mod_osso, and the OracleAS Single Sign-On

mod_osso protects URLs behind the OracleAS Single Sign-On environment by making the HTTP server effectively into a partner application. Oracle Delegated Administration Services functionality is single sign-on enabled by using mod_osso to get the user's identify from the OracleAS Single Sign-On session.

Figure 6-5 Relationship between Oracle Delegated Administration Services, mod_osso, and OracleAS Single Sign-On

Description of "Figure 6-5 Relationship between Oracle Delegated Administration Services, mod_osso, and OracleAS Single Sign-On"

mod_osso is a module of the Oracle HTTP Server that is written as a partner application. You can use mod_osso to enable applications, including OC4J applications, for single sign-on. You achieve this by configuring mod_osso with Oracle HTTP Server directives to restrict access to the OC4J application URLs.

Oracle Delegated Administration Services is implemented as an OC4J application, which relies on mod_osso to authenticate users attempting access. When a user attempts to access an Oracle Delegated Administration Services dialog (for example, a list of users or groups, or the Create User form), mod_osso checks whether the user has been authenticated. mod_osso performs no authorization checks other than checking for authentication. If the user has not been authenticated, mod_osso, which is an OracleAS Single Sign-On partner application, redirects the user's request to OracleAS Single Sign-On. OracleAS Single Sign-On either:

• Finds a cookie that indicates the user has been properly authenticated and sends back an authenticated token to mod_osso.

• Or, if no cookie has been created yet, it brings up the login page to authenticate the user.

Once the user has been properly authenticated, they are redirected by mod_osso to the requested Oracle Delegated Administration Services URL. Oracle Delegated Administration Services then becomes accessible to the user and enforces the user's privileges, typically relying on access control items in the Oracle Internet Directory.

Oracle Delegated Administration Services URLs

The first request to Oracle Delegated Administration Services from a user session in OracleAS Portal is redirected to the OracleAS Single Sign-On so that mod_osso, which acts as a partner application on behalf of Oracle Delegated Administration Services, can establish the identity of the user. OracleAS Single Sign-On constructs a URLC token that includes the requested Oracle Delegated Administration Services URL. There is about a 2K limit on the length of the URLC token imposed by Internet Explorer. As such, the length of the Oracle Delegated Administration Services URL is also limited. To provide a seamless integration with Oracle Delegated Administration Services, OracleAS Portal includes the URLs of the current portal page and the portal home page within this Oracle Delegated Administration Services URL. A typical Oracle Delegated Administration Services URL appears as follows:

http://myportal.us.abc.com:7777/oiddas/ui/oracle/ldap/das/group/AppCreateGroupInfo
Admin?doneURL=https%3A%2F%2Fwebsvr.us.abc.com%3A5001%2Fportal%2Fpage%3F_
pageid%3D6%2C1%2C6_12%3A6_18%26_dad%3Dportal_9_0_2_6_7%26_schema%3DPORTAL_9_0_2_
6_7&homeURL=https%3A%2F%2Fwebserver.us.abc.com%3A5001%2Fportal%2Fpage%3F_
pageid%3D6%2C1%2C6_12%3A6_18%26_dad%3Dportal_9_0_2_6_7%26_schema%3DPORTAL_9_0_2
_6_7&parentDN=cn%3Dportal_9_0_2_6_
7.s901dev0.portalserver.us.abc.com%2Ccn%3Dgroups%2Cdc%3Dus%2Cdc%3Doracle%2Cdc%3Dco
m&enablePA=true 

When this URL is included in the URLC token, which is then encrypted for security reasons, the length of the resulting token easily approaches the 2K threshold. If it exceeds this limit, the browser may show an error.

There is no fixed size for the URL. However, if you see browser errors when performing Oracle Delegated Administration Services operations, you should consider reducing the size of various parts that comprise the portal URL as this will help ensure that the URL does not exceed the 2k limit. For example, limit hostnames to 8 characters or less and DAD names to 6 characters or less.

In the event that you encounter this problem, the workaround is to log in to Oracle Delegated Administration Services first through a shorter URL, such as the Directory Administration link in the Services portlet. Any subsequent access to Oracle Delegated Administration Services will then not require SSO redirection, and will succeed.

6.1.7.9.1 Example: Defining a User Administrator Role

Suppose that you want to create a role with the appropriate privileges for a user administrator. You could create such a role by following these steps:

Step 1: Create a group.

You begin by creating a group in the usual manner:

1. From Portal Builder (the Design-Time pages), click Administer, if you are not already on the Administer tab.

2. Click Create New Group in the Group portlet and the Create Group page appears, as shown in Figure 6-11.

   Figure 6-11 Create Group Page

   
   Description of "Figure 6-11 Create Group Page"
   
   

3. Enter the required fields (indicated by asterisks).

4. On the Create Group page, click Privilege Assignment to go to that section and choose the following privileges, as shown in Figure 6-12:

   • Allow user creation

   • Allow user editing

   • Allow user deletion

   Figure 6-12 Privilege Assignment Section of the Create Group Page

   
   Description of "Figure 6-12 Privilege Assignment Section of the Create Group Page"
   
   

5. Click Submit.

Step 2: Assign the Manage privilege for all user profiles.

After you create the user administrator group, you need to assign it the Manage privilege for all user profiles. This privilege is the only global privilege that you need to assign to this group for user administration.

1. From Portal Builder (the Design-Time pages), click Administer, if you are not already on the Administer tab.

2. From the Portal Group Profile portlet, enter the name of your newly created group and click Edit.

3. Click Privileges to go to that tab.

4. Scroll down to the Administration Privileges section, shown in Figure 6-13. From the list next to All User Profiles, choose Manage.

   Figure 6-13 Administration Privileges Section of the Edit Group Profile Page

   
   Description of "Figure 6-13 Administration Privileges Section of the Edit Group Profile Page"
   
   

5. Click OK.

Step 3: Make the group a role.

Now that you have created a group representing the user administrator role, you need to enable it as a role so it appears in the list of roles on the Create User page.

1. From Portal Builder (the Design-Time pages), click Administer, if you are not already on the Administer tab.

2. In the Services portlet, click Directory Administration.

3. Click Configuration to display that tab.

4. Click User Entry.

5. Click Next until you reach Step 5 of 5, Configure Roles, of the wizard, as shown in Figure 6-14.

6. Click Add Role to choose the new group and add it to the list of roles.

   Figure 6-14 Configure Roles Page

   
   Description of "Figure 6-14 Configure Roles Page"
   
   

7. Click Finish. Your group will now appear in the list of public groups on the Create User page.

Step 4: Hide detailed privilege assignment section.

To encourage the usage of roles rather than direct privilege assignment, you can turn off the detailed privilege assignment section of the Create Users page. To implement this change, you need to update a configuration entry in the OracleAS Portal schema. This setting stops Oracle Delegated Administration Services from displaying the Privilege Assignment section in the Create/Edit User page when it is called from an OracleAS Portal administration page.

1. Log in to the PORTAL schema through SQL*Plus.

   
   

   Note: The PORTAL schema password is stored in the Oracle Internet Directory and the entry may be viewed by an administrator using the oidadmin utility with the following path under Entry Management: OrclResourceName=PORTAL,orclReferenceName=iasdb.myhost.au.oracle.com,cn=IAS Infrastructure Databases,cn=IAS,cn=Products,cn=OracleContext

   
   

2. Invoke the following commands to set the das_enable_pa variable in OracleAS Portal's Oracle Internet Directory configuration preference store:

   $ sqlplus
   ...
   Enter user-name: portal
   Enter password: 
   ...
   SQL> set serverout on
   SQL> exec wwsec_oid.set_preference_value('das_enable_pa', 'N');
   
   PL/SQL procedure successfully completed.
   
   SQL> commit;
   
   Commit complete.
   
   SQL> exit
   ...
   
   

3. Because the User Portlet is cached in OracleAS Web Cache and the OracleAS Portal middle-tier file system cache, you must invalidate the cached version of the portlet before you are done. Updating the configuration parameter changes the behavior of the portlet, but updating the parameter does not invalidate the cache. Follow these steps to invalidate the cached version of the User Portlet:

   1. Log in to OracleAS Portal as a user with administrator privileges.

   2. Go to the Builder.

   3. Click the Administration tab.

   4. From the Portal tab, open Global Settings and navigate to the SSO/OID tab.

   5. Scroll to the bottom of the page.

   6. Check Refresh Cache for the Oracle Internet Directory parameters.

   7. Click Apply.

   
   

   See Also: Oracle Application Server Web Cache Administrator's Guide

   
   

Step 5: Validate your changes.

Once you have performed steps 1 through 4, go to the Create User page to verify that your user administrator group appears there. Note how the other OracleAS Portal administrative roles, or groups, are already pre-seeded into the Roles Assignment list on this page.

6.1.8.3.1 Portal Server Authentication

Portal Server Authentication restricts access to a provider to a small number of recognized computers. This method compares the IP address or the hostname of an incoming HTTP message with a list of trusted hosts. If the IP address or hostname is in the list, the message is passed to the provider. If not, it is rejected before reaching the provider.

6.1.8.3.2 Message Authentication

Message authentication works by appending a checksum based on a shared key to provider messages. When a message is received by the provider, the authenticity of the message is confirmed by calculating the expected value of the checksum and comparing it with the actual value received. If the values are the same, the message is accepted. If they are different the message is rejected without further processing. The checksum includes a time stamp to reduce the chance of a message being illegally recorded in transit and resent later.

6.1.8.3.3 Message encryption

Message encryption relies on the use of the HTTPS protocol for communication between the provider and OracleAS Portal. Messages are strongly encrypted to protect the data therein. While encryption provides a high level of security, it also of necessity impacts performance.

6.1.8.4.1 Partner Application

A partner application shares the same OracleAS Single Sign-On as OracleAS Portal for authentication. Sharing OracleAS Single Sign-On instances means that when a user is already logged into OracleAS Portal, their identity can be asserted to the partner application without logging in again.

Partner applications tightly integrate with OracleAS Single Sign-On. When a user attempts to access a partner application, the partner application delegates the authentication of the user to OracleAS Single Sign-On. Once authenticated with a valid user name and password, a user need not provide a user name or password when accessing other partner applications that share the same OracleAS Single Sign-On instance. OracleAS Single Sign-On determines that the user was successfully authenticated and indicates successful authentication to the other partner applications.

The partner application provider trusts OracleAS Portal to authenticate the user on the provider's behalf. This relationship is possible because OracleAS Portal is, itself, a partner application. Partner application providers must trust OracleAS Portal to authenticate the user in this way because the provider cannot perform the authentication itself. Authenticating the user directly requires the provider to redirect the browser to OracleAS Single Sign-On and provide success and failure URLs. This method is not possible due to the provider architecture. The primary reason for it is that the authentication occurs in response to an API call from OracleAS Portal to the provider. OracleAS Single Sign-On cannot imitate that call upon successful authentication to the initSession()/dologin() method to complete its normal processing.

Authentication of users in partner applications differ from conventional applications. Partner applications delegate user authentication to OracleAS Single Sign-On. If the user has not been authenticated, OracleAS Single Sign-On displays a login page prompting the user to enter a user name and password. The login page submits the user name and password back to OracleAS Single Sign-On.

If successfully authenticated, OracleAS Single Sign-On creates a special cookie containing information about the user. For security, OracleAS Single Sign-On encrypts the contents of the cookie. The cookie is sent back to the user's browser but is scoped such that only OracleAS Single Sign-On can access it. It is not passed to any other listeners. After creating the cookie, OracleAS Single Sign-On redirects the Web browser to the success URL specified by the partner application. At this point, the partner application creates an application session cookie which contains information the application needs to reestablish the session later. Upon making subsequent requests to the partner application, it detects the presence of the partner application session cookie and from it knows that the user is already authenticated.

If the user later accesses another partner application, that application looks for its application specific session cookie. If the cookie is not found, the application redirects the request to OracleAS Single Sign-On as described previously. This time OracleAS Single Sign-On detects the presence of the user's OracleAS Single Sign-On cookie. This cookie indicates that the user is already authenticated and OracleAS Single Sign-On redirects the browser to the success URL of the second partner application without prompting the user for credentials again. At this point, the partner application creates its own application specific session cookie.

Advantages

• Provides the tightest integration with OracleAS Portal and OracleAS Single Sign-On.

• Provides the best OracleAS Single Sign-On experience to users.

• Provides the most secure form of integration because user names and passwords are not transmitted between the portal and the provider.

• The application and the portal share the same user repository, which reduces user maintenance.

Disadvantages

• The application must share the same user repository as OracleAS Portal even though the application's user community may be a subset of the portal's user community. This minor issue can be addressed because you can restrict access to the portal pages that expose the application to the application's user community.

• The application can only be tightly integrated with one or more OracleAS Single Sign-On if they share the same user repository.

Implementation Techniques

You make an application a partner application by protecting its URLs using mod_osso. Once configured, mod_osso restricts access to URLs and handles such things as the redirection to OracleAS Single Sign-On and the creation of cookies.

mod_osso

mod_osso is a general purpose Oracle HTTP Server module and a partner application of OracleAS Single Sign-On. It uses OracleAS Single Sign-On to do the authentication. The module does all the communication and handling of cookies between the Oracle HTTP Server and OracleAS Single Sign-On. If mod_osso is configured to protect the URLs of a Web application, then the application effectively becomes a partner application.

OracleAS Portal is also a partner application and uses OracleAS Single Sign-On to authenticate users. Provided OracleAS Portal and mod_osso use the same OracleAS Single Sign-On instance, the user can access either the Web application or OracleAS Portal by logging in to either one, that is, they need only login once to be able to access both the Web application and OracleAS Portal.

Advantages 

• mod_osso is simple to set up.

• You need no additional code in the application.

• New features to the OracleAS Single Sign-On environment are exposed through simple dynamic directives.

• mod_osso generates a partner application cookie and does all the cookie handling.

• mod_osso secures the partner application and deep links from the partner application provider.

Disadvantages  

• Although not neccessarily a drawback, mod_osso can only be used with Web applications.

6.1.8.4.2 External Application

An External Application is an application that uses a different authentication mechanism than OracleAS Portal. The application may use a different instance of OracleAS Single Sign-On than the used by OracleAS Portal or some other authentication method. In either case, OracleAS Single Sign-On stores user name mappings, passwords, and any other required credentials to authenticate the user in each external application. When a user is already logged into OracleAS Portal, they will be logged into the external application without having to enter their user name or password.

Applications that manage their own authentication of users can be loosely integrated with OracleAS Single Sign-On by registering as external applications. An external application can be exposed as a provider using the Oracle Application Server Portal Developer Kit so that it may be accessed from a portlet on a page. External application providers are only available to Web providers.

When a previously authenticated user accesses an external application for the first time, OracleAS Single Sign-On attempts to authenticate the user with the external application. The authentication is performed by submitting an HTTP request that combines the registration information and the user's user name and password for the application. If the user has not yet registered their user name and password for the external application, OracleAS Single Sign-On prompts the user for the required information before making the authentication request. When a user supplies a user name and password for an external application, OracleAS Single Sign-On maps the new user name and password to the user's OracleAS Portal user name and stores them. The next time the user needs to access the external application the stored credentials are used.

Advantages

• Allows integration with many portals. If there is a preferred portal, the application could be integrated as a partner application of that portal and an external application of other portals.

• Provides a single sign-on experience for users. However, users still need to maintain different user names and passwords. In addition, the external application user name mapping must be maintained.

• Allows integration with multiple portals independent of their user repositories and single sign-on mechanisms.

Disadvantages

• External applications do not share the same user repository as the portal, which requires additional maintenance of user information.

• The user name and password is transmitted to the provider in plain text. This approach is not as secure as a partner application.

• The application must be written using a technology that can be easily integrated with Java or PL/SQL.

6.1.8.4.3 No Application Authentication

In this case, the provider trusts the portal sending the requests. The provider can determine if the user is logged in and the portal user name, but the application has not authenticated the user.

Advantages

• You can implement this form of integration most easily and very fast.

Disadvantages

• Provides the weakest integration with OracleAS Portal.

6.1.8.5.1 Advantages

• ACLs offer a simple, yet very powerful, mechanism to secure portal objects.

• Because the management of users and groups is centralized, you do not have to change the ACLs as the membership of groups changes.

6.1.8.5.2 Disadvantages

ACLs are applied at the provider or portlet level. You cannot vary the security rules for a portlet depending on the portal page on which the portlet is placed.

6.1.8.6.1 Advantages

With portlet security methods, you can have a portlet produce different output depending on the user's level of authorization.

6.1.8.6.2 Disadvantages

Most security manager implementations use the authorization level or some other user specific element in an incoming message. A check of this type could be bypassed by an entity imitating OracleAS Portal.

6.1.8.7.1 Advantages

• This approach only allows trusted hosts to access the provider.

• You can set the restrictions up easily.

6.1.8.7.2 Disadvantages

• OracleAS Web Cache does not have IP address checking capability. If you have OracleAS Web Cache in front of a provider, a client on any host can send show requests to OracleAS Web Cache.

• You can circumvent this approach by sending messages to a provider containing fake IP addresses and hostnames. This method is tricky to carry out effectively because return messages will go to the computer with the copied IP address, but it can still cause problems.

6.1.8.8.1 Advantages

Message authentication ensures that the message received by a provider comes from a legitimate OracleAS Portal instance.

6.1.8.8.2 Disadvantages

• Message authentication can cause administration problems if a provider serves more than one OracleAS Portal instance.

• Message authentication has a performance implication if made very secure by having a short session timeout.

6.1.8.10.1 Advantages

• SSL encrypts the contents of a portlet during the transmission of the data from the provider to the Parallel Page Engine. To further secure the portlet contents, the surrounding page should be invoked by a SSL based request.

6.1.8.10.2 Disadvantages

• Encryption has a performance impact on OracleAS Portal.

• If used, encryption requires all portlets from a provider to use HTTPS even if some of the content is public.

You will find additional information on security for your Web providers in the papers:

• Overview of Provider Security

• Overview of Password Authenticated Applications

on OTN, http://www.oracle.com/technology/.

6.3.2.1.1 Overview of SSL Configurations

OracleAS Portal uses a number of different components (such as the Parallel Page Engine, Oracle HTTP Server, and OracleAS Web Cache) each of which may act as a client or server in the HTTP communication. As a result, each component in the Oracle Application Server middle tier may be configured individually for the protocols of HTTPS rather than HTTP.

Interacting with OracleAS Portal involves a number of distinct network hops. These hops are as follows:

• Between the client browser and the entry point of the portal environment. That is either:

  • OracleAS Web Cache

  • Network edge hardware device such as a Reverse Proxy or SSL accelerator

• Between OracleAS Web Cache and Oracle HTTP Server of the Oracle Application Server middle tier

• Between the client browser and the Oracle HTTP Server of the OracleAS Single Sign-On or Oracle Internet Directory (or infrastructure) tier

• A loopback between the Parallel Page Engine (PPE) on the middle tier and OracleAS Web Cache or front-end Reverse proxy

• Between the Parallel Page Engine (PPE) and the Remote Web Provider producing Portlet content

• Between OracleAS Portal infrastructure and the Oracle Internet Directory

SSL Usage Restriction

External JavaServer Pages do not work with the Parallel Page Engine in a partial SSL configuration mode. They will work when SSL is used throughout OracleAS Portal. If SSL is implemented externally with a load balancing router, only internal JavaServer Pages will work. As a result, with the SSL configurations described in Section 6.3.2.1.2, "SSL to OracleAS Single Sign-On", Section 6.3.2.1.4, "SSL Throughout OracleAS Portal", and Section 6.3.2.1.5, "External SSL with Non-SSL Within Oracle Application Server", you should only use external JSPs.

Configuring Enterprise Manager Security

In all the SSL configurations discussed here, you need to perform an additional task whenever you use Enterprise Manager to monitor SSL URLs.

Follow the instructions provided in Oracle Application Server Administrator's Guide.

SSL Configuration Tool and Its Limitations

This release introduces the SSL Configuration Tool (SSLConfigTool), which helps automate many of the manual steps currently required for configuring SSL. The SSLConfigTool executable is located in the ORACLE_HOME/bin directory and its usage syntax is as follows:

SSLConfigTool ( -config_w_prompt
               | -config_w_file <input_file_name>
               | -config_w_default
               | -rollback )
               [-dry_run]
               [-wc_for_infra]
               [-secure_admin]
               [-opwd <orcladmin_pwd>]
               [-ptl_dad <dad_name>]
               [-ptl_inv_pwd <ptl_inv_pwd>]

See Oracle Application Server Administrator's Guide for more details.

Table 6-17 describes the command-line options for the SSLConfigTool command.

Rolling Back Changes Made by SSLConfigTool

If you have run SSLConfigTool in an OracleAS Infrastructure or middle-tier home earlier, you need to first roll back the changes that were made when you last ran the tool, before you can run SSLConfigTool again in that Oracle home. To roll back the changes, run SSLConfigTool as shown here in an example for Windows:

SSLConfigTool.bat -rollback -opwd <orcladmin_pwd>

Where:

• rollback is used to roll back the changes made by running SSLConfigTool in the same Oracle home earlier.

• opwd is the Oracle administrator password. If no password is specified, you will be prompted to enter the password.

The sections that follow describe the usage of the SSL Configuration Tool for all the SSL configurations. You can also perform manual steps to configure SSL, which are also described in detail.

Checks to Perform Before Configuring SSL

Before using the methods recommended to configure SSL, you must confirm that OracleAS Portal is working correctly in the default non-SSL configuration. To test this, you must ensure that the following portal tasks work without errors:

• The OracleAS Portal home page is accessible

• Users can log in to OracleAS Portal

• Edits to content are shown immediately

6.3.2.1.2 SSL to OracleAS Single Sign-On

If any connection should be secured with SSL, it is the connection between the browser and OracleAS Single Sign-On. The password should be protected by SSL in transit between the browser and OracleAS Single Sign-On. For at least a minimal level of security, you should configure your installation with this option. All of the subsequent SSL configurations assume that you have configured SSL for OracleAS Single Sign-On.

Figure 6-16 shows a configuration where OracleAS Single Sign-On is configured to use SSL.

Figure 6-16 Secured Connection to OracleAS Single Sign-On

Description of "Figure 6-16 Secured Connection to OracleAS Single Sign-On"

After you have successfully performed the checks described in "Checks to Perform Before Configuring SSL", you can use either of the following two methods to configure SSL to OracleAS Single Sign-On:

• Configuring SSL to OracleAS Single Sign-On Using SSLConfigTool

• Configuring SSL to OracleAS Single Sign-On Manually

Configuring SSL to OracleAS Single Sign-On Using SSLConfigTool

Refer to the section "SSL Configuration Tool and Its Limitations" before using SSLConfigTool.

To configure this option using the SSL configuration tool, perform the following tasks:

1. Enable SSL on the OracleAS Infrastructure that has Identity Management installed. Run SSLConfigTool in the infrastructure Oracle home, as shown in the following example for Windows:

   SSLConfigTool.bat -config_w_default -opwd <orcladmin_pwd>
   
   

   Where:

   • config_w_default is used to run the tool in silent mode using the values specified in the portlist.ini and ias.properties files.

   • opwd is the Oracle administrator password. If no password is specified, you will be prompted to enter the password.

   Enter n when prompted by the script to configure your site to accept browser requests using the SSL protocol.

   
   

   See Also: Oracle Application Server Administrator's Guide The information on enabling SSL in the Oracle Application Server Single Sign-On Administrator's Guide. If you are going to configure OracleAS Single Sign-On behind a reverse proxy server, you should refer to the information on deploying OracleAS Single Sign-On with a proxy server, in the Oracle Application Server Enterprise Deployment Guide.

   
   
   
   

   Note: In the previously described configuration of SSL, you must re-register the OracleAS Single Sign-On middle-tier partner application. Because the OracleAS Single Sign-On middle-tier partner application is still non-SSL, you must re-register it as non-SSL. Therefore, the re-registration of mod_osso needs to specify the non-SSL URL of the OracleAS Single Sign-On middle tier for the mod_osso_url parameter to ssoreg. Refer to the information on registering mod_osso in the Oracle Application Server Single Sign-On Administrator's Guide.

   
   

2. After enabling SSL on the OracleAS Infrastructure that has Identity Management installed, you must protect OracleAS Single Sign-On URLs. To do this, refer to the section "Protect Single Sign-On URLs" in Oracle Application Server Single Sign-On Administrator's Guide.

3. Run SSLConfigTool in the middle-tier Oracle home, or multiple middle-tier Oracle homes, as shown in the following example, for Windows:

   SSLConfigTool.bat -config_w_prompt -ptl_inv_pwd <ptl_inv_pwd> -opwd <orcladmin_pwd>
   
   

   Where:

   • config_w_prompt is passed to run SSLConfigTool in interactive mode.

   • ptl_inv_pwd is the portal invalidation password.

   • opwd is the Oracle administrator password. If no password is specified, you will be prompted to enter the password.

   Choose No when prompted to configure HTTPS.

4. Set the OracleAS Single Sign-On query path URL. See "Setting the OracleAS Single Sign-On Query Path URL" for the steps to be performed.

At this point, configuration is complete for SSL communication to OracleAS Single Sign-On.

Configuring SSL to OracleAS Single Sign-On Manually

To manually configure this option, refer to the information on enabling SSL in the Oracle Application Server Single Sign-On Administrator's Guide. If you are going to configure OracleAS Single Sign-On behind a reverse proxy server, you should refer to the information on deploying OracleAS Single Sign-On with a proxy server, in the Oracle Application Server Single Sign-On Administrator's Guide.

After enabling SSL on OracleAS Single Sign-On following the steps listed in the Oracle Application Server Single Sign-On Administrator's Guide, you must complete the following configuration tasks on OracleAS Portal:

• Re-Registering the OracleAS Portal Partner Application

• Setting the OracleAS Single Sign-On Query Path URL

• Conditionally Updating the Oracle Delegated Administration Services URL Base Entry in Oracle Internet Directory

• Re-Registering the Oracle HTTP Server Partner Application

Re-Registering the OracleAS Portal Partner Application

After OracleAS Single Sign-On is SSL-enabled, all OracleAS Single Sign-On partner applications need to be re-registered so that the updated SSL login URL is obtained by each partner application for subsequent authentication requests.

To re-register the OracleAS Portal partner applications, invoke ptlconfig (on the OracleAS Portal middle tier).

For example:

ptlconfig -dad portal -site

Setting the OracleAS Single Sign-On Query Path URL

OracleAS Portal maintains the URL prefix of OracleAS Single Sign-On, which accesses certain information through HTTP calls from the database using the UTL_HTTP package. These calls must be done through HTTP rather than HTTPS. As a result, even if OracleAS Portal and OracleAS Single Sign-On are configured to use HTTPS, you must still have access to an HTTP port on OracleAS Single Sign-On to support these interfaces. The calls made across this interface are required for the following reasons:

• Obtain the list of external applications to allow customization of the External Applications portlet.

• Perform the mapping of OracleAS Single Sign-On user names to external application user names.

To set this URL prefix, and the OracleAS Single Sign-On Query Path URL, perform the following steps:

1. Log on to OracleAS Portal as the portal administrator.

2. Click the Administer tab.

3. Click the Portal tab.

4. Click Global Settings in the Services portlet.

5. Click the SSO/OID tab.

6. Edit the Query Path URL Prefix under the SSO Server Settings. Enter a URL for OracleAS Single Sign-On, for example:

   http://infra.domain.com:7777/pls/orasso
   
   

Conditionally Updating the Oracle Delegated Administration Services URL Base Entry in Oracle Internet Directory

After enabling the infrastructure tier's Oracle HTTP Server for SSL, you were asked to re-register all partner applications, which includes mod_osso on the infrastructure tier. You have the option of accessing Oracle Delegated Administration Services over non-SSL or SSL. The base URL for Oracle Delegated Administration Services is stored in Oracle Internet Directory, and this determines the URL that other applications render when providing links to Oracle Delegated Administration Services functionality.

If you want Oracle Delegated Administration Services accessed over SSL, then the re-registration of mod_osso needs to specify an SSL URL for the mod_osso_url parameter to ssoreg. Refer to the information on registering mod_osso in the Oracle Application Server Single Sign-On Administrator's Guide.

If you decide that you want to access Oracle Delegated Administration Services over SSL, then the orcldasurlbase attribute in the cn=OperationURLs, cn=DAS, cn=Products, cn=OracleContext entry needs to be updated in Oracle Internet Directory to reflect this fact. This attribute value is then used by OracleAS Portal for generating subsequent Oracle Delegated Administration Services URLs. This procedure assumes that the Oracle HTTP Server on the infrastructure tier is also listening on an HTTPS port.

1. For this step, you need Oracle Directory Manager (Integrated Management Tools : Oracle Directory Manager on Windows, or INFRA_ORACLE_HOME/bin/oidadmin on UNIX). Run the Oracle Directory Manager and log in as cn=orcladmin.

2. Navigate to Entry Management, cn=OracleContext > cn=Products > cn=DAS > cn=OperationURLs.

3. Update the orcldasurlbase entry to reflect the HTTPS port being used on the infrastructure tier, that is, https://<infrahost>:<port>/.

Once the entry is updated in Oracle Internet Directory, you must force a refresh of the portal cache, which holds the relevant Oracle Internet Directory information.

1. Logon to OracleAS Portal as a user with administrator privileges.

2. Go to the Builder.

3. Click the Administration tab.

4. From the Portal tab, open Global Settings and navigate to the SSO/OID tab.

5. Scroll to the bottom of the page.

6. Check Refresh Cache for the Oracle Internet Directory parameters.

7. Click Apply.

8. The page should refresh with the appropriate value in the DAS Host Name field.

Re-Registering the Oracle HTTP Server Partner Application

Run ssoreg to register the virtual host for which mod_osso facilitates single sign-on. The specific application URLs to be defined as partner applications within this site are defined in the file osso.conf. ssoreg is located in the directory MID_TIER_ORACLE_HOME/sso/bin.

The following example shows the usage of ssoreg on UNIX:

MID_TIER_ORACLE_HOME/sso/bin/ssoreg.sh 
-oracle_home_path MID_TIER_ORACLE_HOME
-site_name www.abc.com
-config_mod_osso TRUE
-mod_osso_url http://www.abc.com:7777
-config_file MID_TIER_ORACLE_HOME/Apache/Apache/conf/osso/osso.conf
-admin_info cn=orcladmin

On Windows you must run the ssoreg.bat batch file instead. Refer to the information on creating partner applications in the Oracle Application Server Single Sign-On Administrator's Guide.

At this point, configuration is complete for SSL communication to OracleAS Single Sign-On.

6.3.2.1.3 SSL to OracleAS Web Cache

Once you secure the OracleAS Single Sign-On communication, the next option is to secure the communication to the front door of OracleAS Portal, which is OracleAS Web Cache. In this configuration, OracleAS Web Cache can forward the request to the Oracle HTTP Server, which is acting as the OracleAS Portal middle tier, using HTTP for better performance. Similarly, the Parallel Page Engine requests for portlet content that loopback to OracleAS Web Cache can request the content using HTTP.

Figure 6-17 shows a configuration where OracleAS Web Cache is configured to use SSL.

Figure 6-17 Secured Connection to OracleAS Web Cache

Description of "Figure 6-17 Secured Connection to OracleAS Web Cache"

After you have successfully performed the checks described in "Checks to Perform Before Configuring SSL", you can use either of the following two methods to configure SSL to OracleAS Single Sign-On:

• Configuring SSL to OracleAS Web Cache Using SSLConfigTool

• Configuring SSL to OracleAS Web Cache Manually

Configuring SSL to OracleAS Web Cache Using SSLConfigTool

Before using SSLConfigTool, refer to the section "SSL Configuration Tool and Its Limitations".

To configure SSL for OracleAS Web Cache, perform the following tasks:

1. Create a Wallet. Refer to "Creating a Wallet" for details.

2. Run SSLConfigTool in the middle-tier Oracle home to setup SSL for OracleAS Web Cache, as shown in the following example for Windows:

   SSLConfigTool.bat -config_w_default -opwd <orcladmin_pwd>
   
   

   Where:

   • config_w_default is used to run the tool in silent mode using the values specified in the portlist.ini and ias.properties files.

   • opwd is the Oracle administrator password. If no password is specified, you will be prompted to enter the password.

   Enter the following values when prompted by the script:

   • y, when prompted to configure your site to accept browser requests using the SSL protocol.

   • n, when asked if your Oracle HTTP Server accepts requests in SSL protocol.

3. Register Web providers or Provider groups. See "Registering Web Providers or Provider Groups Exposed over SSL" for details.

4. Add the Web provider server certificate to the trusted certificate file. See "Augmenting the Portal Tools Trusted Certificate File" for details.

5. Enable access for Oracle Ultra Search. See "Enabling Access for Oracle Ultra Search" for details.

6. Re-register OracleAS Portal as an Oracle Ultra Search content source. See "Re-Registering OracleAS Portal as an Oracle Ultra Search Content Source" for details.

See Oracle Application Server Administrator's Guide for details.

Configuring SSL to OracleAS Web Cache Manually

To configure SSL to OracleAS Web Cache manually, perform the following steps:

• Creating a Wallet

• Securing OracleAS Web Cache

• Securing the Parallel Page Engine

• Re-Registering the Oracle HTTP Server Partner Application

• Specifying the OracleAS Portal Published Address and Protocol

• Registering Web Providers or Provider Groups Exposed over SSL

• Augmenting the Portal Tools Trusted Certificate File

• Enabling Access for Oracle Ultra Search

• Re-Registering OracleAS Portal as an Oracle Ultra Search Content Source

Creating a Wallet

The various components of OracleAS Portal use the Oracle Wallet Manager to store the certificates for the secure communication. The first step in this process is to obtain a certificate from a Certificate Authority (for example, OracleAS Certificate Authority, Verisign, GTE CyberTrust, and so on).

Obtaining a Certificate To obtain a digital certificate from the relevant signing authority, you submit a Certificate Request (CR) uniquely identifying your server to the signing authority.

1. Open the Oracle Wallet Manager in the middle-tier MID_TIER_ORACLE_HOME. On UNIX, enter owm from the command prompt. On Windows, invoke Oracle Wallet Manager from the Start menu.

2. Choose Wallet > New.

   On UNIX, the wallet is stored in the following location by default:

   /etc/ORACLE/WALLETS/<Account Name creating the Wallet>
   
   

   On Windows, the wallet is stored in the following location by default:

   \Documents And Settings\<Account Name creating the Wallet>\ORACLE\WALLETS
   
   

3. Create a password for the wallet.

4. Click Yes to accept the option to create a CR.

5. Fill out the Certificate Request dialog with details that uniquely identify your server. Table 6-18 shows some sample values for the various fields in the Certificate Request dialog.

   Table 6-18 Sample Values for Fields in the Certificate Request Dialog

   Field Name	Sample Values
   Common Name	www.abc.com
   Organizational Unit	DOCUMENTATION
   Organization	Oracle Corporation
   Locality/City	Redwood Shores
   State/Province (Note: Do not use abbreviations; the value specified for state or province must be completely spelled out)	California

   
   

6. Click OK. A dialog will inform you that the certificate request was created successfully. The Certificate node in the Wallet Navigator will change to Requested.

7. Save the wallet in a convenient directory, for example:

   MID_TIER_ORACLE_HOME\webcache\wallets\portalssl
   
   

8. Send the CR to the chosen Certificate Authority (CA).

   
   

   Note: Certificates are issued by trusted third parties known as Certification Authorities (CA), for example, OracleAS Certificate Authority or Verisign. For details on how to obtain a certificate, check the appropriate vendor's Web site.

   
   

Cutting and Pasting

Depending on the CA, you may need to cut and paste the certificate request in their Web page or export the CR to a file for subsequent uploading to the site.

1. Select the Certificate node in the Wallet Navigator.

2. Highlight the Certificate text in the Certificate Request field. Make sure to include the BEGIN/END NEW CERTIFICATE REQUEST lines.

3. Copy and paste into the Certificate Request field on the CA's Web site.

Exporting Certificate Request

To export the certificate request:

1. Choose Operations > Export Certificate Request.

2. Choose the Name and Location of the CR file. A Status Line Message will confirm the successful export of the CR.

3. Once exported, the CR can be uploaded to the CA's Web site.

Managing Trusted Certificates Once the CA has processed the request, the User Certificate is forwarded to you either as text within an e-mail or as a simple file that is downloaded from a given Web page.

Importing Trusted Certificate (if necessary)

To import the trusted certificate:

1. Choose Operations > Import Trusted Certificate.

2. Based on the CA, choose Paste the Certificate or Select a file that contains the certificate.

3. Select the appropriate certificate file or paste in the text from the e-mail. Oracle Wallet Manager expects base-64 encoded root certificates. If you do not have a base-64 encoded root certificate, then you must perform the steps described in the "Changing Trusted Certificate Format (if necessary)" section.

4. Click OK.

A status line message should appear indicating that the certificate was successfully imported. When you import the server specific User Certificate, the certificate node in the tree structure should also display as Ready.

Changing Trusted Certificate Format (if necessary)

If the certificate import fails, then it is possible that the Certificate is in a format that the Oracle Wallet Manager does not support. In this case, you need to convert it to a supported format before importing. The easiest way to do this is through the certificate Import and Export Wizards within a browser. The following steps are for the Internet Explorer browser:

1. In Internet Explorer, select Tools > Internet Options....

2. Click the Content tab.

3. Click Certificates....

4. Click the Trusted Root Certification Authorities tab.

5. Select Import... and follow the wizard to import the certificate.

6. Highlight the newly imported certificate from the list.

7. Click Export... and follow the wizard to the Export File Format page.

8. Choose Base-64 encoded X.509.

9. Click Next and give the certificate a file name.

10. Click Next.

11. Click Finish.

12. In Oracle Wallet Manager, choose Operations > Import Trusted Certificate.

Once the Trusted Root Certificate has been successfully imported into the Oracle Wallet Manager you may then import the server specific User Certificate.

Importing Server's User Certificate

To import the server's user certificate:

1. Choose Operations > Import User Certificate.

2. Based on the CA, choose Paste the Certificate or Select a file that contains the certificate.

3. Select the appropriate certificate file or paste in the text from the e-mail.

4. Click OK.

A status line message should appear indicating that the User Certificate has been successfully imported.

Having imported the certificate, it is important to save the wallet with the Autologin functionality enabled. This step is required because OracleAS Web Cache accesses the wallet as the process starts and the wallet password is not held by OracleAS Web Cache. If this property is not set, OracleAS Web Cache immediately shuts down if running in SSL mode. To set this property, perform the following steps:

1. Choose the Trusted Certificate you just imported from the list in the Oracle Wallet Manager.

2. Check Wallet > AutoLogin, if it is not already checked.

3. Choose Wallet > Save.

Securing OracleAS Web Cache

The sections that follow describe how to configure OracleAS Web Cache to accept SSL connections.

Configuring OracleAS Web Cache SSL Port To Configure the OracleAS Web Cache SSL port, perform the following steps:

1. From the OracleAS Web Cache administration page, click the Listen Ports link in the Ports section.

2. To add the SSL port, click Add... and enter the following information:

   • IP Address: ANY

   • Port Number: SSL port that Web Cache will listen on

   • Protocol: HTTPS

   • Require Client-Side Certificate: No (unchecked)

   • Wallet: Path to the Oracle Wallet directory containing the SSL server certificate

3. Click Submit.

For more information on the procedure in the preceding text, refer to "Task 3: Configure HTTPS Operations Ports for the Cache" in Chapter 8, "Specialized Configurations" of the Oracle Application Server Web Cache Administrator's Guide.

Defining a Site for the Published SSL Hostname and Port As there is no out-of-box default SSL configuration, you need to add a Site definition for the SSL-based Site that OracleAS Web Cache will be caching. To add a site definition, perform the following steps:

1. From the OracleAS Web Cache administration page, click Site Definitions under Origin Servers, Sites, and Load Balancing.

2. Define a Site where Host Name is the hostname seen by the browser.

   This is the load balancing router or reverse proxy server name for configurations that use a load balancing router or other reverse proxy, or it is the OracleAS Web Cache hostname in a configuration where OracleAS Web Cache receives browser requests.

3. Set Port to the HTTPS port addressed by the browser requests.

4. Enter Site information as follows:

   URL Path Prefix: Leave blank

   HTTPS Only Prefix: Leave blank

   Client-Side Certificate: Not required

   URL Parameters to Ignore: Leave blank

   Default Site: Yes

   Create Alias from Site Name with/without www: No

5. Click Submit.

6. Remove any sites that are no longer applicable to your modified configuration, including the default, out-of-the-box non-SSL site.

For more information on the procedure in the preceding text, refer to:

• The section on creating a site for HTTPS requests for the cache, in the Oracle Application Server Web Cache Administrator's Guide.

• The section on creating site definitions in the Oracle Application Server Web Cache Administrator's Guide.

Adding Site Aliases Site aliases are necessary if content is cached across a number of different hostnames, or ports, or both, but which actually refer to the same logical content. For example, when the PPE makes a request for a portlet, and this portlet is requested on a non-SSL port, but the main Site is accessed over SSL, then an alias entry is needed. This equates the content accessed through the Site with SSL, to the content accessed over non-SSL. This way, invalidation requests that are sent to invalidate the content, will invalidate the content that is cached over either form of URL.

You need to create an alias for the non-SSL OracleAS Web Cache listening port for the OracleAS Web Cache SSL site. To create a site alias:

1. From the OracleAS Web Cache administration page, return to the Site Definitions page, select the newly added site, and click Add Alias.

2. Enter the same hostname as used by the site entry, and provide the non-SSL port that the PPE will use to request portlets from OracleAS Web Cache. Click Apply Changes.

3. Restart the server after making the necessary additions.

For example, if the logical site name is accessed using the URL https://portal.mycompany.com:4443, and the non-SSL Listen Port for OracleAS Web Cache is 7777, then you should select the Site with SSL Port 4443, and add an alias for it using the non-SSL port of OracleAS Web Cache (7777).

For more information on the procedure in the preceding text, refer to the section on creating site definitions in the Oracle Application Server Web Cache Administrator's Guide.

Adding Site to Server Mappings of the New Site to the Origin Server After adding a new site definition, you must add the site to server mapping for the newly defined site to the origin server. To do this:

1. From the OracleAS Web Cache Administration page, click Site-to-Server Mapping under Origin Servers, Sites, and Load Balancing.

2. Select the first option of the Site-to-Server Mapping table.

3. Click Insert Above.. to bring up the Edit/Add Site-to-Server Mapping dialog window.

4. Select the Site you are mapping from the drop-down list, which should be the OracleAS Web Cache site with the SSL port. For example, if your logical site name is https://portal.mycompany.com:4443, then select the site with Host Name portal.mycompany.com and Port 4443.

5. In the Select Application Web Servers field, select the non-SSL Origin Server to which requests should be routed for content. For example, if the origin server is running on port 7778 on host portal.mycompany.com, then select portal.mycompany.com:7778 HTTP.

6. Click Submit to close the dialog box and see the new mapping appear in Table 6-20, "Site-to-Server Mapping" of the original page.

7. Click Apply Changes.

8. Restart the server.

For more information on the procedure in the preceding text, refer to the section on mapping sites to origin servers in the Oracle Application Server Web Cache Administrator's Guide.

Securing the Parallel Page Engine

In this configuration, you need to configure the PPE to make portlet requests using HTTP requests. The sections that follow describe how to implement a partial SSL PPE configuration for this purpose. To configure the PPE, perform the following steps:

1. Open the web.xml file associated with the OC4J_PORTAL instance on the middle tier. The file is located in the following directory:

   MID_TIER_ORACLE_HOME\j2ee\OC4J_Portal\applications\portal\portal\WEB-INF\
   
   

2. Add useScheme, usePort, and httpsports in additional <init-param> blocks in web.xml. The useScheme http indicates that the HTTP protocol should be used for PPE loopbacks and usePort indicates which port these non-SSL loopbacks should use. The HTTP port you specify for usePort should be the OracleAS Web Cache non-SSL HTTP port. The httpsports parameter must point to the OracleAS Web Cache HTTPS listening port. For example:

   <servlet>
   <servlet-name>page</servlet-name> 
      <servlet-class>oracle.webdb.page.ParallelServlet</servlet-class> 
      <init-param>
        <param-name>useScheme</param-name>
        <param-value>http</param-value>
      </init-param>
      <init-param>
        <param-name>usePort</param-name>
        <param-value>7777</param-value>
      </init-param>
      <init-param>
        <param-name>httpsports</param-name>
        <param-value>4443</param-value>
      </init-param>
    </servlet>
   
   

   (Optional) If you want the PPE to trust only specific certificates, add x509certfile in an additional <init-param> block in web.xml. The value of x509certfile is the absolute path to the text file containing the list of certificates which defines the group of "trusted" servers. For example:

   <servlet>
   <servlet-name>page</servlet-name> 
      <servlet-class>oracle.webdb.page.ParallelServlet</servlet-class> 
        <init-param> 
           <param-name>x509certfile</param-name> 
           <param-value>C:\mySSLconfig\trustedCerts.txt</param-value>
        </init-param>
    </servlet>
   
   

   
   

   Note: If you choose not to implement x509certfile, the PPE trusts any SSL certificate.

   
   

3. Save the web.xml file.

Re-Registering the Oracle HTTP Server Partner Application

Run ssoreg to register the virtual host for which mod_osso facilitates single sign-on. The specific application URLs to be defined as partner applications within this site are defined in the file osso.conf. ssoreg is located on the middle tier in MID_TIER_ORACLE_HOME/sso/bin.

The following example shows the usage of ssoreg on UNIX:

MID_TIER_ORACLE_HOME/sso/bin/ssoreg.sh
  -oracle_home_path MID_TIER_ORACLE_HOME
  -site_name www.abc.com
  -config_mod_osso TRUE
  -mod_osso_url https://www.abc.com:4443
  -config_file MID_TIER_ORACLE_HOME/Apache/Apache/conf/osso/osso.conf
  -admin_info cn=orcladmin

On Windows you must run the ssoreg.bat batch file instead. Refer to the information on creating partner applications in the Oracle Application Server Single Sign-On Administrator's Guide.

At this point, configuration is complete for SSL communication to OracleAS Web Cache.

Specifying the OracleAS Portal Published Address and Protocol

To specify the published address for OracleAS Portal with the modified port for SSL, you need to use Oracle Enterprise Manager as follows:

1. Navigate to the Oracle Enterprise Manager 10g Application Server Control Console.

2. Click the Standalone Instance with the Oracle Application Server that is running the OracleAS Portal middle tier.

3. Click the OracleAS Portal system component.

4. Under Administration, click Portal Web Cache Settings.

5. For Listen Port, enter the OracleAS Web Cache SSL port number.

6. For Listening Port SSL Enabled, choose Yes.

7. Click OK. The OracleAS Portal schema is updated with the setting and the Oracle Enterprise Manager 10g target instance is updated to use HTTPS for its URL tests.

   If at a later time you choose to switch to HTTP, you would perform this same procedure and return Listening Port SSL Enabled to No.

   
   

   Notes: This procedure updates the settings in the iasconfig.xml file. See Appendix A, "Using the Portal Dependency Settings Tool and File" for more information about iasconfig.xml.

   
   

8. Edit httpd.conf as follows:

   1. Access the Application Server Control Console.

   2. Click the link for the application server where OracleAS Portal is installed.

   3. Click the HTTP Server link.

   4. Click the Administration link.

   5. Click Advanced Server Properties.

   6. Select httpd.conf.

   7. Scroll to the bottom of the file and enter the following LoadModule directive:

      On UNIX:

      LoadModule certheaders_module libexec/mod_certheaders.so 
      
      

      On Windows:

      LoadModule certheaders_module modules/ApacheModuleCertHeaders.dll 
      
      

      For more information on mod_certheaders, refer to the Oracle HTTP Server Administrator's Guide.

   8. Add a Virtual Host definition. This must be inserted after the LoadModule directive, as follows:

      NameVirtualHost <OHS_computer_IP_address>:<OHS_listening_port>
      
      <VirtualHost <OHS_computer_IP_address>:<OHS_listening_port>>
        ServerName <portal_site_server_name>
        Port <ssl_listening_port_for_portal_site>
        SimulateHttps On
        RewriteEngine On
        RewriteOptions inherit
      </VirtualHost>
      
      

      For example:

      NameVirtualHost 123.45.67.8:7778
      
      <VirtualHost 123.45.67.8:7778>
        ServerName w1.abc.com
        Port 4443
        SimulateHttps On
        RewriteEngine On
        RewriteOptions inherit
      </VirtualHost>
      
      

   9. Click Apply.

   10. When asked to restart Oracle HTTP Server, click Yes.

9. Run the following command to synchronize the manual configuration changes:

   MID_TIER_ORACLE_HOME/dcm/bin/dcmctl updateconfig
   
   

10. Restart your Oracle Application Server instance:

    MID_TIER_ORACLE_HOME/opmn/bin/opmnctl stopall
    MID_TIER_ORACLE_HOME/opmn/bin/opmnctl startall
    
    

Registering Web Providers or Provider Groups Exposed over SSL

Refer to "Registering Web Providers or Provider Groups Exposed over SSL" for details.

Augmenting the Portal Tools Trusted Certificate File

Refer to "Augmenting the Portal Tools Trusted Certificate File" for details.

Enabling Access for Oracle Ultra Search

Refer to "Enabling Access for Oracle Ultra Search" for details.

Re-Registering OracleAS Portal as an Oracle Ultra Search Content Source

If you use Oracle Ultra Search to crawl your portal and you reconfigure OracleAS Web Cache to use SSL, you must re-register OracleAS Portal as a content source with Oracle Ultra Search. See Section 8.2.3.2, "Registering OracleAS Portal as a Content Source" for details.

6.3.2.1.4 SSL Throughout OracleAS Portal

For installations that require the utmost security, it is possible to configure SSL throughout the system. In this configuration, the loopback from the PPE to OracleAS Web Cache uses a wallet and the hop between the PPE and the Web providers uses a certificate directly rather than through a wallet.

Figure 6-18 shows a configuration where SSL is configured throughout OracleAS Portal.

Figure 6-18 Secured Connections Throughout the System

Description of "Figure 6-18 Secured Connections Throughout the System"

After you have successfully performed the checks described in "Checks to Perform Before Configuring SSL", you can use either of the following two methods to configure SSL to OracleAS Single Sign-On:

• Configuring SSL Throughout OracleAS Portal Using SSLConfigTool

• Configuring SSL Throughout OracleAS Portal Manually

Configuring SSL Throughout OracleAS Portal Using SSLConfigTool

Refer to the section "SSL Configuration Tool and Its Limitations" before using SSLConfigTool.

To configure SSL throughout OracleAS Portal using the SSL configuration tool, perform the following tasks:

1. Create a wallet. See "Creating a Wallet" for details.

2. Enable SSL on the OracleAS Infrastructure that has Identity Management installed. Run SSLConfigTool in the infrastructure Oracle home, as shown in the following example, for Windows:

   SSLConfigTool.bat -config_w_default -opwd <orcladmin_pwd>
   
   

   Where:

   • config_w_default is used to run the tool in silent mode using the values specified in the portlist.ini and ias.properties files.

   • opwd is the Oracle administrator password. If no password is specified, you will be prompted to enter the password.

   Enter the following values when prompted by the script:

   • y, when prompted to configure your site to accept browser requests using the SSL protocol.

   • y, when asked if your Oracle HTTP Server accepts requests in SSL protocol.

   
   

   See Also: Oracle Application Server Administrator's Guide The information on enabling SSL in the Oracle Application Server Single Sign-On Administrator's Guide. If you are going to configure OracleAS Single Sign-On behind a reverse proxy server, you should refer to the information on deploying OracleAS Single Sign-On with a proxy server, in the Oracle Application Server Single Sign-On Administrator's Guide.

   
   
   
   

   Note: In the previously described configuration of SSL, you must re-register the OracleAS Single Sign-On middle-tier partner application. Because the OracleAS Single Sign-On middle-tier partner application is still non-SSL, you must re-register it as non-SSL. Therefore, the re-registration of mod_osso needs to specify the non-SSL URL of the OracleAS Single Sign-On middle tier for the mod_osso_url parameter to ssoreg. Refer to the information on registering mod_osso in the Oracle Application Server Single Sign-On Administrator's Guide.

   
   

3. Run SSLConfigTool in the middle-tier Oracle home, or multiple middle-tier Oracle homes, as shown in the following example for Windows:

   SSLConfigTool.bat -config_w_prompt -ptl_inv_pwd <ptl_inv_pwd> -opwd <orcladmin_pwd>
   
   

   Where:

   • config_w_prompt is passed to run SSLConfigTool in interactive mode.

   • ptl_inv_pwd is the portal invalidation password.

   • opwd is the Oracle administrator password. If no password is specified, you will be prompted to enter the password.

4. Register Web providers or Provider groups. See "Registering Web Providers or Provider Groups Exposed over SSL" for details.

5. Add the Web provider server certificate to the trusted certificate file. See "Augmenting the Portal Tools Trusted Certificate File" for details.

6. Enable access for Oracle Ultra Search. See "Enabling Access for Oracle Ultra Search" for details.

7. Re-register OracleAS Portal as an Oracle Ultra Search content source. See "Re-Registering OracleAS Portal as an Oracle Ultra Search Content Source" for details.

Configuring SSL Throughout OracleAS Portal Manually

To manually configure SSL throughout OracleAS Portal, perform the following tasks:

• Creating a Wallet

• Enabling OracleAS Single Sign-On for SSL

• Securing the Oracle HTTP Server

• Securing OracleAS Web Cache

• Securing the Parallel Page Engine

• Specifying OracleAS Portal Published Address and Protocol

• Re-Registering the Oracle HTTP Server Partner Application

• Associating the Federated Portal Adapter with SSL

• Registering Web Providers or Provider Groups Exposed over SSL

• Augmenting the Portal Tools Trusted Certificate File

• Enabling Access for Oracle Ultra Search

• Re-Registering OracleAS Portal as an Oracle Ultra Search Content Source

Creating a Wallet

It is possible to share a single wallet across both the listener and origin server (and all other available ports in OracleAS Web Cache) if OracleAS Web Cache and the Oracle HTTP Server are on the same computer. Conversely, specific wallets may be created for each port. In this case the two servers and ports will be sharing the same wallet specified earlier.

In some cases, such as when the Oracle HTTP Server is on a different computer than OracleAS Web Cache, you need to create a separate wallet for the Oracle HTTP Server. For this situation, refer to the steps in "Creating a Wallet" to create the wallet for the Oracle HTTP Server.

In the default case, where the Oracle HTTP Server is on the same computer as OracleAS Web Cache, you can share the wallet between the two.

Enabling OracleAS Single Sign-On for SSL

For the complete steps for enabling the single sign-on server for SSL, see Oracle Application Server Single Sign-On Administrator's Guide.

Securing the Oracle HTTP Server

You need to configure the Oracle HTTP Server as the OracleAS Web Cache's origin server to accept HTTPS-based communication. The Oracle HTTP Server implements SSL by the use of mod_ssl. As such, the configuration to use HTTPS is fairly straightforward.

The SSL configuration of the Oracle HTTP Server is defined within ssl.conf. This file may be edited directly or by using the Advanced Server Properties page under the Oracle HTTP Server node of the appropriate Oracle Application Server instance within the Oracle Enterprise Manager Administration pages. If you edit the files manually, it is recommended that you run the dcmctl utility with the following options to make sure that the file is synchronized with the Distributed Configuration Management (DCM) repository:

MID_TIER_ORACLE_HOME/dcm/bin/dcmctl updateConfig -ct ohs

1. Open ssl.conf in MID_TIER_ORACLE_HOME/Apache/Apache/conf.

2. Search for the following directives and change the values accordingly:

   Table 6-19 Wallet Entries in ssl.conf

   Default Entry	Updated Entry
   SSLWallet file: MID_TIER_ORACLE_HOME/Apache/Apache/conf/ssl.wlt/default	SSLWallet file: /Directory where the wallet has been saved

   
   

3. In ssl.conf in MID_TIER_ORACLE_HOME/Apache/Apache/conf, verify that the default virtual host for SSL communication specifies the correct, preallocated port number for SSL. When creating the corresponding Web Cache site to server mappings, you should take note of the following properties in the ssl.conf file, for example:

   Listen 4445

   Port 4444

   
   

   Note: When setting up OracleAS Portal to communicate through HTTPS, it is common to configure both the middle and infrastructure tiers to operate in this mode. You must leave an HTTP port open on the infrastructure tier for OracleAS Portal to communicate with OracleAS Single Sign-On for External Application information. This call is made directly from the repository using the UTL_HTTP package.

   
   

4. Ensure that the start mode of the Oracle HTTP Server is set to ssl-enabled in MID_TIER_ORACLE_HOME/opmn/conf/opmn.xml. For example:

   <ias-component id="HTTP_Server">
      <process-type id="HTTP_Server" module-id="OHS">
         <module-data>
            <category id="start-parameters">
               <data id="start-mode" value="ssl-enabled"/>
            </category>
         </module-data>
         <process-set id="HTTP_Server" numprocs="1"/>
      </process-type>
   </ias-component>
   
   

Securing OracleAS Web Cache

The sections that follow describe how to configure OracleAS Web Cache to accept SSL connections and forward SSL requests to the SSL-enabled origin server.

Configuring the OracleAS Web Cache SSL Port To configure the OracleAS Web Cache SSL port, perform the following steps:

1. From the OracleAS Web Cache Administration page, click the Listen Ports link in the Ports section.

2. To add the SSL port, click Add... and enter the following information:

   IP Address: ANY

   Port Number: SSL port that Web Cache is listening on. This property maps to the port setting (Port number 4444, as in the earlier example) in the HTTP server's ssl.conf file.

   Protocol: HTTPS

   Require Client-Side Certificate: No (unchecked)

   Wallet: Path to the directory where the SSL server certificate is stored

3. Click Submit.

For more information on the procedure in the preceding text, refer to the section on configuring HTTPS operations ports for the cache, in the Oracle Application Server Web Cache Administrator's Guide.

Adding the SSL Origin Server To add the SSL origin server:

1. From the OracleAS Web Cache administration page, click Origin Servers under Origin Servers, Sites, and Load Balancing.

2. Click Add... to add the SSL Origin Server.

3. Enter the information as follows:

   Host Name: Physical hostname of the computer in which Oracle HTTP Server is running

   Port: Oracle HTTP Server's SSL listen port. This maps to the Listen Parameter (Port number 4445, as in the earlier example) in the ssl.conf file.

   Routing: Enable

   Capacity: 100

   Failover Threshold: 5

   Ping URL: /

   Ping Interval: 10

   Protocol: HTTPS

4. Click Submit.

For more information on the procedure in the preceding text, refer to the section on configuring Origin Server, Load Balancing, and Failover Settings, in the Oracle Application Server Web Cache Administrator's Guide.

Defining a Site for the Published SSL Host Name and Port As there is no out-of-box default SSL configuration, you need to add a site definition for the SSL-based Site that OracleAS Web Cache will be caching. To define a site, perform the following steps:

1. From the OracleAS Web Cache Administration page, click Site Definitions under Origin Servers, Sites, and Load Balancing.

2. Define a site where Host Name is the hostname seen by the browser, which would be the OracleAS Web Cache hostname.

3. Set Port to the HTTPS port addressed by the browser requests, which would be the OracleAS Web Cache SSL listen port (Port number 4444, as in the earlier example).

4. Enter site information as follows:

   HTTPS Only Prefix: Leave blank

   Client-Side Certificate: Not required

   Default Site: Yes

   Create Alias from Site Name with/without www: No

   URL Path Prefix: Leave blank

   URL Parameters to Ignore: Leave blank

5. Click Submit.

6. Remove any sites that are no longer applicable to your modified configuration.

For more information on the procedure in the preceding text, refer to:

• The section on creating a site for HTTPS requests for the cache, in the Oracle Application Server Web Cache Administrator's Guide.

• The section on creating site definitions, in the Oracle Application Server Web Cache Administrator's Guide.

Adding Site to Server Mappings of the New Site to the Origin Server After adding a new site definition, you must add the site to server mapping for the newly defined site to the origin server. To do this:

1. From the OracleAS Web Cache Administration page, click Site-to-Server Mapping under Origin Servers, Sites, and Load Balancing.

2. Select the first option of the Site-to-Server Mapping table.

3. Click Insert Above.. to bring up the Edit/Add Site-to-Server Mapping dialog window.

4. Select the Site you are mapping from the drop-down list, which should be the OracleAS Web Cache site with the SSL port.

5. Check the Origin Server that you added in the previous step, entitled "Adding the SSL Origin Server", to which requests should be routed for content.

6. Click Submit to close the dialog box and see the new mapping, as shown in Table 6-20 of the original page.

   Table 6-20 Site-to-Server Mapping

   	Site			Origin Server
   Host Name	Port	ESI Content Policy	Host Name	Port	Proxy
   www.mycompany.com	4444	Unrestricted	www.mycompany.com	4445	No

   
   

For more information on the procedure in the preceding text, refer to the section on mapping sites to origin servers, in the Oracle Application Server Web Cache Administrator's Guide

Adding Wallet Path for the Origin Server Wallet You must enter the wallet path in the Origin Server Wallet page, by performing the following steps:

1. From the OracleAS Web Cache Administration page, click Origin Server Wallet under Origin Servers, Sites, and Load Balancing.

2. Select the option for the Cache Name to change its wallet path.

3. Click Edit Selected to display the Edit Origin Server Wallet dialog window.

4. Enter a valid Wallet Directory. For example, use the wallet directory path specified on the Listen Ports page.

5. Click Submit to close the dialog window. The new wallet directory path is displayed in the table on the Origin Server Wallet page.

Securing the Parallel Page Engine

In this configuration, SSL is used throughout as the request comes to OracleAS Web Cache through HTTPS and the PPE loops back over HTTPS as well. The server specifies the chain that goes with its certificate. As long as the chain is valid and leads to a self-signed root certificate, it is validated without determining whether it is trusted, assuming that you have not loaded any trust points into it.

To implement this configuration, perform the following steps on the OracleAS Portal middle tier:

1. Open the ssl.conf file, located in the following directory:

   MID_TIER_ORACLE_HOME/Apache/Apache/conf/
   
   

2. Add SSLWallet. For example:

   SSLWallet file:/usr/local/adeviews/webdb/webdb_3000_ias902PW/Apache/Apache/conf/ssl.wlt/default
   

   
   

   See Also: For more information about SSLWallet, and httpd.conf, see the Oracle HTTP Server Administrator's Guide.

   
   

3. Open the web.xml file associated with the OC4J_Portal instance on the middle tier.

   MID_TIER_ORACLE_HOME\j2ee\OC4J_Portal\applications\portal\portal\
   WEB-INF\web.xml
   
   

4. Add httpsports in an additional <init-param> block in web.xml. This should point to the OracleAS Web Cache HTTPS listening port. For example:

   <servlet>
   <servlet-name>page</servlet-name> 
      <servlet-class>oracle.webdb.page.ParallelServlet</servlet-class> 
      <init-param>
        <param-name>httpsports</param-name>
        <param-value>4443</param-value>
      </init-param>
    </servlet>
   

   
   

   Note: If your current web.xml file contains the useScheme and usePort directives, you need to remove them. The configuration with SSL throughout should only use the httpsports directive.

   
   

5. (Optional) If you want the PPE to trust only specific certificates, add x509certfile in an additional <init-param> block in web.xml. The value of x509certfile is the absolute path to the text file containing the list of certificates which defines the group of "trusted" servers. For example:

   <servlet>
   <servlet-name>page</servlet-name> 
      <servlet-class>oracle.webdb.page.ParallelServlet</servlet-class> 
        <init-param> 
          <param-name>x509certfile</param-name> 
          <param-value>C:\mySSLconfig\trustedCerts.txt</param-value>
        </init-param>
    </servlet>
   

   
   

   Note: If you choose not to implement x509certfile, the PPE trusts any SSL certificate.

   
   

Specifying OracleAS Portal Published Address and Protocol

To specify the published address for OracleAS Portal with the modified port for SSL, you need to use Oracle Enterprise Manager as follows:

1. Navigate to the Oracle Enterprise Manager 10g Application Server Control Console.

2. Click the Standalone Instance with the Oracle Application Server that is running the OracleAS Portal middle tier.

3. Click the OracleAS Portal system component.

4. Under Administration, click Portal Web Cache Settings.

5. For Listen Port, enter the OracleAS Web Cache SSL port number.

6. For Listening Port SSL Enabled, choose Yes.

7. Click OK. The OracleAS Portal schema is updated with the setting and the Oracle Enterprise Manager 10g target instance is updated to use HTTPS for its URL tests.

   If at a later time you choose to switch to HTTP, you would perform this same procedure and return Listening Port SSL Enabled to No.

   
   

   Note: This procedure updates the settings in the iasconfig.xml file.

   
   
   
   

   See Also: See Appendix A, "Using the Portal Dependency Settings Tool and File" for more information about iasconfig.xml.

   
   

Re-Registering the Oracle HTTP Server Partner Application

Run ssoreg to register the virtual host for which mod_osso facilitates single sign-on. The specific application URLs to be defined as partner applications within this site are defined in the file osso.conf. ssoreg is located on the middle tier in MID_TIER_ORACLE_HOME/sso/bin.

The following example shows the usage of ssoreg on UNIX:

MID_TIER_ORACLE_HOME/sso/bin/ssoreg.sh 
  -oracle_home_path MID_TIER_ORACLE_HOME
  -site_name www.abc.com
  -config_mod_osso TRUE
  -mod_osso_url https://www.abc.com:4443
  -config_file MID_TIER_ORACLE_HOME/Apache/Apache/conf/osso/osso.conf
  -admin_info cn=orcladmin

On Windows you must run the ssoreg.bat batch file instead. Refer to the information on creating partner applications in the Oracle Application Server Single Sign-On Administrator's Guide.

Setting the OracleAS Single Sign-On Query Path URL

OracleAS Portal maintains the URL prefix of OracleAS Single Sign-On, which accesses certain information through HTTP calls from the database using the UTL_HTTP package. These calls must be done through HTTP rather than HTTPS. As a result, even if OracleAS Portal and OracleAS Single Sign-On are configured to use HTTPS, you must still have access to an HTTP port on OracleAS Single Sign-On to support these interfaces.

To set this URL prefix, and the OracleAS Single Sign-On Query Path URL, refer to Step 4 in Section 6.3.2.1.2, "SSL to OracleAS Single Sign-On", for the steps to be performed.

Associating the Federated Portal Adapter with SSL

The Federated Portal Adapter uses the Oracle HTTP Server rewrite rules to simplify URLs for registering providers. By default, these rewrite rules are only specified for HTTP communication. To set up the Federated Portal Adapter with SSL, perform the following steps:

1. Edit the virtual hosts section of your ssl.conf file, located in the MID_TIER_ORACLE_HOME/Apache/Apache/conf directory, as follows:

   ## SSL Virtual Host Context 
   ## 
   # 
   # NOTE: this value should match the SSL Listen directive set previously in this 
   # file otherwise your virtual host will not respond to SSL requests. 
   # 
   <VirtualHost _default_:3011> 
     #  General setup for the virtual host 
     DocumentRoot /u01/app/oracle/product/as10g/Apache/Apache/htdocs 
     ServerName host1.abc.com 
     ServerAdmin you@your.address 
     ErrorLog /u01/app/oracle/product/as10g/Apache/Apache/logs/error_log 
     TransferLog "/u01/app/oracle/product/as10g/Apache/Apache/logs/access_log" 
     Port 3001 
     SSLEngine on 
     SSLCipherSuite
   SSL_RSA_WITH_RC4_128_MD5:SSL_RSA_WITH_RC4_128_SHA:SSL_RSA_WITH_3DES_EDE_CBC_SHA:SSL_RSA_WITH_DES_CBC_SHA:SSL_RSA_EXPORT_WITH_RC4_40_MD5:S
   
   SL_RSA_EXPORT_WITH_DES40_CBC_SHA 
     SSLWallet file:/u01/app/oracle/product/as10g/Apache/Apache/conf/ssl.wlt/default 
   
     <Files ~ "\.(cgi|shtml)$"> 
      SSLOptions +StdEnvVars 
     </Files> 
     <Directory /u01/app/oracle/product/as10g/Apache/Apache/cgi-bin> 
      SSLOptions +StdEnvVars 
     </Directory> 
   
           SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown 
           CustomLog /u01/app/oracle/product/as10g/Apache/Apache/logs/ssl_request_log "%t %h %{SSL_PROTOCOL}x
   %{SSL_CIPHER}x \"%r\" %b" 
   
           RewriteEngine on 
           RewriteOptions inherit
   
       </VirtualHost> 
   
   

2. Run the following command to synchronize the manual configuration changes:

   MID_TIER_ORACLE_HOME/dcm/bin/dcmctl updateconfig
   
   

3. Restart your Oracle Application Server instance:

   MID_TIER_ORACLE_HOME/opmn/bin/opmnctl stopall
   MID_TIER_ORACLE_HOME/opmn/bin/opmnctl startall
   
   

Registering Web Providers or Provider Groups Exposed over SSL

To register a Web provider, which is exposed over SSL, you must have a copy of the root certificate of the certificate authority used by the Web provider. If the Web provider is using an unknown or uncommon certificate authority, you need to add the appropriate root certificate (using Base-64 encoded X.509 format) to the set of trusted certificates recognized by the Oracle Database hosting the OracleAS Metadata Repository containing the OracleAS Portal schema. To register Web providers or provider groups, perform the following steps:

1. Change directory to ORACLE_HOME/javavm/lib/security/ on the Oracle home containing the Oracle Database hosting the OracleAS Metadata Repository containing the OracleAS Portal schema.

2. Create a backup of the truststore file cacerts, for example, cacerts.bak.

3. Execute the following command to add the required certificate to the trust store:

   $ORACLE_HOME/jdk/bin/keytool -import -alias <aliasName> -file <root_certificate_file_name> -trustcacerts -v -keystore $ORACLE_HOME/javavm/lib/security/cacerts
   
   

4. Provide the trust store password, and type Yes, when prompted for confirmation.

Augmenting the Portal Tools Trusted Certificate File

If you use the Web Page data source of OmniPortlet provider, you are doing a loopback to the Web Clipping provider, and so need to add the web provider server certificate to the trusted certificate file pointed to by the <trustedCertificateLocation> tag in OmniPortlet provider.xml file. The default certificate file is the ca-bundle.crt file, located in the MID_TIER_ORACLE_HOME/portal/conf directory.

To do this, perform the steps shown subsequently, which are based on the Internet Explorer browser. The steps may differ slightly if you are using another browser for capturing and exporting the necessary certificate.

1. Capture the necessary certificate: Point your browser to the Web Clipping provider test page: http://<host>:<port>/portalTools/webClipping/providers/webClipping.

   You should see a Security Alert dialog box that shows "The security certificate was issued by a company you have not chosen to trust. View the certificate to determine whether you want to trust the certifying authority." or something similar. Click View Certificate, and then go through the following steps to export the certificate into a temporary file:

   1. Select the Details tab.

   2. Select Show: <All> in the drop-down list, and click Copy to File....Run the Export wizard to export the certificate in Base-64 encoded X.509 format into a temporary file MID_TIER_ORACLE_HOME/portal/conf/providertemp.cer.

2. Append the certificate in the temporary file to the certificate file used by OmniPortlet provider (default is MID_TIER_ORACLE_HOME/portal/conf/ca-bundle.crt).

Enabling Access for Oracle Ultra Search

For Oracle Ultra Search to access secure Web sites, you need to import certificates into the crawler's trust store and the Oracle Application Server Containers for J2EE (OC4J) JVM's trust store.

By default, the OC4J JVM recognizes certificates of well-known certificate authorities. However, if the secure portal instance uses a self-signed certificate or a certificate signed by an unknown certificate authority, then you must import the portal's certificate into the OC4J JVM's truststore. The OC4J JVM default truststore is located at ORACLE_HOME/jdk/jre/lib/security/cacerts.

To add the required certificate to the trust store, perform the following steps:

1. Change directory to ORACLE_HOME/jdk/jre/lib/security/ on the middle tier.

2. Create a backup of the truststore file cacerts, for example, cacerts.bak.

3. Execute the following command to add the required certificate to the trust store:

   $ORACLE_HOME/jdk/bin/keytool -import -alias <aliasName> -file <root_certificate_file_name> -trustcacerts -v -keystore $ORACLE_HOME/jdk/jre/lib/security/cacerts
   
   

4. Provide the trust store password, and type "Yes", when prompted for confirmation.

Re-Registering OracleAS Portal as an Oracle Ultra Search Content Source

If you use Oracle Ultra Search to crawl your portal and you reconfigure SSL throughout OracleAS Portal, you must re-register OracleAS Portal as a content source with Oracle Ultra Search. See Section 8.2.3.2, "Registering OracleAS Portal as a Content Source" for details.

6.3.2.1.5 External SSL with Non-SSL Within Oracle Application Server

The previous configurations discuss how to configure OracleAS Portal in such a way that communications within Oracle Application Server are secured through SSL. In some cases, you may want to have OracleAS Portal set up such that the site is externally accessible through SSL URLs but the Oracle Application Server is internally running in non-SSL mode. Note that in this latter scenario, you need to have the SSL to non-SSL translation done either by a load balancing router (LBR) or an SSL accelerator. The section that follows outlines the steps you would use with an accelerator on an LBR or a reverse proxy server performing the SSL translation.

With this option, the SSL features of the OracleAS Security Framework are not used, but, instead, an external component is used for providing the SSL connection point. These external accelerators may be coupled with LBRs or reverse proxy servers. Oracle Application Server enables you to configure these external devices to provide SSL, thus allowing Oracle Application Server to use HTTP internally for the best performance.

Figure 6-19 shows a configuration where OracleAS Portal is externally accessible through SSL.

Figure 6-19 External SSL Only

Description of "Figure 6-19 External SSL Only"

For the purposes of this procedure, assume the following:

• In this example, SSL acceleration is performed by the LBR, which also proxies page requests between the HTTP and HTTPS protocols and their ports. The location of the SSL end point will determine the target for the loopback requests. For example, if an SSL-enabled reverse proxy server front-ends a single protocol LBR, loopback requests will be sent to the LBR, while the published site is exposed by the reverse proxy server.

• Your load balancing router is running on lbr.abc.com and the LBR port used for accessing the site is 443.

• OracleAS Web Cache is on computer w1.abc.com and the listening port is 7777, the administration port is 4000, and the invalidation port is 4001.

• The Oracle HTTP Server is running on computer m1.abc.com and the port is 7778.

• The port numbers used are example values only.

After you have successfully performed the checks described in "Checks to Perform Before Configuring SSL", you can use either of the following two methods to configure SSL to OracleAS Single Sign-On:

• Configuring External SSL Using SSLConfigTool

• Configuring External SSL Manually

Configuring External SSL Using SSLConfigTool

Refer to the section "SSL Configuration Tool and Its Limitations" before using SSLConfigTool.

To configure external SSL with non-SSL within Oracle Application Server using the SSL configuration tool, you must perform the following tasks:

1. Run SSLConfigTool

2. Configure Seeded Providers and Provider Groups

Run SSLConfigTool

Run SSLConfigTool in the middle-tier home, or multiple middle-tier Oracle homes, as shown here for Windows:

SSLConfigTool.bat -config_w_file <input_file_name> -ptl_inv_pwd <ptl_inv_pwd> -opwd <orcladmin_pwd>

Where:

• config_w_file is used to run the tool in silent mode using the values specified in the <input_file_name> file. See Oracle Application Server Administrator's Guide for details.

• ptl_inv_pwd is the portal invalidation password.

• opwd is the Oracle administrator password. If no password is specified, you will be prompted to enter the password.

For example:

SSLConfigTool.bat -config_w_file portal.config -ptl_inv_pwd invalidator -opwd administrator

The contents of the portal.config file for this example would include something similar to Example 6-1:

<SSLConfig>
   <mid_tier>
      <virtual_address ssl="on" host="lbr.abc.com" port="443" inv_port="4001" ssl_terminate="lbr"/>
      <lbr loopback_port="80"/>
      <wc/>
      <ohs>
         <servers>
            <server host="machine_6.us.oracle.com" port="7778" />
         </servers>
      </ohs>
   </mid_tier>
</SSLConfig>

Configure Seeded Providers and Provider Groups

1. To enable communication between OmniPortlet and Web Page Data Source using HTTP, configure OmniPortlet as follows:

   1. Open the web.xml file located in the directory, MID_TIER_ORACLE_HOME/j2ee/OC4J_Portal/applications/portalTools/omniPortlet/WEB-INF.

   2. Add the following context parameters to ensure that HTTP is used and not HTTPS that is used by the site:

      <context-param> 
          <param-name>useScheme<param-name>
          <param-value>HTTP</param-value>
      </context-param>
      <context-param>
          <param-name>usePort</param-name>
          <param-value>7777</param-value>
      </context-param>
      
      

   3. Save the web.xml file.

   4. Run the following command to synchronize the manual configuration changes:

      MID_TIER_ORACLE_HOME/dcm/bin/dcmctl updateconfig

   5. Restart OC4J_Portal.

2. Update the default JPDK instance URL port and protocol, by performing the following steps:

   1. Log in to OracleAS Portal as the administrator (for example, PORTAL).

   2. Click the Administer tab.

   3. Click the Portal tab.

   4. Click Global Settings in the Services portlet.

   5. Click the Configuration tab.

   6. For the Default JPDK Instance setting, change the protocol and port in the URL from https://lbr.abc.com:443/ to http://lbr.abc.com:7777/.

3. Update the seeded providers registration to use HTTP instead of HTTPS, by performing the following steps:

   1. Log in to OracleAS Portal as the administrator (for example, PORTAL).

   2. Click the Administer tab.

   3. Click the Portlets subtab.

   4. In the Remote Providers portlet, enter WEBCLIPPING in the Name field.

   5. Click Edit.

   6. Click the Connection tab.

   7. In the URL field, change the URL from:

      https://lbr.abc.com:443/portalTools/webClipping/providers/webClipping 
      
      

      to:

      http://lbr.abc.com:7777/portalTools/webClipping/providers/webClipping 
      
      

   8. Click OK to commit the change.

   9. Repeat steps d through g but with the following exceptions:

      • In Step d, enter OMNIPORTLET instead of WEBCLIPPING.

      • In Step g, change the URL from:

        https://lbr.abc.com:443/portalTools/omniPortlet/providers/omniPortlet
        
        

        to:

        http://lbr.abc.com:7777/portalTools/omniPortlet/providers/omniPortlet
        
        

4. Update the seeded provider group registration to use HTTP instead of HTTPS, by performing the following steps:

   1. Log in to OracleAS Portal as the administrator (for example, PORTAL).

   2. Click the Administer tab.

   3. Click the Portlets subtab.

   4. In the Remote Provider Group portlet, enter oracle.ias.providers in the Name field.

   5. Click Edit.

   6. Click the Connection tab.

   7. In the URL field, change the protocol and port in the URL from https://lbr.abc.com:443/ to http://lbr.abc.com:7777/.

   8. Click OK to commit the change.

   9. Repeat steps d through g but with the following exception:

      In Step d, enter oracle.sample.providers instead of oracle.ias.providers.

When you register locally hosted Web providers or provider groups (such as the JPDK Sample provider), you need to register them using HTTP as the protocol, lbr.abc.com as the hostname, and 7777 as the port number. This restriction only applies to locally hosted Web providers or provider groups (that is, Web providers or provider groups running on the same middle tier as OracleAS Portal).

For example, to register the JPDK Sample provider, the URL is:

http://lbr.abc.com:7777/jpdk/providers/sample

Configuring External SSL Manually

To manually configure external SSL with non-SSL within Oracle Application Server, you must perform the following tasks:

• Configuring the Oracle Application Server Middle Tier

• Configuring Seeded Providers (Web Clipping and OmniPortlet) and Locally Hosted Web Providers

• Re-Registering the Oracle HTTP Server Partner Application

• Re-Registering OracleAS Portal as an Oracle Ultra Search Content Source

Configuring the Oracle Application Server Middle Tier

You need to configure the Oracle Application Server middle tier to allow the underlying components to construct URLs based on the load balancing router's hostname, lbr.abc.com, and port (443). To do this:

1. Edit httpd.conf as follows:

   1. Access the Application Server Control Console.

   2. Click the link for the application server where OracleAS Portal is installed.

   3. Click the HTTP Server link.

   4. Click the Administration link.

   5. Click Advanced Server Properties.

   6. Select httpd.conf.

   7. Scroll to the bottom of the file and enter the following LoadModule directive:

      On UNIX:

      LoadModule certheaders_module libexec/mod_certheaders.so
      
      

      On Windows:

      LoadModule certheaders_module modules/ApacheModuleCertHeaders.dll
      
      

      For more information on mod_certheaders, refer to the Oracle HTTP Server Administrator's Guide.

   8. Add a Virtual Host definition. This must be inserted after the LoadModule directive, as follows:

      NameVirtualHost <OHS_computer_IP_address>:<OHS_listening_port>
      
      <VirtualHost <OHS_computer_IP_address>:<OHS_listening_port>>
        ServerName <portal_site_server_name>
        Port <ssl_listening_port_for_portal_site>
        SimulateHttps On
        RewriteEngine On
        RewriteOptions inherit
      </VirtualHost>
      
      

      For example:

      NameVirtualHost 123.45.67.8:7778
      
      <VirtualHost 123.45.67.8:7778>
        ServerName lbr.abc.com
        Port 443
        SimulateHttps On
        RewriteEngine On
        RewriteOptions inherit
      </VirtualHost>
      
      

   9. Define a second virtual host for internal use by Application Server Control Console. For example:

      <VirtualHost 123.45.67.8:7778>
        ServerName m1.abc.com
        Port 7777
        RewriteEngine On
        RewriteOptions inherit
      </VirtualHost>
      
      

   10. Click Apply.

   11. When asked to restart Oracle HTTP Server, click Yes.

2. Configure the Parallel Page Engine. To do this, perform the following steps:

   1. Open the web.xml file, located in the directory MID_TIER_ORACLE_HOME/j2ee/OC4J_Portal/applications/portal/portal/WEB-INF.

   2. Make the following changes to the Page servlet section to attempt loopbacks using a different protocol and port than what is used by the site:

      <servlet>
      <servlet-name>page</servlet-name> 
         <servlet-class>oracle.webdb.page.ParallelServlet</servlet-class>
                <init-param>
                   <param-name>useScheme</param-name>
                   <param-value>http</param-value>
                </init-param>
                <init-param>
                   <param-name>usePort</param-name>
                   <param-value>7777</param-value>
                </init-param>
                <init-param>
                   <param-name>httpsports</param-name>
                   <param-value>443</param-value>
                </init-param>
      </servlet>
      
      

   3. Save the web.xml file.

   4. Run the following command to synchronize the manual configuration changes:

      MID_TIER_ORACLE_HOME/dcm/bin/dcmctl updateconfig
      
      

   5. Run the following commands to restart your Oracle Application Server instance:

      MID_TIER_ORACLE_HOME/opmn/bin/opmnctl stopall
      MID_TIER_ORACLE_HOME/opmn/bin/opmnctl startall
      
      

3. Ensure that DNS resolves lbr.abc.com to the LBR's IP address.

4. Register new URLs with OracleAS Portal using the LBR's hostname and port. To do this, edit iasconfig.xml (located by default in ORACLE_HOME/portal/conf) and specify a new Farm element that points to the LBR. A typical Farm element in iasconfig.xml looks like the bold text in Example 6-2:

   Example 6-2 WebCacheDependency Entry in iasconfig.xml

   <IASConfig XSDVersion="1.0">
       <IASFarm Name="Farm-1.lbr.abc.com" Host="lbr.abc.com">
           <WebCacheComponent ListenPort="443" InvalidationPort="4001"
           InvalidationUsername="invalidator" InvalidationPassword="welcome1"
           SSLEnabled="true"/>
       </IASFarm>
       <IASInstance Name="iAS.infra.abc.com" Host="infra.abc.com">
           <OIDComponent AdminPassword="@BVs2KPJEWC5a0l4n8lbTxUY="
           PortSSLEnabled="true" LDAPPort="3060" AdminDN="cn=orcladmin"/>
       </IASInstance>
       <IASInstance Name="iAS.w1.abc.com" Host="infra.abc.com">
         <EMComponent ConsoleHTTPPort="1814" SSLEnabled="false"/>
       </IASInstance>
       <PortalInstance DADLocation="/pls/portal" SchemaUsername="portal"
       SchemaPassword="@Beyh8p2bOWELQCsA5zRtuYc="
       ConnectString="cn=iasdb,cn=oraclecontext">
          <WebCacheDependency ContainerType="IASFarm" Name="Farm-1.lbr.abc.com"/>
           <OIDDependency ContainerType="IASInstance" Name="iAS.infra.abc.com"/>
          <EMDependency ContainerType="IASInstance" Name="iAS.w1.abc.com"/>
       </PortalInstance>
   </IASConfig> 
   
   

5. Run ptlconfig (typically located in the directory MID_TIER_ORACLE_HOME/portal/conf) as shown in the following example:

   ptlconfig -dad <portal name> -site -wc
   
   

6. To prevent access to Oracle Enterprise Manager from the outside, the Oracle Enterprise Manager link provided by OracleAS Portal needs to be changed back to point to the internal server. To do this, run ptlconfig (typically located in the directory MID_TIER_ORACLE_HOME/portal/conf) as shown in the following example:

   ptlconfig -dad portal -em 
   
   

7. From the OracleAS Web Cache administration page, click Site Definitions under Origin Servers, Sites, and Load Balancing.

8. Click Add Site.

9. Enter site information as follows:

   • Host Name: The published hostname and fully qualified domain of the external SSL accelerator device or reverse proxy server.

   • Port Number: The SSL port number, for example, 443 for the default SSL port.

   • HTTPS Only Prefix: Leave blank.

   • Client-Side Certificate: Not required.

   • Default Site: Yes.

   • Create Alias from Site Name with/without www: No.

   Refer to the Oracle Application Server Web Cache Administrator's Guide for detailed instructions on the configuration mentioned earlier.

10. Set up an alias for OracleAS Web Cache. In the configuration where the Parallel Page Engine loops back to OracleAS Web Cache and OracleAS Web Cache is listening on a different port than the load balancing router, loopback content gets cached with a URL key of lbr.abc.com:7777, whereas OracleAS Portal sends invalidation requests to invalidate URLs with the format lbr.abc.com:443. To get around this inconsistency, you need to set up an alias in OracleAS Web Cache to let it know that lbr.abc.com:7777 and lbr.abc.com:443 are the same, invalidation requests for one should invalidate requests for the other as well, and the cached content should also be leveraged based on this alias.

    1. Go to the Oracle Application Server Web Cache administration page and log in as the administrator.

    2. Click Site Definitions.

    3. Select the radio button in the Select column that corresponds to the site for which the alias will be added, in this case lbr.abc.com.

    4. Click Add Alias.

    5. On the window that comes up, enter lbr.abc.com as the Host Name and 7777 as the port where 7777 is the value for usePort in the web.xml configuration file for the Parallel Page Engine.

    6. Click Submit.

    If the default HTTPS port 443 is chosen for a site configured with external SSL configuration, as in the preceding example, an additional alias needs to be defined in OracleAS Web Cache for the site lbr.abc.com:443, which should be lbr.abc.com:80. Follow the instructions for creating the alias as mentioned in Step 10 and replace port 7777 with 80.

    An alias for port 80 is needed because the "Host" header sent by the browser will be lbr.abc.com (without a port number appended to it). Because OracleAS Web Cache is listening on the HTTP port, it will assume that the port number is 80 and use this to determine the site-to-server mapping. It also uses this for cache key creation.

11. After adding a new site definition, you must add the site to server mapping for the newly defined site to the origin server. To do this:

    1. In the navigation frame, select Site-to-Server Mapping under Origin Servers, Sites, and Load Balancing.

    2. In the Site-to-Server Mapping page, select the first mapping in the table and click Insert Above.

    3. In the Edit/Add Site-to-Server Mapping page, select the Select from Site definitions option and then select a site definition created in the previous step (lbr.abc.com).

    4. In the Select Application Web Servers section, select the application server (m1.abc.com) specified in the Origin Servers page.

    5. Click Submit.

    6. Click Apply Changes on the top of the page.

    7. In the Cache Operations page, click Restart to restart Web Cache.

       To verify that the site has been mapped correctly, navigate to the Site-to-Server Mapping page, and ensure that m1.abc.com is mapped to the site lbr.abc.com.

    For more information on the procedure in the preceding text, refer to the section on mapping sites to origin servers, in the Oracle Application Server Web Cache Administrator's Guide.

12. Configure your load balancing router, lbr.abc.com, to:

    1. Accept requests on HTTPS port 443 and forward them to the OracleAS Web Cache port 7777 running on computer w1.abc.com, while converting HTTPS requests to HTTP.

    2. Accept requests on HTTP port 7777 and forward them to the OracleAS Web Cache port 7777 running on computer w1.abc.com. This enables the loopback requests. The LBR's port 7777 should only be accessible from the middle tier. Your firewall may need to be configured separately to make this work. To test this, run the following command on the middle-tier server:

       telnet lbr.abc.com 7777
       
       

       You should not see any connection failure message when you run the telnet command.

    3. Accept requests on HTTP port 4001 for the invalidation requests and forward them to the OracleAS Web Cache invalidation port 4001. You must be able to connect to the LBR's port for invalidation requests from the OracleAS Metadata Repository. Your firewall may need to be configured separately to make this work. To test this, run the following command on the OracleAS Metadata Repository server:

       telnet lbr.abc.com 4001
       
       

       You should not see any connection failure message when you run the telnet command.

    4. Facilitate communication from the middle tier to OracleAS Web Cache through the LBR. NAT-related configuration may be required for this. Refer to Section 5.3, "Configuring Multiple Middle Tiers with a Load Balancing Router" for more information on configuring NAT.

       
       

       Note: Refer to Section 5.3.6, "Step 6: Configure Portal Tools and Web Providers (Optional)" for information on how this configuration might affect your Web providers.

       
       

    5. Facilitate communication from the OracleAS Metadata Repository to OracleAS Web Cache for the invalidation requests through the LBR. NAT-related configuration may be required for this.

13. Optionally, re-register the Wireless gateway URL with the load-balancer's address. See Section 5.10, "Configuring OracleAS Wireless" for more information.

14. To enable monitoring of the load balancing router's front-end host and port settings for OracleAS Portal, you must edit targets.xml (located in MID_TIER_ORACLE_HOME/sysman/emd/) on M1, as follows:

    1. Open targets.xml on M1, using a text editor.

    2. Search for OracleAS Portal targets, that is, TYPE="oracle_portal".

    3. Edit the PortalListeningHostPort property, to point to the LBR. For example:

       <Property NAME="PortalListeningHostPort" VALUE=https://lbr.abc.com:443/>
       
       

    4. Save the changes to targets.xml.

    5. Reload the targets in the Application Server Control Console:

       On Solaris/Linux:

       MID_TIER_ORACLE_HOME/bin/emctl reload
       
       

       On Windows:

       MID_TIER_ORACLE_HOME\bin\emctl reload
       
       

Configuring Seeded Providers (Web Clipping and OmniPortlet) and Locally Hosted Web Providers

Refer to the "Configure Seeded Providers and Provider Groups" subsection, in Section 6.3.2.1.5, "External SSL with Non-SSL Within Oracle Application Server" for the manual steps to be performed.

Re-Registering the Oracle HTTP Server Partner Application

Run ssoreg to register the virtual host for which mod_osso facilitates single sign-on. The specific application URLs to be defined as partner applications within this site are defined in the file osso.conf. ssoreg is located on the middle tier in MID_TIER_ORACLE_HOME/sso/bin.

The following example shows the usage of ssoreg on UNIX:

MID_TIER_ORACLE_HOME/sso/bin/ssoreg.sh
  -oracle_home_path MID_TIER_ORACLE_HOME
  -site_name lbr.abc.com
  -config_mod_osso TRUE
  -mod_osso_url https://lbr.abc.com
  -config_file MID_TIER_ORACLE_HOME/Apache/Apache/conf/osso/osso.conf
  -admin_info cn=orcladmin
  -virtualhost

On Windows you must run the ssoreg.bat batch file instead. Refer to the information on creating partner applications in the Oracle Application Server Single Sign-On Administrator's Guide.

Re-Registering OracleAS Portal as an Oracle Ultra Search Content Source

If you use Oracle Ultra Search to crawl your portal and you reconfigure external SSL with non-SSL within Oracle Application Server, you must re-register OracleAS Portal as a content source with Oracle Ultra Search. See Section 8.2.3.2, "Registering OracleAS Portal as a Content Source" for details.

6.3.2.3.1 Cache for Oracle Internet Directory Parameters

As pointed out in Section 6.1.7, "Leveraging Oracle Identity Management Infrastructure", OracleAS Portal maintains a cache of information from the directory. From the Global Settings page, you can refresh this cache with the updated information from the directory. Refresh Cache for the Oracle Internet Directory parameters immediately updates the cache with the latest parameters values from the directory. The cached information is relatively static information, hence you do not need to refresh the cache frequently.

6.3.2.3.2 Oracle Directory Integration Platform Synchronization

Because OracleAS Portal caches group membership information, it requires a mechanism for updating the cache when the information is changed in the directory. The directory integration server notifies OracleAS Portal whenever a change is made in the directory that must be reflected in OracleAS Portal. In Global Settings, you can set:

• Enable directory synchronization defines whether the directory integration server notifies OracleAS Portal when a relevant change is made in the directory. If this setting is not checked, then OracleAS Portal will not be notified of any directory integration server subscribed events.

• Send event notifications every n seconds defines the interval of time between event notifications sent by the directory integration server to notify OracleAS Portal of relevant changes. This setting is available only when Enable directory synchronization is checked.

When the Oracle Directory Integration and Provisioning server is running and configured to work with OracleAS Portal, group membership changes in Oracle Internet Directory will result in soft cache invalidations in OracleAS Portal.

Some examples of group membership cache invalidations are:

• If you add a user to a group, the Oracle Directory Integration and Provisioning server notifies OracleAS Portal of the change. OracleAS Portal will then issue a single soft invalidation message that will be processed by the soft invalidation job. This is because of the possibility that the user may have new privileges that can affect what data can be viewed.

• If you add group _A to group _B, the Oracle Directory Integration and Provisioning server notifies OracleAS Portal of the change. OracleAS Portal will then issue a soft invalidation message for each user in group _A. This is because of the possibility that the users in group _A may have new privileges that affect what data they can view.

6.3.2.3.3 Group Creation Base Distinguished Name (DN)

OracleAS Portal maintains its user group information in the directory. When groups are created through the Group portlet, they are created under a node of the LDAP Directory Information Tree (DIT). A node is identified by its distinguished name (DN). Therefore, in OracleAS Portal, you need to specify in which node you wish to create groups:

Group Creation Base DN is the DN of the node in which you want OracleAS Portal to maintain its user groups. For example:

cn=portal.040820.123756.096286000,cn=Groups,dc=MyCompany,dc=com

This setting is particularly useful if you adapt OracleAS Portal to interact with an existing DIT.

6.3.2.3.4 Group Search Base Distinguished Name (DN)

Just as you need to define the node in which you want to create groups, you must also define the node in which you want OracleAS Portal to search for existing groups. For example, you need to specify where OracleAS Portal searches when it displays the group's list of values in the Group portlet.

Local Group Search Base DN is the DN of the node in which you want OracleAS Portal to maintain its user groups. For example:

cn=portal.040820.123756.096286000,cn=Groups,dc=MyCompany,dc=com

This setting is particularly useful if you adapt OracleAS Portal to interact with an existing DIT.

6.3.2.4.1 Safeguard Passwords for Lightweight OracleAS Portal Users

Unscrupulous users might try to learn the passwords of your default users, which could result in an account lock. This lock can be released from the server, but it is far better that you not depend on the default user accounts for administrative purposes. To safeguard the passwords for these accounts do the following:

1. Immediately change the default passwords for all of the following default users:

   • PORTAL

   • PORTAL_ADMIN

   • PUBLIC

2. Create new lightweight administrator accounts with the same access rights as the default users, and set the account termination date in OracleAS Single Sign-On for the default users. Alternatively, you can also deselect the Allow User To Log In setting in the Edit User page for the default users.

3. Once you have disabled login or changed the passwords for the default users, try logging in to the portal as the default users with the default passwords to ensure that your changes have been successful.

6.3.2.4.2 Remove Unnecessary Objects

To prevent users from entering your portal through obsolete or unnecessary pages, you should remove any unused objects from your OracleAS Portal and database environment. For example:

• Delete page groups that are no longer in use.

• Delete OracleAS Portal providers that are no longer in use.

6.3.2.4.3 Review Default Seeded Privileges

When OracleAS Portal is installed, the seeded groups listed in Table 6-2 are provisioned with a set of privileges that are typically required by users in those roles. You should review these initial set of privileges to ensure that they are consistent with your security policy.

Users or groups can obtain privileges from one of the following sources:

• OracleAS Portal access control entries

• Oracle Internet Directory privilege groups

To edit the privileges granted through OracleAS Portal access control entries, you edit the user or group profile from the Administer tab with the User Profile Portlet or Group Profile Portlet. Click the User or Group Profile dialog's Privilege tab. You can revoke or assign privileges from this list.

To edit the privileges granted through Oracle Internet Directory privilege groups, use the User Portlet or Group Portlet to edit the User or Group in Oracle Internet Directory. Select or deselect the check marks by the Privilege Assignment list to grant or revoke the appropriate privileges in Oracle Internet Directory.

Privileges granted to the AUTHENTICATED_USERS group are given to any user that logs on to OracleAS Portal through OracleAS Single Sign-On upon successful authentication. This is the group that you will want to establish with the default privileges for all your logged in users.

For example, if you do not want authenticated users to be able to create groups, then edit the AUTHENTICATED_USERS group through the Group Portlet and remove the check mark beside Allow group creation under Privilege Assignment.

6.3.2.4.4 Revoke Public Access to Provider Components

In some cases, OracleAS Portal provider components may give users the option to view or modify records in application tables. To tighten security, you should revoke public access from such components if it is unnecessary. You can also use a menu component with specific access rights on the menu options to more tightly control application access.

6.3.2.4.5 Control Access to Administration Pages

To prevent users who should not have access to administration interfaces from entering administration pages, you should ensure that you control access rights for the following page groups and the pages they contain:

• Portal Design-Time Pages is the page group that contains the OracleAS Portal Home Page, and the Builder and Navigator pages.

• Portlet Repository

To control access to the page groups mentioned earlier, perform the following steps:

1. In the Navigator, click Page Groups.

2. Click Edit Properties next to the page group for which you want to change the access settings.

3. Click the Access tab.

4. Grant MANAGE ALL to specific users or to certain groups. For example, DBA, PORTAL_ADMINISTRATORS, PORTAL_DEVELOPERS, and your own groups.

5. When you are done, click OK.

To control access to individual administration pages in these page groups, perform the following steps:

1. In the Navigator, click Page Groups.

2. Click Contents next to the page group that contains the pages on which you want to change the access settings.

3. Click Pages.

4. Click Properties next to the page for which you to change the access settings.

5. Click the Access tab.

6. Grant MANAGE ALL to specific users or to certain groups. For example, DBA, PORTAL_ADMINISTRATORS, PORTAL_DEVELOPERS, and your own groups.

7. When you are done, click OK.

   
   

   Note: The Builder page is the root page of the Portal Design-Time Pages page group. To alter its access settings, you must click Edit Root Page next to the Portal Design-Time page group.

   
   

6.3.2.4.6 Protect PL/SQL Packages

The default installation protects standard database procedures that are granted to PUBLIC, for example dbms_*, utl_*, and so on. If you write your own PL/SQL packages, which are granted to PUBLIC, and do not want to provide access to these packages through a Web browser, then refer to the chapter "Securing Application Database Access Through mod_plsql" in Oracle Application Server mod_plsql User's Guide.

6.3.2.4.7 Consider SSL and the Login Portlet

To secure passwords going across the Internet you can use Secure Sockets Layer (SSL) communications by configuring OracleAS Portal to run in HTTPS. However, to enable or disable SSL, you must have portal administrator privileges.

Login Portlet Versus Login Page

OracleAS Portal has the option to place a Login portlet on a page (typically the home page). This portlet shows user name and password fields and a login button when the user is not logged in. If the user is logged in, it shows a logout link. This portlet provides a way to log in without having to navigate to a dedicated login page. It also displays in the OracleAS Portal page layout style.

However, if you use this portlet, you must ensure that the pages on which it appears are SSL-encrypted. Bear in mind, that SSL encryption for your complete site could adversely affect performance because it requires more resources. Furthermore, the Login portlet presents a security risk because you cannot prevent showing the login screen, as it is shown when the user is not logged in. Hence, in situations where you want SSL encryption on passwords, you should not use the Login portlet when you want SSL encryption. To enforce this restriction, you must remove access rights for the Login portlet in the Portlet Repository.

6.3.2.4.8 Consider LDAP over SSL for Oracle Internet Directory Connections

By default, OracleAS Portal connects to the directory using LDAP without SSL. If the directory server is configured for an SSL port, though, OracleAS Portal can be configured to use LDAP over SSL, also known as LDAPS.

To configure OracleAS Portal to use SSL to connect to the directory, you must run the secupoid.sql script, located in ORACLE_HOME/portal/admin/plsql/wwc. This script enables you to change the following OracleAS Portal configuration parameters related to the directory:

• Directory hostname

• Directory port

• Application directory password

• SSL setting

When you install OracleAS Portal, it is automatically configured with a directory server. However, you may want to change some settings, such as whether to use SSL, after installation. To change to an SSL connection for the directory, simply run the secupoid.sql script in the PORTAL schema to specify the LDAPS port instead of the LDAP port, and indicate that you want to use SSL.

Running the secupoid.sql script

The section that follows shows a sample execution of secupoid.sql from SQL*Plus.

In the example, the directory was initially configured to run LDAP on port 389. Later, an LDAPS port was activated on 636. Because the server name does not change, we retain the old value, update the port, and indicate that we want to use SSL by setting the Use SSL? value to Y. When you run the script, it displays the current configuration and lets you replace any of the configurable settings. The script also enables you to update OracleAS Portal's directory cache after running it. Because activating SSL does not change any of the directory information cached by OracleAS Portal, it is not usually necessary to refresh the cache in this case.

SQL> @secupoid 
Current Configuration 
-------------------- 
OID Host: oid.domain.com 
OID Port: 389 
Application DN: 
orclApplicationCommonName=PORTAL.040820.123756.096286000,cn=Portal,cn=Products,cn=OracleContext 
Application Password: 3E8C2D1B87CB61011757239C5AA9B390 
Use SSL? N 

PL/SQL procedure successfully completed. 

Updating OID Configuration Entries 
Press [Enter] to retain the current value for each parameter 
For SSL Connection to LDAP, specify "Y"es or "N"o 
------------------------------------------------ 
Enter value for oid_host: 
Enter value for oid_port: 636 
Enter value for app_password: 
Enter value for use_ssl_to_connect_to_ldap: Y 
Enter value for refresh_with_new_settings: N 

PL/SQL procedure successfully completed. 

No errors.

After executing the script, OracleAS Portal is configured for LDAPS access of the directory. Refer to Section C.3, "Using the secupoid.sql Script" for more information.

6.3.2.4.9 Change the Application Entity Password

OracleAS Portal never passes a user's password to the directory. Only OracleAS Single Sign-On performs that task. However, OracleAS Portal authenticates itself to the directory through its application entity and password.

If you want to change the application entity's password, you need to first change its entry in the directory, using command line utilities or the Oracle Directory Manager. To locate the application entry in the directory, you need its DN, which is reported by the secupoid.sql script. By default, OracleAS Portal's application entry is:

orclApplicationCommonName=PORTAL.040820.123756.096286000,cn=Portal,cn=Products,cn=OracleContext 

To change the password, you set the userPassword attribute for the application entry to the new password.

After you have changed the password in the directory, you run secupoid.sql script in the PORTAL schema and specify the new password there, too. Running the script enables OracleAS Portal to encrypt the password and store it for retrieval when it needs to connect to the directory.

Refer to Section C.3, "Using the secupoid.sql Script" for more information about the secupoid.sql script.

6.3.2.4.10 Configure Oracle Enterprise Manager 10g to Monitor OracleAS Portal Running in SSL Mode

To enable Enterprise Manager to monitor OracleAS Portal running in either the mixed SSL mode or fully SSL-enabled mode, you must perform additional configuration.

To do this, follow the instructions for configuring Oracle Enterprise Manager 10g to monitor SSL-Enabled Targets, provided in Oracle Application Server Administrator's Guide.