How Authentication Types Determine Access

For each of these methods, the user can either pass or fail the authentication. Once the determination has been made, each method follows this procedure. Step 1 through Step 3 follows a successful authentication; Step 4 follows both successful and failed authentication.

1. Access Manager confirms whether the authenticated user(s) is defined in the Directory Server data store and whether the profile is active.

   The User Profile attribute in the Core Authentication module can be defined as Required, Dynamic, Dynamic with User Alias, or Ignored. Following a successful authentication, Access Manager confirms whether the authenticated user(s) is defined in the Directory Server data store and, if the User Profile value is Required, confirms that the profile is active. (This is the default case.) If the User Profile is Dynamically Configured, the Authentication Service will create the user profile in the Directory Server data store. If the User Profile is set to Ignore, the user validation will not be done.

2. Execution of the Authentication Post Processing SPI is accomplished.

   The Core Authentication module contains an Authentication Post Processing Class attribute which may contain the authentication post-processing class name as its value. AMPostAuthProcessInterface is the post-processing interface. It can be executed on either successful or failed authentication or on logout.

3. The following properties are added to, or updated in, the session token and the user’s session is activated.

   realm. This is the DN of the realm to which the user belongs.

   Principal. This is the DN of the user.

   Principals. This is a list of names to which the user has authenticated. (This property may have more then one value defined as a pipe separated list.)

   UserId. This is the user’s DN as returned by the module, or in the case of modules other than LDAP or Membership, the user name. (All Principals must map to the same user. The UserID is the user DN to which they map.)

   ---

   Note –

   This property may be a non-DN value.

   ---

   UserToken. This is a user name. (All Principals must map to the same user. The UserToken is the user name to which they map.)

   Host. This is the host name or IP address for the client.

   authLevel. This is the highest level to which the user has authenticated.

   AuthType. This is a pipe separated list of authentication modules to which the user has authenticated (for example, module1|module2|module3).

   clientType. This is the device type of the client browser.

   Locale. This is the locale of the client.

   CharSet. This is the determined character set for the client.

   Role. Applicable for role-based authentication only, this is the role to which the user belongs.

   Service. Applicable for service-based authentication only, this is the service to which the user belongs.

4. Access Manager looks for information on where to redirect the user after either a successful or failed authentication.

   URL redirection can be to either an Access Manager page or a URL. The redirection is based on an order of precedence in which Access Manager looks for redirection based on the authentication method and whether the authentication has been successful or has failed. This order is detailed in the URL redirection portions of the following authentication methods sections.

URL Redirection

In the Authentication Configuration service, you can assign URL redirection for successful or unsuccessful authentication. The URLs, themselves, are defined in the Login Success URL and Login Failure URL attributes in this service. In order to enable URL redirection, you must add the Authentication Configuration service to your realm to make it available to configure for a role, realm, or user. Make sure that you add an authentication module, such as LDAP - REQUIRED, when adding the Authentication Configuration service.