Identity Federation
Starting
small and reaching way beyond
Thomas Lenggenhager
SWITCH
SWITCH, Case postale, CH-8021 Zurich
Résumé
How to extend Web Single Sign-On beyond the security domain of a single university? This well-known problem initiated the implementation of the Swiss identity federation (SWITCHaai).
Universities issue digital identities to registered students and their staff by providing them their user account. When a university is part of a federation, such digital identities can also allow access to web based applications run by other institutions.
In Switzerland, the primary use case to establish the Authentication & Authorization Infrastructure (AAI) was to enable access for students to courses on learning management systems (LMS) hosted by third party universities. After five years of operational experience, SWITCHaai is well established and has become 'the key' for authenticated access to web servers in higher education.
The first part tells the story of SWITCHaai and some of the lessons learned.
Today's federations are limited to their national scope, as they are mostly operated by a national research & education network (NREN). The time has come to reach beyond national borders by building the technical and trust framework on which national federations shall be able to inter-federate.
Once inter-federation is a reality, a professor of a French university could direct his/her students to a course hosted on the LMS of e.g. Université de Genève. Today, unless the course is publicly accessible, it would require a huge overhead to bilaterally enable properly authenticated access.
Ideas and activities towards a scalable inter-federation future are in the focus of the second half of this paper.
Mots clefs
AAI, Federated Identity, inter-federation, SAML, Shibboleth, WebSSO
Seamless authenticated access to e-learning courses, irrespective of the university offering the courses, was precisely the concern which laid the ground for the Swiss AAI activities back in 1999. Users were not to need additional accounts – their existing account at their home institution would be the only one required for access to web-based services in other security domains too.
The use case for AAI originated from the federal funded impulse program Swiss Virtual Campus (SVC). The goal of this four-year program (2000 – 2003) was promoting learning over the internet in Swiss higher education. SWITCH was invited to get involved in finding a scalable solution to federated authentication.
The term AAI for ‹Authentication and Authorization Infrastructure› was first coined in a document dated November 1999. AAA was a term familiar from the network layer – with the third ‹A› standing for accounting. Neither the SVC problem statement nor other use cases at that time required accounting up front.
The other two ‹A’s› provided challenge enough. SWITCH thus chose the ‹I› for infrastructure to stress its key goal of complementing the network infrastructure with infrastructure for authentication and authorization on the middleware layer.
To tackle the AA problem, SWITCH closely cooperated with the universities. A concept paper in September 2001 introduced the vision of e-academia and stated: ‹an AAI represents a small yet important step in this direction.› This concept included a four-year roadmap towards an AAI, which was subsequently adhered to quite closely during its implementation.
In a first step, four working groups focused on legal, organizational, technical and financial issues. This study phase was summarized in an AAI Report in July 2002.
The subsequent pilot phase evaluated the best suited technology for the final deployment and provided showcases. In January 2003, Shibboleth was selected as the technology for SWITCHaai. The Internet2 Middleware Initiative had made a start on the Shibboleth design and implementation project back in 1999. Shibboleth is based on SAML, the standard Security Assertion Markup Language, which it influenced to a major extent.
Shibboleth version 1.0 came out in July 2003. Switzerland was the first country outside the US to select Shibboleth for deployment in higher education. SAML and Shibboleth have now been adopted and deployed in a large number of other countries.
Students were first able to access e-learning courses via AAI in autumn 2003. On the basis of the AAI Report, and with the support of the universities, SWITCH successfully applied for federal funding for an AAI rollout between 2004 and 2007.
Universities were able to apply for matching funds for the installation of Identity Management and Shibboleth. Based on the final AAI policy and legal framework, production service started in October 2005. Just one year later, all the federal and cantonal universities had already joined SWITCHaai. Since then, nearly all the universities of applied sciences, as well as a couple of teacher training universities have joined SWITCHaai, and hence, since 2009, user coverage has been in excess of 95% in the tertiary education sector.
Today, the Swiss AA infrastructure comprises more than 40 identity providers (> 270'000 user accounts) and more than 360 AAI protected services. Most actively used are still the many AAI protected LMS systems. In Sept 2009, every three seconds a user sent an authentication request via one of the two central discovery servers operated by SWITCH.
With the SWITCHaai Advisory Committee on the strategic level and the Operations Committee on the operational level, SWITCH is continuing the tradition of close cooperation with representatives of the user base.
With the strong use case of SVC, it was much easier to get the universities committed to AAI. From the beginning, SWITCH was in close contact with the top level as well on the administrative and technical level of the universities. That paid out well in the deployment phase, where the matching funds eased adoption further.
Around 2000, one would have thought that user certificate based stronger authentication would get quicker adoption than we see now. However, AAI is ready for supporting stronger authentication. Where is the use case from a university which wants to go forward?
As with all infrastructures, AAI also needs proper maintenance. It is a security relevant software, so security updates should be quickly applied. This requires the availability of well-trained sysadmins or web application admins, also after the first deployment.
The next step, after establishing a national AAI, is to plan the next level, going international. In the established federations, you find a couple of foreign SAML Service Providers (SP); mainly from publishers offering licensed digital content. Since joining a federation generally requires signing a contract, the overhead is considerable.
Instead of joining more than one federation, it is also possible to negotiate and configure bilateral agreements between a single Identity Provider (IdP) and an SP. That scales badly, but is rather straightforward and one can solve an immediate need. In such a way, the IdP of a university in Munich is capable of authenticating users for the LMS operated by University of Zurich.
Nowadays, SAML is the accepted standard for AAI federations. That eases finding a solution for inter-federation, because there is no need to support a couple of protocols . For each federation, the SAML metadata describes which IdPs and SPs participate in the federation. Each entry in SAML metadata lists the communication endpoints and public keys used by an entity. This information is crucial for successful interoperation between an IdP and SP, it allows to reach and properly identify the other party. SAML metadata gets digitally signed by the federation operator to protect it against forgery.
The GÉANT3 sub-project eduGAIN is tasked to start an operational inter-federation service by mid 2010. The idea is to collect the SAML metadata from participating federations and to make the collection available to them.
Most likely, not all IdPs and SPs from a federation will have an immediate use case to participate in inter-federation. So they will be able to opt-in, and the SAML metadata used within a federation will be more extensive than what gets shared with other federations.
All that sounds simple, and in fact, the technical hurdles seem to be solvable in time.
Beyond the technical aspects, inter-federation faces legal challenges, mainly concerning data protection. What information is allowed to cross national borders? Is general or explicit user consent required to release information?
Trust is another aspect to consider. Why should an SP trust an authentication statement asserted by a foreign IdP with which no direct agreement exists? What kind of assurance an SP can get about the quality of the data it received? Is it really a student properly enrolled at the other institution?
All such questions have to be considered when discussing and planning the legal and trust framework for inter-federation. This part of the work seems still more fuzzy and unclear which kinds of policies are really required. Finally the overhead introduced for inter-federation should be as little as possible but still enable a wide range of usage.
It was a long way from the first idea of AAI in 1999 to the production service in 2005 and nearly full coverage as today. However, building infrastructure is always an investment into the future and often enables new usages never thought of in the beginning. Just think of the railway system. Extending infrastructure in a compatible way to the international level is even more complex but it will offer as well many benefits once in place and readily usable.