Wednesday 24 August 2011

SSO, social and institutional identities

I've periodically ruminated on the future of university information services and how if everything is outsourced, all we are left with is access mediation, ie providing institutional logins that allow access to institutional resources, federated institutional resources such as a research cloud, and external resources such as Jstor, for which you gain access because your home institution has paid a subscription to provide access to the resource.

Now if everything was happily outsourced via the institution, say Google Apps, or Live for Edu, we would have something quite nice and tidy. The id you use would still be tied to the institution and therefore you can have institution level access.

But in fact we see that people are starting to blend resources accessed through their social identities with their institutional work. Essentially self outsourcing.

And of course there is no reason why they shouldn't - or example if someone finds Windows Live and One Note ideal for managing research notes why shouldn't they, especially as they can access it from almost everywhere and from a range of platforms.

Your social identity is your google id, twitter id, Live login etc etc, and as increasingly there are lot of services that invite you to login with your google id or twitter id people start doing exactly that, rather than creating yet another id and password.

The UX lesson is that people don't like having multiple id's and passwords. The other lesson is that Google and Twitter are winning the account federation war.

The trouble is that anyone can have a social id - even my cat has a blog and a twitter account and consequently social id's are reputation free.

This of course doesn't matter in 99% of cases. It doesn't even matter when creating a virtual organisation, say an online collaboration, until we get to the problem of access to resources.

Now as people self outsource, this will be a growing problem - the Internet 2 wiki has some real world use cases and I'm sure you can add your own without too much thought.

The solution is probably a gateway of some type where people self declare their preferred social id's and link them to their institutional id's - this is not so different as what happens with a reverse proxy service, where for example, if you want to work from home and access a resource that allows access on the basis of ip address, you log into an institutional reverse proxy service, in my case virtual.anu.edu.au with your institutional credentials to gain access to the resource.

The logic is quite instructive:
  • you log in with your uni-id to prove you belong to the university
  • the service provides you with a connection as if you have a campus id address
You could then imagine this enhanced scenario:
  • you are logged into google and you google credentials are cached locally
  • you connect to the proxy server.
  • The proxy server inspects your machine and notices your google credentials are set. It looks up your gmail address and sees you have previously linked that to you institutional id
  • it asks you to type your institutional password to confirm it's really you
  • just as in CAS it creates an obfuscated token it passes to all services that request it to allow access to institutional resources including federated resources
And, given the Jasig/CAS Sakai tie up, allows you access to a collaboration platform which allows you to share resources with you colleagues in a collaboration or virtual organisation. providing they all have an electronic institutional affiliation

No comments: