There are three existing 'production' University Federations worldwide; SWITCHaai Federation, a group of Swiss academic organisations; the HAKA Federation in Finland; and InCommon Federation in the USA. There is also a transitional service in the US called InQueue, for organisations which have not identified a suitable Federation to join, but wish to participate in the use of Shibboleth (this is available to institutions in countries which have not established a national Federation, or cannot comply with the trust and privacy regulations of existing Federations).
SWITCHaai Federation[12]
The SWITCHaai Federation is a group of organisations (universities, hospitals, libraries, etc.) that have agreed to cooperate regarding inter-organisational authentication and authorisation and, for this purpose, operate a Shibboleth-based authentication and authorisation infrastructure (AAI).
The organisations agree to abide by a common set of policies and practices such as:
-
business rules governing registration of users and exchange and use of user attributes
-
a set of rules governing the development of the Federation
-
best practice on associated technical issues, involving attribute management and security
SWITCH defined two categories of membership for participation in the Federation:
-
Education and Research institutions; i.e. all universities, Swiss Federal Institutes of Technology, research institutes in the FIT sector, universities of applied sciences, public research institutes and teaching hospitals. It comprises all organisations which, pursuant to Swiss Law, are supported by public subsidies. It also includes organisations engaging predominantly in pre-competitive research.
-
Supporting Organisations; comprising public institutions with which the Education and Research organisations collaborate by way of practice and support of their activities (e.g. libraries, Swiss National Science Foundation, Swiss University Conference, SWITCH)
SWITCH also acts as a service provider, supplying the central AAI Services and operating a resource registry. SWITCH has also allowed for Federation Partners, who would offer services and resources to the Federation members, but would not act as Home Organisations, as they do not represent communities of users. However, to date no such Partner organisation has been found to act within the SWITCHaai Federation, so there is no formal service agreement covering this category of member.
The legal framework for the SWITCHaai Federation has been based on existing Swiss Data Protection Law outlining the legal basis for handling personal data and existing University rules governing liability issues among participating organisations. A new legal framework[13] had to be devised for the SWITCHaai Federation since there was no existing service agreement structure in Switzerland. This complies with data protection laws, but there appear to be gaps which would need to be filled for compliance with the UK Data Protection Act; for example, it does not make it clear who is responsible for challenging which attributes Service Providers request, and does not clearly require that the Identity Provider must ask for consent from its users before releasing attributes to third parties.
The core functionality of the Switch AAI is to couple together the three basic interactions between a user, his or her home institution and a resource during the authentication and authorisation process. These three basic interactions are: user authentication, which is always carried out by the user’s home institution; access request; and delivery of authorisation attributes from the home institution to the resource.
The system and interface specification for SWITCHaai is given in their online documentation: http://www.switch.ch/aai/documents.html
InCommon™[14]
"InCommon is a formal federation of organisations focused on creating a common framework for trust in support of research and education".
By using Shibboleth authentication and authorisation technology, InCommon intends to make sharing of protected resources easier, enabling collaboration between InCommon participants which protects privacy. Access decisions to protected resources are based on user attributes contributed by the user's home institution. InCommon became operational on 5 April 2005.
InCommon development was based on a temporary members Federation called InQueue. This was set up in 2004 to test basic services, processes and policies needed for a Shibboleth Federation. Member organisations in InQueue are able to trial membership in a Shibboleth Federation, and learn about Shibboleth Software. However, it did not have sufficient security to operate as a production-level federation, and organisations were discouraged from making sensitive resources available via the federation.
One goal of the Federation is to develop, over time, community standards for such cooperating organisations to ensure that shared attribute assertions are sufficiently robust and trustworthy to manage access to important protected resources. As the community of trust evolves, the Federation expects that participants eventually should be able to trust each other's identity management systems and resource access management systems as they trust their own.
In October 2004, the InCommon Federation published[15] the following documents outlining their planned policies and practices:
-
Overview of the InCommon Federation
-
InCommon Federation: Federation Operating Practices and Procedures
-
InCommon Federation: Participant Agreement
-
InCommon Federation: Common Identity Attributes
-
InCommon Federation: Participant Operating Practices
Participants in the Federation place a certain amount of trust in the Federation Organisation to perform correctly and reliably the support functions that it provides. Participants also need place a great deal of trust in each other as the source of attribute information or a repository of subject information. InCommon has also developed a risk assessment, and operations which will be undertaken within the federation to mitigate those risks.
Given that the primary mission of InCommon is to build trust between participants, institutions must agree at an executive level to adhere to the terms and conditions of federation participation. InCommon requires that participants make available to other participants certain basic information about how they verify identity, distribute user accounts, and manage information on their campus.
Organisations applying to join InCommon must agree at an executive level of their organisation to the terms and conditions of federation participation, which include documenting the practices and procedures used to grant and manage user accounts. Being accepted into InCommon has been set up as a two-step process:
-
completion of the InCommon application: this identifies the person who will act as the liaison to InCommon; the application is reviewed by the InCommon Steering Committee, and the liaison person is vetted;
-
by invitation, the administrative contact for the organisation can submit metadata to InCommon, after which InCommon will issue certificates to the organisation.
All information submitted to InCommon will be verified to check that it is correct.
Participation in InCommon is open to all two- and four-year, degree granting higher-education academic institutions that are regionally accredited by agencies on the U.S. Department of Education’s list of Recognised Accrediting Agencies. Academic institutions join InCommon primarily as Higher Education Institutions that act as Credential Providers (or Identity Providers), supporting an identity management system for its community, though they may also choose to offer resources as well.
Regarding service providers, to join InCommon a Sponsored Partner must be an organisation providing resources (information or services) to the academic community and as such, must be sponsored by an InCommon Higher Education participant.
InCommon has been set up as a Limited Liability Company (LLC); the Limited Liability Company Agreement outlines the purpose, membership, and structure of InCommon. The InCommon steering committee, representing the founder university members of the federation make up the directors of the LLC. No fees are paid to them, but their expenses in running the federation are covered. There is also an "operations manager", who is appointed by the Steering Committee from Internet2 staff and acts as the Chief Executive officer.
On 18 April 2005 a set of "bylaws" for operating the InCommon LLC were published online, defining the operations of the company, and the responsibilities of the members of the Steering Committee in more detail
Since InCommon has been set up as an LLC it forms a legal entity and therefore is governed by the laws of the State of Delaware and any other state in which the company conducts business, as well as US Federal Law. The participant contract includes clauses covering adherence to Governing Law, and that the "Participant agrees not to participate in the Federation in a manner that violates federal, state or local laws and rules, or in a manner that interferes or could interfere with services provided to others".
Participants must agree to respect the copyright on any content accessed. Clause 8 in the participant agreement refers to respect for intellectual property (covering usage of copyrighted materials) and Clause 9 of the agreement outlines Respect for Privacy of Identity Information
There are technical requirements to becoming an InCommon member; Shibboleth v1.1 or higher must be installed, to support InCommon's federated authentication model. Otherwise the technical framework is outlined in documentation on the InCommon website: http://www.incommonfederation.org/technical.cfm
The HAKA Federation in Finland entered its production phase in late 2004. The Federation was set up in 2003, currently including 2 (of 20) universities and 1 (of 29) polytechnics as Identity Providers, and 4 service providers, including the National Library Portal (Nelli). In Finland[16], the libraries in higher education traditionally co-operate widely in licensing electronic journals. The Finnish Electronic Library consortium is the centralised organisation negotiating the licence agreements with publishers. Furthermore, the consortium has recently deployed a portal (Metalib, a product of Ex Libris Ltd) that constitutes a common interface to the dozens of publishers the libraries have licence agreements with. The portal uses services of the Haka federation to authenticate the user and provide her with customised services.
The organisation of the HAKA Federation has been based on the SWITCHaai model[17]. Development of the Federation has been closely coupled to the IT department developments in the HEIs involved. From the start special attention was paid to the quality of data held and collected by institutional identity management systems and directories. The Federation is hosted by the Finnish IT Centre for Science (CSC), which also maintains the national research network (FUNET), however, identity management rests with each of the higher education institutions. The HAKA federating infrastructure service will be provided by CSC and based on an agreement between CSC and each Federation member.
One of the HAKA Federation rules states that only institutions with up to date user data are welcome to join. HAKA have also defined minimum requirements for an institution intending to join the Federation[18].
The SWITCHaai service agreement is the basis for the legal framework for HAKA. The Finnish Personal Data act needed to be considered in setting up a legal framework for the Federation. The Swiss agreement was considered to be "unnecessarily detailed and complex". A shorter more generic framework has been written for HAKA. This considers three main principles:
-
the purpose of the federation "to support research and education in higher education and research institutions".
-
responsibilities for challenging the necessity of attributes
-
asking for user consent before attributes are released and for the end user to be able to study a privacy policy
The HAKA Federation believes that Shibboleth technology fits well with Finnish Data Protection requirements, and there is no conflict of interest for the user between use of resources through Shibboleth and personal privacy.
The HAKA Federation has the same components and operation as the SWITCHaai Federation (see 2.1.4).
Like in SWITCHaai, the Haka federation has two categories for federation participants; federation members and partners. Higher education and research institutions may join the federation as members and become both Identity Providers and Service Providers. Federation partners, such as library content providers, may only become Service Providers. As the service agreement of the Haka federation is signed between the federation operator and the participant, from the federation participants’ point of view, the federation is a service provided by the operator and the other federation participants are subcontractors for the operator. In the agreement, it is made explicit that the contents of the service agreements are equal for each federation member.
[12] Detail taken from SWITCHaai Federation - Organization and Processes documentation: http://www.switch.ch/aai/documents.html
[13] For more detail see http://www.switch.ch/aai/agreement/
[14] Summary information taken from: http://www.incommonfederation.org/
[16] Linden, M (2005) Organising Federated Identity in Finnish Higher Education. Trans-European Research and Education Networking Association Conference, 6-9 June 2005, Conference Paper. http://www.terena.nl/conferences/tnc2005/programme/presentations/show.php?pres_id=77