...
During the evaluation phase, different components were checked to decide which one suited the LifeWatch ERIC needs better, including EGI
checkincheck-in, B2ACCESS
and INDIGO IAM., 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:
| 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:
| 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
...
Pilot Vs AARC BP
Use Cases
| Access to Rshiny | ||
|---|---|---|
| 1. | Access RShiny research service to analyze/calculate thermoclines in water columns.
|
|
| 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.