Oracle Single Sign-On Application Developer's Guide Release 3.0.6 Part Number A86782-03 |
| Library | Service | Index

# 2
Concepts and Architecture

This chapter describes the components of Single Sign-On, the kinds of applications to which it can provide access, and the authentication methods it uses. It explains the process and architecture through which Single Sign-On authenticates users to applications.

This chapter contains these topics:

- Components of Single Sign-On

- Single Sign-On Application Types

- Single Sign-On Authentication Methods

- How Single Sign-On Works

## Components of Single Sign-On

Single Sign-On has two components:

- Login Server

- Single Sign-On Application Programming Interface (API)

### Login Server

The first time that a user seeks access to an application, the Login Server:

- Authenticates the user by means of user name and password

- Passes the client's identity to the various applications

- Marks the client being authenticated with an encrypted login cookie

In subsequent user logins, this login cookie provides the Login Server with the user's identity, and indicates that authentication has already been performed. If there is no login cookie, then the Login Server presents the user with a login challenge.

To guard against sniffing, the Login Server can send the login cookie to the client browser over an encrypted SSL channel.

The login cookie expires with the session, either at the end of a time interval specified by the administrator, or when the user exits the browser. It is never written to disk.

A partner application can expire its session through its own explicit logout.

Note: To logout of a partner application and log in as another user, you must also log out of the Login Server session. Otherwise, the authentication request returns the partner application to the logged in state of the previous user.

### Single Sign-On Application Programming Interface (API)

The Single Sign-On API enables:

- Applications to communicate with the Login Server and to accept a user's identity as validated by the Login Server

- Administrators to manage the application's association to the Login Server

## Single Sign-On Application Types

There are two kinds of applications to which Single Sign-On provides access:

- Partner Applications

- External Applications

### Partner Applications

Partner applications are integrated with the Login Server. They contain a Single Sign-On API that enables them to accept a user's identity as validated by the Login Server.

### External Applications

External applications are web-based applications that retain their authentication logic. They do not delegate authentication to the Login Server and, as such, require a user name and password to provide access. Currently, these applications are limited to those which employ an HTML form for accepting the user name and password. The user name may be different from the SSO user name, and the Login Server provides the necessary mapping.

## Single Sign-On Authentication Methods

Single Sign-On can use one of these authentication methods:

##### Single Sign-On Authentication Methods

Local user authentication | Uses a lookup table within the Login Server schema. This table contains user name, password, Login Server privilege level, and other auditing fields for the user. The incoming password is one-way hashed and compared to the entry in the table.
External repository authentication | Typically relies on an LDAP-compliant directory. In this case, the Login Server binds to the LDAP-compliant directory, then looks up the user credentials stored there. External Authentication includes LDAP and Database Authentication and any others that may be custom-developed.

## How Single Sign-On Works

Whenever a user accesses either a partner application or an external application, the Login Server first authenticates that user.

This section contains these topics:

- Authenticating to the Login Server

- Accessing a Partner Application

- Accessing an External Application

### Authenticating to the Login Server

The Login Server authenticates a user in this way:

Text description of the illustration concepta.gif

See Also: "Login Server" for information on the login cookie

### Accessing a Partner Application

When a user seeks access to a partner application, the following steps occur:

Text description of the illustration concept2.gif

Note: In Step 2 of this process, the partner application directs the user to the Login Server only if the application requires it based on the URL requested. Some URLs may be public and no redirection to the Login Server is necessary. When it is necessary, the partner application must protect itself from unauthenticated access by using its own session management.

If, during the same session, the user again seeks access to the same or to a different partner application, then the Login Server does not prompt the user for user name and password. Instead, the Login Server obtains that information from the login cookie on the client browser.

### Partner Application Development Requirement

- To implement an authentication check:

  1. Protected URLs need to check for an application session cookie for authorization.

  2. If no application session cookie exists, then the browser redirects the user to the Single Sign-On server.

  3. If the URL is publicly accessible, then no authorization check is implemented.

- To implement a sign-on URL:

  1. This URL must establish an application session cookie using the identity information sent by the Single Sign-On server.

  2. The browser then redirects the user to the requested URL

### Accessing an External Application

You can accessing an external application through Oracle Portal. In this scenario, Oracle Portal functions as a partner application.

This section contains these topics:

- Authenticating to Oracle Portal

- Authenticating to an External Application for the First Time

- Authenticating to an External Application After the First Time

#### Authenticating to Oracle Portal

When a user seeks access to an external application by way of Oracle Portal, Single Sign-On authenticates the user to Oracle Portal through this process:

Text description of the illustration concept3.gif

If, during the same session, the user again seeks access to Oracle Portal, then the Login Server does not prompt the user for user name and password. Instead, it obtains that information from the login cookie on the client browser.

#### Authenticating to an External Application for the First Time

Single Sign-On uses the process described in the next figure under these conditions:

- The user has authenticated to the Oracle Portal

- The user is accessing an external application for the first time through Oracle Portal

  Text description of the illustration concept4.gif

#### Authenticating to an External Application After the First Time

Single Sign-On uses the process described in the next figure if the user:

- Has authenticated to the Oracle Portal

- Has a user name and password in the Login Server password store

- Is accessing an external application after the first time

  Text description of the illustration concept5.gif

If the user has not stored a user name and password in the Login Server password store, then Single Sign-On follows the process described in "Authenticating to an External Application for the First Time".

| Copyright © 1996-2000 Oracle Corporation. All Rights Reserved. |
| Library | Service | Index