« Snatching success from the jaws of failure | Main | Cory Doctorow on open licences »

July 03, 2008

Catch you on the flip side later - improving the federated user experience

My colleague, David Orrell, gave a presentation to the JISC Federated Access: Future Directions day in Birmingham earlier this week.  Here are his slides:

David's presentation covered the user experience of both federated and user-centric approaches to identity management (i.e. the UK Access Management Federation and OpenID), the associated trust issues, and the potential impact that Information Cards might have on this space.

This blog entry focuses primarily on the first of these - the potential lack of consistency of the user experience in federated identity management environments such as that offered by the UK Access Management Federation.  There are two aspects to this: firstly the different experiences that different users see of the same service (by virtue of the fact that the authentication part of that experience is offered by their home institution rather than by the service itself) and secondly the different experiences that the same user sees of different services within the federation.

By way of example, let's consider two users, Janet and John (each from different universities, let's say Bath and Bristol) and two services, Service A and Service B.

When Janet and John access Service A they will each have a slightly different experience because the authentication part of the process will be provided by Bath in one case and Bristol in the other.  That makes it difficult for Service A to completely document its interface because at some point it will have to resort to saying something like: "you will then be re-directed to your institutional login page, we'll catch you on the flip side once you've been authenticated".

Conversely, when Janet (or John) accesses Service A followed by Service B she (or he) will have a different user experience of each in terms of how she (or he) is authenticated because the two services will probably present the login form differently and at a different place on the page, one may point to the federation WAYF service while the other embeds a pull-down list of universities, they may use different language to describe what is happening, and so on.

Ukamfexamples_2 Don't believe me?  Just look down the list of UK Access Management Federation services and try it for yourself.  David has put some images of the way in which different services in the UK Federation present the login process to their users on slide 26 of his presentation but it is a little hard to read in the Slideshare version (above) so I'm embedding a bigger version here (click on the image to see it full size).

Look at the differing forms of language being used - "Shibboleth" vs. "UK Federation" vs. "institutional" vs. "organisational" login.  Look at the differing ways of selecting the user's home institution - "search" vs. "pull-down list" vs. "multiple pull-down lists" vs. ...

The point here is not to suggest that any one of these approaches is better or worse than the others (though I happen to think that putting form boxes labelled "User Name" and "Password" next to text saying "Athens/Other Institution Login" when in fact the username/password pair being requested is the service-specific (i.e. non-federated) one, as one service has done, doesn't exactly represent best-practice and is presumably resulting in large numbers of institutional username/password pairs being seen by the service in question!).  Rather, the point is that there is currently a very wide range of practice out there across UK Federation service providers (including that adopted by Eduserv in our own services), ultimately leading to confusion for the end-user.

Now... inconsistency of experience isn't bad just because it confuses people - though of course that is a very real problem.  Inconsistency also represents an opportunity for phishing to take place because users have less of a handle on what step comes next in the authentication process.  We probably haven't seen any phishing taking place in the context of the UK Federation to date, and maybe the controlled nature of the environment means that we won't.  But it is certainly something to beware of - and certainly something that has troubled the rather more open environment within which OpenID has to operate.

Lack of consistency also represents a significant (and in the case of the UK Federation probably insurmountable) hurdle to overcome for browser-based plug-ins that might otherwise help smooth the federated authentication process.

Consider a tool like Sxipper, a Firefox plug-in that manages your usernames and passwords for you (including your OpenIDs) and that can recognise when and where to present them to services as part of their Web registration and/or login pages.  Sxipper works because, despite some superficial differences across services, most logins revolve around two text boxes and a submit button (though actually, Sxipper can deal with much more than this).  Furthermore, in the case of OpenID at least, there are well-adopted conventions for how these XHTML form items should be named.  Heck... in most cases, even in the absence of a tool like Sxipper, the browser will do a pretty good job of remembering what needs to go where.

Contrast this with services in the UK Federation.  The lack of consistency in the way information is presented and requested and the widespread use of drop-down lists to navigate to the user's home institution means that browsers and plug-ins like Sxipper stand very little (probably zero) chance of helping to smooth the process.

We can and should do better.  In the short term I think we need the help of some usability designers to streamline the UK Federation user experience and to issue guidelines for service providers so that a more coherent and consistent experience is offered overall.  And in the longer term... well, readers of this blog will know that I have views on institutional vs. user-centric approaches to identity management.  But setting those views to one side for the moment, I suspect we are still not mainstream enough in our approaches to access and identity management.  For example, can anyone point to a single mainstream Web 2.0 service that has adopted Shibboleth?  The move from Athens to Shibboleth has been a step in the right direction for the UK education community (at least in my opinion) since it represents a move to open standards. But does it go far enough? Shibboleth still feels like a community-specific solution to me. Whilst I accept that the community is now significantly bigger than was the case with Athens and that the solution is based on open standards I think we will only see real community benefits (in terms of the widespread adoption and development of tools and services) if we become part of a much bigger community - a truly global community.

I think it will be interesting to see what comes of the information card work, and in particular whether the ability to embed our identity management toolkits more firmly into the desktop improves the user experience whilst stengthening security and thus improving trust models.  I certainly hope so...


TrackBack URL for this entry:

Listed below are links to weblogs that reference Catch you on the flip side later - improving the federated user experience:


Hi Andy

Couldn't agree with you more, we need to move to the next stage of Service Providers adopting federated access. Whilst the focus in the UK is on library-type resources we aren't going to see much movement on this.

I think the next steps will be institutions looking at what they can do with federated access internally. There has been good progress with VLEs with most of the major players offering federated modules. Moodle really is a killer ap in the UK FE sector. Blogs and Wikis are the next in line and we are busy at JISC federating our blog system (a wordpress implementation) and our wiki system (confluence). We are seeing many of the early adopters of shibboleth doing the same thing.

The wider picture? Well our friends in the States have been better at this than us. iTunesU is fully federated, Microsoft are offering Dreamspark services, and then there is the very interesting University Tickets service. Feide have also introduced Foodle (a federated Doodle, not a federated Moodle! It gets complicated).

So now we just have to think what we can offer to this space. I'm interested in ideas :-)

I note that the JISC have just issued some initial guidance in the area of terminology, which seems to make sense:

Login terminology

We do not recommend using the term 'Shibboleth' or 'Federation' because users will not know what these mean. We recommend retaining the term 'Athens', at least in the short-term, because this is what current users of Athens will be used to.

For publishers which have both Athens and federated access management users:

'Login via Athens or your home organisation' or 'Login via Athens or your home institution'

For publishers which only have federated access management users:

'Login via your home organisation' or 'Login via your home institution'

See http://www.jisc.ac.uk/whatwedo/themes/access_management/federation/publisherlogin.aspx

Good stuff...

One of the things about Shibboleth that has long puzzled me is why the WAYF (Where Are You From) service is considered out of scope for a Shibboleth federation implementation. It would seem that one of the key functions that a Shibboleth Federation should supply is the bridge between SP (Service Provider) and IdP (Identity Provider). Your highlight of David Orrell's presentation shows exactly the reason why.

This is how I think it should work. An SP can be a part of one or more federations and the user selects their federation at the SP either by name or by graphic identity. The SP then redirects to the federation-supplied WAYF for the user to select the IdP organization. The federation WAYF then redirects to the appropriate organization's IdP.

In this manner, the responsibilities are clearly delineated. We can substitute "Country" for "Federation" above in the case where there is only one federation per country. But the user's selection of their home organization should happen at that level, not at the SP level.

The comments to this entry are closed.



eFoundations is powered by TypePad