Hi all,
everyone is always asking about how the unification module works, so the engineering team have written the attached document.
Please have a look and post back here if you have any questions or queries!
Overview
The Unification process is a means by which we can collect the identity of a user from different applications using Identity Data Collectors and unify pieces of information from each application to form the user’s corporate identity or master record. Consequently this master record will be used by the rest of ACM to associate all the user’s entitlements within the company to provide a comprehensive view of the user. Since this master record is an accumulation of information it is imperative to know what information is available from the various applications and which ones have maintain the data while others may just consume the information.
Example:
Our HR system allows the user to maintain their First and Last name, while the Active Directory uses this information just for displaying the name. In this case we would want to use HR as the source for the user’s name since this will be the most up to date information.
In order to join this information into a master record you must understand how a user is uniquely identified within an application as well as what types of information allow you to connect/join that user to other applications.
Example:
Using the previous example while we want the user’s name from the HR system, but it may not be the best way to connect that user in another application. This fails when you have more common names like John Smith. During the unification process the single HR user would be matched with all the records found in Active Directory and each would produce a different master record. The HR system will have a way to uniquely identify the user within that application, and if this identifier is also stored within the Active Directory it should be considered as a possible way to join this information. One should verify that a search of Active Directory using that identifier would produce a single record, otherwise it would produce the same results as a join on the user’s name.
You also need to identify what pieces of information you will use from each application to create the user. As above we decided that user’s name would be taken from the HR system. If you want to include the user’s email address you may find that is available in both the HR system and Active Directory. In that scenario you setup an attribute inheritance. When gathering the information for the master record you can take the email address from the Active Directory as long as the user has a record. If the user does not have a record then you could then specify to use the email address from the HR system.
