3
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

• Managing Users in Oracle Internet Directory

• Single Sign-On User Accounts

• Password Policies

• Directory Tree for Oracle Single Sign-On

• Changing Single Sign-On Server Settings in the Directory

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 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:

• Delegated Administration Service (DAS)

  DAS is a self-service application that enables administrators to manage users and groups. For example, you can create and delete Single Sign-On users and change passwords.

  You can access DAS with a URL of the following form:

  http://host:port/oiddas/
  

  where host is the name of the computer on which the DAS server is located, and port is the port number of the server. In a typical iAS infrastructure installation, the host for the Single Sign-On Server and the DAS server are the same.

  See Also: "Managing Users, Groups, and Subscribers by Using the Delegated Administration Service" in Chapter 9 of Oracle Internet Directory Administrator's Guide

• Oracle Directory Manager (ODM)

  ODM is a Java-based GUI tool for managing most functions in Oracle Internet Directory. Use it to configure password policies.

• LDAP Command-Line Tools

  You can use command-line tools like ldapmodify in place of DAS and Oracle Directory Manager. These tools operate on text files. They take arguments that use the Lightweight Directory Interchange (LDIF) format.

  See Also: Chapter 4, "Directory Administration Tools" in Oracle Internet Directory Administrator's Guide Appendix A, "Syntax for LDIF and Command-Line Tools" in Oracle Internet Directory Administrator's Guide

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
ssousername	User nickname as entered by user on Single Sign-On login page	Single Sign-On login page
user_dn	Single Sign-On user's distinguished name	User entry in Oracle Internet Directory
user_guid	Single Sign-On user's globally unique user ID (GUID)	Single Sign-On user's globally unique user ID (GUID)
accept_language	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
ssousername	HTTPServletRequest.getRemoteUser()
nls_info	HTTPServletRequest.getHeader("Accept-Language")
user_dn	HTTPServletRequest.getHeader("Osso-User-Dn")
user_guid	HTTPServletRequest.getHeader("Osso-User-Guid")

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:

• specify the minimum number of characters a password requires

• specify the minimum number of numeric characters a password requires

• determine whether an old password can be used as a new one

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 the illustration ssoag006.gif

See Also: Chapter 14, "Oracle Components and Oracle Internet Directory" in Oracle Internet Directory Administrator's Guide Appendix C, "Schema Elements" in Oracle Internet Directory Administrator's Guide

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:

• directory host name

• directory port

• DN for Single Sign-On server

• password for Single Sign-On Server

• SSL connections to the directory

  Note: A new instance of Oracle Internet Directory must be a replicated instance.

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.