Pilot Description

LifeWatch-ERIC is a European Infrastructure Consortium providing e-Science research facilities to scientists seeking to increase our knowledge and deepen our understanding of Biodiversity organisation and Ecosystem functions and services in order to support civil society in addressing key planetary challenges.

LifeWatch-ERIC was established as a European Research Infrastructure Consortium by the European Commission Implementing Decision (EU) 2017/499 of 17 March 2017.

During its ESFRI stage, LifeWatch was composed by different national initiatives working on different services and solutions for the research community. During this new ERIC stage, LifeWatch ERIC requires a solutions to provide access to the different services in a common way, as well as organize the different defined groups and roles. Currently, the different LifeWatch services, Virtual Laboratories and Virtual Research Environment manage their own local users, with some exceptions that allows institutional IDs. The technology behind depends on the services, but they mainly support web-based authentication, with some exceptions using, for example, HPC resources.

This pilot activity aims to identify and enhance an existing AAI solutions to be adopted by LifeWatch ERIC as IdP, integrating already existing institutional or social identities in a federated way.

Pilot goals

Some questions to answer:

What are the goals of this pilot?
Why is it in AARC project?
How this pilot will improve AARC community?
Why should I use this pilot instead of other solutions?

This IdP solution will be used for the following purposes:

To give access to restricted LW services. The services may be restricted because of processing power or storage demands.
To protect user data and scripts that are stored on the infrastructure (unix home folders etc)
To give access to data not yet in the public domain. (data in databases , project moratorium period )
To distinguish between users uploading data to the system (RvLab , eLab, data explorer)
To give access to openstack configuration interface and computing resources at infrastructure layer.
To manage roles/groups and authorize them to access specific services.

Currently, the different user apps manage their own users. The institutional credentials could be federated in the Identity Provider. Also, it should manage the following roles/users:

IT administrator who have access at infrastructural level.
Developers/Solver who have access to computing/storage resources to develop new Vlabs/VREs.
LifeWatch ERIC research users
Citizen Science (to have access to concrete applications)

The architecture suggested by AARC based on the blueprint is a promising approach to be adapted to the European framework, in particular for the European Open Science Cloud.

Description

This Pilot, which is based on the AARC BP architecture, deploys a Keycloak instance to work as LifeWatch ERIC IdP, which will b the official user manager solution. It will be deployed on production as a High-Availability service on LifeWatch ERIC ICT resources.

Keycloak satisfy all the expected functionalities, since is is compatible with the most used technologies (SAML, OIDC), it allow IdP federation and allows user group management and attribute mapping. The characteristics provided make Keycloak a promising solution to be adopted instead other available.

Components

This section will contain a lists of components used for this pilot.

It is not required to add a detailed description for each component, but 3 important parts are:

Add Link to component web page
Add a short description to explain its function (not more than 1 raw)
Explain why these components have been chosen

An example:

Component A - Service provider
Component B - Bring order to chaos
Component C - Hide my precious treasure

The components are as follows:

Component

Description

Why did we choose it?

Link

Keycloak

Keycloak is an open source Identity and Access Management solution aimed at modern applications and services. It makes it easy to secure applications and services with little to no code.

Keycloak fullfil all the required functionalities expected:

Compatible: OIDC (priority), SAML (interesting, eduGain).
Federation of 1-N Institutions. Citizen Scientists (Social IDs).
Roles Management. Role mapping (e.g. Google users to Citizen Scientist).
Identity linking (optional).
Group Management. Some groups are allowed to do…
Distributed, clustered. High availability. NATIVE

https://www.keycloak.org/

FEUDAL

Federated User Credential Deployment Portal.

One possibility to link between the IdP (Keycloak) and a "non-compatible" service.

https://hdf-portal.data.kit.edu/

WaTTS

WaTTS allows using any legacy service with federated identities, such as eduGain or google.

For this, WaTTS accepts federated identities (via OpenID Connect) and uses a plugin scheme to generate credentials for your service. This allows you to provide services that do not normally support federated identities to federated users.

One possibility to link between the IdP (Keycloak) and a "non-compatible" service.

https://github.com/indigo-dc/tts

Architecture

This section will provide 2 important parts:

Graphic representations of pilot architecture
Graphic representations of workflow
Lists of all components of related pilot

Use Cases

This section should explain how this pilot works through use cases (at least 2).

Use cases can be represented in the form of a table, where:

The title is the use case
Each line is a step
2 columns available, first with text and description, second with a screenshot

(Here's a valid example LINK)

Further information

Last part contain a list of information, link or anything related to the pilot that was not mentioned in ahead seciton.