Federation enables a more centralized identity model that can be selectively shared across disparate domains and allows an end user to create, maintain, and control a singular identity.
Federated Identity as a concept is built on top of the OpenID Connect (OIDC) and OAuth 2.0 standards. This article assumes that the reader has a base understanding of Modern Authentication models and a working understanding of the purpose and function of the SCIM protocol.
As the Digital Revolution moves from Web 2.0 to Web 3.0, identity and security are at the core of the conversation. Identity theft and ransomware attacks are prevalent in the news, and the Identity Theft Research Center reported a 68% increase in data compromises from 2020 to 2021.
To combat the privacy concerns of the Web 2.0 world, the World Wide Web Consortium (W3C) has worked to develop the concept of Decentralized Identifier (DID). While some of the largest names on the internet (e.g., Microsoft, Google, Apple, Mozilla) have formed the Web Hypertext Application Technology Working Group (WHATWG) and have said they oppose the DID standard, the point remains that a central or more uniform concept of Identity within the digital world is both necessary and imminent.
The purpose of this article is to inform the direction and debate of identity, identify the causality of these problems superficially, and then focus on the agreed-upon standards and implementations that exist today.
Federation in the Real World
The best analogy of Federation within the physical world is the concept of a passport.
An individual is issued a passport by their country of origin: a time-bound, signed document that asserts information about the bearer. If a United States citizen wishes to travel to Canada, Canada does not have to validate the information about the individual; it trusts the US issuance and allows the individual in.
This is the concept of Federation in a nutshell. The User wants to access some Resource (Canadian soil), and that Resource is controlled by an IdP (Canadian Customs), but that IdP does not act as the source of that user information. Instead, it Federates to the Profile Source IdP (US Government) and grants access to its Resource purely because it trusts the access from the originating IdP (US Government).
Passwords
According to a report from LastPass, the average business user has 191 passwords that they must keep track of and manage. Additionally, National Institute of Standards and Technology (NIST) guidelines around password complexity and makeup have changed over the years.
Where password complexity (upper/lower/number/special) combined with rotation frequency used to be the standards of good password hygiene, NIST has changed the recommendation, instead focusing on the length over complexity, and has advised against forced password rotation.
This is largely because users simply have so many passwords to manage, that when they’re forced to rotate them frequently they cannot remember the latest permutation and resort to writing them down on sticky notes next to their computer. What NIST is saying is that we are making it harder for humans to remember their passwords and easier for computers to guess.
Federation
NIST defines Federation as “a process that allows the conveyance of identity and authentication information across a set of networked systems.”
This approach is sound, given that the problems presented by passwords suggest a logical solution is to reduce the number of passwords that a user needs to remember.
Ideally a user can establish their identity with a centralized Identity Provider (IdP) and then convey that identity between one or more “networked systems.” This is Single Sign-On (SSO) for the internet, not just for a set of systems within a single domain.
It is also important to note that each of the federated domains must establish trust with the IdP—a universal solution such as the DID is more the pinnacle of idealism, rather than a current reality.
IdP(s) and Federation
The core concept of SSO is rooted in the capabilities of Federation. Here we want to emphasize those federated cases in which disparate domains are required to trust each other.
In these, and most, cases, two IdPs are required to agree on who the owner of the user identity (IdP) is and who becomes the delegator of identity (Service Provider [SP] or Resource Provider [RP]). The RP in this case might be considered an IdP to other services but will federate some or all identity duties out to the formal IdP.
Consider the following diagram:
A User comes to an Application (Step 1) and wants access to a Service or Resource. This application is federated (little f, to designate a trusted domain) to an IdP (e.g., Okta, Microsoft AAD). However, this user has a profile that is sourced from a secondary IdP.
The application delegates access to the IdP as a RP (Step 2), which then delegates the identity to the profile source IdP (Step 3). Once the Profile Source IdP validates the user identity, it will pass access (e.g., a token) back to the IdP as an RP (Step 4).
The IdP as an RP then establishes the requisite session or access (i.e., a [new] signed token) and passes that back to the original calling application (Step 5).
At this point the User is provided access to the application. Since the User now has established sessions with both the IdP as an RP and the Profile Source IdP, the User can access another application (Step 6 and Step 8) that will ask its IdP (Step 7 and Step 9) for validation. This immediately allows the User access due to the existing session (provided the lifetime of the session has not been exceeded).
Enhance Federation
While Federation is a phenomenal tool for addressing (or at least reducing) the problem of “too many passwords,” it is not without its limitations.
In a purely federated system, updates to the validity of a User (if the User still allowed to log in) and attributes of a profile (information about that user) only occur when a user successfully executes a login to the federated system.
By way of the real-world example above, Canada does not have a record of all US citizens who obtain passports. Instead, when a US citizen enters Canada, they are recorded Just-in-Time and Canada has a limited amount of information about that individual User.
In typical Federated systems, the same concept is true: the User in the diagram above has stored their profile in the Profile Source IdP, but the IdP as an RP only has a limited amount of information—and that information is only updated when the IdP as an RP needs to Federate that User identity to itself or its applications.
This is where SCIM, or the System for Cross Domain Identity Management, comes into play.
SCIM allows a normalized medium by which the Profile Source IdP can proactively share some or all of the User details with the IdP as an RP. While SCIM is not a requirement for Federation, it is a huge enhancement that can significantly improve upon the capabilities of all systems involved.
Conclusion
Identity is central to the concepts of the modern world, and digital identity is becoming harder and harder to manage. Something as simple as an address change can take hours, days, or even weeks to propagate through the various systems that a single User interacts with.
Federation enables businesses to allow employee access to customer tools (with the employee identity) and enables an automatic deprovisioning model.
Are you or your company struggling with identity across distributed systems? If so, we hope this helps, but if you need more information or assistance, please reach out to us—we are happy to help.
