Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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. This

Pilot goals

 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.

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?

Description

Main objective of this section is to report detailed informations about pilot. 

Some questions:

  • How this pilot works

  • Reason to prefer this pilot instead of other existing tool

  • Detailed Scope

  • others

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:

  1. Add Link to component web page
  2. Add a short description to explain its function (not more than 1 raw)
  3. 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

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).

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.

During the evaluation phase, different components were checked to decide which one suited the LifeWatch ERIC needs better, including EGI check-in, B2ACCESS, INDIGO IAM, and Keycloak. Finally, the decision was keycloak, an open source solution supported by RedHat and adopted by different communities. The reason for selecting keycloak was the set of features that provides, which are enough for the needs of LifeWatch ERIC as a community:

  • Different ways of user management. Keycloak allows to create a local user in a database or connect with LDAP systems.
  • User federation using the main technologies: OpenID Connect, SAML, Oauth2. It is pre-configured with many different social IDs (Google, Facebook, Github, other keycloak instances). Also eduGAIN.
  • Unlimited federation of IdPs. It is needed for the complex LifeWatch community, with representatives of many institutions.
  • Customizable set of attributes, both in local users as well as federated.
  • Attributes mapping from federated IdPs. It is needed to classify the different expected roles.
  • Group and role management to identify user permissions.
  • Easy to install and maintained. It works with a database that can be distributed.
  • Clustered mode to set up a high-availability environment.

Components

The components are as follows:

ComponentDescriptionWhy did we choose it?Link
KeycloakKeycloak 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

Image Added

Pilot Vs AARC BP

Image Added

Use Cases


Access to Rshiny
1.

Access RShiny research service to analyze/calculate thermoclines in water columns.

 

 

Afbeeldingsresultaat voor browser iconImage Added

2.

The User is redirected to LifeWatch IdP

Image Added

3.

You can select among the list of federated institutions belonging LifeWatch. For example, IFCA SSO will redirect you to the IFCA IdP

Image Added

4.

Overview of attributes being shared (to authenticate and perhaps authorize)...... 

Image Added
5b.

The user is successfuly redirected to Rshiny app

Image Added

   


Use Case 2 - User Role Mapping (Researcher Vs. Citizen Scientist)


Access to Rshiny (for the moment)
1.

LifeWatch ERIC IdP needs to federate different institutions and different social ids to distinguish between different types of users (Researchers, citizen scientists...).

 

 

Image Added

2.

Keycloak allows mapping to defined roles depending on the identity provider used for accessing.

Image Added

4.

It can be configures to propagate that information as an attribute for a service.

Image Added

5.

So the service can get that info and decide if the user has or not access rights.

Image Added

   


Further information

The pilot has been implemented and deployed in a testbed aiming at proving that everything will work as expected. The AARC BPA has been used to identify which components are needed to address the pilot needs. The BPA has also been the model to define the pilot architecture, as the following schema shows:

The pilot will be the official LifeWatch ERIC IdP and it will be used to access the services taking into account the different roles in the community. It will be deployed in a high-availability environment since it will be a critical service for the Research Infrastructure, and it will be one of the keys to integrating LifeWatch ERIC in the context of the European Open Science Cloud, so the sustainability of the pilot is guaranteed

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.