3
Configuring Oracle9iAS Single Sign-On

Oracle9iAS Single Sign-On is a component of Oracle9i Application Server that enables users to log in to multiple Web-based applications, such as expense reports, e-mail, and benefits information, using a single user name and password. As such, Oracle9iAS Single Sign-On serves as the security gateway for all Oracle9iAS features.

This chapter explains how to configure security features for Oracle9iAS Single Sign-On. It also provides a conceptual overview of the product.

The chapter covers the following topics:

• Single Sign-On Overview

• Configuring Security Features for Oracle9iAS Single Sign-On

• Enabling the Single Sign-On Server for SSL

• Configuring Oracle9iAS Single Sign-On for Digital Certificates

• Enabling Timeouts

• Enabling IP Checking

• Managing Password Policies

Single Sign-On Overview

This section takes a quick look at the salient features of Oracle9iAS Single Sign-On. Each component is described in the following sections.

See Also: For more detailed information about Oracle9iAS Single Sign-On, refer to the Oracle9iAS Single Sign-On Administrator's Guide in the Oracle9iAS Documentation Library.

• Oracle9iAS Single Sign-On Server (Single Sign-On server)

  The server consists of program logic in the Oracle9iAS database that enables users to log in securely to single sign-on enabled applications.

• Single Sign-On Applications

  Single sign-on applications take two forms: partner and external. Partner applications are those that delegate authentication to the Single Sign-On server. Examples of such applications are Oracle9iAS Portal, Oracle9iAS Discoverer and Oracle9iAS Reports Services. External applications require reauthentication, but the Single Sign-On server performs this function for the user. Examples include Yahoo! Mail and Oracle Mobile.

  Partner applications use either an Oracle HTTP Server authentication module called mod_osso or the Oracle9iAS Single Sign-On Software Development Kit (SDK) to redirect first-time user requests to the Single Sign-On server and to validate additional application requests once a user is logged in. Applications integrated with mod_osso are actually not partner applications at all, because only mod_osso is registered with the Single Sign-On server. SDK-integrated applications, on the other hand, must be registered individually.

• Mod_osso

  The Oracle HTTP Server authentication module mod_osso is an alternative to the Single Sign-On SDK, used in earlier releases of Oracle9iAS Single Sign-On to integrate partner applications. Mod_osso simplifies the authentication process by serving as the sole partner application to the Single Sign-On server, rendering authentication transparent for Oracle9iAS applications.

• Single Sign-On SDK

  The Single Sign-On Software Developer's Kit consists of application programming interfaces for PL/SQL and Java. It also contains sample code that explains how to implement these interfaces. The SDK ships separately with Oracle9iAS. As such, its APIs must be incorporated into partner applications. Mod_osso spares application developers the burden of integrating these APIs.

Configuring Security Features for Oracle9iAS Single Sign-On

Oracle9iAS Single Sign-On is installed automatically as part of an Oracle9iAS infrastructure installation. At install time, users are offered the option of registering mod_osso with the Single Sign-On server. They may elect to use the SDK instead.

Beyond simple authentication, Oracle9iAS Single Sign-On has a few security features that must be configured after installation if an enterprise elects to use them. These features are as follows:

• Secure Sockets Layer (SSL)

• Digital Certificates

• Global User Inactivity Timeout

• IP Checking

Password policies, another Oracle9iAS Single Sign-On security feature, are managed in Oracle Internet Directory.

The rest of this chapter describes how to configure the security features just enumerated.

See Also: For a more detailed treatment of this topic, see Oracle9iAS Single Sign-On Administrator's Guide in the Oracle9iAS Documentation Library. If you specifically require SSL connections between the Single Sign-On server and Oracle Internet Directory, refer to Chapter 3 in the Oracle9iAS Single Sign-On Administrator's Guide.

Enabling the Single Sign-On Server for SSL

The Single Sign-On server can be enabled for Secure Sockets Layer (SSL) at install time. If the administrator does not select this option, SSL must be configured manually.

To configure the Single Sign-On server for SSL:

1. Configure the Oracle HTTP server to use SSL.

   See Also: "Using Secure Sockets Layer (SSL) to Authenticate Users" for information about configuring Oracle HTTP Server to use SSL.

2. Change all references of HTTP in Single Sign-On URLs to HTTPS. The script ssocfg.sh is provided for this purpose. It can be found at the following location:

   IAS_HOME/sso/bin

   Enter the command, using the following syntax:

   ssocfg.sh protocol host port [sso_schema_name]

   In this case, protocol is https. (To change back to HTTP, use http.) The parameter new_host is the host name of the Web listener for the Single Sign-On server. You can either assign a new host name or use an existing one. The parameter new_port is the port number of the listener, and sso_schema_name is the name of the Single Sign-On schema. The default schema name is orasso. Note from the syntax that this last parameter is optional.

   Here is an example:

   ssocfg.sh https login.acme.com 443 
   
   

   Port 443 is the default port number for Single Sign-On over SSL.

3. Protect Single Sign-On URLs to use SSL. In the dads.conf file, use the following HTTP directive to protect the Single Sign-On DAD with SSL.

   <IfDefine SSL>
      <Location /pls/orasso>
         SSLRequireSSL
      </Location>
   </IfDefine>
   
   

   The dads.conf file can be found at the following location:

   IAS_HOME/Apache/modplsql/conf/dads.conf

Configuring Oracle9iAS Single Sign-On for Digital Certificates

Oracle9iAS Single Sign-On users have the option of using digital certificates instead of the SSO user name and password to authenticate. This form of authentication involves an exchange of X.509 certificates between client and server over Secure Sockets Layer (SSL).

Oracle9iAS Single Sign-On can be configured for SSL both with and without client certificates. The first option, server-side authentication, offers a strong degree of security. Still, the user's password is vulnerable to attack--either by guesswork or by brute force. Certificate-based authentication on both client and server sides, on the other hand, makes it difficult to sniff or modify data or to impersonate the client or server.

This section covers the following topics:

• System Requirements

• Configuration Tasks

System Requirements

The following criteria must be met before certificate-enabled single sign-on can proceed:

• The Single Sign-On server and Oracle Internet Directory, Oracle9iAS, Release 2, must be installed.

• The Oracle HTTP Server must have a valid server certificate installed.

• The distinguished name (DN) of the client certificate must be chosen in such a way that it contains some information about the SSO user name, or nickname, and, optionally, the subscriber name for this user name. The cn attribute within the DN, for instance, might be the user's nickname (cn=jsmith). An o attribute might be the user's subscriber name (o=acme).

• The certificate of the client certificate issuer must be installed as a trusted certificate in the Single Sign-On server.

• The certificate of the server certificate issuer must be installed as a trusted certificate in the user's browser.

Configuration Tasks

Certificate-enabled single sign-on is not a default option in Oracle9iAS, and it must be configured manually. The follow components may require configuration:

• Oracle HTTP Server (SSL)

• Single Sign-On DAD (mod_plsql)

• User Name Mapping Module

• Oracle Internet Directory

• Single Sign-On Server

Oracle HTTP Server (SSL)

To configure the Oracle HTTP server, navigate to the server configuration file, using the following path:

IAS_HOME/Apache/Apache/conf/httpd.conf

In the SSL Virtual Host Context section of the httpd.conf file, add the parameters listed in Table 3-1:

Table 3-1 Oracle HTTP Server Parameters for Certificate-Enabled Single Sign-On  

Parameter	Description
ServerName	The name of the server to be enabled for SSL
SSLEngine [on | off]	Setting the SSLEngine parameter to on enables the server for SSL
SSLWallet file:	The location, or path, of the server wallet
SSLVerifyClient	The verification type for client certificates. The options are as follows: none--SSL without certificates optional--server certificate only require--server and client certificates

When configured properly, the SSL Virtual Host Context section of the httpd.conf file looks similar to the example that follows.

## SSL Virtual Host Context
##
#
# file otherwise your virtual host will not respond to SSL requests.
#
<VirtualHost _default_:443>
#  General setup for the virtual host
DocumentRoot "/private/oracle/work/Apache/Apache/htdocs"
ServerName db_host:db_port:db_sid
ServerAdmin you@your.address
ErrorLog /pivate/oracle/work/Apache/Apache/logs/error_log
TransferLog /private/oracle/work/Apache/Apache/logs/access_log

#   SSL Engine Switch:
#   Enable/Disable SSL for this virtual host.
SSLEngine on

#   Server Wallet:
#   The server wallet contains the server's certificate, private key
#   and trusted certificates. Set SSLWallet at the wallet directory
#   using the syntax:  file:<path-to-wallet-directory>

SSLWallet file:/private/iAS/wallet

#   Certificate Revocation Lists (CRL):
#   Set the CA revocation path where to find CA CRLs for client
#   authentication or alternatively one huge file containing all
#   of them (file must be PEM encoded)
#   Note: Inside SSLCARevocationPath you need hash symlinks
#         to point to the certificate files. Use the provided
#         Makefile to update the hash symlinks after changes.
#SSLCARevocationPath /private/oracle/Apache/Apache/conf/ssl.crl
#SSLCARevocationFile /private/oracle/Apache/Apache/conf/ssl.crl/ca-
 bundle.crl
#   Client Authentication (Type):
#   Client certificate verification type and depth.  Types are
#   none, optional, require and optional_no_ca.  Depth is a
#   number which specifies how deeply to verify the certificate
#   issuer chain before deciding the certificate is not valid.
SSLVerifyClient optional

</VirtualHost>

Single Sign-On DAD (mod_plsql)

Configuring the Oracle HTTP Server PL/SQL module for certificates entails adding environment variables to the database access descriptor (DAD) for the Single Sign-On server. To add these variables, navigate to the DAD configuration file, using the following path:

IAS_HOME/Apache/modplsql/conf/dads.conf

In the dads.conf file, add the PlsqlCGIEnvironmentList parameter and the variables in Table 3-2.

Table 3-2 dads.conf Environment Variables  

Variable	Description
SSL_CLIENT_S_DN	The distinguished name of the user
SSL_CLIENT_CERT	The client certificate in base 64 format

mod_plsql must pass these variables to the user name mapping module.

When configured properly, the relevant section of the dads.conf file looks something like this:

<IfModule mod_plsql.c>
<Location /pls/orasso>
  SetHandler pls_handler
  Order deny,allow
  PlsqlDatabaseConnectString    db_host:db_port:db_sid
  PlsqlDatabasePassword         password
  PlsqlDatabaseUsername         orasso
  PlsqlDefaultPage              orasso.home
  PlsqlDocumentTablename        orasso.wwdoc_document
  PlsqlDocumentPath             docs
  PlsqlDocumentProcedure        orasso.wwdoc_process.process_download
  PlsqlEnableConnectionPooling  On
  PlsqlAuthenticationMode       SingleSignOn
  PlsqlPathAlias                url
  PlsqlPathAliasProcedure       orasso.wwpth_api_alias.process_download
  PlsqlSessionCookieName        orasso
  PlsqlCGIEnvironmentList       SSL_CLIENT_		S_DN, SSL_CLIENT_CERT
</Location>

<IfDefine SSL>
<Location /pls>
  SSLOptions +ExportCertData +StdEnvVars
</Location>
</IfDefine>

User Name Mapping Module

The module that maps a user DN to a user name is actually the package ssodnmap.pks, which is located in the following directory:

IAS_HOME/sso/admin/plsql/sso

If the user accepts the default implementation for the package, no file configuration is required. The default implementation assumes that the user's DN in the directory is the same as the certificate DN.

See Also: Those who want to customize the module can view the file ssodnmap.pks in Chapter 4 of Oracle9iAS Single Sign-On Administrator's Guide, "Configuring Single Sign-On for Certificates." This document is located in the Oracle9iAS Documentation Library.

Oracle Internet Directory

For certificate-based authentication to be successful, the user certificate must be present in Oracle Internet Directory. If the certificate is issued by an in-house certificate authority (CA) or by Oracle's CA, it might be possible to publish the certificate in the directory automatically. If the certificate issuer is a third-party CA, a self-service application can fulfill this function.

See Also: To determine whether a self-service application is feasible, see the procedures in "Configuring Single Sign-On for Certificates" in Chapter 4 of Oracle9iAS Single Sign-On Administrator's Guide in the Oracle9iAS Documentation Library.

Single Sign-On Server

To enable the Single Sign-On server for SSL, all references to HTTP in SSO URLs must be changed to HTTPS. The script ssocfg.sh is provided for this purpose.

To run ssocfg.sh:

1. Go to the directory that contains the script. The path is as follows:

   IAS_HOME/sso/bin

2. Enter the command, using the following syntax:

   ssocfg.sh protocol host port [sso_schema_name]
   

   In this case, protocol is https. (To change back to HTTP, use http.) The parameter new_host is the host name of the Oracle HTTP Server listener for the Single Sign-On server. You can either assign a new host name or use an existing one. The parameter new_port is the port number of the listener, and sso_schema_name is the name of the SSO schema. The default schema name is orasso. This last parameter is optional.

   Here is an example:

   ssocfg.sh https login.acme.com 443 
   
   

   Port 443 is the default port number for single sign-on over SSL.

Enabling Timeouts

Oracle9iAS Single Sign-On has two timeout features: the single sign-on session timeout and the global user inactivity timeout. The first can be configured through the SSO user interface. The second must be configured from the command line.

This section covers the following topics:

• Configuring the SSO Session Timeout

• Configuring the Global User Inactivity Timeout

Configuring the SSO Session Timeout

By default, an SSO session lasts eight hours. The administrator can specify a shorter or longer period on the Edit SSO Server page.

To change the SSO session duration:

1. Enter a URL of the following form:

   http://host:port/pls/Single_Sign_On_DAD

   where host is the name of computer on which the Single Sign-On server is located, port is the port number of the server, and Single_Sign_On_DAD is the database access descriptor for the SSO schema. The default DAD is orasso.

   The Access Partner Applications page appears.

2. Select Login in the upper right corner of the Access Partner Applications page.

   The Single Sign-On Login page appears.

3. Enter your administrative user name and password, and then click the Login button.

4. The Single Sign-On home page appears.

5. From the Single Sign-On home page navigate, in succession, to the following pages:

   --SSO Server Administration

   --Edit SSO Server Configuration

   --Edit SSO Server

6. On the Edit SSO Server page, under the heading SSO Session Policy, enter the number of hours that a user can be logged in without timing out.

Configuring the Global User Inactivity Timeout

The Single Sign-On server uses the Web cookie SSO_TIMEOUT_ID to track user inactivity across mod_osso-protected applications and to enable these applications to force users to reauthenticate if they have been idle for a preconfigured amount of time. The global user inactivity timeout is a useful feature for sensitive applications that may require a much shorter user inactivity timeout than the SSO session timeout.

The global user inactivity timeout is not configured by default. You must enable it by running the script ssogito.sql and by modifying the file mod_osso.conf.

To configure the global user inactivity timeout:

1. Log in to SQL*Plus using the SSO schema name and password. The default is orasso/orasso.

2. Run the script ssogito.sql by entering the following command:

   SQL> @ssogito.sql
   
   

3. Running the script brings up a list of fields.

4. In the field "Enter value for timeout_cookie_domain:" enter a domain name that is common to all of the applications enabled by the Single Sign-On server.

   Note: If this field is left blank, the domain name defaults to the host name for the Single Sign-On server.

5. In the field "Enter value for inactivity period:" enter the length of the desired inactivity period. For example, you can enter 15 minutes.

6. To enable the new settings, select the return key. To cancel the transaction, select the return key twice.

7. Once you have completed a transaction, the script furnishes you a summary of the new timeout settings.

8. In the file mod_osso.conf, make sure that the parameter ossoIdleTimeout exists and that it is set to on.

Enabling IP Checking

IP checking can be enabled for both the Single Sign-On server and for mod_osso. On the Single Sign-On server, IP checking is activated on the Edit SSO Server page of the SSO user interface. An IP check verifies that the IP address of the browser is the same as the IP address of the authentication request. On the mod_osso side, the directive OssoIPCheck verifies that the user who authenticates to the Single Sign-On server is the same user who is accessing a mod_osso-protected application.

This section covers the following topics:

• Enabling IP Checking for the Oracle9iAS Single Sign-On Server

• Enabling IP Checking for Mod_osso

  Note: IP checking should be enabled only if a browser can communicate with both the Single Sign-On server and the HTTP server without using proxy servers. This is because proxies may not use static IP addresses.

Enabling IP Checking for the Oracle9iAS Single Sign-On Server

To enable IP checking, use the following steps:

1. Navigate to the Edit SSO Server page using the procedures presented in "Configuring the SSO Session Timeout".

2. On the Edit SSO Server page, under the heading SSO Session Policy, select the check box Verify IP Addresses for Requests Made to the Single Sign-On Server.

Enabling IP Checking for Mod_osso

To enable mod_osso for IP checks, the directive OssoIPCheck in the mod_osso.conf file must be set to on. If OssoIPCheck is enabled when proxy servers are used, then an error message might be displayed.

Managing Password Policies

The SSO user password is stored in Oracle Internet Directory as an attribute of the user's entry. Users can change their passwords either in the SSO user interface or through Delegated Administration Service (DAS). Oracle Directory Manager, a GUI tool, enables the directory administrator to adjust password rules, password expiry, and account lockout to suit enterprise needs.

See Also: To learn how to configure password policies, see "Managing Password Policies by Using Oracle Directory Manager" and "Setting Password Policies by Using Command-Line Tools." Both topics can be found in Chapter 17 of Oracle Internet Directory Administrator's Guide in the Oracle9iAS Documentation Library.