Pass-Through Authentication

Use pass-through authentication to grant user and administrator access through one or more different passwords.

Identity Manager manages authentication through the implementation of:

• Login applications (a collection of login module groups)

• Login module groups (an ordered set of login modules)

• Login modules (set authentication for each assigned resource and specify one of several success requirements for authentication)

About Login Applications

Login applications define a collection of login module groups, which further define the set and order of login modules that will be used when a user logs in to Identity Manager. Each login application comprises one or more login module groups.

At login, the login application checks its set of login module groups. If only one login module group is set, then it is used, and its contained login modules are processed in the group-defined order. If the login application has more than one defined login module group, then Identity Manager checks the login constraint rules applied to each login module group to determine which group to process.

Login Constraint Rules

Login constraint rules are applied to login module groups. For each set of login module groups in a login application, only one cannot have a login constraint rule applied to it.

When determining which login module group of a set to process, Identity Manager evaluates the first login module group’s constraint rule. If it succeeds, then it processes that login module group. If it fails, then it evaluates each login module group in turn, until a constraint rule succeeds or a login module group with no constraint rule is evaluated (and subsequently used).

If a login application will contain more than one login module group, then the login module group with no login constraint rules should be placed in the last position of the set.

Example Login Constraint Rule

In the following example of a location-based login constraint rule, the rule gets the IP address of the requester from the HTTP header, and then checks to see if it is located on the 192.168 network. If 192.168. is found in the IP address, then the rule will return a value of true, and this login module group is selected.

Example 12–1 Location-Based Login Constraint Rule

<Rule authType=’LoginConstraintRule’ name=’Sample On Local Network’> 
<match> <ref>remoteAddr</ref> <s>192.168.</s> </match> 
<MemberObjectGroups> <ObjectRef type=’ObjectGroup’ name=’All’/> </MemberObjectGroups> 
</Rule>

Editing Login Applications

From the menu bar, select Security -> Login to access the Login page.

The login application list shows:

• Each Identity Manager login application (interface) defined

• The login module groups that comprise the login application

• The Identity Manager session timeout limits set for each login application

From the Login page you can:

• Create custom login applications

• Delete custom login applications

• Manage login module groups

To edit a login application, select it from the list.

Setting Identity Manager Session Limits

From the Modify Login Application page, you can set a timeout value (limits) for each Identity Manager login session. Select hours, minutes, and seconds, and then click Save. The limits you establish display in the login application list.

You can set session timeouts for each Identity Manager login application. When a user logs in to an Identity Manager application, then the currently configured session timeout value is used to compute the future date and time when the user’s session will time out due to inactivity. This computed date is then stored with the user’s Identity Manager session so that it is available to be checked each time a request is made.

If a login administrator changes a login application session timeout value, then that value will be in effect for all future logins. Existing sessions will time out based on the value in effect when the user logged in.

Values set for HTTP timeout affect all Identity Manager applications and take precedence over the login application session timeout value.

Disabling Access to Applications

From the Create Login Application and Modify Login Application pages, you can select the Disable option to disable a login application, thereby preventing users from logging in. If a user tries to log in to a disabled application, the user is redirected to an alternate page that states that the application is currently disabled. You can edit the message that displays on this page by editing the custom catalog.

Login applications remain disabled until you deselect the option. As a safeguard, you cannot disable administrator login.

Editing Login Module Groups

The login module group list shows:

• Each login module group

• The individual login modules that make up a login module group

• Whether a login module group contains constraint rules

From the Login Module Groups page you can create, edit, and delete login module groups. Select a login module group from the list to edit it.

Editing Login Modules

Enter details or make selections for login modules as follows. (Not all options are available for each login module.)

• Login success requirement. Select a requirement that applies to this module. Selections are:

  • Required. The login module is required to succeed. Irrespective of whether it succeeds or fails, authentication proceeds to the next login module in the list. If it is the only login module, the administrator is successfully logged in.

  • Requisite. The login module is required to succeed. If it succeeds, authentication proceeds to the next login module in the list. If it fails, authentication does not proceed.

  • Sufficient. The login module is not required to succeed. If it does succeed, authentication does not proceed to the next login module, and the administrator is successfully logged in. If it fails, authentication continues to the next login module in the list.

  • Optional. The login module is not required to succeed. Irrespective of whether it succeeds or fails, authentication continues to the next login module in the list.

• Login search attributes. (LDAP only.) Specify an ordered list of LDAP user attribute names to be used when attempting to bind (log in) to the associated LDAP server. Each of the LDAP user attributes specified, along with the user’s specified login name, is used (in order) to search for a matching LDAP user. This allows a user to log in to Identity Manager by using an LDAP cn or email address (when Identity Manager is configured for pass-through to LDAP).

  For example, if you specify the following and the user attempts to log in as gwilson, then the LDAP resource will first attempt to find an LDAP user where cn=gwilson.

  cn

  mail

  If that succeeds, then the bind is attempted with the password specified by the user. If it does not succeed, then the LDAP resource will search for an LDAP user where mail=gwilson. If that also fails, then login fails.

  If you do not specify a value, then the default LDAP search attributes are:

  uid

  cn

• Login correlation rule. Select a login correlation rule to be used to map the login information provided by the user to an Identity Manager user. This rule is used to search for an Identity Manager user by using the logic specified in the rule. The rule must return a list of one or more AttributeConditions that will be used to search for an Identity Manager user that matches. The rule you select must have the LoginCorrelationRule authType. For a description of the steps Identity Manager takes to map an authenticated user ID to an Identity Manager user, see Example 12–2.

• New user name rule. Select a new user name rule to be used when automatically creating new Identity Manager users as part of login.

Click Save to save a login module. Once it is saved, you can position the module relative to all other modules in the login module group.

If Identity Manager login is configured to authenticate to more than one system, an account’s user ID and password should be the same across all systems that are targets of Identity Manager authentication.

If the user ID and password combinations differ, login will fail on each system whose user ID and password do not match the user ID and password entered on the Identity Manager User Login form.

Some of these systems may have a lockout policy enforcing the number of failed login attempts before an account is locked. For these systems, user accounts are eventually locked, even though the user’s login through Identity Manager continues to succeed.

Example 12–2 contains pseudocode that describes the steps Identity Manager takes to map authenticated user IDs to Identity Manager users.

Example 12–2 Login Module Processing Logic

if an existing IDM user’s ID is the same as the specified user ID 

   if that IDM user has a linked resource whose resource name matches the 
   resource that was authenticated and whose accountId matches the resource 
   accountId returned by successful authentication (e.g. dn), then we have 
   found the right IDM user 

   otherwise if there is a LoginCorrelationRule associated with the 
   configured login module 

      evaluate it to see if it maps the login credentials to a single IDM 
      user 

      otherwise login fails 

   otherwise login fails 

if the specified userID does not match an existing IDM user’s ID 

   try to find an IDM user that has a linked resource whose resource 
   name matches the resource accountID returned by successful authentication 

     if found, then we have found the right IDM user 

     otherwise if there is a LoginCorrelationRule associated with the 
     configured login module 

         evaluate it to see if it maps the login credentials to a single 
         IDM user 

         otherwise login fails 

     otherwise login fails

In Example 12–2, the system will try to find a matching Identity Manager user using the user’s linked resources (resource information). If the resource information approach fails, however, and a loginCorrelationRule is configured, the system will try to find a matching user using the loginCorrelationRule.