Skip Headers
Oracle® Application Server Portal Configuration Guide
10g Release 2 (10.1.4)
B19305-03
  Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
Next
Next
 

6 Securing OracleAS Portal

One of the most important aspects of any portal solution is security. The ability to control user access to Web content and to protect your site against people breaking into your system is critical. This chapter describes the architecture of OracleAS Portal security in the following topics:

6.1 About OracleAS Portal Security

The sections that follow provide an overview of OracleAS Portal security and how it works with the OracleAS Security Framework.

6.1.1 OracleAS Portal Security Model

When you make content available on the Web, it is very likely that you need to restrict access to at least some parts of it. For example, it is unlikely that you want every user to be able to see every document on your site. It is even less likely that you want every user to be able to change every document on your site. OracleAS Portal provides a comprehensive security model that enables you to completely control what users can see and change on your Web site.

Before a user logs on to OracleAS Portal, they can only view the content that the content contributors designate as public. Public content can be viewed by any user who knows the URL of a portal object (for example, a page) and can connect to the computer where it is stored. The user sees only those aspects of the object that are designated as public, such as the public portlets. If the object has no public contents, then the user is denied access to it.

Once the user logs in to the portal, they may or may not be able to see and change content depending upon their access privileges. Typically, an authenticated user can see and do more in the portal than a public user. For example, an authenticated user might see items or portlets on the page that the public user cannot view. An authenticated user might also be able to add and edit content, and change properties, privileges that would typically be denied to a public user. In the portal, you can control access to objects (pages, items, or portlets) by user and group. That is, you might grant access privileges for a page to specific named users, user groups, or a combination of both.

To support this flexible approach to controlling access to Web content, OracleAS Portal leverages the other components of Oracle Application Server and Oracle Database 10g to provide strong protection for your portal. OracleAS Portal interacts with all of the following components to implement its security model:

  • Oracle Application Server Single Sign-On authenticates users, who are attempting to gain access to non-public areas of your portal.

  • mod_osso is an Oracle HTTP Server module that redirects authentication requests to OracleAS Single Sign-On. It also keeps track of user activity in partner applications.

  • OracleAS Web Cache is the cache used to serve up pages generated by OracleAS Portal (or proxied to the Oracle HTTP Server if not able to service the request). Based on invalidation caching, OracleAS Portal invalidates the cache when the underlying page or metadata changes.

  • Oracle Internet Directory, Oracle's native LDAP version 3 service, acts as the repository for user credentials and group memberships.

  • The Oracle Internet Directory's Oracle Delegated Administration Services adds or updates the information stored inside the directory (users and groups).

  • Oracle Directory Integration Platform notifies OracleAS Portal upon the occurrence of any directory events (for example, user deletions) to which OracleAS Portal subscribes. In essence, the directory integration server informs OracleAS Portal when a change occurs in the directory that requires a change in OracleAS Portal.

OracleAS Portal Architecture

Figure 6-1 shows the components and relationships of the OracleAS Portal security architecture.

Figure 6-1 OracleAS Portal Security Architecture

Description of Figure 6-1  follows
Description of "Figure 6-1 OracleAS Portal Security Architecture"

The OracleAS Portal architecture consists of three basic tiers, including the client browser, the middle-tier server, and the infrastructure servers and repositories. By default, Oracle Internet Directory and OracleAS Single Sign-On are installed on the same host as part of the infrastructure installation. This tier is subsequently used for the OracleAS Portal installation.

While the default installation has all three servers and repositories installed on the same host, we recommend that you install these functions on separate servers.

In OracleAS Portal, the middle and infrastructure tier components have a number of components in common. These include a repository access component made up of a Database Access Descriptor (DAD) and Oracle Containers for J2EE (OC4J). The latter is used on the infrastructure tier to run Oracle Delegated Administration Services and to execute portal runtime engine on the middle tier.

To optimize the throughput and performance of OracleAS Portal, generated pages are cached in OracleAS Web Cache. If a request for a portal page can be served from OracleAS Web Cache, it will be returned without accessing the OracleAS Portal middle tier. If not, the request will be forwarded to the origin HTTP server and the Parallel Page Engine.

If the current user is not authenticated with the Single Sign-On environment, and if the requested page is not a public page, the user is prompted for a user name and password. This function is carried out through a redirection to OracleAS Single Sign-On for authentication, which in turn verifies the credentials against Oracle Internet Directory through an LDAP request. The credentials are compared to those found in the directory.

Upon successful authentication, OracleAS Single Sign-On creates a single sign-on session cookie. Once the user is authenticated and an appropriate OracleAS Portal session created, it is necessary to determine which pages and objects the user has the necessary access privileges to. For performance reasons the access control lists (ACLs) for all portal objects are stored in the OracleAS Portal schema in the OracleAS Metadata Repository along with the definition of the objects being secured.

User and Group provisioning is a function of Oracle Internet Directory. That is, all user and group membership information is stored in the Oracle Internet Directory. When a user first logs in to OracleAS Portal, their current group membership is read from the directory and cached in the same repository as the ACLs. This process allows for fast lookup of object privileges. Once the object and page privileges of the user are known, the appropriate page metadata can be generated to allow the Parallel Page Engine to assemble the secured page.

To simplify the provisioning of users and groups in Oracle Internet Directory for use in the portal, OracleAS Portal uses Oracle Delegated Administration Services to generate a user interface to allow direct access to Oracle Internet Directory. Calls to Oracle Delegated Administration Services are protected by the mod_osso plug-in, which verifies that the user has been properly authenticated before providing access to the Oracle Internet Directory.

One important feature of the security architecture is the ability to keep the local cached group membership list synchronized with Oracle Internet Directory. The Oracle Directory Integration Platform automatically keeps the locally cached information up-to-date with changes in Oracle Internet Directory.

If you need to authenticate against an external repository, Oracle Internet Directory supports both delegated and external authentication. Likewise, just as the Oracle Directory Integration Platform keeps the local cache synchronized with the Oracle Internet Directory, it also keeps the Oracle Internet Directory synchronized with any external repository.

6.1.2 Classes of Users and Their Privileges

OracleAS Portal provides a number of user accounts and groups by default.

6.1.2.1 OracleAS Portal Default, Seeded User Accounts

Table 6-1 describes the user accounts created by default when OracleAS Portal is installed.

Table 6-1 Default OracleAS Portal Users

User Description

PUBLIC

Is the user account that identifies unauthenticated access to the OracleAS Portal. Once a user logs in, the user name changes from PUBLIC to the user name by which the user is authenticated. When granting portal privileges on individual objects that do not have an explicit check box for granting the object to Public, this user can be identified as the grantee of the privilege to grant access to it for unauthenticated users.

PORTAL

Is the super-user for the portal. In a standard installation, the user name is PORTAL. This user account has the highest privileges because it is granted all the global privileges available in the portal. The initial password for PORTAL is the password that is supplied during the Oracle Application Server installation.

This user is also an Oracle Instant Portal administrator for every Oracle Instant Portal, regardless of who created them.

ORCLADMIN

Similar to PORTAL, this account is granted the highest privileges in OracleAS Portal. This account is created for the Oracle Application Server administrators, and uses the password that is supplied during the Oracle Application Server installation.

This user is also an Oracle Instant Portal administrator for every Oracle Instant Portal, regardless of who created them.

PORTAL_ADMIN

Is a privileged OracleAS Portal user account with administrative privileges excluding those that would give the user the ability to obtain higher privileges or perform any database operations. This user cannot edit any group or manage privileges on any schema or shared object. This account is typically intended for an administrator who manages pages and provisions user accounts. The initial password for PORTAL_ADMIN is the password that is supplied during the Oracle Application Server installation.


6.1.2.2 OracleAS Portal Default, Seeded Groups

Table 6-2 describes the groups created by default when OracleAS Portal is installed.

Table 6-2 Default OracleAS Portal Groups

GroupFoot 1  Description

AUTHENTICATED_USERS

Is the group that includes any authenticated, or logged in, user. The purpose of this group is to provide a means to assign the default privileges you want every logged in user to have in the portal.

By default, this group is given the Create Group and Create All Styles privileges.

This group is a member of OracleDASCreateGroup.

DBA

Is a highly privileged group established for Oracle Application Server administrators. Components that are part of Oracle Application Server grant full component-specific privileges to members of this group.

The DBA group is a member of the PORTAL_ADMINISTRATORS group.

This group is also a member of the following Oracle Application Server privilege groups:

  • OracleDASCreateUser

  • OracleDASEditUser

  • OracleDASDeleteUser

  • OracleDASUserPriv

  • OracleDASCreateGroup

  • OracleDASEditGroup

  • OracleDASDeleteGroup

  • OracleDASGroupPriv

  • OracleDASConfiguration

Members of DBA do not have the necessary privileges to administer OracleAS Single Sign-On. If you want members of this group to administer OracleAS Single Sign-On, then you must grant them those privileges as described in the Oracle Application Server Single Sign-On Administrator's Guide.

PORTAL_ADMINISTRATORS

Is a highly privileged group established for OracleAS Portal.

By default, this group is given the following OracleAS Portal global privileges:

  • Manage All Page Groups

  • Manage All Pages

  • Manage All Styles

  • Manage All Providers

  • Manage All Portlets

  • Manage All Portal DB Providers

  • Manage All Portal User Profiles

  • Edit All Group Profiles

  • Manage All Logs

  • Execute All Transport Sets

This group is a member of the following Oracle Application Server privilege groups:

  • OracleDASCreateUser

  • OracleDASEditUser

  • OracleDASDeleteUser

  • OracleDASCreateGroup

  • OracleDASConfiguration

Members of PORTAL_ADMINISTRATORS do not have the necessary privileges to administer OracleAS Single Sign-On. If you want members of this group to administer OracleAS Single Sign-On, then you must grant them those privileges as described in the Oracle Application Server Single Sign-On Administrator's Guide.

PORTLET_PUBLISHERS

Is a privileged group established for users who need to publish portlets to other users of the portal.

By default, this group is given the Publish All Portlets global privilege of OracleAS Portal.

PORTAL_DEVELOPERS

Is a privileged group established for users who are building portlets.

By default, this group is given the following OracleAS Portal global privileges:

  • Create All Portal DB Providers

  • Manage All Shared Components

If you want PORTAL_DEVELOPERS to create database providers and portlets, you need to give this group privileges that enable them to modify schema, for example, Modify Data on all schemas. For more information, refer to Table 6-6.

RW_ADMINISTRATOR

Is the group of users who administer OracleAS Reports Services reports, printers, calendars, and servers.

You must assign this group any desired object privileges (for example, Manage).

RW_DEVELOPER

Is the group of users who develop OracleAS Reports Services reports.

You must assign this group any desired object privileges (for example, Execute or Manage).

RW_POWER_USER

Is the group of users who can modify OracleAS Reports Services reports.

You must assign this group any desired object privileges (for example, Execute or Manage).

RW_BASIC_USER

Is the group of users who use OracleAS Reports Services reports.

You must assign this group any desired object privileges (for example, Execute).

OIP_USER_ADMINS

Is the group of users who can both create Oracle Instant Portals and perform user administration on them. Both the PORTAL and ORCLADMIN users are members of this group.

OIP_AVAILABLE_USERS

Is the group of users who can access Oracle Instant Portals. This list appears in the Manage User Rights dialog box in the Oracle Instant Portal user interface.

Note: To designate OracleAS Portal users as Oracle Instant Portal users, use the Groups portlet to add them to the OIP_AVAILABLE_USERS group, which was created by default during the installation process. Then use the Manage User Rights dialog in Oracle Instant Portal to grant the appropriate privileges.


Footnote 1 All groups shown in this table are located in cn=<portal_group_container>,cn=Groups,dc=MyCompany,dc=com. Note that identity management realm name is determined by the domain name of the server on which the system is installed. For example, if the domain name of the server was oracle.com, the default identity management realm name would be dc=oracle,dc=com. If the domain name of the server could not be determined, Oracle Internet Directory defaults to the domain specified during installation by the administrator. The OracleDASxxxxx groups are Oracle Internet Directory privilege groups that reside under cn=groups,cn=OracleContext,dc=MyCompany,dc=com. These groups provide the privileges to perform operations in Oracle Internet Directory, such as creating or editing of users and groups, and their privileges.

Notes:

  • When viewing portal-related roles in Oracle Internet Directory Self-Service Console, the descriptions for these roles are prefixed with numbers, for example, portal.040823.142021.462000000. The numbers are actually the name of the OracleAS Portal application, and are displayed to enable selection of roles in a multiple-portal environment where multiple portals associated with the same Identity Management system exist.

  • When a user is granted Manage privileges on any Oracle Instant Portal's home page, he or she is granted full privileges over that particular portal. The user cannot edit, delete, or even view any other Oracle Instant Portal, unless he or she has been granted explicit permission to do so. However, the user can do the following:

    — Create new users.

    — Delete any user in the Manage User Rights dialog box, even those he or she did not create. (For this reason, it's wise to curtail the number of users who have Manage privileges on a home page.)

    — Create new Oracle Instant Portals.

    Refer to the Oracle Instant Portal Getting Started guide for more information.


6.1.2.3 OracleAS Portal Default Schemas

When you install OracleAS Portal, the installation process installs some default schemas of which you need to be aware.

Table 6-3 describes the schemas created by default when OracleAS Portal is installed.

Table 6-3 Default OracleAS Portal Schemas

Schema Description

PORTAL

Contains the OracleAS Portal database objects and code.

To execute Web requested procedures, Portal Services uses N-Tier authentication to connect to the schema to which the lightweight user accounts are assigned (by default, PORTAL_PUBLIC). As shown in Figure 6-2, access to the database of the portal user is proxied through the single schema user.

The default name for this schema in a standard OracleAS Portal installation is PORTAL. If you want to give it another name, you must perform a custom installation.

PORTAL_PUBLIC

Is the schema that all lightweight users are mapped to by default. All procedures publicly accessible through the Web are granted execute to PUBLIC, which makes them accessible through this schema.

In a standard OracleAS Portal installation, this schema is named PORTAL_PUBLIC. If you want to give it another name, you must perform a custom installation.

PORTAL_DEMO

Is created to hold some demonstration code. The installation of this schema is optional.

PORTAL_APP

Is used for external JSP application authentication.


Figure 6-2 shows the N-Tier authentication by user proxy.

Figure 6-2 N-Tier Authentication By User Proxy

Description of Figure 6-2  follows
Description of "Figure 6-2 N-Tier Authentication By User Proxy"

6.1.3 Resources Protected

Within OracleAS Portal, you decide at what level of granularity you want to control access. You can assign privileges to any object for each user or for each group. For example, you can assign access privileges for each user for each and every item in your portal, but this approach creates considerable overhead for your content contributors.

If you want to lessen the burden on contributors, then you can assign privileges for each group at the page level and simply ensure that all of the items that you place on any given page have similar security requirements. With this approach, the security that items receive through the page that contains them is usually sufficient and content contributors only need to assign privileges for items that require higher security than the page.


See Also:

Section 6.1.6.9, "Oracle Delegated Administration Services Public Roles" for information about how you might model privileges.

6.1.3.1 Global Privileges

Use global privileges to give a user or group a certain level of privileges on all objects of a particular type.


Note:

Global privileges confer a great deal of power on the user to whom they are granted. As a result, they should be granted very cautiously and only to users or groups who truly require them. You should only have a small number of users with global privileges.

There are three types of privilege groups:

Table 6-4 Page Group Privileges

Object Type Privileges

All Page Groups

None: No global page group privileges are granted.

Manage All: Perform any task on any page group. This privilege supersedes any other privilege in the other global page group privileges. For example, this also allows managing of any page.

Manage Classifications: Create, edit, and delete any category, perspective, custom attribute, custom page type, or custom item type in any page group.

Manage Templates: Create, edit, and delete any Portal Template or HTML template in any page group. Grant access to any template.

Manage Styles: Create, edit, and delete any style in any page group.

View: View any page in any page group.

Create: Create page groups, and create any page group object in those page groups. Users or groups with these privileges can also edit and delete the page groups and page group objects they create. Note: These users cannot create any objects in the existing page groups.

All Pages

None: No global page privileges are granted.

Manage: Create, edit, personalize, or delete any page in any page group. Grant access to any page in any page group.

Manage Content: Add, edit, hide, show, share, or delete any item, portlet, or tab on any page in any page group.

Manage Items With Approval: Create new items on any page in any page group. These items are not published until approved via a specified approval process. Users and groups with this privilege can also edit the items they create. Users and groups with this privilege can personalize pages. When approvals are not enabled for the page group, this privilege becomes equivalent to the global privilege Manage Content on the object type All Pages with regard to items.

Manage Styles: Apply an available or new style to any page in any page group. Create, edit, and delete new styles. Note: Only allows editing of styles created by user (cannot modify or delete other user's styles).

Personalize Portlets (Full): Personalize any page in any page group to add, show, hide, delete, move, or rearrange portlets. Personalize any page to show, hide, delete, or rearrange tabs, or add tabs to existing tabbed regions. Personalize any page in any page group to use a different style.

Personalize Portlets (Add-only): Personalize any page in any page group to add portlets or add tabs to existing tabbed regions. Users or groups with these privileges can also delete the portlets they add. Personalize any page in any page group to use a different style.

Personalize Portlets (Hide-Show): Personalize any page in any page group to show or hide portlets or tabs. Personalize any page in any page group to use a different style. Arrange portlets in any page in any page group.

Personalize (Style): Personalize any page in any page group to use a different style.

View: View any page in any page group.

Create: Create subpages in any page group. Users or groups with these privileges can also edit and delete the subpages they create. Note: You must have Manage privileges on the root page in a page group in which you want to create the pages.

All Styles

None: No global style privileges are granted.

Manage: Create, edit, and delete any style in any page group.

View: View any style in any page group.

Publish: Make any style in any page group public for other users to use.

Create: Create styles in any page group. Users or groups with these privileges can also edit and delete the styles they create.

All Providers

None: No global provider privileges are granted.

Manage: Register, edit, deregister any provider, and display and refresh the Portlet Repository. Also allowed to grant edit abilities on any provider.

Edit: Edit any registered provider.

Publish: Register and deregister any provider.

Execute: View the contents of any provider.

Create: Register portlet providers. On the provider the user (or group) creates, the user gets a Manage privilege; therefore, the user can perform all operations (including edit and deregister) on the particular provider that the user has created.

All Portlets

None: No global portlet privileges are granted.

Manage: Create, edit, or delete any portlet in any provider.

Edit: Edit any portlet in any provider.

Execute: Execute any portlet in any provider. Users or groups with these privileges can see all portlets even if the portlet security is enforced. The Show link appears in the Navigator for all portlets.

Access: View any portlet in any provider.

Publish: Publish any page, navigation page, or Portal DB Provider portlet to the portal, making it available for adding to pages.


Table 6-5 Portal DB Provider Privileges

Object Type Privileges

All Portal DB Providers

None: No global application privileges are granted.

Manage: Edit or delete any Portal DB Provider. Create, edit, or delete any portlet in any Portal DB Provider. Grant access to any Portal DB Provider and any portlet in any Portal DB Provider.

Edit Contents: Edit any portlet in any Portal DB Provider.

View Source: View the package specification and body and run any portlet in any Portal DB Provider. Intended primarily for users or groups who may want to look at a portlet's source so they know how to call it.

Personalize: Run and personalize any portlet in any Portal DB Provider.

Run: Run any portlet in any Portal DB Provider.

Create: Create Portal DB Providers. Users or groups with these privileges can edit, and delete the providers they create and create, edit, and delete any portlet in them.

All Shared Components

None: No global shared component privileges are granted.

Manage: Create, view, copy, edit, delete, and export any shared component in any Portal DB Provider. View and copy any system shared component. Grant access to any non-system shared component.

Create: Create shared components in any Portal DB Provider. View and copy any system shared component. View any shared component. Users and groups with these privileges can view, copy, edit, delete, and export the shared components they create.


Table 6-6 Administration Privileges

Object Type Privileges

All User Profiles

None: No global user profile privileges are granted.

Manage: Edit any user profile. Grant this privilege to other users and groups.

Edit: Edit any user profile.

All Group Privileges (profiles)

None: No global group profile privileges are granted.

Manage: Edit any group profile. Grant this privilege to other groups. The Privileges tab of the group profile allows the user to assign those privileges to the group. The Manage privilege provides the edit privilege and the ability to grant it to others.

Edit: Edit any portal group profile (setting the default home page and default mobile home page). Note: The ability to change any group's description, memberships, and owners is controlled by the Oracle Internet Directory access control policies, which are administered through membership in the OracleDASEditGroup group.

All Schemas

None: No global schema privileges are granted.

Manage: Create, edit, and drop any schema. Grant access to any schema. Create, edit, drop, and rename any database object in any schema. Query, update, delete, and insert data in any table or view in any schema. Compile any function, procedure, package, or view in any schema. Execute any function, procedure, or package in any schema. Grant access to any database object in any schema.

Modify Data: Create schemas. Query, update, delete, and insert data in any table or view in any schema. Compile any function, procedure, package, or view in any schema. Execute any function, procedure, or package in any schema. Users or groups with these privileges can edit, drop, and grant access to the schemas they create.

Insert Data: Create schemas. Query and insert data in any table or view in any schema. Users or groups with these privileges can edit, drop, and grant access to the schemas they create.

View Data: Create schemas. Query data in any table or view in any schema. Users or groups with these privileges can edit, drop, and grant access to the schemas they create.

Create: Create schemas. Users with these privileges can also edit, drop, and grant access to the schemas they create. Note: If you want a user or group to access the Schemas portlet on the Administer Database tab of the Builder page, either make the user or group a member of the DBA group, or explicitly grant the user or group View privileges on the Administer Database tab. If you do not grant these privileges, the user or group will still be able to use the Navigator to access schemas.

All Logs

None: No global log privileges are granted.

Manage: Edit or purge any log. Grant this privilege to others.

Edit: Edit or purge any log.

View: View any log.

All Transport Sets

None: No global transport set privileges are granted.

Execute: Export and Import objects that are not shared. In addition, users with these privileges can edit or purge Export and Import objects that are not shared.

Manage: Edit or purge any import or export sets. Grant this privilege to others.


6.1.3.2 Object Privileges

You can assign access privileges to users or groups for all of the following objects within OracleAS Portal through the Access tab of the object's Edit Page:

Table 6-7 OracleAS Portal Objects with Privilege Control

Type of Object Available Privileges Inherited Privileges

Calendar

  • Manage

  • View

  • Personalize

  • Execute

From Database Provider

Chart

(based on SQL query)

  • Manage

  • Edit

  • View

  • Personalize

  • Execute

From Database Provider

Chart

(based on wizard)

  • Manage

  • Edit

  • View

  • Personalize

  • Execute

From Database Provider

Data Component

  • Manage

  • Edit

  • View

  • Personalize

  • Execute

From Database Provider

Data Component Cell

  • Edit

  • View

From Data Component

Database Provider

  • Manage

  • Edit

  • View Source

  • Personalize

  • Execute

Not applicable

Document

  • Own

  • Manage

  • View Only

From page or item

Dynamic Page Component

  • Manage

  • Edit

  • View

  • Personalize

  • Execute

From Database Provider

FormFoot 1 

  • Manage

  • Edit

  • View

  • Personalize

  • Execute

From Database Provider

Frame Driver

  • Manage

  • Edit

  • View

  • Personalize

  • Execute

From Database Provider

Hierarchy

  • Manage

  • Edit

  • View

  • Personalize

  • Execute

From Database Provider

Image Chart

  • Manage

  • Edit

  • View

  • Personalize

  • Execute

From Database Provider

Link

  • Manage

  • Edit

  • View

  • Personalize

  • Execute

From Database Provider

List of Values

  • Manage

  • Edit

  • View

  • Personalize

  • Execute

From Database Provider

Menu

  • Manage

  • Edit

  • View

  • Personalize

  • Execute

From Database Provider

OracleAS Reports Services printer

  • Manage

  • Edit

  • View

  • Execute

From Database Provider

OracleAS Reports Services report

  • Manage

  • Edit

  • View

  • Personalize

  • Execute

From Database Provider

OracleAS Reports Services Server

  • Manage

  • Edit

  • View

  • Execute

From Database Provider

Page

  • Manage

  • Manage Content

  • Manage Items With ApprovalFoot 2 

  • Manage Style

  • Personalize Portlets (Full)

  • Personalize Portlets (Add-Only)

  • Personalize Portlets (Hide-Show)

  • Personalize (Style)

  • View

From the root page of the page group

Page group

  • Manage All

  • Manage Classifications

  • Manage Templates

  • Manage Styles

  • View

Not applicable

Page Item

  • Own

  • Manage

  • View Only

From page

Portlet

  • Manage

  • Edit

  • Execute

  • Access

  • Publish

Not applicable

Provider

  • Manage

  • Edit

  • Publish

  • Execute

Not applicable

Query by example form

  • Manage

  • Edit

  • View

  • Personalize

  • Execute

From Database Provider

ReportFoot 3 

  • Manage

  • Edit

  • View

  • Personalize

  • Execute

From Database Provider

Schema

  • Manage

  • Modify

  • Insert

  • View

Not applicable

URL

  • Manage

  • Edit

  • View

  • Personalize

  • Execute

From Database Provider

XML

  • Manage

  • Edit

  • View

  • Personalize

  • Execute

From Database Provider


Footnote 1 You can have many different types of forms (stored procedure or table based, version 2 or version 3 based, and master-detail), but all of these types have the same available privileges and privilege inheritance.
Footnote 2 This privilege is only available on the Access tab if approvals are enabled at the page group level. When approvals are not enabled for the page group, or when approvals are enabled, but there is no approval process defined at the page or page group level, this privilege becomes equivalent to the global privilege Manage Content on the page.
Footnote 3 You can have two different types of reports (SQL and table based), but all of these types have the same available privileges and privilege inheritance.

6.1.3.3 Granting Privileges to New Providers

When you create or register a new provider, a page is created in the Portlet Repository under Portlet Staging Area to display portlets for that provider. This page is not visible to all logged in users. It is only visible to the user who published the provider and portal administrators. The publisher or portal administrator can change the provider page properties to grant privileges to appropriate users or groups, as required.

6.1.3.4 Privileges to Create and Edit Web Providers and Provider Groups

To create and manage Web providers and provider groups through the user interface, as opposed to working with files directly, you need to grant appropriate privileges to the administrative users. The access control list is implemented differently than for the OracleAS Portal schema resident objects. Refer to Section 6.1.3.1, "Global Privileges" and Section 6.1.3.2, "Object Privileges" for information about the OracleAS Portal schema resident objects. Rather, the grants for provider privileges are maintained in an XML file.


Note:

The privileges described here are for users developing new Web providers and pertain to authorizations that are enforced by the provider user interface. These privileges are not required to register Web providers.

To grant privileges to create, edit, and delete Web providers or provider groups, you need to manually make changes to the following file:

MID_TIER_ORACLE_HOME/j2ee/OC4J_Portal/applications/portalTools/providerBuilder/WEB-INF/deployment_providerui/provideruiacls.xml

An example of this file follows:


Note:

In this example, the user names any_provider_manage_user, any_provider_edit_user, and so on, are just sample user names used here to illustrate the privilege codes that correspond to the privileges implied by the corresponding user names. An actual user grant would have the OracleAS Single Sign-On user name as the value of the name attribute in the <user> element, and the privilege would be populated with the appropriate privilege code.

<providerui xmlns="http://www.oracle.com/portal/providerui/1.0">
    <objectType name="ALL_OBJECTS">
        <object name="ANY_PROVIDER" owner="providerui">
           <user name="any_provider_manager_user" privilege="500"/>
           <user name="any_provider_edit_user" privilege="400"/>
           <user name="any_provider_execute_user" privilege="300"/>
           <user name="any_provider_create_user" privilege="100"/>
        </object>
        <object name="ANY_PORTLET" owner="providerui">
           <user name="any_portlet_manage_user" privilege="500"/>
           <user name="any_portlet_edit_user" privilege="400"/>
           <user name="any_portlet_execute_user" privilege="300"/>
        </object>
   </objectType>
   <objectType name="PROVIDER">
        <object name="TEST_PROVIDER" owner="providerui">
           <user name="provider_manage_user" privilege="500"/>
           <user name="provider_edit_user" privilege="400"/>
           <user name="provider_execute_user" privilege="300"/>
      </object>
   </objectType>
   <objectType name="PORTLET">
        <object name="PORTLET_UNDER_TEST_PROVIDER" owner="TESTPROVIDER">
           <user name="portlet_manage_user" privilege="500"/>
           <user name="portlet_edit_user" privilege="400"/>
           <user name="portlet_execute_user" privilege="300"/>
        </object>
   </objectType>
</providerui>

This file allows for granting of the following types of privileges, described in the following sections:

6.1.3.4.1 Global Privileges

Table 6-8 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.

Table 6-8 Global Privilege Codes for provideruiacls.xml

Type of Object Available Privileges

ANY_PROVIDER

500 (Manage): Can create, edit, delete, and open any provider or provider group and portlets under them.

400 (Edit): Can create and edit any provider or provider group and execute the portlets under them.

300 (Execute): Can open any provider or provider group and execute the portlets under them.

100 (Create): Can create any provider or provider group.

ANY_PORTLET

500 (Manage): Can edit, delete, and execute any portlet under any provider.

400 (Edit): Can edit and execute any portlet under any provider.

300 (Execute): Can execute any portlet under any provider.


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

Table 6-9 Object Privilege Codes for provideruiacl.xml

Type of Object Available Privileges

PROVIDER

500 (Manage): Can edit, delete, and open the specified provider or provider group and the portlets under it.

400 (Edit): Can edit the specified provider or provider group and execute the portlets under it.

300 (Execute): Can open the specified provider or provider group and execute the portlets under it.

PORTLET

500 (Manage): can edit, delete, and execute the specified portlet under the specified provider.

400 (Edit): Can edit and execute the specified portlet under the specified provider.

300 (Execute): Can execute the specified portlet under the specified provider.


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-10 summarizes these rules:

Table 6-10 Attribute Values for Providers and Portlets

Attribute Provider Instance Grant Portlet Instance Grant

ObjectType name

PROVIDER

PORTLET

Object name

Provider or provider group name

Portlet name

Object owner

providerui

Provider name

User name

OracleAS Single Sign-On user name

OracleAS Single Sign-On user name

User privilege

Privilege code

Privilege code


6.1.3.5 Privileges to Create and Edit WSRP Producers

For information on granting privileges to create and edit WSRP producers, refer to the Security section of the JSR 168 specification, at http://jcp.org/aboutJava/communityprocess/first/jsr168/index.html.

6.1.3.6 Privileges to Create and Edit URL and XML Portlets in the Portlet Repository

To create and edit URL and XML portlets in the Portlet Repository, privileges need to be granted to the users. The URL and XML portlets are available from the Portlet Builders page in the Portlet Repository. To grant access, or to edit sample providers in the JPDK Web application, you need to manually make changes to following file:

MID_TIER_ORACLE_HOME/j2ee/OC4J_Portal/applications/jpdk/jpdk/WEB-INF/
deployment_providerui/provideruiacls.xml

Refer to Section 6.1.3.4, "Privileges to Create and Edit Web Providers and Provider Groups" for information about the privileges you can grant.

6.1.4 Authorization and Access Enforcement

When users attempt to log in to OracleAS Portal, OracleAS Single Sign-On must first verify their credentials against the directory. Once their identity has been verified, OracleAS Portal checks their access privileges in the directory to determine which objects they may see and use within the portal.

  1. From OracleAS Portal, the user requests to log in by clicking the Login link.

  2. The login request is forwarded to OracleAS Single Sign-On for authentication.

  3. OracleAS Single Sign-On verifies the user credentials against the information stored in the directory.

  4. If authentication is successful, then OracleAS Single Sign-On creates an SSO cookie for the user. If authentication is not successful, the user is denied access and returned to the login page to re-enter their user name and password.

  5. Once the user's identity has been verified, control is returned to OracleAS Portal, which creates a portal session cookie. OracleAS Portal then connects to the directory and determines the user's group memberships and privileges.

  6. OracleAS Portal caches the user's membership and privilege information locally for the duration of their session.

  7. When the user attempts to access a page, OracleAS Portal performs the following checks:

    • Checks whether the page is public. If so, the user can view it.

    • If the page is not public, OracleAS Portal checks the local privilege table to determine whether the current user has privileges to view the page. If the user has viewing privileges, the user can view it.

    • If the current user does not have direct viewing privileges on the page, OracleAS Portal checks the cached membership information and privilege table to determine whether any of the groups to which the user belongs has privileges to view the page. If one of the groups to which the user belongs has viewing privileges on the page, the user can view it.


      Note:

      If changes are made to Oracle Internet Directory that affect the user's privileges, a notification is raised and the cached information about the user is invalidated. Thus, OracleAS Portal starts enforcing the user's updated privileges as soon as it receives the notification. If you are using groups that are based on the groupOfNames objectclass, then you need to update the provisioning profile. See "Update Subscription Profiles for Groups Based on groupOfNames" for more details.

6.1.5 Leveraging Oracle Application Server Security Services

OracleAS Portal leverages Oracle Application Server Security Services in the following ways:

SSL Encryption

The use of HTTPS and the Secure Sockets Layer (SSL) allows for the creation of a secured connection between a client and a server. Digital certificates on each end of the communication verify the validity of the server and encryption of the communication to ensure that it is not compromised. You can implement SSL encryption for OracleAS Portal through the Oracle Application Server Security Services.

JAZN

JAZN is the internal name for a Java Authentication and Authorization Service (JAAS) provider. JAAS is a Java package that enables applications to authenticate and enforce access controls upon users. The use of JAZN in OracleAS Portal is limited to the authentication of external JSPs.

J2EE Security

JPDK Web providers can leverage OC4J J2EE security roles for implementing authorization logic when the container is configured for JAZN LDAP and the portal is configured to use enhanced authentication to ensure message integrity.

6.1.6 Leveraging Oracle Identity Management Infrastructure

To provide a more comprehensive security solution, OracleAS Portal takes advantage of a variety of components in the Oracle Identity Management infrastructure:

OracleAS Portal also takes advantage of Oracle Identity Management when it creates users and groups. The most common way to create users and groups, and set global privileges and preferences for your portal is through the following portlets:

6.1.6.1 Relationship Between OracleAS Portal and OracleAS Single Sign-On

OracleAS Portal uses OracleAS Single Sign-On for user authentication. Refer to Section 6.1.4, "Authorization and Access Enforcement" for more information.

6.1.6.1.1 OracleAS Portal As an OracleAS Single Sign-On Partner Application

OracleAS Single Sign-On manages the Single Sign-On sessions of users. In order for single sign-on security to function properly with OracleAS Portal, the following tasks must be completed:

  • Add OracleAS Portal as a partner application for OracleAS Single Sign-On.

  • Add OracleAS Portal entries to the partner application enabler configuration table.

The Oracle Universal Installer performs these two configuration steps for you upon installation. If you need to make changes to your configuration after installation, you can do so by:

6.1.6.1.2 Support for External Applications

OracleAS Single Sign-On supports the concept of External Applications, which retain their own authentication mechanisms, but for which OracleAS Single Sign-On can automate logins for OracleAS Portal users. This is achieved by providing an External Applications portlet that exposes the list of external applications registered with the single sign-on server.

6.1.6.1.3 Support for Global Inactivity Timeout in OracleAS Portal

A Global Inactivity Timeout can be configured for the OracleAS Single Sign-On Server. This feature is supported from OracleAS Portal 10g Release 2 (10.1.2) onwards. To use this feature, you must configure the OracleAS Single Sign-On Server on the infrastructure tier and mod_osso on the Oracle Application Server middle tier. See the Oracle Application Server Single Sign-On Administrator's Guide for more information on configuring this feature.

6.1.6.2 Relationship Between OracleAS Portal and Oracle Internet Directory

Oracle Internet Directory is Oracle's highly scalable, native LDAP version 3 service and hosts the Oracle common user identity. As stated in the previous section, OracleAS Portal queries the directory to determine a user's privileges and what they are entitled to see and do in the portal. In particular, OracleAS Portal retrieves the group memberships of the user from the directory to determine what they may access and change.

Given this model, OracleAS Portal requires the following interactions with Oracle Internet Directory:

  • OracleAS Portal specific entries stored in the directory

  • Group attributes stored in the directory

  • User attributes stored in the directory

  • Caching of user and group information from the directory

  • Populating user and group lists of values from the directory through Oracle Delegated Administration Services

OracleAS Portal makes use of the features in Oracle Internet Directory to provide efficient user and group management. For a complete list of features provided by Oracle Internet Directory, refer to the chapter, "What's New in Oracle Internet Directory" in the Oracle Internet Directory Administrator's Guide. However, a few of Oracle Internet Directory features are not supported by OracleAS Portal.

Table 6-11 lists and describes the Oracle Internet Directory features not supported in OracleAS Portal.

Table 6-11 Oracle Internet Directory Features Not Supported in OracleAS Portal

Features Description

Dynamic Groups

In dynamic groups, membership is computed dynamically based on specific attribute values and assertions that you specify. The Dynamic Group feature is not supported in OracleAS Portal because it relies on the use of cached information for greater performance and scalability. That is, user and group information is cached within the portal environment while assembled pages and content are cached within OracleAS Web Cache. The invalidation and subsequent flushing of the cache occurs when the definition of a user or the user's group membership changes. The change is propagated to OracleAS Portal using a Directory Integration Subscription Event. In the case of dynamic groups, there is no group change event because the membership is evaluated for each LDAP query and therefore there is no method of propagating this to the portal.

You can use the Oracle Internet Directory Plug-in functionality to generate a static group populated by the outcome of a Dynamic Group query. This enables the use of groups based on attributes, but the provisioning and maintenance of this group may have a significant impact on the overall performance of the system (based on the size of the group and so on).

Single Authentication Security Layer (SASL)

SASL is a method for adding authentication support to connection-based protocols. Oracle Internet Directory server supports SASL-based authentication mechanisms, but currently these mechanisms are not supported in the DBMS_LDAP package, which is used by OracleAS Portal.

Client-side referral caching

For performance reasons, an API can be used to cache the cached referral entries on the client side. Currently, there is no support for client-side referral caching in the DBMS_LDAP package, which is used by OracleAS Portal.


6.1.6.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=comFoot 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=com1). 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-3 shows where the OracleAS Portal information is located in the directory's DIT structure.

Figure 6-3 OracleAS Portal DIT Structure

Description of Figure 6-3  follows
Description of "Figure 6-3 OracleAS Portal DIT Structure"

Under cn=Groups,cn=OracleContext,<subscriber_dn>, there is a cn=Groups container, that contains the following groups:


authenticationServices
userProxyPrivilege
iasadmins
OracleDASCreateUser
OracleDASEditGroup
OracleDASCreateGroup
OracleDASEditUser
OracleDASDeleteUser
OracleDASUserPriv
OracleUserSecurityAdmins
OracleDASDeleteGroup
OracleDASGroupPriv
OracleDASConfiguration

These privilege group entries are modified during a portal installation to add portal groups and the portal application entry to their memberships, to achieve desired portal functionality. As such, portal information is contained in these groups as well.

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

Table 6-12 inetOrgPerson Attributes

inetOrgPerson (IETF) attributes Comment

cn

Common name of the user

This attribute is mandatory.

employeeNumber

Number used to identify employees

sn

Last name. This attribute is mandatory. If nothing is explicitly specified for this attribute, the user's nickname is used.

givenName

First name

middleName

displayName

Preferred name

mail

e-mail address

telephoneNumber

homePhone

mobile

pager

facsimileTelephoneNumber

street

l

City of office

st

State of office

postalCode

Postal code of office

c

Country of office

homePostalAddress

Home address

jpegPhoto

Person's picture

o

Organization

title

manager

Employee's supervisor

uid

User ID

userPassword

preferredLanguage


Table 6-13 orclUserV2 Attributes

orclUserv2 attributes Comments

orclIsVisible

A flag to indicate whether the user should be hidden from all but administrators.

orclDisplayPersonalInfo

A flag to indicate whether a user's personal information should be hidden from all but administrators.

orclMaidenName

orclDateOfBirth

orclHireDate

orclDefaultProfileGroup

Default user group for the person

orclActiveStartDate

When account was activated

orclActiveEndDate

when account was (or will be) terminated

orclTimeZone

orclIsEnabled

A flag to indicate whether the user account is active. If not active, the user will not be allowed to log in.


6.1.6.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-4 shows where the OracleAS Portal information for groups is located in the directory's DIT structure.

Figure 6-4 DIT Structure for OracleAS Portal Groups

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

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

Table 6-14 groupOfUniqueNames/groupOfNames Attributes

groupOfUniqueNames/groupOfNames (IETF) attributes Comment

cn

The common name of the group, which can be typed into places like the Edit Group field in the Group portlet to locate the group.

description

The text description of the group, which is displayed in lists of values where the group appears.

uniqueMember/member

A list of the distinguished names (DNs) of all of the members of the group. The member DNs can represent a user or another group.

owner

A list of the DNs of all of the users and groups that have the privilege of administering this group.


Table 6-15 orclGroup Attributes

orclGroup attributes Comment

orclGUID

The globally unique identifier (GUID) for this group.

orclIsVisible

A flag to indicate whether the group is public or private. Private groups only appear in lists of values for their owners. Other users cannot see them.


6.1.6.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.6.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. From OracleAS Portal 10g Release 2 (10.1.2) onwards, 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.6.3 Relationship Between OracleAS Portal and Oracle Directory Integration Platform

As shown in Figure 6-5, the Oracle Directory Integration Platform provides important services to notify components of user and group change events and synchronize directories.

Figure 6-5 Oracle Directory Integration Platform Synchronization

Description of Figure 6-5  follows
Description of "Figure 6-5 Oracle Directory Integration Platform Synchronization"

In the figure, the flow to and from the Oracle Internet Directory has two paths. The first path, labeled Oracle Directory Synchronization Service, shows the concept of synchronization. In this case, the Oracle Internet Directory acts as a gateway to some external directory or repository. The synchronization service ensures that changes are coordinated between the Oracle Internet Directory and its connected directories. Whenever a change occurs in one of the directories, a notification must be raised with the Oracle Internet Directory to appropriately reflect the change across all of the affected directories.

The second path, labeled Oracle Directory Provisioning Integration Service, shows the concept of provisioning. In provisioning, an application, such as OracleAS Portal, subscribes to changes to certain user or group information. For example, suppose that an administrator removes a user from a group through the Oracle Delegated Administration Services. As a result of this change, the user should no longer be allowed to access certain pages in OracleAS Portal. The Oracle Directory Integration Platform must notify OracleAS Portal to update its local cache and immediately prevent the user from accessing the pages to which she no longer should have access.

For provisioning services, components like OracleAS Portal subscribe to provisioning events (for example, deletion of a group) to keep their local caches of user and group information synchronized with the central user and group repository in the Oracle Internet Directory. When a change event occurs, all of the components that are subscribed to that change event are notified by the Directory Synchronized Provisioning agent of the Oracle Directory Integration Platform. OracleAS Portal sets the portal directory synchronization subscription flag in the directory to indicate that it should be notified whenever a subscribed change event takes place. Table 6-16 shows the events to which OracleAS Portal subscribes and the actions it takes when those events occur.

Table 6-16 Directory Synchronized Events Handled By OracleAS Portal

Subscribed event OracleAS Portal action

USER DELETE

The local user profile entry is deleted, resulting in the deletion of the user's privileges. Pages associated with this user are invalidated in OracleAS Web Cache.

USER MODIFY

(orclDefaultProfileGroup)

The default group of the user is changed in the local user profile.

GROUP DELETE

The local group profile is deleted, resulting in the deletion of the privileges assigned to this group. The WWSEC_FLAT$ table is updated accordingly.

GROUP MODIFY

(uniqueMember, member)

The WWSEC_FLAT$ table is updated to reflect membership changes that affect OracleAS Portal.

If the membership changes involve a group being added or deleted from the modified group, the pages associated with the users of the added or deleted group are invalidated in OracleAS Web Cache. The reason for this action is that the security changes might affect what is visible on the page or the access privileges of the page itself.



Note:

OracleAS Portal does not need to subscribe to user and group creation events. The local user profile is created automatically when a new user first logs on or is assigned some privilege that causes the user to be referenced in an access control list (ACL) of OracleAS Portal. Similarly, a local group profile is created automatically when a new group is first referenced in an ACL.

To function properly, OracleAS Portal requires the following for its integration with Oracle Directory Integration Platform:

  • The Oracle Directory Integration Platform must be running. With OracleAS Portal Release 9.0.4 and later, the Oracle Directory Integration and Provisioning agent is started by default if the user had started the infrastructure tier using opmnctl start all. To start the Oracle Directory Integration Platform, you use the oidctl command, for example:

    oidctl instance=1 server=odisrv flags="host=iasqa-ultra1.abc.com port=4032" start
    
    
  • The subscription profile must be created in the Oracle Internet Directory. A default subscription profile is automatically created during the installation of OracleAS Portal.

6.1.6.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.6.4 Relationship Between OracleAS Portal and Oracle Delegated Administration Services

In addition to querying the directory for user and group information, OracleAS Portal must provide users with the means to add and modify user and group information. To change information in the directory, use the Oracle Delegated Administration Services. OracleAS Portal provides links to the delegated administration server for users with the privileges to add and change users and groups.

6.1.6.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.6.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-6 Relationship between Oracle Delegated Administration Services, mod_osso, and OracleAS Single Sign-On

Description of Figure 6-6  follows
Description of "Figure 6-6 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.6.5 User Portlet

The User portlet on the Portal tab under Administration enables you to create and update users through Oracle Delegated Administration Services. To create a new user, click the Create New Users link in the User portlet. To update information for an existing user, enter their user name in the Name field or choose it from the list of values and click Edit. To delete a user, enter their user name in the Name field or choose it from the list of values and click Delete.


Note:

Only a user who is a member of the OracleDASCreateUser, OracleDASEditUser, or OracleDASDeleteUser privilege groups can see the User portlet. The link to create new users is displayed only to users who are members of the OracleDASCreateUser group.

6.1.6.6 Portal User Profile Portlet


Note:

The Portal User Profile portlet is only visible to users with Manage or Edit privileges for All User Profiles.

To set global user privileges and preferences that pertain specifically to the portal, use the Portal User Profile portlet. To update a user's portal preferences and privileges, enter their user name in the Name field or choose it from the list of values. You can set all of the following for the user's profile:

  • Preferences

    • whether the user can access the portal

    • database schema name for the user

    • whether the user has a personal page

    • default user group for the user

    • default home page for the user

    • default style for the user

    • whether to clear the OracleAS Web Cache for the user

  • Global Privileges

    • page group privileges

    • Portal DB Provider privileges

    • administration privileges

Figure 6-8 Portal User Profile Portlet

Description of Figure 6-8  follows
Description of "Figure 6-8 Portal User Profile Portlet"

6.1.6.7 Group Portlet


Note:

Every user can see the Group portlet, but the link to create new groups is displayed only to users who are members of the OracleDASCreateGroup privilege group. Users can only edit or delete a group if they are the group's owner or a member of a group with appropriate access control information (ACI) to edit or delete the group. The following privilege groups are seeded in the Oracle Internet Directory:
  • OracleDASCreateGroup

  • OracleDASEditGroup

  • OracleDASDeleteGroup

The preceding privilege groups imply global privileges, and should be allocated carefully.


The Group portlet on the Portal tab under Administration enables you to create and update user groups through Oracle Delegated Administration Services. To create a new group, click the Create New Groups link in the Group portlet. To update information for an existing group, enter its name in the Name field or choose it from the list of values and click Edit. To delete a group, enter the group name in the Name field or choose it from the list of values and click Delete.

6.1.6.8 Portal Group Profile Portlet


Note:

The Portal Group Profile portlet is displayed to all users, but only users with the Manage or Edit privilege for All Group Profiles, or the owner of a group can edit its profile.

To set global group preferences and privileges that pertain specifically to the portal, you need to use the Portal Group Profile portlet. To update a group's portal preferences and privileges, enter the group name in the Name field or choose it from the list of values. You can set all of the following for the group's profile:

  • Preferences

    • default home page for the group

    • default style for the group

  • Global Privileges

    • page group privileges

    • Portal DB privileges

    • administration privileges

Figure 6-10 Portal Group Profile Portlet

Description of Figure 6-10  follows
Description of "Figure 6-10 Portal Group Profile Portlet"

6.1.6.9 Oracle Delegated Administration Services Public Roles

In many cases, it is more efficient to use roles exposed by Oracle Delegated Administration Services to assign privileges for each individual user. When creating users, you might notice a section called Roles Assignment on the Create User page, shown in Figure 6-11.


Note:

In releases before 9.0.4, roles were called public groups.

Figure 6-11 OracleAS Portal Create User Page

Description of Figure 6-11  follows
Description of "Figure 6-11 OracleAS Portal Create User Page"

Roles provide a very convenient mechanism by which users can be created and granted a set of privileges simultaneously. When a check box for a role is checked for a given user, they are granted the designated role upon creation. As an administrator, you can create your own roles and pre-assign any combination of Oracle Internet Directory and OracleAS Portal privileges to them.

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

    Figure 6-12 Create Group Page

    Description of Figure 6-12  follows
    Description of "Figure 6-12 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-13:

    • Allow user creation

    • Allow user editing

    • Allow user deletion

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

    Description of Figure 6-13  follows
    Description of "Figure 6-13 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-14. From the list next to All User Profiles, choose Manage.

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

    Description of Figure 6-14  follows
    Description of "Figure 6-14 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-15.

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

    Figure 6-15 Configure Roles Page

    Description of Figure 6-15  follows
    Description of "Figure 6-15 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. Select Refresh Cache for OID Parameters.

    7. Click Apply.

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.7 Security for Portlets

Portlets act as windows on your application, displaying summary information and providing a way to access the full functionality of the application. Portlets expose application functionality directly in your portal or provide deep links that take you to the application itself to perform a task. Because portlets format information for display on a Web page, the underlying application need not be Web enabled to be integrated with OracleAS Portal.

In OracleAS Portal, portlets are managed by providers. A provider is an application that you register with OracleAS Portal. OracleAS Portal supports three types of providers:

  • Web providers

  • Database providers

  • Web Services for Remote Portlets (WSRP) producers

Portlet security consists of three major areas of functionality:

  • Authentication: When a user first accesses a secure URL, they must be challenged for information that verifies their identity, such as a user name and password, or a digital certificate.

  • Authorization: Authorization is the process that allows certain users to access parts of an application. Some parts of an application may have public access while others may be accessible only to a limited number of authenticated users.

  • Communication security: Communication security is the means by which OracleAS Portal establishes the authenticity of communications (for example, messages) to and from providers. In a heavily networked environment, it is critical to verify that communications are authenticate.

To make your Web providers truly secure, you need to make sure that they are secured in each of these areas. If you only implement security features for one or two out of three areas, then your providers cannot be considered secure. The effort you expend to secure a Web provider should be proportional to the confidentiality of the data the provider exposes.

To make your WSRP portlets secure, ensure that OracleAS Portal and the WSRP producers communicate through an inherently secure network, such as a VPN network or a network that is behind a firewall.

6.1.7.1 Authentication

When a user first logs in to OracleAS Portal, they must enter their password to verify their identity before being permitted access. OracleAS Single Sign-On manages the login process. Refer to Section 6.1.7.7, "Single Sign-On" for more information.

6.1.7.2 Authorization

Authorization determines whether a particular user should view or interact with a portlet. There are two types of authorization checks:

  • Portal Access Control Lists: When you log in to OracleAS Portal, OracleAS Single Sign-On authenticates you. Once authenticated, OracleAS Portal uses access control lists (ACLs) to grant you privileges on portal objects such as pages and portlets. The actions may range from simply viewing an object to performing administrative functions. If you do not belong to a group that has been granted a specific privilege, OracleAS Portal prevents you from performing the actions associated with that privilege.

  • Programmatic Portlet Security: The Portal Developer's Kit-Java includes APIs that are called to determine if a particular user is authorized to view a portlet. You can use these APIs to implement authorization logic that augments the Portal ACL security.

  • J2EE Security Roles: You can use J2EE programmatic security in your provider code. To leverage this capability, you must configure your provider for enhanced authentication to protect the integrity of the asserted identity. From within your portlet code, you can use request.isUserInRole("securityrole"), where request is the HttpServletRequest request and securityrole is a declared J2EE security role. Refer to Section 6.3.1.3.2, "Enhanced Authentication" for more information on how to configure enhanced authentication.

6.1.7.3 Communication Security

Authentication and authorization are important components of securing your Web providers. They do not, however, check the authenticity of messages being received by a provider and are therefore not suitable on their own for securing access to a provider. If the communication is unsecured, someone could imitate OracleAS Portal and fool the Web provider into returning sensitive information.

Communication security focuses on securing communications between OracleAS Portal and a JPDK Web provider. These methods do not apply to database providers, which execute within the portal database. There are three types of communication security:

  • Portal Server Authentication ensures that incoming messages came from a trusted host.

  • Message Authentication ensures that the incoming messages were not tampered with.

  • Message Encryption protects the contents of a message by encrypting them.

6.1.7.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.7.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.7.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 and provide confidentiality. While encryption provides a high level of security, it also of necessity impacts performance.


Note:

Use of the HTTPS protocol for communication between OracleAS Portal and WSRP producers is not supported in this release.

6.1.7.4 Access Control Lists

When you log in to OracleAS Portal, OracleAS Single Sign-On authenticates you. OracleAS Portal then uses access control lists (ACLs) to determine if you are authorized to view each piece of content, including providers and portlets. If you do not belong to a group that has been granted a specific privilege, OracleAS Portal prevents you from performing the actions associated with that privilege.

ACLs are managed by the following:

  • Privileges define the actions that can be performed on the object to which they are granted. Several privileges can be granted, such as Manage, Execute, Access, and Publish. If you set any of these privileges, then the user can access the portlet.

  • Users and their privileges are managed from the Portal tab under the Administer tab of the builder.

  • Group membership in a group and the privileges granted to the group are managed from the Portal tab under the Administer tab of the builder. A privilege granted to a user group is inherited by all members of that group.

  • Privileges can be granted to a provider. By default, those privileges apply to the provider and all the portlets in the provider. Provider ACLs are managed on the Provider tab of the navigator.

  • Privileges for portlets can override the privilege set for the portlet's provider. Portlet ACLs are managed on the Provider tab of the navigator. Using Open for the Provider takes you to a page to manage the portlets of the provider.

6.1.7.4.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.7.4.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.7.5 OracleAS Portal Server Authentication

One way you can prevent unauthorized access to providers is to restrict access to the provider to known client computers at the server level. This method goes some way toward defending against denial of service attacks.

In the Oracle HTTP Server, you can permit or deny directives in the httpd.conf file based on hostnames or IP addresses. If hostnames are used as discriminators, the server needs to look them up on its Domain Name Server, which incurs overhead to the processing of each request. Using the IP address prevents this added overhead, but the IP address may change without warning.

6.1.7.5.1 Advantages

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

  • You can set the restrictions up easily.

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

The following sections are applicable for Web providers only and not WSRP producers.

6.1.7.6 Securing the Portal Tools Provider Configuration Pages

Out of the box, the Portal Tools (OmniPortlet and Web Clipping) provider configuration pages are protected with certain privileges. Refer to Section 6.1.3.4, "Privileges to Create and Edit Web Providers and Provider Groups" for more information about these privileges. In the event that the pages are no longer protected, check in the web.xml file under the ORACLE_HOME/j2ee/OC4J_Portal/applications/portalTools/providerBuilder/WEB-INF directory, that the following param-value is set to true and not false:

<init-param>
<param-name>oracle.webdb.providerui.securedAccessParam</param-name>
<param-value>true</param-value>
</init-param> 

6.1.7.7 Single Sign-On

Portlets act as windows into an application by displaying a summary of content and a method for accessing the full functionality of the application. Portlets can expose application functionality directly in the portal or provide deep links into the application itself to perform a task.

If the application does not perform authorization, then users need not be authenticated to see and use it or its associated portlets. For more restricted applications, you need to authenticate the user who is accessing the application:

  • Partner applications share the same authenticated user as the OracleAS Portal user. The application user and the OracleAS Portal user are the same in this case.

  • External applications use a different authentication mechanism than OracleAS Portal and usually a different repository for user credentials. The application user name can be the same as in OracleAS Portal, but the external application verifies the user through its own mechanism.

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

In order to protect the integrity of the identity assertion made by OracleAS Portal to the provider, message authentication with HMAC should be configured. See Section 6.3.1.3, "Configuring Provider Message Authentication" for information on how to set this up.

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.7.7.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 that 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 in to 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 JPDK Web providers.


See Also:

For more information about the External Applications portlet, see the Oracle Application Server Portal User's Guide.

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.


Note:

If there is a change in the URL of an external application, then the external application must be updated in the OracleAS Single Sign-On Server. For information about updating the external application, refer to the "Editing an External Application" section in the Oracle Application Server Single Sign-On Administrator's Guide.

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. Configuring the provider URL to use SSL addresses this issue.

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

6.1.7.7.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. However, this may not be an issue if your portlet content is not sensitive, or if the provider location is secured by the network topology and only accessible by the portal.

6.1.7.8 Programmatic Portlet Security

You can implement portlet security methods within a provider to verify that given users may access portlet instances. These security methods work at the portlet level, that is, each portlet may have its own user access control. By implementing access control methods in the provider, content may only be retrieved from a portlet if the user's credentials pass the authorization logic. If you do not implement portlet security methods in the provider, any user name may be passed in, even a fictitious, unauthenticated one.

A provider can implement two portlet security methods:

  • Get a list of portlets

  • Determine portlet accessibility

These methods have access to the following information about authorization level:

  • Strong indicates that OracleAS Single Sign-On has authenticated a user in the current OracleAS Portal session, that is, the user logged in to OracleAS Portal with a valid user name and password, and called the portlet in that session.

  • Public indicates a user has not logged in within the context of the current OracleAS Portal session and does not have a persistent cookie to indicate that such a state previously existed.

Portlets can also access the OracleAS Portal user privileges and group memberships:

  • User's default group

  • User or group privileges

  • User's highest available privilege across all groups

  • Objects a user can access

6.1.7.8.1 Advantages

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

6.1.7.8.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.7.9 Message Authentication

The Oracle Application Server Portal Developer Kit supports message authentication to limit access to a specified provider instance or group of provider instances. A provider is registered with a secret shared key known only to the portal and provider administrators.

An OracleAS Portal instance sends a digital signature, calculated using a Hashed Message Authentication Code (HMAC) algorithm, with each message to a provider. A provider may authenticate the message by checking the signature with its own copy of the shared key. This technique may be used in SSL communication with a provider instead of client certificates.

An OracleAS Portal instance calculates a signature based on user information, a shared key, and a time stamp. The signature and time stamp are sent as part of the SOAP message. The time stamp is based on UTC (coordinated universal time, the scientific name for Greenwich Mean Time) so that time stamps can be used in messages between computers in different time zones.

When the provider receives this message it will generate its own copy of the signature. If the signatures agree, it will then compare the message time stamp with the current time. If the difference between the two is within an acceptable value the message is considered authentic and processed accordingly.

A single provider instance cannot support more than one shared key. Multiple keys could cause security and administration problems if several clients sharing a provider use the same key. For instance, if one copy of the shared key is compromised in some way, the provider administrator has to create a new key, distribute it to all of the clients, and the clients must then update their provider definition. The way around this issue is to deploy different provider services, specifying a unique shared key for each service. Each provider service has its own deployment properties file so that each service is configured independently of the others. The overhead of deploying multiple provider services within the same provider adapter is relatively small.

If a provider does not have an OracleAS Web Cache in front of it, the use of the same signature cookie over the lifetime of a provider session means you must trade off between performance and the security provided by authenticating the requests. The signature cookie value is calculated only once after the initial SOAP request establishes the session with the provider. The shorter the provider session timeout, the more often a signature will be calculated to provide greater security against an illegal show request. However, the SOAP request required to establish a session takes more time.

In a provider that uses OracleAS Web Cache to cache show request responses, you make a similar trade-off. Cached content is secured in the sense that incoming requests must include the signature cookie to retrieve the cached content, but caching content for an extended period of time leaves the provider open to illegal show requests.

The signature element provides protection against interception and the resending of messages, but it does nothing to prevent the interception and reading of message contents. Messages are still transmitted in plain text. If you are concerned about the content of messages being read by unauthorized people, you should use message authentication in conjunction with SSL.

6.1.7.9.1 Advantages

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

6.1.7.9.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.7.10 HTTPS Communication

Normal communication between OracleAS Portal and a provider uses HTTP, a network protocol that transmits data as plain text using TCP as the transport layer. An unauthorized agent can read an intercepted message. HTTPS uses an extra security layer (SSL) on top of TCP to secure communication between a client and a server.

Each entity (for example, an OracleAS Web Cache instance) that receives a communication using SSL has a freely available public key and a private key known only to the entity itself. Any messages sent to an entity are encrypted with its public key. A message encrypted by the public key may only be decrypted by the private key so that even if a message is intercepted it cannot be decrypted.

Certificates are used to sign communications, thereby ensuring that the public key does in fact belong to the correct entity. These certificates are issued by trusted third parties known as Certification Authorities (CA), for example, OracleAS Certificate Authority or Verisign. They contain an entity's name, public key, and other security credentials. They are installed on the server end of an SSL communication to verify the identity of the server. Client certificates may also be installed on the client to verify the identity of a client, but this feature is not yet supported OracleAS Portal. Message authentication may be used instead.

Oracle Wallet Manager is the application used to manage public key security credentials. It is used to generate public/private key pairs, create a certificate request to a CA, and then install the certificate on a server.

6.1.7.11 Configuration of SSL

When a provider is registered from an OracleAS Portal instance, only one URL is entered. HTTP or HTTPS may be used, but not a combination of both.

A server side certificate that is installed on a computer identifies that computer, or the domain, and may be used by any number of port definitions on that computer. A certificate trust list ensures that communication is limited to specifically identified servers. Message authentication should be used as well to fully secure communication between a trusted OracleAS Portal instance and a provider.

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

More on OTN

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

  • Overview of Provider Security

  • Overview of Password Authenticated Applications

on the Oracle Technology Network (OTN), http://www.oracle.com/technology/.

6.1.8 Securing the OmniPortlet and Simple Parameter Form

The OmniPortlet and simple parameter form are located under Portlet Builders in the Portlet Repository. By default, any user who has the privilege to create pages can add these portlets to a page and define them. Furthermore, a user who has at the minimum Manage Content privileges on the page can define these portlets by clicking the Define OmniPortlet or Define Simple Parameter Form.

To control this kind of access, you can activate a privilege check. Once you perform the procedure that follows, the display of these portlets depends upon the privileges granted to the user or user group from the Access tab. To perform any operations on the portlet, the user or user group needs at least the Execute privilege.

  1. Log in to OracleAS Portal.

  2. Click the Navigator link.

  3. Click the Portlet Repository page group.

  4. Click Pages.

  5. Next to the Portlet Builders page, click Edit.

  6. Click Page: Access in the upper left of the page.

  7. Select Enable Item Level Security.

  8. Click OK.

  9. Click the Edit Item icon next to OmniPortlet.

  10. Click the Access tab.

  11. Check Define Portlet Access Privileges.

  12. Click Apply and note the appearance of the Grant Access and Change Access sections of the page.

  13. Use the Grant Access section to assign privileges to users and groups as desired.

  14. Click OK.

  15. Repeat steps 9 through 14 for the Simple Parameter Form.

6.1.9 Securing the Web Clipping Provider

Appendix I, "Configuring the Portal Tools Providers" describes the administrative tasks that must be performed before you are able to use the Web Clipping provider. The following sections describe some security configuration options that you should implement to enable the Web Clipping provider to access trusted sites and encrypt the channel between itself and the database:

6.1.9.1 Adding Certificates for Trusted Sites

When a user navigates to a secure site, the Web site typically returns a certificate, identifying itself to the user when asking for secure information. If the user accepts the certificate, the certificate is placed into the list of trusted certificates of the browser so that a secure channel can be opened between the browser and that server. Like a Web browser, the Web Clipping provider behaves as an HTTP client to external Web sites. In order for the Web Clipping provider to keep track of trusted sites, it makes use of a file that stores the certificates of those sites, namely the ca-bundle.crt file, located in the MID_TIER_ORACLE_HOME/portal/conf directory.

The shipped ca-bundle.crt is an exported version of the trusted server certificate file from Oracle Wallet Manager. The default trusted server certificate in Oracle Wallet Manager does not cover all possible server certificates that exist on the Web. For this reason, when a user navigates to a secure server using HTTPS, the user may get an SSL Hand-shake failed exception in the Web Clipping Studio. To solve this problem, the ca-bundle.crt file needs to be augmented with new trusted sites that are visited. As a portal administrator, you must do the following to extend the shipped ca-bundle.crt file:

  1. Use a browser (preferably Internet Explorer) to download the root server certificate from each external HTTPS Web site in BASE64 format that is visited, and is missing from the trusted certificate file.

  2. Use Oracle Wallet Manager to import each certificate.

  3. Export the trusted server certificates into a file and replace the ca-bundle.crt file with that file.

More on OTN

For more information about Oracle Wallet Manager, see the Oracle Database Advanced Security Administrator's Guide in the Oracle Database documentation on OTN, http://www.oracle.com/technology/.

6.1.9.2 Configuring Oracle Advanced Security for the Web Clipping Provider

The Web Clipping provider can use Oracle Advanced Security Option (ASO) to secure and encrypt the channel between itself (on the middle tier) and the database that hosts the Web Clipping Repository. As ASO is a feature available only on Oracle Application Server Enterprise Edition, or as an add-on option to the Standard Edition, this feature is disabled by default. To enable it, perform the following steps:

  1. Go to the Web Clipping provider test page at:

    http://<host>:<port>/portalTools/webClipping/providers/webClipping
    
    
  2. Under the Provider Configuration section, in the Setting column, there is a Web Clipping Repository field. Click its corresponding Edit link in the Actions column.

  3. In the Repository Settings section of the Edit Provider: webClipping page, select the enable (secure database connections) option in the Advanced Security Option field.

  4. Select OK to save the settings and return to Web Clipping provider test page.

In addition, you must set the following ASO configuration parameters in the sqlnet.ora file to ensure that the database connections created between the Web Clipping provider and the database hosting the Web Clipping Repository are using ASO. See the Oracle Advanced Security Administrator's Guide for the list of values to use as all possible combinations of parameters are described in detail.

  • SQLNET.AUTHENTICATION_SERVICES -- This parameter is used to select a supported authentication method in making database connections with ASO. See the Oracle Advanced Security Administrator's Guide for more information about setting this parameter.

  • SQLNET.CRYPTO_SEED -- This parameter denotes the cryptographic seed value (FIPS 140-1 setting), used in making database connections with ASO.

    See the Oracle Advanced Security Administrator's Guide for more information about setting this parameter.


    Note:

    When setting these parameters after the initial configuration (where the database parameters are already set up), the database connections are assumed to be open already. Because enabling ASO affects all connections made to the database, it is advisable to restart the OC4J instance containing the Web Clipping provider to reset all the current connections to now use ASO. You would also need to do this when disabling ASO.

6.1.10 Securing the Federated Portal Adapter

The Federated Portal Adapter is a component of OracleAS Portal that allows portal instances to share their portlets through the Web portlet interface. For example, suppose that a user displays a page in one portal instance that contains a portlet whose source resides on another portal instance. When the Federated Portal Adapter on the remote portal receives the request for the portlet, it starts a session for the user on the remote portal. The portlet can then be run from the remote portal instance by the user. This scenario has a couple of security implications:

  • Because the Federated Portal Adapter must create a session for the user on the remote portal, it would be best for the two portal instances to share the same single sign-on server. Otherwise, name collisions could occur when the Federated Portal Adapter attempts to log the user onto the remote portal instance.

  • Because the Federated Portal Adapter creates private portal sessions based on SOAP messages it receives, it is a potential security risk. A message authentication code must be used to ensure that any messages received by the Federated Portal Adapter emanate from a trusted source.

More on OTN

You will find additional information in the article "How to Add Remote Portlets Using the Federated Portal Adapter," on OTN, http://www.oracle.com/technology/.

6.1.11 Securing OraDAV

WebDAV (World Wide Web Distributed Authoring and Versioning) is the IETF's standard for collaborative authoring on the Web. It defines a set of extensions to HTTP that facilitates collaborative editing and file management between users located remotely from each other on the Internet.

OraDAV, Oracle's implementation of WebDAV, is the mechanism used by the Oracle HTTP Server to communicate with WebDAV clients. OraDAV enables your users to connect to OracleAS Portal using their WebDAV clients. In terms of security, accessing OracleAS Portal through WebDAV presents two security issues for you to consider:

  • Expiration of OracleAS Portal session cookies for OraDAV

  • SSL and OraDAV

6.1.11.1 Session Cookie Expiration

The OraDAV configuration parameter, ORACookieMaxAge, specifies, in seconds, the length of time for which the DAV client should retain the cookie. The default value is 28800 (that is, 8 hours).

ORACookieMaxAge can be changed in Oracle Enterprise Manager or by directly editing it in the oradav.conf file located in MID_TIER_ORACLE_HOME/Apache/oradav/conf. If you choose to manually change the file, you must synchronize the changes with Dynamic Configuration Management. Once the change has been made in the configuration file, you need to restart the Oracle HTTP Server to have the changes take effect in the runtime system:

cd MID_TIER_ORACLE_HOME/dcm/bin
./dcmctl shell
- dcmctl> updateConfig -ct ohs

After you exit the dcmctl shell, execute the following command from MID_TIER_ORACLE_HOME\opmn\bin to restart the Oracle HTTP Server:

opmnctl restartproc type=ohs

Note:

Not all WebDAV clients use cookies. Some perform their authentication on each request using HTTP basic authentication. A client may choose to record the user name and password for the duration of that WebDAV client session and thus only need to prompt the user once for their credentials. In either case, though, this behavior results in a slower response time from OracleAS Portal because every request from such clients must be authenticated, requiring added communication with the Oracle Internet Directory.

6.1.11.2 SSL and OraDAV

The use of SSL for WebDAV communication is supported with OraDAV.

6.2 Configuring OracleAS Security Framework for OracleAS Portal

This section describes considerations for:

6.2.1 Configuring OracleAS Security Framework Options for OracleAS Portal

For OracleAS Portal, the main consideration when configuring the OracleAS Security Framework is how to properly configure SSL. Refer to Section 6.3.2.1, "Configuring SSL for OracleAS Portal" for a full description of SSL configuration for OracleAS Portal.

6.2.2 Configuring Oracle Identity Management Options for OracleAS Portal

As you configure OracleAS Portal for security, you should consider the following topics related Oracle Identity Management:

6.2.2.1 Setting the Appropriate Naming and Nickname Attributes

When deciding on the Directory Information Tree structure and the setting of the Oracle Context parameters for your Oracle Identity Management Infrastructure, you should consider making the naming attribute different from the nickname attribute. The naming attribute is used for the first attribute in the entry's Distinguished Name. By contrast, the nickname attribute holds the OracleAS Single Sign-On user name.

For OracleAS Portal to properly support renaming users by changing the value of the nickname attribute in the Oracle Internet Directory, the nickname attribute must be different than the naming attribute. By keeping the two separate, the Distinguished Name of the user's entry in the Oracle Internet Directory remains unchanged even when the value of the nickname attribute changes.

6.2.2.2 Configuring the Portal Administrator for Single Sign-On Administration

In previous releases of OracleAS Portal, the super user, PORTAL, was able to perform OracleAS Single Sign-On administration. With OracleAS Portal Release 9.0.4, the ability to perform OracleAS Single Sign-On administration out of the box is removed. The rationale for this change is that in enterprise settings it is not necessarily appropriate for an OracleAS Portal administrator to have permissions to perform Oracle Internet Directory and OracleAS Single Sign-On administration. Much like the discussion in the previous section, regarding the roles of the centralized Oracle Identity Management Infrastructure administrator and the departmental OracleAS Portal administrator, it may be inappropriate for the OracleAS Portal administrator to have the permissions to perform OracleAS Single Sign-On administration.

If you need to allow the OracleAS Portal account to perform OracleAS Single Sign-On administration, you need to explicitly give the user the privilege.

6.3 Configuring OracleAS Portal Security

This section describes configuration considerations for OracleAS Portal.

6.3.1 Configuring OracleAS Portal Security Options

This section contains the following subsections:

6.3.1.1 Changing Settings on the Global Settings Page

Once you have installed OracleAS Portal and performed the appropriate tasks from Section 6.3.2.3, "Post-Installation Security Checklist", you can change all of the following settings that pertain to security from the Global Settings page of OracleAS Portal:

6.3.1.1.1 Cache for Oracle Internet Directory Parameters

As pointed out in Section 6.1.6, "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 OID 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.1.1.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.1.1.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.1.1.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.1.2 Enforcing Role-Based Access Control

From OracleAS Portal 10g Release 2 (10.1.2) onwards, it is possible to enable or disable enforcement of Role-Based Access Control. This option is disabled in the default configuration. Role-Based Access Control can prevent the assignment of both object level privileges and global privileges directly to users from the OracleAS Portal User Interface and forces them to be granted only to groups. However, this option does not have any impact on the privileges granted directly to users:

  • Before Role-based Access Control was enabled

  • Automatically when an object is created

  • Through the use of the OracleAS Portal APIs

To enable or disable Role-based Access Control, you must run the script secrlacl.sql located in the directory ORACLE_HOME/portal/admin/plsql/wwc. The syntax for secrlacl.sql is:

@secrlacl.sql Y|N

For example, if you want to enable Role-based Access Control, run the script as follows:

@secrlacl.sql Y

Once Role-based Access Control is enabled, you will see the following changes in OracleAS Portal:

  • Access Tab for Objects. Here you will see only the Group LOV; the User LOV does not appear.

  • The Privilege tab is not rendered on the Edit User Profile page.

6.3.1.3 Configuring Provider Message Authentication

Additional configuration is required to set up a provider service that expects HMAC-enabled communication. You can set up basic or enhanced authentication.

6.3.1.3.1 Basic Authentication

If your JPDK provider code is accepting the portal user's identity through the oracle.portal.provider.v2.ProviderUser from the oracle.portal.provider.v2.render.PortletRenderRequest object, and using this identity for any sensitive operations, you should configure the portal and this provider for basic message authentication. Basic message authentication utilizes a Hashed Message Authentication Code (HMAC), which is a mechanism for message authentication using cryptographic hash functions, to ensure the integrity of the message.

To configure basic authentication using HMAC, you need to configure both the JPDK Web provider and OracleAS Portal as follows:

JPDK Web Provider

For the JPDK Web provider, add a shared key as a Web provider JNDI environment variable to the web.xml file. The exact position of environment entries in web.xml is toward the end, as shown in bold in Table 6-17, which shows the relative order of the elements in web.xml.

Table 6-17 Relative Order of the Elements In web.xml

Element Name

icon?

display-name?

description?

distributable?

context-param*

filter*

filter-mapping*

listener*

servlet*

servlet-mapping*

session-config?

mime-mapping*

welcome-file-list?

error-page*

taglib*

resource-env-ref*

resource-ref*

security-constraint*

login-config?

security-role*

env-entry*

ejb-ref*

ejb-local-ref*


Add a JNDI environment variable definition to the web.xml file, by adding the following env-entry element in the appropriate location:

<env-entry>
   <env-entry-name>oracle/portal/provider/service_name/sharedKey</env-entry-name>
   <env-entry-value>shared_key_value</env-entry-value>
   <env-entry-type>java.lang.String</env-entry-type>
</env-entry>

Enter the service name and the shared key value, as shown in Example 6-1.

Example 6-1 Adding a JNDI Environment Variable Definition to web.xml

<env-entry>
   <env-entry-name>oracle/portal/provider/sample/sharedKey</env-entry-name>
   <env-entry-value>1234567890abcdeFGHIJ</env-entry-value>
   <env-entry-type>java.lang.String</env-entry-type>
</env-entry>

In this example, sample is the service name for the provider and 1234567890abcdeFGHIJ is the shared key value. The value of the shared secret key used for the HMAC computation must contain between 10 and 20 alphanumeric characters.

You must define this environment variable for each provider instance that you want to secure, as shown in Example 6-2.

Example 6-2 Defining JNDI Environment Variables for Multiple Provider Instances in web.xml

<env-entry>
   <env-entry-name>oracle/portal/provider/provider0/sharedKey</env-entry-name>
   <env-entry-value>1234567890abcdeFGHIJ</env-entry-value>
   <env-entry-type>java.lang.String</env-entry-type>
</env-entry>

<env-entry>
   <env-entry-name>oracle/portal/provider/provider1/sharedKey</env-entry-name>
   <env-entry-value>0987654321abcdeFGHIJ</env-entry-value>
   <env-entry-type>java.lang.String</env-entry-type>
</env-entry>

<env-entry>
   <env-entry-name>oracle/portal/provider/provider2/sharedKey</env-entry-name>
   <env-entry-value>123123123123</env-entry-value>
   <env-entry-type>java.lang.String</env-entry-type>
</env-entry>

Alternatively, you can add the provider property sharedKey in the .properties file. To do this, perform the following steps:

  1. Open the file <app_root>/WEB-INF/deployment/service_name.properties. (Substitute service_name with the name of your provider service instance.)

  2. Add the provider property sharedKey and the value for your shared key, as shown in the following example:

    sharedKey=1234567890abcdeFGHIJ
    
    

    You must set this property in each of the service_name.properties files for each provider instance that you want to secure.


Note:

The disadvantage of this alternate approach is that you cannot manage the environment variables for the provider using Application Server Control Console, as you would with JNDI environment entries.

OracleAS Portal

In OracleAS Portal, register the provider with the shared key and login frequency settings, as follows:

  1. In the Portal Builder, click the Administer tab, then click the Portlets subtab.

  2. In the Remote Providers portlet, click Register a Provider.

  3. In the Register a Provider page, enter the provider details, and click Next.

  4. In the General Properties section, for Shared Key, enter the value of the secret key.

  5. In the User/Session Information section, for Login Frequency, select Once Per User Session.

  6. Follow the instructions in the wizard and click Finish.

6.3.1.3.2 Enhanced Authentication

If your JPDK Web provider code is running in an OC4J container configured for JAZN-LDAP, and the provider code uses J2EE security or obtains the user's identity through the getRemoteUser() or getUserPrincipal() methods of the HttpServletRequest object, you should configure the portal and this provider for enhanced message authentication. You should also configure enhanced message authentication if you are using the LDAP (Oracle Internet Directory) Security features in your provider, as documented in the Oracle Application Server Portal Developer's Guide. Enhanced message authentication secures the integrity of the additional headers that are used to propagate the user's authenticated identity to the provider.


Note:

Enhanced authentication is a new feature in OracleAS Portal 10g Release 2 (10.1.4).

To configure enhanced authentication using HMAC, you need to configure both the JPDK Web provider and OracleAS Portal.

JPDK Web Provider

To configure the JPDK Web provider, perform the following steps:

  1. For the JPDK Web provider, add a shared key as a Web provider JNDI environment variable to the web.xml file. The exact position of environment entries in web.xml is toward the end, as shown in Table 6-17, which shows the relative order of the elements in web.xml.

    Add a JNDI environment variable definition to the web.xml file, by adding the following env-entry element in the appropriate location:

    <env-entry>
       <env-entry-name>oracle/portal/provider/service_name/sharedKey</env-entry-name>
       <env-entry-value>shared_key_value</env-entry-value>
       <env-entry-type>java.lang.String</env-entry-type>
    </env-entry>
    
    

    Enter the service name and the shared key value, as shown in Example 6-1.

    In Example 6-1, sample is the service name for the provider and 1234567890abcdeFGHIJ is the shared key value. The value of the shared secret key used for the HMAC computation must contain between 10 and 20 alphanumeric characters.

    You must define this environment variable for each provider instance that you want to secure, as shown in Example 6-2.

    Alternatively, you can add the provider property sharedKey in the .properties file. To do this, perform the following steps:

    1. Open the file <app_root>/WEB-INF/deployment/service_name.properties. (Substitute service_name with the name of your provider service instance.)

    2. Add the provider property sharedKey and the value for your shared key, as shown in the following example:

      sharedKey=1234567890abcdeFGHIJ
      
      

      You must set this property in each of the service_name.properties files for each provider instance that you want to secure.


    Note:

    The disadvantage of this alternate approach is that you cannot manage the environment variables for the provider using Application Server Control Console, as you would with JNDI environment entries.

  2. Add the provider property enhancedAuthentication in the .properties file. To do this, perform the following steps:

    1. Open the file <app_root>/WEB-INF/deployment/service_name.properties. (Substitute service_name with the name of your provider service instance.)

    2. Add the provider property enhancedAuthentication and set it to true, as shown in the following example:

      enhancedAuthentication=true
      
      

      You must set this property in each of the service_name.properties files for each provider instance that you want to secure.

OracleAS Portal

In OracleAS Portal, register the provider with the shared key and login frequency settings, as follows:

  1. In the Portal Builder, click the Administer tab, then click the Portlets subtab.

  2. In the Remote Providers portlet, click Register a Provider.

  3. In the Register a Provider page, enter the provider details, and click Next.

  4. In the General Properties section, for Shared Key, enter the value of the secret key.

  5. In the User/Session Information section, for Login Frequency, select Once Per User Session.

  6. Follow the instructions in the wizard and click Finish.

6.3.2 Configuring Options for OracleAS Security Framework

When configuring OracleAS Portal, you should consider the following options that leverage the OracleAS Security Framework:

6.3.2.1 Configuring SSL for OracleAS Portal

The sections that follow provide an overview of the most common SSL configurations for OracleAS Portal and describe the procedures necessary to implement them.

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


Notes:

  • The SSL Configuration Tool is available with any Oracle Application Server installation type. OracleAS Infrastructure installations are the only installation type that support SSL configuration during the installation. This option is available on one of the installation screens.

  • If you install Oracle Application Server and choose to make some configuration changes before running the SSL Configuration Tool, you should run the tool and then refer to the SSL Configuration Tool log files to verify that your changes were not overwritten. The SSL Configuration Tool creates log files in the directory from which the tool is run. A new log file is created each time the tool is run. For these reasons, it is suggested that you create a separate directory from which you can run the SSL Configuration Tool.


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

Table 6-18 SSL Configuration Tool Command Line Options

Parameter Description

-config_w_prompt

Run in interactive mode.

-config_w_file <input_file_name>

Run in silent mode using the values specified in the <input_file_name> file. This input file should be an XML file. See the Oracle Application Server Administrator's Guide for more information.

-config_w_default

Run in silent mode using the values specified in the portlist.ini and ias.properties files.

-rollback

Revert to the previous state before the command was last run. SSO registration will be done using virtual host and port.

-dry_run

Print the steps without implementing them.

-wc_for_infra

Forces an OracleAS Web Cache to be used as a load balancer for an infrastructure environment.

-secure_admin

Secure the OracleAS Web Cache and Enterprise Manager administration ports (the ports used to display Application Server Control Console).

-opwd <orcladmin_pwd>

Set the Oracle administrator password. This parameter is required.

-ptl_dad <dad-name>

Set the OracleAS Portal DAD name. If no name is specified, the default "portal" will be used.

-ptl_inv_pwd <ptl_inv_pwd>

Set the Portal invalidation password used to send invalidation to OracleAS Web Cache.

If you are running SSLConfigTool with the -rollback parameter, this parameter is not required.


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

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

To configure SSL to OracleAS Single Sign-On using SSLConfigTool, perform the following steps:

  1. Run the SSLConfigTool script on the Oracle Application Server Infrastructure.

    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.


      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 the Oracle Application Server Single Sign-On Administrator's Guide.

  2. Create a wallet. See "Creating an Empty Wallet (HTTPS)" for more information.

  3. Check if the issuer of the OracleAS Single Sign-On certificate is listed in the Trusted Certificates list. If not, you must add the Trusted Root Certificate to the Wallet, as shown in "Adding the Trusted Root Certificate to the Wallet (HTTPS)".

  4. Update wallet path and password in iasconfig.xml. See "Updating Wallet Path and Password in iasconfig.xml (HTTPS)" for more information.

  5. Run the SSLConfigTool script on the Oracle Application Server middle tier, 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.

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

    Choose No when prompted to configure HTTPS.

  6. Verify the wallet path and the OracleAS Single Sign-On Query Path URL. See "Verifying the Wallet Path and the OracleAS Single Sign-On Query Path URL (HTTP and HTTPS)" for more information.

  7. The orcldasurlbase attribute in the cn=OperationURLs, cn=DAS, cn=Products, cn=OracleContext entry may need to be updated in Oracle Internet Directory. If it is not set to use the HTTPS port, you must refresh the cache for the Oracle Internet Directory parameters: To do this, perform the following steps:

    1. Using 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. Check if the orcldasurlbase entry reflects the HTTPS port being used on the infrastructure tier, that is, https://<infrahost>:<port>/.

    If the orcldasurlbase entry does not reflect the HTTPS port, change it in Oracle Internet Directory and force a refresh of the portal cache, which holds the relevant Oracle Internet Directory information. To refresh the portal cache, perform the following steps:

    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. Select Refresh Cache for OID Parameters.

    7. Click Apply.

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

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.


Note:

In the previously described configuration of SSL, you must re-register the OracleAS Single Sign-On middle-tier partner application. As 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.


After enabling SSL on OracleAS Single Sign-On following the steps listed in the Oracle Application Server Single Sign-On Administrator's Guide. In this release of OracleAS Portal, you have the option of configuring portal to access the OracleAS Single Sign-On URLs over HTTP or HTTPS. The steps that follow indicate which steps are needed for each configuration:

Creating an Empty Wallet (HTTPS)

Perform the steps in this section only if you plan to use an HTTPS port on OracleAS Single Sign-On, after configuring OracleAS Single Sign-On to use SSL.

Create an empty wallet to establish the trust points for SSL access to the OracleAS Single Sign-On. To do this, perform the following steps:

  1. Open the Oracle Wallet Manager on the INFRA_ORACLE_HOME. Note that you can run Oracle Wallet Manager from any location, as long as the generated wallet is accessible from the portal schema in the OracleAS Metadata Repository. You can also save the wallet (the directory containing the wallet files) anywhere and move it to another location that is accessible from the portal schema in the OracleAS Metadata Repository.

  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. Enter the same password in the Confirm Password field.

  5. Select Standard for Wallet Type.

  6. Click OK.

  7. Click No when asked to create a certificate request.

  8. Check if the issuer of the OracleAS Single Sign-On certificate is listed in the Trusted Certificates list. If not, you must add the Trusted Root Certificate to the Wallet, as shown in "Adding the Trusted Root Certificate to the Wallet (HTTPS)".

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

    INFRA_ORACLE_HOME\wallets
    
    
  10. Choose Wallet > Save.

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

Adding the Trusted Root Certificate to the Wallet (HTTPS)

Perform the steps in this section only if you do not have the trusted root certificate of the OracleAS Single Sign-On server's issuing certificate authority listed in the Trusted Certificates list. In this case, you must add the Trusted Root Certificate to the Wallet as shown in the following steps, which are based on the Internet Explorer browser:

  1. Using the browser, go to the OracleAS Single Sign-On home page, https://infra.domain.com/pls/orasso. Ensure that this is on an HTTPS URL.

    1. If the certificate on the server is not automatically trusted by your browser, the Security Alert dialog box is shown.

    2. Click View Certificate.

    3. Click the Certification Path tab.

    4. Select the Certificate Authority Root, which is the first certificate in the list.

    5. Click View Certificate.

    6. Click Install Certificate.

      This brings up the Certificate Import Wizard. This will import the certificate into the browser's list of trusted certificate authorities.

    7. Click Next.

    8. Select Automatically select a certificate store based on the type of certificate.

    9. Click Next.

    10. Click Finish.

      The trusted root certificate is installed in your browser.

  2. Click the lock icon in the status bar to bring up the Certificate dialog box.

  3. Click the Certification Path tab.

  4. Select the Certificate Authority Root, which is the first certificate in the list.

  5. Click View Certificate.

  6. Click the Details tab.

  7. Click Copy to File....

    This brings up the Certificate Export Wizard.

  8. Click Next.

  9. Under Select the format you want to use, select Base-64 encoded X.509 (.CER).

  10. Click Next and specify a file name for the certificate. You can provide any filename for the certificate with a .cer extension.

  11. Click Next and then Finish.

At this point, a .cer certificate file is created, which contains the trusted certificate authority's root certificate. This certificate must be added to the Wallet's list of Trusted Certificates. To accomplish this, assuming that the wallet manager is already running and the empty wallet has been opened, perform the following steps:

  1. Right-click the Trusted Certificates node.

  2. Select Import Trusted Certificate....

  3. Select Paste the certificate, and click OK.

  4. Copy the contents of the certificate file you created earlier into the text area for the BASE64 format certificate, and then click OK.

  5. Verify that the Certificate Authority Root has been added to the list of trusted certificates.

  6. Save the wallet.

Updating Wallet Path and Password in iasconfig.xml (HTTPS)

Perform the steps in this section only if you plan to use an HTTPS port on OracleAS Single Sign-On, after configuring OracleAS Single Sign-On to use SSL.

To update the wallet path and password in the iasconfig.xml file, perform the following tasks:

  1. Open the iasconfig.xml file, which is available in the following directory:

    MID_TIER_ORACLE_HOME/portal/conf
    
    
  2. Update the wallet path and password as shown in the following example:

    <IASConfig XSDVersion="1.0">
        <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"
        WalletPath="file:/export/home/oracle/wallets"
        WalletPassword="welcome">
           <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>
    

    Note:

    While performing the next task, which is, reregistering OracleAS Portal partner applications, the wallet password in the iasconfig.xml gets encrypted, and the portal schema in the OracleAS Metadata Repository gets updated with the changes made in the iasconfig.xml file.

Setting the OracleAS Single Sign-On Query Path URL (HTTP)

Perform the steps in this section only if you plan to use an HTTP port on OracleAS Single Sign-On to support these interfaces, after configuring OracleAS Single Sign-On to use SSL.

OracleAS Portal maintains the URL prefix of OracleAS Single Sign-On, which accesses certain information through calls from the database using the UTL_HTTP package. These calls can be made using HTTP or HTTPS. As a result, even if OracleAS Portal and OracleAS Single Sign-On are configured to use HTTPS, you can still use 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 personalization 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. Open the iasconfig.xml file, which is available in the following directory:

    MID_TIER_ORACLE_HOME/portal/conf
    
    
  2. Add or update the SSOQueryPath value as shown in the following example:

    <IASConfig XSDVersion="1.0">
        <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"
        SSOQueryPath="http://infra.abc.com:7777/pls/orasso/">
           <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>
    

Re-Registering the OracleAS Portal Partner Application (HTTP and HTTPS)

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) in the following modes:

  1. Encrypt any plain text passwords in the iasconfig.xml configuration file. To do this, navigate to MID_TIER_ORACLE_HOME/portal/conf, and run the following command:

    ptlconfig -encrypt
    
    

    Note:

    To use ptlconfig, the ORACLE_HOME environment variable must be set.

  2. Register the URL changes with OracleAS Portal. To do this, navigate to MID_TIER_ORACLE_HOME/portal/conf, and run the following command:

    ptlconfig -dad <portal_dadname> -site
    
    

    For example,

    ptlconfig -dad portal -site
    
    

Note:

If you have multiple virtual hosts configured in OracleAS Portal, you will need to re-register each of the virtual hostnames individually using the command ptlconfig -dad portal -sso -host <portal_host> -port <port> [-ssl], specifying the host and port, for each virtual hostname. Refer to Section A.1, "Portal Dependency Settings Tool" for more information on using ptlconfig.

Verifying the Wallet Path and the OracleAS Single Sign-On Query Path URL (HTTP and HTTPS)

OracleAS Portal maintains the URL prefix of OracleAS Single Sign-On, which accesses certain information through calls from the database using the UTL_HTTP package. 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 verify the wallet path and OracleAS Single Sign-On Query Path URL, perform the following steps:

  1. Log in 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. The SSO Server Settings section should have the appropriate values.

Conditionally Updating the Oracle Delegated Administration Services URL Base Entry in Oracle Internet Directory (HTTP and HTTPS)

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. Select Refresh Cache for OID 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 (HTTP and HTTPS)

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

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. Perform the steps described in "Configuring SSL to OracleAS Single Sign-On Using SSLConfigTool" to enable OracleAS Single Sign-On for SSL.

  2. Create a wallet. Refer to "Creating a Wallet" for details.

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

    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.

  4. Configure and register Web providers or Provider groups. See "Configuring and Registering Web Providers or Provider Groups Exposed over SSL" for details.

  5. Configure and register WSRP producers exposed over SSL. See "Configuring and Registering WSRP Producers Exposed Over SSL" for details.

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

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

  8. 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 the 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:

Enabling OracleAS Single Sign-On for SSL

Perform the steps described in "Configuring SSL to OracleAS Single Sign-On Manually" to enable OracleAS Single Sign-On for SSL.

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


Note:

When you enabled OracleAS Single Sign-On for SSL, you had to create an empty wallet. For this procedure, Oracle recommends that you create a new wallet.

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-19 shows some sample values for the various fields in the Certificate Request dialog.

    Table 6-19 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.


Note:

If you are using a trial Root Certificate or have chosen a CA which is not currently installed in the Oracle Wallet Manager, you must first import the CA's Trusted Certificate before importing your server-specific User Certificate.

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. Choose Wallet > Save.

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

Securing OracleAS Web Cache

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


Note:

Changing OracleAS Web Cache settings (for example, Listening Port) can change the OracleAS Portal URL. If you do this, mobile settings need to be updated manually. See Section C.8, "Using the cfgiasw Script to Configure Mobile Settings" for more information.

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:

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-21, "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:


  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
    
    

Configuring and Registering Web Providers or Provider Groups Exposed over SSL

See "Configuring and Registering Web Providers or Provider Groups Exposed Over SSL" for details.

Configuring and Registering WSRP Producers Exposed Over SSL

See "Configuring and Registering WSRP Producers Exposed Over SSL" for details.

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 Containers for J2EE (OC4J) JVM's trust store on the middle-tier and infrastructure instances.

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 on the middle-tier and infrastructure instances:

  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
    
    

    Note:

    Use any arbitrary value for -alias, but ensure that it is unique for each certificate.

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


Note:

The preceding steps also need to be performed on the OracleAS Infrastructure containing the Oracle Ultra Search crawler.

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.4.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  follows
Description of "Figure 6-18 Secured Connections Throughout the System"


Note:

If you have already followed the steps described in Section 6.3.2.1.3, "SSL to OracleAS Web Cache", you must revert all the changes you have made before configuring SSL throughout OracleAS Portal.

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

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. Perform the steps described in "Configuring SSL to OracleAS Single Sign-On Using SSLConfigTool" to enable OracleAS Single Sign-On for SSL.

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

  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.

    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.

  4. Configure and register Web providers or Provider groups. See "Configuring and Registering Web Providers or Provider Groups Exposed Over SSL" for details.

  5. Configure and register WSRP producers exposed over SSL. See "Configuring and Registering WSRP Producers Exposed Over SSL" for details.

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

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

  8. Re-register OracleAS Portal as an Oracle Ultra Search content source, and specify the SSL URL of OracleAS Portal. See "Re-Registering OracleAS Portal as an Oracle Ultra Search Content Source" for details.

  9. Register the Ultra Search provider with OracleAS Portal. See "Registering the Ultra Search Provider with OracleAS Portal" for details.

Configuring SSL Throughout OracleAS Portal Manually

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

Enabling OracleAS Single Sign-On for SSL

Perform the steps described in "Configuring SSL to OracleAS Single Sign-On Manually" to enable OracleAS Single Sign-On for SSL.

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.

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


Note:

Changing OracleAS Web Cache settings (for example, Listening Port) can change the OracleAS Portal URL. If you do this, mobile settings need to be updated manually. See Section C.8, "Using the cfgiasw Script to Configure Mobile Settings" for more information.

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:

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-21 of the original page.

    Table 6-21 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.


Note:

After you have performed all the steps to secure OracleAS Web Cache, you must restart the OracleAS Web Cache server using the OracleAS Web Cache Manager for the changes to take effect.

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

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

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
    
    

Configuring and Registering Web Providers or Provider Groups Exposed over SSL

Refer to "Configuring and Registering Web Providers or Provider Groups Exposed Over SSL" for details.

Configuring and Registering WSRP Producers Exposed Over SSL

Refer to "Configuring and Registering WSRP Producers 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 SSL throughout OracleAS Portal, you must re-register OracleAS Portal as a content source with Oracle Ultra Search. Make sure that you specify the SSL URL for OracleAS Portal. See Section 8.2.4.2, "Registering OracleAS Portal as a Content Source" for details.

Registering the Ultra Search Provider with OracleAS Portal

To access the Oracle Ultra Search portlet, you must register the Ultra Search provider with OracleAS Portal. Make sure that you specify the SSL URL during registration. See Section 8.2.4.3, "Registering the Ultra Search Provider with OracleAS Portal" 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  follows
Description of "Figure 6-19 External SSL Only"


Note:

In a typical configuration, w1.abc.com and m1.abc.com would reside on the same computer, but for illustration purposes, they are separated here.

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 OracleAS Portal with external SSL:

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

  3. Enabling Access for Oracle Ultra Search

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 the 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-3:

Example 6-3 Example Configuration File

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

    9. Click OK to commit the change.

    10. Repeat steps d through h 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
        
        
  3. 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 Apply.

    9. Click OK to commit the change.

    10. Repeat steps d through h 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

However, if you want to create a new Web provider or provider group in the Providers tab in the Portal Navigator, you must first follow the steps described in the subsection "Configuring and Registering Web Providers or Provider Groups Exposed over SSL" in Section 6.3.2.1.4, "SSL Throughout OracleAS Portal".


Note:

If your infrastructure is located on a separate computer than your OracleAS Portal middle tier, you need to add the following to your /etc/host file:

w1.w1.w1.w1 lbr.abc.com

where w1.w1.w1.w1 is the IP Address of your LBR or reverse proxy server.


Enabling Access for Oracle Ultra Search

Refer to Enabling Access for Oracle Ultra Search for details.

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

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

    Example 6-4 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.11, "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.

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 Containers for J2EE (OC4J) JVM's trust store on the infrastructure instance.

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 on the infrastructure instance:

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

  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
    
    

    Note:

    Use any arbitrary value for -alias, but ensure that it is unique for each certificate.

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


Note:

The preceding steps also need to be performed on the OracleAS Infrastructure containing the Oracle Ultra Search crawler.

6.3.2.1.6 Configuring and Registering Web Providers, Provider Groups, and WSRP Producers Exposed Over SSL

This section describes how you can configure OracleAS Portal to provide access to Web providers, Provider groups, and WSRP producers exposed over SSL. This section contains the following topics:

Configuring and 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 configure Web providers or provider groups exposed over SSL, 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
    

    Note:

    Use any arbitrary value for -alias, but ensure that it is unique for each certificate.

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


Note:

If your portal schema is located in an OracleAS RepCA database and if the release of that Oracle Database is earlier than 10g (10.1.0.x), then these steps do not need to be performed.

Configuring and Registering WSRP Producers Exposed Over SSL

To configure WSRP producers exposed over SSL, perform the following steps:

  1. In a Web browser, enter the WSDL URL of your WSRP producer to ensure that it is working. If the WSDL definition does not appear in the browser, then the deployment of your WAR file must have failed. Refer to the section on diagnosing Java portlet problems in the Oracle Application Server Portal Developer's Guide.

  2. Modify your WSDL file and make it available over HTTP. To do this, perform the following steps:


    Note:

    The following steps are for a setup where the WSRP ports are generated with the HTTP protocol because HTTP was used for requesting the WSDL URL. However, if you are accessing WSDL using HTTP and the internal URLs are referenced using HTTPS, then you can skip Step 2.

    1. In a Web browser, enter the HTTPS WSDL URL. For example:

      https://host:port/context-root/portlets?WSDL
      
      

      Each port in the WSDL definition should be displayed with an HTTPS location. For example:

      <wsdl:port binding="bind:WSRP_v1_Markup_Binding_SOAP" name="WSRPBaseService">
      <soap:address location="https://host:port/context-root/portlets/WSRPBaseService"/>
      </wsdl:port>
      
      
    2. Save a copy of the WSDL definition to a file on your application server in a location where it can be accessed externally over HTTP. For example, the ORACLE_HOME/Apache/Apache/htdocs/ directory of your Oracle Application Server middle tier installation. When you register the producer in OracleAS Portal, use the location of this WSDL for your WSDL URL on the Define Connection page of the registration. The format of a WSDL URL is as follows:

      http://<host>:<port>/<Savedxml.xml>?WSDL
      
      
    3. If the ports are not listed with HTTPS locations, then you must change them manually before proceeding. You can do this by saving the XML to a file from the browser and opening it in a text editor.

  3. To register a WSRP producer, which is exposed over SSL, you must have a copy of the root certificate of the certificate authority used by the WSRP producer. Check if the root certificate exists in the set of trusted certificates recognized by the Oracle Database hosting the OracleAS Metadata Repository containing the OracleAS Portal schema. To check if a root certificate already exists, register a sample JPDK provider using an SSL-enabled URL. Access the home page of the SSL-enabled portal. If a certificate security alert dialog box appears, then skip Step 4.

  4. If the WSRP producer is using an unknown or uncommon certificate authority, then you need to add the appropriate root certificate (using Base-64 encoded X.509 format) to the set of trusted certificates. To add a root certificate of the certificate authority used by the WSRP producer to the truststore, 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
      
      

      Notes:


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

    5. (Optional) If you want the PPE to trust only specific certificates, then add x509certfile in an additional <init-param> block in the file, MID_TIER_ORACLE_HOME\j2ee\home\applications\portletapp\wsrp-samples\WEB-INF\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>
      
      

      The contents of a typical trustedCerts.txt file would look as shown in Example 6-5.

      Example 6-5 Sample File Containing a List of Certificates

      -----BEGIN CERTIFICATE-----
      MIICPDCCAaUCEDJQM89Q0VbzXIGtZVxPyCUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMx
      FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
      IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2MDEyOTAwMDAwMFoXDTIwMDEwNzIzNTk1OVow
      XzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAx
      IFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUA
      A4GNADCBiQKBgQDlGb9to1ZhLZlIcfZn3rmN67eehoAKkQ76OCWvRoiC5XOooJskXQ0fzGVuDLDQ
      VoQYh5oGmxChc9+0WDlrbsH2FdWoqD+qEgaNMax/sDTXjzRniAnNFBHiTkVWaR94AoDa3EeRKbs2
      yWNcxeDXLYd7obcysHswuiovMaruo2fa2wIDAQABMA0GCSqGSIb3DQEBAgUAA4GBAEtEZmBoZOSY
      G/OwcuaViXzde7OVwB0u2NgZ0C00PcZQmhCGjKo/O6gE/DdSlcPZydvN8oYGxLEb8IKIMEKOF1Ac
      ZHq4PplJdJf8rAJD+5YMVgQlDHx8h50kp9jwMim1pN9dokzFFjKoQvZFprY2ueC/ZTaTwtLXa9ze
      WdaiNfhF
      -----END CERTIFICATE-----
      
      -----BEGIN CERTIFICATE-----
      MIICPTCCAaYCEQC6WslMBTuS1qe2307QU5INMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVT
      MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMgUHJpbWFy
      eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0wNDAxMDcyMzU5NTla
      MF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3Mg
      MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEF
      AAOBjQAwgYkCgYEAtlqLow1qI4OAa885h/QhEzMGTCWi7VUSl8WngLn6g8EgoPovFQ18oWBrfnks
      +gYPOq72G2+x0v8vKFJfg31LxHq3+GYfgFT8t8KOWUoUV0bRmpO+QZEDuxWAk1zr58wIbD8+s0r8
      /0tsI9VQgiZEGY4jw3HqGSRHBJ51v8imAB8CAwEAATANBgkqhkiG9w0BAQIFAAOBgQC2AB+TV6QH
      p0DOZUA/VV7t7/pUSaUw1iF8YYfug5MLv7Qz8pisnwa/TqjOFIFMywROWMPPX+5815pvy0GKt3+B
      uP+EYcYnQ2UdDOyxAArdG6S7x3ggKLKi3TaVLuFUT79guXdoEZkj6OpS6KoATmdOu5C1RZtG644W
      78QzWzM91Q==
      -----END CERTIFICATE-----
      
      

      Note:

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

    6. Restart your Oracle Application Server instance:

      MID_TIER_ORACLE_HOME/opmn/bin/opmnctl stopall
      MID_TIER_ORACLE_HOME/opmn/bin/opmnctl startall
      
      
    7. Register the WSRP producer, by specifying the WSDL defined at the location determined in Step 2. The URL used here must be HTTP based, and not HTTPS. For example:

      http://><host>:<port>/myProducerWsdl.xml
      
      

6.3.2.2 Securing the Connection to Oracle Internet Directory (Optional)

In Section 6.3.2.1, "Configuring SSL for OracleAS Portal", we were mainly concerned with the HTTP-based network hops. However, you can also secure the network connection to the Oracle Internet Directory itself, which is LDAP-based communication. In this case the Oracle Internet Directory should be configured to use LDAP over SSL (LDAPS). You can find further information about configuring the Oracle Internet Directory for LDAPS in the Oracle Internet Directory Administrator's Guide.

Once Oracle Internet Directory is configured to use SSL, you must update the OracleAS Portal schema to use the new port on the LDAP server. To perform this step, you run the SQL script, secupoid.sql, located in MID_TIER_ORACLE_HOME/portal/admin/plsql/wwc. This script allows for the setting of the following Oracle Internet Directory related parameters:

  • Directory Host Name

  • Directory Port

  • Application Directory Password

  • SSL Settings

When you run the script, it displays the current settings and gives you the ability to change them accordingly. In this case, you want to set the following:

use_ssl_to_connect_to_ldap=Y 

The script will then give you the option of automatically refreshing OracleAS Portal's Oracle Internet Directory cache. Refer to Section C.3, "Using the secupoid.sql Script" for more information.


Note:

From 10g Release 2 (10.1.2) onwards, you can optionally install OracleAS Portal using LDAPS rather than having to implement it after installation.

6.3.2.3 Post-Installation Security Checklist

After OracleAS Portal is installed, you should consider performing the following steps to complete the security configuration:

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

  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.3.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.3.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.3.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.3.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.3.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 the Oracle Application Server mod_plsql User's Guide.

6.3.2.3.7 Consider SSL

If your portal contains confidential information, you should consider configuring it with SSL. See Section 6.3.2.1, "Configuring SSL for OracleAS Portal" for the available SSL configuration options.

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


See Also:

Section 6.1.6.2.1, "Directory Entries in Oracle Internet Directory for OracleAS Portal", for more information about the application entity.

6.3.2.3.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 the Oracle Application Server Administrator's Guide.

6.3.3 Configuring OracleAS Portal Options for Database Security

Fine-grained access controls and secure application contexts add a new dimension to your ability to secure your data in the database.

Fine-grained access control is sometimes referred to as virtual private database or row level security. Fine-grained access control in the Oracle Database 10g is the ability to dynamically attach, at run time, a predicate (WHERE clause) to any and all queries issued against a database table or view. This feature gives you the ability to procedurally modify the query at run time. You may evaluate who is running the query, where they are running the query from, when they are running the query and develop a predicate given those circumstances. With the use of application contexts, you may securely add additional information to the environment (such as an application role the user may have) and access it in your procedure or predicate as well.

As an example of fine-grained access control, you might have a security policy that determines what rows different groups of people may see. Your security policy will develop a predicate based on who is logged in and what group they are in.

More on OTN

You will find additional information about fine-grained access and application contexts on Portal Center, http://portalcenter.oracle.com/.



Footnote Legend

Footnote 1: The default identity management realm name is determined by the domain name of the server on which the system is installed. For example, if the domain name server was oracle, the default identity management realm name would be dc=oracle,dc=com. If the domain name server cannot be determined, the default name assigned by the directory is dc=Default Company,dc=com