Shibboleth: Myths, Lies and the Truth

Jon Dowland facilitiated a workshop session entitled Shibboleth: Myths, Lies and the Truth at the Institutional Web Management Workshop 2005, which took place in Manchester on 7th July 2005.

The abstract for this session is available at http://www.ukoln.ac.uk/web-focus/events/workshops/webmaster-2005/sessions/dowland/.

Slides (licence):

There were 16 registered participants and roughly 18 attendants. The session followed the structure of the slides, with some deviations to make note of participant's specific situations.

At the beginning of the session, people were asked to shout out some preconceptions about what Shibboleth was. The following were recorded:

Particular points of note: Shibboleth is not a single sign-on solution per se, but builds on an existing single sign-on solution in order to provide the attributes and inter-institutional stuff.

Web-based is indeed correct - it is only of use for web-based services at present.

'Authentication' as a concept is different from 'Authorisation', a point laboured in the slides that followed.

Early on in the presentation, the audience was asked to describe some of the shortcomings of their existing authentication/authorisation management systems. The plan was to describe how Shibboleth might tackle each of these. Here follows those that were suggested, plus a few concocted in advance, alongside the discussion of how Shibboleth may improve the situation:

account burden + account expiry
Accounts will still need to be managed somewhere, but the problem is relegated to the home institution for the users, and not replicated to service providers.
`fringe' users
The core shib model relies on each user having a single `home' institution. This is not the case for shared students. Two possible approaches include nominating an arbitrary institution as their home; treating the user as two seperate users, who have access to each other's resources.
reluctant service providers
International service providers can be reluctant to work within the Athens framework in the UK as it is an irritation and UK-specific. If Shibboleth becomes the standard model for resource sharing, then it is an international thing, so SPs should not be reluctant.
number of passwords ; confusion
Each service provider does not need to maintain a seperate user-base. Therefore adoption of Shibboleth reduces the number of distinct password stores the user interacts with.
cost to resources; data
Difficult/impossible to answer generally.
protection / privacy; Fine-grained access control
More attributes = finer access control; fewer attributes = greater privacy. It was noted that you cannot sign away your right to data protection.
Usage statistics
Some institutions concerned about inflated / untrustworthy usage statistics via athens or Service Providers. Shibboleth allows local logging of which resources are in use, and can potentially be used to look at which types of users are accessing which resources, opening up the possibility of more limited subscriptions on tight budgets.
Bureaucracy and ad-hoc groups (VRGs)
Ad-hoc, short-lived and geographically dispirate groups of people (such as virtual research groups or VRGs) may find it difficult to share resources or establish e.g. mailing lists, a web site, due to the lack of a common institutional infrastructure. If each member of a VRG belonged to an institution with an Identity Provider, and under the proviso that these institutions trusted each other (e.g. were in the same Federation), then resources such as these could be put together with relative ease due to the trust barrier being overcome.

For technical reasons, a demonstration of Shibboleth in action was postponed until the end of the session. However, the slides contain a step-through description of the Shibboleth process.

Of particular note was the audience reaction to the WAYF's approach towards determining a home institution. The usability of this approach is questionable - the InQueue federation's list of institutions is a good example of why this doesn't scale.

It was agreed that this was an important problem to be overcome. It was speculated that this was not a priority for the core Shibboleth developers, perhaps due to the open-source mentality of make it work, then make it work well, or that it was not perceived to be an interesting or hard enough problem.

These works are licensed under a Creative Commons License. Creative Commons License