single-sign-on-writeup Latest text of pad single-sign-on-writeup Saved Feb 11, 2012 |
 |
|
|
 |
N
The below content is kept for historical reference only:
Schools' hidden & broken barriers
Author: John McLear of Primary Technology LtMawson, Mark Fisher
Date of creation and placement into public domain: 15/10/2011
Date of publication: TBC
Historical revisions: http://john.primarypad.com/ep/pad/view/single-sign-on-writeup/latest
Research partners: Primary Technology Ltd
Personalised learning needs smooth transition between various services offering learning content and activities. Continual password prompts are a barrier to this style of learning, putting off many schools. Single Sign On (SSO) should be one of the underlying technologies that removes this barrier, yet it is failing to live up to its promise and the hard work many people have put into it. This endangers the whole thrust of personalisation mediated by tech.
Schools have a want and need to try to personalise students learning. Since 2006 many schools, districts and local authorities have tried to accomplish this by accessing web based learning resources using a Single Sign On system called Shibboleth to avoid typing multiple passwords. This system isn't achieving its goals, in this article I will try to explain why and how we can go about making SSO a more natural experience for schools. If I saw this article I would've given up reading by now, thinking "Meh, it's someone else's problem", but really it isn't. Single Sign On affects everyone; it requires input all the way from the classroom teacher to the Service provider. It should, in theory, become more of an important part of our engagement with technology, so I believe understanding this technology should be essential to the technologically engaged educator. Don't worry though, by understanding I don't mean understanding the inner working from a technical perspective, I mean understanding who is involved in each process and how this impacts on learning.
Why write this report?
Primary Technology comissioned me to write a "State of the Shibboleth" report and I decided to write it publicly using PrimaryPad, this meant anyone was welcome to contribute to the report in real time and also see how the document evolved prior to publishing. I have requested contributions to the report publicly via Twitter and haven't restricted input. Each author is listed in the author section. Various other people have helped proof read. If you want to see how this document has evolved you can do so with this link :: http://john.primarypad.com/ep/pad/view/single-sign-on-writeup/latest
What is Single Sign On?
Single Sign On (SSO) is the process of accessing multiple web sites without the requirement to login over and over again. An example of this is when you visit Google.com and sign in you can also be logged in at Google Mail and Calendar. Shibboleth's SSO capabilities are way more verbose than the commonly used oAuth and this is where the problem comes in.
(I'm not going to mention SAML in this post. If you want to quickly throw the SAML spanner in and say Shibboleth is a type of SAML, I am fully aware of that - I just don't want to confuse my readers.)
How do I know Single Sign On isn't achieving it's goals?
Companies such as Primary Technology that develop web based applications talk to their competitors, schools and local authorities. Over the course of the last 6 months one of my key roles has been to discuss with the stakeholders that are part of the single sign on process. On top of that we have been sharing statistics (mostly in the form of Web Analytics) that show a lack of uptake which could have a large impact on teaching and learning due to a lack of Single Sign On usage. Unfortunately, I can't share any of the statistics I have gathered, mostly because Local Authorities find it extremely difficult to sign-off release forms on information and even if I tried to anonymize the data it may still be clear which Local Authorities have participated in the study.
If Shibboleth is a problem why do we use it?
The advantage of Shibboleth in this situation is that Shibboleth can pass an unlimited number of attributes about a person - an attribute could be something like their class name, their teacher name etc. This information can be passed from an Identity provider (IDP) to a Service Provider (SP). Think of an Identity provider as a local authority and think of a service provider as a web-based service like PrimaryPad. When a user goes to login to PrimaryPad, they can login using their Local authority credentials, that way PrimaryPad knows who the user is and which school or local authority they belong to. The benefit of this method is that PrimaryPad can direct a user's learning to the appropriate content ie the correct pad that their teacher has assigned to the pupil's entire class.
Shibboleth does suffer from a single point of failure as far as the WAYF is concerned: if the Federation Metadata at JISC becomes corrupt then learning can be interrupted but in my four years or so experience with Shibboleth, this hasn't become the case.
Shibboleth is still the right mechanism and choice for local authorities and schools to adopt. If we think of Single Sign On as a chain of steps, Shibboleth is far from the weakest link but probably the most technically complex of them all. Shibboleth's international community is also pretty disparate and vague. The UK Federation are part of this community and whilst their support is very good, the Shibboleth community as a whole doesn't have a great method for debugging problems. I know of a lot of Service Providers who have looked at deploying Shibboleth and have given up due to the confusing technical complexity of Shibboleth's design.
Isolating the hidden barriers
Now I have covered shibboleth as a software package and explained the core elements of Single Sign On inside of schools I want to introduce you to the other responsible parties and what their roles are.
- Classroom Teacher: Provide the School Administrator with Class data
- School Administrator: Input the Class data in to the school MIS
- School MIS: Store the Data accurately and in an easy to understand and reachable format.
- User account Middleware: Transfer the data from the school MIS to a Local Authority Store
- Local Authority: Usually manage a helpdesk service that is used to communicate between school and their managed service provider.
- Managed Service provider: An internet technology company usually manages the User account Middleware, authentication store and IDP.
- Authentication store: Usually something like LDAP that is used to authenticate against and hold attributes.
- Shibboleth IDP: Software that handles the authentication communication between the service provider and the Authentication store
- Shibboleth SP: Software that provides the authentication for the web service
- The Web service: Provides the learning content.
Now at this point I bet you're thinking "Wow that is a lot of points of failure" and you would be completely correct in your assertion. This is a huge part of the problem. Throughout the early stages of the process, a school's technical support provider is also responsible, so you can have up to 10 individuals managing the Single Sign On process. The above list only shows the people responsible for creating Single Sign on accounts - once created, account details need to be communicated back to the school and this often means we have to complete most of the steps at least twice. The same process is encountered during user updates, but the communication flow tends to be one way, without the requirement to communicate back to the ICT co-ordinator.
How big can a failure be?
Some schools log in to their network with the same credentials as their single sign on. When a new member of staff joins a school, they may have to wait for the "chain" to complete before being given a username and password. I have heard of cases where a teacher has had to wait weeks to log in to a school network. This can mean they don't have access to the school's policies, software, or access to teach using expensive resources that schools provide, such as an IWB. This is when Single Sign On really falls down.
Who fails the most?
I have worked with all levels of the chain and spoken to various people trying to clear up what's happened and why the process has failed. Each time a different point in the chain has failed and, as there is absolutely no resiliency in the chain, the service has failed to deliver the content to the teacher's class. An example of this is where the School Administrator is 100% certain they have typed the correct data into the school MIS but the MIS has not stored the data successfully. Isolating the error here would be extremely difficult due to the complex nature of school MIS systems. I have seen other instances where entire MIS data has stopped being imported into the Middleware for a number of months, and as no active monitoring was in place to check data integrity, it went unnoticed, ultimately breaking the chain.
The inconsistent password problem
Shibboleth IDPs are the point where authentication is completed. That's fine, however a lot of SPs allow the user to change the password on the web service - causing a mis-match between the passwords held by the SP and the IDP. Also, it's worth stating that having the same username and password on multiple websites is not "Single Sign On" - due to each service holding it's own set of password data, rather than referring to the central IDP.
The emerging technologies problem
Emerging technologies, by default, aren't built with Single Sign On in mind. For example most of the exciting really-real time web applications being built at present are built on a platform called NodeJS. NodeJS doesn't have Shibboleth support so the overheads of writing such support would be huge and often counterproductive from an organizational point of view. Shibboleth is also more costly than integrating oAuth solutions and often does less to reduce barriers to adopting single sign on as the greater part of the world population is not currently in full time education.
What the failures have meant in real terms?
A lot of secondary schools and colleges use the excuse of failing single sign on to invest more in hosting their own web based services. These provide some huge problems such as scaling issues, support, licensing and the distrubition and fragmentation of skills. Subsequently this means schools will have larger internal technical support teams solving the same problem over and over again with no real innovation - ultimately starving the UK economy of highly skilled people in niche areas.
What can we all do to help solve the issues?
As is often the case with ill-performing systems all of the stake holders [stakeholders] have a part to play to improve the system. I am aware that making the following suggestions sounds slightly preachy - and most of the time this type of request isn't actually taken on board - so with that in mind I am hoping that Gov/Local Authorities read this and are able to apply some sort of incentive to the relevant parties to promote each activity.
- Teachers should perform regular checks of the integrity of their pupil data in their school MIS.
- Teachers should contact any web site they or their pupils log into regularly and ask them if they have support for Shibboleth.
- Teachers should provide Web service providers with feature requests and report any problems or bugs and web service providers should provide easy, clearly sign-posted means to do so.
- Schools should put pressure on their school MIS provider to supply teachers with the ability to easily check this data, this experience should be natural and their should be more incentives in place to encourage teachers to be pro-active about this.
- Service providers need to provide more of an incentive to schools to provide single sign on. Service Providers can do this by requesting as much information as possible from the Identity Providers and making this information part of the learning process. The more information provided to a Service Provider about a learner will provide a more personalized learning experience.
- Service Providers need to ensure the inconsistent password issue is resolved by ensuring the user is forwarded to the IDPs password reset tool.
- Local Authorities should be actively promoting services that provide Single Sign On and clearly explaining the advantages for personalized learning.
- Identify providers, the UK Federation and Service providers should create a draft standard for passing data between schools. Currently the UK Fed does a great job of some attributes but there is no standard described for timetabling and other more complex functions.
- Identity providers should consider releasing some of their middleware open source. Currently this market is in terrible shape with a lack of well documented products being held by a few companies.
- The Shibboleth community could provide an easier way to deploy Shibboleth, both at IDP and SP level. The UK federation data could also be truncated somewhat as it is becoming a bit of a behemoth. It may be that the UK federation decide to release subsets of metadata for each different organization level, ie a subset for Primary and a seperate subset for secondary however this poses problems of transition through to secondary schools and could possibly lead to a more fragmented learning experience.
The Golden bullet
This will never exist, but in a dream world we would be able to automate the pupil management process and merge the school MIS, Middleware, Authentication storage and IDP into one managed service. The problem here is that Serco and Capita are already under investigation for anti-competitive practices and the general respect and trust amongst educators is at an all time low. It would cost an absolute fortune for a software company to develop an MIS that had all of the features I am proposing, especially as I envisage that this software is built to open standards and provided as an open source venture. It's this exact problem that creates the greatest predicament - it would take a large amount of government funding to solve it and it is highly unlikely the government would fund an incentive that would compete with two of the governments largest backers.
Summary
We are in a dangorous place with Single Sign On. The worst case scenario is that we trust a large international third party organization such as Twitter or Facebook with our user accounts. Such an organization won't be able to pass the right types of attributes and subsequently won't be able to provide a truly personalized learning experience. Currently, under-13s are unable to register for the majority of social networks however this market space is becomming more competitive and various social networks for children have taken a foothold. I want to issue a very important warning here. Google, Facebook, Twitter etc. will not be around forever - no company lasts - we shouldn't use any closed systems for our authentication model. This road is very dangerous and should be avoided at all costs.
If Single Sign On was on the Gartner hype cycle it's probable we are in the Trough of Disillusionment. That's not a bad thing; if anything, it's a perfect time to become aware of Single Sign On and how your institution can adopt it.
Single Sign On is boring, really boring - people just expect it to work and rightly so. Very few people will actually read this whole article despite the fact that personalized online learning should be a huge part of the UK's success in learning in the future. There is also very little financial incentive for either Service providers or Identity providers to push this technology. Schools that have experienced single sign on through Local Authorities are used to a service that rarely works, and even Local Authorities have become frustrated with their managed service providers who are contracted to manage Single Sign On and have not renewed their contracts. :: http://www.iii.co.uk/investment/detail?code
Ultimately Single Sign On needs to be simpler than managing user accounts via a CSV upload and providing pupils with generic passwords. At current, this isn't the case.
Before signing out on this article I want to state that a lot of good people have put a lot of great work into Single Sign On and despite the critical nature of what I have written I do believe that the future of Single Sign On is bright - assuming we can reduce the complexity and promote the positive aspects.
I can't stress how important the links between Single Sign On and personalized learning really are. I think this often gets overlooked when we think about Single Sign On as just a way of reducing sign on complexity. The feedback loop between Teachers and Web Service providers is probably the most important issue here.
Authors notes:
Scope of the report
This report covers Primary Schools use of the Single Sign on mechanism (Shibboleth) and all parties involved in this process.
