Marcus Hardt (on behalf of the HIFIS AAI Task)

April 2022

General Part: Architecture

Concept for modern AAIs

  • EU Project AARC
    • Analyse existing Architectures
    • Analyse existing Policies
  • Give recommendations
  • AARC Blueprint Architectures
    • Introduction of the “proxy” component
  • 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
    • (Designed to be GDPR compliant)

The “proxy” component

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

Evolution of the BPA (~2019)

One specific Community AAI:
Helmholtz AAI

Relation to DFN AAI


  • Home IdP
    • Germany: DFN
    • Globe: EduGAIN
    • Others: Google, GitHub, Orcid, umbrellaID, …
  • Not yet
    • Identity Linking
    • National e-ID

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

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

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

Interfaces for Service Integration

  • Translation between Multiple Protocols:
    • Identities: SAML, OpenID Connect, X.509
    • Services: OpenID Connect, SAML
  • Examples for integrated services
  • More docs at Helmholtz AAI:

Adanced example:
Keycloak Infrastructure proxy

  • Use case:
    • DESY operates the dCache storage infrastructure
    • Local DESY users already possess data (Terabytes)
    • Goal: Allow external users, while not touching existing internal ones
  • Solution
    • Yet Another Proxy! (known as “Infrastructure Proxy”)
    • In this case: Keycloak
      • Handle incoming users
      • Check with local user-db
      • Forward user to services (dCache is just the first one)
  • Result:
    • Authorisation delegated to VO Managers
    • Reuse existing infrastructure setup (no additional instance of dCache)
    • A single infrastructure proxy allows connection of legacy site services

Helmholtz AAI: Numbers


Design Constraints

  • Infrastructure Proxies
    • Collect infrastructures
    • Provide them to Communities
  • Cross community access is not trivial to support
    • Different identifiers issued by different community AAI
    • Key question: What is a good size for a community:
      • The Community of German Researchers
      • The community of Bavarian Alpine Yeti Researchers
  • Fragmentation should be avoided!!!
  • Identity-linking is not supported:
    • This is a major effort
    • Creates a lot of problems in the details
    • Hell breaks loose, when deprovisioning linked accounts



  • Do not build your own AAI
    • You are likely to repeat some of the stone, bronze, and/or iron-ages
    • You will increase the fragmentation of communities and resources
  • Some communities are already organised
    • I.e. they run their own community AAI
    • Why not join forces with them?
  • Users always live in the context of their community AAI
    • Many AAIs will cause fragmentation
    • Difficult to cooperate across community borders