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 minLevel 2
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
In order to further understand AAI requirements, a series of interviews with selected user communities was conducted in September 2015 via teleconference. These interviews provided room to discuss and gain a much deeper insight into the communities’ AAI needs and issues. In view of the usefulness of these results, more interviews are scheduled to take place up to the end of JRA1.1. A summary of the findings from the interviews is presented hereafter.
EGI
EGI is a highly distributed, multi-disciplinary resource infrastructure, integrating more than 300 resource centres (service providers) and almost 20,000 users grouped in 200 user communities called Virtual Organizations (VO). Currently, authentication and authorisation within EGI is enabled through a X.509-based Public Key Infrastructure (PKIX), based on the Interoperable Global Trust Federation (IGTF) and EUGridPMA Certification Authorities federation.
The EGI requirements have been discussed with Peter Solagna, Senior Operations Manager at EGI.eu.
Figure 7: Current EGI authentication and authorization workflow
The process to access EGI services, as illustrated in Figure 7, is described below.
The user, shown on the left, obtains a personal certificate from a certification authority recognised by EGI, then adds the information about their VO to the certificate, generating a X.509 proxy. To be able to do this, the user must be authorised by the VO manager (who can be the Principal Investigator of the collaboration) who controls the membership of the VO they are managing.
All the needed information (user identity, VO membership, additional roles and capabilities within their VO) is shipped to the EGI services that use this information to authorize access to the services. Generally, access to services is regulated by VO membership: a service provider supports a number of VOs and users can search for the services enabled for their VO. Finer-grained user authorization is possible but not often applied in view of the scale of the infrastructure. The AuthN/AuthZ process is based on the trust between the CAs’ federation and the service providers’ federation, as well as the trust between the service providers and the user communities (VO).
The key feature for EGI is collaboration. The scale of EGI does not allow having a single entity responsible for the authentication and authorization of the users. Service providers, user communities and identity providers must be able to work together, contributing to the operations of the AAI workflow, to enable the users to access EGI services.
X.509 technology, and in particular X.509 proxy certificates, enables some of the most important capabilities for EGI: scalability, command line access and delegation. The user actions are usually initiated by submitting a request with an attached X.509 proxy certificate. This means that, for example in case of bulk submissions of thousands of computing tasks, the services do not need to contact the IdP or the attribute authority of the users thousands of times, since all the needed information is contained in the proxy certificate. The X.509 credentials work with no issues with command line commands, and the proxy certificate implements a form of delegation (impersonation) that allows a service to perform a defined set of actions on behalf of the user.
From a technical point of view, X.509 authentication has proven to be scalable and to work for almost any use case. However, new user communities prefer to use other technologies for authentication, for example username/password-based authentication.
There is a capillary network of certification authorities and registration authorities, distributed among the EGI partners, which can be contacted by users to obtain a certificate. EGI runs a catch-all CA to support users who – for any reason – cannot access another existing CA.
To bridge different authentication technologies with X.509, the EGI partners and the user communities are deploying science gateways and portals where users can authenticate with username/password, and access the resources through web-based tools and interfaces. The portals are then generating short-lived X.509 credentials that are used to access resources.
The most common mechanism used to bridge between IdPs and X.509 are the robot certificates, which can generate programmatically short-lived X.509 proxy certificates that then can be used to access EGI services. One of the drawbacks of this solution is that the real user identity is hidden behind the robot certificate. To partially address this issue, EGI is implementing an extension of the X.509 proxy certificate that contains an ID that can identify the user if needed. This is particularly useful for accounting purposes and, at the same time, improves the overall security of the implementation.
EGI critical requirements:
- Single sign on. Users should be enabled to use their institutional credentials to access EGI services. One barrier for new users is that they have to obtain a new credential to access the e-infrastructure. In some cases, this is just an inconvenience, yet another credential to manage, but for some users – those outside institutions or the major IdP federations – it may be not possible to obtain such a credential. User friendliness is of course a major feature for any SSO capability.
- Community attributes-based authorization. Community-based authorization has been implemented in EGI from the beginning, and is at the basis of the collaborative nature of EGI. It is fundamental for EGI that every AAI technology and architecture enables the communities to manage the capabilities and the roles of their users, and to let these attributes be used by the services to regulate the authorization. Given the scale of the EGI service, providers cannot implement per-user authorization, but must authorize a user based on the attributes associated to that user.
- Non-web access. EGI services are accessible natively by command line clients, implementing the services’ standard APIs. While there are several options for users to use web-tools to access the resources, authentication must consider both web and non-web access scenarios.
- Delegation. EGI services allow complex workflows, and users often submit thousands of computational tasks that need to access other resources (e.g. storage) on their behalf. The authentication technology must support delegation, either natively or through credential translation to another technology. Without delegation EGI users cannot get the full potential of the services.
- Scalable policies for attribute release. EGI is a highly distributed infrastructure, with hundreds of service providers, hundreds of communities, and tens of thousands of users. In this scenario, it is critical that the policies and the procedures are scalable with the number of actors involved. Attributes are important to reduce the effort for user management falling on the communities or the service providers. If trusted IDPs can release adequate information to the service providers, credentials can be used to access the most complex workflows in the infrastructure without the need for additional vetting of the user, even in a scenario where the IdP releases a minimal set of attributes, policies must scale. For example, services must be able to store and share with other services the unique identifier of the user provided by the IdP. Service provider federations should be seen by the IdPs as trusted entities, and policies, once agreed with the federation, should be valid for all the service providers within the federation.
EGI non-critical requirements:
PID for users. EGI foresees the need for a user unique and persistent identifier. One use case is to map multiple credentials to a single user. A second use case, and in particular for an EGI- specific unique identifier, is to share authorization assertions between EGI services, which may not be possible when using an IdP-provided user UID.
LoA management. EGI supports a very diverse set of use cases. Open data is a typical use case where a very large community of users can access a data set, but there is need for a lightweight authentication, for example to account for the number of actual users using a service. In this example, EGI needs to enable users without the need for ‘expensive’ high assurance credentials. Clearly service providers must be able to extract information about the LoA from the attributes associated to the user identity. LoA definitions should be standard and simple, so as not to over-complicate the service provider’s decision as to whether or not to allow the user task.
Credential translation services. While the plan is to push forward with the direct support of federated identity technologies for the central tools and the new service types, some services, for example those offering HTC resource, will likely continue to use X509 technologies, therefore credentials translation capabilities are necessary to allow users with federated identity credentials to access the full set of EGI services.
How EGI AAI will evolve in the future.
EGI has strong requirements for extending the credential types that can be used to access services, in particular from new communities. Some communities also asked for basic AAI tools not necessarily related to resources access, but to be used for their internal workflows.
EGI is eager to implement and use the outcomes of the AARC project, and at the same time to implement federated AAI where necessary as soon as possible.
The current plan for EGI is to provide an IdP proxy to integrate external IdPs with the EGI services. The IdP proxy will provide the following capabilities:
Integrate new heterogeneous IdP. EGI will integrate in the proxy-IdP the identity provider requested by the (new and existing) communities, making it easier to configure with the EGI service providers. Services will only have to consider the IdP proxy as the source of identity information.
Aggregate attributes provided by community attribute management services. The aggregation makes it easier to configure additional attribute authorities, and at the same time allows EGI to certify authoritative sources of authorization data.
Allow users to use multiple credentials to access EGI resources. The proxy IdP will associate a single UID to multiple credentials, either an EGI UID or an externally provided ibe, to allow services to identify the users if they use credentials.
As previously mentioned, it is a priority for EGI to provide AAI services that are aligned with the AARC architecture and, more in general, with the project recommendation.
ELIXIR
ELIXIR is a Pan-European infrastructure for data storage, management and distribution, which aims to support biological research. ELIXIR resources are available to all life science researchers. An ELIXIR service may comprise a number of individual services provided by more than one institution, potentially geographically dispersed across Europe. However, such a service should be perceived by the end- user as a single service, whereby authentication and authorisation take place only once.
The purpose of the AARC interview with ELIXIR representatives was thus to assess the ELIXIR service requirements for federated AAI, as well as to discuss barriers to its implementation and respective solutions. A list of the collected requirements follows:
- Unique identity: Each ELIXIR identity should represent a single natural person and should be uniquely identified by two independent identifiers:
- a unique, permanent, opaque, non-reassignable ELIXIR identifier, and
- a unique, human-readable, user-defined nickname that may change. In the case where the nickname is updated by the user, the old nickname should not be assigned to other users.
- Up-to-date affiliation information: Each ELIXIR identity can be associated with one or more affiliations, known as home organisations, such as research institutions or private companies. To describe a user's affiliation with their home organisation(s), it is recommended to use one of the predefined values, i.e. faculty, member, or affiliate. The up-to-dateness of the affiliation information should be guaranteed through a verification process recurring every 12 months.
- User-managed identity attributes: A user should be able to self-manage some of their attributes through a web-based UI. Depending on the attribute type, special update procedures should be supported (e.g., to update their email address, users need to demonstrate ownership of the address through a handshake protocol).
- Multiple authentication providers: A user should be able to link one or more external authentication providers to their ELIXIR identity. To link a new authentication provider, the user should first log into the ELIXIR AAI through an existing authentication provider and perform a subsequent login using the new authentication provider. The ELIXIR AAI must provide a web- based self-service management UI for this. The following authentication providers should be supported:
- IdPs managed by the users' home organisations to which ELIXIR AAI connects via the eduGAIN interfederation service or otherwise. Users can use the authentication credentials managed by their home organisation to log in (SAML 2.0 technology)
IdPs managed by common social media providers, such as Google, Linkedin or ORCID. ELIXIR users can register a social identity to log into ELIXIR (typically, OAuth2 technology)
the ELIXIR authentication credential (password) managed by the ELIXIR AAI.
- Level of Assurance: To qualify as an authentication provider, the eduGAIN IdPs must provide sufficient LoA meeting the following requirements:
- The accounts must belong to individual users
- The home organisations must have a standard identity-proofing mechanism for issuing user credentials
The home organisations should either deactivate the account of a departing user or update their affiliation information accordingly.
- Common attribute policy framework: All participating entities in the AAI ecosystem (IdPs, AAs, SPs) should commit to a common policy framework for the processing of personal data. This framework should incorporate at least the GÉANT Data Protection Code of Conduct.
- Step-up authentication: The ELIXIR AAI should provide a step-up authentication service covering both strong identity proofing (face-to-face) and strong authentication (two-factor) at the time of login. For the latter case, the following second-factor authentication mechanisms are suggested:
- SMS-OTP (one-time password delivered to the user’s registered cell phone number)
- a smartphone application (e.g. Tiqr) and
- a hardware token generating one-time passwords, (e.g. Yubikey, a token emulating a keyboard).
In the future, the ELIXIR step-up authentication service should be able to integrate with external strong authentication services, such as government eID or eIDAS.
Groups and roles: Each user can belong to one or more groups. A group member can have arbitrary roles in a given group, such as “member”, “owner”, “secretary” or “chair”. The AAI should provide a web-based service for managing ELIXIR group members and roles. The group owner needs to periodically confirm that the group is still active. Integration of the ELIXIR group management service with external group management systems (e.g. VOOT or SCIM technology) is also foreseen.
Distributed access control: ELIXIR AAI requires a distributed interface for delivering access rights from the system component where they are granted and archived (Policy Decision Point - PDP) to the system component that enforces access control (Policy Enforcement Point - PEP). Revocation of access rights distributed across multiple PEPs should be supported in a timely fashion.
Browser & non-browser based federated access: The ELIXIR services that require federated access can be either web-based or non-web-based, e.g., SSH, FTP, etc.
EUDAT
The B2ACCESS service is a bridge between technologies. It is based on Unity software with the addition of the CA Server from the Contrail project. Unity is an IdP/SP proxy, which also works as attribute provider, asking the users to add the missing attributes. In the current implementation of B2ACCESS, EUDAT can add extra attributes to the users, but the users have no control over the EUDAT-specified attributes. B2ACCESS also has support for social IdPs the policy says that depending on what users authenticate with, they get assigned a different LoA that gives them different access rights. B2ACCESS will go in production by the end of September 2015. EUDAT has already registered B2ACCES with the DFN-AAI and the CLARIN SP Federation.
Account linking is not yet available in Unity. If this functionality becomes available from Unity, then EUDAT will consider it.
At the time Unity was chosen as the preferred IdM for EUDAT, it was the only solution that supported bridging between different authentication technologies. Unity is an open source middleware, developed in Poland and currently well supported. Unity is used in Unicore and by the Human Brain Project. Unity also gives control deciding what information is sent to different services, giving the possibility to delegate different sets of attributes to different services. Attribute release happens after user consent.
Regarding eduGAIN, EUDAT does not see any technical issues that might hinder its future integration. There are some aspects to clarify in the policy space, especially how to deal with the GÉANT Data Protection Code of Conduct, as B2ACCESS will effectively act as a proxy for a number of SPs, which will be hidden behind it. Jens Jensen is dealing with the Code of Conduct from the EUDAT side.
EUDAT is interested in having B2ACCESS join eduGAIN as an SP and not as an IdP. As mentioned earlier, B2ACCESS has joined the DFN-AAI federation, so it can already consume credentials coming from the German federation.
EUDAT sees a role for AARC to harmonise the attributes, but it was clarified that the semantic harmonisation is a lost battle and that AARC will not work to that extent. However, some work on the harmonisation of which attributes should be released by the IdPs and which could be offloaded to attribute providers is in scope. B2ACCESS was already designed with the notion that a core set of attributes will be retrieved from the institutional IdPs as well as a richer set of attributes from community-specific attribute providers. Given the low number of attribute provider services operated by the communities, EUDAT could add and manage attributes in B2ACCESS for the communities it supports.
- Requirement: There should be harmonization of the attributes that will be used by the scientific communities for cross e-Infrastructure collaboration.
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.