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.
- 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).
- 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.
- IAM 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 verifies the assertion/token with the IAM solution.
- The IAM solution verifies the security of the request and returns the information to Product 2.
- 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.
- 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.
- Implementing SSO across multiple products requires integration to the central IAM solution – not each individual application
- Minimizes the complexity and reuses existing interactions
- 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.
- 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“