Dies ist eine alte Version des Dokuments!


edu-ID – Versuch einer Architektur

Die folgenden Ausführungen basieren auf den Ergebnissen des Workshops im November 2019 in Bamberg. Siehe hierzu auch die seinerzeit erstellten Notizen und das zugehörige Tafelbild.

  • Unterstützung zentraler edu-ID Use Cases
    • Onboarding
    • „Wiedererkennen“, Unterbrechungsfreie Nutzung von Diensten
    • Account Linking, Aggregation von Attributen und Identitäten („Affiliations“)
  • Nutzung lokaler bzw. einrichtungsspezifischer Service Provider muss weiterhin möglich sein
  • Idealerweise ein einziger IdP als Authentifizierungsquelle (also nicht edu-ID-IdP versus Heimat-IdP)
  • Vergabe/Generierung einer edu-ID erfolgt zentral –> zentraler IdP für Onboarding

(werden durch ein edu-ID System nicht überflüssig, übernehmen aber fallweise eine andere Rolle)

  • Müssen edu-ID (den Identifier) lokal im IdM führen
  • …und in der Lage sein, Attribute mit dem edu-ID-System zu synchronisieren, idealerweise via Push-API (SCIM), Attribute Query als Not-/Übergangslösung
  • Müssen i.d.R. weiterhin lokale SPs „bedienen“ (oftmals Spezial-Konfigurationen)
  • Heimat-IdP als bevorzugte Authentifizierungsquelle (in edu-ID-Szenarien liefert der edu-ID-IdP die Attribute).
  • Modell SWITCH: Ein zentraler IdP, der in der Lage ist, die IdPs der teilnehmenden Heimateinrichtungen zu emulieren
  • Hybrid-Modell: Heimat-IdPs und edu-ID IdP nebeneinander, edu-ID IdP nur für bestimmte SPs / Use Cases
  • Dezentrales Modell: edu-ID-System liefert lediglich den Identifier und die von den Usern zur Verfügung gestellten Kernattribute
  • Basiert auf Hybrid-Modell
  • edu-ID System erfüllt mehrere Rollen:
    • IdP: für Homeless Users, insbesondere in Onboarding-Szenarien
    • Proxy-SP: Heimat-IdP als Authentifizierungsquelle –> eine User Session (SSO)
      (Use Case „Wiedererkennen“, Unterbrechungsfreie Nutzung von Diensten)
    • Attribut- und Identitäts-Aggregator
  • Von edu-ID abgeleitete Identifier:
    • (targeted) pairwise-id, fallweise auch (unique) subject-id
    • Werden vom edu-ID System generiert
    • … und könnten über einen Data Connector (Web Service) von den Heimat-IdPs abgerufen und gecached werden. Dies kann aber nur eine Notlösung sein! (schwierig für „edu-SPs“) –> SSO besser über Proxy-SP (s.o.)
    • Discovery im „Proxy Modus“
      • Bestmögliche User Experience anstreben
      • Idealerweise keine kaskadierende Auswahl
    • Account Linking, Aggregation von Attributen und Identitäten
      • Push-API (wie SWITCH) zur Provisionierung von Nutzerdaten an das edu-ID-System
      • Verknüpfung von Identitäten erfolgt nicht automatisch, sondern User-gesteuert
      • Essentiell für FIDs und Forschungsinfrastrukturen
      • Um IDs verlässlich zu aggregieren (kein Copy+Paste) bedarf es individueller Lösungen (wie z.B. von ORCID)

  • Zuletzt geändert: vor 6 Monaten