York Meeting, 04/05/05

Preamble

This is a summary of the discussions that took place between members of the Iamsect project, York and Hull Universities on 04/05/2005.

Questions and answers that were discussed throughout the day are collected after a brief description of the events. My notes that I have based this summary on were by no means complete. If anyone else has a set of notes that may help expand on this, please feel free to either submit a modified version to me, or pass on your notes for assimilation into this summary, to jon.dowland@ncl.ac.uk.

Some of the questions that were asked we were unable to adequately answer at the time. Where possible I have supplied an answer now. It is my intention to collate the Q&As (both answered and un-answered) with those from other events in one place on the Iamsect site in future.

Some questions were really a collection of different questions bundled up into a discussion point and have been separated out. Discussion on one topic quite naturally drifted to another and so division was necessary.

Introduction

Paul Browning introduced the IAMSECT team and gave a brief talk about Shibboleth. Highlights included British Educational Communications and Technology Agency (BECTA) making motions in the shibboleth world. Each person then gave a brief introduction to themselves. There were representatives from the web-team and faculty of medical computing at the University of Newcastle; the library at the University of York, Hull/York Medical School and Hull and York Universities.

Presentation

In the first half of the day, Tony gave a presentation to explain what Shibboleth is and what the Iamsect project are working towards. The core concepts of shibboleth were described, drawing parallels with the existing Athens technologies. There was a `dry-run', slide-based demonstration which explained each step of the shibboleth process.

Here are Tony's slides from the day: PDF (916KB), Powerpoint (2.9MB).

These works are licensed under a Creative Commons License.

Question and Answers

The second half of the day kicked off with a demonstration of Shibboleth in action. Caleb accessed the BIOSIS journals service, by authenticating at an Identity Provider (IdP) in Newcastle. We then polled the group and obtained a list of questions / discussion points to try and cover. Although the second half of the day was provisionally for technical questions, we were happy to answer anything.

Is it necessary to have SSO before you can participate in Shibboleth?

Short answer, yes.

Long answer: The shibboleth origin software does not provide login functionality. You need a piece of software which will allow a user to login, authenticate them and provide the logged in user's username as the REMOTE_USER server variable in apache, even if this information is not going to be propagated to the service provider. (This is the de-facto way of providing usernames to programs with apache).

The recommended way of doing this is to use a single-sign on (SSO) technology such as Pubcookie or Yale CAS. This, in turn, can talk to an existing institutional database such as Microsoft Active Directory. However, any method which can populate the REMOTE_USER variable will suffice, including plain text (`htpasswd') files maintained manually on the server itself.

In most cases however, the single sign-on approach will be less maintenance work and of benefit outside of shibboleth.

Those wishing to test can just use htpasswd files or their password store via something like mod_auth_ldap to get a feel for how it works before getting proper SSO. it should be noted that the shibboleth model would allow a collegiate style approach where an institute might have several different password stores, e.g. Bede college users auth against Bede's active directory, st john's against st john's kerberos server. this would need the wayf to ask users which college they came from.

Will it be a management nightmare joining lots of different federations? For example, if a US resource is in a US federation will each UK institution need to join that federation?

Possibly too early to tell, though the current trend seems to be to have as few federations as possible. The resource might be the one joining the uk fed rather than every institute joining some foreign fed. There are technical reasons at present why joining multiple federations is not a good idea.

In a federation, who looks after the Where Are you From (WAYF) server? Can the WAYF be omitted altogether?

The WAYF can be looked after by anyone: a service provider, an identity provider, or even contracted out to a third party, as it's a relatively lightweight service. It could be run on the same machine as a service or identity provider in the federation it operates for.

The WAYF can be omitted altogether : a service provider can be configured to send users off to a fixed identity provider rather than a WAYF. We do this when setting up a new service provider as a quick way of testing. It means that all of your users must come from a single identity provider, however.

Can a service provider do some thinking about how/where to authenticate a user itself?

Yes - (this is a very speculative answer): however, you'd essentially be duplicating the work of a WAYF.

If there was a national federation, who would run it?

At present, the SDSS project have created a federation that they describe as being for `development'. This means not production - they have not been asked and do not intend to run a federation designed for production use. It also means not test. For example, the Inqueue federation is a test federation, which is useful for the initial job of setting up Shibboleth but does not provide guarantees about identity and so is of no use for setting up the Shibboleth trust model.

So there is no current work being put into developing a national federation, although the understanding is that as few federations as possible is best, so a national one would be a good idea.

Since the York meeting we have learned more about JISC's plans with regards a national federation. There is still nothing concrete but they have been thinking about it.

Cal: There is a document called "blue print for a national federation" being circulated by Alan Robiette and Terry Morrow (both of JISC) but I can't find an online copy. If you are interested mail Terry and ask for a copy.

What do we know about the Athens federation?

(At the time of the meeting) very little. A test federation does exist, and Newcastle is a member. This federation however only allows you to access demo resources, and the `success' situation is 'You are logged into the Athens service, but you do not have permission to access this particular resource.'

The Middleware Assisted Take-Up service (MATU, http://www.matu.ac.uk/) had only very recently established their website and details of their plans had yet to be published. Their website is now considerably more informative and details their plans for integrating Athens and Shibboleth. They have recently announced their news page (http://www.matu.ac.uk/news/) where their developing plans are expected to be shared. This has just been updated with details.

Isn't the Athens/Shibboleth integration a fixed road-map?

Yup see http://www.athensams.net/gatewayresources.php http://www.athensams.net/local_auth/shibboleth/ng-roadmap.pdf

How does Yale CAS compare with pubcookie? Why did we choose pubcookie?

We have no experience with using Yale CAS so it is hard for us to compare it to pubcookie. The original reasons for adopting pubcookie over Yale CAS were fairly specific to the experience and preferences of the people setting it up at Newcastle. CAS is a Java project, pubcookie leverages the apache httpd server, and in our experience apache-based services are more reliable and easier to maintain than Java ones (such as tomcat). Pubcookie also has active mailing lists and questions were answered more readily than with CAS at the time.

It was noted that at present, CAS are doing better at disseminating their solution than pubcookie and so more people looking at this software have heard of it.

If you are planning on using CAS, we would be very interested in how you get on; specifically if you use one of our documents (see http://iamsect.ncl.ac.uk/deliverables/). In this case we would be grateful to know if any of our documents were inaccurate or misleading when used in conjunction with Yale CAS.

Would existing US-based resource providers who do not support Athens be more inclined to support Shibboleth?

Without talking about a specific service, there is a higher likelihood. Reluctance to support Athens is presumably because Athens is UK-only, and the service has national interest. As shibboleth is being adopted world-wide, there is more of a justification for service providers to support it.

How do I shibbolize X [Where X could be Aleph, Blackboard, Metalib, or a generic service]

Wait and see! we are working on Blackboard (some have already got it working); our library has been funded to work on getting Aleph and Metalib working, but all of this is at an early stage.

How transparent will this middleware be when setup properly? Will users need to be educated to know which button to press?

Some background on this question: The SDSS demonstration at present requires the users to click on a button labelled 'Login via Shibboleth', vs. a button 'Login via Athens', as the two authentication methods are being run in parallel. To a user who wants to access a resource, this is too much of a burden of knowledge. The user shouldn't have to concern themselves with the specifics of how they are authorised to access a resource.

With a `pure' shibboleth resource, there is no such button - a user need only know what their `home institution' is. The current situation can only be expected to last as long as two authentication methods are running in parallel.

From a technical perspective, how resilient is the Shibboleth architecture to fail-over? E.g. if the WAYF is down, does that prevent Service and Identity providers from working together?

Cal: Shib is designed as a decoupled architecture. Basically it is modular bits that do one job and each modular bit can be clustered for resilience: the attribute authority can be clustered; the identity provider can be clustered (well pubcookie certainly can as we have); the WAYF can apparently be clustered; the target should be cluster-able. the only bit I am unsure of is the handle service (part of the identity provider) but then it is not doing anything monumental so is shouldn't be loaded and I suspect it can be.

[Installation War-stories]. Who is using Shibboleth in anger? How hard is it?

America, Finland and the Swiss are using it in anger. in the uk it is still testing rather than proper production, though i expect proper service to begin this summer. at present is is relatively hard to setup and configure but certainly doable and the docs (including iamsect's) are getting better.

As an example of how hard it is to setup an identity provider, this was one of the first tasks attempted by Jon Dowland on starting as the position of Project Officer, and it was perhaps a week's work (which included gaining familiarity with all of the systems concerned). At the time of the York meeting, we hadn't successfully set-up a service provider.

We have now managed to setup service providers and are actively working on getting `useful' services: namely, a Zope-based VLE and Blackboard behind Shibboleth. It is our belief that the process of installing the Shibboleth software is too confusing at present, although the situation (and documentation) is rapidly improving.

It was noted that Simon McLeish (PERSEUS project hosted at LSE) has written about their experiences with shibboleth in Ariadne issue 43.

How does the Shibboleth software compare to the traditional HTTP 401-based authentication with regards to load?

Not too sure. People have stress tested it and some of the Americans are using it with brutally large user populations and there haven't been any major stumbling blocks yet.

What is the roadmap for continuing standards usage with Shibboleth?

Shib and SAML2 seem to be converging and indeed the lead Shib author is the lead editor of the SAML spec. Liberty alliance and Microsoft seem to be genuinely interested in converging too. (see the discussion point below).

Discussion Points

Discussion point: Liberty Alliance

See https://mail.internet2.edu/wws/arc/shibboleth-users/2005-05/msg00178.html and also apparently the Russell group IT directors have invited Sun + Microsoft to brief them on what is happening (with firm words about it not being a sales pitch...they want facts) in September.

Discussion point: N-tier authentication and Shibboleth

[Definition for the benefit of some of us: N-tier authentication is related to portals and is where authentication information can be propagated between web services on your behalf. An example would be a portal which can talk to a mail service on your behalf to report how many unread mails you have, by taking an authentication `token' from you (as oppose to automatically having the right to read all mail-boxes)].

You tell us :-) we are looking but this is a poorly understood field and not within the scope of our project.

Finally...

The following questions were asked but I do not have sufficient notes to supply answers to them:

If anyone else present believes I've missed a question out, or part of an answer, or can flesh out those points above, please send info to jon.dowland@ncl.ac.uk and I'll incorporate it into this summary.