Skip Headers

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

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

Go to previous page Go to next page

Directory-Enabled Single Sign-On

This chapter examines those aspects of Oracle9iAS Single Sign-On that are dependent upon Oracle Internet Directory. The directory is the repository for all Single Sign-On user accounts and passwords--administrative and nonadministrative. In Oracle 9iAS, Release 2, all user and group management functions for Single Sign-On are handled by the directory.

The chapter covers the following topics:

Authentication Flow for Directory-Enabled Single Sign-On

Figure 3-1 illustrates how Single Sign-On authentication works when Oracle Internet Directory is the authentication repository.

Figure 3-1 Directory-Enabled Single Sign-On

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

  1. The user attempts to access a protected URL.

  2. The user is redirected to the Single Sign-On server.

  3. The user's credentials are verified against his user entry in the directory. Specifically, the user's nickname--the name he enters on the Single Sign-On login page--is mapped to his distinguished name (DN) in the directory; then his password, an attribute of his entry, is validated. Once his password is validated, he is authenticated.

  4. The Single Sign-On server fetches the user's attributes, specifically his globally unique user ID (GUID) and distinguished name (DN).

  5. The Single Sign-On server passes the fetched attributes, as well as the user's nickname and language preference to the partner application.

  6. The partner application may fetch other attributes using attributes that have already been fetched--the user's GUID, for instance.

Managing Users in Oracle Internet Directory

Management functions for Single Sign-On users are performed with the following tools:

Single Sign-On User Accounts

In Oracle9iAS, user accounts are stored and managed in Oracle Internet Directory. This means that Single Sign-On authentication is performed in the directory, against the user's entry. When the client requests an application and is redirected to the Single Sign-On server, the server validates the user's credentials against Oracle Internet Directory. This validation involves verifying the user's password and, also, his account status--for instance, whether the user is locked out or whether his password is about to expire.

If the user is successfully authenticated, the Single Sign-On server passes her nickname-- which is typically her user name--her globally unique user ID (GUID), her distinguished name (DN), and her language preference to the partner application.

Table 3-1 lists all of the user attributes that the Single Sign-On server sends to partner applications using the URLC token. Note that some of these attributes are stored in the Single Sign-On database.

Table 3-1 User Attributes Passed to Partner Applications
Attribute Description Source


User nickname as entered by user on Single Sign-On login page

Single Sign-On login page


Single Sign-On user's distinguished name

User entry in Oracle Internet Directory


Single Sign-On user's globally unique user ID (GUID)

Single Sign-On user's globally unique user ID (GUID)


Language and territory. User selects these on the login page

Single Sign-On server

Table 3-2 lists the Java functions that partner applications can use to retrieve attributes from the HTTP headers set by mod_osso. Non-Java applications can also make function calls to retrieve attributes.

Table 3-2 Functions Used to Retrieve Attributes from HTTP Headers
Attribute Function









Password Policies

The Single Sign-On user password is stored in Oracle Internet Directory as an attribute of the user's entry. Users can change their passwords either in the Single Sign-On interface or by going to DAS. Oracle Directory Manager enables the directory administrator to adjust password expiry behavior to suit enterprise needs.

Password Rules

Oracle Directory Manager has fields that enable the administrator to do the following when configuring password behavior:

Password Expiry

Using either Oracle Directory Manager or LDAP command-line tools, administrators can configure password life and can specify when users are prompted to change their passwords. Administrators can also configure a grace login period for users. This is a period after which the user's password has expired. If the user neglects to change his password within this period, he must have an administrator reset it for him.

Account Lockout

An account lockout occurs when users are unable to access the Single Sign-On server from any number of workstations because they have submitted the incorrect user name and password combination more times than is permitted by Oracle Internet Directory. Once the limit has been reached, even a valid user name and password combination fails to log the user in.

Because Single Sign-On user accounts are managed in the directory, the directory administrator determines account lockout policies. Oracle Directory Manager has fields for enabling and disabling lockout and for specifying lockout duration.

Configuring Password Policies

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.

Directory Tree for Oracle Single Sign-On

Oracle Single Sign-On, like other components in the iAS complement, has its own "container" within the directory information tree (DIT). This container is found within the Oracle Context, an entry that serves as the root for all Oracle-specific data. In the simplified DIT shown in Figure 1-2, only the root Oracle Context is expanded. The root Oracle Context is the repository for sitewide information--that is, information that applies to all subscribers and products. Structurally, subscriber-specific Oracle Contexts are mirror images of the root context, but the information they contain pertains only to a particular subscriber.

In Figure 3-2 , the Single Sign-On container is identified by the entry cn=SSO. It contains a single entry, orclApplicationCommonName=orasso_sso, which is the entry for the Single Sign-On server. In the illustration, this entry has been expanded to show the object classes and attributes that define the entry. For example, the attribute orclapplicationcommonname gives the default name for the Single Sign-On server, orasso. Note, too, that the Single Sign-On server has its own password, which, along with orclapplicationcommonname, the directory server uses to authenticate the Single Sign-On server when the latter performs user searches.

The container Common is a repository for information common to all iAS products. For instance, it houses attributes that enable products to identify the subscriber search base, or node, and the subscriber nickname. Subscriber-specific Common containers--not shown here--contain attributes that enable products to locate users within a subscriber subtree. In addition to expanding the SSO container, the illustration expands entries for an iAS user who is also an administrator.

Figure 3-2 Directory Information Tree for Oracle Single Sign-On

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

See Also:

Changing Single Sign-On Server Settings in the Directory

The script ssooconf.sql enables the Single Sign-On administrator to change the following settings in the directory:

To change directory settings for the Single Sign-On server:

  1. Log in to SQL*Plus as the Single Sign-On schema. The default user name and password is orasso.

  2. Run the script ssooconf.sql by issuing the following command:

    SQL> @ssooconf.sql
  3. In the fields prefaced by the words Enter value for, make the desired changes.

  4. To update the file, select Return.

    The script displays updated settings for the Single Sign-On server.

If you run the script and then decide not to make changes, select Return to retain existing values.

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

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