You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Requirements gathering

Communities contacted

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

 

EGI

EGI is a resource infrastructure. The main goal is to enable users to access the distributed infrastructures.

The process to access EGI services is illustrated in the above picture:

The user, on the left, 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.

 

EUDAT

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.

 

 

 

 

 

 

  • No labels