By hubertsblog on Oct 22, 2006
In my previous post I talked about a bootcamp I attended that focuses on identity federation. In this entry I will discuss what identity federation is and what its purpose is. To do so I will be describing the scenario that forms the basis for all the labs the students of the bootcamp go through. I will also borrow some of the excellent illustrations they have in their material.
First, let’s describe the situation that is mostly prevalent today, that is when no federation exists. Every time a user (John Doe) visits a new web site ( we call them Service Providers - SP) and wants to do business with it he must create a local account at the SP. Because all these online applications have their own policy when it comes to user account creation (security etc.), the resulting situation is that John has (almost) as many different accounts as Service Providers. Later on, he will have to enter his account information (usually username and password) every time he visits one of those SP as described in the figure below:
The situation might be slightly better in the enterprise world where common authentication (single sign-on) can be achieved using LDAP (and other mechanisms) but I have yet to hear of a (big) company where employees don’t have several accounts to deal with.
I know some people might say: why is it a bad thing to have all those accounts? Well there are several issues with that:
The user’s online experience is bad as his surfing experience is constantly interrupted by authentication procedures.
The user needs to remember all those accounts ; the 2 most widely ways of achieving this is either to use the same username/password combination (though not always possible) or write down all that information on a post-it and stick it on the side of your screen. Obviously not ideal security-wise.
Each Service Provider needs to perform authentication at a satisfying level - this represents additional cost for the SP.
There is no possibility of sharing attributes between Service Providers: John will have to enter the same personal information (e.g. his shipping address) at every single SP that may need it. The problem is that it then becomes painful for the user to update those scattered bits of information. Also there’s a higher chance the info a SP hosts is no up-to-date.
The idea of federation is to alleviate all these issues by enabling the sharing of a user’s authentication status (and beyond that of attributes). Of course the adopted architecture must preserve both the user’s privacy (no unsolicited correlation between SPs, prior user consent to exchange of information...) as well as the security and confidentiality of the Service Provider’s relation with that user. The now predominant SAML 2.0 offers an elegant architecture that does meet those requirements and many more (note: Liberty’s ID-FF does too since it constitutes the basis of what SAML 2.0 is).
The overarching concept behind identity federation is that each SP establishes a relationship with a particular service provider we call identity provider (IdP). The IdP will be the one authenticating the user (local account for John at the IdP) and asserting that authentication (or the lack of it) to the requesting SP. To make sure the SP does not give up information about his customers to the IdP both the SP and the IdP agree to use a nonce (a random and unique number) that has no meaning except in the context of this federation. A typical IdP would be a service provider both you and SPs that will federate with can trust (more on that later), something like your bank online service or your ISP.
The result is a hub-and-spoke architecture with 1-to-1 relationships between the SPs and the IdP. See the figure below:
That’s it for today, more on federation to come soon!