10g (9.0.4)
Part Number B10356-01
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle® Application Server Portal Configuration Guide 10g (9.0.4) Part Number B10356-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 OracleAS Portal security in the following topics:
The sections that follow provide an overview of OracleAS Portal security and how it works with the OracleAS Security Framework.
When you make content available on the Web, it is very likely that you need to restrict access to at least some parts of it. For example, it is unlikely that you want every user to be able to see every document on your site. It is even less likely that you want every user to be able to change every document on your site. OracleAS Portal provides a comprehensive security model that enables you to completely control what users can see and change on your Web site.
Before a user logs on to OracleAS Portal, they can only view the content that the content contributors designate as public. Public content can be viewed by any user who knows the URL of a portal object (for example, a page) and can connect to the 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, OracleAS Portal leverages the other components of Oracle Application Server and Oracle9i Database Server to provide strong protection for your portal. OracleAS Portal interacts with all of the following components to implement its security model:
Figure 6-1 illustrates the components and relationships of the OracleAS Portal security architecture.
The OracleAS Portal architecture consists of three basic tiers, including the client browser, the middle-tier server, and the infrastructure servers and repositories. By default, Oracle Internet Directory and OracleAS Single Sign-On are installed on the same host as part of the infrastructure installation. This tier is subsequently used for the OracleAS Portal installation.
While the default installation has all three servers and repositories installed on the same host, we recommend that you install these functions on separate servers.
If you used releases prior to 9.0.2, notice that the middle and infrastructure tier components have changed. The DAD and mod_plsql combination still exists on the infrastructure tier but is now joined by DAS running in Oracle Application Server Containers for J2EE (OC4J). Similarly, the Parallel Page Engine appears on the middle-tier also running in OC4J.
Furthermore, the OracleAS Single Sign-On model has expanded to include the addition of mod_osso, which allows any URL to participate in OracleAS Single Sign-On. Even if the application was not written as a partner application, mod_osso is now the recommended method to introduce third party applications into OracleAS Single Sign-On. Any application capable of reading HTTP headers may avail itself of the OracleAS Single Sign-On capability.
OracleAS Web Cache front ends these middle-tier components and thus optimizes the throughput of OracleAS Portal. When a page request comes from the browser, OracleAS Web Cache takes it. If possible, the page is delivered from the cache. If not, the request goes through to the origin Oracle HTTP Server.
As with Release 1.x, if the requested page is not a public page, the user is challenged for a username and password. This function is still carried out through a redirection to OracleAS Single Sign-On for authentication. (Note that the single sign-on DAD has been renamed to orasso for this release.)
Unlike Release 1.x, OracleAS Single Sign-On does not compare the user credentials against to its own schema tables. It verifies them on the Oracle Internet Directory through LDAP. The credentials are compared to those found within the Directory (LDAP compare) and the result returned to OracleAS Single Sign-On. Upon successful authentication, OracleAS Single Sign-On creates a single sign-on cookie.
Once the user is authenticated and an appropriate OracleAS Portal session created, she may access pages and other objects. It is necessary to determine which pages and objects the user has the necessary privileges to access. As in Release 1.x, the Access Control Lists for all portal objects are held in the OracleAS Portal Repository.
The difference in Release 2 is that all user and group membership information is stored in the Oracle Internet Directory. When a user first logs in to OracleAS Portal, the group memberships of the user are copied to the portal node and cached on that tier. This process allows for fast lookup of object privileges. Once the object and page privileges of the user are known, the Parallel Page Engine can go on to generate the page from the appropriate pieces.
In Release 2, all user provisioning is performed against the Oracle Internet Directory rather than the OracleAS Single Sign-On schema. The interface between the middle-tier and the LDAP server is the DAS servlet. The calls to the DAS servlet 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 the Oracle Internet Directory. The Oracle Directory Integration Platform automatically keeps the locally cached information up to date with changes in the Oracle Internet Directory.
If you need to authenticate against an external repository, the Oracle Internet Directory performs this step rather than OracleAS Single Sign-On server as in Release 1.x. 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.
OracleAS Portal provides a number of user accounts and groups by default.
Table 6-1 describes the user accounts created by default when OracleAS Portal is installed.
Table 6-2 describes the groups created by default when OracleAS Portal is installed.
GroupFoot 1 |
Description |
|---|---|
|
|
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 following privileges: This group is a member of OracleDASCreateGroup. |
|
|
Is a highly privileged group established for Oracle Application Server administrators. Components that are part of Oracle Application Server grant full component-specific privileges to members of this group. The DBA group is a member of the PORTAL_ADMINISTRATORS group. This group is also a member of the following Oracle Application Server privilege groups: |
|
|
Is a highly privileged group established for OracleAS Portal. By default, this group is given the following OracleAS Portal global privileges:
This group is a member of the following Oracle Application Server privilege groups:
Members of PORTAL_ADMINISTRATORS do not have the necessary privileges to administer OracleAS Single Sign-On. If you want members of this group to administer OracleAS Single Sign-On, then you must grant them those privileges as described in the Oracle Application Server Single Sign-On Administrator's Guide. |
|
|
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 following OracleAS Portal global privileges: |
|
|
Is a privileged group established for users who are building portlets. By default, this group is given the following OracleAS Portal global privileges: If you want PORTAL_DEVELOPERS to create database providers and portlets, you need to give this group privileges that enable them to modify schema, for example, Modify Data on all schemas. For more information, refer to Table 6-5. |
|
|
Is the group of users who administer OracleAS Reports Services reports, printers, calendars, and servers. You must assign this group any desired object privileges (For example, Manage). |
|
|
Is the group of users who develop OracleAS Reports Services reports. You must assign this group any desired object privileges (For example, Execute or Manage). |
|
|
Is the group of users who can modify OracleAS Reports Services reports. You must assign this group any desired object privileges (For example, Execute or Manage). |
|
|
Is the group of users who use OracleAS Reports Services reports. You must assign this group any desired object privileges (For example, Execute). |
Within OracleAS 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.
|
See Also:
For information about how you might model privileges, see Section 6.1.6.9, "DAS Public Roles". |
For information about how you might model privileges, refer to the white paper, Strategies for Administering Privileges in OracleAS Portal Release 2, on the Oracle Technology Network, http://otn.oracle.com.
Use global privileges to give a user or group a certain level of privileges on all objects of a particular type.
There are three types of privilege groups:
You can assign access privileges to users or groups for all of the following objects within OracleAS Portal through the Access tab of the object's Edit Page:
| Type of Object | Available Privileges | Inherited Privileges |
|---|---|---|
|
Calendar |
From Database Provider |
|
|
(based on SQL query) |
From Database Provider |
|
|
(based on wizard) |
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 |
|
|
OracleAS Reports Services printer |
From Database Provider |
|
|
OracleAS Reports Services report |
From Database Provider |
|
|
OracleAS Reports Services 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 create and manage Web providers and provider groups through the user interface, as opposed to working with files directly, you need to grant appropriate privileges to the administrative users. The access control list is implemented differently than for the OracleAS Portal repository resident objects described in Section 6.1.3.1, "Global Privileges" and Section 6.1.3.2, "Object Privileges". Rather, the grants for provider privileges are maintained in an XML file.
To grant privileges to create, edit, and delete Web providers or provider groups, you need to manually make changes to the following file:
MID_TIER_ORACLE_HOME/j2ee/OC4J_ Portal/applications/portalTools/providerBuilder/WEB-INF/deployment_ providerui/provideruiacls.xml
An example of this file follows:
<providerui xmlns="http://www.oracle.com/portal/providerui/1.0"> <objectType name="ALL_OBJECTS"> <object name="ANY_PROVIDER" owner="providerui"> <user name="any_provider_manager_user" privilege="500"/> <user name="any_provider_edit_user" privilege="400"/> <user name="any_provider_execute_user" privilege="300"/> <user name="any_provider_create_user" privilege="100"/> </object> <object name="ANY_PORTLET" owner="providerui"> <user name="any_portlet_manage_user" privilege="500"/> <user name="any_portlet_edit_user" privilege="400"/> <user name="any_portlet_execute_user" privilege="300"/> </object> </objectType> <objectType name="PROVIDER"> <object name="TEST_PROVIDER" owner="providerui"> <user name="provider_manage_user" privilege="500"/> <user name="provider_edit_user" privilege="400"/> <user name="provider_execute_user" privilege="300"/> </object> </objectType> <objectType name="PORTLET"> <object name="PORTLET_UNDER_TEST_PROVIDER" owner="TESTPROVIDER"> <user name="portlet_manage_user" privilege="500"/> <user name="portlet_edit_user" privilege="400"/> <user name="portlet_execute_user" privilege="300"/> </object> </objectType> </providerui>
This file allows for granting of the following types of privileges, described in the following sections:
Table 6-7 describes the global object types and corresponding privilege codes that can be granted to users in the provideruiacls.xml file. When granting a privilege to the user, you should specify the numeric privilege code.
To add a privilege to a particular user, add an entry in the proper object type container, for example:
<objectType name="ALL_OBJECTS"> <object name="ANY_PROVIDER" owner="providerui"> <user name="jdoe" privilege="400"/> ... </object> </objectType>
For these global privileges, the objectType name is set to ALL_OBJECTS, the object owner is set to providerui, and the object name should be ANY_PROVIDER or ANY_PORTLET depending on the type of grant you are setting.
You then set the user name and privilege to the values corresponding to the OracleAS Single Sign-On username 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.
Table 6-8 describes the object level privileges that can be granted to users to give them privileges on specific object instances as referenced within the provideruiacl.xml XML file.
To add a privilege to a particular user, add an entry into the proper object type container, for example:
<objectType name="PORTLET"> <object name="PORTLET_UNDER_TEST_PROVIDER" owner="TESTPROVIDER"> <user name="jdoe" privilege="400"/> ... </object> </objectType>
For the object level privileges, the objectType name is set to PROVIDER or PORTLET, depending upon to which object instances you are providing access. The object name is set to the provider name or the portlet name, respectively. The object owner is set to providerui or the name of the associated provider, again respectively for providers and portlets.
Table 6-9 summarizes these rules:
To create and edit URL and XML portlets in the Portlet Repository, privileges need to be granted to the users. The URL and XML portlets are available from the Portlet Builders page in the Portlet Repository. To grant access, you need to manually make changes to following file:
MID_TIER_ORACLE_HOME/j2ee/OC4J_Portal/applications/jpdk/jpdk/WEB-INF/ deployment_providerui/provideruiacls.xml
The privileges are identical to those described earlier in Section 6.1.3.3, "Privileges to Create and Edit Web Providers and Provider Groups".
When users attempt to log in to OracleAS Portal, OracleAS Single Sign-On must first verify their credentials against the directory. Once their identity has been verified, OracleAS Portal checks their access privileges in the directory to determine which objects they may see and use within the portal.
OracleAS Portal leverages Oracle Application Server Security Services in the following ways:
To provide a more comprehensive security solution, OracleAS Portal takes advantage of a variety of components in the Oracle Identity Management infrastructure:
OracleAS Portal also takes advantage of Oracle Identity Management when it creates users and groups. The most common way to create users and groups, and set global privileges and preferences for your portal is through the following portlets:
See Also:
OracleAS Portal uses OracleAS Single Sign-On for user authentication, as discussed in Section 6.1.4, "Authorization and Access Enforcement".
|
Note: OracleAS Portal Release 3.0.9.8.4 or later can be used with OracleAS Single Sign-On Release 9.0.Foot 1 You cannot use versions older than Release 3.0.9.8.4 with OracleAS Single Sign-On 9.0. |
|
1
Refers to the release of OracleAS Single Sign-On that ships with Oracle Application Server Release 2. |
OracleAS Single Sign-On manages the Single Sign-On sessions of users. In order for single sign-on security to function properly with OracleAS Portal, the following tasks must be completed:
The Oracle Universal Installer performs these two configuration steps for you upon installation. If you need to make changes to your configuration after installation, you can do so by:
ptlasst.csh (UNIX) or ptlasst.bat (MS Windows) with -mode MIDTIER -type SSO. This procedure adds OracleAS Portal as a partner application to an existing OracleAS Single Sign-On installation. To work correctly, you must already have installed OracleAS Portal and OracleAS Single Sign-On, and created their DADs.
The ptlasst scripts and their documentation are located in MID_TIER_ORACLE_HOME/assistants.
Oracle Internet Directory is Oracle's highly scalable, native LDAP version 3 service and hosts the Oracle common user identity. As stated in the previous section, OracleAS Portal queries the directory to determine a user's privileges and what they are entitled to see and do in the portal. In particular, OracleAS Portal retrieves the group memberships of the user from the directory to determine what they may access and change.
Given this model, OracleAS Portal requires the following interactions with Oracle Internet Directory:
In order for security to function properly, OracleAS Portal requires the following entries in the directory's Directory Information Tree (DIT) structure:
For Release 10g (9.0.4) of OracleAS Portal, the name of the group container is derived from the following in OracleAS Portal:
The format of the name is:
schema_name.yymmdd.hhmi
For Release 9.0.2.6 of OracleAS Portal, the name of the group container is derived from the following in OracleAS Portal:
For example, if the schema name is PORTAL, SID is iasdb, and the hostname is host1.abc.com then the name of the group container is cn=PORTAL.iasdb.host1.abc.com.
Figure 6-2 shows where the OracleAS Portal information is located in the directory's DIT structure.
OracleAS Portal, like all other components of Oracle Application Server, relies upon the directory to store user information. All users in the directory are defined using the following object classes:
The subsequent tables show the various user attributes stored in Oracle Internet Directory. A complete list of these attributes is available in IETF RFC 2798.
For users who are familiar with the user properties from previous versions of OracleAS Portal, the following table maps the old user properties to the new Oracle Internet Directory attributes.
OracleAS Portal, like all other components of Oracle Application Server, relies upon the directory to store group information. All groups in the directory are defined using the following object classes:
groupOfUniqueNames object class contains all of the group attributes defined by IETF (RFC 2256).
Figure 6-3 shows where the OracleAS Portal information for groups is located in the directory's DIT structure.
The subsequent tables show the various group attributes stored in Oracle Internet Directory:
For users who are familiar with the group properties from previous versions of OracleAS Portal, the following table maps the old user properties to the new Oracle Internet Directory attributes:
To improve performance, OracleAS Portal caches some directory information locally. In particular, OracleAS Portal caches the following:
The majority of the information cached by OracleAS Portal is fairly static (for example, directory connection information). For those items that are more dynamic, such as group memberships and default group, OracleAS Portal relies upon the Directory Synchronized Provisioning agent for updates. OracleAS Portal maintains a directory synchronization subscription in the directory that flags the agent to notify it of any change events that affect OracleAS Portal security (for example, adding or deleting a user from a group).
The User, Group, Portal User Profile, and Portal Group Profile portlets include lists of values for users or groups. These lists of values must be populated with information stored in the directory. By default, the list of values displays the groups contained under the OracleAS Portal group container in the OracleAS Portal DIT structure. You can, however, browse to any group in the tree to which you have access from the list of values.
The groups that are displayed in the list of values for groups depend on the privileges of the user viewing them. For example, if a user views the list of values from the Group portlet, the list only displays those groups that can be edited or deleted by that user.
In some cases, you may encounter problems in rendering these user and group lists of values. You can resolve these problems in one of two ways:
If you have your directory and OracleAS Portal servers residing in different domains, you must explicitly set the JavaScript domain for OracleAS Portal such that it can resolve user and group lists of values. For example, suppose that your installation has OracleAS Portal configured to use a different Oracle HTTP Server than the DAS. 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 DAS to the page displayed by OracleAS Portal.
To create a single domain in this case, do the following:
secjsdom.sql <domain_name>
where <domain_name> is something like abc.com.
Performing this procedure enables you to run directory lists of values from OracleAS Portal in either Netscape or Microsoft Internet Explorer. For more information about secjsdom.sql, refer to Section C.4, "Using the secjsdom.sql Script".
|
See Also:
Section 6.3.2.3.4, "Group Search Base Distinguished Name (DN)" for information about choosing where OracleAS Portal searches for groups. |
In the preceding section, Defining a Common JavaScript Domain for DAS Lists of Values, we described how to create a single domain for DAS lists of values using secjsdom.sql. In some cases, creating a single domain with secjsdom.sql is not sufficient to resolve the JavaScript cross-domain scripting restrictions. In these situations, listed subsequently, you may need to deploy DAS on OracleAS Portal's middle-tier:
To avoid the issues of cross-domain scripting and browser restrictions with support of the common domain directives in JavaScript, you can install DAS directly on the OracleAS Portal middle-tier. In this way, DAS can be used to support the lists of values that need to write values back to the OracleAS Portal forms. Implementing this configuration involves the following high-level steps:
MID_TIER_ORACLE_HOME/dcm/bin directory.
MID_TIER_ORACLE_HOME/dcm/bin/dcmctl createcomponent -verbose -debug -ct oc4j -co OC4J_SECURITY
MID_TIER_ORACLE_HOME/dcm/bin/dcmctl start -verbose -debug -co OC4J_SECURITY
oiddas.ear file using the following command:
MID_TIER_ORACLE_HOME/dcm/bin/dcmctl deployApplication -debug -verbose -a oiddas -f ORACLE_HOME/ldap/das/oiddas.ear -co OC4J_SECURITY
opmn.xml file:
MID_TIER_ORACLE_HOME/opmn/conf directory and open opmn.xml in a text editor.
opmn.xml:
For a UNIX environment:
<environment> <variable id="DISPLAY" value="localhost:0.0"/> <variable id="LD_LIBRARY_PATH" value="MID_TIER_ORACLE_HOME/lib"/> </environment>
For a Windows environment:
<environment> <variable id="PATH" value="MID_TIER_ORACLE_HOME\\bin"/> </environment>
Replace hostname and MID_TIER_ORACLE_HOME with the appropriate values. Note the following example in the OC4J_SECURITY section of opmn.xml (MS Windows environment) :
<process-type id="OC4J_SECURITY" module-id="OC4J"> <environment> <variable id="PATH" value="D:\\oracle\\bin"/> </environment> <module-data> <category id="start-parameters"> ..... ..... </category> </module-data> <start timeout="3500" retry="2"/> <stop timeout="120"/> <restart timeout="720" retry="2"/> <port id="ajp" range="3301-3400"/> ..... ..... <process-set id="default_island" numprocs="1"/> </process-type>
MID_TIER_ORACLE_HOME/dcm/bin directory.
MID_TIER_ORACLE_HOME/dcm/bin/dcmctl updateconfig -verbose -debug -ct opmn
MID_TIER_ORACLE_HOME/dcm/bin/dcmctl restart -verbose -ct opmn
MID_TIER_ORACLE_HOME/dcm/bin/dcmctl stop -verbose -debug -ct oc4j -co OC4J_SECURITY MID_TIER_ORACLE_HOME/dcm/bin/dcmctl start -verbose -debug -ct oc4j -co OC4J_SECURITY
orclApplicationCommonName=OracleAS_instance_name,cn=IAS Instances,cn=IAS,cn=Products,cn=OracleContext) to the group entry under the DAS application that defines the associated middle-tiers.
To perform this step, do the following:
cn=IAS Instances,cn=IAS,cn=Products,cn=OracleContext
For example:
orclApplicationCommonName=OracleAS_instance_name,cn=IAS Instances,cn=IAS,cn=Products,cn=OracleContext
uniquemember attribute of the following entry:
cn=Associated Mid-tiers,orclApplicationCommonName=DASApp,cn=DAS, cn=Products,cn=OracleContext
http://midtier_hostname:port_number/oiddas
where midtier_hostname is the name of the computer on which the Oracle HTTP Server is running and port_number is the corresponding http port number. This URL should display the DAS home page.
After you manually deploy and configure DAS on OracleAS Portal's middle-tier, you need to set the configuration setting that instructs OracleAS Portal to render the DAS list of values links as OracleAS Portal middle-tier URLs rather than using the DAS base URL value from Oracle Internet Directory. You do this step by running secdaslc.sql.
MID_TIER_ORACLE_HOME/portal/admin/plsql/wwc and make it your current working directory.
@secdaslc.sql Y commit; exit;
At this point, OracleAS Portal is configured to invoke DAS lists of values from the OracleAS Portal middle-tier. All other DAS operations will continue to be invoked on the infrastructure instance of DAS. The OracleAS Portal middle-tier based lists of values will not have any issues with cross-domain scripting problems.
As shown in Figure 6-4, the Oracle Directory Integration Platform provides important services to notify components of user and group change events and synchronize directories.
In the figure, the flow to and from the Oracle Internet Directory has two paths. The first path, labeled Oracle Directory Synchronization Service, illustrates 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, illustrates the concept of provisioning. In provisioning, an application, such as OracleAS Portal, subscribes to changes to certain user or group information. For example, suppose that an administrator removes a user from a group through the DAS. As a result of this change, the user should no longer be allowed to access certain pages in OracleAS Portal. The Oracle Directory Integration Platform must notify OracleAS Portal to update its local cache and immediately prevent the user from accessing the pages to which she no longer should have access.
For provisioning services, components like OracleAS Portal subscribe to provisioning events (for example, deletion of a group) in order to keep their local caches of user and group information synchronized with the central user and group repository in the Oracle Internet Directory. When a change event occurs, all of the components that are subscribed to that change event are notified by the Directory Synchronized Provisioning agent of the Oracle Directory Integration Platform. OracleAS Portal sets the Portal directory synchronization subscription flag in the directory to indicate that it should be notified whenever a subscribed change event takes place. Table 6-16 shows the events to which OracleAS Portal subscribes and the actions it takes when those events occur:
In order to function properly, OracleAS Portal requires the following for its integration with Oracle Directory Integration Platform:
oidctl command, for example:
oidctl instance=1 server=odisrv flags="host=iasqa-ultra1.abc.com port=4032" start
By default, groups created in the Oracle Internet Directory by the DAS 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.
If you need to change the subscription profile, we recommend you first delete the old subscription profile with this command:
ptlasst.csh -mode MIDTIER -type DIPUNREG
And then re-create a new subscription profile with this command:
ptlasst.csh -mode MIDTIER -type DIPREG
Only perform these operations during periods of downtime or no activity, so that changes pending in the change log are not lost as a result of deleting the old profile and starting the new one.
Details of the MIDTIER mode types DIPREG and DIPUNREG used to create/drop the Oracle Directory Integration Platform subscription profiles are as follows:
DIPREG
ptlasst.csh -i custom -mode MIDTIER -type DIPREG -s <portal_schema> -c <portal_ connect_string> -ldap_h <oid_host> -ldap_p <oid_port> -ldap_d <oid_admin_dn> -ldap_w <oid_admin_password> -silent -verbose
DIPUNREG
ptlasst.csh -i custom -mode MIDTIER -type DIPUNREG -s <portal_schema> -c <portal_connect_string> -ldap_h <oid_host> -ldap_p <oid_port> -ldap_d <oid_ admin_dn> -ldap_w <oid_admin_password> -silent -verbose
The resulting subscription profile will correctly subscribe to modifications and deletions for both types of group.
In addition to querying the directory for user and group information, OracleAS Portal must provide users with the means to add and modify user and group information. To change information in the directory, use the DAS. OracleAS Portal provides links to the delegated administration server for users with the privileges to add and change users and groups.
The DAS provides a comprehensive interface for making updates to the directory. Authenticated users who have the appropriate privileges can access the delegated administration server through the User and Group portlets on the Administration tab in OracleAS Portal. To access these portlets, a user must be a member of the OracleDASCreateUser and OracleDASCreateGroup groups, respectively. The PORTAL and PORTAL_ADMIN users are members of both of these groups by default. AUTHENTICATED_USERS may also create groups by default.
mod_osso protects URLs behind the OracleAS Single Sign-On environment by making the HTTP server effectively into a partner application. DAS 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, including OC4J applications, for single sign-on. You achieve this by configuring mod_osso with Oracle HTTP Server directives to restrict access to the OC4J application URLs.
DAS is implemented as an OC4J application, which relies on mod_osso to authenticate users attempting access. When a user attempts to access a DAS 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:
Once the user has been properly authenticated, they are redirected by mod_osso to the requested DAS URL. DAS then becomes accessible to the user and enforces the user's privileges, typically relying on access control items in the Oracle Internet Directory.
The first request to DAS from a user session in OracleAS Portal is redirected to the OracleAS Single Sign-On so that mod_osso, which acts as a partner application on behalf of DAS, can establish the identity of the user. OracleAS Single Sign-On constructs a URLC token that includes the requested DAS URL. There is about a 2K limit on the length of the URLC token imposed by Internet Explorer. As such, the length of the DAS URL is also limited. In order to provide a seamless integration with DAS, OracleAS Portal includes the URLs of the current portal page and the portal home page within this DAS URL. A typical DAS URL appears as follows:
http://myportal.us.abc.com:7777/oiddas/ui/oracle/ldap/das/group/AppCreateGroupIn foAdmin?doneURL=https%3A%2F%2Fwebsvr.us.oracle.com%3A5001%2Fportal%2Fpage%3F_ pageid%3D6%2C1%2C6_12%3A6_18%26_dad%3Dportal_9_0_2_6_7%26_schema%3DPORTAL_9_0_2_ 6_7&homeURL=https%3A%2F%2Fwebserver.us.abc.com%3A5001%2Fportal%2Fpage%3F_ pageid%3D6%2C1%2C6_12%3A6_18%26_dad%3Dportal_9_0_2_6_7%26_schema%3DPORTAL_9_0_2_ 6_7&parentDN=cn%3Dportal_9_0_2_6_ 7.s901dev0.portalserver.us.abc.com%2Ccn%3Dgroups%2Cdc%3Dus%2Cdc%3Doracle%2Cdc%3D com&enablePA=true
When this URL is included in the URLC token, which is then encrypted for security reasons, the length of the resulting token easily approaches the 2K threshold. If it exceeds this limit, the browser may show an error.
There is no fixed size for the URL. However, if you see browser errors when performing DAS operations, you should consider reducing the size of various parts that comprise the portal URL as this will help ensure that the URL doesn't 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 login to DAS first through a shorter URL, such as the Directory Administration link in the Services portlet. Any subsequent access to DAS will then not require SSO redirection, and will succeed.
The User portlet on the Portal tab under Administration enables you to create and update users through DAS. To create a new user, click the Create New Users 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 Portal tab under Administration enables you to create and update user groups through DAS. To create a new group, click the Create New Groups 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:
In many cases, it is more efficient to use DAS roles to assign privileges rather than the more granular, per-user approach. When creating users, you might notice a section called Roles Assignment on the Create User page, shown in Figure 6-10.
Roles provide a very convenient mechanism by which users can be created and granted a set of privileges simultaneously. When a check box for a role is checked for a given user, they are granted the designated role upon creation. As an administrator, you can create your own roles and pre-assign any combination of Oracle Internet Directory and OracleAS Portal privileges to them.
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:
You begin by creating a group in the usual manner:
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.
Now that you have created a group representing the user administrator role, you need to enable it as a role so it appears in the list of roles on the Create User page.
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. In order to implement this change, you need to update a configuration entry in the OracleAS Portal repository. This setting stops DAS from displaying the Privilege Assignment section in the Create/Edit User page when it is called from an OracleAS Portal administration page.
das_enable_pa variable in OracleAS Portal's Oracle Internet Directory configuration preference store.
$ sqlplus ... Enter user-name: portal Enter password: ... SQL> set serverout on SQL> exec wwsec_oid.set_preference_value('das_enable_pa', 'N'); PL/SQL procedure successfully completed. SQL> commit; Commit complete. SQL> exit ...
secupoid.sql and specifying options to update the cache.
Once you have performed steps 1 through 4, go to the Create User page to verify that your user administrator group appears there. Note how the other OracleAS Portal administrative roles, or groups, are already pre-seeded into the Roles Assignment list on this page.
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. Since portlets format information for display on a Web page, the underlying application need not be Web enabled to be integrated with OracleAS Portal.
In OracleAS Portal, portlets are managed by providers. A provider is an application that you register with OracleAS Portal. OracleAS Portal supports two types of providers:
Portlet security consists of three major areas of functionality:
In order 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.
When a user first logs in to OracleAS Portal, they must enter their password to verify their identity before being permitted access. OracleAS Single Sign-On manages the login process. Refer to Section 6.1.7.4, "Single Sign-On" for more information.
Authorization determines whether a particular user should view or interact with a portlet. There are two types of authorization checks:
Authentication and authorization are important components of securing your Web providers. They do not, however, check the authenticity of messages being received by a provider and are therefore not suitable on their own for securing access to a provider. If the communication is unsecured, someone could imitate OracleAS Portal and fool the Web provider into returning sensitive information.
Communication security focuses on securing communications between OracleAS Portal and a 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 restricts access to a provider to a small number of recognized machines. 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.
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.
Message encryption relies on the use of the HTTPS protocol for communication between the provider and OracleAS Portal. Messages are strongly encrypted to protect the data therein. While encryption provides a high level of security, it also of necessity impacts performance.
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 is not confidential (that is, public), 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:
A partner application shares the same OracleAS Single Sign-On as OracleAS Portal for authentication. Sharing OracleAS Single Sign-On instances means that when a user is already logged into OracleAS Portal, their identity can be asserted to the partner application without logging in again.
Partner applications tightly integrate with OracleAS Single Sign-On. When a user attempts to access a partner application, the partner application delegates the authentication of the user to OracleAS Single Sign-On. Once authenticated with a valid username and password, a user need not provide a username 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.
Partner application providers expose portlets that integrate a partner application's content with OracleAS Portal. The partner application provider trusts OracleAS Portal to authenticate the user on the provider's behalf. This relationship is possible because OracleAS Portal is, itself, a partner application.
Partner application providers must trust OracleAS Portal to authenticate the user in this way because the provider cannot perform the authentication itself. Authenticating the user directly requires the provider to redirect the browser to OracleAS Single Sign-On and provide success and failure URLs. This method is not possible due to the provider architecture. The primary reason for it is that the authentication occurs in response to an API call from OracleAS Portal to the provider. OracleAS Single Sign-On cannot imitate that call upon successful authentication to the initSession()/dologin() method to complete its normal processing.
Authentication of users in partner applications differs 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 username and password. The login page submits the username and password back to tOracleAS 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. The contents may be encrypted using the Single Sign-on SDK. 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. To secure the application session cookies, the content may be encrypted using the Single Sign-On SDK.
You make an application a partner application through either of the following mechanisms:
mod_osso is a general purpose Oracle HTTP Server module and a partner application of OracleAS Single Sign-On. It uses OracleAS Single Sign-On to do the authentication. The module does all the communication and handling of cookies between the Oracle HTTP Server and OracleAS Single Sign-On. If mod_osso is configured to protect the URLs of a Web application, then the application effectively becomes a partner application.
OracleAS Portal is also a partner application and uses OracleAS Single Sign-On to authenticate users. Provided OracleAS Portal and mod_osso use the same OracleAS Single Sign-On instance, the user can access either the Web application or OracleAS Portal by logging into either one, that is, they need only login once to be able to access both the Web application and OracleAS Portal.
The Single Sign-On SDK enables programmers to integrate their application with OracleAS Single Sign-On. This SDK consists of a number of database packages that communicate with OracleAS Single Sign-On when an application wants to authenticate a user. These packages make an application a partner application. It also includes methods to encrypt/decrypt information, which are used to secure information stored in the application cookie. The Single Sign-On SDK also has Java class wrappers to the PL/SQL packages, which enable Java applications to become either partner or external applications.
OracleAS Portal is a partner application and uses OracleAS Single Sign-On to authenticate users. Provided OracleAS Portal and the Single Sign-On SDK are configured to use the same OracleAS Single Sign-On instance, the user can access either OracleAS Portal or the application by logging into either one, that is, they need only login once to be able to access both the Web application and OracleAS Portal.
An External Application is an application that uses a different authentication mechanism than OracleAS Portal. The application may use a different instance of OracleAS Single Sign-On than the used by OracleAS Portal or some other authentication method. In either case, OracleAS Single Sign-On stores user name mappings, passwords, and any other required credentials to authenticate the user in each external application. When a user is already logged into OracleAS Portal, they will be logged into the external application without having to type in their username or password.
Applications that manage their own authentication of users can be loosely integrated with OracleAS Single Sign-On by registering as external applications. An external application can be exposed as a provider using the Oracle Application Server Portal Developer Kit so that it may be accessed from a portlet on a page. External application providers are only available to Web providers.
|
See Also:
For more information about the External Applications portlet, see Oracle Application Server Portal User's Guide. |
When a previously authenticated user accesses an external application for the first time, OracleAS Single Sign-On attempts to authenticate the user with the external application. The authentication is performed by submitting an HTTP request that combines the registration information and the user's username and password for the application. If the user has not yet registered their username 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 username and password for an external application, OracleAS Single Sign-On maps the new username and password to the user's OracleAS Portal username and stores them. The next time the user needs to access the external application the stored credentials are used.
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.
When you login to OracleAS Portal, OracleAS Single Sign-On authenticates you. OracleAS Portal then uses Access Control Lists (ACLs) to determine if you are authorized to view each piece of content, including providers and portlets. If you do not belong to a group that has been granted a specific privilege, OracleAS Portal prevents you from performing the actions associated with that privilege.
ACLs are managed by the following:
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.
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 username may be passed in, even a fictitious, unauthenticated one.
A provider can implement two portlet security methods:
These methods have access to the following information about authorization level:
Portlets can also access the OracleAS Portal user privileges and group memberships:
With portlet security methods, you can have a portlet produce different output depending on the user's level of authorization.
Most security manager implementations use the authorization level or some other user specific element in an incoming message. A check of this type could be bypassed by an entity imitating OracleAS Portal.
One way you can prevent unauthorized access to providers is to restrict access to the provider to known client machines at the server level. This method goes some way towards 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.
The Oracle Application Server Portal Developer Kit supports message authentication to limit access to a specified provider instance or group of provider instances. A provider is registered with a secret shared key known only to the Portal and provider administrators.
An OracleAS Portal instance sends a digital signature, calculated using a Hashed Message Authentication Code (HMAC) algorithm, with each message to a provider. A provider may authenticate the message by checking the signature with its own copy of the shared key. This technique may be used in SSL communication with a provider instead of client certificates.
An OracleAS Portal instance calculates a signature based on user information, a shared key, and a time stamp. The signature and time stamp are sent as part of the SOAP message. The time stamp is based on UTC (coordinated universal time, the scientific name for Greenwich Mean Time) so that time stamps can be used in messages between computers in different time zones.
When the provider receives this message it will generate its own copy of the signature. If the signatures agree, it will then compare the message time stamp with the current time. If the difference between the two is within an acceptable value the message is considered authentic and processed accordingly.
A single provider instance cannot support more than one shared key. Multiple keys could cause security and administration problems if several clients sharing a provider use the same key. For instance, if one copy of the shared key is compromised in some way, the provider administrator has to create a new key, distribute it to all of the clients, and the clients must then update their provider definition. The way around this issue is to deploy different provider services, specifying a unique shared key for each service. Each provider service has its own deployment properties file so that each service is configured independently of the others. The overhead of deploying multiple provider services within the same provider adapter is relatively small.
If a provider does not have an OracleAS Web Cache in front of it, the use of the same signature cookie over the lifetime of a provider session means you must trade off between performance and the security provided by authenticating the requests. The signature cookie value is calculated only once after the initial SOAP request establishes the session with the provider. The shorter the provider session timeout, the more often a signature will be calculated to provide greater security against an illegal show request. However, the SOAP request required to establish a session takes more time.
In a provider that uses OracleAS Web Cache to cache show request responses, you make a similar trade-off. Cached content is secured in the sense that incoming requests must include the signature cookie to retrieve the cached content, but caching content for an extended period of time leaves the provider open to illegal show requests.
The signature element provides protection against interception and the resending of messages, but it does nothing to prevent the interception and reading of message contents. Messages are still transmitted in plain text. If you are concerned about the content of messages being read by unauthorized people, you should use message authentication in conjunction with SSL.
Message authentication ensures that the message received by a provider comes from a legitimate OracleAS Portal instance.
Normal communication between OracleAS Portal and a provider uses HTTP, a network protocol that transmits data as plain text using TCP as the transport layer. An unauthorized agent can read an intercepted message. HTTPS uses an extra security layer (SSL) on top of TCP to secure communication between a client and a server.
Each entity (for example, an OracleAS Web Cache instance) that receives a communication using SSL has a freely available public key and a private key known only to the entity itself. Any messages sent to an entity are encrypted with its public key. A message encrypted by the public key may only be decrypted by the private key so that even if a message is intercepted it cannot be decrypted.
Certificates are used to sign communications, thereby ensuring that the public key does in fact belong to the correct entity. These certificates are issued by trusted third parties known as Certification Authorities (CA), for example, Verisign. They contain an entity's name, public key, and other security credentials. They are installed on the server end of an SSL communication to verify the identity of the server. Client certificates may also be installed on the client to verify the identity of a client, but this feature is not yet supported OracleAS Portal. Message authentication may be used instead.
Oracle Wallet Manager is the application used to manage public key security credentials. It is used to generate public/private key pairs, create a certificate request to a CA, and then install the certificate on a server.
When a provider is registered from an OracleAS Portal instance, only one URL is entered. HTTP or HTTPS may be used, but not a combination of both.
Each port on each server that may be used to receive SSL messages must have a server side certificate installed, that is, the OracleAS Web Cache instance (if any) in front of the Web provider and the server which hosts the provider. The certificate installed on a server port ensures that communication between two points is encrypted, but it does not authenticate the source of a message. Message authentication should be used as well to fully secure communication between a trusted OracleAS Portal instance and a provider.
You'll find additional information on security for your Web providers in the papers:
on Portal Center, http://portalcenter.oracle.com. Click the Search icon in the upper right corner of any Portal Center page.
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 only has view 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.
Appendix I, "Administering Web Clipping" 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:
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.
The shipped ca-bundle.txt 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:
ca-bundle.crt file with that file.
For more information about Oracle Wallet Manager, see Chapter 17 "Using Oracle Wallet Manager" in Oracle Advanced Security Administrator's Guide in the Oracle9i Release 2 (9.2) documentation section on the Oracle Technology Network, http://otn.oracle.com.
The Web Clipping Provider can use Oracle Advanced Security Option (ASO) to secure and encrypt the channel between itself (at the middle-tier) and the database that hosts the Web Clipping Repository. As ASO is a feature available only on Oracle Application Server Enterprise Edition, or as an add-on option to the Standard Edition, this feature is disabled by default. To enable it, you must 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 the Repository Settings section of the Edit Provider: webClipping page, select the enable (secure database connections) option in the Advanced Security Option field, then select OK to save the settings and return to Web Clipping Provider test page.
In addition, you must set the following ASO configuration parameters in the sqlnet.ora file to ensure that the database connections created between the Web Clipping Provider and the database hosting the Web Clipping Repository are using ASO. See the Oracle Advanced Security Administrator's Guide for the list of values to use as all possible combinations of parameters are described in detail.
SQLNET.AUTHENTICATION_SERVICES -- This parameter is used to select a supported authentication method in making database connections with ASO. See Oracle Advanced Security Administrator's Guide for more information about setting this parameter.
SQLNET.CRYPTO_SEED -- This parameter denotes the cryptographic seed value (FIPS 140-1 setting), used in making database connections with ASO.
See the Oracle Advanced Security Administrator's Guide for more information about setting this parameter.
The Federated Portal Adapter is a component of OracleAS Portal that allows portal instances to share their portlets through the Web portlet interface. For example, suppose that a user displays a page in one portal instance that contains a portlet whose source resides on another portal instance. When the Federated Portal Adapter on the remote portal receives the request for the portlet, it starts a session for the user on the remote portal. The portlet can then be run from the remote portal instance by the user. This scenario has a couple of security implications:
You'll find additional information in the article "How to Add Remote Portlets Using the Federated Portal Adapter," on Portal Center, http://portalcenter.oracle.com. Click the Search icon in the upper right corner of any Portal Center page.
WebDAV (World Wide Web Distributed Authoring and Versioning) is the IETF's standard for collaborative authoring on the Web. It defines a set of extensions to HTTP that facilitates collaborative editing and file management between users located remotely from each other on the Internet.
OraDAV, Oracle's implementation of WebDAV, is the mechanism used by the Oracle HTTP Server to communicate with WebDAV clients. OraDAV enables your users to connect to OracleAS Portal using their WebDAV clients. In terms of security, accessing OracleAS Portal through WebDAV presents two security issues for you to consider:
The OraDAV configuration parameter, ORACookieMaxAge, specifies, in seconds, the length of time for which the DAV client should retain the cookie. The default value is 28800 (that is, 8 hours).
ORACookieMaxAge can be changed in Oracle Enterprise Manager or by directly editing it in the oradav.conf file located in MID_TIER_ORACLE_HOME/Apache/oradav/conf. If you choose to manually change the file, you must synchronize the changes with Dynamic Configuration Management. Once the change has been made in the configuration file, you need to restart the Oracle HTTP Server to have the changes take effect in the runtime system:
cd MID_TIER_ORACLE_HOME/dcm/bin ./dcmctl shell - dcmctl> updateConfig -ct ohs
After you exit the dcmctl shell, execute the following command from MID_TIER_ORACLE_HOME\opmn\bin to restart the Oracle HTTP Server:
opmnctl restartproc type=ohs
Access to OracleAS Portal through OraDAV using SSL was not certified for Oracle Application Server Release 2 (9.0.2). In Release 2 (9.0.4), SSL access is certified.
This section describes considerations for:
For OracleAS Portal, the main consideration when configuring the OracleAS Security Framework is how to properly configure SSL. For a full description of SSL configuration for OracleAS Portal, refer to Section 6.3.2.1, "Configuring SSL for OracleAS Portal".
As you configure OracleAS Portal for security, you should consider the following topics related Oracle Identity Management:
When deciding on the Directory Information Tree structure and the setting of the Oracle Context parameters for your Oracle Identity Management Infrastructure, you should consider making the naming attribute different from the nickname attribute. The naming attribute is used for the first attribute in the entry's Distinguished Name. By contrast, the nickname attribute holds the OracleAS Single Sign-On user name.
For OracleAS Portal to properly support renaming users by changing the value of the nickname attribute in the Oracle Internet Directory, the nickname attribute must be different than the naming attribute. By keeping the two separate, the Distinguished Name of the user's entry in the Oracle Internet Directory remains unchanged even when the value of the nickname attribute changes.
In previous releases of OracleAS Portal, the super user, PORTAL, was able to perform OracleAS Single Sign-On administration. With OracleAS Portal Release 9.0.4, the ability to perform OracleAS Single Sign-On administration out of the box is removed. The rationale for this change is that in enterprise settings it is not necessarily appropriate for an OracleAS Portal administrator to have permissions to perform Oracle Internet Directory and OracleAS Single Sign-On administration. Much like the discussion in the previous section, regarding the roles of the centralized Oracle Identity Management Infrastructure administrator and the departmental OracleAS Portal administrator, it may be inappropriate for the OracleAS Portal administrator to have the permissions to perform OracleAS Single Sign-On administration.
If you need to allow the OracleAS Portal account to perform OracleAS Single Sign-On administration, you need to explicitly give the user the privilege. This procedure can be done for each Identity Management Realm, or at the root Oracle Context level.
This section describes configuration considerations for OracleAS Portal.
When you install OracleAS Portal, the installation process installs some default schemas of which you need to be aware.
Table 6-17 describes the schemas created by default when OracleAS Portal is installed.
| Schema | Description |
|---|---|
|
|
Contains the OracleAS Portal 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 uses N-Tier authentication to connect to the schema to which the lightweight user accounts are assigned (by default, PORTAL_PUBLIC). As shown in Figure 6-11, access to the database of the portal user is proxied through the single schema user. By default, this entry is named something like The default name for this schema in a standard OracleAS Portal installation is PORTAL. If you want to give it another name, you must perform a custom installation. |
|
|
Is the schema that all lightweight users are mapped to by default. All procedures publicly accessible through the Web are granted execute to PUBLIC, which makes them accessible through this schema. In a standard OracleAS Portal installation, this schema is named PORTAL_PUBLIC. If you want to give it another name, you must perform a custom installation. |
|
|
Is created to hold some demonstration code. The installation of this schema is optional. |
|
|
Is used for external JSP application authentication. |
When configuring OracleAS Portal, you should consider the following options that leverage the OracleAS Security Framework.
The sections that follow provide an overview of the most common SSL configurations for OracleAS Portal and describe the procedures necessary to implement them:
OracleAS Portal uses a number of different components (such as the Parallel Page Engine, Oracle HTTP Server, and OracleAS Web Cache) each of which may act as a client or server in an HTTP communication. As a result, each component in OracleAS Portal's middle-tier must be configured individually for the protocols of HTTPS rather than HTTP.
Interacting with OracleAS Portal involves a number of distinct, "network hops." These include:
Internal and external JSPs do not work with the Parallel Page Engine in a partial SSL configuration mode. They will work when SSL is used throughout OracleAS Portal or when SSL is implemented externally with a load balancing router. As a result, you should only use JSPs with the SSL configurations described in Section 6.3.2.1.2, "SSL to OracleAS Single Sign-On", Section 6.3.2.1.4, "SSL Throughout OracleAS Portal", and Section 6.3.2.1.5, "External SSL with Non-SSL Within Oracle Application Server".
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.
To configure this option, refer to Enabling SSL in Chapter 9, Advanced Configurations, of the Oracle Application Server Single Sign-On Administrator's Guide. If you are going to configure OracleAS Single Sign-On behind a reverse proxy server, you should refer to Deploying OracleAS Single Sign-On with a Proxy Server in Chapter 9, Advanced Configurations, of the Oracle Application Server Single Sign-On Administrator's Guide.
|
Note:
In the previously described configuration of SSL, you must re-register the OracleAS Single Sign-On middle-tier partner application. Since 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 Refer to the section titled "Registering mod_osso" in Chapter 4 of the Oracle Application Server Single Sign-On Administrator's Guide for more information. |
After enabling SSL on OracleAS Single Sign-On following the steps listed in the Oracle Application Server Single Sign-On Administrator's Guide, you must complete the following configuration tasks on OracleAS Portal:
After OracleAS Single Sign-On is SSL-enabled, all OracleAS Single Sign-On partner applications need to be re-registered so that the updated SSL login URL is obtained by each partner application for subsequent authentication requests.
To re-register the OracleAS Portal partner applications, invoke OPCA with ptlasst.csh (on the OracleAS Portal middle-tier). On MS Windows, you use ptlasst.bat.
For example:
MID_TIER_ORACLE_HOME/assistants/opca/ptlasst.csh -i typical -mode MIDTIER -type SSO -host portal_site_name -port portal_site_port
where:
portal_site_name is the hostname.domain of the portal middle-tier.
portal_site_port is the OracleAS Web Cache listen port or the reverse proxy listen port that the browser addresses.
OracleAS Portal maintains the URL prefix of OracleAS Single Sign-On, which accesses certain information through HTTP calls from the database using the UTL_HTTP package. These calls must be done through HTTP rather than HTTPS. As a result, even if OracleAS Portal and OracleAS Single Sign-On are configured to use HTTPS, you must still have access to an HTTP port on OracleAS Single Sign-On to support these interfaces. The calls made across this interface are required for the following reasons:
To set this URL prefix, the OracleAS Single Sign-On Query Path URL, perform the following steps:
http://infra.domain.com:7777/pls/orasso
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 DAS over non-SSL or SSL. The base URL for DAS is stored in Oracle Internet Directory, and this determines the URL that other applications render when providing links to DAS functionality.
If you want DAS accessed over SSL, then the re-registration of mod_osso needs to specify an SSL URL for the mod_osso_url parameter to ossoreg.jar. Refer to the section titled "Registering mod_osso" in Chapter 4 of the Oracle Application Server Single Sign-On Administrator's Guide for more information.
If you decide that you want to access DAS over SSL, then the orcldasurlbase attribute in the cn=OracleContext,cn=Products,cn=DAS,cn=OperationURLs entry needs to be updated in Oracle Internet Directory to reflect this fact. This attribute value is then used by OracleAS Portal for generating subsequent DAS URLs. This procedure assumes that the Oracle HTTP Server on the infrastructure tier is also listening on an HTTPS port.
INFRA_ORACLE_HOME/bin/oidadmin on UNIX). Run the Oracle Directory Manager and log in as cn=orcladmin.
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 OracleAS Portal cache, which holds the relevant Oracle Internet Directory information.
You now need to register the secured request with OracleAS Single Sign-On by configuring it as a partner application. The script ossoreg performs this registration. ossoreg is located on the middle-tier in MID_TIER_ORACLE_HOME/sso/lib.
ossoreg:
ORACLE_HOME=MID_TIER_ORACLE_HOME LD_LIBRARY_PATH=ORACLE_HOME/lib
ossoreg. The following example illustrates the usage of ossoreg.
MID_TIER_ORACLE_HOME/jdk/bin/java -jar MID_TIER_ORACLE_HOME/sso/lib/ossoreg.jar -site_name abc.com -mod_osso_url http://www.abc.com:7777 -config_mod_osso TRUE -oracle_home_path MID_TIER_ORACLE_HOME -u install_user -config_file MID_TIER_ORACLE_HOME/Apache/Apache/conf/osso/osso.conf -admin_info cn=orcladmin
Refer to the section titled "Registering mod_osso" in Chapter 4 of the Oracle Application Server Single Sign-On Administrator's Guide for more information.
At this point, configuration is complete for SSL communication to OracleAS Single Sign-On.
Once you secure the OracleAS Single Sign-On communication, the next option is to secure the communication to the front door of OracleAS Portal, which is OracleAS Web Cache. In this configuration, OracleAS Web Cache can forward the request to the Oracle HTTP Server, which is acting as the OracleAS Portal middle-tier, using HTTP for better performance. Similarly, the Parallel Page Engine requests for portlet content that loop back to OracleAS Web Cache can request the content using HTTP.
The various components of OracleAS Portal use the Oracle Wallet Manager to store the certificates for the secure communication. The first step in this process is to obtain a certificate from a Certificate Authority (for example, Verisign, GTE CyberTrust).
In order to obtain a digital certificate from the relevant signing authority, you submit a Certificate Request (CR) uniquely identifying your server to the signing authority.
MID_TIER_ORACLE_HOME. On UNIX, enter owm from the command prompt. On Windows, invoke Oracle Wallet Manager from the Start menu.
On UNIX the wallet is stored in the following location by default:
/etc/ORACLE/WALLETS/<Account Name creating the Wallet>
On MS Windows the wallet is stored in the following location by default:
\Documents And Settings\<Account Name creating the Wallet>\ORACLE\WALLETS
www.abc.com.
Requested.
MID_TIER_ORACLE_HOME\webcache\wallets\portalssl
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.
BEGIN/END NEW CERTIFICATE REQUEST lines.
To export the certificate request:
Once the CA has processed the request, the User Certificate is forwarded to you either as text within an e-mail or as a simple file that is downloaded from a given Web page. Note, if you are using a trial Root Certificate or have chosen a CA which is not currently installed in the Oracle Wallet Manager, you must first import the CA's Trusted Certificate before importing your server specific User Certificate.
To import the trusted certificate:
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.
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/Export Wizards within a browser. The following steps are for the Microsoft 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.
To import the server's user certificate:
A status line message should appear indicating that the User Certificate has been successfully imported.
Having imported the certificate, it is important to save the wallet with the Autologin functionality enabled. This step is required because OracleAS Web Cache accesses the wallet as the process starts and the wallet password is not held by OracleAS Web Cache. If this property is not set, OracleAS Web Cache immediately shuts down if running in SSL mode.
This sections that follow describe how to configure OracleAS Web Cache to accept SSL connections.
|
Note: Changing OracleAS Web Cache settings (for example, Listening Port) can change the OracleAS Portal URL. If you do this, mobile settings need to be updated manually. For more information, see Section C.8, "Using the cfgiasw Script to Configure Mobile Settings". |
For more information on the procedure in the preceding text, refer to Task 3: Configure HTTPS Operations Ports for the Cache in Chapter 8, Specialized Configurations, of the Oracle Application Server Web Cache Administrator's Guide.
Since there is no out-of-box default SSL configuration, you need to add a Site definition for the SSL-based Site that OracleAS Web Cache will be caching.
This is the load balancer or reverse proxy server name for configurations that use a load balancer device or other reverse proxy, or it is the OracleAS Web Cache hostname in a configuration where OracleAS Web Cache receives browser requests.
HTTPS Only Prefix: Leave blank
Client-Side Certificate: Not required
Default Site: Yes
Create Alias from Site Name with/without www: No
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 some portlet, and this portlet is requested on a non-SSL port, but the main Site is accessed over SSL, then an alias entry is needed. This equates the content accessed through the Site with SSL, to the content accessed over non-SSL. This way, invalidation requests that are sent to invalidate the content, will invalidate the content that is cached over either form of URL.
You need to create an alias for the non-SSL OracleAS Web Cache listening port for the OracleAS Web Cache SSL site. To create a site alias:
For more information on the procedure in the preceding text, refer to Create Site Definitions in Chapter 7, Basic Setup and Configuration, of the Oracle Application Server Web Cache Administrator's Guide.
After adding a new Site definition and associated aliases, you must add the Site to Server mapping for the newly defined Site to the origin server. To do this:
For more information on the procedure in the preceding text, refer to Map Sites to Origin Servers in Chapter 7, Basic Setup and Configuration, of the Oracle Application Server Web Cache Administrator's Guide.
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.
web.xml file associated with the OC4J_PORTAL instance on the middle-tier.
MID_TIER_ORACLE_HOME\j2ee\OC4J_Portal\applications\portal\ portal\WEB-INF\web.xml
useScheme and usePort in additional <init-param> blocks in web.xml. The useScheme http indicates that the http protocol should be used for PPE loop backs and usePort indicates which port these non-SSL loop backs should use. The HTTP port you specify for usePort should be the OracleAS Web Cache non-SSL http port. For example:
<servlet> <servlet-name>page</servlet-name> <servlet-class>oracle.webdb.page.ParallelServlet</servlet-class> <init-param> <param-name>useScheme</param-name> <param-value>http</param-value> </init-param> <init-param> <param-name>usePort</param-name> <param-value>7777</param-value> </init-param> </servlet>
x509certfile in an additional <init-param> block in web.xml. For example:
<servlet> <servlet-name>page</servlet-name> <servlet-class>oracle.webdb.page.ParallelServlet</servlet-class> <init-param> <param-name>x509certfile</param-name> <param-value>C:\mySSLconfig\trustedCerts.txt</param-value> </init-param> </servlet>
You now need to register the secured request with OracleAS Single Sign-On by configuring it as a partner application. The script ossoreg performs this registration. ossoreg is located on the middle-tier in MID_TIER_ORACLE_HOME/sso/lib.
ossoreg:
ORACLE_HOME=MID_TIER_ORACLE_HOME LD_LIBRARY_PATH=ORACLE_HOME/lib
ossoreg. The following example illustrates the usage of ossoreg.
MID_TIER_ORACLE_HOME/jdk/bin/java -jar MID_TIER_ORACLE_HOME/sso/lib/ossoreg.jar -site_name abc.com -mod_osso_url https://www.abc.com:4443 -config_mod_osso TRUE -oracle_home_path MID_TIER_ORACLE_HOME -u install_user -config_file MID_TIER_ORACLE_HOME/Apache/Apache/conf/osso/osso.conf -admin_info cn=orcladmin
Refer to the section titled "Registering mod_osso" in Chapter 4 of the Oracle Application Server Single Sign-On Administrator's Guide for more information.
To specify the published address for OracleAS Portal with the modified port for SSL, you need to use Oracle Enterprise Manager as follows:
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.
|
See Also:
For more information about |
MID_TIER_ORACLE_HOME/Apache/Apache/conf/httpd.conf file as follows:
4443 for the Port directive.
SimulateHttps On
To make the SimulateHttps directive take effect, you must load mod_ certheaders in the Oracle HTTP Server by adding one of the following directives before the SimulateHttps directive:
On UNIX:
LoadModule certheaders_module libexec/mod_certheaders.so
On MS Windows:
LoadModule certheaders_module modules/ApacheModuleCertHeaders.dll
For more information, refer to the "mod_certheaders" section of Chapter 8, Oracle HTTP Server Modules, in the Oracle HTTP Server Administrator's Guide.
MID_TIER_ORACLE_HOME/dcm/bin/dcmctl updateconfig
MID_TIER_ORACLE_HOME/opmn/bin/opmnctl stopall MID_TIER_ORACLE_HOME/opmn/bin/opmnctl startall
For installations that require the utmost security, it is possible to configure SSL throughout the system. In this configuration, the loop back from the PPE to OracleAS Web Cache uses a wallet and the hop between the PPE and the Web providers uses a certificate directly rather than through a wallet.
|
Note: If you have already followed the steps described in Section 6.3.2.1.3, "SSL to OracleAS Web Cache", you must revert all the changes you have made prior to configuring SSL throughout OracleAS Portal. |
It is possible to share a single wallet across both the listener and origin server (and all other available ports in OracleAS Web Cache) if OracleAS Web Cache and the Oracle HTTP Server are on the same machine. Conversely, specific wallets may be created for each port. In this case the two servers/ports will be sharing the same wallet specified earlier.
In some cases, such as when the Oracle HTTP Server is on a different machine than OracleAS Web Cache, you need to create a separate wallet for the Oracle HTTP Server. For this situation, refer to the steps in "Creating a Wallet" to create the wallet for the Oracle HTTP Server.
In the default case, where the Oracle HTTP Server is on the same machine as OracleAS Web Cache, you can share the wallet between the two.
You need to configure the Oracle HTTP Server as the OracleAS Web Cache's origin server to accept HTTPS-based communication. The Oracle HTTP Server implements SSL by the use of mod_ssl. As such, the configuration to use HTTPS is fairly straightforward.
|
Note: The default installation of the Oracle HTTP Server provides a basic implementation of SSL with a demo certificate. For production use, you should obtain a server certificate from a certificate authority following the instructions in "Creating a Wallet" . |
The SSL configuration of the Oracle HTTP Server is defined within ssl.conf. This file may be edited directly or by using the Advanced Server Properties page under the Oracle HTTP Server node of the appropriate Oracle Application Server instance within the Oracle Enterprise Manager Administration pages. If you edit the files manually, it is recommended that you run the dcmctl utility with the following options to make sure that the file is synchronized with the DCM repository.
MID_TIER_ORACLE_HOME/dcm/bin/dcmctl updateConfig -ct ohs
ssl.conf in MID_TIER_ORACLE_HOME/Apache/Apache/conf.
Table 6-18 Wallet Entries in ssl.conf
| Default Entry | Updated Entry |
|---|---|
|
|
/Directory where the wallet has been saved |
|
.... (hashed out) |
password used when creating the wallet |
ssl.conf in MID_TIER_ORACLE_HOME/Apache/Apache/conf, verify that the default virtual host for SSL communication specifies the correct, preallocated port number for SSL.
ssl-enabled in MID_TIER_ORACLE_HOME/opmn/conf/opmn.xml. For example:
<ias-component id="HTTP_Server"> <process-type id="HTTP_Server" module-id="OHS"> <module-data> <category id="start-parameters"> <data id="start-mode" value="ssl-enabled"/> </category> </module-data> <process-set id="HTTP_Server" numprocs="1"/> </process-type> </ias-component>
The sections that follow describe how to configure OracleAS Web Cache to accept SSL connections and forward SSL requests to the SSL-enabled origin server.
|
Note: Changing OracleAS Web Cache settings (for example, Listening Port) can change the OracleAS Portal URL. If you do this, mobile settings need to be updated manually. For more information, see Section C.8, "Using the cfgiasw Script to Configure Mobile Settings". |
IP Address: ANY
Port Number: SSL port that Web Cache is listening on
Protocol: HTTPS
Require Client-Side Certificate: No (unchecked)
Wallet: Path to the SSL server certificate
For more information on the procedure in the preceding text, refer to Task 3: Configure HTTPS Operations Ports for the Cache in Chapter 8, Specialized Configurations, of the Oracle Application Server Web Cache Administrator's Guide.
To add the SSL origin server:
Host Name: Physical hostname of the machine in which Oracle HTTP Server is running
Port: Oracle HTTP Server's SSL port
Routing: Enable
Capacity: 100
Failover Threshold: 5
Ping URL: /
Ping Interval: 10
Protocol: HTTPS
For more information on the procedure in the preceding text, refer to Task 9: Configure Origin Server, Load Balancing, and Failover Settings in Chapter 7, Basic Configuration and Setup, of the Oracle Application Server Web Cache Administrator's Guide.
Since there is no out-of-box default SSL configuration, you need to add a site definition for the SSL-based Site that OracleAS Web Cache will be caching.
HTTPS Only Prefix: Leave blank
Client-Side Certificate: Not required
Default Site: Yes
Create Alias from Site Name with/without www: No
For more information on the procedure in the preceding text, refer to:
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:
For more information on the procedure in the preceding text, refer to Map Sites to Origin Servers in Chapter 7, Basic Setup and Configuration, of the Oracle Application Server Web Cache Administrator's Guide.
In this configuration, SSL is used throughout as the request comes to OracleAS Web Cache through HTTPS and the PPE loops back over HTTPS as well. The server specifies the chain that goes with its certificate. As long as the chain is valid and leads to a self-signed root certificate, it is validated without determining whether it is trusted, assuming that you have not loaded any trust points into it.
To implement this configuration, perform the following steps on the OracleAS Portal middle-tier:
ssl.conf file.
MID_TIER_ORACLE_HOME/Apache/Apache/conf/ssl.conf
SSLWallet and SSLWalletPassword. For example:
SSLWallet file:/usr/local/adeviews/webdb/webdb_3000_ias902PW/Apache/Apache/conf/ssl.wlt/default SSLWalletPassword serverWalletPassword
|
See Also:
For more information about |
web.xml file associated with the OC4J_PORTAL instance on the middle-tier.
MID_TIER_ORACLE_HOME\j2ee\OC4J_Portal\applications\portal\portal\ WEB-INF\web.xml
httpsports in an additional <init-param> block in web.xml. This should point to the OracleAS Web Cache HTTPS listening port. For example:
<servlet> <servlet-name>page</servlet-name> <servlet-class>oracle.webdb.page.ParallelServlet</servlet-class> <init-param> <param-name>httpsports</param-name> <param-value>4443</param-value> </init-param> </servlet>
x509certfile in an additional <init-param> block in web.xml. For example:
<servlet> <servlet-name>page</servlet-name> <servlet-class>oracle.webdb.page.ParallelServlet</servlet-class> <init-param> <param-name>x509certfile</param-name> <param-value>C:\mySSLconfig\trustedCerts.txt</param-value> </init-param> </servlet>
The Smart Page functionality of OracleAS Portal allows for the publishing of Events and Page Parameters to allow portlets to communicate information to each other. The Event servlet, which runs in the same container as the Parallel Page Engine itself, implements this functionality. Since the Event servlet also must create the appropriate ACTION URLs resulting from the user interaction, it also requires knowledge of the protocol used to generate the page. The required parameters to indicate the use of HTTPS are the same ones used for the Page servlet.
web.xml file associated with the OC4J_PORTAL instance on the middle-tier.
MID_TIER_ORACLE_HOME\j2ee\OC4J_ Portal\applications\portal\portal\WEB-INF\web.xml
<init-param> block to the file to indicate the ports that are using HTTPS. This block should point to the OracleAS Web Cache HTTPS listening port.
<servlet> <servlet-name>event</servlet-name> <servlet-class>oracle.webdb.event.EventServlet</servlet-class> <init-param> <param-name>httpsports</param-name> <param-value>4443</param-value> </init-param> </servlet>
To specify the published address for OracleAS Portal with the modified port for SSL, you need to use Oracle Enterprise Manager as follows:
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.
|
See Also:
For more information about |
You now need to register the secured request with OracleAS Single Sign-On by configuring it as a partner application. The script ossoreg performs this registration. ossoreg is located on the middle-tier in MID_TIER_ORACLE_HOME/sso/lib.
ossoreg:
ORACLE_HOME=MID_TIER_ORACLE_HOME LD_LIBRARY_PATH=ORACLE_HOME/lib
ossoreg. The following example illustrates the usage of ossoreg.
MID_TIER_ORACLE_HOME/jdk/bin/java -jar MID_TIER_ORACLE_HOME/sso/lib/ossoreg.jar -site_name abc.com -mod_osso_url https://www.abc.com:4443 -config_mod_osso TRUE -oracle_home_path MID_TIER_ORACLE_HOME -u install_user -config_file MID_TIER_ORACLE_HOME/Apache/Apache/conf/osso/osso.conf -admin_info cn=orcladmin
Refer to the section titled "Registering mod_osso" in Chapter 4 of the Oracle Application Server Single Sign-On Administrator's Guide for more information.
The Federated Portal Adapter uses the Oracle HTTP Server rewrite rules to simplify URLs for registering providers. By default, these rewrite rules are only specified for HTTP communication.
portal.conf to the Oracle HTTP Server configuration files. The rewrite rules in portal.conf are as follows:
# Portal PL/SQL Adapter URL Simplification RewriteEngine on # This is to match '/adapter/<dad_name>/<schema_name>' and an optional trailing '/' RewriteRule ^/adapter/(.+)/([^/]+)/?$ /pls/$1/!$2.wwpro_app_adapter.process_request [PT] # This is to match '/adapter/<dad_name>' and an optional trailing '/' RewriteRule ^/adapter/([^/]+)/?$ /pls/$1/!$1.wwpro_app_adapter.process_request [PT]
You need to add these same rules to the virtual hosts section of your Oracle HTTP Server file as follows:
## SSL Virtual Host Context ## # # NOTE: this value should match the SSL Listen directive set previously in this # file otherwise your virtual host will not respond to SSL requests. # <VirtualHost _default_:3011> # General setup for the virtual host DocumentRoot /usr/local/adeviews/webdb/webdb_3000_ias902PW/Apache/Apache/htdocs ServerName host1.abc.com ServerAdmin you@your.address ErrorLog /usr/local/adeviews/webdb/webdb_3000_ias902PW/Apache/Apache/logs/error_log TransferLog "/usr/local/adeviews/webdb/webdb_3000_ias902PW/Apache/Apache/logs/access_log" Port 3001 SSLEngine on SSLCipherSuite SSL_RSA_WITH_RC4_128_MD5:SSL_RSA_WITH_RC4_128_SHA:SSL_RSA_WITH_3DES_EDE_CBC_SHA:SSL_RSA_WITH_DES_CBC_SHA:SSL_ RSA_EXPORT_WITH_RC4_40_MD5:S SL_RSA_EXPORT_WITH_DES40_CBC_SHA SSLWallet file:/usr/local/adeviews/webdb/webdb_3000_ias902PW/Apache/Apache/conf/ssl.wlt/default <Files ~ "\.(cgi|shtml)$"> SSLOptions +StdEnvVars </Files> <Directory /usr/local/adeviews/webdb/webdb_3000_ias902PW/Apache/Apache/cgi-bin> SSLOptions +StdEnvVars </Directory> SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown CustomLog /usr/local/adeviews/webdb/webdb_3000_ias902PW/Apache/Apache/logs/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" RewriteEngine on # This is to match '/adapter/<dad_name>/<schema_name>' and an optional trailing '/' RewriteRule ^/adapter/(.+)/([^/]+)/?$ /pls/$1/!$2.wwpro_app_adapter.process_request [PT] # This is to match '/adapter/<dad_name>' and an optional trailing '/' RewriteRule ^/adapter/([^/]+)/?$ /pls/$1/!$1.wwpro_app_adapter.process_request [PT] </VirtualHost>
MID_TIER_ORACLE_HOME/dcm/bin/dcmctl updateconfig
MID_TIER_ORACLE_HOME/opmn/bin/opmnctl stopall MID_TIER_ORACLE_HOME/opmn/bin/opmnctl startall
At this point, configuration is complete for SSL communication throughout OracleAS Portal.
The previous configurations discuss how to configure OracleAS Portal in such a way that communications within Oracle Application Server are secured through SSL. In some cases, you may want to have OracleAS Portal set up such that the site is externally accessible through SSL URLs but the Oracle Application Server is internally running in non-SSL mode. Note that in this latter scenario, you need to have the SSL to non-SSL translation done either by a load balancer or an SSL accelerator. The section that follows outlines the steps you would use with an accelerator on a load balancer or a reverse proxy server performing the SSL translation.
With this option, the SSL features of the OracleAS Security Framework are not used, but, instead, an external component is used for providing the SSL connection point. These external accelerators may be coupled with load balancers or reverse proxy servers. Oracle Application Server enables you to configure these external devices to provide SSL, thus allowing Oracle Application Server to use HTTP internally for the best performance.
For the purposes of this procedure, assume the following:
lbr.abc.com and the load balancer port used for accessing the site is 443.
w1.abc.com and the listening port is 7777, the administration port is 4000, and invalidations are sent to port 4001.
m1.abc.com and the port is 7778.
lbr.abc.com, and port (443). To do this, perform the following steps:
lbr.abc.com) in the Server Name field for your virtual host.
443 for the Port directive in the VirtualHost container. In that same VirtualHost container, add a line:
SimulateHttps On
To make the SimulateHttps directive take effect, you must load mod_ certheaders in the Oracle HTTP Server by adding one of the following directives before the SimulateHttps directive:
On UNIX:
LoadModule certheaders_module libexec/mod_certheaders.so
On MS Windows:
LoadModule certheaders_module modules/ApacheModuleCertHeaders.dll
For more information, refer to the "mod_certheaders" section of Chapter 8, Oracle HTTP Server Modules, in the Oracle HTTP Server Administrator's Guide.
MID_TIER_ORACLE_HOME/j2ee/OC4J_Portal/applications/portal/portal/WEB-INF/web.xml:
<servlet> <servlet-name>page</servlet-name>
<servlet-class>oracle.webdb.page.ParallelServlet</servlet-class>
<init-param> <param-name>useScheme</param-name> <param-value>http</param-value> </init-param> <init-param> <param-name>usePort</param-name> <param-value>7777</param-value> </init-param> </servlet>
MID_TIER_ORACLE_HOME/dcm/bin/dcmctl updateconfig
MID_TIER_ORACLE_HOME/opmn/bin/opmnctl stopall MID_TIER_ORACLE_HOME/opmn/bin/opmnctl startall
m1.abc.com such that it resolves the load balancer's hostname to be the IP address of the machine running OracleAS Web Cache. You can either rely on DNS resolution for this step or make entries in the /etc/hosts file as follows:
w1.w1.w1.w1 lbr.abc.com
This change coupled with the previous steps causes the Parallel Page Engine to loop back locally to OracleAS Web Cache.
ptlasst.csh. On MS Windows, you use ptlasst.bat.
For example:
ptlasst.csh -i typical -mode MIDTIER -type OHS -sdad portal -host lbr.abc.com -chost w1.abc.com -port 443 -cport_i 4001 -cport_a 4000 -wc_i_pwd welcome1 -ssl
ptlconfig (typically located in the directory MID_TIER_ORACLE_HOME/portal/conf) as shown in the following example:
ptlconfig -dad portal -em
Please refer to the Oracle Application Server Web Cache Administrator's Guide for detailed instructions on the configuration mentioned earlier.
lbr.abc.com:7777, whereas OracleAS Portal sends invalidation requests to invalidate URLs with the format lbr.abc.com:443. To get around this inconsistency, you need to set up an alias in OracleAS Web Cache to let it know that lbr.abc.com:7777 and lbr.abc.com:443 are the same, invalidation requests for one should invalidate requests for the other as well, and the cached content should also be leveraged based on this alias.
lbr.abc.com.
lbr.abc.com as the Host Name and 7777 as the port where 7777 is the value for usePort in the web.xml configuration file for the Parallel Page Engine.
lbr.abc.com).
m1.abc.com) specified in the Origin Servers page.
To verify that the site has been mapped correctly, navigate to the Site-to-Server Mapping page, and ensure that m1.abc.com is mapped to the site lbr.abc.com.
For more information on the procedure in the preceding text, refer to Map Sites to Origin Servers in Chapter 7, Basic Setup and Configuration, of the Oracle Application Server Web Cache Administrator's Guide.
lbr.abc.com, to accept requests on port 443 and forward them to the OracleAS Web Cache port (7777) running on machine w1.abc.com, while converting HTTPS requests to HTTP.
For information on how this configuration might affect your Web Providers, refer to Section 5.3.6, "Step 6: Configure Portal Tools and Web Providers (Optional)".
Note:
PORTAL).
WEBCLIPPING in the Name field.
https://lbr.abc.com:443/portalTools/webClipping/providers/webClipping
to:
http://lbr.abc.com:7777/portalTools/webClipping/providers/webClipping
When you register locally hosted Web Providers (such as the JPDK Sample provider), you need to register them using HTTP as the protocol, lbr.abc.com as the hostname, and 7777 as the port number. This restriction only applies to locally hosted Web Providers (that is, Web Providers running on the same middle-tier as OracleAS Portal).
For example, to register the JPDK Sample provider, the URL is:
http://lbr.abc.com:7777/jpdk/providers/sample
You now need to register the secured request with OracleAS Single Sign-On by configuring it as a partner application. The script ossoreg performs this registration. ossoreg is located on the middle-tier in MID_TIER_ORACLE_HOME/sso/lib.
ossoreg:
ORACLE_HOME=MID_TIER_ORACLE_HOME LD_LIBRARY_PATH=ORACLE_HOME/lib
ossoreg. The following example illustrates the usage of ossoreg.
MID_TIER_ORACLE_HOME/jdk/bin/java -jar MID_TIER_ORACLE_HOME/sso/lib/ossoreg.jar -site_name lbr.abc.com -mod_osso_url https://lbr.abc.com -config_mod_osso TRUE -oracle_home_path MID_TIER_ORACLE_HOME -u install_user -config_file MID_TIER_ORACLE_HOME/Apache/Apache/conf/osso/osso.conf -admin_info cn=orcladmin
Refer to the section titled "Registering mod_osso" in Chapter 4 of the Oracle Application Server Single Sign-On Administrator's Guide for more information.
In Section 6.3.2.1, "Configuring SSL for OracleAS Portal", we were mainly concerned with the HTTP-based network hops. However, you can also secure the network connection to the Oracle Internet Directory itself, which is LDAP-based communication. In this case the Oracle Internet Directory should be configured to use LDAP over SSL (LDAPS). You can find further information about configuring the Oracle Internet Directory for LDAPS in the Oracle Internet Directory Administrator's Guide.
Once Oracle Internet Directory is configured to use SSL, you must update the OracleAS Portal repository to use the new port on the LDAP server. To perform this step, you run the SQL script, secupoid.sql, located in MID_TIER_ORACLE_HOME/portal/admin/plsql/wwc. This script allows for the setting of the following Oracle Internet Directory related parameters:
When you run the script, it displays the current settings and gives you the ability to change them accordingly. In this case, you want to set the following:
use_ssl_to_connect_to_ldap=Y
The script will then give you the option of automatically refreshing OracleAS Portal's Oracle Internet Directory cache.
Once you have installed OracleAS Portal and performed the appropriate tasks from Section 6.3.2.4, "Post-Installation Security Checklist", you can change all of the following settings that pertain to security from the Global Settings page of OracleAS Portal:
As pointed out in Section 6.1.6, "Leveraging Oracle Identity Management Infrastructure", OracleAS Portal maintains a cache of information from the directory. From the Global Settings page, you can refresh this cache with the updated information from the directory. Refresh Cache for the Oracle Internet Directory parameters immediately updates the cache with the latest parameters values from the directory. The cached information is relatively static information, hence you do not need to refresh the cache frequently.
Because OracleAS Portal caches group membership information, it requires a mechanism for updating the cache when the information is changed in the directory. The directory integration server notifies OracleAS Portal whenever a change is made in the directory that must be reflected in OracleAS Portal. In Global Settings, you can set:
When the Oracle Directory Integration and Provisioning server is running and configured to work with OracleAS Portal, group membership changes in Oracle Internet Directory will result in soft cache invalidations in OracleAS Portal.
Some examples of group membership cache invalidations are:
OracleAS Portal maintains its user group information in the directory. When groups are created through the Group portlet, they are created under a node of the LDAP Directory Information Tree (DIT). A node is identified by its distinguished name (DN). Therefore, in OracleAS Portal, you need to specify in which node you wish to create groups:
Group Creation Base DN is the DN of the node in which you want OracleAS Portal to maintain its user groups. For example:
cn=ptl_schema_name.031009.0430,cn=Groups,dc=MyCompany,dc=com
This setting is particularly useful if you adapt OracleAS 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 OracleAS Portal to search for existing groups. For example, you need to specify where OracleAS Portal searches when it displays the group's list of values in the Group portlet.
Local Group Search Base DN is the DN of the node in which you want OracleAS Portal to maintain its user groups. For example:
cn=ptl_schema_name.031009.0430,cn=Groups,dc=MyCompany,dc=com
This setting is particularly useful if you adapt OracleAS Portal to interact with an existing DIT.
After OracleAS 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 OracleAS Portal as follows:
PORTAL DAD and change the password of the corresponding database user.
SAMPLE_DAD is unnecessary.
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 OracleAS Portal and database environment. For example:
When OracleAS Portal is installed, the seeded groups listed in Table 6-2 are provisioned with a set of privileges that are typically required by users in those roles. You should review these initial set of privileges to ensure that they are consistent with your security policy.
Users or groups can obtain privileges from one of the following sources:
To edit the privileges granted through OracleAS Portal access control entries, you edit the user or group profile from the Administer tab with the User Profile Portlet or Group Profile Portlet. Click the User or Group Profile dialog's Privilege tab. You can revoke or assign privileges from this list.
To edit the privileges granted through Oracle Internet Directory privilege groups, use the User Portlet or Group Portlet to edit the User or Group in Oracle Internet Directory. Select or deselect the checkmarks by the Privilege Assignment list to grant or revoke the appropriate privileges in Oracle Internet Directory.
Privileges granted to the AUTHENTICATED_USERS group are given to any user that logs on to OracleAS Portal through OracleAS Single Sign-On upon successful authentication. This is the group that you will want to establish with the default privileges for all your logged in users.
For example, if you don't 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.
In some cases, OracleAS Portal provider components may give users the option to view or modify records in application tables. To tighten security, you should revoke public access from such components if it is unnecessary. You can also use a menu component with specific access rights on the menu options to more tightly control application access.
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 page groups mentioned earlier, 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.
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.*
To secure passwords going across the Internet you can use Secure Sockets Layer (SSL) communications by configuring OracleAS Portal to run in HTTPS. However, to enable or disable SSL, you must have portal administrator privileges.
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 OracleAS Portal page layout style.
However, if you use this portlet, you must ensure that the pages on which it appears are SSL-encrypted. Bear in mind, that SSL encryption for your complete site could adversely affect performance because it requires more resources. Furthermore, the Login portlet presents a security risk because you cannot prevent showing the login screen 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, OracleAS Portal connects to the directory using LDAP without SSL. If the directory server is configured for an SSL port, though, OracleAS Portal can be configured to use LDAP over SSL, also known as LDAPS.
To configure OracleAS Portal to use SSL to connect to the directory, you must run the secupoid.sql script, located in ORACLE_HOME/portal/admin/plsql/wwc. This script enables you to change the following OracleAS Portal configuration parameters related to the directory:
When you install OracleAS Portal, it is automatically configured with a directory server. However, you may want to change some settings, such as whether to use SSL, after installation. To change to an SSL connection for the directory, simply run the secupoid.sql script in the PORTAL schema to specify the LDAPS port instead of the LDAP port, and indicate that you want to use SSL.
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 enables you to update OracleAS Portal's directory cache after running it. Since activating SSL does not change any of the directory information cached by OracleAS Portal, it is not usually necessary to refresh the cache in this case.
SQL> @secupoid Current Configuration -------------------- OID Host: oid.domain.com OID Port: 389 Application DN: orclApplicationCommonName=PORTAL,cn=Portal,cn=Products,cn=OracleContext Application Password: 3E8C2D1B87CB61011757239C5AA9B390 Use SSL? N PL/SQL procedure successfully completed. Updating OID Configuration Entries Press [Enter] to retain the current value for each parameter For SSL Connection to LDAP, specify "Y"es or "N"o ------------------------------------------------ Enter value for oid_host: Enter value for oid_port: 636 Enter value for app_password: Enter value for use_ssl_to_connect_to_ldap: Y Enter value for refresh_with_new_settings: N PL/SQL procedure successfully completed. No errors.
After executing the script, OracleAS Portal is configured for LDAPS access of the directory.
OracleAS Portal never passes a user's password to the directory. Only OracleAS Single Sign-On performs that task. However, OracleAS Portal authenticates itself to the directory through its application entity and password.
If you want to change the application entity's password, you need to first change its entry in the directory, using command line utilities or the Oracle Directory Manager. To locate the application entry in the directory, you need its DN, which is reported by the secupoid.sql script. By default, OracleAS Portal's application entry is:
orclApplicationCommonName=PORTAL,cn=Portal,cn=Products,cn=OracleContext
To change the password, you set the userPassword attribute for the application entry to the new password.
After you have changed the password in the directory, you run secupoid.sql script in the PORTAL schema and specify the new password there, too. Running the script enables OracleAS Portal to encrypt the password and store it for retrieval when it needs to connect to the directory.
For more information about the secupoid.sql script, refer to Section C.3, "Using the secupoid.sql Script".
|
See Also:
Section 6.1.6.2.1, "Directory Entries in Oracle Internet Directory for OracleAS Portal", for more information about the application entity. |
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 Oracle9i Database Server is the ability to dynamically attach, at runtime, 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 runtime. 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.
You'll find additional information about fine-grained access and application contexts in the technical note "How to Implement Fine Grained Access Controls and Secure Application Contexts," on Portal Center, http://portalcenter.oracle.com. Click the Search icon in the upper right corner of any Portal Center page.
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
|
 Copyright © 2002, 2003 Oracle Corporation. All Rights Reserved. |
|