Skip Headers

Oracle9i Application Server Security Guide
Release 2 (9.0.2)

Part Number A90146-01
Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Go to previous page Go to next page

6
Configuring Oracle9iAS Portal Security

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

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. Oracle9iAS 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 Oracle9iAS 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 machine 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, Oracle9iAS Portal leverages the other components of Oracle9iAS and Oracle9i to provide strong protection for your portal. Oracle9iAS Portal interacts with all of the following components to implement its security model:

Figure 6-1 Oracle9iAS Portal Security Architecture

Text description of porsecar.gif follows

Text description of the illustration porsecar.gif

User Authentication and Privilege Model

When a user attempts to log in to Oracle9iAS Portal, their credentials must first be verified by Single Sign-On server against the directory. Once their identity has been verified, Oracle9iAS Portal checks their access privileges in the directory to determine which objects they may see and use within the portal. The figure and text below describe this model in more detail.

Figure 6-2 Oracle9iAS Portal Authentication Model

Text description of porauthmo.gif follows

Text description of the illustration porauthmo.gif

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

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

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

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

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

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

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

Portal Security Architecture

As you might expect, based upon the model described in the previous sections, Oracle9iAS Portal administrators need to understand all of the following:

Relationship between Oracle9iAS Portal and Oracle9iAS Single Sign-On

Portal uses Oracle9iAS Single Sign-On for user authentication, as discussed in "User Authentication and Privilege Model".


Note:

Oracle9iAS Portal can only be associated with Oracle9iAS Single Sign-On Release 9.0. It cannot be used with older versions. Similarly, Oracle9iAS Single Sign-On Release 9.0 will not work with earlier versions of Oracle9iAS Portal.


The Oracle9iAS Single Sign-On manages the Single Sign-On sessions of users. In order for Single Sign-On security to function properly, Oracle9iAS Portal requires the following for integration with Oracle9iAS Single Sign-On:

These two configuration steps are performed for you upon installation by the Oracle Universal Installer. If you need to make changes to your configuration after installation, you can do so by invoking ptlasst.csh (Unix) or ptlasst.bat (MS Windows). These scripts and their documentation are located in ORACLE_HOME/assistants, where ORACLE_HOME is the home directory for Oracle9i Application Server. To change the Oracle9iAS Single Sign-On settings for Oracle9iAS Portal, you must invoke these scripts with -mode set to one of the following:

Relationship between Oracle9iAS Portal and Oracle Internet Directory

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

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

Directory entries in Oracle Internet Directory for Oracle9iAS Portal

In order for security to function properly, Oracle9iAS Portal requires the following entries in the directory's DIT structure:

The figure below shows where the Oracle9iAS Portal information is located in the directory's DIT structure.

Figure 6-3 DIT Structure for Oracle9iAS Portal

Text description of porditst.gif follows

Text description of the illustration porditst.gif

User attributes stored in Oracle Internet Directory

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

The tables below show the various user attributes stored in Oracle Internet Directory.

Table 6-1 inetOrgPerson Attributes  
inetOrgPerson (IETF) attributes Comment

Cn

The common name and default nickname of the user. This is the name the user logs in to Oracle9iAS Portal via Single Sign-On server.

This attribute is mandatory.

EmployeeNumber

Number used to identify employees

Sn

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

GivenName

First name

MiddleName

 

DisplayName

Nickname

Mail

e-mail address

TelephoneNumber

 

HomePhone

 

Mobile

 

Pager

 

FacsimileTelephoneNumber

 

Street

 

L

City of office

St

State of office

PostalCode

Postal code of office

C

Country of office

HomePostalAddress

Home address

JpegPhoto

Person's picture

O

Organization

Title

 

Manager

Employee's supervisor

UserPassword

 

PreferredLanguage

 

Table 6-2 orclUserV2 Attributes  
orclUserv2 attributes Comments

orclIsVisible

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

orclDisplayPersonalInfo

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

orclMaidenName

 

orclDateOfBirth

 

orclHireDate

 

orcleDefaultProfileGroup

Default user group for the person

orclActiveStartDate

When account was activated

orclActiveEndDate

when account was (or will be) terminated

orclTimeZone

 

orclIsEnabled

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

For users who are familiar with the user properties from previous versions of Oracle9iAS Portal, the following table maps the old user properties to the new Oracle Internet Directory attributes.

Table 6-3 Mapping of Oracle9iAS Portal User Properties to Oracle Internet Directory  
Previous Oracle9iAS Portal user property inetOrgPerson or orclUserv2 attributes

ID

Not applicable because ID remains a local Oracle9iAS Portal attribute that is linked to the corresponding directory entry by means of a globally unique identifier.

EMPNO

EmployeeNumber

LAST_NAME

Sn

FIRST_NAME

GivenName

MIDDLE_NAME

MiddleName

KNOWN_AS

DisplayName

EMAIL

Mail

WORK_PHONE

TelephoneNumber

HOME_PHONE

HomePhone

MOBILE_PHONE

Mobile

PAGER

Pager

FAX

FacsimileTelephoneNumber

OFFICE_ADDR(1,2,3)

Street

OFFICE_CITY

L

OFFICE_STATE

St

OFFICE_ZIP

PostalCode

OFFICE_COUNTRY

C

HOME_ADDR[1,2,3],CITY, STATE,ZIP,COUNTRY

HomePostalAddress

IMAGE

JpegPhoto

ORGANIZATION

O

TITLE

Title

MANAGER

Manager

PASSWORD

UserPassword

DISPLAY

orclIsVisible

DISPLAY_PERSONAL_INFO

orclDisplayPersonalInfo

NOTIFICATION_PREFERENCE

orclWorkflowNotificationPref

USER_NAME

orclCommonNickNameAttribute, which is the nickname used in place of the user's full Dn. The full Dn attribute is quite long (cn=name,o=domain,dc=com), hence it is simpler for users to log in with this nickname. For more information, refer to the documentation on Oracle Internet Directory.

MAIDEN_NAME

orclMaidenName

DATE_OF_BIRTH

orclDateOfBirth

HIREDATE

orclHireDate

SUBSCRIBER_ID

Not applicable because the subscriber identifier is obtained from the user's subscriber node.

DEFAULT_GROUP

orcleDefaultProfileGroup

Group attributes stored in Oracle Internet Directory

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

The tables below show the various group attributes stored in Oracle Internet Directory:

Table 6-4 groupOfUniqueNames Attributes  
groupOfUniqueNames (IETF) attributes Comment

Cn

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

Description

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

uniqueMember

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

Owner

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

Table 6-5 orclGroup Attributes  
orclGroup attributes Comment

orclGUID

The globally unique identifier (GUID) for this group.

orclIsVisible

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

For users who are familiar with the group properties from previous versions of Oracle9iAS Portal, the following table maps the old user properties to the new Oracle Internet Directory attributes:

Table 6-6 Mapping of Oracle9iAS Portal Group Properties to Oracle Internet Directory
Previous Oracle9iAS Portal group property groupOfUniqueNames or orclGroup attribute

ID

local ID for the group, which can be matched to the orclGUID in the directory by a new locally stored orclGUID.

HIDDEN_GROUP

orclIsVisible

SUBSCRIBER_ID

Subscriber id is no longer needed because the location of the group entry under a subscriber base indicates the subscriber.

NAME

Cn

DESCRIPTION

Description

group membership

uniqueMember

OWNER

Owner

Oracle Internet Directory Cache in Oracle9iAS Portal

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

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

User and Group Lists of Values in Oracle9iAS 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.

If you have your directory and Oracle9iAS Portal servers residing in different domains, you must explicitly set the JavaScript domain for Oracle9iAS Portal such that it can resolve user and group lists of values. For example, suppose that your installation has Oracle9iAS Portal configured to use a different Oracle HTTP Server than the Delegated Administration Service. In this situation, you need to have a common domain so that the values can be transferred from the list of values displayed by the Delegated Administration Service to the page displayed by Oracle9iAS Portal.

To create a single domain in this case, do the following:

  1. Login to SQL*Plus as PORTAL.

  2. Run the following SQL script:

    secjsdom.sql <domain_name>
    
    

Performing this procedure enables you to run directory lists of values from Oracle9iAS Portal in either Netscape or MicroSoft Internet Explorer. When using lists of values, a transit window is displayed in addition to the list of values itself. The transit window is required to pass values to Oracle9iAS Portal without forcing pages to reset their domain.

See Also:

"Group Search Base Distinguished Name (DN)" for information about choosing where Oracle9iAS Portal searches for groups.

Relationship between Oracle9iAS Portal and the Oracle Directory Integration Server

Directory synchronized provisioning is a service provided by Oracle Directory Integration Server to notify components of user and group change events in the directory. The figure below illustrates how the directory integration server keeps components synchronized with the latest information in the directory.

Figure 6-4 Oracle Directory Integration Server Synchronization Model

Text description of dipsynch.gif follows

Text description of the illustration dipsynch.gif

Components, such as Oracle9iAS Portal, subscribe to provisioning events (for example, deletion of a group) in order to keep their local caches of user and group information synchronized with the central user and group repository in the 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 directory integration server. Oracle9iAS 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. The table below shows the events to which Oracle9iAS Portal subscribes and the actions it takes when those events occur:

Table 6-7 DIrectory Synchronized Events Handled by Oracle9iAS Portal  
Subscribed event Oracle9iAS 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 Oracle9iAS Web Cache.

USER MODIFY
(orclDefaultProfileGroup)

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

GROUP DELETE

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

GROUP MODIFY
(uniqueMember)

The WWSEC_FLAT$ table is updated to reflect membership changes that effect Oracle9iAS Portal.

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


Note:

Oracle9iAS 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 of Oracle9iAS Portal. Similarly, a local group profile is created automatically when a new group is first referenced in an access control list.


Relationship between Oracle9iAS Portal and Delegated Administration Service

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

Creating and updating information stored in Oracle Internet Directory

The Delegated Administration Service 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 Oracle9iAS Portal. To access these portlets, a user must be a member of the OracleDASCreateUser and OracleDASCreateGroup groups, respectively. The PORTAL and PORTAL_ADMIN users are members of both of these groups by default. AUTHENTICATED_USERS may also create groups by default.

Relationship between Delegated Administration Service, mod_osso, and the Oracle9iAS Single Sign-On Server

When users access the delegated administration server, they do so through mod_osso for authentication. If they are successfully authenticated and have the appropriate privileges, they can access the delegated administration server.

Creating Users and Groups

As stated in the previous section, the most common way to create users and groups for your portal is through the User and Group portlets on the Administration page of Oracle9iAS Portal. Furthermore, you can set global privileges and preferences for portal users and groups via the Portal User Profile and Portal Group Profile portlets.

You must be a member of one of the following groups to access the User, Group, Portal User Profile, and Portal Group Profile portlets:

If you are not a member of one of these groups, then you must be a member of the following privilege groups:

The directory access control policy on the directory information tree provides members of these privilege groups with access to the User, Group, Portal User Profile, and Portal Group Profile portlets.

User Portlet

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

See Also:

The following documentation for detailed information on the settings that are available through the User portlet:

  • Oracle9iAS Portal Online Help

  • Oracle Internet Directory Administrator's Guide in the Oracle9iAS Documentation Library for information about Delegated Administration Service

Figure 6-5 User Portlet

Text description of userport.gif follows.

Text description of the illustration userport.gif

Portal User Profile Portlet

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

Figure 6-6 Portal User Profile Portlet

Text description of uprfport.gif follows.

Text description of the illustration uprfport.gif

Group Portlet

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

See Also:

Detailed information on the Group portlet settings in the following documentation:

  • Oracle9iAS Portal Online Help

  • Oracle Internet Directory Administrator's Guide in the Oracle9iAS Documentation Library for information about Delegated Administration Service

Figure 6-7 Group Portlet

Text description of grpport.gif follows.

Text description of the illustration grpport.gif

Portal Group Profile Portlet

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

Figure 6-8 Portal Group Profile Portlet

Text description of gprfport.gif follows.

Text description of the illustration gprfport.gif

Granting Access Privileges

Within Oracle9iAS Portal, you decide at what level of granularity you want to control access. You can assign privileges to any object on a per user or per group basis. For example, you can assign access privileges on a per user basis 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 on a per group basis 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.

Access Tab

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

Table 6-8 Oracle9iAS Portal Objects with Privilege Control  
Type of Object Available Privileges Inherited Privileges

Calendar

  • Manage

  • View

  • Customize

  • Execute

From Database Provider

Chart
(based on SQL query)

  • Manage

  • Edit

  • View

  • Customize

  • Execute

From Database Provider

Chart
(based on wizard)

  • Manage

  • Edit

  • View

  • Customize

  • Execute

From Database Provider

Data Component

  • Manage

  • Edit

  • View

  • Customize

  • Execute

From Database Provider

Data Component Cell

  • Edit

  • View

From Data Component

Database Provider

  • Manage

  • Edit

  • View Source

  • Customize

  • Execute

Not applicable

Document

  • Own

  • Manage

  • View Only

From page or item

Dynamic Page Component

  • Manage

  • Edit

  • View

  • Customize

  • Execute

From Database Provider

FormFoot 1

  • Manage

  • Edit

  • View

  • Customize

  • Execute

From Database Provider

Frame Driver

  • Manage

  • Edit

  • View

  • Customize

  • Execute

From Database Provider

Hierarchy

  • Manage

  • Edit

  • View

  • Customize

  • Execute

From Database Provider

Image Chart

  • Manage

  • Edit

  • View

  • Customize

  • Execute

From Database Provider

Link

  • Manage

  • Edit

  • View

  • Customize

  • Execute

From Database Provider

List of Values

  • Manage

  • Edit

  • View

  • Customize

  • Execute

From Database Provider

Menu

  • Manage

  • Edit

  • View

  • Customize

  • Execute

From Database Provider

Oracle9i Reports printer

  • Manage

  • Edit

  • View

  • Execute

From Database Provider

Oracle9i Reports report

  • Manage

  • Edit

  • View

  • Customize

  • Execute

From Database Provider

Oracle9i Reports Server

  • Manage

  • Edit

  • View

  • Execute

From Database Provider

Page

  • Manage

  • Manage Content

  • Manage Items With Approval

  • Manage Style

  • Customize Portlets (Full)

  • Customize Portlets (Add-Only)

  • Customize Portlets (Hide-Show)

  • Customization(Style)

  • View

Not applicable

Page group

  • Manage All

  • Manage Classifications

  • Manage Templates

  • Manage Styles

  • View

Not applicable

Page Item

  • Own

  • Manage

  • View Only

From page

Portlet

  • Manage

  • Edit

  • Execute

  • Access

  • Publish

Not applicable

Provider

  • Manage

  • Edit

  • Publish

  • Execute

Not applicable

Query by example form

  • Manage

  • Edit

  • View

  • Customize

  • Execute

From Database Provider

ReportFoot 2

  • Manage

  • Edit

  • View

  • Customize

  • Execute

From Database Provider

Schema

  • Manage

  • Modify

  • Insert

  • View

Not applicable

URL

  • Manage

  • Edit

  • View

  • Customize

  • Execute

From Database Provider

XML

  • Manage

  • Edit

  • View

  • Customize

  • Execute

From Database Provider

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

See Also:

Oracle9iAS Portal Online Help for more information on the available privileges for each of these objects.

Administering Portal Security

To effectively administer Oracle9iAS Portal security, you must decide where you will install the portal components, understand the default security settings, complete the security checklist, and understand how to change the Oracle Internet Directory settings. Each of these tasks is described in the following sections:

Security Settings Upon Installation

Before you can begin to administer Oracle9iAS Portal, you must first understand the default settings that are created during installation.

Oracle9iAS Portal Default Schemas and Accounts

The tables that follow describe the schemas, users, and groups that are created by default when Oracle9iAS Portal is installed.

Table 6-9 Default Oracle9iAS Portal Schemas  
Schema Description

PORTAL

Contains the Portal product database objects and code. This schema also represents the proxy user account that mod_plsql uses to connect to the database through the credentials provided in the corresponding DAD. To execute Web requested procedures, mod_plsql then uses N-Tier authentication to connect to the schema to which the lightweight user accounts are assigned (by default, PORTAL_PUBLIC).

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

PORTAL_PUBLIC

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

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

See Also:

For more information about mod_plsql and how to use it.

Table 6-10 Default Oracle9iAS Portal Users  
User Description

PUBLIC

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

PORTAL

Is the super-user for the portal. In a standard installation, the user name is PORTAL. This user account has the highest privileges because it is granted all the global privileges available in the portal.

PORTAL_ADMIN

Is a privileged Oracle9iAS Portal user account with administrative privileges excluding those that would give the user the ability to obtain higher privileges or perform any database operations. This user cannot edit any group or manage privileges on any schema or shared object. This account is typically intended for an administrator who manages pages and provisions user accounts.

Table 6-11 Default Oracle9iAS Portal Groups  
GroupFoot 1 Description

AUTHENTICATED_USERS

Is the group that includes any authenticated, or logged in, user. The purpose of this group is to provide a means to assign the default privileges you want every logged in user to have in the portal. Hence, this group is initialized with all of the privileges that you want to grant to the least privileged user who logs in to the portal.

DBA

Is a highly privileged group established for Oracle9i Application Server administrators. Components that are part of Oracle9i Application Server grant full component-specific privileges to members of this group. The DBA group is a member of the PORTAL_ADMINISTRATORS group.

PORTAL_ADMINISTRATORS

Is a highly privileged group established for Oracle9iAS Portal. The PORTAL_ADMINISTRATORS group is a member of the IASADMINS group. Thus, members of PORTAL_ADMINISTRATORS can, by default, administer Oracle9iAS Single Sign-On (just as they could in earlier versions of Oracle9iAS Portal).

PORTLET_PUBLISHERS

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

PORTAL_DEVELOPERS

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

RW_ADMINISTRATOR

Is the group of users who administer Oracle9i Reports reports, printers, and servers

RW_DEVELOPER

Is the group of users who develop Oracle9i Reports reports

RW_POWER_USER

Is the group of users who can modify Oracle9i Reports reports

RW_BASIC_USER

Is the group of users who use Oracle9i Reports reports

1 All groups shown in this table are located in cn=PORTAL_GROUPS,cn=Groups,o=MyCompany,dc=com. Note that subscriber 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 subscriber name would be o=oracle,dc=com. If the domain name server cannot be determined, Oracle Internet Directory defaults to the domain specified during installation by the administrator.

Post-Installation Security Checklist

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

Configure mod_plsql Settings

The mod_plsql settings are configured in Oracle Enterprise Manager, which can be accessed from Oracle9iAS Portal as follows:

  1. From the Oracle9iAS Portal Design-Time Pages page, click the Administer tab.

  2. In the Services portlet, click Portal Service Monitoring.

  3. Go to the mod_plsql page.

  4. Change the password of the corresponding database user for the PORTAL DAD.

  5. Delete all DADs that you do not need. For example SAMPLE_DAD is unnecessary.

  6. Add a new DAD for the portal you are building, and set the default home page for this DAD. For example:

    <hostname>.<some_domain>.com/<home_page>/<page_name>.htm
    
    
  7. Make the new DAD the default DAD. This redirects the browser to the DAD when the following URL is entered:

    http://<hostname>:<port>/pls

    See Also:

    Oracle9i Application Server mod_plsql User's Guide to find more information about configuring mod_plsql settings.

Safeguard Passwords for Lightweight Oracle9iAS Portal Users

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

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

    • PORTAL

    • PORTAL_ADMIN

    • PUBLIC

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

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

Remove Unnecessary Objects

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

Revoke Public Access to Provider Components

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

Control Access to Administration Pages

In order 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:

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

  1. In the Navigator, click Page Groups.

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

  3. Click the Access tab.

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

  5. When you are done, click OK.

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

  1. In the Navigator, click Page Groups.

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

  3. Click Pages.

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

  5. Click the Access tab.

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

  7. When you are done, click OK.


    Note:

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


Protect Oracle9iAS Portal Monitoring Packages

You must protect the execution of PL/SQL procedures granted to PUBLIC in the database. These procedures pose a security hole when they are executed through a Web browser. For example, some procedures in the dbms_% packages allow access to sensitive information. You can specify which packages to protect with the PlsqlExclusionList directive in the mod_plsql configuration file called dads.conf.

See Also:

"Protecting the PL/SQL Procedures Granted to PUBLIC" for information about how to use the PlsqlExclusionList directive in dads.conf.

In relation to Oracle9iAS Portal, PUBLIC access to the monitoring packages can expose pages that contain sensitive information or degrade system performance because of heavy queries to the portal database. To resolve this, specify some or all of the following packages with the PlsqlExclusionList directive in the dads.conf file:

To ensure the best security, specify the following system default settings with the PlsqlExclusionList directive for each DAD:

PlsqlExclusionList sys.*
PlsqlExclusionList dbms_*
PlsqlExclusionList utl_*
PlsqlExclusionList owa_util.*
PlsqlExclusionList portal.wwmon_*

To test your changes, try to access the following URL without logging in first:

http://<hostname>:<port>/pls/<dad>/portal30.WWMON_CHART_BY_USER.show

This attempt should result in an HTTP 404 error: "It is forbidden to call this procedure from the browser!"


Note:

To run the Oracle9iAS Portal monitor charts, create an extra secretly named DAD with a less restrictive PlsqlExclusionList.


Consider SSL and the Login Portlet

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

Login Portlet Versus Login Page

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

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

See Also:

Oracle9iAS Portal Configuration Guide for a detailed description on how to enable SSL within Oracle9iAS Portal.

Consider LDAP over SSL for Oracle Internet Directory Connections

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

See Also:

Oracle Internet Directory Administrator's Guide in the Oracle9iAS Documentation Library for a detailed description on how to configure the directory for an LDAP port over SSL.

To configure Oracle9iAS Portal to use SSL to connect to the directory, you must run the secupoid.sql script. This script allows you to change the following Oracle9iAS Portal configuration parameters related to the directory:

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

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

PL/SQL procedure successfully completed. 

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

PL/SQL procedure successfully completed. 

No errors.

After executing the script, Oracle9iAS Portal is configured for LDAPS access of the directory.

Change the Application Entity Password

Oracle9iAS Portal never passes a user's password to the directory. Only Oracle9iAS Single Sign-On performs that task. However, Oracle9iAS Portal authenticates itself to the directory through its application entity and password. This account can proxy as any user because it has proxy privileges and thus it is also an account that ought to be protected.

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, Oracle9iAS Portal's application entry is:

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

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

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

See Also:

Directory entries in Oracle Internet Directory for Oracle9iAS Portal for more information about the application entity.

Changing LDAP Settings on the Global Settings Page

Once you have installed Oracle9iAS Portal and performed the appropriate tasks from "Post-Installation Security Checklist" , your Oracle9iAS Portal configuration is secure. From the Global Settings page of Oracle9iAS Portal, you can now change all of the following settings that pertain to security:

Cache for Oracle Internet Directory Parameters

As pointed out in "Portal Security Architecture", Oracle9iAS Portal maintains a cache of information from the directory. From the Global Settings Page, you can refresh this cache with the updated information from the directory. Refresh Cache for the directory parameters immediately updates the cache with the latest parameters values from the directory. The cached information is relatively static information, hence you do not need to refresh the cache frequently.

Oracle Directory Integration Server Synchronization

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

Group creation base DN

Oracle9iAS Portal maintains its user group information in the directory. When groups are created through the Groups 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 Oracle9iAS 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 Oracle9iAS Portal to maintain its user groups. For example:

cn=PORTAL_GROUPS,cn=Groups,o=MyCompany,dc=com

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

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 Oracle9iAS Portal to search for existing groups. For example, you need to specify where Oracle9iAS Portal searches when it displays the groups list of values in the Groups portlet.

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

cn=PORTAL_GROUPS,cn=Groups,o=MyCompany,dc=com

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


1 The default subscriber 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 subscriber name would be o=oracle,dc=com. If the domain name server cannot be determined, the default name assigned by the directory is o=Default Company,dc=com


Go to previous page Go to next page
Oracle
Copyright © 2002 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index