Requirements gathering

Communities contacted

The following table summarizes the communities, either represented in AARC consortium or external, in contact with AARC JRA1.1 or other tasks. Contributing to the definition of the AARC plans.

• DARIAH
• CLARIN
• WLCG
• ELIXIR
• PARTHENOS
• ARIADNE
• BioVel

Other stakeholders/target for the questionnaire

• Education/Cloud providers for education
• Libraries
• IdPs

Summary of the answers collected

BioVel

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.

EISCAT

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.

CLARIN

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.