Chapter 3 Authentication

The Sun Java System 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 the Authentication Service works with other Access Manager components to authenticate a user, or prove that the user’s identity is genuine. Topics covered include:

• Authentication Overview

• Authentication Modules

• Authentication Configuration Services

• Authentication Service User Interface

• Distributed Authentication User Interface

• Inside the Core Authentication Component

• Authentication Programming Interfaces

Authentication Overview

The following example demonstrates how the Authentication Service works from the perspective of the user. 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 provides a user name and password. Access Manager compares the user’s input with data stored in a central user repository. If Access Manager finds a match for the user name, and if the given password matches the stored password, Access Manager authenticates the user’s identity. After authentication, the policy evaluation process occurs. If the policy agent allows access to the user, the corporate phone book is displayed. The Basic User Session section in the previous chapter contains a detailed description and illustration of the authentication process within a basic user session.

---

Note –

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

---

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 granted access to the requested resource. If the user provides information that does not meet the authentication criteria, the user is denied access to the requested resource. Access Manager is installed with a number of authentication modules. The following table provides a brief description of them.

Table 3–1 Access Manage Authentication Module Types

Authentication Module Name	Description
Active Directory	Uses an Active Directory operation to associate 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	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 Access Manager 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.
HTTP Basic	Enables authentication to occur with no data encryption. Credentials are validated internally using the LDAP 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 ID password with a particular LDAP entry. You can define multiple LDAP authentication configurations for a realm.
Membership	Enables 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 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 with Access Manager without having to provide the login information again. Leverages Kerberos authentication and is specific to the Windows operating system.
Windows NT	Uses a Microsoft Windows NTTM server to verify identities.

You can use the Access Manager Console to enable and configure the authentication modules that are installed with Access Manager by default. 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 Access Manager authentication framework. See Chapter 4, Managing Authentication, in Sun Java System Access Manager 7.1 Administration Guide for detailed information about enabling and configuring default authentication modules and authentication module instances. See Chapter 2, Using Authentication APIs and SPIs, in Sun Java System Access Manager 7.1 Developer’s Guide for more information about writing custom authentication modules.

Authentication Configuration Services

The Authentication framework includes the following pluggable and customizable services:

• General Authentication Service

• 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.) Configuration is available in each configured realm. 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. For more information, see Chapter 4, Managing Authentication, in Sun Java System Access Manager 7.1 Administration Guide.

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. For more information, see Role-based Authentication in Sun Java System Access Manager 7.1 Administration Guide.

Authentication Service User Interface

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

The Authentication Service user interface can be used for the following:

• 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.1 provides customization support for the Authentication Service user interface. You can customize JavaServer Pages™ (JSP™) and the file directory level for /org/service/locale/client_type. See Chapter 12, Customizing the Authentication User Interface, in Sun Java System Access Manager 7.1 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. A web browser communicates an HTTP request to the remote authentication user interface which, in turn, presents a 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 to the Access Manager server. The Distributed Authentication User Interface enables a policy agent or an application that is deployed in a non-secured area to communicate with an instance of the Access Manager Authentication Service installed in a secured area of the deployment. The following figure illustrates this scenario.

Figure 3–1 Distributed Authentication

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 an Access Manager deployment. The remote component then works with the Authentication client APIs and authentication utility classes to authenticate web users. For a more detailed process flow, see User Authentication. For detailed installation and configuration instructions, see Chapter 11, Deploying a Distributed Authentication UI Server, in Sun Java System Access Manager 7.1 Postinstallation Guide.

Inside the Core Authentication Component

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

• Client Detection Service

• Authentication Type Configurations

• Login URLs and Redirection URLs

• Account Locking

• Authentication Chaining

• Fully Qualified Domain Name Mapping

• Persistent Cookie

• Session Upgrade

• Validation Plug-in Interface

• JAAS Shared State

Client Detection Service

An initial step in the authentication 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. For more information, see Chapter 7, Client Detection Service, in Sun Java System Access Manager 7.1 Developer’s Guide.

Authentication Type Configurations

After granting or denying access to a resource, Access Manager checks for information about where to redirect the user. A specific order of precedence is used 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. When you install Access Manager, a number of authentication types are automatically configured for you. Following is a list of authentication type configurations. For more information, see Authentication Types in Sun Java System Access Manager 7.1 Administration Guide.

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 grouping of like items in the repository. A static role is created when an attribute is assigned to a specific user or container. A filtered role is dynamically generated based on an attribute contained in the a user’s or container’s entry. For example, all users that contain a value for the employee attribute 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.

Organization-based Authentication.

User authenticates to an organization or suborganization.

---

Note –

This authentication type only applies to Access Manager when installed in Legacy mode.

---

Login URLs and 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 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 (realm-based, role-based, and so forth) 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 Access Manager proceeds through the order of precedence, see Authentication Types in Sun Java System Access Manager 7.1 Administration Guide.

Account Locking

The Authentication Service provides an account locking feature that 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. Access Manager supports the following types of account 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.

The account locking feature is disabled by default. You can enable it by using the Access Manager console. For more information, see Account Locking in Sun Java System Access Manager 7.1 Administration Guide.

Authentication Chaining

You can configure one or more authentication module instances so that a user must pass authentication credentials to all of them before the user is allowed access. This feature is called authentication chaining. Access Manager uses the Java Authentication and Authorization Service (JAAS) framework (already integrated in the Authentication Service) to implement authentication chaining. The JAAS framework validates all user IDs used during the authentication process, and 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, 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 can configure authentication chaining by realm, user, role, or service. Determining access is based upon control flags you specify for the chain. Authentication modules use one of the following control flags to indicate requirements for successful authentication.

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 fail and the user will be notified of this.

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.

For more information, see Authentication Chaining in Sun Java System Access Manager 7.1 Administration Guide.

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 is also used to allow access to one instance of Access Manager using many different aliases. For example, you might configure one instance of Access Manager as intranet.example.com for employees and extranet.example.com for partners. For more information, see Fully Qualified Domain Name Mapping in Sun Java System Access Manager 7.1 Administration Guide.

Persistent Cookie

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. For more information, see Persistent Cookie in Sun Java System Access Manager 7.1 Administration Guide.

Session Upgrade

The Authentication Service allows for the upgrade of a valid session token based on a second, successful authentication performed by the same user. If a user with a valid session token 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 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. For more information, see Session Upgrade in Sun Java System Access Manager 7.1 Administration Guide.

Validation Plug-in Interface

An administrator can write username or password validation logic appropriate for a particular realm, and plug the logic into the Authentication Service. Before authenticating a user or changing the user password, Access Manager will invoke 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. For more information, see Validation Plug-in Interface in Sun Java System Access Manager 7.1 Administration Guide.

---

Note –

The Validation Plug-In Interface is only supported by the LDAP and Membership authentication module types.

---

JAAS Shared State

The JAAS shared state enables 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. For more information, see JAAS Shared State in Sun Java System Access Manager 7.1 Administration Guide.

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. 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 also use the XML/HTTP interface directly to initiate an authentication request.

Additionally, you can add custom authentication modules to Access Manager by using the com.iplanet.authentication.spi package. 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 2, Using Authentication APIs and SPIs, in Sun Java System Access Manager 7.1 Developer’s Guide.