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.

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.