The script content on this page is for navigation purposes only and does not alter the content in any way.

7 Securing Oracle 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 Oracle Portal security in the following topics:

7.1.1 Oracle 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. Oracle 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 Oracle 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, Oracle Portal leverages the other components of Oracle Fusion Middleware and Oracle Database 11g to provide strong protection for your portal. Oracle 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.

Oracle Web Cache is the cache used to serve up pages generated by Oracle Portal (or proxied to the Oracle HTTP Server if not able to service the request). Based on invalidation caching, Oracle 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.

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

Oracle Portal Architecture

Figure 7-1 shows the components and relationships of the Oracle Portal security architecture.

The Oracle 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 Oracle 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 Oracle 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 Fusion Middleware. 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 Oracle Portal, generated pages are cached in Oracle Web Cache. If a request for a portal page can be served from Oracle Web Cache, it will be returned without accessing the Oracle 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 Oracle 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 Oracle Portal schema in the Oracle 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 Oracle 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, Oracle 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.

7.1.2 Classes of Users and Their Privileges

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

7.1.2.1 Oracle Portal Default, Seeded User Accounts

Table 7-1 describes the user account created by default when Oracle Portal is installed.

Table 7-1 Default Oracle Portal User

User

Description

orcladmin

This account is granted the highest privileges in Oracle Portal. This account is created for the Oracle Fusion Middleware administrators, and uses the password that is supplied during the Oracle Fusion Middleware installation.

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

7.1.2.2 Oracle Portal Default, Seeded Groups

Table 7-2 describes the groups created by default when Oracle Portal is installed.

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 Fusion Middleware administrators. Components that are part of Oracle Fusion Middleware 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 Fusion Middleware privilege groups:

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

PORTAL_DEVELOPERS

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

By default, this group is given the following Oracle 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 7-6.

RW_ADMINISTRATOR

Is the group of users who administer Oracle 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 Oracle 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 Oracle 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 Oracle 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. FMWADMIN 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 Oracle 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 Oracle 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 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.)

7.1.2.3 Oracle Portal Default Schemas

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

Table 7-3 describes the schemas created by default when Oracle Portal is installed.

Table 7-3 Default Oracle Portal Schemas

Schema

Description

PORTAL

Contains the Oracle 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 7-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 Oracle 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. Procedures are granted to the PORTAL_PUBLIC schema specifically. They are no longer granted execute to PUBLIC.

In a standard Oracle 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.

7.1.3 Resources Protected

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

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

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

7.1.3.2 Object Privileges

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

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.

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

7.1.3.4 Privileges to Edit Web Providers and Provider Groups

To 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 Oracle Portal schema resident objects. Refer to Section 7.1.3.1, "Global Privileges" and Section 7.1.3.2, "Object Privileges" for information about the Oracle Portal schema resident objects. Rather, the grants for provider privileges are maintained in an XML file.

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

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.

7.1.3.4.1 Global Privileges

Table 7-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 7-8 Global Privilege Codes for provideruiacls.xml

Type of Object

Available Privileges

ANY_PROVIDER

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

400 (Edit): Can 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.

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:

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.

7.1.3.4.2 Object Level Privileges

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

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.

7.1.3.6 Privileges to Edit URL and XML Portlets in the Portlet Repository

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

7.1.4 Authorization and Access Enforcement

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

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

The login request is forwarded to mod_osso, which uses dynamic directives to integrate with the OracleAS Single Sign-On server for authentication.

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

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.

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

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

When the user attempts to access a page, Oracle Portal performs the following checks:

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

If the page is not public, Oracle 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, Oracle 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, Oracle 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.

7.1.5 Authorization Modification

In Oracle Portal 11g, a user's ability to view or edit a page, is based on the definition of an ACL policy, which references the page and the user (and/or any roles to which they belong). The user's privileges are defined by a “named” individual identity, rather than based on a specific business rule (such as from where the request originated). To allow for extensions to this security model, the Oracle Portal 11g includes the Authorization Modifier Package for extending the authorization routines. This package is executed prior to the standard ACL check, and enables additional rules to be evaluated before interrogating the ACL itself. If the Authorization Modifier succeeds (returns true) then the authorization check falls through to the default ACL based mechanism in order to determine if the user has the appropriate access rights. Conversely, if the Authorization Modifier denies access (returns false) the ACL is not even interrogated, and the behavior is to act as if the user did not have appropriate privileges for the operation, even if the ACL would have allowed it. By default, the installed Authorization Modification Package always returns true, and hence the functionality is effectively disabled. Thus the determination of access privileges is based solely on the evaluation of the security ACLs. To switch on the Authorization modifier it is necessary to replace the default package body with one that implements the desired business rule.

7.1.5.1 Secure Network Aware Authorization Modifiers

Oracle Portal is shipped with three predefined Modifier packages (see Table 7-11) which allow for the implementation of a Secure Network Aware Portal environment, this helps to implement security policies based not only on an ACL, but also on the origin of the Portal page request.

Table 7-11 Authorization Modifiers Packages

Script Files

Description

cfgamyes.pkb

The default ConFiGuration Authorization Modifier disables ALL page Editing or Customization functionality for requests which originate outside of the secured network

cfgampev.pkb

The ConFiGuration Authorization Modifier for Page Edit and View, allows for the securing of individual pages outside of the secured network. That is, the ability to prevent the viewing or editing of specific pages when the request originated from outside the secure network environment.

cfgamno.pkb

Returns the Authorization modifier to the default disabled state.

The Modifier packages are available in the ORACLE_HOME\upgrade\portal\admin\plsql\wwc directory.

To run the packages perform the following steps:

Using SQL*Plus, connect to the Oracle Portal schema as the owner.

Run the required package body script file to over-write the current Authorization Modifier installed.

7.1.5.2 Default Authorization Modifier

This implementation of the Authorization Modifier package uses the existence of the ORA_EXT_REQ CGI environment variable described above to recognize that the request has been received on a server that has been designated as publicly accessible, and hence should be considered outside of the Secure Network environment. Once compiled into the Authorization packages, any request from outside of the network which involves an Edit request is automatically disabled. That is, all customize and Edit links are removed from the page and direct edit URL references are disallowed.

7.1.5.3 Page View and Edit Authorization Modifier

This implementation includes:

7.1.5.3.1 Securing Specific Pages

The more specific Authorization Modifier (cfgampev) also uses the CGI variable to determine an external request. It however uses it in conjunction with defined page meta-data, in the form of a custom page attribute, to localize the desired inside/outside security to a subset of pages within the portal. Hence the ability to have externally available view and/or edit privileges on a specific page is determined on whether one or both named attributes are defined in the page in question.

7.1.5.3.2 Preventing External Viewing of a Specific Page

The ability to view a page externally is determined by the isViewRestricted named custom attribute. Once defined as part of the page description (through the use of a custom page template, the setting of this attribute will determine dynamically if the page is to be viewable, or not. That is, when set to On external viewing of the page is prevented, while a value of 'Off' (the default) indicates it is to be available externally. From the perspective of the end user, the activation of this rule has the effect of removing any links which reference the page as well as preventing any direct URLs to it (such as via a browser bookmark).

7.1.5.3.3 Preventing External Edits and Customization for a Specific Page

In a similar manner, the use of another named attribute isEditRestricted will dictate whether a specific page may be edited from outside of the secured network. This is different to the Default Modifier which globally turns off the ability to perform any editWhen the value of this attribute is set to 'On' the ability to edit/customize the page is revoked, while setting it to 'Off' indicates edits from “outside” are to be allowed. The effect of setting this this attribute is to not only remove the page level edit links, but also revoke the edit/customize capability of the Portlets embedded within the page. function on any page within the Portal.

7.1.5.4 Defining Required Page Attributes for use with Authorization Modifiers

While the attributes described above are not currently part of the standard page meta-data, the extensible page model allows us to add them in the form of “Custom Attributes” to our page definition. By the creation of a custom page type to be used as the basis of the inside/outside secureable pages it is a simple process to allow a page designer to define declaratively whether the page is to be internally secured or accessible both from with-in and with-out the secured network. The following section documents the steps required to create the appropriate page type used to secure a page via the Authorization Modifier functions described above.

Log in to the Oracle Portal.

From the Portal Builder page, select Navigator.

In the Portal Navigator page, under Page Groups Tab, select Shared Objects to define the Custom Attribute and Page Types. It is recommended that these properties are defined as Shared Objects rather than scoped to a specific Page Group, as it allows for their reuse across multiple Page Groups.

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 Oracle Portal through the Oracle Fusion Middleware Security Services.

J2EE Security

JPDK Web providers can leverage WLS 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.

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

7.1.7.1 Relationship Between Oracle Portal and OracleAS Single Sign-On

7.1.7.1.1 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 login for Oracle 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.

Note:

Single sign-on using the Basic authentication method (user name and password) is supported for external applications that users access using Firefox. However, single sign-on is not currently supported when using Internet Explorer 6.x or 7.x for external applications that use the Basic authentication method.

7.1.7.1.2 Support for Global Inactivity Timeout in Oracle Portal

A Global Inactivity Timeout can be configured for the OracleAS Single Sign-On Server. To use this feature, you must configure the OracleAS Single Sign-On Server on the infrastructure tier and mod_osso on the Oracle Fusion Middleware middle tier. See the Oracle Application Server Single Sign-On Administrator's Guide for more information on configuring this feature.

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

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

Oracle 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

Oracle 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 Fusion Middleware Administrator's Guide for Oracle Internet Directory. However, a few of Oracle Internet Directory features are not supported by Oracle Portal.

Table 7-12 lists and describes the Oracle Internet Directory features not supported in Oracle Portal.

In dynamic groups, membership is computed dynamically based on specific attribute values and assertions that you specify. Because of the inability to determine when to issue web cache invalidations for dynamic groups, pages that are secured with dynamic groups need to use expiry based caching or no caching.

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

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

Default user accounts(cn=PUBLIC, cn=orcladmin) are created in the identity management realm's user base (cn=Users,dc=MyCompany,dc=comFoot 1 ). By default, the orcladmin user is added to the DBA group during portal install and configuration. 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 containeris created within the identity management realm's group base (cn=Groups,dc=MyCompany,dc=com1). Oracle 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 Oracle Portal group container.

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

Oracle Portal schema name

Date and time when Oracle 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 Oracle Portal older than 10g Release 1.

Groupsare created within the Oracle 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. Oracle 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 Oracle 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 Oracle 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 Oracle 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 subscriptionA 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 Oracle Portal when user or group privilege information has changed. It enables Oracle 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 7-7 shows where the Oracle Portal information is located in the directory's DIT structure.

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.

7.1.7.2.2 User Attributes Stored in Oracle Internet Directory

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

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

7.1.7.2.5User and Group Lists of Values in Oracle 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 Oracle Portal group container in the Oracle 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 Oracle 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 Oracle Portal earlier than 10g Release 2 (10.1.2), and if your Infrastructure and Fusion Middleware 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.

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

If Oracle 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:

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

ORACLE_HOME\portal\admin\plsql\wwc

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

@secdaslc N
commit;

If Oracle Portal is used with an older release of Oracle Delegated Administration Services that does not support the callback method and the directory and Oracle 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.

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 Oracle 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 Oracle Portal. The Oracle Directory Integration Platform must notify Oracle 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 Oracle 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. Oracle 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 7-17 shows the events to which Oracle Portal subscribes and the actions it takes when those events occur.

Table 7-17 Directory Synchronized Events Handled By Oracle Portal

Subscribed event

Oracle 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 Oracle 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 if immediate synchronization is enabled on the Global Settings SSO/OID tab.

GROUP MODIFY

(uniqueMember, member)

The WWSEC_FLAT$ table is updated to reflect membership changes that affect Oracle Portal if immediate synchronization is enabled on the Global Settings SSO/OID tab.

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

Oracle 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 Oracle Portal. Similarly, a local group profile is created automatically when a new group is first referenced in an ACL.

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

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

7.1.7.3.1 Update Subscription Profiles for Groups Based on groupOfNames

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

To create or update the subscription profile, run oidprovtool as shown in the following example:

In addition to querying the directory for user and group information, Oracle 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. Oracle Portal provides links to the delegated administration server for users with the privileges to add and change users and groups.

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 Oracle Portal. To access these portlets, a user must be a member of the OracleDASCreateUser and OracleDASCreateGroup groups, respectively. AUTHENTICATED_USERS may create groups by default.

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

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

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 on WLS applications, for single sign-on. You achieve this by configuring mod_osso with Oracle HTTP Server directives to restrict access to the Oracle Fusion Middleware application URLs.

Oracle Delegated Administration Services is implemented as an WLS 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 Oracle 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, Oracle 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:

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

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

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

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

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

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

Note:

In releases before 9.0.4, roles were called public groups.

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 Oracle Portal privileges to them.

7.1.7.9.1 Example: Defining a User Administrator Role

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

Step 1: Create a group.

You begin by creating a group as follows:

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

Click Create New Group in the Group portlet and the Create Group page appears, as shown in Figure 7-15.

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.

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

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

Click Privileges tab.

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

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 Oracle 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 Oracle Portal administration page.

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

st.au.oracle.com,cn=IAS Infrastructure

Databases,cn=IAS,cn=Products,cn=OracleContext

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

Because the User Portlet is cached in Oracle Web Cache and the Oracle 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:

Log in to Oracle Portal as a user with administrator privileges.

Go to the Builder.

Click the Administration tab.

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

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 Oracle Portal administrative roles, or groups, are already pre-seeded into the Roles Assignment list on this page.

7.1.8 Configuring Dynamic Groups

Dynamic group support relies on the dynamically populated static group functionality. Dynamic groups in 11.1.1 are exposed in the same manner as static groups (in fact a dynamic group can be a composite of a static member list and a dynamically determined membership).

The dynamic membership of the group is defined through the setting of the group's labeledURI attribute with an appropriate LDAP query filter. The query filter defines the set of users that will define the membership of the group.

Note:

The labeledURI attribute is not exposed in the DAS console, so a dynamic group cannot be defined in DAS. The labeledURI attribute must be defined within Oracle Directory Manager, or by using an appropriate LDAP command, such as ldapmodify, from the command line.

7.1.8.1 Defining the Dynamic Group

You can create the dynamic group in two ways:

Create the dynamic group with an LDIF file and using the ldapadd command

Create the dynamic group using the Oracle Directory Services Manager (ODSM)

Option 1: Create Dynamic Group Using an LDIF file

To create the dynamic group using an LDIF file:

Create an LDIF file with a text editor. The following example shows how a dynamic group can be defined that represents all users under the default user search base, with the title of "Manager":

The labledURI syntax for an LDAP URL is defined in RFC 2255 (http://www.faqs.org/rfcs/rfc2255.html). In the example above, it is representing a search for any entry under the DN cn=users,dc=us,dc=mybiz,dc=com with the attribute title=Manager. This is to be done on the server myserver.mycompany.com at LDAP port 12061 and using a subtree ("sub") search.

A dynamic group can be defined on any attribute or condition that can be represented as an LDAP URL and defined in the labeledURI attribute. Dynamic groups can also be defined using the ConnectBy assertion, which is included in the orclDynamicGroup objectClass. Refer to the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory for more information for this alternate approach.

Save the file, and then update the OID server by issuing the ldapadd command. For example:

Provide the DN and add the objectclasses orclDynamicGroup and groupOfUniqueNames.

On the Mandatory Properties tab, provide the CN attribute.

On the Optional Properties tab, provide the attributes for labeleduri.

Click OK to complete the definition of the dynamic group.

When you refresh the tree view you'll see the new group that you created. Note that group members will not be shown in ODSM.

7.1.8.2 Using a Dynamic Group to Secure a Page

Once the dynamic group is defined, it can be used as a guarantee to secure pages in the Portal. Since updates to dynamic groups do not issue DIP change events, the Portal doesn't have any trigger to invalidate pages that may be affected by these dynamic groups. Therefore, pages using dynamic groups to secure them should either not be cached, or cached with expiry-based caching at the user level with a cache duration appropriate for the attribute being used to define the dynamic group.

7.1.9 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 Oracle Portal.

In Oracle Portal, portlets are managed by providers. A provider is an application that you register with Oracle Portal. Oracle 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 Oracle 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 Oracle Portal and the WSRP producers communicate through an inherently secure network, such as a VPN network or a network that is behind a firewall.

7.1.9.1 Authentication

When a user first logs in to Oracle 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 7.1.9.7, "Single Sign-On" for more information.

7.1.9.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 Oracle Portal, OracleAS Single Sign-On authenticates you. Once authenticated, Oracle 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, Oracle 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 7.3.1.3.2, "Enhanced Authentication" for more information on how to configure enhanced authentication.

7.1.9.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 Oracle Portal and fool the Web provider into returning sensitive information.

Communication security focuses on securing communications between Oracle 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.

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

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

7.1.9.3.3 Message encryption

Message encryption relies on the use of the HTTPS protocol for communication between the provider and Oracle 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 Oracle Portal and WSRP producers is not supported in this release.

7.1.9.4 Access Control Lists

When you log in to Oracle Portal, OracleAS Single Sign-On authenticates you. Oracle 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, Oracle 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.

7.1.9.4.1 Advantages

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

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

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

7.1.9.5.1 Advantages

This approach only allows trusted hosts to access the provider.

You can set the restrictions up easily.

7.1.9.5.2 Disadvantages

Oracle Web Cache does not have IP address checking capability. If you have Oracle Web Cache in front of a provider, a client on any host can send show requests to Oracle 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.

7.1.9.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 7.1.3.4, "Privileges to 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 MW_HOME\user_projects\domains\<DomainName>\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\kjdcke\war\WEB-INF directory, that the following param-value is set to true and not false:

7.1.9.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 Oracle Portal user. The application user and the Oracle Portal user are the same in this case.

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

7.1.9.7.1 Partner Application

A partner application shares the same OracleAS Single Sign-On as Oracle Portal for authentication. Sharing OracleAS Single Sign-On instances means that when a user is already logged into Oracle 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 Oracle Portal to authenticate the user on the provider's behalf. This relationship is possible because Oracle Portal is, itself, a partner application. Partner application providers must trust Oracle 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 Oracle 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.

Provides the tightest integration with Oracle 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 Oracle 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.

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

7.1.9.7.2 External Application

An External Application is an application that uses a different authentication mechanism than Oracle Portal. The application may use a different instance of OracleAS Single Sign-On than that used by Oracle 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 Oracle 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 Fusion Middleware 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.

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

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

7.1.9.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 Oracle Portal session, that is, the user logged in to Oracle 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 Oracle Portal session and does not have a persistent cookie to indicate that such a state previously existed.

Portlets can also access the Oracle 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

7.1.9.8.1 Advantages

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

7.1.9.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 Oracle Portal.

7.1.9.9 Message Authentication

The Oracle Fusion Middleware 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 Oracle 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 Oracle 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 Oracle 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 Oracle 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.

7.1.9.9.1 Advantages

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

7.1.9.9.2 Disadvantages

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

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

7.1.9.10 HTTPS Communication

Normal communication between Oracle 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 Oracle 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 Oracle 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.

7.1.9.11 Configuration of SSL

When a provider is registered from an Oracle 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 Oracle Portal instance and a provider.

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

7.1.9.11.2 Disadvantages

Encryption has a performance impact on Oracle Portal.

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

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

7.1.10.1 Setting Up the Keystores

The security credentials of the WSRP producer and Portal application can be retrieved and managed using a Java Keystore (JKS) or an Oracle Wallet. A keystore is a file that provides information about available public and private keys. Keys are used for a variety of purposes, including authentication and data integrity. User certificates and the trust points needed to validate the certificates of peers are also stored securely in the wallet or keystore. See the Oracle Fusion Middleware Security and Administrator's Guide for Web Services for information about keystores.

The consumer in the step-by-step procedures below is the Oracle Portal, which consumes portlets generated by the remote portlet producer over WSRP. The producer uses the public key of the consumer to verify the authenticity of the security tokens received from the consumer in the WS-Security headers of the requests it receives over its getMarkup interface. To do this, the producer needs a Java keystore that contains the certificate of the consumer and the root certificate used to sign it. These certificates are added to the Java keystore as trusted certificates.

This section describes how to create keystores and keys using a Java Keystore (JKS). JKS is the proprietary keystore format defined by Sun Microsystems. To create and manage the keys and certificates in the JKS, use the keytool utility that is distributed with the Java JDK 6.

Create Java keystores for the consumer and producer

To create Java keystores for the consumer, perform the following steps:

By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

Click Keystore tab.

The Default Keystore page is displayed.

In the Default Keystore page, enter the required information.

Click Apply.

Click OK.

Registering the WSRP Producer

To register the producer, do the following:

Click the Portlets subtab.

In the Remote Providers portlet, click Register a Provider to display the Register Provider page and enter the following information:

In the Name field, enter the name of the provider. This name must not be more than 200 characters or contain spaces or other special characters.

In the Display Name field, enter a name to display for the provider when it is referenced, for example in the Portlet Repository. The display name must not be more than 200 characters.

In the Timeout field, enter the number of seconds Oracle Portal should try to connect to the provider before displaying the timeout message.

In the Timeout Message field, enter the message to display when Oracle Portal cannot establish contact with the provider within the number of seconds specified in the Timeout field. The message displays within the body of the portlet.

In the WSDL URL field, enter the WSDL URL for your provider and click Next.

The Portal Registration Property Values page is displayed.

Provide any registration properties required by the provider. If there are none, you can proceed to the next step.

The WS-Security Configuration page is displayed.

In the Keystore Configuration section, enter the parameters discussed in Table 7-18.

Table 7-18 WSRP Producer Key Store Connection Parameters

Field

Description

Store Path

Enter the full path to the keystore that contains the certificate and the private key that is used for signing some parts (security token and SOAP message body) of the SOAP message.

The selected file could be a keystore created with the JDK keytool, or an Oracle Wallet.

Store Password

Provide the password to the key store that was set when the key store was created. Ensure that you enter the correct store password. If you enter a wrong password, the producer portlet displays an error during runtime.

Store Type

Select a keystore type (JKS or ORACLEWALLET) for this producer.

Signature Key Alias

Select a signature key alias from the list.

Signature Key Password

Specify the password for accessing the key identified by the alias specified in Signature Key Alias.

Click Finish. You should see a Registration Confirmation page.

Note:

PeopleSoft 8.48 and 8.49 WSRP producers support the Username Token profile only. An Oracle WSRP producer supports SAML Token profile. For other WSRP containers, check with the specific vendor to determine the token formats they support.

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

Log in to Oracle Portal.

Click the Navigator link.

Click the Portlet Repository page group.

Click Pages.

Next to the Portlet Builders page, click Edit.

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

Select Enable Item Level Security.

Click OK.

Click the Edit Item icon next to OmniPortlet.

Click the Access tab.

Check Define Portlet Access Privileges.

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

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

7.1.12 Securing the Web Clipping Provider

Appendix E, "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:

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

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.

Use Oracle Wallet Manager to import each certificate.

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

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

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 Fusion Middleware 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:

Go to the Web Clipping provider test page at:

http://<host>:<port>/portalTools/webClipping/providers/webClipping

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.

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 Database Advanced Security Administrator's Guide for the list of values to use as all possible combinations of parameters are described in detail.

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

7.1.13 Securing the Federated Portal Adapter

The Federated Portal Adapter is a component of Oracle 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.

7.1.14 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 Oracle Portal using their WebDAV clients. In terms of security, accessing Oracle Portal through WebDAV presents two security issues for you to consider:

Expiration of Oracle Portal session cookies for OraDAV

SSL and OraDAV

7.1.14.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). Many WebDAV clients (For example Oracle Drive, WebFolders and Cadaver) do not prompt the user for a user name and password after that time as they retain the values entered when the user first connected and use them to create a new cookie.

ORACookieMaxAge can be changed in Oracle Enterprise Manager or by directly editing it in the mod_oradav.conf file located in ORACLE_INSTANCE\config\OHS\ohs1\moduleconf. 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:

Execute the following command from ORACLE_INSTANCE\bin\opmnctl 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 Oracle Portal because every request from such clients must be authenticated, requiring added communication with the Oracle Internet Directory.

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

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

7.2.2.2 Defining a Role for Oracle Portal Installers

To run the Oracle Portal Configuration Assistant (OPCA), the user needs certain permissions for the various operations performed by this tool. When the user runs ptlasst, if they provide the credentials -ldap_d 'cn=orcladmin' -worcladmin_pwd, then they assume the identity of the Oracle Internet Directory super user, which enables all operations to succeed. However, if a user needs to run ptlasst as someone other than cn=orcladmin, then explicit privileges must be provided to this user for the operations to succeed.

In enterprise deployments of the Oracle Fusion Middleware, a central data center may have charge of maintaining and managing the central Oracle Identity Management Infrastructure, including Oracle Internet Directory and Oracle Application Server Single Sign-On. If a department or division within the enterprise were to install Oracle Portal and needed to associate it with the central infrastructure, the Oracle Identity Management Infrastructure administrators would probably not want to just hand out the cn=orcladmin password to the departmental administrator to install her Oracle Portal. In such cases, the Oracle Identity Management administrator would grant certain privileges to the Oracle Portal administrator in order to allow her to run the Oracle Portal configuration. After performing the configuration, those privileges could then be revoked.

To define the role for Oracle Portal Installers and assign it to someone, perform the following steps:

An LDIF substitution file (.sbs) is provided to create the group and add it to the appropriate privilege groups in order for it to inherit the necessary privileges to successfully perform Oracle Portal configuration.

The file is:

ORACLE_HOME/portal/admin/plsql/wwc/secadmin.sbs

This file needs to be run through the ldifmigrator to replace the keywords and transform it into a proper LDIF file:

Once the secadmin.ldif file is loaded in the Oracle Internet Directory, the newly created role will be available on the Create/Edit user page of Oracle Delegated Administration Services. In order to grant a user this role, you must be logged in as orcladmin, which is the only user that is able to grant this role to others.

Log on to Oracle Delegated Administration Services and locate the entry for the user to whom you want to grant the ability to install Oracle Portal. Edit the user entry and check the role for Oracle Portal Installer. The user should now have the ability to successfully do the Oracle Portal Configuration.

Note:

In addition to defining this role for Oracle Portal Installers, you should also make sure that, if the directory contains a lot of groups, the Query Entry Return Limit on the directory server is high enough to return all of the groups when queried during Oracle Portal configuration. This limit is stored in the orclsizelimit attribute in the root entry of the directory. The Oracle Portal configuration queries the list of groups in order to populate its local cache. When invoking the configuration using the cn=orcladmin account, query limits are not imposed. However, when doing the configuration as any user other than cn=orcladmin, the server query limits will be imposed. Hence, you must make sure that the limits are set high enough, even if it is just for the duration of the execution of Oracle Portal configuration.

A sample LDIF file that you can use with the ldapmodify command line utility follows:

dn:changetype: modifyreplace: orclsizelimitorclsizelimit: 2000

Alternatively, you can set the Query Entry Return Limit from the Oracle Directory Manager. The attribute is listed against the server entry.

Once the Oracle Portal configuration is complete, you can edit the user's entry again and remove the privilege, which is no longer needed after performing the initial configuration.

7.3.1.1.1 Cache for Oracle Internet Directory Parameters

As pointed out in Section 7.1.7, "Leveraging Oracle Identity Management Infrastructure", Oracle 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.

7.3.1.1.2 Oracle Directory Integration Platform Synchronization

Because Oracle 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 Oracle Portal whenever a change is made in the directory that must be reflected in Oracle Portal. In Global Settings, you can set:

Enable directory synchronization defines whether the directory integration server notifies Oracle Portal when a relevant change is made in the directory. If this setting is not checked, then Oracle Portal will not be notified of any directory integration server subscribed events. For a proper and supported configuration of Oracle Portal this option must be enabled.

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

The following settings let you adjust for login performance and how soon the effects of provisioning changes in groups affect user authorizations:

Enable lazy synchronization of role memberships

A user's group memberships are updated in the portal only at the next login after group memberships are changed in Oracle Internet Directory, and only at the next login. Changes in authorization take effect at the next login. If no updates to the user's groups have occurred between login events, the user's groups are no longer required on subsequent logins, until a change occurs to one of the user's groups.

Enable immediate synchronization of role memberships

A user's group memberships are updated at each login, and are updated when the Portal receives a group update notification from Oracle Internet Directory. This mode is recommended only when authorization updates need to be enforced soon after the updates in Oracle Internet Directory occur, possibly changing a user's authorizations within a current session.

Enable synchronization of role memberships on every login

A user's group memberships are updated in the portal at each login and take effect at the next login after groups are updated in Oracle Internet Directory.

A user's group memberships are updated in the portal at each login, with the updated set of group memberships being in effect for the duration of that session. Oracle Internet Directory is queried for the current set of group memberships at each login, whether needed or not. If, for any reason, the user's group memberships are not correctly reflected in the Portal, it will be re-established with the correct set at each login.

Figure 7-18 compares the tradeoffs between login performance, and how quickly user authorizations are updated for each setting:

Table 7-19 Synchronization Setting Comparison

Setting

Description

Lazy synchronization

Best performance - login slows only after a group membership change affecting this user has been done.

Immediate Synchronization

This has the most performance impact as group synchronization updates may occur within a user's session, and will also occur at each login, and to get the most "immediate" effect, the DIP synchronization interval and the webcache soft invalidation interval needs to be set fairly low, thereby increasing the frequency of these events.

Synchronize at each login

Baseline performance - consistent with previous releases.

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

If you add a user to a group, the Oracle Directory Integration and Provisioning server notifies Oracle Portal of the change. Oracle 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 Oracle Portal of the change. Oracle 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.

7.3.1.1.3 Group Creation Base Distinguished Name (DN)

Oracle 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 Oracle 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 Oracle 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 Oracle Portal to interact with an existing DIT.

7.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 Oracle Portal to search for existing groups. For example, you need to specify where Oracle 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 Oracle 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 Oracle Portal to interact with an existing DIT.

7.3.1.2 Enforcing Role-Based Access Control

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

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

7.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 Oracle 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 7-20, which shows the relative order of the elements in web.xml.

Table 7-20 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:

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

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

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

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 Oracle Fusion Middleware Control, as you would with JNDI environment entries.

Oracle Portal

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

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

In the Remote Providers portlet, click Register a Provider.

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

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

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

Follow the instructions in the wizard and click Finish.

7.3.1.3.2Enhanced Authentication

If your JPDK Web provider code is running in an WLS 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 Fusion Middleware Developer's Guide for Oracle Portal. Enhanced message authentication secures the integrity of the additional headers that are used to propagate the user's authenticated identity to the provider.

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

JPDK Web Provider

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

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 7-20, 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:

Enter the service name and the shared key value, as shown in Example 7-2.

In Example 7-2, 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 7-3.

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

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

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 Oracle Fusion Middleware Control, as you would with JNDI environment entries.

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

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

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.

Oracle Portal

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

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

In the Remote Providers portlet, click Register a Provider.

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

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

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

7.3.2.1.1 Overview of SSL Configurations

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

Interacting with Oracle 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:

Oracle Web Cache

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

Before using the methods recommended to configure SSL, you must confirm that Oracle 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 Oracle Portal home page is accessible

Users can log in to Oracle Portal

Edits to content are shown immediately

7.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 7-19 shows a configuration where OracleAS Single Sign-On is configured to use SSL.

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.

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:

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

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:

Logon to Oracle Portal as a user with administrator privileges.

Click the Administration tab, in the Portal Builder page.

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

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.

After enabling SSL on OracleAS Single Sign-On by following the steps listed below. In this release of Oracle 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:

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:

Open the Oracle Wallet Manager (ORACLE_HOME\bin\owm). 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 Oracle 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 Oracle Metadata Repository.

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

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:

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.

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

Click View Certificate.

Click the Certification Path tab.

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

Click View Certificate.

Click Install Certificate.

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

Click Next.

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

Click Next.

Click Finish.

The trusted root certificate is installed in your browser.

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

Click the Certification Path tab.

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

Click View Certificate.

Click the Details tab.

Click Copy to File....

This brings up the Certificate Export Wizard.

Click Next.

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

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

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:

Right-click the Trusted Certificates node.

Select Import Trusted Certificate....

Select Paste the certificate, and click OK.

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

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

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

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

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.

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

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.

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.

Log on to Oracle Portal as a user with administrator privileges.

Go to the Builder.

Click the Administration tab.

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

Scroll to the bottom of the page.

Select Refresh Cache for OID Parameters.

Click Apply.

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

Note:

When SSO is enabled for SSL and registered to access via Portal URL, ensure that the Portal Global settings page points to the https url for the orcldasurlbase entry in OID, to facilitate OID operations from Oracle Portal.

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 infrastructure tier (OID) directory ORACLE_HOME/sso/bin.

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

7.3.2.1.3SSL to Oracle Web Cache

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

Figure 7-20 shows a configuration where Oracle Web Cache is configured to use SSL.

In the previously described configuration of SSL, you must re-register the Oracle Portal 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.

The various components of Oracle 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 CertificateTo obtain a digital certificate from the relevant signing authority, you submit a Certificate Request (CR) uniquely identifying your server to the signing authority.

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

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

Create a password for the wallet, and select one of the option standard (default value) or PKCS1, as the Wallet Type.

Click Yes to accept the option to create a CR.

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

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

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.

Save the wallet in a convenient directory, for example:

ORACLE_HOME\webcache\wallets\portalssl

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.

Select the Certificate node in the Wallet Navigator.

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

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

Exporting Certificate Request

To export the certificate request:

Choose Operations > Export Certificate Request.

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

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

Managing Trusted CertificatesOnce 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:

Choose Operations > Import Trusted Certificate.

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

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.

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:

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:

Choose Operations > Import User Certificate.

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

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

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 Oracle Web Cache accesses the wallet as the process starts and the wallet password is not held by Oracle Web Cache. If this property is not set, Oracle Web Cache immediately shuts down if running in SSL mode. To set this property, perform the following steps:

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

Choose Wallet > Save.

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

Securing Oracle Web Cache

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

Configuring Oracle Web Cache SSL Port

To Configure the Oracle Web Cache SSL port, perform the following steps:

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

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 Oracle Web Cache hostname in a configuration where Oracle Web Cache receives browser requests.

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

Leave the URL Prefix blank.

Select the Default site checkbox.

Deselect the Compression checkbox.

Click OK.

Click Apply.

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:

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 Oracle Web Cache listening port for the Oracle Web Cache SSL site. To create a site alias:

From the Sites page, select the newly added site, and click Edit.

In the Aliases section, click Create to create a new alias and 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 Oracle Web Cache.

Click OK.

Click Apply.

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 Oracle Web Cache is 8090, then you should select the Site with SSL Port 4443, and add an alias for it using the non-SSL port of Oracle Web Cache (8090).

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:

From the Sites page, in the Site-to-Server Mapping section, click Create.

The Create Site-to-Server Mapping Definition page is displayed.

In the Create Site-to-Server Mapping section, enter the information of the Site you are mapping, which should be the Oracle 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 Patternportal.mycompany.com and PortPattern4443.

In the Origin Servers section, select the non-SSL Origin Server to which requests should be routed for content, and move it from All Origin Servers to the Selected Origin Servers listing. For example, if the origin server is running on port 8888 on host portal.mycompany.com, then select portal.mycompany.com:8888.

The Session Binding feature in Oracle Web Cache is used to bind user sessions to a given origin server to maintain state for a period of time. Although almost all components running in a default Oracle Portal middle tier are stateless, session binding is required:

To make Oracle Web Cache bind the portal user session to the Oracle Portal middle tier, perform the following steps:

Navigate to the Web Cache Home page, in the Oracle Enterprise Manager 11g Fusion Middleware Control.

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:

Login to the Oracle Enterprise Manager 11g Fusion Middleware Control.

From the Oracle Portal home page's Portal menu, select Settings, and then Page Engine.

The Page Engine Configuration page is displayed.

In the Advanced Properties section, add the following parameters:

Use Port: 8090

Use Scheme: http

HTTPS Ports: 3232

(Optional) If you want the PPE to trust only specific certificates, in the Advanced Properties section, add x509certfile in the 509 Certification file field.The value of x509certfile is the absolute path to the text file containing the list of certificates which defines the group of "trusted" servers.

Note:

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

Click Apply.

Restart your managed server (WLS_PORTAL).

Configure HTTP Server

Add a Virtual Host definition, for Portal to work with the SSL port of web cache, this configuration will specify the self-referential urls for the hostname and the port. Add the following details for the virtual host in the httpd.conf file:

Restart the Oracle HTTP Server by selecting Control, and then Restart from the Oracle HTTP Server Home page.

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 infrastructure tier (OID) in MID_TIER_ORACLE_HOME/sso/bin.

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

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:

Select the Details tab.

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 ORACLE_HOME/portal/conf/providertemp.cer.

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

Enabling Access for Secure Enterprise Search

For Secure Enterprise Search to access secure Web sites, you need to import certificates into the crawler's trust store and the Oracle Containers for J2EE (WLS) JVM's trust store on the middle-tier and infrastructure instances.

By default, the WLS 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 WLS JVM's truststore. The WLS 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:

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

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

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

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

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 Secure Enterprise Search crawler.

Wiring the Portal Repository

Configure the portal middle tier as follows :

Navigate to the Portal Home page in the Oracle Enterprise Manager 11g.

From the Portal menu, select Settings, and then Wire Configuration.

The Portal Wire Configuration page is displayed.

Enter the following information under Portal Middle Tier section in the Portal Wire Configuration page:

Published Host: Enter the host name.

Listening Port: Enter the port number.

Check the SSL Protocol check box.

Click Apply.

Restart your managed server.

Configuring Portal Repository for Web Cache SSL

Portal requires mod_osso to retrieve the SSO information. Now that mod_osso is configured for SSL (registered as partner application with WC ssl port), portal requires the wallet path and password used to store the WC ssl certificate.

To update the Wallet Path and Password in Portal Repository Preference Store, do the following:

If you don't have a database wallet, you could create one using OWM (Oracle wallet manager) or orapki utility in the installation where the database resides. Once you have the wallet, import the SSL certificate of web cache into the database wallet.

This wallet location has to be registered into the Portal preference store using the secwc.sql script, located at ORACLE_HOME\portal\admin\plsql\wwc.

7.3.2.1.4 End to End SSL for Oracle 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 Oracle 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 7-21 shows a configuration where SSL is configured throughout Oracle Portal.

It is possible to share a single wallet across both the listener and origin server (and all other available ports in Oracle Web Cache) if Oracle 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 Oracle 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 Oracle Web Cache, you can share the wallet between the two.

Configuring Oracle HTTP Server and Oracle WebLogic Server

You need to configure the Oracle HTTP Server to establish SSL communication to WebLogic Server (WLS) and the routing information to Weblogic Managed Server (WLS_PORTAL), should proxy the SSL mode. To configure HTTP and WLS perform the following steps:

From the Oracle Enterprise Manager 11g Fusion Middleware Control, go to Oracle HTTP Server home page, and select Administration, and then Advanced Configuration.

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 and ensure that in the webcache.xml file, the wallet location is added in the <OSWALLET> tag.

Restart the Oracle HTTP Server.

Copy the certificate from the wallet, you created above to a text file and import into the truststore used by the Weblogic Managed Server where Portal is deployed.

For exporting the certificate from the OHS wallet, you can used Oracle Wallet Manager or the orapki utilities available with middle tier and for importing into the truststore, you can use java keytool.

Securing Oracle Web Cache

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

Configuring the Oracle Web Cache SSL Port

To configure the Oracle Web Cache SSL port, perform the following steps:

The Session Binding feature in Oracle Web Cache is used to bind user sessions to a given origin server to maintain state for a period of time. Although almost all components running in a default Oracle Portal middle tier are stateless, session binding is required for two reasons:

To make Oracle Web Cache bind the portal user session to the Oracle Portal middle tier, perform the following steps:

Navigate to the Web Cache Home page, in the Oracle Enterprise Manager 11g Fusion Middleware Control.

From the Web Cache menu, select Administration, and then Session Configuration.

The Session Configuration page displays.

Select the Site, you have created in previous steps.

From the Session Binding Configuration section, select Cookie based session binding with any Set-Cookie.

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

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 Oracle Web Cache, you must restart the Oracle Web Cache server using the Oracle Fusion Middleware Control for the changes to take effect.

Securing the Parallel Page Engine

In this configuration, SSL is used throughout as the request comes to Oracle 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 Oracle Portal middle tier:

Login to the Oracle Enterprise Manager 11g Fusion Middleware Control.

From the Oracle Portal home page's Portal menu, select Settings, and then Page Engine to display the Page Engine Configuration page.

In the Advanced Properties section, enter 3232 as the HTTPS Ports value.

(Optional) If you want the PPE to trust only specific certificates, add x509certfile. The value of x509certfile is the absolute path to the text file containing the list of certificates which defines the group of "trusted" servers.

Note:

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

Click Apply.

Restart your managed server (WLS_PORTAL).

Specifying Oracle Portal Published Address and Protocol

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

Click the Standalone Instance with the Oracle Fusion Middleware that is running the Oracle Portal middle tier.

Click the Oracle Portal system component.

Under Administration, click Portal Web Cache Settings.

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

For Listening Port SSL Enabled, choose Yes.

Click OK. The Oracle Portal schema is updated with the setting and the Oracle Enterprise Manager 11g 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.

Configure HTTP Server

Edit the Virtual Host definition, for Portal to work with the SSL, this configuration will specify the self-referential urls for the hostname and the port . Go to Oracle HTTP Server home page in the Oracle Enterprise Manager 11g Fusion Middleware Control, select Administration, andthen Advanced Configuration. Select the ssl.conf file, and add the following details for the virtual host shown in bold:

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 infrastructure tier (OID) in ORACLE_HOME/sso/bin.

Portal queries mod_osso to retrieve the SSO information. Now that mod_osso is configured for SSL (registered as partner application with WC ssl port), portal need to know the wallet path and password used to store the WC ssl certificate.

To update the Wallet Path and Password in Portal Repository Preference Store, do the following:

If you don't have a database wallet, you could create one using OWM (Oracle wallet manager) or orapki utility in the installation where the database resides. Once u have the wallet, import the SSL certificate of web cache into the database wallet.

This wallet location has to be registered into the Portal preference store using the secwc.sql script, located at ORACLE_HOME\portal\admin\plsql\wwc.

7.3.2.1.5 External SSL with Non-SSL Within Oracle Fusion Middleware

The previous configurations discuss how to configure Oracle Portal in such a way that communications within Oracle Fusion Middleware are secured through SSL. In some cases, you may want to have Oracle Portal set up such that the site is externally accessible through SSL URLs but the Oracle Fusion Middleware 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 Oracle Fusion Middleware 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 Fusion Middleware enables you to configure these external devices to provide SSL, thus allowing Oracle Fusion Middleware to use HTTP internally for the best performance.

Figure 7-22 shows a configuration where Oracle Portal is externally accessible through SSL.

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 an SSL accelerator, such as 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.

Oracle Web Cache is on computer w1.abc.com and the listening port is 8090, the administration port is 4002, and the invalidation port is 4001.

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

You need to configure the Oracle Fusion Middleware 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:

Set up an alias for Oracle Web Cache. In the configuration where the Parallel Page Engine loops back to Oracle Web Cache and Oracle 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:8090, whereas Oracle 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 Oracle Web Cache to let it know that lbr.abc.com:8090 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.

From the Oracle Web Cache home page in the Oracle Enterprise Manager 11g Fusion Middleware Control, select Administration, and then Sites.

From the Sites page, select the newly added site, in this case lbr.abc.com and click Edit.

The Edit Site page is displayed.

In the Aliases section, click Create to create a new alias, enter lbr.abc.com as the Host and 8090 as the Port, where 8090 is the value for usePort in the appConfig.xml configuration file for the Parallel Page Engine.

Click OK.

Click Apply.

From the Web Cache menu, select Control, and then Restart, to restart Oracle Web Cache.

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

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:

From the Sites page, in the Site-to-Server Mapping section, click Create.

The Create Site-to-Server Mapping Definition page is displayed.

In the Create Site-to-Server Mapping section, enter the information of the Site you are mapping (lbr.abc.com) and then select a site definition created in the previous step.

In the Origin Servers section, select m1.abc.com, and move it from All Origin Servers to the Selected Origin Servers listing.

Click OK.

Click Apply.

From the Web Cache menu, select Control, and then Restart, to restart Oracle 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.

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

Accept requests on HTTP port 8090 and forward them to the Oracle Web Cache port 8090 running on computer w1.abc.com. This enables the loopback requests. The LBR's port 8090 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 8090

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

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

telnet lbr.abc.com 4001

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

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

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 infrastructure tier in MID_TIER_ORACLE_HOME/sso/bin.

For Secure Enterprise Search to access secure Web sites, you need to import certificates into the crawler's trust store and the Oracle Containers for J2EE (WLS) JVM's trust store on the infrastructure instance.

By default, the WLS 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 WLS JVM's truststore. The WLS 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:

Change directory to ORACLE_INSTANCE\jdk\jre\lib\security on the infrastructure.

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

Execute the following command in UNIX to add the required certificate to the trust store:

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 Oracle Metadata Repository containing the Oracle Portal schema. To configure Web providers or provider groups exposed over SSL, perform the following steps:

To import the producer SSL certificate into the database keystore, perform the following:

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

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

Execute the following command (in Unix) to add the required certificate to the trust store:

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

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

Note:

If your portal schema is located in an Repository Creation Utility (RCU) 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.

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

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 Fusion Middleware Developer's Guide for Oracle Portal.

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.

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:

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 Portal installation. When you register the producer in Oracle 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

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.

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 Oracle Metadata Repository containing the Oracle 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.

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:

Change directory to ORACLE_INSTANCE\javavm\lib\security on the Oracle home containing the Oracle Database hosting the Oracle Metadata Repository containing the Oracle Portal schema.

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

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

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

(Optional) If you want the PPE to trust only specific certificates, then add x509certfile in the appConfig.xml file (Located at, MW_HOME\user_projects\domains\<DomainName>\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration). 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:

<x509certfile>c:\mySSLconfig\trustedCerts.txt</x509certfile>

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

Once Oracle Internet Directory is configured to use SSL, you must update the Oracle Portal schema to use the new port on the LDAP server. To perform this step, you run the SQL script, secupoid.sql, located in 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:

7.3.2.3.1 Updating the Oracle Text Base URL

After configuring SSL for portal, perform the following steps to update the Oracle Text Base URL:

Login to your Oracle Portal.

Click the Administer tab.

Under Services, select Global Settings.

Select the Search tab, from the Global Setting page.

In Oracle Text Base URL, change the URL property from http to https in the Base URL. For example, change http://abc0088.us.abc.com:8090/portal/pls/portal/ to https://abc0088.us.abc.com:8090/portal/pls/portal/.

7.3.2.3.2 Safeguard Passwords for Lightweight Oracle 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:

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.

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.

7.3.2.3.3 Remove Unnecessary Objects

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

Delete page groups that are no longer in use.

Delete Oracle Portal providers that are no longer in use.

7.3.2.3.4 Review Default Seeded Privileges

When Oracle Portal is installed, the seeded groups listed in Table 7-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:

Oracle Portal access control entries

Oracle Internet Directory privilege groups

To edit the privileges granted through Oracle 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 Oracle 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.

7.3.2.3.5 Revoke Public Access to Provider Components

In some cases, Oracle 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.

7.3.2.3.6 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 Oracle Portal Home Page, and the Builder and Navigator pages.

Portlet Repository

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

In the Navigator, click Page Groups.

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

Click the Access tab.

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

When you are done, click OK.

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

In the Navigator, click Page Groups.

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

Click Pages.

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

Click the Access tab.

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

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.

7.3.2.3.7 Protect PL/SQL Packages

The default installation protects standard database procedures that are granted to PUBLIC (for example, dbms_*, utl_*). 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 Fusion Middleware User's Guide for mod_plsql.

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

To configure Oracle 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 Oracle Portal configuration parameters related to the directory:

Directory hostname

Directory port

Application directory password

SSL setting

When you install Oracle 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 Oracle Portal's directory cache after running it. Because activating SSL does not change any of the directory information cached by Oracle Portal, it is not usually necessary to refresh the cache in this case.

7.3.2.3.10 Change the Application Entity Password

Oracle Portal never passes a user's password to the directory. Only OracleAS Single Sign-On performs that task. However, Oracle 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, Oracle Portal's application entry is:

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 Oracle Portal to encrypt the password and store it for retrieval when it needs to connect to the directory.

7.3.3 Configuring Oracle 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 11g 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.

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