This document provides an overview of the IdentityIQ Account Correlation feature and how to measure its success or failure.
IdentityIQ account correlation is the process of matching an application account to an IdentityIQ identity. Account correlation occurs during a regularly scheduled IdentityIQ aggregation task that extracts accounts from a connected system. The aggregation task is normally configured so that once an account is correlated, no attempt is made to re-correlate unless there is some relevant change to the account attribute values.
Accounts can be correlated by a simple attribute matching process where a key value of an identity is compared to a key value in the source application. Matching the account’s username attribute to the username of an existing identity is an example of a simple account correlation.
Correlation can also be done with an IdentityIQ correlation rule that programmatically implements any business requirements that may apply. If the rule is used in concert with attribute matching, the attribute match will only be used if the rule fails to correlate an account.
Finally, accounts can be correlated manually by an IdentityIQ administrator though the use of a UI page. This should only be used for outliers that are not handled by the other methods.
The best attributes for match or rule correlation should be unique, unchanging and non-sensitive in nature. For example, people can share the same first and last name. In some systems the account name is not unique on its own. Social security numbers are sensitive. These are all examples of attributes that should be avoided.
Correlation failure will be rare with proper project planning and execution.
Attribute match failure occurs when the key values cannot be matched. The causes are very simple and are preventable by proper data discovery and testing in lower environments:
• The data value or format is incorrect in either system.
• There are missing records in IdentityIQ.
• The data changes when it is extracted from the application or is transported to IdentityIQ.
Correlation rules apply business logic programmatically to the correlation process, so they can fail for additional reasons. Programmatic failures can occur if technical conditions are not handled in the rule. For example, if the correlation rule must look up an employee Id in an external system, and that system is not available, then correlation fails.
Business logic is also a cause of correlation rule failure if the rule is based on incorrect assumptions or the rule has not implemented the business logic properly. An incorrect assumption that all accounts that start with “C” will only correlate to a contractor can cause correlation failure. If the rule should, but does not make a case insensitive comparison of account name to identity name, that would be an implementation error.
Finding the cause of correlation rule failure is usually as simple as comparing the account data to the identity data. Rules with complex logic can be more difficult to troubleshoot, but the rule can have additional logging to help trace the cause of failure to the rule programming.
IdentityIQ has no correlation dashboard view that will show if correlation logic is working according to design. There are some ways to test if the correlation logic is working correctly.
IdentityIQ has reports that can provide a per application summary and detail view of uncorrelated accounts. This is the best way to get an overall measure of account correlation results from a completed aggregation task. The reports are highly customizable and customers must modify them if they have a need to analyze account correlation by dimensions other than application, such as department or account type.
Another way to check if correlation is working is to select a set of accounts that will flow through each correlation decision logic point in advance of the aggregation task. Once correlation is complete compare the expected to the actual correlation outcome.
Select a small set of accounts to aggregate, then review the results. If the results are as expected, then repeat this process until all accounts are correlated. Note that not all connectors will support this option. This is a simple, but time consuming option to check if correlation is working when an application is first deployed in IdentityIQ. This is not a good option for regular operations.
Correlation rules can have logic to raise an error when a correlation case does not fit the business logic, and IdentityIQ aggregation tasks can be configured to terminate when a specified number of errors occur. These two features can be used to uncover correlation that is not working as designed. This option will add development effort to the project.
The preferred method of remediating failed correlation depends on the number of failures and the nature of the failure. For a small number of failures that are expected to be infrequent or limited to the initial load of data, manual correlation might be sufficient.
Remediation of many accounts should not be needed in a well-planned and executed IdentityIQ project. When it does happen, the correlation logic must be corrected and a small configuration change is made to the aggregation task so that it will attempt to re-correlate the accounts.