Page History

...

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 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:

...

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.Image Removed

Image Added

The pilot authentication flow is shown belowfollowing:Image Removed

1. User access accesses (or is redirected to) the WaTTS page, and selects the desired its OIDC provider , in this case EGI CheckIn Serviceto log in. This may be EGI, EUDAT, Google, Human Brain Project or INDIGO IAM.
2. User is redirected to the desired OIDC provider . In case of EGI CheckIn Service, user can select between his home IdP, or social networks (SN) (Google, etc.), among others. However, these do affect the LoA granted to the user, i.e. home organisation has Substantial LoA, while SNs have Low.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 the WATTS WaTTS (i.e. LoA, issuer, name, mail, etc.)
4. User then selects the desired action.
5. User uploads/generates an SSH key
6. SSH key is deployed to the desired VMs, and username and hostname is shown to the user.

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.

1. Back at WaTTS, user selects the X509_RCauth_Pilot
2. 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.
3. User is redirected to RCauthWAYF and follows the respective "login-dance". NOTE: RCauth only offers IdPs with an appropriate LoA.
4. 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 Select "European Grid InfrastructureIn this example we will use EUDAT b2acess. So, we will select "EUDAT (b2access)" and click on "Login".	Image Added	Image Removed
2.	Select your Identity Provider from the discovery page (WAYF)on the EUDAT b2access page. The institutional IdP to select (for this demo) is : IGTF Certificate Proxy KIT, and then we use the institutional grid certificate (in this case, KIT Grid Certificate)click on Authenticate.	Image AddedImage Removed
3.	This page displays which values will be released by IGTF-to-eduGAIN-Proxy. User should click on Yes to accept and proceed.	Image Removed
4.	This page displays which values will be released by EGI-CheckIn. User should click on Yes to accept and proceed. We can see that the LoA is now Substantial.	Image Removed
5.	Upon successful login, the user is redirected to the WaTTS. We then select the desired plugin, in this case aarc_ssh, and we can select either Request, or Advanced. First option creates SSH key par for the user, and deploys the public key to the VMs. User then must download the key pair if intends to use them, since the keys are never stored on WaTTS. If skipping this step, user must recreate the SSH keys again. Second option (Advanced) will enable the user to upload its own public SSH key.	Image Removed
6.	If user select Advanced option, then it is able to upload its own key. After pasting the key, user should click on the Submit button.	Image Removed
After authenticating, we can see what information is released to B2ACCESS.	Image Added
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.	Image Added
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.	Image Added
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.	Image Added
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.	Image Added
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).	Image Added	7.	After successfully uploading or generating SSH key, the user now has SSH access to VMs. The username and full VM hostname is displayed to the user.