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.