Introduction

WaTTS (the INDIGO Token Translation Service) is a plugin-based Token Translation Service. Enabled by plugins, several credentials (e.g. SSH keys, X.509, S3 access tokens, etc.) are supported.  WaTTS accepts many different implementations of OIDC providers (EGI-CheckIn, B2Access, Human Brain, Google and Indigo IAM)

In this pilot, we have implemented a plugin to demonstrate the integration with the RCauth.eu online CA. The WaTTS plugin implements a MasterPortal and VO-Portal for the RCauth CA. After authenticating in WaTTS  with any OIDC Provider, a certificate may be requested. For this, the user is redirected to the RCauth CA WAYF. There, she may choose which home-IdP to use for authenticating to RCauth. In this autentication step, the LoA must be high enough to fulfill policy requirements. To date B2Access, Checkin and a set of individual IdPs support these requirements.

NOTE:

In the first version of this pilot, we will use the development instance of RCauth, which does not use a WAYF but redirects users directly to the EGI-AAI-Dev instance.

Upon successful authentication at RCauth.eu, the users browser is redirected back to WaTTS, where he is given a proxy of his certificate. The full certificate is stored inside a myProxy. Development to provide a VOMS proxy is on-going.

Commandline / API Access:

One goal of this pilot is to show the command line (CLI) access. Once the user user has his OIDC-Access token on the command line, he can use the REST interface of WaTTS (we encourage the appropriate client wattson (https://github.com/indigo-dc/wattson) to retrieve his grid proxy.

Detailed description

Goal of the pilot is to demonstrate how WaTTS can be leveraged to deliver X.509 certificates of RCauth. In addition, support for usage from the commandline is demonstrated.

Pilot example is following:

User first needs to authenticate itself at WaTTS using one of the available OIDC providers. So far, EGI CheckIn service, EUDAT, Human Brain Project, INDIGO Access Management, and Google are supported. More OIDC providers can be provided in the future. After the successful login, user is displayed a number of available plugins. For this demo, X509_RCauth_Pilot is the plugin used to provide the service, and user request a proxy certificate by clicking on the Request button. This plugin needs access to user's OIDC access token (this info is displayed to the user). As shown on the picture below, the RCauth plugin initially tries to get a proxy certificate from the credentials stored on the Credential Store (MyProxy server), where the user's credentials are stored under unique user's identifier. In case the credentials are not present in the Credential Store, the user is informed that it will be redirected to RCauth CA WAYF, where the user should use it's home IdP to authenticate itself. For the test CA used in this demo, IdPs with low LoA can be used. After the user is successfully authenticated at the second IdP, the plugin uses new user's information to retrieve the certificate from the RCauth CA, stores it in the Credential Store (PUT or STORE flow in the picture), and creates a proxy certificate which is then, subsequently, provided to the user (GET flow). Proxy certificate can be retrieved as long as the original certificate is valid (~ 11 days), and itself is valid for 12 hours. Long lived proxy certificate obtained from the RCauth CA, along with the user's private key, never leaves the Credential Store. Only Short Lived Proxy is provided to the user. Plugin also provides the possibility for the user to remove it's credentials from the Credential Store. To demonstrate CLI capability for the user to retrieve a short proxy certificate, small bash script is provided.

The pilot structure is shown in picture below.

The pilot authentication flow is following:

1. User accesses (or is redirected to) the WaTTS page, and selects its OIDC provider to log in. This may be EGI, EUDAT, Google, Human Brain Project or INDIGO IAM.
2. User is redirected to the desired OIDC provider at which it authenticates. NOTE, that the LoA is not relevant at this point (yet, since the demo uses the test CA)
3. User is prompted to accept the release of information, and at the end, the information about the user is returned to WaTTS (i.e. LoA, issuer, name, mail, etc.)
4. Back at WaTTS, user selects the X509_RCauth_Pilot
5. If already authenticated with RCauth see point 7. Otherwise, user is notified that he will be redirected to authenticate at RCauth. NOTE, this authentication step is only required once every 11 days.
6. User is redirected to RCauthWAYF and follows the respective "login-dance". NOTE: RCauth only offers IdPs with an appropriate LoA.
7. User is presented with a page that allows him to download its X.509 proxy-certificate.

For commandline access this flow applied

4. User is also presented with his OIDC Access Token

5a. If already authenticated, user may use wattson (or the nice cli-get-proxy.sh) to follow the commandline flow. User's proxy will be placed to /tmp/x509up_uxxxx

5b. If not authenticated, user is informed that it has to authenticate by pointing its browser to WaTTS.

NOTE:

In the future, for security reasons, users can retrieve their proxy certificates using SSH access, naturally after first obtaining End Entity Certificate. This feature is under development, and will be implemented soon (mid 2017). This wiki page will be updated to reflect future developments.

WATTS source and info pages:

https://github.com/indigo-dc/tts
https://www.gitbook.com/book/indigo-dc/token-translation-service

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

Installing wattson: https://github.com/indigo-dc/wattson/releases/latest

https://github.com/urost/cli-get-proxy

Note that the WaTTS page might be moved in the future, probably to https://github.com/indigo-dc/watts.

Access to the cloud resources
1.	Access WaTTS instance at https://watts-dev.data.kit.edu In this example we will use EUDAT b2acess. So, we will select "EUDAT (b2access)" and click on "Login".
2.	Select your Identity Provider from the discovery page on the EUDAT b2access page. The institutional IdP to select (for this demo) is KIT, and then we click on Authenticate.
3.	After authenticating, we can see what information is released to B2ACCESS.
4.	After successful authentication, user is redirected from B2ACCESS to WaTTS. Then, in order to obtain a certificate user needs to use X509_RCauth_Pilot plugin, so we click on Request. The arrow is pointing to the information whether the credentials already exists on the myproxy-server or not. In this case, we will show the full flow, with authenticating with RCauth Test CA.
5.	Since in this flow, the credentials are not yet stored, we will be redirected to authenticate with RCauth Test CA and obtain (new) credentials.
6.	At this step, we are redirected to select the IdP with which to authenticate. If selecting the same IdP as used with the initial authentication at WaTTS (in this case home IdP), user is not prompted to authenticate again. However, at this point user can select different IdP to authenticate with RCauth. This flexibility provides the ability for the user to, e.g., use IdP with different LoAs, one to authenticate with WaTTS, different one to authenticate with RCauth. E.g. user can use Google account to authenticate with WaTTS, and use its home IdP to authenticate with RCauth.
7.	Here, user can see what information will be released to the RCauth Test CA (and, in production to RCauth itself). User should click Yes if agrees with releasing the information.
8.	User can now download and use the obtained short proxy certificate. The proxy certificate is also displayed to the user, (blacked in the example picture).