3 Configuring Single Sign-On in an Enterprise Deployment Topology

The following sections provide brief information and additional resources for OracleAS Single Sign-On in an enterprise deployment topology:

About High Availability
About Security
Multiple Single Sign-On Middle Tiers with One Oracle Internet Directory

3.1 About High Availability

The availability of a system or any component in that system is defined by the percentage of time that it works normally. A system works normally when it meets its correctness and performance specifications.

You should become familiar with basic concepts of how high availability affects Oracle Application Server security features such as Oracle Internet Directory and OracleAS Single Sign-On.

For more information, see the Oracle Application Server 10g High Availability Guide.

3.2 About Security

Oracle Application Server provides a comprehensive security framework supporting all its components, as well as third-party and custom applications deployed on the application server. The framework is based on OracleAS Single Sign-On for authentication, Oracle Internet Directory for authorization and centralized user provisioning, Oracle HTTP Server for the Web server component, and the Oracle Application Server Java Authentication and Authorization Service (JAAS) provider for security in Java2 Enterprise Edition (J2EE) applications.

For complete information about security in Oracle Application Server, see the Oracle Application Server 10g Security Guide. Updated information can always be found on the Oracle Technology Network (OTN) at http://otn.oracle.com/.

Additionally, refer to the documentation for each component regarding security in that component.

3.3 Multiple Single Sign-On Middle Tiers with One Oracle Internet Directory

The simplest high availability scenario involves failover within the single sign-on instance itself, at the middle tier. Adding middle tiers increases scalability and therefore makes the single sign-on server more available.

In this configuration, a single HTTP load balancer is placed in front of two or more Oracle HTTP servers. At the backend is one directory server and one identity management infrastructure database. The purpose of the load balancer is to publish a single address to single sign-on partner applications while providing a farm of single sign-on middle tiers that actually service the application requests. The HTTP load balancer can detect when one of these Oracle HTTP server instances has failed and can then fail over requests to another instance.

3.3.1 Usage Scenario

The usage scenario presented here assumes the following hypothetical configurations:

The directory server and identity management infrastructure database are located at oid.mydomain.com.
There are two single sign-on middle tiers. One is installed on host sso1.mydomain.com, IP address 138.1.34.172. The other is installed on sso2.mydomain.com, IP address 138.1.34.173. Both servers listen on non-SSL port 7777. Both are configured to use the directory and identity management infrastructure database located at oid.mydomain.com.

The address of the single sign-on server that is published to partner applications is sso.mydomain.com, IP address 138.1.34.234. The HTTP load balancer is configured to listen on sso.mydomain.com, port 80. It load balances user requests between sso1.mydomain.com and sso2.mydomain.com.

Notes:

In this scenario, the load balancer is listening on port 80, a non-SSL port number. If the load balancer is configured to use SSL to interact with the browser, a different port number must be selected. The default SSL port number is 443.
In this scenario and the one immediately following, two single sign-on middle tiers are used. There can, in fact, be any number of middle tiers.

Figure 3-1 shows two single sign-on middle tiers configured to use a single instance of Oracle Internet Directory.

Figure 3-1 Two Single Sign-On Middle Tiers, One Oracle Internet Directory

This

Description of the illustration sso.gif

3.3.2 Configuration Steps

Setting up the single sign-on system presented in Figure 3-1 involves the following tasks:

Install the identity management infrastructure database, the directory server and the single sign-on servers
Configure the Oracle HTTP servers on the single sign-on middle tiers
Configure the HTTP load balancer
Configure the identity management infrastructure database
Reregister mod_osso on the single sign-on middle tiers

Install the identity management infrastructure database, the directory server and the single sign-on servers

Choose a single sign-on server name that will be published to partner applications. This will also be the address of the load balancer. In the scenario presented here, the address is sso.mydomain.com.
Install the Oracle Application Server infrastructure on oid.mydomain.com, choosing the option "Identity Management and Oracle Application Server Metadata Repository." When presented with the component list for this installation type, choose Oracle Internet Directory only.
Install the Oracle Application Server infrastructure on the middle tiers sso1.mydomain.com and sso2.mydomain.com, again choosing the option "Identity Management and Oracle Application Server Metadata Repository."

When presented with the component list for this installation type, choose Oracle Application Server Single Sign-On only. When the Oracle Universal Installer asks you to name the directory server associated with these single sign-on instances, enter oid.mydomain.com.

Note:

The Oracle Application Server installer, by default, assigns port numbers from a range of numbers. If you want to assign a different port number to a component, see "Static Port Numbers" in Oracle Application Server 10g Installation Guide

Configure the Oracle HTTP servers on the single sign-on middle tiers

When a load balancer is placed between the user and the Oracle HTTP Server, the effective URL of the single sign-on server changes. The Oracle HTTP configuration file httpd.conf on both single sign-on middle tiers must be modified to reflect this change. This file can be found at $ORACLE_HOME/Apache/Apache/conf.

Add the following lines to the httpd.conf file on sso1.mydomain.com and sso2mydomain.com:
```
KeepAlive off
ServerName sso.mydomain.com
Port 80
```
This step configures the Oracle HTTP servers at the single sign-on middle tiers to listen at the externally published name, which, in the scenario presented, is sso.mydomain.com.
If you configure the HTTP load balancer to use SSL, configure mod_certheaders on both sso1.mydomain.com and sso2.mydomain.com. This module enables the Oracle HTTP Server to treat requests that it receives over HTTP as SSL requests. The sequence is as follows:
1. In the httpd.conf file on both middle tiers, enter the following line:
```
LoadModule certheaders_module libexec/mod_certheaders.so
```
2. If you are using Oracle Application Server Web Cache as a load balancer, enter the following line:
```
AddCertHeader HTTPS
```
  If you are using a hardware load balancer, enter the following line:
```
SimulateHttps on
```
3. Synchronize system clocks between both middle tiers.
4. Execute the following command to update the Distributed Cluster Management (DCM) schema with the changes:
```
$ORACLE_HOME/dcm/bin/dcmctl updateConfig -v -d
```

Configure the HTTP load balancer

The HTTP load balancer used can be hardware such as BigIP, Alteon, or Local Director or software such as Oracle Application Server Web Cache.

Hardware Load Balancer

If you are using a hardware load balancer, configure one pool of real servers with the addresses 138.1.34.172 and 138.1.34.173. Configure one virtual server with the address 138.1.34.234. This virtual server is the external interface of the load balancer. For instructions, consult the documentation provided by your load balancer vendor.
Software Load Balancer

If you are using Oracle Application Server Web Cache to load balance connection requests, see both of the following links:

"Routing Single Sign-On Server Requests" and "Leveraging Oracle Identity Management Infrastructure" in Oracle Application Server Web Cache Administrator’s Guide.

Note:
For optimal performance, use a hardware load balancer.

Configure the identity management infrastructure database

Run the script ssocfg on one of the single sign-on middle tiers. This script configures the single sign-on server to accept authentication requests from the externally published address of the single sign-on server. Using the example provided, the script would be executed in the following way:

UNIX:

$ORACLE_HOME/sso/bin/ssocfg.sh http sso.mydomain.com 80

Windows NT/2000:

%ORACLE_HOME%\sso\bin\ssocfg.bat http sso.mydomain.com 80

Note that the command example provides the listener protocol, host name, and port number of the load balancer as arguments. Recall that the load balancer address is the externally published address of the single sign-on server. If the load balancer is configured to use SSL, replace non-SSL port 80 with SSL port 443 and http with https.

After executing ssocfg, restart the single sign-on middle tiers:

$ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=OC4J_SECURITY

Finally, test the application:

http://sso.mydomain.com/pls/orasso

Reregister mod_osso on the single sign-on middle tiers

On both middle tier machines, reregister mod_osso as the partner application sso.mydomain.com.

To reregister mod_osso on sso1.mydomain.com:

On the computer sso1.mydomain.com, log in to the single sign-on administration pages as the single sign-on administrator. Be sure to log in to http://sso.mydomain.com/pls/orasso.
Use the Administer Partner Applications page to delete the existing entry for the partner application sso1.mydomain.com.
Set the environment variable ORACLE_HOME to point to the Oracle home for sso1.mydomain.com. Include $ORACLE_HOME/jdk/bin in the PATH variable.

Run the registration script. For the URLs, be sure to substitute values appropriate for your installation. The script creates a partner application called sso.mydomain.com.

$ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/sso/lib/ossoreg.jar
-oracle_home_path orcl_home_path
-site_name site_name
-config_mod_osso TRUE
-mod_osso_url mod_osso_url
-u userid
[-virtualhost virtual_host_name]
[-update_mode CREATE | DELETE | MODIFY]
[-config_file config_file_path]
[-admin_id adminid]
[-admin_info admin_info]

For a description of command parameters, please see "Registering mod_sso" in Chapter 4 of the Oracle Application Server Single Sign-On Administrator’s Guide.

To reregister mod_osso on sso2.mydomain.com:

On the computer sso2.mydomain.com, log in to the single sign-on administration pages as the single sign-on administrator. Be sure to log in to http://sso.mydomain.com/pls/orasso.
Use the Administer Partner Applications page to delete the existing entry for the partner application sso2.mydomain.com.
Create a clear text osso.conf file using the following steps:
1. Click the Edit Partner Application Page for sso.mydomain.com.
2. On the Edit Partner Application page, make a note of the parameters sso_server_version, cipher_key, site_id, site_token, login_url, logout_url, and cancel_url. You will use the same values that you used when you registered the application on sso1.mydomain.com. The idea is to maintain the same site id, site token, and cipher key between both middle tiers. This enables these servers to act as clones of each other.
3. Create the osso.conf file, using a text editor:
```
sso_server_version=v1.2
cipher_key=encryption_key
site_id=id
site_token=token
login_url=http://sso.mydomain.com/pls/orasso/orasso.wwsso_app_admin.ls_login
logout_url=http://sso.mydomain.com/pls/orasso/orasso.wwsso_app_admin.ls_logout
cancel_url=http://sso.mydomain.com:80/
```
Log in to sso2.mydomain.com as root; then navigate to the osso.conf file that you created in Step 3. Obfuscate the file:
```
$ORACLE_HOME/Apache/Apache/bin/iasobf osso.conf $ORACLE_HOME/Apache/Apache/ 
conf/osso/osso.conf
```

Restart the Oracle HTTP Server:

$ORACLE_HOME/opmn/bin/opmctl restartproc type=ohs

Change the base URL for the Delegated Administration Service (DAS), using the oidadmin tool:
1. Start the tool:
```
$ORACLE_HOME/bin/oidadmin
```
2. Log in to Oracle Directory Manager as cn=orcladmin.
3. Navigate to the entry that contains the attribute orcldasurlbase:
```
cn=OperationalURLs,cn=DAS,cn=Products,cn=OracleContext
```
4. Change the attribute to the following value:
```
http://sso.mydomain.com/
```
  Make sure that you include the backslash after the host name. When you click useradmin in a portal, the URL for useradmin is appended to this value.
Test the partner application oiddas:
```
http://sso.mydomain.com/oiddas
```