« JISC briefing paper on third party suppliers of federated access management solutions - some clarification about OpenAthens | Main | The man whose tweets were all exactly alike »

March 06, 2008

Options for joining the UK Access Management Federation

In their recent briefing paper about third party providers of federated access management solutions (see also my previous blog entry on the same topic) the JISC present three options for participating in the federation, as follows:

  1. Become a full member of the UK federation, using open source software with in-house technical support
  2. Become a full member of the UK federation, using open source software with paid-for support
  3. Subscribe to an ‘outsourced Identity Provider’ to work through the UK federation on the institution’s behalf

It strikes me that this is a rather unsatisfactory list for two reasons...

Firstly, options 1 and 2 are prefixed with the phrase "Become a full member of the UK federation" whereas option 3 is not.  Why?  The implication seems clear enough... if you choose to outsource your identity provision then you are not a "full member" of the federation, whatever that means.  This is an odd choice of wording, especially in a political and financial environment where institutions are generally being encouraged to consider shared service solutions as alternatives to doing everything in-house.

As I said in my previous blog entry, I am not particularly trying to promote outsourced solutions here - our's or anybody else's - institutions can make their own minds up about that.  But I see no good reason to give the impression that those institutions that choose to outsource their identity provision to a third party are any less members of the federation than those that do everything in-house.

Secondly, the list mixes up 'technology provision' and 'support arrangements' in a rather unhelpful way.  It would be more helpful to separate these, giving two lists as follows:

  1. In-house identity provision using open source software.
  2. In-house identity provision using commercially licensed software.
  3. Outsourced identity provision using an external service provider.


  1. In-house support
  2. External support

I appreciate that even these lists aren't perfect (we offer a partially outsourced identity provision option for example) and that a matrix of the two may not be fully populated (the combination of in-house support and outsourced identity provision doesn't sound likely for a start!).  Despite that, it think it is a more accurate reflection of the options facing institutions than the three options currently presented by the JISC.


TrackBack URL for this entry:

Listed below are links to weblogs that reference Options for joining the UK Access Management Federation:


I think this is where you have a fundamental lack of understanding of how the UK federation works Andy. In the present arrangements an institution using an 'outsourced identity provider' - rather than using commercial support to adopt an in-house SAML compliant solution - does not register an entity with the UK federation so is fundamentally a different type of member than those who do so directly. This is true of both the in-house AthensDA (LA?) product and classic Athens (Athens MD?) so your distinctions are not correct. We are actually in the process of working closely with Tom Demeranville at Eduserv to see if we can change this process to allow OpenAthens to provide accountability. I think this is a positive move forward and I am very grateful for his work and the work his is doing to provide consistency for entityIDs and user IDs for institutions. However, this work is not complete and our briefing paper is correct. Eduserv were given the opportunity to comment before this went to print.

Actually, that part of my comment had nothing particular to do with the Eduserv OpenAthens offerings, both of which I really consider to fall under the outsourced case (case 3 in both your list and my list).

My comment is that your list seems to have missed the possibility that an institution could buy in Shibboleth software as a commercial (i.e. not open source) software package from a commercial vendor and run it in-house.

This isn't the case in either of our offerings but seems to me to be a perfectly valid choice for institutions. But for some reason it doesn't appear on the list. I just wondered why it had been ignored as a possibility?

BTW, thanks for putting me straight about my "fundamental lack of understanding"! Always good to know! :-)

I guess I was slightly cryptic...

I do understand that JISC and/or the UKAMF took a policy decision at some point to treat institutions who implement Shibboleth in-house differently from those who choose to outsource - i.e. to handle their registration with the Federation differently.

And, yes, I understand that someone took a policy decision to call one 'full' membership and one not. However, I don't see that there was any technical basis for why that policy decision was made. I presume it was made purely on the basis that it might encourage in-house adoption?

Whatever... my personal view is that it is no business of either the federation or the JISC whether an institution chooses to do things in-house or chooses to outsource. The important thing is that they are implementing Shibboleth. Full-stop.

Furthermore, there are very good practical reasons why the choice between in-housing and outsourcing should be completely transparent to the Federation. Why? Because if it is transparent then any subsequent transition from outsourced to in-house adoption becomes much more straight-forward. With the current set up, an institution that implements an outsourced solution but then wants to transition to an in-house solution in the future will have more work to do than should be the case.

We want to make that transition as smooth and as open as possible.

The comments to this entry are closed.



eFoundations is powered by TypePad