...

This task deals with piloting of solutions to manage attributes on a central, cross application and even cross application e-infrastructure level. We will demonstrate and test an integrated AAI framework consisting of:

• identity Identity providers, 
• attribute Attribute and group providers, 
• attribute Attribute aggregation platforms and 
• shared Shared e-infrastructure services that are able to consume attributes

Information about the Openstack pilot set-up

...

• am02.pilots.aarc-project.eu is the controller node
• am05.pilots.aarc-project.eu is the compute node

The OpenStack version installed is Liberty, on the operating system Ubuntu 14.04. The OpenStack components deployed are: keystone, neutron, nova, glance and horizon

The keystone component was configured to work in a federated environment: it acts as (Shibboleth) Service Provider. No local accounts were created on it, apart the admin one.

When an user goes to the horizon login page, there are two options:

• login with Keystone credentials (which obviuosly hasn't got)
• login through SAML assertion

Chosen the SAML option, the user is redirected on a page where can select the preferred Identity Provider for performing the authentication: currently it was configured only the IDP of the pilot testbed (am-proxy.pilots.aarc-project.eu).

Once filled-in its data, the user is brought back to horizon where he can finally access to the openstack functionalities.

The actions he can perform depend on:

• the local group which the user is mapped to
• the role assigned to the user in that particular group for one of the existing OpenStack project

On OpenStack it was created 3 projects for the AARC pilot users: aarc-pilot, aarc-pilot2 and aarc-pilot3.

The local groups reflect the eduPersonAffiliation attribute owned by the users in their IDP: member, student, employee, faculty and staff.

The role assigned for a particular project can be: user or admin

The following is a simplified rule just for explaining how the IDP users are mapped to ephemeral account:

All the users having "faculty" in the eduPersonAffiliation attribute are mapped to the local group which has got the id=2694979ea7fb41a9a6adf00eb212a335 and as local username is used the eppn.

The dashboard login page is https://am02.pilots.aarc-project.eu/horizon/

Notes on some issues found

• When trying to login into horizon using the local accounts defined in openstack (admin and demo users), the access fails with the following error reported in the log /var/log/apache2/error.log:

For solving it we had to set "OPENSTACK_SSL_NO_VERIFY = True" in the horizon configuration. It is also important having the CAs added in the python-requests in horizon (as mentioned in https://wiki.egi.eu/wiki/Federated_Cloud_APIs_and_SDKs#CA_Certificates )

• When trying the federated login via the SAML authentication, if you get the following error page:

and in the /var/log/apache2/keystone.log there is the following error:

you may have hit this bug http://trwa.ca/2014/10/shibboleth-2-5-apache-2-4-and-breaking-apache-basic-auth/

So creating this file

The figure below gives a simplified overview of such a setup

Image Added

 and enabling it in shibboleth solves the issue

Information about the COmanage Registry set-up

...