Executive Summary
This document provides an analysis of the requirements the team has collected up to now from scientific communities and project stakeholders. It is an outcome of the "Requirement Analysis" activity in the JRA1 work package, "Architecture for an integrated and interoperable AAI". For the requirement- gathering process, we followed a three-step approach. Section 2 elaborates on the requirement extraction methodology adopted by AARC to ensure that the proposed integrated AAI framework can meet the needs of all stakeholders.
As a first step, we returned to the results of previous activities such as the "TERENA AAA Study" and the FIM4R workshop series and analysed their outcomes in order to produce an initial set of requirements, presented in Section 3.1.
During the second step, this set of requirements was enriched through the results of a survey that was run by AARC during the summer period. The goal of this survey was to identify the barriers communities are currently facing to adopting and using federated access, and to capture their requirements for an interoperable AAI. Α total of 10 scientific communities have responded to this survey and the results are presented in Section 3.2 of the document. In addition, a set of one-to-one discussions were held with key representatives from EGI, ELIXIR, EUDAT and GÉANT, in which we discussed their plans, their successes and the barriers they are facing. The results of these discussions are presented in detail in Section 3.3.
As part of the third and final step, the extracted requirements have been extensively processed, homogenised, merged, filtered, extended and classified to produce a refined set of requirements formulated into tables, shown in Section 4. We have identified 25 distinct requirements, 18 relating to tools and architecture and 7 relevant to policies and best practices. The document's conclusions are drawn in Section 5.
Finally, the questionnaire used for the AARC internal survey is presented in 0, while a brief description of the main AAI use case for each participating user community is provided in Appendix B.
Introduction
Controlling access to research-related resources and collaborative tools is challenging, particularly when dealing with research communities that can be geographically dispersed across Europe and the globe. National identity federations for Research and Education (R&E), whereby the user's identity is verified by the institution that issues the user’s credentials, enable users to access different services with the same credentials, while allowing research e-Infrastructures to offer resources in a more controlled and consolidated way.
While eduGAIN serves as a global interconnection framework for national identity federations, multiple interoperability gaps still exist between the different Authentication and Authorisation Infrastructures (AAIs) that are operated by the national federations and the various research collaborations and e- Infrastructures. Besides interoperability issues, there are also functional aspects that have yet to be addressed, such as identity attribute aggregation from multiple providers, Single Sign On (SSO) support for non-web applications, delegation capabilities, and credential translation services. In addition to addressing these technical aspects, integration of AAIs requires significant efforts to define a common policy framework covering the necessary legal and operational practices for all entities involved in the AAI ecosystem, including identity providers, attribute providers, resource providers and federation operators.
The AARC project aims to build on the developments and deployments that have led to the AAI frameworks used to date to deliver a common framework for authentication and authorisation that will allow research communities to share information resources and services easily and effectively across e-Infrastructures in a secure, well-controlled fashion, while at the same time reducing operational burden. AARC brings together different e-Infrastructure providers, as well as libraries and research communities, in order to capture and analyse the requirements for a Pan-European identity federation for researchers, educators and students. This approach ensures user-community engagement, avoids duplication of efforts by reusing existing AAI frameworks, and creates the conditions to enhance these frameworks to address community requirements.
The goal of this document is to collect the needed requirements to enable the design and pilot of an integrated Federated Authentication and Authorization Architecture for e-Infrastructures.
Methodology
Before AARC, several other initiatives have explored the requirements for federated AAI capabilities. The work presented in this document builds upon these efforts in order to capture and analyse today’s requirements for a Pan-European identity federation for researchers, educators and students.
The findings from previous studies provided an insight into the different user communities involved and the current status with respect to the penetration of federated identity management. AARC researchers then collaborated to devise questions that were circulated to many of these communities. It should be noted that the project used a questionnaire (see 0) as part of its methodology in order to gain access to a larger sample of user communities than could be feasibly achieved through direct contact. However, to gather more detailed information about the requirements described in the survey’s responses, a series of interviews were also conducted with a subset of the participating communities. These were held in the form of informal conversations and semi-structured interviews with key users of the selected communities who have an extensive understanding of the needs and issues of their AAI.
More specifically, the methodology used for this deliverable to analyse requirements comprises the following steps:
gathering of initial requirements from a multitude of external sources, including input from previous activities such as the “TERENA AAA Study” and the documents produced by FIM4R,
evaluation, analysis, filtering and refinement of initial requirements based on collected feedback from AARC internal survey and interviews with selected but broad representation of user communities,
harmonisation, classification and ranking of requirements.
The described methodology will also serve as the basis for extracting use cases in a continuous and iterative process the results of which will be recorded on the project’s wiki1. In addition, the information gathered will allow for an assessment of the authentication and authorisation technologies adopted by the user communities. The latter results will be documented in a different report to be shared among AARC partners (MJRA1.1).
Input from stakeholders
Past activities
FIM4R
FIM4R (Federated Identity Management for Research) is an international cross-domain activity which organised a series of workshops with the purpose of discussing and proposing solutions to the problems experienced by research infrastructures that need FIM capabilities in order to operate their facilities and serve their user communities. Through these workshops, FIM4R produced a set of common requirements and recommendations for the uptake of FIM, which are documented in [FIM4R2012]. This report considers information originating from a diverse selection of research communities:
High Energy Physics, represented by the WLCG collaboration and CERN
Life Sciences, represented by the ELIXIR ESFRI
Humanities, including infrastructure projects: CLARIN ESFRI, DARIAH ESFRI, CESSDA ESFRI, DASISH, and Project Bamboo
European Neutron and Photon Facilities
Climate Science, including projects CEMS, ESGF and CMIP5, Metafor, IS-ENES, CORDEX, Exarch, Climate Data Exchange, GENESI-DEC.
After initially extracting the requirements specific to each community, FIM4R summarised the common requirements that emerged, assigning them two levels of priority: High and Medium. A list of the identified requirements grouped by priority level is presented below:
High Priority FIM Requirements
- User friendliness: The Federated AAI framework should provide simple and intuitive tools that
- are able to address the needs of users with different levels of ICT literacy.
- Homeless users: Users without a federated institutional IdP should be supported. Such users include citizen scientists and researchers without formal association to research laboratories or universities.
- Browser & non-browser based federated access: FIM capabilities are required for a wide range of applications used by the communities, regardless of whether a web browser front-end is available or not.
- Implementations based on open standards and sustainable with compatible licenses: Open and standards-based AAI technologies should be used by the different communities to allow for interoperability by means of suitable translation services.
- Different Levels of Assurance with provenance: Credentials issued under different policies and procedures will need to include the provenance of the level under which they were issued.
- Authorisation under community and/or facility control: Communities should be able to manage the assignment of attributes to their members for authorisation purposes.
- Attributes must be able to cross national borders: The different data protection policies need to be considered for flows of identity attributes between countries.
Medium Priority FIM Requirements
- Bridging communities: Efficient identity attribute mapping mechanisms are required in the case of communities in different research fields, commercial sections and social groupings.
- Multiple technologies with translators including dynamic issue of credentials: Translators between different technologies will be required to allow credentials from one community to be used by services offered by another community and this translation will often need to take place in a dynamic fashion.
- Well-defined semantically harmonised attributes: Authorisation across the service providers residing in different communities requires open and/or standardised identity attributes.
- Flexible and scalable IdP attribute release policy: Given that bilateral negotiations between all SPs and all IdPs is not a scalable solution, a flexible negotiation mechanism is required to govern the release of identity attributes.
- Attribute aggregation: Appropriate mechanisms will be required to support the aggregation of attributes originating from different sources of authority, including federated IdPs and community-based attribute authorities.
- Privacy and data protection to be addressed with community-wide individual identities: The release of personal data should be managed in a way that satisfies all legal requirements for the protection of user privacy.
FIM4R also analyses several operational aspects that are important for the adoption of federated identity management in the services of a production infrastructure. These aspects include risk analysis, traceability, incident response and easy integration with existing SPs.
FIM4R spawned the Federated Identity Management Interest Group (FIMig) at RDA (Research Data Alliance) to align their requirements with the works undertaken in RDA and to increase the co-operation with Non-European activities that had limited representation in the FIM4R workshops.
Terena AAA Study
In 2012, TERENA (now GÉANT Association) published a study on AAI Platforms for Scientific Data in Europe. This study was led by TERENA and carried out by a consortium composed of four partners and a number of external experts.
The study was commissioned to address the recommendations of the High-Level Expert Group on Scientific Data that indicated that an authentication and authorisation system should be set up by integrating existing AAA infrastructures in order to allow distributed and collaborative AAA for scientific data.
The goal of the study was to evaluate the feasibility of delivering an integrated Authentication and Authorisation (and, possibly, accounting) Infrastructure (AAI) to help the emergence of a robust platform (Scientific Data Infrastructure (SDI) for access to and preservation of scientific information.
The targeted actors in the study were the research and education communities, information service providers (data centres, libraries) and e-Infrastructure providers.
The output of the study consisted of a set of recommendations (of technical, policy, funding and legal nature) for the delivery of an integrated AAI to be used for SDI. Some of these recommendations confirmed the results of the FIM4R study.
The recommendations highlight the following priorities:
The general assumption confirmed by this study is that an AAI for SDI should be built on standard technologies, using mechanisms to translate between various authentication and authorisation technologies, and that federated access plays an important role
To fully benefit from federated access, more funding is needed to improve the reach of national identity federations in research and education
Further research is needed to enhance authorisation and accounting mechanisms
A common policy and trust framework for identity management is needed, as well as clarity on data protection laws – these should be coordinated at a European level.
The tables below provide a more detailed description of these technical and policy recommendations, many of which confirmed the findings of the FIM4R document.
| Technical Recommendations | Action Required | Main Stakeholder(s) |
|---|---|---|
Support the use and standardisation of federated technologies for network, service and application access across Europ. | Specific support should be given to inter-federation to achieve cross- disciplinary and cross-boundary requirements and to create a common, but distributed AAI for research and education. | e-Infrastructures, national federations and international research collaborations. |
Enhance existing AAIs to address the demand of the research communities to access different type of services in a secure way. | a. Enable federated AAI for mobile access and mobile devices. b. Support for federated access for non-web application c. Develop security translation services to enable the interoperability of different AAIs d. Provide guest identity providers for users that cannot rely on institutional IdPs e. Enable the support of persistent identifiers g. Support social identities and groups as both identity providers and attribute providers for the SDI. | National identity federations, eduGAIN and international research collaborations. |
| Enhance authorisation in inter-federation scenarios by providing support for distributed attribute management. | Enhance authorisation in inter-federation scenarios by providing support for distributed attribute management | National identity federations, eduGAIN and international research collaborations. |
| Phase out IP-based authentication in favour of federated acces. | Provide support for those institutions relying on IP-based authentication to migrate to federated acces. | National identity federations, service providers and funding bodies. |
| Facilitate the development of a common policy and trust framework for Identity Management that involves, identity federations, research communities, libraries and data centres. | Use existing frameworks to coordinate the creation of best practices. | e-IRG, REFEDS, IGTF, ESFRI, e-Infrastructures, LIBER and libraries. |
| To expand the coverage of national federation. | Allocate national and international funding to train communities to join federations. | National funding bodies and EC. |
| Implement scalable policy negotiation mechanism. | Define ways to simplify the negotiations of service agreement. | REFEDS, eduGAIN, national federation. |
| Identity federations to harmonise their policie. | Define guidelines to harmonise policy federation. | REFEDS, national federation. |
| Lower the entry level for using a AA. | Consider ways to offer ready to use solutions that hide technical complexity from the user. | e-Infrastructure (AAI) providers and national federation. |
AARC Internal Survey
In addition to the information gathered from external sources, AARC conducted a survey of the communities directly involved in the AARC project with the aim of verifying their requirements to date and determining which issues have been addressed since the FIM4R and TERENA AAAI studies were carried out.
The Survey included ten pan-European Research Communities and Resource Providers. The statistics presented in this section are based on the responses collected.
Out of 10 responders, 8 indicated their community currently had some sort of AAI solution in place. These responders were then asked to rate the level of user experience within their community with their existing AAI solutions (where “0” indicated no experience whatsoever and “3” indicated good experience), to which the average rating response given was “2”. Investigating this question in more detail, it emerged that the communities that used some kind of web-based solution, including FIM, had given a positive usability rating. Certificate-based access to resources, on the other hand, was considered not to be user friendly and to be excessively bureaucratic.
FIM benefit and barriers
100% of the surveyed communities responded in the affirmative when asked whether they saw benefits in Federated Access. Clearly, FIM is viewed as a way forward for enabling access to shared resources. However,severalimpedimentswerealsoidentified.Thelackofadequateinformationabout FIM and the need to improve it was noted as a factor by 75% of respondents. Other barriers were also highlighted, as shown in Figure 1: Perceived barriers to joining a federation. Lack of funding and the excessive bureaucracy when joining a federation were noted as the main barriers, followed by the lack of clarity on benefits within the organisation.
Figure 1: Perceived barriers to joining a federation
The survey went on to investigate how the level of penetration of AAI solutions in the community could be improved. Respondents were asked to indicate what kind of information should be provided to facilitate this. Figure 2 shows their responses, with "Online resources" being most often mentioned followed by “Materials for management and decision makers”. The findings of the survey have been passed on to the AARC NA2 activity.
Figure 2: Materials needed to facilitate AAI penetration in your community
FIM technology
The survey next focused on the technical solutions already adopted by communities. Figure 3 shows responses with regard to protocols in use. From the survey it is clear that SAML2-based solutions are already popular. Several X509 and OAuth based solutions are in place or being deployed (especially for OAuth).
Figure 3: Technical solution adopted
The scale of deployments varied considerably between the participants of the survey. Table 3 shows the reported number of users and connected identity providers. Zeroes indicate there was no production level service in use, whereas a dash shows that the communities in question provided no data on connected IdPs and users. In some of the responses it is not clear whether the numbers refer to actual or potential IdPs and users. This will be clarified in the interviews that are going to follow in the period until the end of the first project year.
| Community | Number of IdPs | Number of users |
|---|---|---|
BioVEL | 0 | - |
Clarin | 1000 | 100000 |
MoBrain (EGI Competence Centre) | - | - |
D4Science | 1 | - |
DARIAH | 30 | 3000 |
EISCAT | 0 | 0 |
EUDAT | 0 | 0 |
FMI | 98 | 1600 |
PSNC | 2 | 750 |
Umbrella | - | 700 |
Community requirements
The respondents were also asked to indicate their high-level requirements for Federated AAI. Some common elements were evaluated, including types of Identity Providers, preferred authentication technology, and other high-level requirements.
Figure 4 shows the Identity Providers used by respondents, with home institutions clearly preferred for authentication, though it is also noted that many VO participants still remain outside of Academia.
Figure 4: Type of Identity Providers used by community
When communities were asked their preferred Authentication method, web-based and non-web-based authentication scored equally, as shown in Figure 5. This clearly confirms that web SSO alone will not solve the AAI challenge for VOs.
Figure 5: Preferred authentication technology
Other high-level requirements we also queried, including the need for scalable IdP attribute release, the need for persistent identifiers, support for different levels of assurance and the need for community- level authorization. Communities were also asked if currently the identity federations provide sufficient coverage in terms of users. Results are presented in Figure 6.
Figure 6: High-level requirements of research communities.
Persistent identifiers, multiple levels of assurance and the ability to perform community-level authorization were indicated as important by most communities. While (lack of) attribute release was seen as an impediment, some also considered the situation to be workable.
Most communities reported that coverage from Identity federations for their collaboration is poor. Less than half of the communities reported that this coverage is sufficient for their activities. One community
noted, on the success of eduGAIN: "In eduGAIN, countries with Opt-In are not well covered and are not sustainable in this respect. Moreover, 6 countries are behind > 1000 IdPs in eduGAIN (July, 2015) leaving ca 300 to the rest of the world, so it would be nice to see IdP coverage in eduGAIN improve."
AARC interviews
Requirements analysis
Conclusions
In this document requirements were investigated from many sources in different projects, from different disciplines, and using documents written over a period of several years, including the surveys produced and collected in the first 6 months of the project. Out of these requirements, 25 high-level items were identified and categorised using the FURPS+3 method. This classification of requirements is illustrated in Figure 8, where it can be seen that the majority of them are non-functional. This supports our initial assumption that, in addition to functional gaps, federated AAI requires significant efforts towards the definition of common policies covering the necessary legal and operational practices for all entities involved in the AAI ecosystem.
The requirements related to policies and best practices are illustrated in Figure 10, where they are ranked based on the frequency of occurrence in various sources. In the figure, the information is presented in such a way as to highlight the possible areas that should be given the greatest attention within the AARC project. For example, sufficient attribute release and policy harmonization are clearly of interest to most of the communities participating in the requirement gathering process. Similarly, regarding the identified architectural and technical requirements, Figure 11 shows that support for different LoA and community-based authorization are required by the majority of the communities.
AARC will continue the discussion with the project stakeholders in order to understand and evaluate their requirements. Over the next months, until the end of the first project year (April 2016), we are going to work on prioritizing these requirements taking into account actual use cases, their horizontal applicability and their technical feasibility. The outcome of that work along with the information included in this document will be important inputs for the first internal draft version of the high-level AAI blueprint architecture, which is planned for the November 2015.
Complementary to this work, in MJRA1.1 "Existing AAI and available technologies for federated access", we will capture and analyse the tools and technologies which are available today for building federated AAIs, and will identify any technology gaps that might exist. This document will be available at the end of 2015.