Jump directly to the page contents

AAI Workpackage

The AAI Workpackage of HDF agreed in August 2017 to follow up on the European approaches that are specifically expressed in the AARC recommendations.

The overall architecture will follow the AARC Blueprint Architecture (AARC BPA). This will allow the integration of users and services. Users exist in several topologies and technologies (DFN-AAI/SAML, Grid/X.509, Social Identities / OIDC). The focus will be on users from IdPs in DFN-AAI, which is based on SAML. Services can be accessed via several different technologies. Targeted within HDF AAI are SAML, OIDC, and X.509. The focus will be on OIDC (OpenID Connect) services.  The SP-IdP-Proxy and a Token Translation Service, as defined in the AARC BPA, will allow the translation between the different technologies.

The choice of different preferred technologies for users and services is intentional and can be explained in detail on request.

Goal of HDF AAI

The goal is to enable several stakeholders with a Helmholtz background to accomplish several tasks:

  • Enable the participating Helmholtz Centres to provide services to well defined sets of federated users, based on solid authentication and authorisation.

  • Enable Principal Investigators at Helmholtz Centres to allocate resources on behalf of their group and to manage the authorisations for the members of their groups.

  • Enable global researchers to use services provided by Helmholtz Centres - given they are properly authorised and their identity is adequately understood.

  • Be in line with european activities that focus around the European Open Science Cloud EOSC

How to join

Here we describe the various options for joining the HDF AAI 

1. As a service

Participating datacentres that want to provide services are encouraged to use OpenID Connect (OIDC). Since SAML and X.509 are well understood, they will not be described here. For HDF we use unity as an OpenID Connect Provider (OP). Please note that unity does also work as a SAML IdP, should you need to integrate a SAML SP. Two unity installations are available:

for integration testing

for production (not used at time of writing (Jul 2018)

Please note that a potentially very large number of users can authenticate to your service, once you have integrated it. Therefore, you should understand how you can use the “groups” claim to only allow users for the Virtual Organisations that you support.

In OIDC you need to register a client (or relying party, RP) with an OIDC-Provider (OP). To do this:

  • make sure you don’t have an active login in unity and visit the /home endpoint (i.e. https://unity.helmholtz-data-federation.de/home)

  • Click “Register a new account” on the top right

  • Specify the required information and note that “User name” is your clientID and “Password credential” is your clientSecret.

Additional steps are client specific. In particular you should check the group membership.

Howtos for a few (non-obvious) clients exist here:

OpenStack

Please make sure to use the groups claim to filter for the Virtual Organisations that you support. You are free to filter using other claims, but please be aware that not all entries may be available in future versions of the HDF-SP-IdP-Proxy.

Please be aware, that you are required by law to provide a privacy policy for you service, for which you can find a good (i.e. GDPR/DSGVO compatible) template in the Appendix of the Policy Starter Pack. Also you should be aware of the HDF Acceptable Use Policy (AUP) and check, if this works with your service. Contact us, if this is not the case.

2. As a Virtual Organisation (Principal Investigator)

If you want to manage a group that needs to access several federated services, you need to create a Virtual Organisation (VO). For this you need to (brief for now, to be extended)

  1. Acquire group management rights in unity administration (/admin endpoint)

  2. Find services that want to support your VO.

  3. Agree on an Acceptable Use Policy (AUP) with the managers of the services you want to use

  4. Add users and yourself to the group and start using the services

3. As a user

As a user you need to be able to log in to

for integration testing

for productive use

Currently available login mechanisms supported are

  • Your home-IdP of the organisation you work for

  • In case that one does not meet all criteria, you can also use github or ORCID

If you use your home-IdP and you get errors from unity or login, you should first consult the administrator of your home-IdP (MET might help you finding him, search for the hostname of your IdP to find your admin contact). Inform them that you need them to release the R&S attribute set to unity and login.

4. Contacts

The coordinator of the HDF AAI group is Dr. Marcus Hardt. The whole group is currently active on this mailinglist: HDF AAI​​​​​​​.

Available Services

Integration Testing (List of services available here)

Unity (SP-IdP-Proxy, Attribute Authority):

Site: FZJ

Supported VOs: All

URL: https://unity.helmholtz-data-federation.de

Comment: Central login Group Management

WaTTS (Token Translation)

Site: KIT

Supported VOs: All

URL: https://watts.helmholtz-data-federation.de

Comment: Get IGTF-IOTA certificates here (11-day certificates) SSH Keys

Prometheus (dCache/webDAV)

Site: DESY

Supported VOs: Unspecified

URL: https://prometheus.desy.de

Comment: Test dCache storage serve, rebuilt daily, not for data storage

KIT OpenStack Test Service

Site: KIT

Supported VOs: myExampleCollab

URL: https://oscloud-1.scc.kit.edu

Comment: OpenStack with Novadocker

Monitoring

Site: GSI

Supported VOs: GsiUserGroup

URL: https://hdf-mon.gsi.de

Comment: INCINGA2 for monitoring components of HDF

Unity (SP-IdP-Proxy, Attribute Authority)

Site: FZJ

Supported VOs: All

URL: https://login.helmholtz-data-federation.de

Comment: Central login Group Management

As curious as we are? Discover more.