Introduction

HNSciCloud is Pre-Commercial Procurement (PCP) tender for the establishment of a European hybrid cloud platform to support the deployment of high-performance computing and big-data capabilities for scientific research. The project is building a public-private partnership between public research actors and cloud service providers.

As part of the procurement process, the HelixNebula consortium worked with cloud service providers to make them available via eduGAIN to enable federated access to them.

The Helix Nebula use-case was added to the list of potential pilots in AARC2, mostly to provide support for AAI aspects. The AARC2 team was involved in the design phase to present options on how to enable federated access to the procured services.

It was not possible to engage in an active pilot with this community due to the fact that the service delivery model was not completely defined at the time and development work was to be performed by the commercial cloud providers themselves rather than the consortium. The participation of the research collaboration in the development is a prerequisite for a pilot in AARC2; the project does not have sufficient manpower to deliver solution on demand.

Service Providers Needs

Federated access with SAML was a requirement; service providers were therefore asked to implement a SAML SP to connect to a federation and via that to get exposed to eduGAIN, and in parallel to become a relying party of ELIXIR. This is already a challenge task for many service providers.

Some SPs decide to base authorisation decisions not only on affiliation (which is generally provided by the SPs) but also on group information, this information is not available in eduGAIN, but it has to be retrieved by a group management system. Consequently, a group management solution had to be chosen from one of the well-established available offerings.

The choice of some of the service providers to rely on entitlements for authorisation, added an extra layer of complexity as such an entitlement has to be populated by at least the identity providers that participated in the pilot, which is not a trivial process and does not support the long-term aim for integration with existing identity federation practices.

Because each federation has their own documentation, and entities (i.e. IdPs and SPs) cannot join eduGAIN directly, the service providers were confronted with multiple sets of documentation; they would have expected to find all the necessary information in a central point. A testing environment would have been extremely beneficial for troubleshooting. There was a general mismatch of expectations regarding the level of operational support (including a help desk) eduGAIN would provide.

Although there are multiple proxy implementations and service offerings (e.g. EGI CheckIn, GÉANT eduTEAMS, EUDAT B2ACCESS) for different communities, there is no clear understanding of the added value of each, or how sustainable the service offerings are. One commercial cloud service opted for developing/maintaining their own proxy service to ensure long-term sustainability, the other chose to bypass a proxy deployment. A publicly available IdP/SP proxy that could have been leveraged by the Helix Nebula consortium would have made things much easier:

• The services would have had a central point, the IdP/SP proxy, to connect to, rather than trying to get into a federation or doing bilateral testing with ad-hoc IdPs.
• The proxy would be operated in a manner that complies with best practices and minimises problems with authentication and attribute flow.
• The Idp/SP proxy would have offered the same interface and procedures as well as centralise support and documentation.
• The proxy would connect to eduGAIN.
• Authentication would be managed via attributes provided via eduGAIN in combination with information provided via a group management.

Non-web use cases are critical for Infrastructure as a Service providers. Since ECP has largely been declared unsupported, there is no native command-line option. Research services wishing to use command line need to be connected to a complex AAI that follows the AARC blueprint, which is not suitable or feasible for some use cases. In particular, the AARC BPA relies on an established community to operate a proxy. In the case of Helix Nebula, there is no pre-existing community since the objective is that any interested research use case should be able to purchase commercial cloud services.

Pilot description

Two commercial providers developed a prototype to provide commercial cloud services to institutions, leveraging SAML authentication. One provider chose to deploy a proxy, and one did not. In the absence of a proxy, the approach followed by the consortium was to connect different services to different federations via which they would be made available in eduGAIN. However different federations follow different practices so the experience was rather different for each service provider. In the process of testing configuration with selected IdPs, SPs discovered that different IdP may release different attributes, despite policy frameworks (REFEDS R&S entity categories) being in place to streamline the process.

The selected providers have now implemented their own solutions and they will continue with that. There are several take away from this exercise:

• The service delivery model should be defined during if not before the procurement phase
• For similar use-cases (services procured for multiple international research communities), a platform (typically an IdP/SP service + group management) should be made available to support their connection to eduGAIN
• Effort to deploy the platform should be allocated.