Companies have dozens of different systems that contain customer identity data and these systems are used by more than hundreds of
products. Having multiple identity systems not only limits the ability to leverage assets easily across the organization but it also provides suboptimal customer experience and prevents us from tracking customers across products.
Consolidating the different identity systems will take multiple years, during which there often is a need to provide value added services
to customers by leveraging system across business boundaries and by reusing existing product widgets. These value added services will require identity federation, so that products can understand various IDs users have across different products.
SAML & OAuth are terms (protocols) often mentioned as methods of connecting various products using different identity systems. There are many challenges associated with implementing SAML and OAuth in most current product environments. To overcome these challenges we will have to make significant changes to our current systems and in many cases implement complex new data flows. Even a handful of such implementations will result in a significantly more complex system, which can be error prone and very difficult to maintain.
By leveraging a central IAM solution as a middle layer for federation, the complexity around user ID mapping across different systems and
user life cycle management (user provisioning/deprovisioning) is isolated away from products to the central layer. User mapping performed once
in the central IAM solution can be leveraged by all business units for federation. Moreover standard design patterns & APIs offered by the
central IAM will significantly simplify the management of systems, and provide enhanced security across Thomson Reuters. Finally, theunified identity provided by an IAM solution facilitates methods for monitoring a user’s activity as they interact with Thomson Reuters’ products.
This information can then be used to better understand our customer’s habits and offer additional services.
Identity alone cannot solve our content sharing problems, final solution will require coordination with backend entitlement systems too but
centralized identity mapping makes federation easier. This blog is first part of a 7 blog series of my brain dump around federation with a goal of
driving conversation about identity with my friends and colleagues across business units.
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“