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.

...

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.

EUDAT

Trust models and workflows

Federated access has been one of the goals from the beginning of the EUDAT project. EUDAT infrastructure is designing a new service called B2ACCESS to enable the integration of federated IdP with the EUDAT services. The use cases for this service are:

• Integrating new IdPs and enabling SSO for the users using credentials they already own
• Providing an EUDAT unique identifier for the users
• Providing additional attributes associated to the user identity
• Providing catch-all IdP for homeless users

This solution may support also non federated IdPs, nevertheless it would benefit from federated identity management relying on the LoA and the other best practices implemented in a federation.

As technical solution for B2ACCESS EUDAT is deploying unity-idm.

The level of information available is different in each of the communities and needs to be tackled case by case as more and more communities join the EUDAT infrastructure.

In general the EUDAT experience with AAI solutions is good both in terms of usability and quality delivered. The technologies currently enabled in EUDAT are X509 certificates, SAML2 and OpenID Connect/OAuth2

B2ACCESS is not yet integrated in eduGAIN, but this is high in the list of priorities, currently it is under testing with an handful of IdPs and users.

Adopted Authentication & Authorisation Technologies

The EUDAT infrastructure is implementing an AAI solution called B2ACCESS which bridges various AAI technologies used by the communities with the various technologies used by the service providers within the infrastructure. Users of the infrastructure must be able to use their home organisations’ IdPs to log in to the EUDAT infrastructure, as well as IdPs run by the user communities (e.g. CLARIN) and, when applicable, social media (e.g. Google). The user’s EUDAT identity contains attributes provided by the “home” (external) IdP, supplemented with attributes maintained by B2ACESS itself (the proxy scenario) - so every internal identity can present, for example, an email attribute. Finally, EUDAT itself can also provide a “homeless” IdP by having users authenticate using username/password.

As EUDAT runs a lot of different services internally, SPs are offered different technologies for integration with B2ACCESS. Based on work originally done in the Contrail project and carried forward by the first EUDAT project, services can choose to use SAML (using the WebSSO profile), OAuth2 (RFC 6749), or X.509 certificates. In a simple scenario, a service will use OAuth for simple access and authorisation; a more complex scenario would use SAML to authenticate and pass authorisation decisions to an XACML infrastructure. In the most elaborate scenario, users would authenticate to a (community or EUDAT) portal using SAML WebSSO (which in turn redirects to the “home” IdP); then the portal obtains an OAuth access token to grant further rights, including the right to obtain a certificate on behalf of the user from a web services certification authority (internal to B2ACCESS) - it then generates the keys and obtains the certificate which includes authorisation attributes. This scenario provides extra security compared to many of the traditional portals as the issuance of the certificate requires additional authorisation (the portal has to be registered as an OAuth client and needs to be authorised to obtain a particular user’s certificate); the management of such authorisations can be predefined administratively or by the user and can be audited subsequently. Power users can download the certificate and use it to drive non-web services from the command line, e.g. B2SAFE and data transfers.  Despite its complexity, this approach offers a high degree of flexibility of integration of the many different components that comprise an EUDAT infrastructure, and many services will choose to use only the least complicated AAI mechanisms depending on their security requirements.

Penetration of federated identity management

EUDAT expects eduGAIN to cover most of the user base of the infrastructure. The  B2ACCESS service will enable connection with other IdPs or federations upon request of the users. EUDAT is developing training material for the infrastructure services, including B2ACCESS.

Authentication and authorization technologies

For a multidisciplinary infrastructure as EUDAT it is important to keep open the possibilities for the users to choose the IdP of their preference, this includes institutional IdPs, both federated in national federations and non federated, catch-all IdP provided bu the research communities, and social IdP. The LoA associated to them is also important.

Within the EUDAT infrastructure many services are offered and each service has it’s own needs with respect to authentication technologies. Currently EUDAT is supporting X.509, SAML and OAuth2. Some services are web based but others are not. In this case the infrastructure is currently using X.509 based solutions. Moreover, EUDAT aims for a single sign on experience but given the complexity of the infrastructure this is not always possible.

Attribute release policies

The more information that is provided by the user’s IdP, the more streamlined the process of creating the users identity in the EUDAT infrastructure will be. If the users IdP is not providing enough of the required attributes, we will prompt the user to provide these. Currently EUDAT aims to a minimum set of attributes a name and email address.

LoA management

The level of assurance assigned to the user credential is a very important attribute for the EUDAT use cases. EUDAT plans to be as open as possible in terms of the types of credentials accepted, and good practices in the management of LoA would be beneficial for the future development of B2ACCESS

Attribute management and community managed authorization

B2ACCESS will consume the attributes provided by the IdPs, and integrate with additional attributes where needed during the user registration process. B2ACCESS will in fact act as an attribute provider as well.

Given the distributed and heterogeneous nature of the EUDAT infrastructure, a persistent identifier for the user is really important. This is exactly the reason why EUDAT is mapping the users community identity to an (internal) EUDAT identity, since at the moment the infrastructure cannot rely on proper persistent identifiers in available from third parties. Even with this approach it is possible that the same user might get multiple EUDAT identities based on the used combination of IDP and SP and the attributes which are provided.

The use of community attributes for distribute authorization is a topic that has not been yet fully addressed by EUDAT but it is high in the agenda.  For the EUDAT services the authorization management should remain on the communities.

Italian libraries (Summary of answers gathered among Italian libraries)

 We are a university library. Our use case is typical for any university library in Italy. Our community uses AAI to access the electronic resources we subscribed, to access the personal area of the opac and of the university website, to use wi-fi.

 In detail we use AAI:

1. In our Discovery Tool (ExLibris Primo ) to access research papers and electronic resources, display and download full-text from e-journals and e-books, discovery tool e-shelf. To search directly databases or a electronic journals.
2. OPAC services: access to  users' personal area, book reservations, loans renewal; interlibrary loan and document delivery requests using the university online forms or SFX form. Access the  digital library of SebinaYou (Data Managment).
3. Online services of the library: photocopying, scanning of documents, printing .
4. Institutional repository: documents loading in the Institutional Repository (ARCA-Iris Cineca); Loading of doctoral thesis in the institutional repository of theses (DSpace).

We need to find a solution with ExLibris to access Primo and our resources from the discovery tool interface using AAI.

What is the current experience with AAI of your community? Has your community/research infrastructure already uses AAI solutions for their use case?

Yes.

What benefits do you see for Federated Access?

It simplifies the way of accessing ER, OPAC personal area and other library services such us photocopies, scanner and print.

It permits to check the  rights of the users because it allows different users' categories to access only the services which they are allowed to use. AAI would permit also to create access for walk-in users but we are not using it at the moment.  Moreover with AAI libraries could get more reliable ER usage statistics independent from publishers.

What barriers do you see in joining a federation?

• Lack of technical knowledge.
• It is unclear how to organise an Identity Management (IdM).
• It is unclear if the IdM should be internally or externally done.
• There is no clarity in the organization about the benefits of using an IdM.
• We already have an IdM but it is not completely compatible with SAML/OpenID or other industry-standards.
• Too much bureaucracy to join a federation.
• Other : There are still a lot of publishers who are not members of the federation and for libraries it seems  important to provide users with a unique way of accessing electronic resources.

As it concerns other libraries (public libraries) we think that the main barriers would be:

• The Management doesn’t consider that important.
• No enough funds/resources (human resources).

What is the user experience in the interaction with the available AAI solutions?

• Expectations fulfillment
• User friendliness
• Quality of service delivered by the tools

Do you think that your organization is lacking in information about federated identity management?

Yes, it lacks communication and coordination among the different actors (libraries, IT staff, IDEM) that are involved. It lacks cooperation between the federation IDEM and CRUI-CARE  (Conference of Italian University Rectors, the association of the Italian state and private universities and CARE is the section which deals with electronic resources contracts), which signs the national contracts with publishers. CRUI-CARE should ask publishers to include in the contracts the technical information about IdPs in order to implement Shibboleth authentication.

It would be interesting to know if in other European countries there are associations like CRUI-CARE and how they deal with national contracts and AAI

What material do you need to inform your organization about federated access?

It would be useful to present online guides and tutorials in the webpages where the users access ER and need instructions. Tutorial should be easy and user-friendly

Do you see the need for trainings to better inform representatives of members in your research area?

Yes, we do.

If your organization isn’t part of a federation yet, what can be helpful in order to join one?

For example:

• More informative material for management and decision makers
• Technical personnel dedicated to IdM
• Guides and trainings on how to implement an IdM and an Identity Provider
• Something ready that can be already used (like Virtual Machines)
• More resources
• External technical support
• A simpler procedure to follow for joining

What are the technical solutions adopted? Can you describe the solutions you have adopted highlighting as applicable?

Technology or technologies adopted:

• X509
• SAML2
• OpenID Connect/OAuth2
• OpenID
• Kerberos

 Identity Providers (IdP) federations integrated (e.g. eduGAIN) or:

• Approximate number of individual IdPs integrated =1
• Approximate number of users =190.000 

Solution for homeless users (users without a federated insitutional IdP). How do you manage guest users in your organization?

We manage guest users in two ways:

1. A guest user can be introduces from a member of the  staff (teacher / libraries or other university staff) filling a form in their personal area. The guest user gets  a  temporary account (7; 30; 90-days account- renewable). The person who introduces the guest is responsible for him/her.
2. During an event (lasting from a day to a week), the event organizer may enable participants to request via a text-message or via a link with the registration form a temporary account.

Both methods enable the use of WI-FI and to access their  persona area and they can  set the proxy or VPN to access electronic resources.

There are also Eduroam guests accessing the WI-FI and may, in some cases, set the Proxy or VPN.

 Solutions to handle user attributes

We use eduPersonScopedAffiliation with the value assigned from looking different databases (teachers, students, staff ...) according to the rules of eduPerson

Which IdPs your users would use?

• Their institutional IdP, part of national federations and eduGAIN.

• Non federated institutional IdPs.

• Research community catch-all IdP.

• Social media, at the moment is not used, but it would be useful for guest users of university libraries: facebook credentials would be accepted if certified by one or more institutional users. As for public libraries Facebook credentials  could be certified by other registered users.

What are the requirements for the authentication technologies to be used in your use cases?

• User friendliness, single sign on (SSO)
• Web browser and non-browser applications support
• Support multiple technologies and credential translation services (e.g. SAML -> X509 translation)
• Support for delegation (e.g. execute complex workflows on behalf of the user)

Could your community  benefit from Scalable IdP attribute release policies? In your use case, do you foresee the need to get attributes (e.g. institution, email address, name,…) from the IdP of the user? If the users will use many different IdPs, coming from different institutions, the service providers supporting the community need to access these attributes, therefore there is need for a set of policies that make scalable the negotiation between SPs and IdPs.

No.

Do you foresee for your use cases the need to have a persistent identifier to be associated to user’s identity? Supporting a persistent identifier allows the users to more easily change IdP preserving their identity.

Not at the moment, maybe in the future. For libraries it would be very interesting to implement ORCID (identifiers for researchers).

Is the support for different level of assurance relevant for your use cases?

Different LoA, allow users to use credentials with different level of assurance, and communicate properly the information to the service providers about the LoA of the used credential.

If yes, whom can we contact to ask further questions on your LoA needs? There is a dedicated task in AARC that investigates LoA.

Yes, for the main university services. Libraries do not need it, they need only a level 1.

Does your community need community level authorization?

Authorization is separated from authentication and it is controlled by the community. To implement this community-driven authorization user communities must manage a set of attributes associated to the users, which need to be provided to the service providers together with the identity attributes provided by the IdP.

At present community level authorization is not used. Publishers recognize only eduPersonScopedAffiliation.  A group-based attribute would be useful for libraries to allow remote access for ER  which are accessible only for a restrict number of users that until now are identified according to a limited IP range (for example electronic resources which can be accessed only from one library PC).

How is the current coverage of IdP federations?Are the current identity federations (e.g. IGTF or eduGAIN) covering enough identity providers/institutions to be a feasible option for your users? What are the use cases where the coverage is not sufficient to reach all the involved users?

At the moment our federation covers part of the Italian Universities (federated). Some universities, companies, visitors, citizens are not included.

ARIADNE

The user community of the ARIADNE project consists of archaeologists and other heritage professionals throughout Europe. The project aims at the integration of archaeological datasets and services. This consists mainly in two aspects:

1. Resource discovery through a Registry. Users will search the registry and find the description of relevant distributed resources, to be accessed directly from the data provider. Data providers have different policies for access. 
2.  Creation of integrated databases. This will be developed at experimental level for selected topics. The integrated database will be hosted by the project.

What is the current experience with AAI of your community?

Without federated access, resource discovery is cumbersome, as users are required to login at different services every time they want to access a resource. This limits the usefulness of the registry. There is no clear perception among partners about the utility of IdM. This is not part of the project original objectives. No resources are allocated to the task.

How to improve the penetration of AAI in your community?

In general, the organization is lacking in information about federated identity management. The best solution would be to demonstrate IdM in some pilot cases with a small group of partners and data providers.

Which type of Identity Providers are relevant for your community?

Their institutional IdP, part of national federations and eduGAIN. Non federated institutional IdPs, as well.

Could your community  benefit from Scalable IdP attribute release policies?

Probably yes.

 Do your community need persistent identifier for users ?

Yes.

Is the support for different level of assurance relevant for your use cases?

Yes, definitely.

How is the current coverage of IdP federations?

Although several partners use eduGAIN, this is not feasible for the larger user community because they may not belong to educational or research institutions. We expect a large number of homeless.

Other requirements

We suggest to develop a pilot use case with one/two project partner and then move to implementation with a larger base. Please note that the project will end in January 2017 so at least the pilot must be implemented by then.

Interviews

Interviews

Lifewatch

Lifewatch overview

Lifewatch (LW) is an ESFRI, more information about the LW overall objectives here:

• https://wiki.egi.eu/wiki/CC-LifeWatch/Introduction
• http://www.lifewatch.eu/

LW most active users are currently mainly concentrated in Portugal and Spain, but the community includes researchers from Belgium, Greece, Italy, Netherlands and Romania. More countries are part of the collaboration as observers, and the final goal is to support users from the whole Europe and beyond.

The use cases of LW can be summarized in two main categories:

• Researchers will access the data, and analyze and correlate the datasets. They need to access computing and storage resources to perform their research, therefore they need access to e-infrastructures.
• Citizen science users will access the dataset and upload data about observations. They are not institutional users, but also biodiversity enthusiasts who are willing to report observations of species around Europe.

The community of LW has a group of expert users, who are managing services and the resources accessible to the users. These expert users, or VO administrators, are more keen to use X.509 credentials, or – more in general – do adapt to the requirements of the e-infrastructures.

Researchers and institutional users very likely will access the e-infrastructure resources through platforms and portals provided by LW. The activities that they can perform requires a certain level of security: usage of resources, accessing non entirely open data, storing data. Therefore integration between institutional credentials (hopefully eduGAIN), the LW specific services, and the e-infrastructures AAI is required.

LW must consider researchers who do not have an institution IdP. These researchers must access anyhow the same services as the other researchers, and to support them LW is planning to deploy a catch-all IdP to be used for the affiliated researchers. LW is working to institute a legal entity who could employ staff to support central services such as the IdP.

Citizen science users are the other category of users relevant for LW. They are not related to institutions but biodiversity enthusiasts who will access very specific portals and data repositories. Citizen scientist are providing data about biodiversity observations, enriching the databases/datasets available online. To access the LW services for citizen science, users will have to be able to use a variety of low LoA credentials, such as social IDs or Google ID.

Another category of users are public authorities who collect environmental data that is relevant for the LW communities, or who are interested in the dataset available in LW, possibly also in using LW resources to run for example simulations.

Lifewatch is currently exploring the possibility to use ORCID ID as a unique identifier for the researchers.

Example of use case

(From the INDICO use cases deliverable)

One SME team wants to model the hydrodynamic behavior of the water reservoir in relation to algae bloom.

 The input comes from ENV experts in the SME.

• An ICT expert launches the simulation in HPC resources in the cloud. Each simulation is run from April to October for a given year, in 1h step, 3D.
• The ICT expert checks with the ENV experts in the SME that the reference distributions (Temperature profiles, water level, etc) make sense and compare them to previous monitoring data (when existing). The SME experts accesses the programs output on cloud resources via remote interactive portal.
• If the comparison is successful, the output is stored. If a prediction is required, different tasks are executed using previous year weather scenarios to provide an estimation of the probability of an algae bloom. A statistical model is then applied to estimate the expectations (this can happen in multiple iterations).

SME team wants to predict algae bloom based on model, and validate against previous year detailed analytical measurements

• The ICT and Biology experts confirm the required input
• The ICT expert prepares the simulation to estimate how the algae will grow. All input parameters to be tuned. An initial random selection using uniform sampling for 1000 different simulation points is prepared, each one requiring around 5h. These 1000 MC points are used as a first estimation of the dependence with the different variables.
• An optimization of the parameters, using history data, is made using a multivariable gradient technique. An optimized set of is obtained.
• The model is run weekly and contrasted with real evolution. Prediction of scenarios are updated. Estimation of the impact of different pressures and corrective measures (for example, water level management, by pass of waste water treatment plants, artificial wetlands, cattle management) is done to propose the best path to the management authorities.

Penetration of the federated AAI

Experience in Spain

At the moment in Spain many institutions are not part of eduGAIN, since they are supporting a previously established national federation PAPI not SAML2 compliant. Some of the institutes are migrating, and the goal would be to federate LW portals and services to eduGAIN.

Though there is some pull back on the eduGAIN migration, since the institutions managing the IdPs, both management and operators of the IdP, are reluctant in joining a new federation, their issue being the effort, or the lack of it, to deploy SAML2 compliant IDP, and the privacy issues that could generate sharing the credential information with the whole Europe.

User communities, not also LW, are explicitly asking for an eduGAIN integration, therefore the support for SAML2 has been taking speed in the last months.

The direction is to support exchanging information through SAML2 keeping PAPI for existing national services.

In other countries, for example Portugal, the penetration of SAML2 standard in the federation is more advanced and the link with eduGAIN should be achieved with no big effort required.

EPOS

EPOS is integrating the diverse European Research Infrastructures for solid Earth Science, and will build on new e-science opportunities to monitor and understand the dynamic and complex solid-Earth System.

The existing national RIs for solid Earth science in Europe generate data and information and are responsible for the operation of instrumentation in each country. They represent the starting point of the EPOS integration plan. The national RIs have a significant economic value both in terms of construction and yearly operational costs, which are typically covered by national investments that will continue during EPOS construction and operation.

The Thematic Core Services constitute the community-specific integration. They represent a governance framework where data and services are provided and where each community discusses its specific implementation and sustainability strategies as well as legal and ethical issues.

The Integrated Core Services represent the novel e-infrastructure consisting of services that will allow access to multidisciplinary data, data products, and synthetic data from simulations, processing and visualization tools.

The key element of the ICS is the central hub (ICS-C) where users can discover and access to data and data products available in the TCS and NRIs as well as access to a set of services for integrating and analysing multidisciplinary data. The interface between TCS and ICS is the compatibility layer, which organizes communication and exchange of information.

The ICS-C will also provide access to distributed computational resources for visualizing, processing and modelling data and data products. These distributed computational resources form the distributed ICS (ICS-d) and include access to supercomputing and facilities as well as to visualization, processing and modelling tools.

AAI Use case

EISCAT 3D

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 data for one year after the date of observations.

The data access control of this has so far been based on the IP address, 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 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 access policy to data are:

• In some countries (full partners of EISCAT) all the users/researchers of the country can access the data.
• In other countries there may be affiliated institutions eligible to access, but only employees of the institutions can access.
• The access policy database for most of the use cases contains only the country, without higher granularity of information.

The highest level of assurance is required for who is accessing is to access the radar facility itself, to schedule specific analysis, authorization is usually managed by the radar site.

EISCAT architecture is - at a very high level - composed by one or more of the following facilities/entities:

• Radar site, where data is produced
• Operations centre, whcih provides - among other services - computing and storage
• Processing sites
• User portal, where the users can connect to browse available data, and access the eiscat services in the opertions centre. All the interactions of the sers are through the poral(s), where user can search/move the data within the eiscat infrastructure, but also download the data.

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.

Data becomes open after a certain amount of time, depending on specific policies, but also to access open data a low level of authentication of user is preferrable to enable accounting.

The Operation Centre is a central facility where data is pre-processed, and stored. Users to further process the data have to stage it to other facilities, processing sites, where temporary storage is provided together with computing services. Some parts of the data cannot be staged/moved, and therefore the computing tasks must be able to access the central repository in the operations centre, on behalf of the user.

The EISCAT 3D use case requires interoperability between e-infrastructures: EGI, EUDAT, PRACE.

HUMAN BRAIN PROJECT

HBP is working on enabling AAI the following plaftorms (other platforms to come):

Neuroinformatic

One of the HBP's most important objectives is to make it easier for neuroscientists to organise and access the massive volumes of heterogeneous data. The HBP will use these tools to develop detailed multi-level atlases of the rodent and human brains, bringing together data from the literature, and from on-going research, and providing a single source of annotated, high quality data for the HBP modelling effort and for the international neuroscience community. Another key feature of the platform will be support for Predictive Neuroinformatics: the mining of large volumes of data and analysis of activity data to identify patterns and relationships between data from different levels of biological organisation, making it possible to predict parameters where experimental data is not yet available and to test and calibrate model implementations.

Neuromorphic computing

Allows non-expert neuroscientists and engineers to perform experiments with configurable Neuromorphic Computing Systems (NCS) implementing simplified versions of brain models developed on the Brain Simulation Platform as well as on generic circuit models.

Neuro-robotics

The Neurorobotics Platform will offer scientists and technology developers a software and hardware infrastructure allowing them to connect pre-validated brain models to detailed simulations of robot bodies and environments and to use the resulting neurorobotic systems in in silico experiments and technology development.

HPC

Provide the HBP Consortium and the broader European neuroscience community with supercomputing, Big Data and Cloud capabilities at the exascale, as well as the system software, middleware, interactive computational steering and visualisation support necessary to create and simulate multi-scale brain models and to address the hard-scaling challenges of whole brain modelling.

Collaboratory

Provide the central services to support all the other platforms.
This will include also a catch-all IdP for the HBP users.
Authorization is often delegated to the service provider. Group authorization can be implemented centrally, but the access to the
resources is always vetted by the service provider. This is the case, for example, for the HPC platform.
Some of the services are behind a high level of assurance authentication of the users, e.g. users must provide a copy of the
passport to the service provider. This is the case, for example, for the HPC platform or the Neuromorphic one.

HBP Users types

• Some are researchers from public research/education institutions.
• HBP expects to have also  companies and indivudals as users.
• Many users join the collaboration by invitation.
• HBP is highly interested in a PID to uniquely identify the users and HBP is looking for potential external sources of such PID.
• Inclusiveness is a critical feature of every AAI implementation for HBP.

HBP is working on an AAI infrastructure to enable also users outside HBP, this will include:

• Authentication interfaces
• Authorization tokens
• Support for SAML2 based technology (ECP profile)

HBP services are likely to use OpenID Connect for authentication. HBP is an internnational collboration that spans across multiple continents.