All entries for 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 06, 2005

SSO v3: Scalability and manageability

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

One of the primary reasons for wanting to create a new Single Sign On (SSO) system is so that we can work better with the much wider range of users and services that want to use SSO.

Some stats:
Servers and developer boxes registered to work with SSO: 64
Logins per day: 9,500
User login checks from services per day: 20,000 (implying each user uses 2 different services per day on average)
Warwick users: 20,000

So, around half of all users login each day to some SSO controlled service. Obviously for a lot of services you can use them without logging in, but you must login to do certain tasks. A lot of users reading pages in SiteBuilder, Blogs and Forums are not logged in (but will login to edit/comment/post).

To manage these numbers more effectively, we needed a more powerful and better compartmentalised system.

Our starting point was the Shibboleth Origin software from Athens. The team at Athens provide a Java based Shibboleth Origin that can be easily integrated into our systems (also Java). From this starting point, we've got up to speed relatively easily with the Shibboleth protocol.

One of the nicest features of the software is the security which uses mutual SSL authentication for more or less everywhere and signed SAML (XML) as the way of getting data securely around.

My other favourite feature is the ability to define which attributes of a user get sent to different client services. So if we only wanted to tell Athens your first name but not your email or full name, we could do so with a simple bit of configuration. But for our internal systems, we could easily configure it to send a lot more detailed and trusted information, thus providing a more secure and private and virtually anonymous way of authenticating to partner services. As long as the partner service trusts Warwick to vouch for someones identity, they will let that user in without knowing their real identity.

The new project: SSO v3

At Warwick we have had a web Single Sign On (SSO) system for a few years now. Not knowing our long term plans, we developed a simple but performant system that served at the time just a couple of applications we had on the web (SiteBuilder our CMS and our forums system).

Times have changed.

There are now the best part of 20 systems using our existing SSO system, everything from blogs to timetabling, printer credits to accommodation bookings. It works well and is easy to integrate with, but we are ready to move to the next level.

Why is it time to move on?

  1. Scalability and management of more client services and users
  2. Ability to federate identity to and from external partners
  3. Improve security

I've been working on this now for the last couple of months and it is almost ready. It should not affect most people except that you'll be presented with a different login screen which will most likely be a full screen rather than a popup.

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