Linking to Accounts on Other Resources

Identity Manager uses correlation and confirmation rules to link accounts. A correlation rule looks for Identity Manager users that might own an account. It returns a list of users that match the criteria defined in the correlation rule. A confirmation rule tests an Identity Manager user against an account to determine whether the user actually does own the account. It returns true or false values. This two-stage approach allows Identity Manager to optimize correlation, by quickly finding possible owners (based on name or other attributes), and by performing expensive checks only on the possible owners.

Before you begin using correlation and confirmation rules, you must be familiar with the data that is present from the first data load. The Identity Manager accountId will always be present. If you performed a Load from File or a Create bulk action, then the values in the heading row of the CSV file are also present. If you performed a Load from Resource or reconciliation, some key attributes found on the resource will be present, but others will be present only if they are explicitly saved.

In addition, you must be familiar with the account data stored on the secondary resources as well. Ideally, a secondary resource contains data that overlaps with data that has already present in Identity Manager.

This can be more difficult than it sounds. Different resources often have varying requirements for user accounts. As an example, the following table compares the requirements and restrictions for a Windows account name and a Solaris account name.

The differences between Windows and Solaris account names highlight some of the difficulties in linking accounts:

• Because of the differences in maximum length, the account names will usually be different on these two systems. On Windows, users often have an account name that matches their first and last name. On Solaris, account names might be the concatenation of the first letter of the first name plus the first seven digits of the last name. Therefore, a correlation rule that compares account IDs will probably not be enough to link a Solaris account to a Windows account.

• To create a user account on Windows, the administrator must supply a display name. Solaris user accounts do not require display names, although the optional GECOS field can be used to specify a user’s name. There are no guidelines about the contents or format of this field. A user’s GECOS field might be blank or contain text unrelated to the user’s Windows display name. Therefore, a correlation rule that compares full names might not trigger as often as you would expect.

Consider the following questions as you prepare to link accounts:

• Do you have users with similar names, such as Mary A. Jones and Mary B. Jones, or John Doe Jr. and John Doe III? If so, how will you distinguish between them?

• Were account names on each resource defined in a consistent manner? If yes, then it will be easier to define a rule that compares an account ID on a resource with a value stored in Identity Manager.

• Did users have the ability to edit resource account data? If yes, then the data might not match values that are stored on a system that users cannot change.

Defining Custom Correlation Keys

A rule cannot compare an account value on a resource with an Identity Manager value unless the value is stored in the system. The accounts[Lighthouse] attribute stores many of these values, but additional values must be added with the Extended User Attributes Configuration object. The system does not save attributes that are not registered in the configuration object.

By default, the following attributes are included as extended user attributes:

• firstname

• lastname

• fullname

The fullname extended user attribute must be added to the list of QueryableAttrNames.

If you want to use a different attribute, such as an employee ID as part of a correlation rule, then you must add it to the User Extended Attributes configuration object. Use the following steps to do this:

To Define a Custom Correlation Key

1. Access the Identity Manager debug page at http://PathToIDM/debug. The System Settings page is displayed.

2. Select Configuration from the List Objects pull-down menu. The List Objects of type: Configuration page is displayed.

3. Select the edit link for User Extended Attributes.

4. Add the new attributes to the List element, for example:

   <String>EmployeeId</String>

5. The attribute must be defined as an Identity Manager attribute on the Account Attributes (schema map) page for the resource.

6. Save your changes. Identity Manager returns to the System Settings debug page.

   The custom attribute must also be added to the QueryableAttrNames element in the UserUIConfig configuration object.

7. Select Configuration from the List Objects pull-down menu. The List Objects of type: Configuration page is displayed.

8. Select the edit link for UserUIConfig.

9. Add the new attributes to the <QueryableAttrNames><List> element, for example:

   <String>EmployeeId</String>

10. Save your changes. Identity Manager returns to the System Settings debug page.

11. Restart your application server.

Creating Custom Rules

Identity Manager predefines a number of correlation and confirmation rules in sample/reconRules.xml. You can use these as a basis for your own rules. Rules must be assigned a subtype of SUBTYPE_ACCOUNT_CORRELATION_RULE or SUBTYPE_ACCOUNT_CONFIRMATION_RULE.

The following rule compares the account.EmployeeId attribute, which is defined on the secondary resource, with the EmployeeId attribute that was previously loaded into Identity Manager. If the secondary resource has an account.EmployeeId value, then the correlation rule returns a list of users that match the EmployeeId.

<Rule subtype=’SUBTYPE_ACCOUNT_CORRELATION_RULE’ name=’Correlate Employee IDs’
   <cond>
      <ref>account.EmployeeId</ref>
      <list>
         <new class=’com.waveset.object.AttributeCondition’>
            <s>EmployeeId</s>
            <s>equals</s>
            <ref>account.EmployeeId</ref>
         </new>
      </list>
   </cond>
</Rule>

In this example, the EmployeeId attribute has been previously added to the User Extended Attributes and UserUIConfig configuration objects. If this attribute has was not included as a default Identity Manager attribute name for the resource, it must also be added or edited on the schema map for the resource.

Correlation rules return a list of possible matches. If the results are expected to return only one match, such as an employee ID, then no confirmation rule would be needed. However, if there could be multiple matches, which could be the case if correlation found accounts that matched by first and last name, then a confirmation rule would be needed to further identify the match.

Rules can be added to Identity Manager by using the Identity Manager IDE, importing an XML file, or editing and renaming an existing rule using the debug page.

Manually Linking Accounts

Identity Manager provides several mechanisms that can be used to assign accounts when correlation and confirmation rules do not find a match.

Using the Account Index

The Account Index records the last known state of each resource account known to Identity Manager. It is primarily maintained by reconciliation, but other Identity Manager functions will also update the Account Index, as needed.

Load from resource, load from file, and bulk actions do not update the Account Index.

To view the account index, click the Resources tab, then click the Account Index link on the left. Then navigate to a resource to display the status of all accounts on that resource.

When you right-click on an uncorrelated account (represented in the Account Index table with a situation of “UNMATCHED” and an Owner of “_UNKNOWN_”), Identity Manager displays a menu that presents you with the options of creating a new Identity Manager user account, running reconciliation on a single account using the reconciliation policy in effect for the resource, specifying an owner, or deleting or disabling the resource account. If you select the “Specify Owner” option, Identity Manager displays a screen that allows you to search for owners that might criteria that you specify. Refer to Business Administrator's Guide for more information.

Enabling Self-Discovery

The Identity Manager User Interface can be configured to allow Identity Manager users to discover their own resource accounts. This means that a user with an Identity Manager identity can associate it with an existing, but unassociated, resource account. Self-discovery can be enabled only on resources that support pass-through authentication.

To enable self-discovery, you must edit the End User Resources configuration object, and add to it the name of each resource on which the user will be allowed to discover accounts.

To Enable Self-Discovery

1. Access the Identity Manager debug page at http://PathToIDM/debug. The System Settings page is displayed.

2. Select Configuration from the List Objects pull-down menu. The List Objects of type: Configuration page is displayed.

3. Select the edit link for End User Resources.

4. After the <List> element, add <String>Resource</String>, where Resource matches the name of a resource object in the repository. For example, to allow users to self-discover their accounts on resources AD and Solaris, edit the <List> element as follows:

   <List>
      <String>AD</String>
      <String>Solaris</String>
   </List>

5. Save your changes. Identity Manager returns to the System Settings debug page.

   When self-discovery is enabled, the user is presented with a new menu item on the Identity Manager User Interface (Inform Identity Manager of Other Accounts) This area allows him to select a resource from an available list, and then enter the resource account ID and password to link the account with his Identity Manager identity.