...
A number of factors have, in recent years, led to increasing deployment of multiple single sign-on (SSO) solutions within individual organizations. Different consumers of SSO services may require different SSO protocols/APIs (eg., SAML vs. OIDC vs. WS-* vs. CAS); implementations of the same protocol may differ in ways that require different SSO providers due to variant interpretations of standards; some (primarily commercial) services may even provide their own self-contained SSO solutions. Apart from the expense of operating multiple SSO systems, this fragmentation of SSO services produces an undesirable, high-friction user experience, and can threaten the consistency and security of identity and access management (IAM) across disparate systems. Required to interact with multiple, unlinked SSO services, users may become confused as to what credentials to use when, and which “sign on” service(s) they should trust. They may quite rightly question how their experience can be termed “single” sign on at all.
A common, and in many cases the only viable approach to reducing friction and limiting the negative impact of SSO service fragmentation on users involves linking disparate SSO systems together, usually with the goal of providing a consistent point of authentication for the end user while allowing SSO consumers (relying parties) to integrate with different linked component services as necessary.
Multiple strategies for linking particular SSO systems may be used, each with different effects on the user experience, security, and federation capabilities. The choice, for example, of which SSO system will be responsible for end-user interaction, and how the integration between linked systems is accomplished, may expand or limit options for such important features as multi-factor authentication (MFA). No single linking strategy may be “optimal” for all sites and all scenarios, but each strategy has strengths and weaknesses which need to be considered when an organization designs a solution.
This report details the creation of the InCommon Linking SSO Working Group and it's attempt to document some of the known strategies for linking SSO systems and significant issues and benefits around each. After compiling the rational for the linked IdP scenarios it was very clear that a core value proposition for Linking linking SSO systems is the ability to federate an otherwise non-InCommon-compatible IdP with InCommon, a multilateral federation. Other common value propositions on linking SSO systems involved less user friction due to consistent login experiences, and even the ability to create temporary transition states or migration paths between different SSO products or solutions.
...