Identity Providers
Previous Posts in this series:
Identity Providers is a big topic so I am going to break it into a couple of posts. Firstly general information about Identity Providers and in my next post I am going to give some pro’s and con’s of different authentication methods that can be used by them.
Identity Providers are a great example of why I like federation; why get the many sites across Government to solve this problem – centralise it. Now this concept is not new, we have had centralised identity providers for a while, however they often followed a web service model. So I would go to the Contoso City Council web site, enter in my UserID and Password and the site would take that information and call a central web service to validate the credentials with the central Identity Provider. The issue I have with this is that it is very brittle and difficult to update or change.
Flexibility over time
What happens when you want to add a new way of authenticating or and update to an existing authentication process? Imagine you want to implement a passphrase in a way similar to many banks, where I enter a UserID and password, and then get prompted for three characters from a pass phrase.
Using web services centralises the actual authentication process, but the UI needed to support that lives on many different sites. In most cases you cannot change the process without changing the UI, and therefore you become blocked as you don't control that UI. All the other sites need to change to support that new process; which is going to raise a huge number of non technical issues. Additionally from a cost point of view, you are replicating the development, test and support burden across multiple sites, meaning a minor change has a cost being multiplied many times.
Using federation, the citizen is passed completely to the Identity Provider and is in their hands. If they want to add certificate support or biometrics; non of the other sites have to be updated (note: I will mention this in the claims post, but it is good to include a claim about how secure the authentication was, as the site may require certificate for specific actions). You have effectively outsourced the authentication to a trusted third party, unlike web services where you outsource the processing but still own the user interface.
User Experience
The first question raised is normally around branding. Government departments have a brand, and they want to use it. Also, users don't like seeing the look and feel of a site change radically during login; it quite rightly worries them. But this can be resolved easily. By using a white-label site, Contoso City Council can provision the Identity provider with style sheets, logos etc and the authentication page can be branded accordingly.
So when a request is received by the identity provider, it knows where the request came from and can load the correct branding, therefore not disturbing the user experience. Remember, some of the biggest hurdles to implementing a system like this is political – don't underestimate the desire for politicians to protect their own brand.
Different data for different departments
Not only does each Government Site have their own branding, but also they often want their own data as well. Many countries do not have a common ‘Citizen ID number’, but different sites and systems use their own identifier. Again, that is fine, as the Identity Provider knows where I came from, and therefore knows what data to send back.
Using the UK departments as an example, HMRC (Her Majesties Revenue Collection) the Tax department want your UTR (Unique Tax References), whereas the Department of Work and Pensions want your NINO (National Insurance Number)
So with the different demands from different departments an identity provider can supply the information that is needed, and no additional data. The Department of Work and Pensions, or Contoso City Council will be told what they need to be told and we will not have additional data leak out.
Who are the Identity Providers?
There are many possible answers to this. In many countries there will either be a central or regional Online ID system run by the Government. However, this is not a cheap service or easy service to run – as many Governments discover. Is there merit in looking at commercial companies? Companies such as Equifax that supply credit checking facilities to businesses can also act as Identity providers. Even systems such as LiveID could act as an Identity Provider for services that do not require a high assurance. As long as the user interface is well designed, I don't think people have a particular problem in having a number of different identities and when to use the right one – just look in your wallet.
Alternatively, Contoso City web site could also have its own Identity Provider. Where adoption of central ID systems can be slow, many city and council web sites have implemented their own authentication. Without using Federation the authentication and authorisation logic is often deeply entwined in the site, this is where using a separate Identity Provider and Federation gives a far cleaner separation, even when used in a single environment. The advantage of this is that when the identity strategy or desire of the Government changes (and it will), there is a clean separation so that either additional Identity Providers could be trusted or other people could trust it.
Next we are going to look at some of the pro’s and con’s of the different authentication methods that are available.
Note: There was a comment on my last post about how federation can help with delegated scenarios; for example my wife or accountant acting on my behalf. I will address that in a separate post as it touches a number of different areas. If you have anything you want me to drill into, please leave a comment and I will try my best to accommodate.
Comments
Anonymous
May 10, 2009
So where were we…. eID for Governments Federation for Government Overview Identity Providers AuthenticationAnonymous
June 18, 2009
(note to self, don't start writing a series of posts unless you have them all ready to publish otherwise