Figure 4: Create an identity hub by conducting an inventory of your current data sources, extracting the metadata from each source and creating a centralized identity layer. Click on image to enlarge.
Step 2: Aggregate and correlate identities to build a unique reference list
Once the existing schemas have been extracted, you can see how each data source defines identities and determine the best way to aggregate and correlate your identity data, in order to build a reference list where every user is represented only once. Using the schema information and the knowledge about any overlapping attribute values, you can create the correlation rules needed to create a unique global profile for each user.
Figure 5: For each user with overlapping identities, the hub should be able to pull all attributes from the original identity sources and include them in a rich global profile for authentication and authorization. Click on image to enlarge.
Step 3: Join identities to create global profiles
Different applications require different aspects of a user’s identity. Identity federation gives you the ability to join these aspects into one global profile, easily accessed by the IdP to package into security tokens for consuming applications. Credentials are kept in the original data source, and identity correlation ensures that users with similar names are not given inappropriate access.
Step 4: Rationalize Groups
Figure 6: For each user with overlapping identities, the hub should be able to pull all attributes from the original identity sources and include them in a rich global profile for authentication and authorization. Click on image to enlarge.
The hub should also be able to leverage and remap existing groups. In such a scenario, the IdP would only need to search the hub to check for group memberships to package into tokens for consuming applications. If you have existing groups that are sufficient for enforcing your policies today, you shouldn’t have to redo any work—the federated identity hub would simply virtualize your existing groups and the translation and Distinguished Name (DN) remapping would happen automatically.
Step 5: Cache resulting views for speed and scalability
A hub would also offer a choice of persistent caching options based on your deployment requirements and environment, so entries, queries, or modeled views could be cached for higher performance and availability, in real-time or on a scheduled basis. The persistence of materialized hierarchical views means query performance would no longer be constrained by complex joins and searches across multiple data sources.
Sign up for CIO Asia eNewsletters.