Versions Compared

Key

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

...

 

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

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.
Access to the cloud resources
1.

Access WaTTS instance at https://watts-dev.data.kit.edu

Select "European Grid Infrastructure" and click on "Login".  

 

 

Image RemovedImage Added
2.

Select your Identity Provider from the discovery page (WAYF).

The institutional IdP to select (considered for this demo purposes only) is: AARC DIY Identity Provider

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

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

 

 

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

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

 

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

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

 

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

Image Removed
   

) is: IGTF Certificate Proxy, and then we use the institutional grid certificate (in this case, KIT Grid Certificate)

Image Added
3.

This page displays which values will be released by IGTF-to-eduGAIN-Proxy. User should click on Yes to accept and proceed.

 

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

 
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"

                   ]

                }

            ]

        },