Chapter 3 User Authentication

Access Manager 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 Authentication service works with other Access Manager components to authenticate a user, or prove that the user’s identity is genuine.

Topics in this chapter include:

• Authentication Overview

• Authentication Plug-In Modules

• Authentication Framework

• Inside the Core Authentication Component

• Presentation Layer

• Distributed Authentication User Interface

• Authentication Programming Interfaces

Authentication Overview

The following example demonstrates a user's view of how Authentication service works. A company employee must look up a colleague’s phone number, so he uses a browser to access the company’s online phone book. To log in to the phone book service, the employee must provide a user name and password. Access Manager compares the user’s input with data stored in Directory Server. If Access Manager finds a match for the user name, and if the given password matches the password stored in Directory Server, Access Manager authenticates the user’s identity. After authentication, the policy evaluation process occurs. If the policy agent allows access to the user, and the corporate phone book is displayed.

See Basic User Session for a detailed description and illustration of the authentication process within a basic user session.

Authentication Service is client-type aware and supports all configured client types such as cookieless and cookie-enabled client types.

Authentication Plug-In Modules

An authentication module is a plug-in that collects user information such as a user ID and password, and then checks the information against entries in a database. If a user provides information that meets the authentication criteria, then the user is granted access to the requested resource. If the user provides information that does not meet authentication criteria, the user is denied access to the requested resource. Access Manager is installed with 15 types of authentication modules. The following table provides a brief description of the 15 default authentication module types.

Table 3–1 Access Manage Authentication Module Types

Authentication Module Name	Description
Active Directory	Uses an Active Directory operation to associates a user ID 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	Allows 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 Access Manager administrator so that Anonymous users have limited access to the server.
Certificate	Allows a user to log in through a personal digital certificate (PDC). The module can require the use of the Online Certificate Status Protocol (OCSP) to determine the state of a certificate. Use of the OCSP is optional. The user is granted or denied access to a resource based on whether or not the certificate is valid.
HTTP Basic	Allows authentication to occur with no data encryption. Credentials are validated internally using the LDAP authentication module.
Java Database Connectivity (JDBC)	Allows 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	Allows authentication using LDAP bind, a Directory Server operation which associates a user ID password with a particular LDAP entry. You can define multiple LDAP authentication configurations for a realm.
Membership	Allows user to self-register. The user create 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.com, or 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 Directory Server 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)	Also known as Kerebos authentication, this module is specific only to the Windows operating system. Allows a user who has already authenticated with a key distribution center to be authenticated with Access Manager without having to provide the login information again.
Windows NT	Uses a Microsoft Windows NTTM server to verify identities.

After granting or denying access, Access Manager checks for information about where to redirect the user. Access Manager uses a specific order of precedence when checking 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. Five types of authentication exist including Realm-based and Role-based authentication. See Authentication Type Configurations for more information about authentication types.

You can use the Access Manager Console to enable and configure authentication module types that come with Access Manager by default. You can also create and configure multiple instances of a particular authentication module type. An instance is a child entity that extends the schema of a parent authentication module and adds its own subschema. See Sun Java System Access Manager 7 2005Q4 Administration Guide for detailed information about enabling and configuring default authentication modules types and authentication module instances.

You can also write your own custom authentication module or plug-in to connect to the Access Manager authentication framework. For more information about writing custom authentication modules, see the Sun Java System Access Manager 7 2005Q4 Developer’s Guide.

Authentication Framework

The Authentication framework includes two pluggable and customizable services: General Authentication Service, and Authentication Configuration Service.

General Authentication Service

The general authentication service is used for server-related attribute configuration. Some of the attributes described in this service are default attributes for all Access Manager authentication modules.

You must register the general authentication service as a service to a realm before a user can use authentication modules to log in. The general authentication service enables the Access Manager administrator to define default values for a realm's authentication parameters. These values can be used if no overriding value is defined in the specified authentication module. The default values for the General Authentication Service are defined in the amAuth.xml file and stored in the Access Manager information tree after installation.

Authentication Configuration Service

The Authentication Configuration Service describes all the dynamic attributes for service-based authentication. This service is used for 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.

Inside the Core Authentication Component

The core Authentication component is where default configurations are stored and where authentication processes are invoked.

Client Detection

An initial step in the authenticating process is to identify the type of client making the HTTP(S) request. This Access Manager feature is known as client detection. The URL information in the HTTP(S) request is used to retrieve the client’s characteristics. Based on these characteristics, the appropriate authentication pages are returned. For example, when a Netscape browser is used to request a web page, Access Manager displays an HTML login page. Once the user is validated, the client type Netscape browser is added to the session token.

Authentication Type Configurations

When you install Access Manager, a number of authentication types are automatically configured for you. The following types of authentication are available to you by default when you install Access Manager.

Realm-based Authentication.

User authenticates to a realm or subrealm in the Access Manager information tree.

Role-based Authentication.

User authenticates to a role within a realm or subrealm of the directory information tree. A role is a group of like items in the directory. A static role is created when an attribute is assigned to a specific user or container in the directory. A filtered role is dynamically generated based on an attribute contained in the a user’s or container’s LDAP entry. For example, all users that contain a particular attribute, for example employee, can be automatically included in a filtered role named employees.

Service-based Authentication.

User authenticates to a specific service or application registered to a realm or subrealm.

User-based Authentication.

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

Authentication Level-based Authentication

Administrator specifies the security level of the modules to which identities can authenticate.

Module-based Authentication.

User specifies the module instance to which the user will authenticate.

Redirection URLs

In the last phase of the authentication process, Access Manager either grants or denies access to the user. If access is granted, Access Manager uses a login URL to display a login page in the browser. If access is denied, Access Manager 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 uses a login URL or redirection URL depending on a specific order of precedence. The order of precedence is based on the authentication type used (realm-based, role-based, and so forth), and on whether authentication succeeded or failed. For a detailed description of how Access Manager proceeds through the order of precedence, see Chapter 7, Managing Authentication, in Sun Java System Access Manager 7 2005Q4 Administration Guide.

Account Locking

The Authentication Service provides an account locking feature that “locks out” or prevents a user from completing the authentication process after a specified number of failures. Only modules that throw an Invalid Password Exception can leverage the Account Locking feature. Access Manager sends email notifications to administrators when account lockouts occur. Account locking activities are also logged. The account locking feature is disabled by default. You can enable account locking by using the Access Manager console.

Access Manager supports two types of account locking: Physical Locking and Memory Locking.

Physical Locking.

By default, user accounts are active or physically unlocked. You can initiate physical locking by changing the status of an LDAP attribute in the user’s profile to inactive. The account remains physically locked until the attribute is changed to active.

Memory Locking.

You can enable memory locking by changing the Login Failure Lockout Duration attribute to a value greater then 0. The user’s account is locked in memory for the number of minutes you specified. The account is unlocked after the time period elapses. You can configure Memory Locking so that a user account is locked in memory after a specified number of tries. The user account will be locked when AM server is restarted.

Authentication Chaining

You can configure one or more authentication module instances so that a user must pass authentication credentials to all authentication modules instances before the user is allowed access. This feature is called as authentication chaining. Determining access is based upon control flags you specify for the chain. Access Manager uses the Java Authentication and Authorization Service (JAAS) framework to implement authentication chaining. The JAAS framework is integrated in the Authentication Service.

You can configure authentication chaining by realm, user, role, or service configuration. Authentication modules use a control flags to indicate requirements for successful authentication.

Each registered authentication module type is assigned one of the following control flags:

Requisite.

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

Required.

Authentication to this module is required to succeed. If any of the required modules in the chain fails, the whole authentication chain will ultimately fail. However, whether a required module succeeds or fails, the control will continue down to the next module in the chain.

Sufficient.

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

Optional.

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

Once authentication to all modules in the chain is successful, control is returned to the Authentication Service from the JAAS framework. The JAAS framework validates all user IDs used during the authentication process, and then maps them all to one user. The mapping is based on the configuration of the User Alias List attribute in the user's profile.

If all the maps are correct, then a valid session token is issued to the user. If all the maps are not correct, then the user is denied a valid session token.

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.

Persistent Cookie

A persistent cookie is an information packet that 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.

Session Upgrade

The Authentication Service enables for the upgrade of a valid session token based on a second, successful authentication performed by the same user to one realm. If a user with a valid session token attempts to authenticate to a resource secured by his current realm, and this second authentication request is successful, 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 by 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.

Validation Plug-in Interface

The Validation Plug-In Interface is supported by only the LDAP and Membership authentication module types. An administrator can write username or password validation logic appropriate for a particular realm, and then the plug logic into the Authentication Service. Before authenticating a user or changing the user password, Access Manager will invokes this plug-in. If the validation is successful, authentication continues. If validation fails, an authentication failed page will be thrown. The plug-in extends the com.iplanet.am.sdk.AMUserPasswordValidation class which is part of the Service Configuration SPI.

JAAS Shared State

The JAAS shared state enable sharing of both user ID and 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.

Presentation Layer

The Authentication Service implements a user interface that is separate from the Access Manager 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. In the following figure. the default Access Manager login page is displayed and prompts the user for user name and password.

Once the credentials have been passed back to Access Manager and authentication is successful, the user can gain access based on the user's specific privileges:

• Administrators can access the administration portion of the Access Manager console to manage their realm’s identity data.

• Users can access their own profiles to modify personal data.

• A user can access a resource defined as a redirection URL parameter appended to the login URL.

• A user can access the resource protected by a policy agent.

Access Manager 7.0 provides customization support for the Authentication Service user interface. You can customize Java server pages (JSPs) and the file directory level for /org/service/locale/client_type. See the Sun Java System Access Manager 7 2005Q4 Developer’s Guide for more information.

Distributed Authentication User Interface

Access Manager provides a remote Authentication user interface component to enable secure, distributed authentication across two firewalls. You can install the remote authentication user interface component on any servlet-compliant web container within the non—secure layer of an Access Manager deployment. The remote component works with Authentication client APIs and authentication utility classes to authenticate web users. The remote component is customizable and uses a JATO presentation framework.

Authentication Programming Interfaces

Access Manager provides both Java APIs and C APIs for writing authentication clients that remote applications can use to gain access to the Authenticate Service. Both Java and C APIs support all Authentication types supported by Web User Interface. This communication between the APIs and the Authentication Service occurs by sending XML messages over HTTP(S). Clients other than Java and C clients can user the XML/HTTP interface directly to initiate an Authentication request.

You can add Authentication modules to Access Manager by using the com.iplanet.authentication.spi package. The 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 about using Authentication programming interfaces, see the Sun Java System Access Manager 7 2005Q4 Developer’s Guide.