web analytics

Single Sign-On – taking it to the desktop – or not? #EDUScotICT

A core service of the Glow Learning Platform is the Single Sign On (SSO) service.  Arguably, this is the absolute core of Glow and one of the services which in concept should always be preserved irrespective of the other services which constitute the complete platform.  When Glow was originally conceived this was taken by some to mean that once a pupil or teacher signed into the network, that they would not need to offer any further authorization credentials.  Sadly, it was not possible to achieve this level of SSO because every local authority at the time operated its own network access control system.   So the current position is that any school-based user must pass through two authentication gates before they can access the Glow Service.  This requires that every user needs to maintain two user names (UID) and password (PWD) combinations.

Time has passed and I wonder if the value of a true single sign -on solution is now generally appreciated where users can achieve access to all the resources both at a local and national level without the need to authenticate twice.  Seems to me that this could be set down as a requirement and revisited in the context of the next iteration of Glow.

I don’t intend to offer a technical solution here but I am prepared to raise a few issues need to be considered whilst working towards a true SSO solution for Glow users.

Who owns the User Identity?
As previously stated each user in the current setup will have at least two UIDs to access the school network and Glow.  Glow through its membership of the UK Access Management Federation (UKMAF) also extends SSO to a number of federated content providers including SCRAN and Scholar.

The users local network UID and PWD provide access to both the Local Area Network and the services which are associated with it.  These services could include file storage, printer services and applications which are stored locally.  Where the LA provides onward access to the internet this will be another service which is accessible through the network login.  As discussed in my previous article access to the internet may well be filtered according to the school or LA policy.

Once connected to the internet the user can then access any service which the filter permits – which will include Glow – this is based on a second UID and PWD of course.

The two UID/PWD combinations will in the worst case be completely separate.  In some cases a LA may have decided to follow advice given early in the Glow project to use the same UID for Glow as for the local network.  Further more users could manually synchronize both passwords making it easier for end users to gain access although they will still have to pass thought the UID/PWD gate for both the local network and Glow.

In the above scenario there are two identities and two identity owners which are the school (LA) and Glow.  As already stated, Glow is the identity owner for Federated access to third party content which prevents users needing to remember other UID/PWD combinations for third party federated services.

Could this be further simplified?
In short the answer is yes, and this can be achieved in a number of different ways.

One approach is to make even more use of the UKAMF by making Glow a Federated service and having each Local Authority become an Identity Provider (IdP) in the context of the Federation.  This would ultimately put some additional responsibility on the LA as they would need to maintain their Authorization service on a 24/7 basis and setup and maintain the Shibboleth IdP service.

Each time a user tries to access a UKAMF federated service, be it Glow, SCRAN or any other, the process of authentication will involve some interaction with the users home local authorities IdP service.  This of course applies when the user is either accessing via the school network or from some other location.

Because of that way that the Shibboleth system operates there is one further stage needed when the user is away from home – ie accessing from a location out with their LA network.

The Where Are You From service (WAYF)

The WAYF service is needed when a user is accessing a federated service when they are not connected to their LA network.  For this illustration we consider the LA network to be the primary network for our users and this is where the user UID/PWD are maintained.  Consequently, a user trying to access a federated service from their domestic/home network or from any other network, roaming public WiFi access points etc, will need to use the WAYF service to ascertain the organization which maintains their IdP service.

In reality this will be fairly straightforward as the user will be given a choice from the list of LAs participating in the scheme.

Users with a National ID?

The effect of this approach is that the school user could through the use of on UID/PWD combination have access to the School internal resources and also have access to third part resources which are federated using the UKAMF.

What if Glow was the IdP for local authority network access?

In this scenario all LAs would have to agree to using the national authentication service for permitting access to the local network.  Once a user has authenticated to Glow the user will be permitted access to the local network.  In this case each user connecting to the LA network would be presented with a prompt for UID/PWD which would be their Glow credentials.

So what are the issues?

As I stated at the start of this post it is not my intention to offer a solution to country wide SSO.

  • Trust is always an issue when dealing with controlling access to resources.
  • An organisation will generally trust its own authentication system – but may be reluctant to trust a third party system.
  • If LA is IdP – this is responsibility to provide 24/7 service which might not be desirable or possible – are LAs setup to provide 24/7 supported services?.
  • Having true SSO to the desktop is definitely desirable (my view!)
  • Is there a case for making a admission control to the network or applications a shared service so same approach it taken throughout UK
  • What are the educational benefits of making access easier for all users – certainly will take one barrier away – what value do we put on easier access?.
  • Once established – why not use the authorization service for other proposes/applications – no suggestions here but many mush exist!
  • What are the implications for FE and HE if they were also to make use of the Glow service package?