...
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 aggregatorsource, for managing the users’ attributes allows to regulate the authorization on services based on externally provided attributes. Such a service can be entirely managed by the research community, independently from service providers or identity providers. It simplifies the configuration at both the service provider and attribute authority level.
...
The setup consist of:
- an IdP proxy based 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 an OpenStack's Identity service (Keystone) using SAML assertions. Before passing the authentication results to OpenStack, the pilot IdP proxy contacts a Comanage COmanage instance, on which it was created some collaborations (CO) have been created that have a corresponding project into in OpenStack for properly mapping the users: it is attached to the SAML assertion attaches any additional entitlement regarding the users membership to the COsof the COs to the SAML assertion. At this point the new SAML assertion is passed to OpenStack 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 used instead: it was created creates 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 a particular OpenStack project with different rights (either admin or simple user).
...