...
Task Leader: EGI, Peter Solagna
This task deals with piloting of solutions to manage attributes on a central and cross application level. We will demonstrate and test an integrated AAI framework consisting of:
- identity providers,
- attribute and group providers,
- attribute aggregation platforms and
- shared e-infrastructure services that are able to consume attributes
Information about the Openstack pilot set-up
We deployed an Openstack testbed on two virtual machines:
- 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
| aarc-pilot | aarc-pilot2 | aarc-pilot3 | |
|---|---|---|---|
| staff | admin | admin | admin |
| student | user | ||
| faculty | user | user | |
| member | admin | user | |
| employee | user | user | admin |
The following is a simplified rule just for explaining how the IDP users are mapped to ephemeral account:
[ { "local": [ { "user": { "name": "{0}" } }, { "group": { "id": "2694979ea7fb41a9a6adf00eb212a335" } } ], "remote": [ { "type": "eppn" }, { "type": "unscoped-affiliation", "any_one_of": [ "faculty" ] } ] } ] |
|---|
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:
| [Mon May 09 16:14:45.903360 2016] [:error] [pid 5980:tid 140331975448320] SSL exception connecting to https://am02.pilots.aarc-project.eu:5000/v3/auth/tokens: [Errno 1] _ssl.c:510: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed [Mon May 09 16:14:45.903966 2016] [:error] [pid 5980:tid 140331975448320] Login failed for user "admin" |
|---|
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:
UnauthorizedThis server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required. |
|---|
and in the /var/log/apache2/keystone.log there is the following error:
| 2016-05-18 12:33:34.035509 AH01629: authorization failure (no authenticated user): /v3/auth/OS-FEDERATION/websso/saml2 |
|---|
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
root@controller:~# cat /etc/apache2/conf-available/shib2.conf ShibCompatValidUser On |
|---|
and enabling it in shibboleth solves the issue
Information about the COmanage Registry set-up
We deployed a COmanage Registry service on the virtual machine am03.pilots.aarc-project.eu:
- chosen the organizational identiy unpooled option
The registry was configured as service provider: the IDP contacted is am-proxy.pilots.aarc-project.eu
Based on the scenarios for an attribute management framework as described in JRA1 this activity will deploy pilots for the tools and methodology identified by JRA1 for deploying attribute management frameworks for collaborative SSO scenarios. The pilots will focus on maximising the interoperability of the tested solutions. This includes:
- Attribute management. Identify tools and services that better support the registration and management of attributes by the research communities. Based on the requirements, as defined in JRA1, at least two tools will be selected for a pilot. The tools should support standard interfaces to be used by user communities and e-infrastructure service providers.
- Attribute aggregation. Multiple scenarios for attribute aggregation are expected to result from the attribute framework definition. This work item will validate at least two basic models, a hub model and a mesh model. From a protocol perspective the same open standards can be used to engage in attribute distribution. This work item will investigate feasibility, security and privacy implications of at least two protocols.
- Attribute based authorisation. Service providers will base authorisation on a combination of IdP and community provided attributes. This work item validates the investigations done in JRA1 with at least two real service providers as they exist in participating R&E communities. In collaboration with NA3, LoA requirements with regard to authorisation attributes will be considered and tested.
To address the attribute management topic we started two pilots:
- A pilot to test components for attribute management in the context of the EGI community. Access to the various services should be granted based on the VO roles the user have and expressed in attributes. Back-end services should not have to deal with the complexity of multiple IdPs/Federations/Attribute Authorities/technologies.
- A pilot to test components for attribute management in the context of the BBMRI ERIC. Here the aim is to establish a full fledged standardised AAI infrastructuur for the BBMRI ERIC community to enable access and authorisation to shared biomedical resources with appropriate level(s) of assurance
In both pilots the IdP/SP proxy approach has been adopted to handle all complexity.
...