AAI Basics

Marcus Hardt

April 2021



Goals of this talk

  • Understand what AAI can do
    • Including the VO Concept
  • Understand what AAI can not do
  • Understand the general architecture
    • EOSC AAI
    • Helmholtz AAI
    • Your AAI

Why AAI?

“eduGAIN age”

  • A huge chaos?
  • Can we organise the Chaos?
  • Is it worth the Effort?
  • What are the Benefits?

Benefits

  • Users from Research and Education - Worldwide
    • 60 National Federations
    • 2,800 identity providers
    • 27,000,000 students, researchers and educators
  • Services in Research and Education: 1,800 service providers

    • More Benefits

    • No userdatabase at services: Reduces Work
    • Up-to-date User Data
    • Minimise accounts per person
    • Single Sign On
      • Log in once, access all services
    • Share identities across multiple services
      • Collaborate on common [Data|CPU|Science]
    • Delegated / Third Party    Authorisation Management
    • Works today (on a small planet)

    Authorisation Management

    • Two sources of authorisation:
      1. Based on Home Organisation
        • Who you are (Staff, Student, Guest)
        • Quality of identity (Passport verified, …)
        • Specialties (Home-Org accepts pay-per-use scheme)
        • …
        • => Home Organisation (HO) concept
      2. Based on Community
        • What you do
          • climate -> ozone -> south-pole
          • cern -> cms -> admin
          • …
        • => Virtual Organisation (VO) concept
        • Very similar: HPC compute projects

    Organisation of Authorisation

    • HO Admins categorise employees
    • VO Managers can administer community members
    • Services can filter users by
      • HO Attributes
        • Staff, Student Guest
        • Passport verified
        • Pay per use
      • VO Attributes
        • climate -> ozone -> south-pole
        • cern -> cms -> admin

    Result

    • Yes, there are Benefits
    • Yes, we can organise the chaos

    • Yes, we can meet existing requirements

    Organisation

    AARC

    Authentication and Authorisation in Research Communities

    • AARC + AARC2
    • Outcomes:
      • AARC Blueprint Architectures (aka: AARC BPA)
      • AARC Policy Development KIT (aka: AARC PDK)
      • AARC Guidelines for interoperable AAI (AKA: AARC-G0XY)
    • Results approved by the AEGIS group
      • ( AARC Engagement Group for Infrastructures (AEGIS)

    Typical Approach in IT:

    • Add an additional layer of Abstraction
    • Organise a Hierachy

    • Make use of Standardisation

    Abstraction

    Hierarchy

    Standardisation

    Implementations of AARC BPA

    Context with EOSC

    • These are all used in EOSC

    Implementations of AARC BPA / EOSC AAI

    • B2Access
    • eduTEAMS
    • EGI Check-in
    • Helmholtz-AAI
    • Indigo IAM
    • Perun

    Helmholtz AAI Basics

    • EOSC compatible
      • AARC Blueprint Architectures (BPA)
      • AARC Policy Development Kit (PDK)
    • Users supported via
      • DFN-AAI / eduGAIN
      • Social: ORCID + Github + Google
      • Homeless Users: Can easily be supported
    • Works in Production today
      • Ready to include more services
      • Ready to include more Communities
        • E.g. NFDIs

    Authorisation

    • Support for multiple means of authorisation (central and de central)
      • Group Membership (aka “Virtual Organisations”)
        • => Managed by Scientists themselves
      • Entitlements from Home-Organisation
        • => Managed by Administration
      • Levels of Assurance: REFEDS Assurance Framework
        • Passport seen, Work-Contract available
        • Uniqueness of the identifier
        • Freshness of attributes
      • Membership in Home-Organisation

    Service Integration

    Bottomline

    • Do not build your own AAI
      • you are likely to repeat stone, bronze, and iron-age
    • Some communities are already organised
      • i.e. they run their own community AAI (which is fine)
    • Users always live in the context of their community AAI
      • Makes it difficult to cooperate across community borders
    • But: Users can be members of multiple communities
      • Example:
        • Access HZDR gitlab => Automatically authenticates me with Helmholtz-AAI
        • Access to Federated-Cloud’s OpenStack => Automatically authenicates me with EGI Check-in