The big picture of AAI

Dr. Marcus Hardt (KIT/SCC)

June 2021



Points of this talk

  • Understand the “why” and “what” of the “modern” AAI
  • Understand what AAI can not do

Before we start: Acronyms

  • SAML: Security Assertion Markup Language
    • Used in the DFN AAI Federation
    • Most commonly used software SHIBBOLETH
  • X.509: Certificates
    • Used by every https connection
    • Usage phased out for user identification
  • OIDC: OpenID Connect
    • Token based
    • Based on OAuth2
    • Microsoft, Google are main drivers
    • WLCG has a roadmap to move there (~1 year)

  • IdP: Identity Provider
    • IdP: SAML
    • OP: OIDC
  • SP: Service Providers
    • SP: SAML
    • RP: OIDC

Why AAI? / The architecture!

“eduGAIN age”

  • A huge chaos?
  • Can we organise the Chaos?
  • Is it worth the Effort?
  • How should it be done?

How should it be done?

  • EU Project AARC
    • Analyse existing Architectures
    • Analyse existing Policies
  • => Give recommendations
    • 21 Final, ~15 more on the roadmap

  • 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 Assesment
      • 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)

Current Status

  • Cross proxy access is not yet supported:
    • => Cross communty access
    • => Cross infrastructures access
    • Fragmented 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

More practical slides

Authentication

  • Home IdP
    • Germany: DFN
    • Globally: EduGAIN
  • Citizen Scientists (aka: homeless users)
    • “Social” IdPs: Google, GitHub, Orcid, umbrellaID
  • Not yet
    • Identity Linking (probably never)
    • National e-ID (probably sooner)

Authorisation Management

  • Based on Community
    • What you do
      • climate -> ozone -> south-pole
      • cern -> cms -> admin
      • …
    • => Virtual Organisation (VO) concept
    • 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

Assurance

  • Levels of Assurance according REFEDS Assurance Framework
  • Allows services to distinguish users
    • Passport seen
    • Work contract available
    • Member of Home Organisation
    • Social Media
  • Benefit
    • AAI can host “lesser-than-maximum” users
    • Scientists only need to upgrade their identity, if necessary to access service

Implementations of AARC BPA

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

Helmholtz AAI

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

  • Integration of additional concept:
  • Home-IdP based approach
    • Home IdP can assert complementary information
    • Employee / Student / Guest
    • Home-Org may assert users eligibility to use certain resources (BW use case)
  • Virtual Organisation approach
    • VOs are managed centrally in the AAI
    • VOs are managed by decentral PIs
    • Automatic VO: Each user is a member of a VO that corresponds to the Home-Organisation
  • Levels of Assurance: REFEDS Assurance Framework
    • Passport seen, Work-Contract available
    • Uniqueness of the identifier
    • Freshness of attributes

Service Integration

Q&A / Demo

Example Services

How to join?

  • As a service:
    • “Simply” connect your service to the AAI of your choice:
      • Technical: registration of a client (this may even be optional)
      • Policy:
        • Read, understand and accept the policies
        • Write + publish the bits of your policy (Security contact, Privacy Statement)
      • Understand and implement the authorisation you need
        • Which VOs do you support
        • Which other attributes are relevant for you
        • Which assurance do you require
    • Services can connect to multiple AAIs at the same tim
  • As a user:
    • You have no choice
    • Whatever the service supports is available
    • Most Institutions already operate IdPs (check https://met.refeds.org)

Bottomline

Summary

  • 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 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

Open Questions

  • Should NFDI e.V. recommend one or more AAIs ?
    • What consequences would such a choice have ?
  • How do we organise VOs?
    • How fine-grained?
    • How coordinated?
  • Do we need agreements between NFDI e.V. and one (or more) AAIs?
    • To host our VOs
    • To host the increased traffic through
      • more users
      • more Services
      • more login activities
  • What would be a contribution NFDI can give back to the AAIs ? Appreciation ? Money ? Active developers ?

Backupslides

Edugain numbers

  • 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)