2
Post-installation and Configuration Tasks

This chapter provides information about Oracle Portal after installation and the configuration tasks that you can perform.

See: For information about installing Oracle Portal with Oracle9i Application Server, see the "Oracle9i Application Server Installation Guide".

Specific topics covered include:

• Default Schemas Created

• Default Oracle Portal Accounts Created

• Default Groups Created

• Accessing Oracle Portal in Your Browser

• Deinstalling Oracle Portal

• Enabling Oracle Portal Beta Features

• Enabling Secure Socket Layer (SSL)

• Configuring Oracle Portal to Use HTTPS

2.1 Default Schemas Created

Oracle Portal is installed primarily in the Oracle8i database, with some supporting components installed on the middle-tier in Oracle9i Application Server.

If you install Oracle Portal in the default mode, five schemas are created. The default base schema name is portal30 which you can change at installation time.

Table 2-1 Default Oracle Portal schemas created

Schema	Description
portal30	This is the product schema for Oracle Portal and contains the installed portal database objects.
portal30_public	This is the schema that the portal users map to when executing procedures in the Oracle Portal product schema. The schema name is constructed from the base schema with "_public" appended to it.
portal30_sso	This is the product schema for the Login Server. This schema can be renamed in the installer. If not specified, it defaults to the base schema name with "_sso" appended to it.
portal30_sso_public	This is the schema that the portal users map to when executing procedures in the Login Server product schema. This name is constructed from the Login Server schema name with "_public" appended to it.
portal30_demo	This is a schema which is installed with some Oracle Portal demonstration code. The name of this schema is the base schema name with "_demo" appended to it.

Note: The portal30 and the portal30_sso schemas are highly privileged database schemas allowing any user with these privileges to view and modify anything in Oracle Portal, even folders, pages, and applications marked private.

2.2 Default Oracle Portal Accounts Created

With each Oracle Portal installation, a default set of login accounts is created. If the product is installed in a schema named portal30, the following default accounts are created:

Table 2-2 Default Oracle Portal accounts created

Account	Description
portal30	This account is created for the Database Administrator (DBA) with the highest privileges in Oracle Portal.
portal30_admin	This is the account created for the portal administrator (ADMIN). This account is similar to the DBA account, however, it does not have privileges that provide access to database administration features, such as creating and managing schemas and other database objects.
portal30_public	This account is created for public users for unauthenticated sessions. This is the account that all sessions are associated with prior to authentication.
portal30_SSO	This account is created for the Login Server application. Since the Login Server is implemented with significant reuse of Oracle Portal infrastructure code, this user account is created as a result of this reuse.
portal30_SSO_public	This account is for non-authenticated sessions by the Login Server application.

Note: For security reasons, change all the passwords for these accounts after initial login. By default, the password is set to the user name. Change the password by logging on to the Login Server and editing the appropriate user accounts and changing their passwords.

See also: Task topics in the "Working with Users" folder from the Oracle Portal Online Help content area.

2.3 Default Groups Created

The following groups are created at installation time:

Table 2-3 Default Oracle Portal groups created

Group	Description
DBA	This group has the maximum privilege levels in the system. All global privileges are granted to this group. When this group is installed, it has only one member - the user with the name of the product schema, for example, portal30.
PORTAL_ADMINISTRATORS	This group has most of the global privileges, except for the database-related privileges: ANY_SCHEMA/MANAGE and ANY_SHARED_COMPONENT/MANAGE. This group is comprised of the admin user, portal30_admin, and includes the dba group.
PORTAL_DEVELOPERS	This group has privileges to build and manage Oracle Portal components and applications.
PORTLET_PUBLISHERS	This group has the privilege of publishing portlets. Members of this group can create components in the system such as folders, charts, calendars, and so on. This group is initially composed of the portal_administrators group who can then decide which users or groups should be added to this group.
AUTHENTICATED_USERS	All users that log on to Oracle Portal are added to this group. This is a convenient mechanism to allow logged on users to perform privileged actions. Specified privileges are granted to this group and group membership cannot be changed.

See also: Task topics in the "Working With Users" folder from the Oracle Portal Online Help content area.

2.4 Accessing Oracle Portal in Your Browser

After Oracle Portal is installed, access it by entering the following URL in your browser:

http://<hostname>:<portnumber>/pls/<dad>

Table 2-4 URL to enter in browser to access Oracle Portal

Parameter	Description
hostname	Defines the machine on which you installed Oracle Portal. Important: Enter both the hostname and the fully-qualified domain name. For example, enter host.domain.com. This name must also match the ServerName parameter in the Apache configuration file, httpd.conf, located in:    <ORACLE_HOME>/Apache/Apache/conf
portnumber	Defines the port number you specified earlier to access Oracle Portal.
pls	Defines the virtual path and indicates that the request is for a PL/SQL procedure which alerts the Oracle HTTP Server powered by Apache to reroute the request to the PL/SQL Gateway.
dad	Defines the Database Access Descriptor (DAD) you specified earlier for your Oracle Portal installation. The DAD contains information on how to connect to the database.

You are prompted to enter the Single Sign-On (SS0) username and password before gaining access to Oracle Portal. The defaults are as follows:

Username: portal30

Password: portal30

See also: Section 2.2, "Default Oracle Portal Accounts Created" "Using the PL/SQL Gateway" guide included in the Oracle9i Application Server documentation library.

2.4.1 Simplifying the Full URL of an Oracle Portal Installation

You can simplify the full URL created by the Oracle Portal installation to a more memorable or meaningful URL using the Apache Redirect directive. In this way, end users can access Oracle Portal by entering a simple URL.

By default, the URL for a new Oracle Portal installation requires you to enter:

http://<hostname>:<portnumber>/pls/<dad>

You can simplify this URL to:

http://<hostname>/<redirectpath>

1. Open the Oracle HTTP Server configuration file, http.conf. By default this file is located in the following directory:

   <ORACLE_HOME>/Apache/Apache/conf/

2. Enter the redirect path as follows:

   Redirect /<DADnamepath> http://<hostname>:<portnumber>/pls/<dad>
   

Example

Redirect /portalhome http://mysite.oracle.com:80/pls/portal30

In this example, end users can enter the following:

http://mysite.oracle.com/portalhome 

to access the full URL which is as follows:

http://mysite.oracle.com:80/pls/portal30

This technique also works with any valid path that is appended to the URL. For example, if you want to display the Oracle Portal Online Help Content Area, enter:

http://mysite.us.oracle.com/portalhome/url/folder/ONLINE_HELP

See also: "What are direct access URLs" topic in the Oracle Portal Online Help Content Area.

2.4.2 Installing Language Support in Oracle Portal

You can choose to install and display the Oracle Portal user interface in any of the 24 supported languages from your browser. To install support for a given language, run the wwvseedus.sql and langinst.csh scripts. Once the language is installed you use the Set Language portlet to choose which language Oracle Portal should use.

The supported languages and their abbreviations are listed in the following table:

Table 2-5 Supported languages and abbreviations

Language	Abbreviation		Language	Abbreviation
Czech	cs		Polish	pl
German	d		Portuguese	pt
Danish	dk		Brazilian Portuguese	ptb
Spanish	e		Romanian	ro
Greek	el		Russian	ru
French	f		Swedish	s
Hungarian	hu		Finnish	sf
Italian	i		Slovak	sk
Japanese	ja		Thai	th
Korean	ko		Turkish	tr
Norwegian	n		Chinese (Simplified)	zhs
Dutch	nl		Chinese (Traditional)	zht

To install support for a given language in Oracle Portal:

1. Start a command line prompt.

2. Change to the <ORACLE_HOME>/portal30/admin/plsql/nlsres/ctl/us directory.

3. Start SQL*Plus and login to the database where Oracle Portal is installed.

4. From SQL*Plus, run the wwvseedus.sql script against the portal30 schema.

5. Change to the <ORACLE_HOME>/portal30/admin/plsql directory.

6. Enter one of the following commands, depending upon your operating system:

UNIX

langinst.csh <-s portal_schema> <-p portal_password> <-o sso_schema> <-d sso_
password> <-c portal_connect_string> -l <language> -available 

Windows NT/2000

langinst.cmd <-s portal_schema> <-p portal_password> <-o sso_schema> <-d sso_
password> <-c portal_connect_string> -l <language> -available 

Example

langinst.csh -s portal30 -p portal30 -o portal30_sso -d portal30_sso -c orcl -l 
cs -available 

where

Table 2-6 Language script parameters (langinst)

Parameter	Description
-s portal_schema	The database schema for the Oracle Portal database objects. Default = PORTAL30
-p portal_password	The Oracle database password for the Oracle Portal schema. Default = <portal_schema>
-o sso_schema	The Oracle database schema for Login Server objects. Default = <portal_schema>_SSO
-d sso_password	The Oracle database password for Login Server schema. Default = <sso_schema>
-c connect_string	The connect string for the database in which the Oracle Portal schema is installed. Provide the connect string only if the schema is located on a remote database.
-l language	The abbreviation for the language you want to install. See Table 2-5, "Supported languages and abbreviations" above.
-available	(Required) Ensures that the tabs are translated.

7. Repeat step 6 for each language desired in Oracle Portal.

8. To enable users to choose their desired language, add the Set Language portlet to a portal page. This portlet displays all of the languages currently installed. Users can then select the language of their choice when logging on.

   Typically, the Set Language portlet is added to your content area home page, but you can add it to any page. Refer to the Oracle Portal online help content area for instructions on how to add portlets to pages.

   Notes: In previous releases, Oracle Portal's language support depended upon the setting of your browser's language preference. With the Set Language portlet, this is no longer the case. The Login Server's language is set separately from that of Oracle Portal. The Login Server automatically displays a list of installed languages on its login page, which determines the language used for the Login Server regardless of what you set in the Set Language portlet.

2.5 Deinstalling Oracle Portal

This section describes how to use Oracle Universal Installer to deinstall Oracle products (which deinstalls them from the Oracle Universal Installer inventory) instead of removing them manually.

See also: "Oracle9i Application Server Installation Guide" for your operating system.

To deinstall Oracle Portal:

1. Launch the Oracle Universal Installer.
   • On UNIX, enter ./runInstaller

   • On Windows NT/2000, choose Start -> Programs -> Oracle Installation Products -> Universal Installer.

   The Welcome window for Oracle Universal Installer appears.

2. Click Deinstall Products.

   The Inventory dialog box appears.

3. Expand the tree of installed products until you find the products to deinstall. In this case, choose Oracle Portal.

4. Check the boxes of products to deinstall.

5. Click Remove.

   The Inventory Confirmation window appears.

6. Click Yes to deinstall the selected products.

   Note: A message may display indicating that removing some products may cause other products to function improperly.

   The products are deinstalled from your computer. The Inventory dialog box appears without the deinstalled products.

7. Click Close to close the Inventory dialog box.

8. Click Exit to exit Oracle Universal Installer.

2.5.1 Deinstalling a Single Oracle Portal Schema or the Login Server

Deleting a single Oracle Portal schema or the Login Server is performed from the Oracle Portal Configuration Assistant - Step 1 of 6: Installation Options.

To deinstall an Oracle Portal schema or the Login Server:

1. Launch the Oracle Portal Configuration Assistant:

Windows NT/2000

Choose Start -> Programs -> Oracle Home -> Oracle Portal Configuration Assistant

UNIX

Go to the $OH/assistants/opca directory and run the launch.sh script

2. The Step 1 of 6: Installation Options window appears.

   Click the option to Deinstall Oracle Portal or the Login Server.

3. Follow the instructions on the remaining screens to complete this task.

See also: "Oracle9i Application Server Installation Guide" for your particular operating system

2.6 Configuring Self-registration

If you want to allow users to create new accounts for themselves through a link on the Login Portlet, you do so by installing the self-registration feature as follows:

1. Start SQL*Plus and login to the database in which the Login Server is installed.

2. Create a schema. This schema is used for accessing user administration objects on the Login Server. From now on in this task we refer to this as the user administration access schema.

3. In the user administration access schema, create a synonym for the Login Server SSO schema package wwsso_api_user_admin. This synonym must be called wwsso_api_user_admin.

4. Grant Execute privileges on the wwsso_api_user_admin package in the Login Server SSO schema to the user administration access schema.

5. If Oracle Portal and the Login Server are installed in different databases:
   1. In the user administration access schema, create a synonym for the Login Server SSO schema package wwctx_api_vpd package. This synonym must be called wwctx_api_vpd.

   2. Grant Execute privileges on the wwctx_api_vpd package in the Login Server SSO schema to the user administration access schema.

   3. In the schema in which Oracle Portal is installed, create a database link to connect to the user administration access schema.

6. Start a command line prompt.

7. Change to the <ORACLE_HOME>portal30/admin/plsql directory of the directory in which Oracle Portal is installed.

8. Enter the following command:

UNIX

selfreg.csh -s <portal_schema> -p <portal_password> -ua <sso_uadmin_schema> -c 
<portal_connect_string> -dblink <sso_uadmin_dblink>

Windows NT/2000

selfreg.cmd -s <portal_schema> -p <portal_password> -ua <sso_uadmin_schema> -c 
<portal_connect_string> -dblink <sso_uadmin_dblink>

where

Table 2-7 Self-registration parameter descriptions

Parameter	Description
portal_schema	The database schema in which Oracle Portal is installed. Default = PORTAL30
portal_password	The password for the above schema. Default = <portal_schema>
sso_uadmin_schema	The user administration access database schema you created in step 1. Default: <portal_schema>_SSO_UA Note: You do not need to provide a value for this parameter if you specify a database link for the dblink parameter.
portal_connect_string	The connect string for the database in which Oracle Portal is installed. Note: You need to provide the connect string only if you are running the script on a different database.
sso_uadmin_dblink	The name of the database link created in step 4c. Note: You need to provide the database link only if the Login Server is installed in a different database instance from the Oracle Portal installation. If you do not provide a value for this parameter, it is assumed that the user administration access schema is in the same database instance as Oracle Portal.

Example

selfreg.csh -s myportal -p myportal -ua myportal_sso_ua -c orcl -dblink uadmin_
link

Press the Enter or Return key.

In the Services portlet, click Global Settings. By default, the Services portlet is located on the Oracle Portal home page's Administer tab.

In the Self-Registration Options section, select Enable Users To Log On Immediately if you want users to be able to log on to Oracle Portal immediately after they create their own user account using the self-registration feature.

Note: If you do not select this check box, you need to assign the user as an authorized user before he or she is able to log on.

To expose the self-registration feature to users, customize the Login portlet to include a self-registration link.

See: "Customizing the Login Portlet" topic in the Oracle Portal Online Help Content Area to continue.

2.7 Enabling Oracle Portal Beta Features

You can switch on and off Beta features from the Oracle Portal 3.0.8 Global Settings page, in the following way:

1. In the Services portlet, click Global Settings. By default, the Services portlet is located on the Oracle Portal home page's Administer tab.

   
   Text description of the illustration beta.gif

2. In the Beta Features section, select the check box to enable the Image Charts From Query Wizard feature or clear the check box to disable this feature. Application developers can create Java-based image charts using a wizard. The wizard to create these charts is accessible from the Application Navigator.

Note: In this release of Oracle Portal, Image Charts From Query Wizard is the only Beta feature offered. If you disable this feature, you cannot create any new components of this type. However, you can still edit, run, and manage the existing components that you have already created.

2.8 Enabling Secure Socket Layer (SSL)

Oracle Portal and the Login Server can be configured to run in HTTPS mode if your portal requires increased security. For optimal performance, you can also choose to have a mixed configuration where Oracle Portal is run in HTTP mode and the Login Server is run in HTTPS mode.

Secure Socket Layer (SSL) is responsible for securing Web HTTP communication between a browser and a Web server in plain HTTP over SSL (named HTTPS). Enabling SSL to work with the Oracle HTTP Server is handled by the mod_ssl package which is provided with the Apache Web server. It uses the URL scheme HTTPS rather than HTTP and a different server port.

Notes: You must be the portal administrator to enable or disable Secure Socket Layer (SSL) in Oracle Portal and on the Login Server. See also: "Oracle9i Application Server Installation Guide" for enabling SSL on the server.

2.8.1 SSL in Apache

For more information about enabling and disabling SSL, visit the Apache interface to mod_SSL at the following location:

http://www.modssl.org

2.8.2 What are Certificates?

Certificates are encrypted files which allow a client and server to pass sensitive data without the fear of that data being read by unauthorized clients. Oracle Portal supports the x.509 certificate standard. This is the most popular standard, and is the type of certificate supplied by most major certificate authorities.

Certificates can be either 40 bit or 128 bit encryption strengths. The greater the number of bits, the more secure the certificates. There are three major types of certificates which operate differently depending upon the certificate type which include:

Table 2-8 Certificate types

Certificate Type	Description
Global Site ID	Also known as a Step Up Certificate or Server Gated Cryptography Certificate, the Global Site ID certificate is an extension in a certificate which is proposed by Verisign. The certificate is used for SSL Server authentication. Verisign initiated this kind of certificate to bypass the restrictions of the U.S. security export controls. With this kind of certificate, any financial institution outside the United States can use the GSID to negotiate stronger algorithms (128 bit key) in an SSL handshake. This key size is only related to SSL session key generation. For example, a Secure Site certificate created with a 1024b key-pair negotiates 128b sessions for domestic (128b) browsers. Now that security export control no longer restricts the key size for the SSL session key, certificates with GSID will not be necessary soon. For more information about this technology, visit: http://digitalid.verisign.com/server/global/ help/globalFAQ.htm
Secure Site ID	This is a 128 bit certificate which causes the browser to operate at the best encryption level used by the client browser. Thus, if the browser is operating at 40 bit encryption, the server does the same. If the client is at 128 bit, then so is the server. In general this is not a problem since most browsers today operate using 128 bit encryption, however, this is not as secure as the Global Site ID.
40 bit Certificate	This is the least secure type of certificate. In this case, the server and all connected clients operate at a 40 bit encryption level. Note: If you receive a trial certificate from a certificate authority, it is probably this certificate type.

These certificates can be purchased from many different authorities. Oracle Portal currently supports Thawte, Verisign, and Netscape certificate providers.

Note: Do not purchase certificates with the V3 extension as these are not supported by Oracle Portal.

2.8.3 What are Signature and Chain Files?

In addition to the certificate, you also need specific signature, and/or chain files from the provider of your certificate. These files are available from your provider's Web site or customer service.

2.8.3.1 Certificate Authority File (CA)

The Certificate Authority (CA) file is the base signature file for the certificate file you have purchased. This file validates the certificate you are using. It informs clients that they can trust the certificate they have received. You require a CA file for any type of certificate you use.

2.8.3.2 Certificate Chain File

The certificate chain file links your certificate to the CA file. You require one of these files if you are using a Global Site ID or if you are using other types of certificates from another provider.

2.8.3.3 Configuration Files

There are several files involved with the certificates. Put these files in the appropriate directory. You can setup the configuration differently, however, this is the standard configuration.

Table 2-9 Certificate file and locations

File	Directory location
Certificate File	<ORACLE_HOME>/Apache/Apache/conf/ssl.crt/
Certificate Authority (CA) Certificate File	<ORACLE_HOME>/Apache/Apache/conf/ssl.crt/
Certificate Chain File (if available)	<ORACLE_HOME>/Apache/Apache/conf/ssl.crt/
Key File	<ORACLE_HOME>/Apache/Apache/conf/ssl.key

2.8.4 Securing Ports to Use Certificates and HTTPS

With HTTPS, you must use certificates for increased security in Oracle Portal. In this case, the Parallel Servlet must be aware of which port(s) are operating under HTTPS. To set this up, edit the zone.properties file which is located in the following location by default:

Table 2-10 zone.properties file location

Operating System	Location
Windows NT/2000	<ORACLE_HOME>\Apache\Jserv\servlets\zone.properties
UNIX	<ORACLE_HOME>/Apache/Jserv/etc/zone.properties

Add the following line to the zone.properties file:

servlet.page.initArgs=httpsports=<port1>:<port2>:. . . :<portn> 

Each port in this list operates using the HTTPS protocol, and must have a certificate created on the Oracle HTTP Server powered by Apache on that port.

See also: "JServ Configuration File (zone.properties)" "Configuring the Login Server for LDAP user authentication" topic in the Oracle Portal Online Help Content Area

2.8.5 Adding JServ File Entries in zone.properties

The JServ configuration file, zone.properties, is used by the servlets at initialization time. The Parallel Page Engine uses this file to get certain information for it to run properly. The file indicates which ports are configured for HTTPS in order for the Parallel Page Engine to know which ports are secure ports and thus use the appropriate protocol on each port. You can add as many ports as needed for secure communication by separating the port numbers with a colon (:).

The line in the zone.properties file should look similar to the following:

One Port	servlet.page.initArgs=httpsports=<port>
Multiple Ports	servlet.page.initArgs=httpsports=<port 1>:<port 2>: <port n>

2.8.6 Configuring Oracle Portal to Use HTTPS

This section addresses how to configure Oracle Portal for HTTPS. It is possible to configure the system so that only the Login Server is configured for HTTPS, or configure it such that both Oracle Portal and the Login Server use HTTPS.

The Apache mod_ssl documentation describes how to configure the server to support HTTPS ports. After configuring the server to support HTTPS ports, run the ssodatan or ssodatax script(s), specifying the appropriate protocol and ports. For example, if you wanted to configure the Login Server to use HTTPS, but have Oracle Portal on HTTP, then run the ssodatan script as follows:

ssodatan -w http://Oracle Portal.acme.com/pls/Oracle Portal30/ -l 
https://login.acme.com/pls/Oracle Portal30_sso/ -s Oracle Portal30 -o Oracle 
Portal30_sso

See also: "Configuring a New Oracle Portal Instance and Login Server with the ssodatan Script"

The following sections address the particular requirements for configuring Oracle Portal for HTTPS.

2.8.7 Adding Certificate Entries in http.conf

The Oracle HTTP Server configuration file, httpd.conf, contains all of the configuration information for the Oracle HTTP Server powered by Apache, including the certificate configuration. Enter the path locations for the following configuration lines. These configuration lines should already exist in comment form (;).

Table 2-11 Certificate Entries in the Oracle HTTP Server configuration file

File	Description
SSLCertificateFile	Enter the path location for the certificate file, either the Trial or the purchased certificate.
SSLCertificateKeyFile	Enter the path location for the Key file which contains the key to decrypt your certificate.
SSLCertificateChainFile	Enter the path location for the Certificate Chain File you received from your provider.
SSLCACertificateFile	Enter the path location for the CA Certificate File you received from your provider.

Note: Do not use the environment variables such as your <Oracle Home> to specify the path location of these configuration files. Use the fully-qualified path location.

The following subsections indicate the configuration entries required in the httpd.conf file, corresponding to each type of certificate. These configuration entries have been used successfully to set up Verisign certificates.

The usage varies slightly depending upon the certificate type you are installing. For example, if the certificate you are using has a chain file, then follow the Global Site ID configuration described below. If your certificate only uses a CA certificate file, then use the Secure Site ID configuration.

2.8.7.1 Global Site ID

SSLCertificateFile	<ORACLE_HOME>/Apache/Apache/conf/ssl.crt/<certificate file>
SSLCertificateKeyFile	<ORACLE_HOME>/Apache/Apache/conf/ssl.key/<key file>
SSLCACertificateFile	<ORACLE_HOME>/Apache/Apache/conf/ssl.crt/<certificate chain file>
SSLCertificateChainFile	<ORACLE_HOME>/Apache/Apache/conf/ssl.crt/<CA Certificate file>

2.8.7.2 Secure Site ID

SSLCertificateFile	<ORACLE_HOME>/Apache/Apache/conf/ssl.crt/<certificate file>
SSLCertificateKeyFile	<ORACLE_HOME>/Apache/Apache/conf/ssl.key/<key file>
SSLCACertificateFile	<ORACLE_HOME>/Apache/Apache/conf/ssl.crt/<CA Certificate file>

2.8.7.3 40 bit Site ID

SSLCertificateFile	<ORACLE_HOME>/Apache/Apache/conf/ssl.crt/<certificate file>
SSLCertificateKeyFile	<ORACLE_HOME>/Apache/Apache/conf/ssl.key/<key file>
SSLCACertificateFile	<ORACLE_HOME>/Apache/Apache/conf/ssl.crt/<CA Certificate file>

Note: The Chain file and CA Certificate file appear to be inverted with their configuration entries. This is intentional, and necessary for Oracle Portal to work properly.

See also: "Oracle HTTP Server Configuration File (httpd.conf)"

2.8.8 Setting Login Server Query Path URL

Oracle Portal maintains the URL prefix of the Login Server 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.

Thus, if Oracle Portal and the Login Server are configured to use HTTPS, access to an HTTP port on the Login Server is still required to support these interfaces. The calls made across this interface are required for the following reasons:

• Obtain the list of external applications to allow the external applications portlet to customize.

• Perform the mapping of the Single Sign-On user name to the external application user name.

• Present an interface to verify the existence of a user.

To set this URL prefix, which is called the Login Server Query Path URL, complete these steps:

1. Log on to Oracle Portal as the portal administrator.

2. Click the Administer tab.

3. Click Global Settings in the Services Portlet.

4. Scroll down to the section on Login Server, and edit the Query Path URL. Set this field to an HTTP URL for the Login Server.

Figure 2-1 Login Server Query Path URL Prefix field

Text description of the illustration logssl.gif

By default, it is the same prefix as specified for the Login Server when running the ssodatan or ssodatax scripts. However, if these scripts specify an HTTPS protocol, then manually update this parameter to use an HTTP protocol.

See also: "Configuring a New Oracle Portal Instance and Login Server with the ssodatan Script" "Updating an Existing Portal Instance with the ssodatax Script" "Step 4: Associate Nodes with the Same Login Server"

2.8.9 Adding SSO Enabler Configuration Entries for HTTPS Mode

If you are using SSL, the default port is 443. With Oracle Portal versions prior to 3.0.8, you need to create two enabler configuration entries, and two corresponding partner configuration entries on the Login Server. Specify the :443 port for one entry, and exclude it for the additional entry.

To add the additional entry, follow the basic procedure of adding the partner entry on the Login Server using the Login Server Administration user interface, and then add the configuration entry on the Oracle Portal side by using the ssodatax script.

If using Oracle Portal version 3.0.8 or later, you only need a single entry - one which excludes the :443 from the URL.

2.8.10 Configuring HTTPS with Microsoft Internet Explorer

In the Oracle HTTP Server configuration file, httpd.conf, comment out the following line to permit Microsoft Internet Explorer browsers to work in HTTPS mode:

SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

2.8.11 Configuring HTTPS with Virtual Hosts

If you want to setup a virtual host, it can be done in one of two ways:

• Through an IP address (for example, 123.1.3.2)

• Through an IP name (for example, server.oracle.com)

When the IP name is used, several aliases use the same IP address. In this case, Apache (or any browser supporting virtual name addresses) looks at the Host field in the HTTP request and determines which of the virtual addresses should be emulated.

However, when SSL is used, the IP name is encrypted. This causes the problem, because the software does not know which decryption key to use since the keys differ by virtual name. If there were 1000 separate virtual addresses supported, then on average the software would try 500 different keys to determine which key to use to decode the message. This is not practical, at least for performance reasons.

Notes: It is more difficult to configure virtual hosts to use HTTPS since the SSL encryption prevents virtual hosts from being resolved in the way that it is done in non-SSL mode. There are some workarounds from which to choose. One is to only use virtual names on the home page and other pages where you do not need protection.

2.8.11.1 SSL Protection Pages

• Obtain an IP address for each virtual host and then obtain a TCP/IP card that can handle multiple IP addresses, one for each virtual host.

• Use one IP address with different port numbers for each virtual host.

• Use one IP address but use different directories, one for each "virtual host" (for example, https://ssladdress.com/virtualname1/<page desired>).