...
- 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 stored the one used by the communities, making easier for the
On the Service Provider side, we can test the user authentication and authorization implementation on a widely deployed cloud framework by using federated identities:
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
- it is not necessary creating local accounts for the users; ephemeral ones will be used
- 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
...
- 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-white | aarc-yellow | aarc-blue | aarc-social | |
|---|---|---|---|---|
| white-normal | user | |||
| white-super | admin | |||
| yellow-normal | user | |||
| yellow-super | admin | |||
| blue-normal | user | |||
| blue-super | admin | |||
| social-normal | user | |||
| social-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