Release 3.0.9
Part Number A90096-01
 Library |
 Solution Area |
 Contents |
 Index |
| Oracle9iAS Portal Configuration Guide Release 3.0.9 Part Number A90096-01 |
|
In an enterprise deployment of Oracle Portal, it is typical to have a separate Oracle HTTP Server powered for Apache listener serving Login Server request and one for Oracle Portal requests. For performance reasons and connection pooling, it makes sense to configure the Login Server on a separate listener so that it is dedicated to authentication service only.
Architecturally, the Login Server is designed to be a central authentication service. As such, several Partner Applications exist within the enterprise and are hosted on various hosts. These Partner Applications are then configured to share a centralized Login Server.
Specific topics covered include:
Oracle Portal is a Partner Application of the Login Server. The following figure illustrates such a configuration. Oracle Portal has a separate listener from the Login Server.
You can set up Oracle Portal as a Partner Application in the following ways depending on preference, scalability, or manageability factors:
If you do not have any administrative authority over the Login Server (for example, it is managed by the IT department), then you would associate an Oracle Portal node in the following way:
ssodatax script and entering the input information provided above. You need to know the following information to run the script:
ssodatax <-i portal_site_id> <-t portal_site_token> <-k encryption_key> <-w portal_url> <-l login_server_url> <-s portal_schema> <-p portal_password> <-v cookie_version> <-o sso_schema> <-e pstore_schema> <-r pstore_password> <-b pstore_dblink> <-c connect_string> <-n ps_connect_string>
|
See also: For syntax and parameter descriptions, see Section B.5, "Updating an Existing Portal Instance with the ssodatax Script". |
ssodatax.cmd -i 1234 -t A1B2C3 -k X9Y8Z7 -w http://webdbsvr.us.oracle.com:3000/pls/portal30/ -l http://webdbsvr.us.oracle.com:3000/pls/portal30_sso/ -s portal30 -p portal30 -v v1.1 -o portal30_sso -e portal30_sso_ps -r portal30_sso_ps -b portal30_dblink -c orcl -n orcl01
After running the ssodatax script, your Oracle Portal is associated with the Login Server, each running on a separate listener providing you specified a different host name in the URL prefix for the Oracle Portal and the Login Server (ssodatax parameters -w and -l parameters respectively).
If you have full administrative control over the Login Server, then you can perform the association between your Oracle Portal and the Login Server using the ssodatan script, providing that they both reside on the same database instance.
If the database instances are on separate instances, complete the following steps first on your Oracle Portal and then on the Login Server.
These steps are summarized below:
linstall script:
linstall <-o sso_schema> <-i pstore_password> <-s login_server_url> <-r random_ seed> <-p sys_password> <-u default_tablespace> <-t temporary_tablespace> <-d document_tablespace> <-l logging_tablespace> <-c connect_string>
|
See also: For syntax and parameter descriptions, see Section B.3, "Manually Installing a Login Server with the linstall Script". |
ssodatax script and enter the input information generated above for your Oracle Portal.
For syntax and parameter descriptions, see Section B.5, "Updating an Existing Portal Instance with the ssodatax Script".
See also:
After running the ssodatax script, your Oracle Portal is associated with the Login Server. Each one is running on a separate listener, if you specified a different host name in the URL prefix for the Oracle Portal and the Login Server (ssodatax parameters -w and -l parameters respectively).
With any of the previously described configurations, you can also use the Oracle Internet Directory as a user repository.
In this architecture, instead of authenticating the user's credentials against a local table, the Login Server authenticates the user's credentials against an LDAP directory (OID). The Login Server makes LDAP API calls to the configured LDAP directory and authenticates the credentials against the directory.
Such a configuration requires that the Login Server be able to establish LDAP protocol communications between the database instance it resides in with the LDAP directory.
So, depending on the placement of the LDAP directory, the Login Server, and any firewalls, it must be noted that the machine on which the Login Server database schema resides needs to be able to have LDAP protocol access to the LDAP server. The default port for LDAP communication is port 389, however, it is configurable.
The Oracle9i Application Server HTTP server powered by Apache supports the configuration of virtual hosts. This allows a single machine and port to represent a number of virtual hosts. To configure virtual hosts, you must set this up on both Oracle Portal as well as on the Oracle HTTP Server.
In our example, let's assume that we want to access Oracle Portal as http://www.abc.com as well as http://www.xyz.com. Also, let's assume that the Login Server's URL is http://www.login.com.
The steps for configuring virtual hosts are:
<ORACLE_HOME>/Apache/Apache/conf, open and edit the Oracle HTTP Server configuration file, http.conf. Verify that the contents of the file includes the similar information in the Virtual Hosts section:
### Section 3: Virtual Hosts NameVirtualHost 127.0.0.1 <VirtualHost 127.0.0.1> ServerName www.abc.com </VirtualHost> <VirtualHost 127.0.0.1> ServerName www.xyz.com </VirtualHost> <VirtualHost 127.0.0.1> ServerName www.login.com </VirtualHost>
This example uses the IP address 127.0.0.1, which represents the local machine. This can be any valid IP address.
The domain names specified in the ServerName entries need to be valid domain names. If you are setting up Oracle Portal on a local laptop, make the appropriate entries in your local hosts file.
# Copyright (c) 1993-1995 Microsoft Corp. # # This is a sample HOSTS file used by Microsoft TCP/IP # for Windows NT. # 127.0.0.1 localhost 127.0.0.1 www.abc.com 127.0.0.1 www.xyz.com 127.0.0.1 www.login.com
http://www.login.com.
Thus, you must register www.abc.com, www.xyz.com, and www.login.com as Partner Applications.
www.abc.com.
www.xyz.com.
www.login.com.
ssodatax script to create configuration entries on the Oracle Portal for each of these entry points.
After running the ssodatax script for each of the Partner Applications, the aliases should be correctly configured.
The Oracle Portal architecture is designed around a three-tier architecture that allows any browser to connect to it. This flexible architecture allows each component (browser, Oracle HTTP Server listener, Oracle8i database, and Oracle Portal) to be upgraded individually as required.
When a page is requested from Oracle Portal, the request is made from the browser to the Oracle HTTP Server listener. The returned page is comprised of many types of portlets. A portlet is an area on a portal page that contains data from a particular data source.
The Parallel Page Engine obtains the page metadata from the Portal Repository and is responsible for assembling the portlets on the page. You can tune the Parallel Page Engine for better performance by adding any of the following optional parameters in the zone.properties file.
Once Oracle Portal is deployed for access over the Internet, there are typically other network devices that may complicate the configuration such as firewalls, reverse proxies, server farms, and so on.
A reverse proxy server is a host process which is used as part of a firewall architecture to isolate the internal hosts from the externally accessible host(s) by providing a proxy through which external requests must pass to access internal services. Typically, such a proxy server takes the form of a dual-homed host. This means that it is a host with two network interface cards. One interface connects to the external network, and the other interface connects to the internal network, or demilitarized zone (DMZ) of the firewall.
In this architecture, the browser accesses the server through a hostname which is published by the proxy server. The proxy server then forwards the request to the actual host within the firewall, which could be some other host name.
For this example, let's assume the following:
www.myportal.com
server.company.com.
server.company.com is listening on port 7777.
Complete these steps to configure Oracle Portal for this architecture:
VirtualHost entries that accept the internal host name, but then assert the externally visible host name, using the ServerName directive, so that self-referential URLs rendered on the Oracle Portal pages are valid for the browser.
ServerNames asserted above, so that they can resolve the hostnames that are generated by Oracle Portal, for HTTP calls looping back to fetch portlet content.
ssodatan or ssodatax script(s), as appropriate, using the externally published server names; for example, www.myportal.com
www.myportal.com domain name on a domain name server on the Internet, with IP address 196.12.67.8.
The following figure shows the server names and ports used in the preceding example:
You provide directives in the Oracle HTTP Server configuration file, httpd.conf, which specify the behavior described in the points above. The reverse proxy server contacts the internal middle-tier server as server.company.com over port 7777.
When the Oracle HTTP Server invokes the PL/SQL Gateway (mod_plsql), and mod_jserv, it then passes www.myportal.com as the ServerName and port 80. URLs that are generated by Oracle Portal code use www.myportal.com and port 80.
The directive "useCanonicalName on" instructs Apache to use the ServerName specified. Otherwise, it passes the name used in the Host field of the request.
The relevant sections in the httpd.conf file for the server.company.com Oracle9i Application Server configuration are shown in the following.
### Section 2: 'Main' server configuration...Port 80Listen 7777Listen 80ServerName www.myportal.com...UseCanonicalName On...### Section 3: Virtual Hosts## VirtualHost: If you want to maintain multiple domains/hostnames on# your machine you can setup VirtualHost containers for them.## If you want to use name-based virtual hosts you need to define at# least one IP address (and port number) for them.## This section is mandatory for URLs that are generated by# the PL/SQL packages of the Oracle Portal# These entries dictate that the server should listen on port# 7777, but will assert that it is using port 80, so that# self-referential URLs generated specify www.myportal.com:80# This will create URLs that are valid for the browser since# the browser does not directly see the host server.company.com.NameVirtualHost 123.45.67.8:7777<VirtualHost server.company.com:7777>ServerName www.myportal.comPort 80</VirtualHost># Since the previous virtual host entry will cause all links# generated by the Oracle Portal to use port 80, the server.company.com# server needs to listen on 80 as well since the Parallel Page# Engine will make connection requests to Port 80 to request the# portlets.NameVirtualHost 123.45.67.8:80<VirtualHost server.company.com:80>ServerName www.myportal.comPort 80</VirtualHost>
If you need to support multiple aliases for the published address www.myportal.com, then some additional directives are needed. For example, if the server also needs to be accessible as www.portal.com, then you need to define additional virtual host entries on the internal server. This is so the reverse proxy directs requests from each corresponding published hostname to a related internal host alias which can assert the correct published name.
In this example, the VirtualHost sections appear as follows:
NameVirtualHost 123.45.67.8:7777<VirtualHost server.company.com:7777>ServerName www.myportal.comPort 80</VirtualHost><VirtualHost server2.company.com:7777>ServerName www.portal.comPort 80</VirtualHost>NameVirtualHost 123.45.67.8:80<VirtualHost server.company.com:80>ServerName www.myportal.comPort 80</VirtualHost><VirtualHost server2.company.com:80>ServerName www.portal.comPort 80</VirtualHost>
A local HOSTS file can help resolve domain names that are not normally visible to the internal network. For example, the Oracle9i Application Server host for server.company.com makes requests to itself, but the URLs that it is requesting are referring to www.myportal.com. You must create host entries in the local HOSTS file on that machine allowing it to resolve this name, within the firewall. The hosts entry for this example should include the following lines:
# This is a sample HOSTS file used by Microsoft TCP/IP # for Windows NT. # 127.0.0.1 localhost 123.45.67.8 www.myportal.com
If you do not provide these entries in the local HOSTS file, then you need to set the Oracle9i Application Server host to recognize a proxy server that would take the request out to the Internet and back in through the reverse proxy (www.myportal.com). Avoid this setup as this may result in poor performance.
The purpose of a Load Balancing Router (LBR) is to provide a single published address to the client browsers, and provide a "farm" of Web servers which actually service the requests, based on the distribution of the requests done by the LBR. The LBR itself is a very fast network device which can distribute Web requests to a large number of physical servers.
If you want to install multiple Oracle9i Application Server middle-tier servers to handle a large load, you could configure Oracle Portal as illustrated in the following diagram:
This example shows that each of the servers can handle requests for either the Login Server or Oracle Portal. Each of the middle-tier servers must have DAD entries for each of the databases. A good way to accomplish this is to have the middle-tier servers share a file system that contains the configuration information for the DADs, and allows them to share cache files.
The important points to consider with this configuration include:
www.myportal.com to the external IP address on the LBR.
www.myportal.com to svr1.company.com, svr2.company.com, and svr3.company.com, addressing the request to their IP addresses, but still containing www.myportal.com in the Host: field of the HTTP request.
www.myportal.com, and their httpd.conf files assert that name as the ServerName. Hence the names svr1, svr2, and so on are irrelevant.
www.myportal.com, each pointing to its own IP address.
It is fairly typical to have a firewall with a SQL*Net proxy between the application server and the database for Oracle installations. Keep in mind though that the Oracle Portal architecture requires HTTP connects from the database to the middle-tier servers, for example, when the Oracle Portal makes an HTTP request to the Login Server to get the list of external applications. Or, when the Oracle Portal repository makes an HTTP request to a particular provider which may be a Web provider, potentially outside the Intranet firewall. Keep this communication path in mind when planning where firewalls should go and what traffic should be allowed through them.
You need to allow HTTP traffic to pass on the ports that are being used, through any firewall set up between the middle-tier and the database on which the Oracle Portal code resides.
Similarly, if the Login Server is setup for LDAP authentication, then LDAP traffic must be allowed to reach the LDAP server. The LDAP calls are made from the Login Server database instance.
However you choose to configure the Oracle HTTP Server powered by Apache listener, you can optimize performance by setting an approximate number of simultaneous requests that can be handled by the Apache listener.
On UNIX, in particular, since Apache is process-based, each process needs to open a database connection for each DAD that has requested it. As a result, the number of requests can be quite high, which may result in clients being "locked out" if the number of sessions allowable has been exceeded. However, setting too high of a value unnecessarily consumes resources.
The scenario is described below:
The first session is for "portal30" and the second is for "portal30_public".
In this case, the first session is for "portal30_sso" and the second session is for "portal30_sso_public".
MaxClients. It defaults to 150.
If each user were logging in and working in Oracle Portal, then scenario (1) and (2) above would result in four sessions per process. The total number of sessions for such a scenario is calculated as follows:
150 * 4 = 600
600 sessions and approximately 300 database connections (2 sessions per connection)
Since login frequency is generally lower than Oracle Portal access frequency, it makes sense to configure the Login Server on a separate Oracle HTTP Server powered by Apache listener. The objective is to tune down the MaxClient setting to a value that is reasonable without affecting the needs of the portal system.
Oracle Portal makes extensive use of Apache mod_plsql which maintains a pool of connections to the database. The MaxClient parameter tunes the number of Apache processes which directly relates to the number of database connections pooled by mod_plsql.
MaxClients parameter, edit this accordingly in the Apache configuration file, httpd.conf, which is located in:
<ORACLE_HOME>/Apache/Apache/conf/
Tune down the MaxClients setting to control the number of requests that Apache services on the Apache listener. This ultimately controls the maximum number of sessions that could be established.
MaxClients parameter according to the needs of the Login Server and the needs of Oracle Portal, without affecting each other. This parameter directly corresponds to the number of sessions established and to the maximum workload that the Apache listener can handle on the Portal listener.
The MaxClients section in the httpd.conf file is shown below:
# Limit on total number of servers running, i.e., limit on the number # of clients who can simultaneously connect --- if this limit is ever # reached, clients will be LOCKED OUT, so it should NOT BE SET TOO LOW. # It is intended mainly as a brake to keep a runaway server from taking # the system with it as it spirals down... # MaxClients 150
|
 Copyright © 2001 Oracle Corporation. All Rights Reserved. |
|