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:

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.

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 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.

Support the use and standardisation of federated technologies for network, service and application access across Europ.

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

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.

Image Removed

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.

Image Removed

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).

Image Removed

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 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.

Image Removed

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.

Image Removed

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.

Image Removed

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.

Image Removed

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:

1.  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.  
2. 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. 
3. 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.   
4. 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.
5. 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:

1. 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.

2. 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.

3. 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.

• 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.

Requirements analysis

Conclusions