All entries for Monday 11 April 2005

April 11, 2005

SSO v3: Federated identity

Follow-up to The new project: SSO v3 from Kieran's blog

In recent years a lot of people have implemented Single Sign On (SSO) systems that work within their company or institution. However, once you leave your institution and start using the services of some external provider you generally lose your identity and have to register and login again with a different username and password.

However, with federated identity, you can share your identity with trusted partners. The perfect example of this (and the main driver for doing this) is the Athens service. Traditionally users had a different username and password that they received when they registered with IT Services which they could then use with Athens. Unfortunately not everyone knows this and those that do can easily enough forget/lose that information.

In the not too distant future we will start federating identities with Athens. This will mean that users login once at Warwick with their usual username and password and will automatically be logged in over at Athens (via our shiny new Shibboleth/SAML based SSO system). This clearly has some big advantages.

  • One username and password to remember (less helpdesk calls to retrieve them!)
  • We control the authentication and the release of information about our users to our Athens.
  • Athens don't have as much user administration to do

Importantly, because this is an open standard that is being adopted by lots of people it won't just be Athens that we can federate with.

Another example is in purchasing. We may well want it so that any staff member can order a hire car from a rental agency we have a partnership with. Instead of having to register everyone and maintain those registrations and all the user info, we set up a federated relationship whereby users login locally and we just tell the rental agency to let this user in because we vouch for who they are.

Once you get into the territory of having our users federated with lots of partners, two more advantages crops up.

  • In a single user creation action, allow a new user to login to many external systems without having to register them on each one
  • When a user leaves Warwick, we just disable their local login and immediately they can't login to any partner sites (no more worrying about tracking down and disabling all external accounts)

Whilst setting us up to be able to federate our users out to other partners, we are also setting it up so that our own services can accept users from other institutions who may want to federate their users. In theory each of our services could accept users from Birmingham University for instance, allowing for very simple cross institutional projects. Examples:

  • Setup a SiteBuilder site that allows external users to edit/read it
  • Create an learning resource that allows users from any federated University login and use it
  • Allow other Universities students to login and comment on blogs

You can of course do this now, but you'd have to register users locally and manage these users, once you federate identity, this isn't your problem. As long as you have a trusted relationship with your partners, you can just leave the user management up to them.

April 2005

Mo Tu We Th Fr Sa Su
Mar |  Today  | May
            1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30   


Search this blog

Most recent comments

  • One thing that was glossed over is that if you use Spring, there is a filter you can put in your XML… by Mathew Mannion on this entry
  • You are my hero. by Mathew Mannion on this entry
  • And may all your chickens come home to roost – in a nice fluffy organic, non–supermarket farmed kind… by Julie Moreton on this entry
  • Good luck I hope that you enjoy the new job! by on this entry
  • Good luck Kieran. :) by on this entry


Not signed in
Sign in

Powered by BlogBuilder