WaTTS is a Token Translation Service developed by KIT in the context of the INDIGO Data Cloud project. WaTTS was developed to address the users' need to access services that can not directly utilise federated access and require that the users use security tokens, such as SSH keys, X.509 ertificates, S3 access tokens etc. In this AARC pilot, WaTTS is integrated with the EGI CheckIn service, so that users can access WaTTS using their EGI accounts, while authenticating either at their home organisations or using their socialIDs. With WaTTS, users are able to manage the SSH access to a number of trusted VMs from a single point in a secure and user-friendly manner. In this pilot, WaTTS is used to manage their SSH public keys and provision them on demand to an authorised set of VMs. Although in this pilot WaTTS is integrated with the EGI CheckIn service, the solution is not limited to EGI, and can be used at any community/infrastructure/service where there is a need to "bridge" between different technologies, and can be run as a standalone "plug-and-play" solution. The only requirement is that the community/infrastructure/service supports integration of OIDC services.
Detailed description
Goal of the pilot is to demonstrate how the credentials can be managed according to user's identity. From the research/user point of view, the desired behavior is having an SSH access to desired VMs. From the administrator/coordinator point of view, the desired outcome is providing access to users in a straightforward manner, as easy as user uploading it's SSH key. However, such access should be granted only to authorized users. Therefore, LoA discrimination is used.
Pilot example is following:
The pilot structure is shown in picture below.
The pilot authentication flow is shown below:
It is important to mention that at neither step the credentials (in this case SSH keys) are stored on WATTS service.
WaTTS is still in development, however, it is also in production. As already mentioned, it is not limited to EGI OIDC providers, but already supports Human Brain Project (HBP), b2access, Google, and naturally, INDIGO IAM (INDIGO Access Management). Adding additional IdPs or configuring the service is straightforward. Support for additional credentials is done through plugins, which can be further developed as needed.
WATTS source and info pages:
https://github.com/indigo-dc/tts
https://www.gitbook.com/book/indigo-dc/token-translation-service
Note that page might be moved in the future, probably to https://github.com/indigo-dc/watts.
| Pilot resources | |||
|---|---|---|---|
WATTS service (https://watts-dev.data.kit.edu) | |||
EGI CheckIn service
| |||
2 VMS provided by ~okeanos. | |||
| KIT Grid certificate (used to authenticate with EGI CheckIn service), alternatively Google account is used, however LoA connected with Google account is not sufficient to upload keys (this is by design, it is configurable, naturally) |
Demonstration workflow
| Access to the cloud resources | ||
|---|---|---|
| 1. | Access WaTTS instance at https://watts-dev.data.kit.edu Select "European Grid Infrastructure" and click on "Login".
| |
| 2. | Select your Identity Provider from the discovery page (WAYF). The institutional IdP to select (considered for demo purposes only) is: AARC DIY Identity Provider | |
| 3. | Enter your login credentials to authenticate yourself with the IdP of your Home Organisation. We will show three cases: a) an user belonging to aarc-yellow CO with admin role b) an user belonging to aarc-yellow CO with no particular roles c) an user belonging to aarc-blue CO with admin role | |
| 4a. | -- user belonging to aarc-yellow CO and with admin role -- After successful authentication, the user needs to give the consensus for releasing your personal information to the Service Provider mentioned in the page (the OpenStack framework in our case). Among the data that will be passed to the Service Provider, there are the Entitlements released by the attribute aggregatore COmanage regarding the ownership in the COs and the roles. In this case the Entitlement contains these piece of information: urn:mace:aarc-project.eu:am03.pilots.aarc-project.eu:members:member@aarc-yellow.pilots.aarc-project.eu urn:mace:aarc-project.eu:am03.pilots.aarc-project.eu:admin:member@aarc-yellow.pilots.aarc-project.eu That is the piece of information used for properly mapping the users to the OpenStack projects. Click on "yes" for going on.
| |
| 5a. | The user is successfuly redirected to the OpenStack Dashboard, mapped to a Keystone user group based on the values of the Entitlement attribute, with the eppn as username. In this case the user is accessing to the aarc-yellow project with administrative rights. | |
| 4b. | -- member of aarc-yellow CO without any priviledged role -- After successful authentication, the user needs to give the consensus for releasing your personal information to the Service Provider mentioned in the page (the OpenStack framework in our case). Among the data that will be passed to the Service Provider, there are the Entitlements released by the attribute aggregatore COmanage regarding the ownership in the COs and the roles. In this case the Entitlement contains these piece of information: urn:mace:aarc-project.eu:am03.pilots.aarc-project.eu:members:member@aarc-yellow.pilots.aarc-project.eu That is the piece of information used for properly mapping the users to the OpenStack projects. Click on "yes" for going on.
| |
| 5b. | The user is successfuly redirected to the OpenStack Dashboard, mapped to a Keystone user group based on the values of the Entitlement attribute, with the eppn as username. In this case the user is accessing to the aarc-yellow project with no administrative rights. | |
| 4c. | -- user belonging to aarc-blue CO and with admin role -- After successful authentication, the user needs to give the consensus for releasing your personal information to the Service Provider mentioned in the page (the OpenStack framework in our case). Among the data that will be passed to the Service Provider, there are the Entitlements released by the attribute aggregatore COmanage regarding the ownership in the COs and the roles. In this case the Entitlement contains these piece of information: urn:mace:aarc-project.eu:am03.pilots.aarc-project.eu:members:member@aarc-blue.pilots.aarc-project.eu urn:mace:aarc-project.eu:am03.pilots.aarc-project.eu:admin:member@aarc-blue.pilots.aarc-project.eu That is the piece of information used for properly mapping the users to the OpenStack projects. Click on "yes" for going on.
| |
| 5c. | The user is successfuly redirected to the OpenStack Dashboard, mapped to a Keystone user group based on the values of the Entitlement attribute, with the eppn as username.. In this case the user is accessing to the aarc-blue project with administrative rights. | |
| Mapping rules: an example | |
|---|---|
{ "local": [ { "user": { "name": "{0}" } }, { "group": { "id": "3b609a4da6654625a3789d1a6bd1fdc7" } } ], "remote": [ { "type": "eppn" }, { "type": "entitlement", "any_one_of": [ "urn:mace:aarc-project.eu:am03.pilots.aarc-project.eu:admin:member@aarc-blue.pilots.aarc-project.eu" ] } ] }, | The mapping rules are passed in Keystone as a json file. Each set of rules is made of a local and a remote section. In the remote part it is specified the external attributes to take into account and that we want to map to the local ones, following the order in which they are listed. In our case, as local username, it will be used the eppn, and any SAML assertion presenting that particular value in the entitlement attribute will be mapped to the local group qith that particular ID. |