Release 2 (9.0.2)
Part Number A90146-01
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle9i Application Server Security Guide Release 2 (9.0.2) Part Number A90146-01 |
|
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:
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:
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.
As you might expect, based upon the model described in the previous sections, Oracle9iAS Portal administrators need to understand all of the following:
Portal uses Oracle9iAS Single Sign-On for user authentication, as discussed in "User Authentication and Privilege Model".
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:
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:
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.
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.
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.
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:
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:
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).
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:
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. |
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.
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:
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.
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.
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.
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.
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.
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:
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.
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:
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.
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:
| Type of Object | Available Privileges | Inherited Privileges |
|---|---|---|
|
Calendar |
From Database Provider |
|
|
Chart |
From Database Provider |
|
|
Chart |
From Database Provider |
|
|
Data Component |
From Database Provider |
|
|
Data Component Cell |
From Data Component |
|
|
Database Provider |
Not applicable |
|
|
Document |
From page or item |
|
|
Dynamic Page Component |
From Database Provider |
|
|
FormFoot 1 |
From Database Provider |
|
|
Frame Driver |
From Database Provider |
|
|
Hierarchy |
From Database Provider |
|
|
Image Chart |
From Database Provider |
|
|
Link |
From Database Provider |
|
|
List of Values |
From Database Provider |
|
|
Menu |
From Database Provider |
|
|
Oracle9i Reports printer |
From Database Provider |
|
|
Oracle9i Reports report |
From Database Provider |
|
|
Oracle9i Reports Server |
From Database Provider |
|
|
Page |
Not applicable |
|
|
Page group |
Not applicable |
|
|
Page Item |
From page |
|
|
Portlet |
Not applicable |
|
|
Provider |
Not applicable |
|
|
Query by example form |
From Database Provider |
|
|
ReportFoot 2 |
From Database Provider |
|
|
Schema |
Not applicable |
|
|
URL |
From Database Provider |
|
|
XML |
From Database Provider |
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:
Before you can begin to administer Oracle9iAS Portal, you must first understand the default settings that are created during installation.
The tables that follow describe the schemas, users, and groups that are created by default when Oracle9iAS Portal is installed.
|
See Also:
For more information about mod_plsql and how to use it. |
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 |
After Oracle9iAS Portal is installed, you should consider performing the following steps to complete the security configuration:
The mod_plsql settings are configured in Oracle Enterprise Manager, which can be accessed from Oracle9iAS Portal as follows:
PORTAL DAD.
SAMPLE_DAD is unnecessary.
<hostname>.<some_domain>.com/<home_page>/<page_name>.htm
http://<hostname>:<port>/pls
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:
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:
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.
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:
MANAGE ALL to specific users or to certain groups. For example, DBA, PORTAL_ADMINISTRATORS, PORTAL_DEVELOPERS, and your own groups.
To control access to individual administration pages in these page groups, perform the following steps:
MANAGE ALL to specific users or to certain groups. For example, DBA, PORTAL_ADMINISTRATORS, PORTAL_DEVELOPERS, and your own groups.
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 |
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:
WWMON_CHART_BY_ACTION.show
WWMON_CHART_BY_BROWSER.show
WWMON_CHART_BY_DATE.show
WWMON_CHART_BY_IPADDRESS.show
WWMON_CHART_BY_LANGUAGE.show
WWMON_CHART_BY_OBJECT.show
WWMON_CHART_BY_ROWS.show
WWMON_CHART_BY_TIME.show
WWMON_CHART_BY_USER.show
WWMON_CHART_SEARCHES.show
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!"
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.
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.
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.
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.
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.
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. |
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:
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.
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:
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.
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
|
 Copyright © 2002 Oracle Corporation. All Rights Reserved. |
|