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.
- 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.
- 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.)
- The Product 1 application connects to its internal identity system database to retrieve the user id (or token) for their Product 2 account.
- Product 1 identity system (or its internal database) returns the requested user id (or token)
- Product 1 calls (passes control) to Product 2 with necessary assertion/token requesting user access to Product 2 services.
- The Product 2 application calls product 2 identity system to verify received assertion/token.
- 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.
- 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:
- 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”.)
- 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
- 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.
- Identity Federation Design Patterns: 1 – Executive Summary
- Identity Federation Design Patterns: 2 – Introduction
- Identity Federation Design Patterns: 3 – SAML
- Identity Federation Design Patterns: 4 – Open Authorization (“Oauth”)
- Identity Federation Design Patterns: 5 – Integration without IAM
- Identity Federation Design Patterns: 6 – Integration with a Central IAM
Also if you liked this blog then you might also like my previous blog “Benefits of Identity and Access Management as Corporate Service“