Last week, we dove into Single Sign-On (SSO). This time we’re going to take a look at Federated Identity Management (FIM). It’s easy to confuse these two concepts, but SSO involves a user logging in once and then gaining access to multiple systems within the context of a single organization. In contrast, FIM allows a user to log in once and then access multiple separate systems. In other words, while SSO enables access to resources within a single domain, FIM allows access to resources and applications across multiple domains or organizations. With FIM, a user can access both company-owned systems as well as systems that the organization doesn’t control. However, the systems have to be part of the same federation—we’ll discuss federations in a moment.
You probably come across federated identity a lot, especially when you go to a website’s sign in page and see options for “log in with Google” or “log in with Facebook”, even though the website is a completely unrelated organization.
There’s a reason that you mostly see these buttons from major tech companies like Google, Apple, Twitter and Facebook—it’s because these major players generally have pretty good security and access control mechanisms, so other companies trust them to do the authentication on their behalf. You’re never going to see a “Log in with Greasy Bob’s Unlicensed Casino” button, because other companies aren’t going to trust Greasy Bob’s authentication process.
How does federated identity work?
If a group of organizations decides that it wants to share user identities between themselves, they can establish a federation. However, the organizations need to be able to trust each other to authenticate users appropriately. Once the federation has been set up, users can log in to one organization’s systems. These credentials are then matched up with federated identities, which allow the users to move between the systems of all of the other organizations within the federation.
The users only need the single account, and they only have to log in once, but they gain federation-wide access. Ultimately, this provides a better user experience, and the smaller number of accounts a user has to maintain may make them less likely to recycle their passwords across multiple accounts.
However, much like single sign-on, federated identity may have some downsides that come from centralization. If an attacker compromises an account with federated identity, they can access all of the user’s resources from across the entire federation. Similarly, if the system for the federated identity goes down, they could be locked out of all of the federation’s resources until it’s back online. Federated identity also introduces greater complexity in exchange for the convenience it provides to users.
Federated identity involves three major roles:
- The user (or the principal) – This is the person that wants to gain access to resources within the federation.
- The identity provider – This is the entity that owns the user’s identity and performs the authentication.
- The relying party (or the service provider) – This is the entity that trusts the identity provider’s authentication process. It allows users to access resources on its platform if they have been authenticated by the relying party.
Let’s say you visit Pinterest and decide you want to start using its services. You notice the “log in with Google” button, and since you already have to remember dozens of other passwords, you figure you will give it a shot. In this case, you are obviously the user, Google is the identity provider, and Pinterest is the relying party.
You click the “Log in with Google” button, which brings you to a window where you log in to Google with your Google credentials. Once you successfully authenticate with Google, you can access Pinterest, because both Pinterest and Google are in a federation together. Within the federation, Pinterest acts as the relying party, and it trusts Google’s authentication process as an identity provider. The trust between these organizations is what allows users to gain access without having to constantly jump through the hoops of authentication.
