Versions Compared

Key

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

...

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

Use Cases


Access to Rshiny
1.

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

 

 

Afbeeldingsresultaat voor browser icon

2.

The User is redirected to LifeWatch IdP

3.

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

4.

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

5b.

The user is successfuly redirected to Rshiny app

   


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

 

 

2.

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

4.

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

5.

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

   


Further information

Provide some description related to BPA. Was BPA useful to achieve this results? how? 

About sustainability:

  • will this pilot survive after AARC?
    • If yes, how?
    • if no, why?

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 guaranteedLast part contain a list of information, link or anything related to the pilot that was not mentioned in ahead seciton.