Welcome to the VAMP2012 blogspace.

This blogspace is intended to provide you with a space to share your thoughts during, and after, the VAMP Workshop in Utrecht.

You can use it to voice your opinion, share your ideas or just mention something interesting. Everything you say will be taken into account, read, understood and thought about by the very people you most need to communicate those ideas with.

Looking forward to hearing your thoughts!

Wednesday, September 5, 2012

The ‘businesscase’ for Federated Collaboration

Identity Federations, like SURFfederatie, have become very successful as a means to simplify secure access to services. With Single Sign-on for endusers, and controle and security for campus IT it is by now the preferred way of allowing access to a remote service. This has been happening both in The Netherlands with SURFfederatie and SURFconext, as well as in many of the countries that have a federation for higher education. However, when it comes to supporting reseach collaborations things look rather bleak.

The business case for federation for a campus is very good, even though some technical, organizational and legal hurtles need to be taken to become an Identity Provider (IdP). This quickly fades against the ease of adding new services for all the users on the campus. Equally so, as a Service Provider (SP) joining a federation immediately makes the service available for all the institutions that are a member of that federation. Of cause, permission to actually use the service may still be required from an IdP. And a commercial agreement may need to be signed, both depending a bit on the governance model of the federation.

So, sharing access to scientific resources and collaboration tools using identity federations should be a breeze. Given their mostly non-commercial character and the fact that these are offer by ‘peer’ institutions makes them ideal Service Providers for the academic federations. Or so it seems….

FIM4R

Because in practice, many issues exist. Recently, a large group of research organisations launched an initiative, FIM4R, to list the requirements for federated identity for research. Several of the requirements directly address the identity federations, their policies and operations, which are currently optimised for supporting IdPs in consuming their ‘campus’ services. Campus services and their requirements differ very much from what is needed for the type of services that are commonplace in research.

A major issue is the release of attributes and identifiers. Contrary to campus services, releasing attributes and identifiers for collaboration services almost always means releasing these to a domain that is not part of the campus. Even though all federation agreements have excellent rules for SPs on how to handle the attributes in a secure and privacy preserving way, institutions are very reluctant to release attributes. Collaborative services however cannot do without basic attributes like first and last name and an email address.  Also often identifiers are presented as a transient IDs, making these completely useless for any collaborative service. All of this puts a large burden on the reseach service providers as they will now need ways to work around that.

Another issue lurking under the surface is scalability on the side of the institutions. Typically a ‘campus’ service will require one connection to serve most of the users at the campus. Whereas in research collaborations it is very likely a rather specific service will serve only five people within a specific department. Now realise that these five requiring access to a specific service are not a special case, so we may find the number of potential SPs to be something like the number of researchers at a given institution. The IdP admins will rapidly see the number of SPs that need to be connected and managed rise to several hundreds. That is a task which is no longer within the capabilities of most campus IT department, if ever it was. Net result is that campus IT is going to be very reluctant to support connecting these kinds of services to their IdP.

A way forward

The above issues are just a few of the hurtles reseach collaborations currently face when they want to engage the world of federated identity management.  But as institutions, do we want to help, or hinder our users, departments, faculties and Virtual Organizations to also leverage the power, trust and security of federated identity to collaborate? As federation operators, can we device better policies and tools to make reuse of our  existing federation infrastructure much easier?

For starters, a change in policy is needed. Any service offered by a federation ‘peer’ should be open by default, preferably without any intervention required from the IT department. That may feel scary, yessir. But do we really think sending documents, data and other content by email or sharing these in services like Google and Dropbox is a better and safer way to let our users collaborate then via services that are part of our trusted federations? By change from “opt-in” to “opt-out” we will not only ease the burden on the IT department, but we will also not break collaboration opportunities for our researchers. Within SURFfederatie this is one of the issues we are working on right now.

When it comes to attributes, we should make life for service providers much, much easier. Of cause policy still needs to be in place. But why can’t we create a number of internationally accepted defaults, an attribute bundle, and link that to a category of SPs we know we can trust, for example because the national NREN has identified them as such. InCommon is now working on something like that with the introduction of their “Research & Scholarship” category.

Most of all a change in mindset is needed. We need to ready our (inter-)federations to become international players in providing internet identity. We must step up to become enablers for global collaboration, not the breakers of it.  If we to keep our federations inward focused, nation based islands as they are now, they will have outlived their usefulness for collaboration tomorrow, and as general providers of identity within a few years.

Think global, act local

And of cause, limiting these efforts to national federations alone make no sense at all. Research collaboration does not adhere to country borders. The five Dutch researchers mentioned earlier will be collaborating with colleagues in the the rest of Europe, and beyond.

On an international level eduGAIN is the European inter federation effort that already has members from several EU countries. Canada recently announced they will be joining in as well. Even though scientific collaboration throughout Europe is plentiful, eduGAIN is not taking off. Mostly because it lacks IdPs because of “opt-in”. And offers no useful attributes, even after we have made the research organization jump trough the many policy hoops we created for them as part of the eduGAIN policy. The recently introduced “eduGAIN SP code of conduct” will surely help here, but this is only a small step, where a giant leap in uptake is required. And what about the ones that are not a member of eduGAIN?

With REFEDs in place to articulate the mutual needs of research and education identity federations worldwide, the platform for direct interaction with our own research community seems in place. Let’s siege this opportunity so our researchers can enjoy the same fruits we have been giving our institutions.
———

Next week, the VAMP meeting, organised by Internet2, SURFnet and Terena, brings together the IT architects of many key international research groups, along with leaders in international federation development. The intent is to directly engage both communities into helping the VO’s in effectively leveraging the emergent interfederation infrastructure, resulting in more effective research organizations.

The author of this blogpost works for SURFnet, however, any and all opinions are his own.

N.B. this post was earlier published on https://blog.surfnet.nl/?p=507

1 comment:

  1. I will be looking for help to build the business case for InCommon to join eduGAIN. All good advice and pointers welcome. --InCommon Tech. Adv. Comm. member KeithH

    ReplyDelete