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

Compare with Current View Page History

« Previous Version 20 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.

It was used a set of dummy users registered in the testbed IdP. In COmanage it was created some collaborations (CO) which have a corresponding project into OpenStack in order to map properly the users.

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 particuale OpernStack project with different rights (either admin or simple user).

Schema

TBA

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

 

1.

a) some research collaborations (CO) were created on a COmanage instance. In our case aarc-white.pilots.aarc-project.eu, aarc-yellow.pilots.aarc-project.eu and aarc-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

 
2.Opestack dashbord login page 
3.choosing idp 
4.idp login 
4.personal information consensus 
6.successfully access 
   
   
   
  • No labels