You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 37 Next »

By delivering an integrated AAI framework, AARC will improve the federated management and access to the services. We started several pilots to address the needs and requirements of distributed user communities accessing federated services.

Although the use case has been initially modeled on the use case of the EGI Federated cloud services and distributed user communities, the tested scenarios and the results are applicable to a very diverse set of use cases, not necessarily related to EGI.


The requirements demonstrated in the pilot

  • Authentication technologies. User communities prefer to use username/password based authentication.
  • Single sign on. Users should be enabled to use their institutional credentials to access the services.

  • Community attributes-­based authorization. Community-based authorization is the core feature for a scalable authorization management in a scenario with federated service providers and distributed communities. Given the scale of the most e-infrastructures and research infrastructures, service providers cannot implement per-­user authorization, but must authorize the user based on the attributes provided by the IdP and the community.
  • Credential translation services. While the plan is to push forward with the direct support of federated identity technologies for the central tools and the new service types, some services, for example those offering HTC resource, will likely continue to use X509 technologies, therefore credentials translation capabilities are necessary to allow users with federated identity credentials to access the full set of EGI services.

These requirements have been described more extensively in the Deliverable "DJRA1.1:Analysis of user community and service provider requirements 

Proposed and piloted solutions to address these issues

The pilot testbed comprises: a Shibboleth IdP, attribute authorities services (Perun and COmanage), an attribute aggregation service (an IdP proxy on SimpleSAMLphp instance), a cloud framework (OpenStack) as service provider.

The use of an IdP proxy has many advantages:

  • Aggregating the attributes provided by the IdP and the attribute authorities the IdP Proxy acts as a single point of access for the Service Providers,and this makes the configuration for the SP easier
  • Easy to add new attribute authority tools or new IdPs to the pilot, without the need to re-configure any endpoint besides the proxy
  • On a production enviroment, the proxy can  control the attributes and entitlements that are provided to the services
    • For the authorization, services expect to receive certain attributes and entitlements with values in a given format
    • Uniform attributes semantic and syntax across multiple communities/infrastructures will never happen
    • Funnelling all AuthN AuthZ information through an IdP/SP proxy allows to rename/edit/control the attributes
  • Idp Proxy can provide the group information in a different syntax than the one used by the communities, making easier for the

In the service provider Federated AAI has been used in the following configuration:

  • Ephemeral users: the usern is not pre-configured in the SP, but usernames are created using the user UID provided by the Idp
  • The access to the resources is regulated by the entitlements released by the IdP proxy and provided by one of the attribute authorities. Users are mapped into groups pre-configured in the service provider.

 


The current status of this work has been presented at the general AARC meeting in Utrecht in May 2016. See this Slide presentation for more details. SA1.2 Pilots. Updates

Requirements
Components in Blue Print Architecture
Status and Results

 

Requirements R1, R3, R5, R6, R7, R8, R9, R14, R15, R16 and R_P_3 (see page 33 and onwards)

 

Status per June, 1st 2016

(reported in this wiki)

 

Status per June 1st 2016

  • A SimpleSAMLphp instance has been deployed in the AARC testbed:
    • Connected as a SP to the Perun instance at CESNET and the Comanage instance deployed in the testbed
    • Connected as a SP to the test IdP available in the testbed
  • An Openstack Liberty installation has been deployed:
    • the Keystone component has been configured to work in a federated environment;
    • in Keystone, the IdP Proxy Aggregator has been configured as the only  and accepted identity provider.
  • It is used the production instance of perun deployed and managed by CESNET:
    • configured a VO dedicated to the pilot
    • Enabled the IdP proxy and the test IdP in the AARC testbed for this specific VO
  • A COmanage instance has been deployed in the testbed specifically for this pilot:
    • the IdP proxy was configured as the only IdP accepted;
    • it was created a number of Collaborative Organizations to test a multi-tenant scenario
  • Successfully tested the attribute aggregation of attribute authorities and IdP through the aggregator to enable access to a service provider
  • Successfully configured SP to consume authorisation and authentication based on two different attribute authorities
    • Tested access using attributes provided by the IdP and provided by the attribute authorities
    • Different entitlements or attributes regulate access to different keystone groups

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-pilotaarc-pilot2aarc-pilot3
staffadminadminadmin
studentuser  
facultyuseruser 
member adminuser
employeeuseruseradmin

 

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/

Some tech details. 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:

Unauthorized

This 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

  • the registry admin is professor3
  • created for the moment 3 COs: aarc-white.pilots.aarc-project.eu,aarc-yellow.pilots.aarc-project.eu and aarc-blue.pilots.aarc-project.eu
  • at each COs correspond a dedicated project in OpenStack
  • we are testing the user mapping to the several projects in OpenStack: depending on the role in their COs, users have got different rights in their project

In order to implement the mapping based on the attributes provided by COmanage, new projects and groups have been created on OpenStack. We used the COmanage default groups for giving the proper access rights on OpenStack: in general, the "member" group in COmanage grants to "user" role into Openstack, instead the "admin" group grants the "admin" role. In the following tabel it is reported the role owned by each Openstack group in the several projects:

 aarc-whiteaarc-yellowaarc-blue
white-normaluser  
white-superadmin  
yellow-normal user 
yellow-super admin 
blue-normal  user
blue-super  admin

 

Here an example of the SAML assertion attribute provided by COmanage and that we are using for mapping the user:

'entitlement': 'urn:mace:aarc-project.eu:am03.pilots.aarc-project.eu:members:member@aarc-white.pilots.aarc-project.eu;urn:mace:aarc-project.eu:am03.pilots.aarc-project.eu:admin:member@aarc-white.pilots.aarc-project.eu'

Since in the entitlement it is present the value "urn:mace:aarc-project.eu:am03.pilots.aarc-project.eu:admin:member@aarc-white.pilots.aarc-project.eu", the user that has got the admin role in the CO aarc-white.pilots.aarc-project.eu is mapped to the white-super group with the admin role in OpenStack

 

 

  • No labels