Skip Headers

Oracle9iAS Single Sign-On Administrator's Guide
Release 2 (9.0.2)

Part Number A96115-01
Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Go to previous page Go to next page

1
Single Sign-On Basics

Oracle9iAS Single Sign-On is a component of Oracle9i Application Server (iAS) that enables users to log in to all features of the iAS product complement, as well as to other Web applications, using a single user name and password.

Oracle9iAS Single Sign-On provides the following benefits:

This chapter covers the following topics:

Oracle9iAS Single Sign-On Components

Oracle9iAS Single Sign-On consists of the following components:

Single Sign-On Server

The Single Sign-On server consists of program logic in the Oracle9iAS database that enables users to log in securely to Single Sign-On applications such as expense reports, mail, and benefits. These applications take two forms: partner applications and external applications. In both cases, the user gains access to several applications by authenticating only once.

Partner Applications

Oracle9iAS applications delegate the authentication function to the Single Sign-On server. For this reason, they are called partner applications. Either an HTTP authentication module called mod_osso or the Single Sign-On Software Development Kit (SDK) enables these applications to accept HTTP headers in lieu of a user name and password once the user has logged into the Single Sign-On server.

A partner application is responsible for determining whether a user authenticated by Oracle9iAS Single Sign-On has the requisite privileges for using the partner application. It also controls user access within the application.

Examples of partner applications include Oracle9iAS Portal, Oracle9iAS Discoverer, and the Single Sign-On server itself.

External Applications

External applications do not delegate authentication to the Single Sign-On server. Instead, they display HTML login forms that ask for application user names and passwords.

Examples of external applications that use HTML login forms include Oracle Mobile and Yahoo! Mail. A unique username and password may be required to access each external application.

The Single Sign-On server can be configured to provide user names and passwords to external applications on behalf of users once they are logged into the Single Sign-On server. Users have the option of storing credentials for external applications in the Single Sign-On database. The Single Sign-On server uses the Single Sign-On user name to transparently locate and retrieve application names and passwords and log the user in to the application. To save an application user name and password, the user selects the Remember My Login Information For This Application check box when first logging in to the application.

Mod_osso

Mod_osso is an HTTP module that provides authentication to iAS applications. It is an alternative to the Single Sign-On SDK, used in earlier releases of Oracle 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 iAS applications. Thus, the administrator for these applications is spared the burden of integrating them with the SDK.

After authenticating the user, mod_osso transmits the simple header values that iAS applications require to validate the user. These include the following:

For details about the attributes that the Single Sign-On server passes to mod_osso in the URLC token, see Table 3-1, "User Attributes Passed to Partner Applications" in Chapter 3, "Directory-Enabled Single Sign-On." To learn how to develop applications using mod_osso, see Chapter 2 in Oracle9iAS Single Sign-On Application Developer's Guide.

Single Sign-On Software Development Kit

The Single Sign-On SDK can be used to create partner applications. As such, the SDK is an alternative to mod_osso. Note though that mod_osso is easier to integrate with the Single Sign-On server because developers need not incorporate Single Sign-On application programming interfaces (APIs) into applications. The SDK consists of PL/SQL and Java APIs as well as sample code that demonstrates how these APIs might be implemented.

See Also:

Chapter 3, "Single Sign-On Software Development Kit", in Oracle9iAS Single Sign-On Application Developer's Guide

Oracle9iAS Single Sign-On Processes

This section describes the following Oracle9iAS Single Sign-On processes:

Accessing the Single Sign-On Server

Nonadministrative users first gain access to the Single Sign-On server by entering the URL of a partner application such as Oracle9iAS Portal or Oracle9iAS Discoverer. Entering such a URL invokes the Single Sign-On login screen. Once they have entered the correct user name and password, users can gain access to other partner applications and to external applications without having to provide credentials again.

Administrative users can access the adminstrative home page for Single Sign-On by typing a URL of the following form:

http://host:port/pls/Single_Sign-On_DAD

where host is the computer where 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 Single Sign-On schema.

The default DAD is orasso.

See Also:

"Accessing the Single Sign-On Administration Pages" in Chapter 2, "Administering Oracle Single Sign-On"

Authentication Flow for Oracle Single Sign-On

Figure 1-1 shows what happens when a user requests the URL for a partner application using the Oracle HTTP authentication module mod_osso.

Figure 1-1 Single Sign-On With mod_osso

Text description of ssoag004.gif follows
Text description of the illustration ssoag004.gif

  1. The user requests a URL through a Web browser

  2. The Web server looks for a mod_osso cookie for the user. If the cookie exists, the Web server extracts the user's identity and credentials and uses this information to log the user in to the requested application.

  3. If the cookie does not exist, the Web server redirects the user to the Single Sign-On server.

  4. The Single Sign-On server looks for its own cookie in the browser. If it finds none, it tries to authenticate the user. If authentication is successful, the Single Sign-On server creates a cookie in the browser as a reminder that the user has been authenticated.

  5. The Single Sign-On server returns the user's encrypted identity and credentials to the Web server.

  6. The Web server creates its own cookie for the user in the browser and redirects the user to the requested URL.

  7. The second authentication call to mod_osso is approved.

If, during the same session, the user again seeks access to the same or to a different partner application, the user is not prompted for a username and password, because the application can obtain this information from the mod_osso session cookie.

Mod_osso redirects the user to the Single Sign-On server only if the requested URL is protected. Some protected applications may have public URLs. These require no redirection to the Single Sign-On server.

Accessing an External Application

External applications are accessible only through Oracle9iAS Portal, a Single Sign-On partner application.

This section contains these topics:

Accessing the External Applications Portlet in Oracle9iAS Portal

In the lower left corner of the Portal home page, select External Applications Portlet; then, from the list of external applications that appears, select an application.

Authenticating to an External Application for the First Time

Selecting an external application in the External Applications portlet begins the external application login procedure. Oracle Single Sign-On uses the following process if the user is accessing an external application for the first time.

  1. The external application login procedure checks the Single Sign-On server password store for the user's credentials for the requested external application. If it finds that the user has no such credentials, the Single Sign-On server prompts the user for them.

  2. The user enters the user name and password. The user can save these credentials in the Single Sign-On server password store by selecting the Remember My Login Information check box on the application login screen.

  3. If the user elects to save the credentials in the Single Sign-On server password store, the server uses these credentials to construct a login form to submit to the login processing routine for the external application. This routine has been preconfigured by the Single Sign-On server administrator and is associated with the requested application.

  4. The Single Sign-On server sends the form to the client browser, with a directive to post it immediately to the external application.

  5. The client posts the form to the external application and logs the user in.

If the user declines to save her credentials in the Single Sign-On password store, she must enter a user name and password each time she logs in to the application.

Authenticating to an External Application After the First Time

If the user saved her credentials when accessing an external application for the first time, The Single Sign-On server retrieves her credentials for her during subsequent logins. The process works like this:

  1. The user selects one of the links in the External Applications portlet of Oracle Portal.

  2. The external application login procedure checks the password store for the user's credentials.

  3. The Single Sign-On server finds the user's credentials and uses them to construct a login form to submit to the login processing routine for the external application. This routine has been preconfigured by the Single Sign-On server administrator and is associated with the requested application.

  4. The Single Sign-On server sends the form to the client browser, with a directive to post it immediately to the external application.

  5. The client posts the form to the external application and logs in.

Single Sign-Off

Single Sign-On users can terminate a Single Sign-On session and log out of all active partner applications simultaneously by logging out of whatever application they are working in. Selecting Logout in a partner application takes them to the Single Sign-Off page, where logout occurs.

If Single Sign-Off has been successful, each of the applications listed on the Single Sign-Off page will have a check mark next to the application name. A broken image next to an application name denotes an unsuccessful logout.

Once all of the application names activated in a session have a check mark, users can select Return to go to the application from which they initiated logout.

Changing the Single Sign-On Password

The Single Sign-On password screen appears only when a password has expired, or is about to expire, and the user tries to log in. If the password is still valid, the user has the option of selecting the Cancel button on this screen and proceeding with the login.

To change or reset a password under other circumstances, the nonadministrative user must go to Delegated Administration Service (DAS), a service of Oracle Internet Directory that performs user and group management functions. The Single Sign-On Administrator can change a password at any time by selecting the Change Password link on the Single Sign-On home page.

The DAS home page can be accessed at a URL of the following form:

http://host:port/oiddas/

where host is the name of the computer where the DAS server is located, and port is the port number of this server. The DAS host computer and Single Sign-On host computer are generally the same.


Note:

Unlike Single Sign-On user names, Single Sign-On passwords are case sensitive and must conform with rules for Oracle Internet Directory.


Global User Inactivity Timeout

The Oracle 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 Single Sign-Out session timeout.

If the Single Sign-On server is enabled for the global user inactivity timeout, it sets the domain cookie and the user authentication time after authenticating the user. The cookie is encrypted with a single shared key and the Single Sign-On server and mod_osso know the value of the key. Because mod_osso updates the timestamp of the cookie, applications can determine whether a user has timed out because of inactivity.

When the user exceeds the global user inactivity timeout limit and tries to access the application, the application sends the Single Sign-On server an authentication request as usual. The Single Sign-On server, ascertaining that the user has exceeded the global user inactivity timeout limit, prompts the user to log in. If the user has not exceeded the limit, the Single Sign-On server authenticates him using the existing session cookie.


Note:

The user might have a valid Single Sign-On session, but if he has exceeded the global timeout limit, he will be prompted for credentials.


See Also:

"Configuring the Global User Inactivity Timeout" in Chapter 2, "Administering Oracle Single Sign-On"

Single Sign-On Authentication Repository

In Oracle9iAS, Release 2, Single Sign-On authentication is directory based, and user names and passwords are managed not in the Single Sign-On database schema, but in Oracle Internet Directory.

Formerly, local authentication meant using a lookup table in the Single Sign-On schema, located in the database associated with Oracle9iAS Portal. In Oracle9iAS, Release 2, local authentication is synonymous with authentication using Oracle Internet Directory.

Both Single Sign-On and Oracle Internet Directory are included in an iAS Infrastructure installation. To learn how to install the Oracle9iAS infrastructure, see "Oracle9iAS Infrastructure Installation," in Chapter 4 of Oracle9i Application Server Installation Guide.


Go to previous page Go to next page
Oracle
Copyright © 2002 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index