JISC and Bob ‘RL’ Morgan initiated a discussion on IdP discovery usability that inspired me to try to summarize my thoughts on the topic.
What is bad today? – Examples from real life
UK Access Federation
In a UK federated service, you would need to know that you must click Shibboleth login (notice: a name of some piece of software), in order to get to a discovery service. A SP-specific IdP Discovery Service today in UK Access Federation will present you with a drop-down box of approximately 750 entries listing universities. It takes quite some time for a browser to scroll to the bottom. When the user goes to the next SP, he/she is blessed with the wonderful SSO experience with simple login, but before that happens, the user is presented with the same question and 750-entries-long drop-down list.
Question or answer?
When a danish user goes to a Kalmar Union service, and is presented with a IdP Discovery Service service asking something along Where are you from?. The correct answer to that to a danish student would be WAYF – Where are you from.
Example shows that there should be (but not always is) a co-ordination between the question asked and the answer you give.
OpenID flawed design
SAML SP Usability with optional anonymous access
If you are logged in to service A, and click to service B, you are supposed to experience Single Sign-On. If service B also supports non-authenticated access, you will not experience SSO. Instead you have to click Login, and then select your Identity Provider in example on a UK Wayf. Then, you are automatically logged in without entering username and password.
Logout: Logout usability deserves a separate document with bad usability examples.
Hub & spoke
Several federations use centralized IdPs, or bridges, sometimes referred to as Hub & Spoke model. Countries with such federations includes; Norway, Denmark, Netherlands, Spain and more… When such federations interconnect, it is more or less impossible to create a one-page discovery service. Multi-step discovery services, in it’s worst scenarios, includes even more than two steps for selecting where you are from.
What will be bad in the future
Because everybody would like to be Identity Providers, it will not only be a matter of where are you from?, but also a matter of which of these companies, where you have account on all of them, did you use to login at the time when you registered. If you login with another Identity Provider, you will have a new empty profile at this service… The natural solution that we will see popup everywhere is account linking. Account linking is a usability mess.
SAML will not be the only authentication protocol. There will be other protocols that you would like to use… We will start seeing discovery services that asks what protocol do you want to use to login: choose between eduID or OpenID. Then after you select eduID you choose which SAML identity provider. Obviously this has nothing to do with user-friendliness.
I cannot wait to see the first UK university to tag metadata like this:
<OrganizationName xml:lang="en">_York St John University</OrganizationName>
What we have done with this mess
Some random bits from our work latest months around the topic Usability. More or less all the ideas sketched below is implemented and available as part of the simpleSAMLphp software.
Real Usability Testing
We hired a company NetlifeResearch to do usability testing of our new production IdP, with real users. Very interesting exercise.
SAML SP Usability with optional anonymous access
When you arrive at a service, the service should automatically discover whether or not you are authenticated at an IdP with SSO enabled. If you are not logged in, you should stay anonymous and optionally select login. We’ve described how to achieve the correct user behaviour with SAML 2.0:
Improved UI on Discovery Service
In SimpleSAMLphp we have a SAML IdP Discovery Service, where we have experimented with several UI improvements.
First thing we did was to get rid of the nasty drop-down boxes, and expose a full nice looking list of choices that you can just click on to select.
Next thing we did was to find a way to reduce the list by using the most appropriate one-dimentional categorization. In some of the use-cases the most appropriate one-dimentional categories was by country. The example below is a bad example, as it is not country only, but also some other names (ignore those).
Then we introduced live incremental search. We are experimenting with a Quicksilver-like search method, where the letters you type does not need to be consecutive in the result word. It needs some polishing in the score calculation algoritm before we can consider it done (work in progress).
Discovery Service Memory Behaviour
We started an experiment with a couple of services; adding a preselect option Remember this choice, which caused the discovery service to be skipped for the next service. Worked very well for those 99% that selected the correct choice the first time. The hassle for the last 1% justified to crap this solution.
Of the different solutions I’ve tested until now; I think this is the best we could do:
First time, do a normal choose where you are from, with no option for remembering anything.
Subsequent times (forever), you will always have to pass through the discovery service, but on the top you will see a message like this:
Some discovery implementations have a Remember this choice for 14 days option. It think it sucks – why do you want to select one IdP after 13 days, and another after 15 days?
Cross-Discovery Service Memory
SP-specific discovery services are preferred because they can be styled, embedded and better integrated with the service. They have a usability issue because preferred IdP is not remembered across service providers, and users will have to select Identity Provider again and again…
We’ve proposed and implemented an extension to the IdP Discovery Protocol, that allows a SP Specific Discovery Service to write an IdP selection (with a passive set-request message) to a central common interface-less Identity Provider.
The implementations will cause SP-specific discovery services to share a preferred IdP, reading and writing selection to a central storage, using the IdP Discovery Service Protocol (with a small extension).
Hinted IdP Discovery
A Discovery Service should do all it can to prioritize the list of available options depending on available information about the user.
Hints that may be useful in discovery:
- IP-address to location. It is possible with impressive accuracy to estimate the position of an IP address using a database or lookup service with IP prefixes.
- IP-addresses to Universities. NRENs often maintain a database of network prefixes that are delegated to each institutions. If this database exist, it may be used.
- True geo-location, as supported by some browsers, including iPhone safari and more.
- Preferred language hints as presented by the user’s browser a.k.a
Accept-Language. Very useful in Europe – may be not so much in US and UK.
More information about instituions in metadata may make it easier to make good UIs. Example of such metadata includes:
Would be interesting if someone would collaborate to make an extension to SAML 2.0 metadata to include more meta information.
I wrote a document introducing an idea of using mail-address instead of URL in OpenID, putting it into educational context. The idea is pretty obvious and I believe several must have had the same idea earlier, but I have not seen it described anywhere.
I’m referring to the part: OpenID Extension: UserID Expansion.
Most of these are my thoughts on UI, and is not necessarily the generic view of my company, UNINETT.