In a previous blog post I wrote about the risks associated with federated identity management. In such systems users do not maintain login credentials for each and every service they use. Instead users have a single account at an identity provider, and a service provider provides access to its service once the user has successfully signed in to his identity provider. To illustrate the problem with this approach, I used the following analogy. Suppose you live in an apartment building with a janitor. Instead of you having the only keys to the door of your apartment, it's the janitor that has all keys to all apartments. And whenever you want to enter your apartment you ask the janitor to open the door for you. (In other words it's like a hotel, basically.) The risks are clear: the janitor can enter your apartment at will.
But in fact, this analogy fails to capture an even bigger problem with federated identity management. In actual fact, anybody claiming to be a janitor can enter your apartment.
To understand this, let's have a look at how federated identity management works in a little more detail. Whenever you want to access a service, the service provider redirects you to an identity provider. There may be many: you select the one you know and have an account with. You then login to your identity provider. When successful, the identity provider creates an access token. This token contains your identifier, i.e. who you are, and is signed by the identity provider. The token is forwarded to the service provider, who verifies the signature. If it is signed by an identity provider it trusts,it uses the identifier inside the token to determine the account to access.
Now if the token contains your name, or any other identifier like your social security number that anybody knows belongs to you, then anybody that the service provider (the lock on your apartment door) recognises as a trusted identity provider (any janitor) can create such token and access your account (your apartment). In such a federation I not only have to trust my own identity provider not to access my account behind my back. I have to trust all identity providers any of my service providers trust not to do so. There may be many of such identity providers, and I will certainly not know all of them, let alone trust them. This is clearly an absurd situation.
How can we limit this trust problem?
For this we return to the original analogy, where the janitor has the key that fits my apartment door. Other janitors do not have this key, and therefore cannot access my apartment. In other words, instead of using publicly known identifiers (like names or social security numbers) in the tokens generated by the identity providers, we need to use secret values (keys) for these identifiers that are only known to the identity provider and the service provider. This does mean that the secrecy of these identifiers needs to be protected. In practice this means the tokens generated by the identity provider need to be encrypted as well as being signed. If we use different keys for different service providers, this even adds some privacy protection, because service providers cannot link user accounts across service providers.
There is still a clear risk: any janitor you trusted with your keys can enter your apartment at will. But the others no longer can. And that at least puts the decision whom to trust with your apartment where it belongs: with you.
(For a much longer in depth study of security, privacy and usability issues with current identity management systems see: G. Alpár, J.-H. Hoepman, and J. Siljee. The Identity Crisis - Security, Privacy and Usability Issues in Identity Management. Journal of Information System Security, 9(1):23-53, 2013. A preprint was published onarXiv.)
[…] op de veiligheid van dergelijke systemen is overigens wel een en ander af te dingen. De kern van het probleem is dat een groot aantal partijen vertrouwd moet worden voor het maken van […]
[…] the federated (or networked) approach, and the claims-based approach. I have written about the risks associated with federated identity management before, and about the “identity crisis” […]
Your blog sensationalises the case. You are appealing to the ignorant and ill informed, as does the Sun newspaper, with sentences such as “In actual fact, anybody claiming to be a janitor can enter your apartment.” This statement is completely untrue and is not a fact, and, worse still you actually know this, because later on you state the truth in “I have to trust all identity providers any of my service providers trust”. Both you and I know that TRUST is the founding rock on which many security services like federated identity management are built, including PKI and TLS on which the entire Internet web service infrastructure rests. So please, lets have more honesty, and less sensationalism in your blog. Otherwise you wont be treated seriously.
Wow. I’m being compared to the Sun newspaper! There’s a first time for everything, I guess ;-) What you call sensationalising is actually my attempt to explain the issue to the layperson. Technology is often complex. Using metaphors helps to convey the main message also to the technically uninitiated. Every metaphor is of course a crude approximation of the actual thing it aims to describe, but in this case I actually believe it captures the problem quite well.
In the metaphor we have the apartment owner (the user), the apartment (the service provider) and the janitor (the identity provider). The apartment door opens (the service provider grants access) when the janitor unlocks it (the identity provider presents an access token) when asked by the apartment owner (the user signed in into the identity provider).
As you yourself say, the underlying issue is trust. More specifically the question is who needs to be trusted, with what, and who decides this. In some federated identity management systems, there is a federation scheme authority who decides which identity providers are trusted to generate access tokens. Service providers have to accept all such tokens from all ‘accredited’ identity providers. In terms of the metaphor: “In actual fact, anybody claiming to be a janitor (by showing a certificate from the International Janitor Association) can enter your apartment.” I now added the explanation within parentheses here for further clarification; the International Janitor Association is the federation scheme authority.
In other federated identity management systems, the service providers themselves keep a list of identity providers they trust. This corresponds to: “I have to trust all identity providers any of my service providers trust”. But note that in many cases the service providers download these lists from the federation, which brings us essentially back to case explained above.
Interestingly enough your example of PKI and TLS, on which the entire Internet web service infrastructure indeed rests, are both a good example of the problem. Both suffer from severe trust issues, as for example the Diginotar case clearly showed. Compromise of one Certification Authority (CA) should not make the whole web vulnerable. In a typical PKI (and hence TLS) this is however the case by definition because any CA can sign any certificate that is then accepted as valid by all users (browsers in this case) of the PKI. In TLS there are many different CAs that are either directly or indirectly trusted by all modern web browsers. Some CAs are controlled by American businesses or government. Others are controlled by Chinese businesses or government. In principle this allows a Chinese government to create a fake certificate for .com domain (the American’s can do the same for .com and .cn domains). As a result it may convince me I am securely browsing the website of Barclays bank (barclays.com) whereas in actual fact I am connected to a fake. (To be clear, in order for this attack to work, the attacker has to also trick me into surfing to the fake website instead of the actual one, for example by sending me an email with a fake link, or by being a man-in-the-middle somewhere in the network.)
Clearly there are risks in this example already, but what if the PKI was not used to authenticate the website of the bank to me, but instead was used to authenticate me to the bank. In that case, the Chinese (or the American) government could easily rob me blind… Would you be willing to let such an access infrastructure decide who gets to access your bank account?