NFDI Background

• NFDI: National Research Data Initiative
• https://nfdi.de
• Three rounds of calls
• 27 Consortia (call 1 + call 2 + call 3)
  • To span many different scientific disciplines
    (social, humanities, engineering, earth, chemistry, physics, …)
• ~ 90 M€/a
• 5a + (potential extension: 5a)

NFDI Background

• NFDI first focussed on consortia
  • asked (infrastructure) questions later
• Identity and Access Management
  • Initially not in focus
  • Added in 3rd call via “Base4NFDI”:
    Basic services: Persistent Identifiers (PID), Metadata, Multicloud, IAM, …
• IAM4NFDI Project submitted (during last years fim4r)
  • Active Phase officially starts on Feb 1st 2024
  • Funding 6FTE until Jan 2026

IAM4NFDI Goals

(Based on requirement analysis run before proposal)

• Provide state of the art IAM to all NFDI Consortia
• Use home organisation identity
• Enable delegated group management (Virtual Organisations)
• Open for NFDI and beyond
• Compatible with AARC / EOSC
• Community AAI as a Service!

Project status

• We have an architecture ✅
• We have a set of attributes ✅
• We have the initial set of policies ✅
• We have the initial documentation ✅
• We have the demonstration Community AAIs up and running ✅

All documented at https://doc.nfdi-aai.de

Documentation

Technical Details tl;dr

• Based on AARC outputs
• Both SAML and OIDC supported
• Including the German eduID
• Standardised set of attributes
  • Following EOSC AAI spec
  • Added ssh_public_key
  • Pushing voperson_external_id (and orcid)
• Supporting three independent components for authorisation
  • Assurance (RAF)
  • Community Attributes (entitlement mainly for expressing VO/group membership)
  • Home Organisation attributes
• Well established contact mailinglists:
  • Core Team: aai-kernteam@lists.kit.edu (email)
  • General Information list nfdi-aai-info@lists.kit.edu (subscribe)

Community AAIs

• Demonstration instances of all CAAI Softwares available
• Supported softwares:
  • AcademicID:
    • Operated and developed by GWDG
  • didmos:
    • Operated and Developed by DAASI international GmbH
  • Reg-APP:
    • Operated and developed by KIT
  • Unity:
    • Operated by FZ-Jülich
    • Developed by BixBit / AuthVizor

Consortia <-> CAAI map

Policies

• Exploiting the AARC Policy Development Kit
• Users (in Helmholtz-AAI) were unhappy with defining the VO AUP
  • Unsure about which responsibilities are actually taken
  • Asking their legal department for advice
  • Spending months to establish VOs
  • Way out
    • Split AUP into VO-AUP and CAAI-AUP
      • VO-AUP is minimally minimal
      • Users agree to CAAI-AUP on first login
• Users (in particular Service admins) were unhappy with “too many policies”
  • Way out
    • Colorise policy table
• Open questions
  • Should we expose SNCTFI to Home Organisations? (Experience, anyone?)

Operational Concept

• Operation of infrastructure Components (CAAIs, InfraProxy, …)
  • Best-Effort during the project phases (5-10 a)
  • Sustainability models are being evaluated during the project
    • Along with all NFDI services at large
• Legal definition (25 pages and growing) of all AAI components
• Defines operation of CAAI for NFDI Consortia
  • Provides operations and service options:
    • “included via project funding”
    • bespoke “additional” services
• Production operation of CAAIs is currently starting

CAAI - InfraProxy

• ~27 CAAIs + 2-3 InfraProxies
• Set up a small SAML federation first
  • Make use of entity categories as part of DFN-AAI
• Later: use the setup for other protocols
  • OIDC
  • OpenID Federation
• Likely SATOSA with a small SAML federation between CAAI and InfaProxy

Tool: naco

Upcoming

• Support AARC-G071 at CAAIs
• Make sure key messages are better understood:
  • We (IAM4NFDI Project) operate one of four CAAI Products as a service for each of the 27 NFDI Consortia
  • Consortia have to choose one CAAI solution
  • We develop the Infrastructure Proxy
  • Once it is there, services for multiple NFDI-Consortia are migrated from CAAI to InfraProxy