Two trust models in Identity Federation

Identity federation is a key part of interconnecting disparate systems. This article focuses on a cornerstone of identity federation, which is the delegation of user authentication, and this aspect is examined in light of the trust that must exist between identity-federated systems: unidirectional trust in some cases, and bidirectional in others.

Identity Federation at its most basic level involves only two parties: the Identity Provider and the Relying Party. Let’s take a hypothetical use case as an example, where the Identity Provider is referred to as “Company IDP” and the Relying Party is called “Company RP.” All users who visit Company RP’s site must be authenticated prior to being granted access. However, Company RP doesn’t store information about each user that would allow it to perform this authentication process itself. For this authentication task, Company RP’s system will delegate that responsibility to another completely separate system – a system controlled by Company IDP. To determine whether a user should be granted access to Company RP’s secure system, the Relying Party will trust Company IDP to perform user authentication, but Company IDP need not trust Company RP in exchange, which brings us to the first type of identity federation trust.

Relying Party Trust in Identity Provider

This level of trust is common in identity federation. When the user enters a username and password, these inputs are being supplied to a user interface presented and wholly controlled by the Identity Provider. The Relying Party is in no way involved in capturing the username and password. The Relying Party is merely a service provider who only wants to know the user is authenticated and trusts the Identity Provider application to perform this authentication. This type of system trust should be familiar to most users, who see examples when they are allowed to use their Facebook, Google, or Windows Live account (to name only three common examples) to access another system. In this case the Identity Provider is Facebook, Google, or Microsoft, and the user will supply his or her login credentials for those accounts directly within a Facebook, Google, or Microsoft system context. None of these systems actually share the user’s login information with the Relying Party system. Rather, the Identity Provider will authenticate the login information and pass along a token to the Relying Party indicating the user is authentic.

Here is a good example of identity federation involving two commonly used web apps – Photobucket and Twitter. When a user navigates to Photobucket’s site, he or she can enter login credentials directly into Photobucket’s system, or the user can choose to use either Facebook or Twitter.


For this real-world example, let’s say the user wants to use her Twitter account credentials to access Photobucket. Perhaps she doesn’t remember her credentials for direct user login into Photobucket. After all, that is another username and password she has to keep track of. The following popup window is what she will see when she clicks on the Twitter Sign In button:


It should be noted that even though the Identity Provider does not share the user’s username and password with the Relying Party, the Identity Provider will commonly pass along identifying attributes such as the name associated with the credentials, as well as things like a profile photo, and birthdate even. (As a side note, even these data may present issues. As of this writing, Facebook, for example, very recently introduced an “anonymous” login feature. It’s not technically an anonymous login, but the federation process does not share name, profile photo, birthdate, etc. See more here: )

Two-way trust between Relying Party and Identity Provider

In a world of casual web surfing and ad hoc online accounts for personal purposes, the Identity Providers such as Facebook and Twitter will not need to trust all possible Relying Parties (there are too many of them), while the Relying Party will have complete trust in the Identity Provider, at least as far as authenticating the user is concerned. But some systems need trust to be bidirectional, a principle behind many organization-to-organization system integrations. This type of two-way trust can be built on something informal such as a familiar working relationship between departments or businesses, or something formal such as a legal agreement that permits parties to exchange sensitive information with each other in full confidence that this trust will not be violated. This type of two-way trust may well involve the Identity Provider allowing the Relying Party to capture the username and password within its system boundary. Nevertheless, the Identity Provider system will still play the authoritative role in authenticating the user. If the username and password are not valid, then the Identity Provider will fail that login attempt made directly against the Relying Party.

The next article will provide a walkthrough of a solution involving two-way trust between an Identity Provider and a Relying Party.