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.
| Table of Contents | ||
|---|---|---|
|
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.
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.
Analysis of user community and service provider requirements in PDF