test

Sun OpenSSO Enterprise 8.0 Technical Overview

Chapter 7 Authentication and the Authentication Service

The Sun OpenSSO Enterprise Authentication Service determines whether a user is the person he claims to be. User authentication is the first step in controlling access to web resources within an enterprise. This chapter explains how the Authentication Service works with other components to prove that the user’s identity is genuine. Topics covered in this chapter include:

Authentication Service Overview

The function of the Authentication Service is to request information from an authenticating party, and validate it against the configured identity repository using the specified authentication module. After successful authentication, the user session is activated and can be validated across all web applications participating in an SSO environment. For example, when a user or application attempts to access a protected resource, credentials are requested by one (or more) authentication modules. Gaining access to the resource requires that the user or application be allowed based on the submitted credentials. From the user perspective, a company employee wants to look up a colleague’s phone number. The employee uses a browser to access the company’s online phone book. To log in to the phone book service, the employee provides a user name and password. OpenSSO Enterprise compares the user’s input with data stored in the appropriate identity repository. If OpenSSO Enterprise finds a match for the user name, and if the given password matches the stored password, the user’s identity is authenticated.

Note –

The Basic User Session section in the previous chapter contains a detailed description of the authentication process itself.

The Authentication Service can be accessed by a user with a web browser, by an application using the Client SDK, or by any other client that correctly implements the Authentication Service messaging interfaces. The Authentication Service framework has a pluggable architecture for authentication modules that have different user credential requirements. Together with the Session Service, the Authentication Service establishes the fundamental infrastructure for SSO. Generally speaking, the Authentication Service:

Every time a request is used to access the Authentication Service, the session token identifier is retrieved and used to get the associated session data structure from the Session Service. Additionally, the Authentication Service interfaces with the Session Service to:

The following diagram illustrates how the two services work together.

Figure 7–1 Authentication Service and Session Service Interfaces

Diagram illustrates how the Authentication Service and the Session Service work together

The Authentication Service also interfaces with other OpenSSO Enterprise services including the Naming Service, the Identity Repository Service, the Logging Service, and the Monitoring Service. It also interfaces with the configuration data store and policy agents protecting system resources. (A policy agent must authenticate itself using the Client SDK authentication interfaces, and users with no valid session must be authenticated.)

Authentication Service Features

The following sections explain some of the features of the Authentication Service.

Account Locking

The Authentication Service provides account locking to prevent a user from completing the authentication process after a specified number of failures. OpenSSO Enterprise sends email notifications to administrators when account lockouts occur. OpenSSO Enterprise supports:

Physical Locking.

By default, user accounts are physically unlocked. You can initiate physical locking by typing inactive as the value of the Lockout Attribute Name attribute in the Core Authentication Service. Additionally, the value of the Login Failure Lockout Duration attribute should be set to 0.

physical lock attr name is: inetuserstatus value active/inactive

Memory Locking.

You can configure Memory Locking so that a user account is locked in memory after a specified number of authentication attempts. By changing the Login Failure Lockout Duration attribute to a value greater then 0, the user’s account is then locked in memory for the number of minutes specified and the account is unlocked after the time period elapses.

To figure out the amount of time the lockout will be in effect, the value of the Lockout Duration Multiplier attribute is multiplied by the value of the Login Failure Lockout Duration attribute for subsequent lockout. For example, if the value of Login Failure Lockout Duration is 5 minutes and the value of the Lockout Duration Multiplier is 2, the first time a user is locked out in memory will be 5 minutes. The second time this same user gets locked out in memory the lockout duration will be 10 minutes (5 minutes x 2). The third time this same user gets locked out in memory the lockout duration will be 20 minutes (5 minutes x 2 x 2).

The account locking feature is disabled by default. Account locking activities are also logged. For information on how to enable it, see Enabling Account Lockout in Sun OpenSSO Enterprise 8.0 Administration Guide.

Note –

Only authentication modules that throw an Invalid Password Exception can leverage the Account Locking feature. Out of the box, these include Active Directory, Data Store, HTTP Basic, LDAP, and Membership.

Authentication Chaining

OpenSSO Enterprise allows the configuration of an authentication process in which a user must pass credentials to one or more authentication modules before session validation is accomplished. This is called authentication chaining. OpenSSO Enterprise uses the Java Authentication and Authorization Service (JAAS) framework (integrated with the Authentication Service) to implement authentication chaining. The JAAS framework validates all user identifiers used during the authentication process, and maps them to one principal. (The mapping is based on the configuration of the User Alias List attribute in the user's profile.) If all the maps are correct, the session token is validated. If all the maps are not correct, the user is denied a valid session token. Once authentication to all modules in the chain succeeds or fails, control is returned to the Authentication Service from the JAAS framework.

You configure an authentication chain by realm, user, role, or service. Determining validation is based upon the control flag configured for each authentication module instance defined in the chain. The flags are:

Requisite

Authentication to this module instance is required to succeed. If it succeeds, authentication continues down the module instance list. If it fails, control immediately returns to the application.

Required

Authentication to this module instance is required to succeed. If any of the required module instances defined in the chain fails, the whole authentication chain will fail.

Sufficient

The module instance is not required to succeed. If it does succeed, control immediately returns to the application (authentication does not proceed down the module instance list). If it fails, authentication continues down the list.

Optional

The module instance is not required to succeed. Whether it succeeds or fails, authentication still continues to proceed down the module instance list.

Note –

Role based authentication is only supported for use with the AM SDK data store. This data store would come from an existing Sun Java System Access Manager 7.x installation or would have been manually created.

For more information, see Chapter 3, Configuring Authentication, in Sun OpenSSO Enterprise 8.0 Administration Guide. For an overview of the authentication module instances, see Authentication Modules.

Fully Qualified Domain Name Mapping

Fully Qualified Domain Name (FQDN) mapping enables the Authentication Service to take corrective action in the case where a user may have typed in an incorrect URL. This is necessary, for example, when a user specifies a partial host name or IP address to access protected resources. This feature can also be used to allow access to one instance of OpenSSO Enterprise using many different aliases. For example, you might configure one instance of OpenSSO Enterprise as intranet.example.com for employees and extranet.example.com for partners. For more information, see Mapping Fully Qualified Domain Names in Sun OpenSSO Enterprise 8.0 Administration Guide.

Persistent Cookies

A persistent cookie is an information packet that is written to the user's hard drive and, therefore, continues to exist after the web browser is closed. The persistent cookie enables a user to log into a new browser session without having to reauthenticate. The Authentication Service can be enabled to write persistent cookies rather than cookies that are written to a web browser's memory. For more information, see Using Persistent Cookies in Sun OpenSSO Enterprise 8.0 Administration Guide.

Session Upgrade

The Authentication Service allows for the upgrade of a valid session based on a second, successful authentication performed by the same user. If a user with a valid session attempts to authenticate to a second resource secured under the realm to which he is currently authenticated, and this second authentication request is successful, the Authentication Service updates the session with the new properties based on the new authentication. If the authentication fails, the current user session is returned without an upgrade. If the user with a valid session attempts to authenticate to a resource secured in a different realm, the user will receive a message asking whether the user would like to authenticate to the new realm. The user can choose to maintain the current session, or can attempt to authenticate to the new realm. Successful authentication will result in the old session being destroyed and a new one being created. For more information, see Upgrading Sessions in Sun OpenSSO Enterprise 8.0 Administration Guide.

Note –

Successful authentication for session upgrade does not necessarily destroy the previous session. If the subsequent AuthContext object is created with the constructor AuthContext(SSOToken ssoToken, boolean forceAuth) when forceAuth is set to true, the existing session will be used and a new session will not be created.

JAAS Shared State

The JAAS shared state enables sharing of both a user identifier and a password between authentication module instances. Options are defined for each authentication module type by realm, user, service and role. If an authentication fails with the credentials from the shared state, the authentication module restarts the authentication process by prompting for its required credentials. If it fails again, the module is marked failed. After a commit, an abort, or a logout, the shared state will be cleared. For more information, see Sharing User Credentials Among Authentication Modules (Shared State) in Sun OpenSSO Enterprise 8.0 Administration Guide.

Security

From a security point of view, here are some general practices implemented in the Authentication Service.

Authentication Modules

An authentication module is a plug-in that collects user information such as a user ID and password, and compares the information against entries in a database. If a user provides information that meets the authentication criteria, the user is validated and, assuming the appropriate policy configuration, granted access to the requested resource. If the user provides information that does not meet the authentication criteria, the user is not validated and denied access to the requested resource. OpenSSO Enterprise is deployed with a number of authentication modules. Table 7–1 provides a brief description of each.

Table 7–1 Authentication Service Modules

Authentication Module Name 

Description 

Active Directory

Uses an Active Directory operation to associate a user identifier and password with a particular Active Directory entry. You can define multiple Active Directory authentication configurations for a realm. Allows both LDAP and Active Directory to coexist under the same realm. 

Anonymous 

Enables a user to log in without specifying credentials. You can create an Anonymous user so that anyone can log in as Anonymous without having to provide a password. Anonymous connections are usually customized by the OpenSSO Enterprise administrator so that Anonymous users have limited access to the server. 

Certificate 

Enables a user to log in through a personal digital certificate (PDC). The user is granted or denied access to a resource based on whether or not the certificate is valid. The module can optionally require the use of the Online Certificate Status Protocol (OCSP) to determine the state of a certificate. 

Data Store 

Enables authentication against one or more configuration data stores within a realm. 

Federation 

Used by the service provider during federation (using SAML v1.x, SAML v2, WS-Federation, Liberty ID-FF) to create a session after validating the assertion. This authentication module can not be invoked like the other modules as it is invoked directly by the SAMLAwareServlet.

HTTP Basic 

Enables authentication to occur with no data encryption. Credentials are validated internally using either the LDAP or Data Store authentication module. 

Java Database Connectivity (JDBC)

Enables authentication through any Structured Query Language (SQL) databases that provide JDBC-enabled drivers. The SQL database connects either directly through a JDBC driver or through a JNDI connection pool. 

LDAP 

Enables authentication using LDAP bind, a directory server operation which associates a user identifier and password with a particular LDAP entry. You can define multiple LDAP authentication configurations for a realm. 

Membership 

Enables user to self-register a user entry. The user creates an account, personalizes it, and accesses it as a registered user without the help of an administrator. Implemented similarly to personalized sites such as my.site.comor mysun.sun.com.

MSISDN 

The Mobile Station Integrated Services Digital Network (MSISDN) authentication module enables authentication using a mobile subscriber ISDN associated with a device such as a cellular telephone. It is a non-interactive module. The module retrieves the subscriber ISDN and validates it against the user repository to find a user that matches the number. 

RADIUS 

Uses an external Remote Authentication Dial-In User Service (RADIUS) server to verify identities. 

Security Assertion Markup Language (SAML) 

Receives and validates SAML assertions on a target server by using either a web artifact or a POST response. 

SafeWord®

Uses Secure Computing’s SafeWord PremierAccessTM server software and SafeWord tokens to verify identities.

SecurIDTM

Uses RSA ACE/Server software and RSA SecurID authenticators to verify identities. 

UNIX®

Solaris and Linux modules use a user’s UNIX identification and password to verify identities. 

Windows Desktop Single Sign-On (SSO) 

Allows a user who has already authenticated with a key distribution center to be authenticated by OpenSSO Enterprise without having to provide the login information again. Leverages Kerberos authentication and is supported wherever Kerberos is supported (including Windows, Solaris, Linux, and Macintosh). 

Windows NT 

Uses a Microsoft Windows NTTM server to verify identities.

You can use the OpenSSO Enterprise console to enable and configure the authentication modules. You can also create and configure multiple instances of a particular authentication module. (An authentication module instance is a child entity that extends the schema of a parent authentication module and adds its own subschema.) Finally, you can write your own custom authentication module (or plug-in) to connect to the OpenSSO Enterprise authentication framework. See Chapter 3, Configuring Authentication, in Sun OpenSSO Enterprise 8.0 Administration Guide for detailed information about enabling and configuring default authentication modules and authentication module instances. See Chapter 1, Using the Authentication Service API and SPI, in Sun OpenSSO Enterprise 8.0 Developer’s Guide for more information about writing custom authentication modules.

Authentication Types

After granting or denying access to a resource, OpenSSO Enterprise checks for information about where to redirect the user. A specific order of precedence is used when checking for this information. The order is based on whether the user was granted or denied access to the protected resource, and on the type of authentication specified. When you install OpenSSO Enterprise, a number of authentication types are automatically configured.

Realm-based Authentication.

User authenticates to a configured realm or sub-realm.

Note –

This authentication type is equivalent to organization—based authentication. The query parameters org and realm would both lead to realm-based authentication in realm mode, and organization-based authentication in legacy mode.

Role-based Authentication.

User authenticates to a configured role within a realm or sub-realm. The user must possess the role. A static role is possessed when an attribute is assigned to a specific user or container. A filtered role is dynamically generated based on an attribute contained in the user’s or container’s entry. For example, all users that contain a value for the employee attribute can be included in a role named employees when the filtered role is created.

Note –

Role based authentication is only supported for use with the AM SDK data store schema plug-in. This data store would come from an existing Sun Java System Access Manager 7.x installation or would have been manually created. If a user installs OpenSSO Enterprise with any other user datastore, role-based authentication will not be supported.

Service-based Authentication.

User authenticates to a specific service or application registered to a realm or sub-realm.

User-based Authentication.

User authenticates using an authentication process configured specifically for him or her.

Authentication Level-based Authentication

An administrator specifies the security level of the authentication modules by defining each with an authentication level. Successful authentication to a higher authentication level defines a higher level of trust for the user. If a user attempts to access a service, the service can determine if the user is allowed access by checking the authentication level in the user's session data. If the authentication level is not high enough, the service redirects the user to go through an authentication process with a set authentication level.

Module-based Authentication.

Allows a user to specify the module to which they will authenticate.

Organization-based Authentication.

User authenticates to an organization or sub-organization.

Note –

This authentication type is equivalent to realm-based authentication. The query parameters org and realm would both lead to realm-based authentication in realm mode, and organization-based authentication in legacy mode.

For more information, see Chapter 3, Configuring Authentication, in Sun OpenSSO Enterprise 8.0 Administration Guide.

Configuring for Authentication

The authentication framework includes the following places where you can configure for authentication:

Explanations of the authentication attributes can be found in the Online Help and the Sun OpenSSO Enterprise 8.0 Administration Reference.

Core Authentication Module and Realm Configuration

The Core Authentication Module contains general authentication properties that can be defined globally using the OpenSSO Enterprise console (under the Configuration tab) or more specifically for each configured realm (under the Access Control tab). Core authentication properties are added and enabled for the top-level realm during installation. As new realms are configured under the top-level realm, these properties (and the values defined globally for them) are dynamically added to each new realm when it is created. Once added, new values can be defined and configured values can be modified by the realm's administrator. The values are then used if no overriding value is defined in the specified authentication module instance or authentication chain. The default values for the Core Authentication Module are defined in the amAuth.xml file and stored in the configuration data store. For more information, see Chapter 3, Configuring Authentication, in Sun OpenSSO Enterprise 8.0 Administration Guide and the Sun OpenSSO Enterprise 8.0 Administration Reference.

Authentication Configuration Service

The Authentication Configuration Service describes all the dynamic attributes for service-based authentication. This service is used for configuring roles. When you assign a service to a role, you can also assign other attributes such as a success URL or an authentication post-processing class to the role.

Login URLs and Redirection URLs

In the last phase of the authentication process, OpenSSO Enterprise either grants or denies access to the user. If access is granted, OpenSSO Enterprise uses a login URL to display a page in the browser. If access is denied, OpenSSO Enterprise uses a redirection URL to display an alternate page in the browser. A typical alternate page contains a brief message indicating the user has been denied access.

Each authentication type (as discussed in Authentication Types) uses a login URL or redirection URL based on a specific order of precedence, and on whether the authentication succeeded or failed. For a detailed description of how OpenSSO Enterprise proceeds through the order of precedence, see Chapter 3, Configuring Authentication, in Sun OpenSSO Enterprise 8.0 Administration Guide.

Authentication Graphical User Interfaces

The OpenSSO Enterprise Authentication Service has two separate graphical user interfaces that can be used. The following sections contain information on them.

Authentication Service User Interface

The Authentication Service implements a user interface that is separate from the OpenSSO Enterprise administration console. The Authentication Service user interface provides a dynamic and customizable means for gathering authentication credentials. When a user requests access to a protected resource, the Authentication Service presents a web-based login page and prompts the user for the appropriate credentials based on the configured authentication module or chain. Once the credentials have been passed back to OpenSSO Enterprise and authentication is deemed successful, the user may gain access to the protected resource if authorized to do so. The Authentication Service user interface can be used for the following:

Below is a screen capture of the default Authentication Service user interface.

Figure 7–2 Authentication Service User Interface

Screen capture of the Authentication Service User Interface

OpenSSO Enterprise provides customization support for the Authentication Service user interface. You can customize JavaServer Pages™ (JSP™) and the file directory level by organization, service, locale, or client type. See Chapter 13, Customizing the Authentication User Interface, in Sun OpenSSO Enterprise 8.0 Developer’s Guide for more information.

Distributed Authentication User Interface

OpenSSO Enterprise also provides a remote authentication user interface component to enable secure, distributed authentication across two firewalls. A web browser communicates an HTTP request to the remote authentication user interface which, in turn, presents the appropriate module login page to the user. The web browser then sends the user login information through a firewall to the remote authentication user interface which, in turn, communicates through the second firewall with OpenSSO Enterprise. The Distributed Authentication User Interface enables a policy agent or an application that is deployed in a non-secured area to communicate with the OpenSSO Enterprise Authentication Service installed in a secured area of the deployment. Figure 7–3 illustrates this scenario.

Figure 7–3 Distributed Authentication Process

This figure illustrates the Distributed Authentication Service located in a non-secured area and the Authentication Service in a secured area.

The Distributed Authentication User Interface uses a JATO presentation framework and is customizable. (See screen capture in Authentication Service User Interface.) You can install the Distributed Authentication User Interface on any servlet-compliant web container within the non-secure layer of a OpenSSO Enterprise deployment. The remote component then works with the Authentication client APIs and authentication utility classes to authenticate web users. For a more detailed process, see User Authentication. For detailed installation and configuration instructions, see Chapter 9, Deploying a Distributed Authentication UI Server, in Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.

Authentication Service Programming Interfaces

OpenSSO Enterprise provides both Java APIs and C APIs for writing authentication clients that remote applications can use to gain access to the Authenticate Service. Communication between the APIs and the Authentication Service occurs by sending XML messages over HTTP(S). The Java and C APIs support all authentication types supported by the browser-based user interface. Clients other than Java and C clients can use the XML/HTTP interface directly to initiate an authentication request. Additionally, you can add custom authentication modules to OpenSSO Enterprise by using the service provider interface (SPI) package, com.iplanet.authentication.spi. This SPI implements the JAAS LoginModule, and provides additional methods to access the Authentication Service and module configuration properties files. Because of this architecture, any custom JAAS authentication module will work within the Authentication Service. For more information, see Chapter 1, Using the Authentication Service API and SPI, in Sun OpenSSO Enterprise 8.0 Developer’s Guide and Sun OpenSSO Enterprise 8.0 Java API Reference.

OpenSSO Enterprise also provides a Client SDK that can implement authentication logic on a remote web server or application server. For information, see Chapter 14, Using the Client SDK, in Sun OpenSSO Enterprise 8.0 Developer’s Guide.