This page contains the details of the surveys and interviews that are being performed by JRA1.1 with user communities, research infrastructures, e-infrastructures, and other stakeholders of the AARC project.
Surveys
BioVel
BioVel supports researchers in the domain of ecology, biodiversity and ecosystems science.
The same requirements reported by BioVel in this document are also more in general applicable to the majority of the environmental sciences.
The use case of BioVel can be described with the following two trust relations:
- Relation between the end-users (for example the researcher) and service providers providing specialized domain specific data and analytical services.
- Relation between service providers mentioned in (a) above and the multi domain e-infrastructure providers like EGI.eu, EUDAT, PRACE, as well as commercial providers as AWS.
The first trust relation has to be secured (typically) by a username/password oriented SSO authentication and authorization mechanism. Service providers are unrelated to one another so a mechanism like that used with e-journals access has to be deployed i.e., persistence of sign-on available to multiple Service Providers for a timed period. Additionally, the persistent sign-on has to be capable of being delegated (automatically) to workflows / agents acting on the users’ behalf at the machine-to-machine level. Such workflows/agents may initiate transactions to multiple SPs in sequence.
The second trust relation between each community SP and a non community-specific service provider(s) is unique to each SP/FP pairing. There is no requirement for persistence across pairings.
The trust model, as has been initially described in the section 2.1.1 BioVel users need to access data repositories to search, access and upload data, and to access computing services to elaborate the data and then store back the results of their analysis. The BioVel community is leveraging on both internal service providers, for example for the data repositories, and on the European multi disciplinary e-infrastructures, for example to access computing capacity.
The community is accessing a number of heterogeneous service providers, single sign on (SSO) capabilities are fundamental to enable scalable workflows, together with an uniform authorization infrastructure. The workflows requires also to delegate the authorization of one user to a service to access data or perform actions on the user’s behalf.
BioVel foresee also to interact with citizen scientist, therefore some use cases may require the integration with low level of assurance credentials such as social media credentials.
AAI technologies
The community is still at the beginning of adopting federated identity/authorization solutions. Working closely with EGI and other service providers using X509 certificates as an authentication mean, the community is relying on the IGTF certification authorities federation. The overhead of obtaining and maintaining a personal certificate could though be seen as an excessive overhead by many new users. This solution is also not feasible for homeless users.
Penetration of federated identity management
Although BioVel management understands the need for federated identity management, the community has limited experience with federated AAI solutions. The research community has not already an AAI solution for the community in place, and therefore there is still need to acquire the needed knowledge.
Most of the users have credentials from their institutional IdPs, but the percentage of these federated in eduGAIN or other federations has not been assessed.
Currently the AAI federations, and AAI coordination activities, have been focusing on the end-user to Service provider direct interaction, in other words enabling simple SSO capabilities on the services. This approach is necessary but not sufficient to fulfil (probably) the BioVel requirements, which envisage a more complex relation between service providers, which need to interact to enable the workflows of the community. Delegation and uniform authorization across service providers will be fundamental bricks of the BioVel infrastructure.
The main barrier for BioVel is the lack of information and knowledge, and the community would benefit from a reliable and organized source of information, in form of online documentation, which can be consulted to take informed decision. Possibly integrate with trainings. Currently the information is very scattered and it is challenging to get the full picture that includes the IdPs documentation, the IdPs federations and the SP federations requirements and best practices.
The training and the documentation should be integrated with a support service and troubleshooting tools, to maximise the efficiency of the federations.
DARIAH
DARIAH-EU is the "Digital Research Infrastructure for the Arts and Humanities"; which legal form is an ERIC (European Research Infrastructure Consortium). The blocks composing the research infrastructure build on national initiatives.
Digital research methods are a fundamental part of the mainstream of humanities, arts and social sciences research. The digital arts and humanities are at a critical point in the transition from a specialty area to a full-fledged community with a common set of methods, sources of evidence and infrastructure. All of these are necessary for achieving academic and data driven scientific recognition. Information and data- intensive, distributed, collaborative and multidisciplinary research is now the norm in many scientific areas. The goal of DARIAH is to be an infrastructure that would ensure that the state-of-the-art of these collaborations is preserved and integrated, and that common best practices and methodological and technological standards are followed also in the field of AAI.
Currently the DARIAH community has almost 3000 active users.
Adopted Authentication & Authorisation Technologies
The DARIAH infrastructure blocks are built within national initiatives. AAI is based on SAML authentication combined with attribute aggregation. A DARIAH homeless account is available.
Personal data of users are stored in a central clustered LDAP server. Group memberships that provide access to services and Wiki spaces, as well as the user data are managed via a web-based administration portal. Attribute queries, as defined in SAML and implemented in Shibboleth, are used to aggregate information from the campus IdP and the DARIAH Attribute Authority implemented in the DARIAH IdP. A registration mechanism based on a central DARIAH SP ensures that all personal data that are are needed, but not provided by the Campus IdPs, are collected as self-asserted data from the user. The DARIAH IdP thus acts as an IdP-AA, but not as an SP, i.e. it is not a proxy.
Penetration of federated identity management
DFN-AAI/eduGAIN is feasible and being used by a number of users. However, there are lots of user accounts in the homeless IdP LDAP server for users that either have no federated IdP or with an IdP that does not release ePPN.
And there is some number of users that simply are aware that "a DARIAH account" can be their institutional account, who even do not try to log in via AAI, going for the homeless user option.
Authentication and authorization technologies
DARIAH user authentication is leveraging on the institutional IdP of their users, part of national federations such as eduGAIN federations, and the catch-all community IdP to host homeless users, who are a consistent fraction of the community user-base.
DARIAH is interested in SAML2, and OpenID/OAuth2 technologies, plus X509 credentials for legacy reasons.
It is important for the community that the authentication technologies are as much user friendly as possible. For the community is also important the support for delegation and non-web access, on top of the normal web accessible services.
Attribute release policies
DARIAH users will use either homeless IdP or one and only one campus IdP, with authorization and additional attributes provided by the VO via SAML attribute queries.
Having campus IdPs releasing ePPN is critical for DARIAH AAI. The community hasbeen working with a number of initiatives (notably CoCo) to improve the current situation. Thus more efforts should be made to scalably a) increase the number of such IdPs and b) find some way for to know whether a given IdP will release ePPN to DARIAH services (e.g. by respective entity categories of IdPs), still before the first user is affected and perhaps disappointed.
As an attempt to solve the, DARIAH decided that a) SPs must express eduPersonPrincipalName as required (via SAML metadata) and b) users' campus IdPs should honor this If not user will have to aplly for An DARIAH homeless account.
LoA management
DARIAH services are used for research and educational purposes only.
Therefore users are classified as : belonging to some research institution (access via eduGAIN qualifies for this, or an institutional e-mail address), or so-called citizen researchers.
Accounts that fall into the latter category are checked manually, i.e. mail communication to make sure that user is involved in research. Any institution that is not yet known (mail domains are stored) is checked manually as well, in order to be sorted into one of the two categories.
After this manual check there is no need for further information about differentiated LoA.
Attribute management and community managed authorization
The only user identifier used is ePPN, DARIAH connects user’s ePPNs and accounts together in the DARIAH portal.
The homeless IdP delivers via SAML attribute queries keyed by the ePPN the following attributes:
- any needed personal attributes the campus IdP did not provide, e.g. mail
- the accepted terms of use for the service in question
- authorization attributes, i.e. the names of the authorization groups the user is member of
Authorization group membership is managed manually via the administration portal in a distributed way, i.e. by the administrators of DARIAH countries, organizations, and projects.
DARIAH is therefore using community attributes to authorize access to internal services and potentially to all the services supporting the community.
EISCAT
EISCAT, the European Incoherent Scatter Scientific Association, is established to conduct research on the lower, middle and upper atmosphere and ionosphere using the incoherent scatter radar technique.
EISCAT Scientific Association is funded by six research councils. The operations of the facilities are divided in two halves, one common programme for joint activities, and the other is distributed among the associates according to funding.
The lower levels of data gathered are available only to the associate countries, and in the non-common each associates have exclusive rights for one year. In recent years, a programme for smaller organisations have been opened to operate the facilities at relative small costs. These affiliate organisations have the right to access data for one year after the date of observations.
Access control of this has so far been based on IP addresses, but with the inclusion of affiliates this becomes more and more complicated. Also, the logging of who downloads data is not done, meaning there is no way of communicating to the users any new information of problems with the data they have taken. Also, for the reporting to the owners, there is no information taken for what kind of study the data has been downloaded.
The use case here, would be a good way for authentication of who and possibly why they download data. An 'EISCAT' certificate for users, including who, why, when, how the user will handle the data. One could think of different levels of the certificate for different levels of data.
Trust models and workflows
The main use case for authentication and authorization in EISCAT is to grant access to datasets to the institutions/users who are eligible to download the data. Federated AAI could also make easier the accounting for the data usage.
The control over the access to the datasets have been done, so far, using the IP address of the client. But with the extensions of the use base, including additional affiliates, service providers will need to adopt a more sophisticated authorization mechanisms, with a user-by-user granularity.
Also, the logging of who downloads data is not done, meaning there is no way of communicate to the users any new information of problems with the data they have taken. Also, for the reporting to the owners, there is no information taken for what kind of study the data has been downloaded.
The use case here, would be a good way for authentication of who and possibly why they download data. An 'EISCAT' certificate for users, including who, why, when, how the user will handle the data. One could think of different levels of the certificate for different levels of data.
Currently EISCAT is not using AAI solutions directly integrated with the services.
Penetration of federated identity management
In general the EISCAT community lacks information about federated identity management.
Photon and Neutron community (Umbrella)
The Umbrella is an identity system designed by the European Photon and Neutron source facilities (PaNs’). It aims to make life easier and science more productive both for the facilities and their users. The Umbrella first of all provides any PaN-user (and effectively anyone interested in scientific discovery) with a unique identity, the UmbrellaID. Equipped with such an ID a user can virtually access the facilities with a single sign-on. Since the same Identity is known at each of the facilities, a user can more simply access or share data, manage administrative processes or make use of services and infrastructures provided by the PaNs’. The Umbrella is a joint project of the PaNs’ and other facilities with similar needs for an Identity Management System. The joint nature of this undertaking is the major benefit for the facilities. It permits to share the efforts for developing and maintaining the Umbrella system. Services offered by one of the facilities can be used by any of the users, which allows sharing of services within the Umbrella federation, which not only reduces the overall maintenance efforts but also leads to a richer eco-system of services for the user communities.
Future user operation at large scale facilities enforces user needs which are asking for a unique persistent user identification to have unified access to the following functionalities: a) 40% of the users do experiments at different facilities and need transfacility access, b) need for access to and management of experimental data, c) online entry mode: remote experiment access, d) access to efficient data analysis tools, e) remote file access, f) minimal administration load for users.
Umbrella is part of several FP7 projects namely: EuroFEL- ESFRI project Free Electron Lasers of Europe, PaNData-Europe & PaNData ODI- FP7 projects, CRISP – Cluster project of different ESFRI projects, CALIPSO – I3 synchrotron community, NMI3 - I3 neutron community, BioStruct-X –structural biology with synchrtron radiation
Adopted Authentication & Authorisation Technologies
The photon and neutron community is using the Umbrella infrastructure for authorization. The technologies relevant for the community are SAML2 and X509 certificates.
Umbrella users are using credentials from their institutional IdPs and the federation in eduGAIN is an added value, alternatively users who cannot access to a federated IdP can use the catch-all IdP provided by Umbrella itself.
For the photon and neutron use cases AAI must support: easy single sign on solution, web based and non-web applications, delegation.
Attribute release policies
Not relevant.
LoA management
LoA management is relevant for the Umbrella use case.
Attribute management and community managed authorization
The community has already an unique identifier for the users. This is provided by the Umbrella infrastructure, since this has been a very important requirement for the community use case from the beginning.
Authorization based on community attributes is less relevant for the photon and neutron use case, since the authorization is entirely regulated by the service providers who enable users to access their services.
ELIXIR
ELIXIR is building a sustainable European infrastructure for storing, analyzing and sharing biological data , supporting life science research and its translation to medicine, agriculture, bioindustries and society. ELIXIR unites Europe’s leading life science organisations in managing and safeguarding the massive amounts of data being generated every day by publicly funded research. It is a pan-European research infrastructure for biological information.
The infrastructure is organized in vertical platforms, one of which is the ELIXIR compute platform. The authentication and authorization related infrastructure (“AAI”) is part of that platform and will provide user identity and access management services for the ELIXIR services (“Relying services”).
Actors in the ELIXIR AAI are currently natural persons. The ELIXIR AAI can be later extended to cover also machine accounts (e.g. servers and portals
ELIXIR AAI will be deployed gradually in the ELIXIR EXCELERATE project starting in September 2015.
Trust models and workflows
The overall ELIXIR architecture is split into three main layers. The bottom layer comprises external authentication providers and serves as a source of identities to the middle layer, i.e. the ELIXIR AAI layer. More specifically, the ELIXIR AAI layer consists of the ELIXIR Directory as a main storage of user data, related services to manage the user data, and services to authenticate the user. The upper layer is composed of relying services for the ELIXIR users. Those relying services can utilise data from the ELIXIR directory. A brief overview of each component follows.
External authentication providers authenticate an end-user and deliver their authenticated (external) identity to the ELIXIR AAI. ELIXIR supports both Home IdPs (e.g. via eduGAIN inter-federation service) and Common IdPs (Google, LinkedIn and ORCID).
The ELIXIR Proxy IdP is an authentication proxy that authenticates an end-user using an external IdP or their internal ELIXIR password (if they don’t have an external identity), and relays the authenticated identity and associated attributes to the Relying services. The ELIXIR Proxy only passes authenticated users’ attributes to the Relying services for authorisation. Associated with the ELIXIR Proxy IdP there is also a service where an end-user can consolidate his/her external identities and the ELIXIR identity, by logging in using the ELIXIR password and/or two or more external IdPs consecutively. The ELIXIR Proxy IdP can also support step-up authentication or credential translation.
The ELIXIR Directory is a central storage which stores identity and attribute information on each ELIXIR user. ELIXIR users can use the attribute self-management service where they can self-manage some of their own attributes (such as preferred language and ELIXIR password), register other identifiers (ORCID, social ID), change their ELIXIR nickname associated to the attributes in the ELIXIR Directory
ELIXIR must ensure to provide some of its services only to the users with an affiliation with academic institution. The ELIXIR AAI will provide a bona fide based status application for bioinformatics researchers, so that the community can vouch for them.
The ELIXIR group management puts strong emphasis on delegation of rights. Group managers can add users to groups via invitation, directly and, in the future, by importing group information from external systems. All group information is exposed to the ELIXIR Directory.
The Dataset authorisation management component is used by ELIXIR users where they can apply for, and dataset owners approve, access rights to datasets. The access rights are exported to the ELIXIR Directory and/or directly to the Relying service that enforces the access rights.
CLARIN
CLARIN is the Common Language Resources and Technology Infrastructure, which aims to provide easy and sustainable access for scholars in the humanities and social sciences to digital language data, and advanced tools to discover, explore, exploit, annotate, analyse or combine them, wherever they are located. CLARIN is building a networked federation of language data repositories, service centres and centres of expertise, with single sign-on access for all members of the academic community in all participating countries.
At the moment, the CLARIN infrastructure is still under construction, but a growing number of participating centres are already offering access services to data, tools and expertise. The goal is to facilitate access to restricted language resources available within CLARIN.
Thus, rather than requiring academic users to register a new username and password for each individual web application, users should be able to login with their existing institutional credentials by leveraging on IdP federations.
Trust models and workflows
CLARIN established a task force for the AAI integration in 2013, and the community is deploying AAI integrated solutions. In most countries the IdP systems of the universities and other research institutions offer a high level of traceability of users which is very relevant for allowing access to restricted corpora.
Another obvious benefit is the single sign on, lack of local accounts, increasing password security for the users and making user management easier for service providers.
CLARIN is following actively developments in the AAI field e.g., by establishing and maintaining CLARIN Service Provider Federation.
The CLARIN infrastructure includes about 1000 SPs and IdPs from 220 institutions in 33 countries. Potentially the user base could be 100.000 users (students and researchers of humanities).
For homeless users CLARIN has deployed a community IdP.
In general the experience of CLARIN with FIM is Good within a National Federation, limited in trans national federations (IdP/SPs do not trust each other, insufficient attribute release, no description of the participants).
Most IdPs offer decent login pages, SAML error messages are often very cryptic and give the wrong impression on what side (client or server) the root cause of the problem is, and the services and tools are not implemented to deal in a transparent way with missing attributes.
Adopted Authentication & Authorisation Technologies
CLARIN users are using, or will use, both their institutional credentials federated and not federated in national federations. Plus the CLARIN catch-all IdP, in order – if possible – to avoid the use of social credentials.
CLARIN use cases involves both web-based and non-web based access to services, and also delegation capabilities, which are being currently tested.
Training on how to deal with the shortcomings of FIM would be helpful: SAML error messages, testing connections, how to request attributes in foreign federations. CLARIN addresses some of the issues via the Service Provider Federation. We also attempt to address these issues ourselves, but most of them are generic FIM issues.
There should be more information for IdP operators on how SPs use them and what problems they have to solve.
Attribute release policies
The CLARIN use cases would benefit by scalable policies for attribute release, this is one of the main issue while integrating new IdP with the research infrastructure. One example of actions towards this direction is the GEANT Data Protection Code of Conduct, which is a requirement to become a CLARIN B centre.
LoA management
For CLARIN LoA management is relevant Yes, LoA is highly relevant: We would like to be able to trace users back to real persons and also have reliable user data to determine the user’s status (for example if they are students or staff).
Attribute management and community managed authorization
Missing attributes not released by the IdPs are handled case-by-case. In the worst case via the homeless IdP. A dedicated project Attribute Authority is in testing.
The CLARIN Service Provider Federation solves the necessary coverage for our project, although even then limited attribute release or complex SP acceptance policies make IdP-SP interoperability difficult in some countries. 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.
EGI
Trust models and workflows
EGI is a resource infrastructure. The main goal is to enable users to access the distributed infrastructures.
The user obtains a personal certificate from a certification authority recognized by EGI, then the user adds the information about their VO to the certificate generating a X509 proxy. To be able to do so the user must be authorized by the VO manager, to simplify the PI of their collaboration, who controls the membership of the VO they are managing.
All the needed information (user identity, Vo memnership, additional roles and capabilities within their VO) are shipped to the EGI services that use these information to authorize the 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 since the scale of the infrastructure. The AuthN/AuthZ process is based on the trust between CAs federation and the service providers federation, plus the trust between the service providers and the user communities (VO).
X509 authentication has proven to be scalable and to work for almost any use case, from a technical point of view. New user communities prefer to use other technologies for the authentication, for example username/password based authentication.
Adopted Authentication & Authorisation Technologies
EGI is a highly distributed infrastructure, multi-disciplinary, 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 X509-based Public Key Infrastructure (PKIX), based on the Interoperable Global Trust Federation (IGTF) and EUGridPMA Certification Authorities federation.
X509 technology, and in paritcular X509 proxies, 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 attached an X509 proxy, this means that in case of bulk submissions of - as an example - thousands of computing tasks, the services do not need to contact the IdP or the attribute authority of the users thousands times, since all the needed information are in the proxy. The X509 credentials work with no issues with command line commands, and the proxy implement 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, X509 authentication has proven to be scalable and to work for almost any use case. However, new user communities prefer to use other technologies for the authentication, for example username/password based authentication.
There is a capillar 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 an existing CA.
To bridge different authentication technologies with X509, 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 X509 credentials that are used to access resources.
The most common mechanism used to bridge between IdPs and X509 are the robot certificates, which can generate programmatically short lived X509 proxies that are 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 X509 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.
Penetration of federated identity management
EGI users are mostly using credentials released by the IGTF federation. the X509 technology is fulfilling the diverse use cases of the EGI community. Never the less EGI also has many use cases of users using federated identities, there is not direct integration with the EGI resources, but science gateways and other web user interfaces have been successfully integrated with eduGAIN federated IdPs or in general with other non-IGTF IdPs.
In summary at the moment of writing EGI users can use - if needed - credentials from federation different from IGTF, but not being directly integrated in the resources, this feature must be implemented differently for every use case.
EGI strategy is to push forward the integration with federated identity providers directly in the services. The expectations are to have direct SSO support for the operational tools that enable federation and cloud services. HTC services will likely leverage on translation mechanisms to X509.
To implement this integration, a uniform policy of attribute release and automatic management of the Level of Assurance (LoA) would be beneficial.
Authentication and authorization technologies
EGI authentication is based on X509 certificates, released by the IGTF federation. From a technical point of view X509 credentials satisfy most of the requirements of the EGI infrastructure.
Authorization on EGI services is mostly regulated by the membership to a virtual organization (VO). Services support VOs, and give access to the resources to the members of the VO. Finer levels of granulaity are possible with user groupings or roles within the VO. All these information - which are in fact community attributes - are added as extensions to the proxy certificate by the VOMS service (Virtual Organization Management Service). VOMS allows the VO Managers, the community responsible, to manage autonomously user membership and the other attributes. In this way EGI service providers delegate authorization to the communities.
Attribute release policies
EGI is a highly distributed infrastructure, whith hundreds of service providers, hundreds of communities, and tens of thousands users. In this scenario 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 on the communities or the service providers. If trusted IDPs can release easily information to the service providers, the credentials can be used to access the most complex workflows in the infrastructure without the need of additional vetting of the user identity.
But 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 to 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, once policies are agreed with the federation should be valid for all the service providers within the federation.
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 to account – for example – the number of connections to 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, not to over-complicate the service provider decision to allow, or not allow, the user task.
Attribute management and community managed authorization
EGI infrastructure is already consuming community-provided information for the authorization of users on the services. Currently the services that allow research communities to manage their attributes are based on X509 certificates. It is critical that integrating with multiple authentication technologies, EGI services are able to both consume attributes from the attributes management services already in use by the communities and offer to the users tools that can be used with their institutional credentials.
Community attributes are also important to integrate the missing information not provided by the IdPs.
The attributes associated with the user identity are not only used to authorize access to the resources (cloud, storage or HTC), but also to identify the user’s role in the community, and authorize privileged access to the Operational Tools.
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 between EGI services authorization assertions which may not be possible when using an IDP-provided user UID.