Identity Federation Design Patterns: 5 – Integration without IAM

June 18, 2014

Let us assume that a Product 1 user is given access to Product 2 (product or services) and we want to provide this customer an integrated product experience. There are multiple design patterns which can enable this single sign-on experience. These can range from placing a layer (IAM or other service) between the two systems to enable this federation or we can try to directly connect the applications.

If we provide a user access to Product 1 content from within the Product 2 application by directly connecting Product 2 and Product 1, the high level data flow will be similar to the diagram shown below:


Current Data flow: Data from order processing systems is loaded directly into each application’s Identity Provider. Product 2 and Product 1 then interact with their corresponding Identity Provider for authentication and authorization purposes.

  1. Prerequisite: Current and new customer data will be sent from Product 1 order processing system to product 2 identity provider so that product 2 identity provider can keep a mapping of product 2 user identity  to product 1 user identity; product 2 identity provider or Product 1 DB must also be modified to keep track of which users have access to Product 2 services.
  2. Product 1 users that have been permitted access to Product 2 data will see a Product 1 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.)
  3. The Product 1 application connects to its internal identity system database to retrieve the user id (or token) for their Product 2 account.
  4. Product 1 identity system (or its internal database) returns the requested user id (or token)
  5. Product 1 calls (passes control) to Product 2 with necessary assertion/token requesting user access to Product 2 services.
  6. The Product 2 application calls product 2 identity system to verify received assertion/token.
  7. Product 2 identity system verifies the security of the request, maps the provided Product 2 user identity ID to the internal Product 2 user identity, and grants access and returns to Product 2 the product 2 user ID.
  8. 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 but:

  1. The user’s identity will be different between Product 2 and Product 1 (i.e. different user id/password on both systems).
    • If the user changes their password on Product 2, the change won’t reflect in their Product 1 credentials.
    • Different profiles in different products may cause an “awkward” user experience. (In one product a user may be referred to as “William” but in the other they may go by “Bill”.)
  2. If the user first logs in to Product 2, they will not experience single sign on when attempting to connect to Product 1.
    • For this access a reverse flow will also need to be implemented
  3. Any two applications between which we want to enable a SSO experience will need to implement the above flow two times
    • Need for SSO customer experience between 5 systems will require 20 flows shown above (multiplicative growth in complexity), making it error prone and very hard to manage


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...