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.)