Glow Authentication and Shibboleth persistentID

In my previous post, my crystal ball suggested that RM would be awarded the 25 month contract for the authentication and portal for the interim Glow/SSDN solution.  As announced on Friday 23rd August, RM were awarded the contract. This means there will be a period of stability based on the same portal that users have available at the moment, RM Unify.

The authentication part of the service will change however and I’m curious about how RM will cope with the issue of changes to a user’s persistentID and any resulting loss of linked services. What do I mean?

Glow uses Shibboleth 2 as the secure protocol for authentication. This protocol uses digital certificates and encrypted/signed messages to prove that a user is who he/she claims to be. When you log into a service that uses Glow’s authentication, the service sends you to Glow to sign in.  With your request it also sends some information about where to come back to once you have signed in.

You enter your username and password in Glow and the Glow system sends you back to the service you first came from. Encoded in the URL that returns you to your service are signed tokens which confirm that you are a Glow user AND attributes (information) about you. By default, Glow provides two attributes, a scopedID and a persistentID.  The scopedID says you are a teacher or student etc and at which establishment but the persistentID is your unique identifier. Every time you login to any service it is the same persistentID that is used by the system.

Many of the current Glow services use this persistentID to link you with your data. And third party services, often created or procured by local authorities also use this persistentID. Right now local authority procured services: SEEMiS, EducationCity, honeycomb, the very popular PurpleMash and others all make use of Glow’s shibboleth sign-on as do NAR, SCRAN and Education Scotland Services and even RM Unify (check the shibboleth based services via the Glow Usage Wiki).

Now it get’s interesting. Any change to the identity provider (the server you sign on at) will result in a change to the persistentID.

This change to the persistentID may break the link between a unique user and his/her data in these services. There isn’t any way round this, it’s a part of the Shibboleth protocols and it is used to ensure that sign-on servers can’t be spoofed by others.

I know that some services have negotiated to receive more than the basic set of attributes from Glow.  Some of these services may use other attributes, instead of the persistentID, to create the link to user data.  For example Aberdeenshire’s HoneyComb eportfolio service uses the “guid” (globally unique identifier)  from the ActiveDirectory that stores all the user details for Glow so it should be ok as long as RM migrate the ActiveDirectory in a particular way to their new authentication system.

Services that use the persistentID but receive other attributes as well may be able to put a fix in place but services that just use the persistentID could be in trouble.

Changes to authentication will have consequences for third party services. These services will have to point their “Glow Login” to the new authentication service, will have to update their metadata (the digital information used to store details of the Glow service) and may have to (re)negotiate the release of user data (attributes) with RM/Education Scotland and Local Authorities.

In Glew, it will be no big deal.  A user will have to sign-in again to Glew, then choose to link his/her Glow account.  This will take him/her to the new RM authentication, they sign-in and are returned to Glew where we store their new persistentID with their Glew account.  This means, in future, we can enable a sign-in to Glew using just your Glow account 🙂

I really hope the migration to RM based authentication does provide useful, user focused, additions (such as the ability to link your Glow Account to other accounts such as Google, Facebook, Twitter and the ability to customise your portal at the user level) then that will be a step forward. It would be great if the RM product also supported sharing tile layouts for different tasks/subject groups (either by email, IM or URL).  RM Unify has improved over the last 9 months and the ability to create your own tiles (as a teacher) is a plus.  I do pop into the RM Unify Trello page every now and again to see what they are working on. 🙂

*any opinion expressed in this post does not represent the view of any employers or groups I am associated with.