test

Sun OpenSSO Enterprise 8.0 Technical Overview

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.