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

Compare with Current View Page History

« Previous Version 40 Next »

Introduction

The purpose of the demonstrator is to show with a practical implementation how the group membership attributes or other attributes from multiple sources can be used in a federated environment to regulate access to services.

The use of COmanage, as an attribute authority, for managing the users’ attributes allows to regulate the authorization on services based on externally provided attributes. Such service can be entirely managed by the research community, independently from service providers or identity providers. The use of an attribute aggregator simplifies the configuration at both service provider and attribute authority level. Acting as an IdP proxy, the attribute aggregator is the only entity that needs to be configured in the service provider for authentication and authorization data provisioning.

Detailed description

A detailed description can be find in this wiki page.

The setup consist of:

  • an IdP proxy on SimpleSAMLphp
  • a COmanage server (configured as service provider) as aggregation service
  • a cloud framework (OpenStack) as service provider.

For the purpose of this pilot, we have enabled federated access to the dashboard of a demo OpenStack Cloud deployment and we are using a set of dummy users registered in the testbed IdP. Specifically, the pilot IdP proxy has been configured to authenticate users and communicate the result of the authentication to a COmanage instance using SAML assertions. In COmanage it was created some collaborations (CO) which have a corresponding project into OpenStack in order to map properly the users, so it is added to the SAML assertion any eventual Entitlement regarding the users membership to the COs. At this point the new SAML assertion is passed to OpenStack's Identity service (Keystone), and it is mapped to keystone user groups, based on which, the authenticating user can access cloud resources using their federated AARC ID.

There was no need to create local accounts on the cloud framework, ephemeral users are using instead: it was created a set of mapping rules that, depending on the entitlements provided by COmanage (ownership to the COs with a precise role), associate the external users to the right group defined into openstack, and each of them can access to as particulare OpenStack project with different rights (either admin or simple user).

Demonstration workflow

 

to show through a screenshots serie how the users are properly mapped to a particular project in OpenStack depending on the COs membership in COmanage

add also an explanation how the mapping rules work

a) some research collaborations who want to access to the OpenStack services were created on a COmanage instance. In our case:
aarc-white.pilots.aarc-project.euaarc-yellow.pilots.aarc-project.euaarc-blue.pilots.aarc-project.eu

b) Each CO has got an admin who approves the membership requests

c) There are some users registered

d) Each CO has got a corresponding project into OpenStack, reserved to its members

 

 

1.  
2.

Access OpenStack's Dashboard (Horizon) at https://am02.pilots.aarc-project.eu/horizon

Select "External suthentication and login" and click on "Connect".  

 

 

3.

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

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

4.

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

5a.

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

 

 

6a.

The user is successfuly redirected to the OpenStack Dashboard, mapped to a Keystone user group based on the values of the Entitlement attribute.

In this case the user is accessing to the aarc-yellow project with administrative rights.

5b.

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

 

6b.

The user is successfuly redirected to the OpenStack Dashboard, mapped to a Keystone user group based on the values of the Entitlement attribute.

In this case the user is accessing to the aarc-yellow project with no administrative rights.

 

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

 

 

The user is successfuly redirected to the OpenStack Dashboard, mapped to a Keystone user group based on the values of the Entitlement attribute.

In this case the user is accessing to the aarc-blue project with administrative rights.

   
  • No labels