How do Research Communities build Authentication and Authorisation Infrastructures that support Federated Identity Management? Which software do they choose and how do they make those critical decisions? Over the coming months we will be speaking with various organisations that have gone through this process and created infrastructure that implements the AARC Blueprint Architecture (AARC BPA). 

For this FIM4R Case Study we met with Uros Stevanovic, one of the implementers behind the Authentication and Authorisation Infrastructure (AAI) for the Helmholtz Data Federation (HDF). The Helmholtz Data Federation is a shared infrastructure connecting the 6 large Helmholtz computing centres funded by the German federal government. It aims to offer seamless data transfer, compute and storage between centres. Uros and colleagues took part in the AAI Working Group to design the shared access mechanism at the heart of the project. 

Integrating Identity Providers and Services 

The AAI Working Group stressed the reuse of existing infrastructure, such as SAML identity federations. At the same time they prioritised the use of OpenID Connect (OIDC) within the infrastructure, following trends in all sectors to adopt the OIDC protocol. Unity was chosen to provide the oidc proxy component, partially due to existing expertise at the Research Center Jülich who became the proxy operators. 5 out of the 6 Helmholtz centres already had a SAML Identity Provider (IdP), which could easily be integrated in Unity, along with all other eduGAIN IdPs through the German Identity Federation DFN. In addition to relying on authorisation from the Identity Providers, Unity offers group based authorisation and the ability to quickly and easily create project groups and virtual organisations (VOs). This group based authorisation followed the AARC Guideline for expressing group and role information, facilitating interoperability with future infrastructure and service integration. 

Services that wished to connect to the HDF infrastructure went through a manual registration process. It was expected that they would wish to continue supporting a single Identity Provider (i.e. their own institute) as well as opening access to all Identity Providers supported by HDF. To date there are roughly 20 connected services including the token translation service WATTS and command line client oidc_agent.

Policy

An additional challenge for the HDF was putting a suitable set of policies in place that support best practices in operational security for infrastructures accessed by users from multiple Identity Providers. At the time, Uros was heavily involved in the development of the AARC Policy Development Kit (PDK) and was able to use the HDF as a trial application of the recommended policies, with a few adjustments. Requirements from the PDK were imposed on connecting services and the proxy itself, such as the need for services to display a data privacy policy and for users to follow well defined user lifecycle management processes. Although the REFEDS Assurance Framework was in its infancy, a forward-looking decision was taken to propagate all assurance information down to connected services allowing them to make access control decisions based on those claims. Some of the more complex, combined assurance policies were not natively supported by Unity, which had to be extended.  

Embedding HDF in HFIS

Shortly after the HDF went into production, a second project came along; HIFIS. HIFIS involves a larger number of both services and identity providers with a similar aim to provide shared access to German resources. 

HIFIS Access Architecture, “Unity” represents the HDF AAI

Several of the implementers had previous experience on a successful project that used a full mesh SAML federation to enable access to shared resources. This model does not fall within the AARC BPA Model as requiring each IdP to release coherent authorisation information becomes problematic as the infrastructure scales up. However, a hybrid approach was chosen in this instance. A full-mesh SAML federation was established between the main IdPs (approximately 10 institutes), and the HDF oidc proxy was made available in parallel to allow authentication from the rest of eduGAIN. The project is ongoing and many of the technical and policy challenges have yet to be solved.

Thank you very much to Uros for sharing his insight with us!

ToolDescriptionLink
UnityOpenID Connect Proxyhttps://www.unity-idm.eu
WATTSToken Translation Servicehttps://github.com/watts-kit/watts