Identity Federation Design Patterns: 6 – Integration with a Central IAM

June 19, 2014

Like previous post, let’s assume that a Product 1 user is given access to Product 2 (product or services) and we want to provide this customer with an integrated product experience. In this design pattern we enable this single sign-on experience by leveraging a central IAM system in between the two systems

The high level data flow will be similar to the flow shown below:


IAM Data Flow: Data from order processing systems  continues to interact directly with each application’s Identity Provider . The data is synchronized from each Identity Provider into the IAM solution – where the user’s central profile is maintained. In addition to user-based information, the central IAM solution maintains a mapping of accounts in between the application-specific Identity Providers and flags indicating inter-application data sharing.

  1. Product 1 users that have been permitted access to Product 2 data will see a link for Product 2 once they authenticate into Product 1. (When the user clicks on the Product 2 link, they would like to have access to their Product 2 screens/data).
  2. The Product 1 application connects to IAM to retrieve the user id (or token) that grants the Product 1 application access to their Product 2 account.
  3. IAM returns the requested user id (or token).
  4. Product 1 calls (passes control) to Product 2 with necessary assertion/token requesting user access to Product 2 services.
  5. The Product 2 application verifies the assertion/token with the IAM solution.
  6. The IAM solution verifies the security of the request and returns the information to Product 2.
  7. Product 2 provides access to the services that the customer is entitled to.

Using the data flow mentioned above (or a variant) the Product 1 user can be granted access to Product 2 services. Once this flow is implemented the user who logs in to Product 1 will be provided access.

  1. The user’s identity will remain different between Product 2 and Product 1 until such time as those applications begin using the central Identity Provider included in the IAM solution
    • A common interface can be implemented to allow users to maintain their profile data from a central location.
    • Bi-directional synchronization of data can be implemented until such time as these applications decide to migrate.
  2. Implementing SSO across multiple products requires integration to the central IAM solution – not each individual application
    • Minimizes the complexity and reuses existing interactions
  3. Users will experience single sign on across web-based or fat clients


This is a broad topic, so I have split this content in different blogs to help focus discussion on sub topics in different blogs.

Also if you liked this blog then you might also like my previous blog “Benefits of Identity and Access Management as­ Corporate Service

Related Articles

Radical and Incremental Innovation

Radical and Incremental Innovation

Yes, Old topics die hard! I was re-reading some old articles about types of innovations, and measuring the effectiveness of different project investments and thought of posting this to the wider community to get some help & feedback. Radical / Disruptive...