This subtasks deals with the pilots for attribute management

• Authentication technologies. New user User communities prefer using technologies for authentication different from X509 digital certificates, for example to use username/password based authentication.

• Single sign on. Users should be enabled to use their institutional credentials to access EGI services. One  barrier  for  new  users  is  that  they  have  to  obtain a  new  credential  to  access  the  e­infrastructure.  In  some  cases, this  is  just  an  inconvenience,  yet another  credential  to  manage,  but  for  some  users  (those  outside institutions  or the  major  IdP  federations) it  may  be  not  possible  to  obtain  such  a credential.  User  friendliness  is  of  course  a  major  feature  for  any  Single Sign On  capability.the services.

• Community attributes-­based authorization. Community-based authorization has been implemented in EGI from the beginning, and is at the basis of the collaborative nature of EGI. It is fundamental for EGI that every AAI technology and architecture enables the communities to manage the capabilities and the roles of their users, and to let these attributes be used by the services to regulate the authorizationthe core feature for a scalable authorization management in a scenario with federated service providers and distributed communities. Given the scale of the EGI service, most e-infrastructures and research infrastructures, service providers cannot implement per-­user authorization, but must authorize a the user based on the attributes associated to that user.
• Non-­web access. EGI services are accessible natively by command line clients, implementing the services’ standard APIs. While there are several options for users to use web-­tools to access the resources, authentication must consider both web and non-­web access scenarios.
• Delegation. EGI services allow complex workflows, and users often submit thousands of computational tasks that need to access other resources (e.g. storage) on their behalf. The authentication technology must support delegation, either natively or through credential translation to another technology. Without delegation EGI users cannot get the full potential of the services.
• Scalable policies for attribute release. EGI is a highly distributed infrastructure, with hundreds of service providers, hundreds of communities, and tens of thousands of users. In this scenario, it is critical that the policies and the procedures are scalable with the number of actors involved.
• PID for users. EGI foresees the need for a user unique and persistent identifier. One use case is to map multiple credentials to a single user. A second use case, and in particular for an EGI-­specific unique identifier, is to share authorization assertions between EGI services, which may not be possible when using an IdP-­provided user UID.
• LoA management. EGI supports a very diverse set of use cases. Open data is a typical use case where a very large community of users can access a data set, but there is need for a lightweight authentication, for example to account for the number of actual users using a service. In this example, EGI needs to enable users without the need for ‘expensive’ high assurance credentials. Clearly service providers must be able to extract information about the LoA from the attributes associated to the user identity. LoA definitions should be standard and simple, so as not to over-­complicate the service provider’s decision as to whether or not to allow the user task.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 use cases have been translated to requirements and have been described more extensively in the Deliverable "DJRA1.1:Analysis of user community and service provider requirements" 
Page 18 of this document provides a dedicated description of the issues.....currently face with regard to federated identity management. Requirements R1, R3, R5, R6, R7, R8, R9, R14, R15, R16 and R_P_3 (see page 33 and onwards) are applicable to this context and have been guiding our work in this pilot. 

Proposed and piloted solutions to address these issues

The pilot testbed we set up 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 usage use of an IdP proxy is convenient becausehas 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
• 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

Requirements	Components in Blue Print Architecture	Status and Results
Requirements R?.....R?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

Information about the Openstack pilot set-up

We deployed an Openstack testbed on two virtual machines:

...

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:

...

• When trying the federated login via the SAML authentication, if you get the following error page:

...

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:

...

• the registry admin is professor3
• created for the moment 2 3 COs: aarc-white.pilots.aarc-project.eu,aarc-yellow.pilots.aarc-project.eu and aarc-yellowblue.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:

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

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