Federation for Government Overview

  • Article

(Following on from the previous post - eID for Governments)

So why federation?  I want to explore how federation works and why I think it is so well suited to Governments.  I have written these posts so they are not too technical as there is more than enough technical detail out there.  This is how I try and explain the advantages of federation to business people; rather than how it works for more technical people.

So lets walk through a basic federation scenario, as we can use this to explain things as we go.  For this scenario we are going to try and access City Council service that requires me to be authenticated – looking at my tax payments for example.  So I as a citizen open a browser go to my city portal homepage – all good so far.  I click on the ‘login’ button, and at this point I am going to be redirected off to be authenticated.

Identity Providers

So this is the first thing to understand about federation.  We split the web site that is going to provide your identity (the Identity Provider), and the web site you are trying to access.

Federation1

This gives us a huge amount of flexibility as we can have multiple Identity Provides if we want.  We can change them, or add more as we go along. In this scenario Contoso City Council could provide its own identity provider, and there could be a Central Government Identity Provider as well.  If we have more than one, we need a bit of user interaction that asks the user which Identity Provider they want to use.  In this example lets assume I only have one Identity Provider so I can be redirected without any additional questions.

When I get passed over to the Identity Provider some information is sent with me.  It basically informs the Identity Provider where I came from, what I want to do, and where I want to go back too.

This means that when I arrive at the Identity Provider it knows I came from the Contoso City Web site, that I want to log in, and I need to go back to the Tax Payments part of the site.

Authentication

So the Identity Provider now needs to authenticate me. this could be via UserID and Password, Certificate, biometric it does not matter.  Once the Identity Provider has authenticated me, it needs to send me back to the web site.

Claims and Tokens

The Identity Provider has to send back some proof that I have been authenticated.  The way it does that is by sending back a digitally signed SAML token.  This is a token that has a bunch of claims; for example.

  • Name=James Brown
  • CitizenID=123456789
  • DateOfBirth=1970/01/01

This is not a new concept.  My passport is a token, signed by the UK Government (so people know it is not forged) and asserts my name, date of birth, passport number etc.  We have been using claims and tokens in the physical world for a long long time.

Authorisation

Once the Contoso City Web site has got the token it looks at the claims to see if I am authorised to access the Tax Payments page.  Note it is the City Web site that is doing this, the Identity Provider does not care, its job is Authentication.  It is the job of the Contoso City web site to authorise if I am allows to see something.

Again this is not unlike my passport.  The UK Government issues me with a passport, it is the job of whatever country I am trying to access to decide if I am allowed in.

 

Federation2

So over the next few posts I am going to start to look into the following elements in more detail:

  • Identity Providers – Why use a separate Identity Provider
  • Authentication – What are the different ways we can authenticate people
  • Claims and Tokens – Why are using Claims so powerful
  • Authorisation – How do sites integrate federation
  • Federation – This is glue that holds all of the above together

So why do I like federation, why do I think it will work well in Government?  We will explore that as we go, but basically it is breaking a really hard problem into different bits, giving the different bits to different parties then giving a Standards based way of gluing them together.

Government IT is hugely complex, run by 100’s (if not 1000’s) of different organisations.  The only way we can get identity to work across this, is break the problem apart so all the different entities are not trying to solve the same problem. And we need to do that in a way that is simple, and supported by multiple vendors

PS.  To the technical people who are reading this….  I know I have missed out lots of stuff like digital signatures, realms etc, but lets not make it too confusing.  I will try and bring in these concepts as we dig a bit deeper.