Sander Apweiler (FZJ), Marcus Hardt (KIT), Uwe Jandt (DESY), Andreas Klotz (HZB)

October 2021


  • Motivation
  • Architecture
  • Implementation
  • Developments


Historical records

  • Helmholtz Data Federation (HDF) needed an AAI (back in 2017)
  • Proof of Concept implementation of the AARC Blueprint Architecture
    • SP-IdP Proxy (in eduGain)
    • 4 Initial services (Nagios, OpenStack, dCache, WaTTS, …)
    • OpenID Connect as a primary target
  • Adaptation of the AARC Policy Development Kit
    • Security + Trust
    • Policy Compatibility with large infrastructures (WLCG, LIGO, XSEDE, ELIXIR, …)

Then HIFIS started

Helmholtz AAI: Goals

  • Users can access many federated services
    • with the one account of their Home Organisation
  • Seamless access
    • Enable Services for users at Helmholtz Centres and Partners
    • Enable researchers and guests to access Services
    • Very general approach => Don’t be limited by specific organisational structure
  • Enable PIs to manage their own Virtual Organisations (VOs)
  • Compatibility with the European Open Science Cloud (EOSC)
  • Support for services beyond the browser
    • Delegation (Computing Jobs)
    • REST APIs
    • Shell access

Relation to DFN-AAI

  • Overlap only in the acronym “AAI”
  • Helmholtz AAI is one service inside DFN-AAI
    • it’s an SP-IdP-proxy
  • Users come in via
    • DFN-AAI, eduGAIN,
    • And others: ORCID, Github, Google
    • Even “Homeless Users” could be supported



AARC Results

  • AARC Policy Development KIT
    • Fundamental policy templates for
      • Operating an infrastructure
      • Handling Incident Response
      • Manage Members
      • Requirements on Authentication
      • Risk Assessment
      • Data Protection
      • Privacy Policy
      • Service Operation
      • Acceptable Use Policy
      All policies designed to be GDPR compliant
  • AARC Blueprint Architectures
    • Introduction of the “proxy” component

The “proxy” component

aka: “SP-IdP-Proxy”

  • Scalability!
    • Stop every IdP needing to talk to every SP (2800 * 1800)
    • Reliable Attribute release
      • (Different nations, different IdPs, each with different schema)
  • Third party authorisation
    • “Community Attribute Services”
  • Enforcement of authorisation
  • Protocol Translation
    • SAML, OIDC, X.509
  • Stackable

Evolution of the BPA (~2019)



Technical implementation

Helmholtz-AAI Features

  • Well documented at https://aai.helmholtz.de
  • Implements the Policy Development Kit
  • Follows AARC recommendations (a lot of the G0XY documents)
    • <=> To use specific schemas for attributes and their content
    • HIFIS is an (observing) member of AEGIS
  • Focus on OIDC
    • OpenID is not OpenID Connect
    • OpenID connect is defined be the OpenID Foundation
    • The OpenID protocol is deprecated
  • Three levels of authorisation
    • Community based
    • Home Organisation Based
    • Assurance Based

Authorisation Management
Based on Community

  • Virtual Organisation (VO) approach
  • Very similar: HPC compute projects
  • VO Managers can administer community members
  • Services can filter users by
    • VO Attributes
      • climate -> ozone -> south-pole
      • cern -> cms -> admin
  "eduperson_entitlement": [

Authorisation Management
Based on Origin

  • Home-IdP based approach
  • Home IdP can assert complementary information
  • Services can filter users by
    • Home-Org asserted eligibility to use certain resources
    • Status: - Employee / Student / Guest
  "eduperson_entitlement": [

Authorisation Management
Based on Assurance

  • Levels of Assurance: REFEDS Assurance Framework
    • Passport seen, Work-Contract available (Most academic Institutes)
    • Uniqueness of the identifier
    • Freshness of attributes
    • Verified Email Address (Social Media)
  • Benefit
    • AAI can host “lesser-than-maximum” users
    • Scientists only need to upgrade their identity, if necessary to access service
    • Services can provide different levels of access
  "eduperson_assurance": [

Information available at services

    "body": {
        "aud": "oidc-agent-marcus2",
        "client_id": "oidc-agent-marcus2",
        "exp": 1635174663,
        "iat": 1635170663,
        "iss": "https://login.helmholtz.de/oauth2",
        "jti": "c8978ad3-0296-43a4-bad2-1e6045a767a4",
        "scope": "openid display_name sn email profile credentials eduperson_scoped_affiliation eduperson_entitlement eduperson_principal_name eduperson_unique_id eduperson_assurance",
        "sub": "6c611e2a-2c1c-487f-9948-c058a36c8f0e"
    "header": {
        "alg": "RS256",
        "typ": "at+jwt"
    "signature": "PO2KI0-BtyzT98avx3qYmJQzrDHvwkNYPrczoKn_V1udVuUAzoVCO7g9w2XhTIFWOV7mCr7J0edqx3MEuEhi8iq57UDJIUrJto6fw4M84OyxbTlNyjGz6aw8Xm3hqxCvLlKB8840h-58FtbwfuvKjyY5eCs3LnyY84Rjd-Fg3-fsRbIsozfDiVLO_WudOAgbbJx9OzsHcdjargxPt7fnMZzo5RCqgcHT4stEFK7AjYDOIjnB97kTQ0y1yRKLiNo1eSzoNgbdaJctH0GhuHZk1r-S1o4EK5r34kesOoopI9pFtpvwuyQctJFgc71CzSlEBWMz5eEiLzXnRaaqBvIo3g"

    "display_name": "Marcus Hardt",
    "eduperson_assurance": [
    "eduperson_entitlement": [
    "eduperson_principal_name": "lo0018@kit.edu",
    "eduperson_scoped_affiliation": [
    "eduperson_unique_id": "6c611e2a2c1c487f9948c058a36c8f0e@login.helmholtz-data-federation.de",
    "email": "marcus.hardt@kit.edu",
    "email_verified": true,
    "family_name": "Hardt",
    "given_name": "Marcus",
    "name": "Marcus Hardt",
    "preferred_username": "marcus",
    "sn": "Hardt",
    "ssh_key": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAqA5FW6m3FbFhCOsRQBxKMRki5qJxoNhZdaeLXg6ym/ marcus@test2022\n",
    "sub": "6c611e2a-2c1c-487f-9948-c058a36c8f0e"

Connected Services

AAI usage

AAI Developments in Helmholtz

Helmholtz Cloud Agent


  • Goal: Support OIDC on end user computers
  • Initial goal: Unix commandline (linux + mac)
    • Handle all the issues with different OIDC Providers
    • Adequate security features
      • All sensitive information on disk is encrypted
      • Everything (sensitive) in RAM is obfuscated
      • Keep the user from stupid moves
    • Works just like ssh-agent
      • oidc-agent, oidc-gen, oidc-add, oidc-token
      • Including agent forwarding and x-session integration
    • Works well with many OIDC providers
      • Google, Eudat, eduTEAMS, EGI-Checkin, Elixir, Helmholtz-AAI, WLCG, Indigo IAM, KIT, Human Brain, …
  • New goal: Support for GUI environments (windows + mac + linux)


  • Mytokens are a new class of tokens
  • Use case: Long running compute job
    • Longer than lifetime of Access Token
  • Mytoken Server
    • Proxy for Refresh Tokens (RT)
    • Implemented as an extension of OIDC
  • User flow:
    1. Create mytoken (MT)
    2. Use MT to obtain
      • Access Tokens (AT)
      • Other mytokens
[{"exp"        :1634300000,
  "nbf"        :1634400000,
  "scope"      :"compute.create",
  "exp"        :1635300000,
  "nbf"        :1635400000,
  "geoip_allow":["DE", "FR", "NL"],
  "scope"      :"storage.write",


  • Enable ssh via federated identity (OIDC)
    • without recompiling OpenSSH
    • with a clear authorisation concept
  • Solution:
    • PAM module
    • Mapping Daemon
    • Client Wrapper
  • Available for Linux
    • Mac and Windows in development (Putty, maybe: MobaXterm)
  • Test it at https://ssh-oidc-demo.data.kit.edu


  • Integrate more services
    • Large Resources (HPC / Clusters)
  • Spread the technology
  • Interoperate with other Community AAIs
    • How to handle cross-community access?
    • How about OIDC-Federations?
  • Contribute to AARC Guidelines:
    • IdP Hinting
    • SCIM and Deprovisioning
    • Expression of Entitlements
  • Manage expectations, e.g. identity linking

More information