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
• Einrichtungsunabhängiges, unterbrechungsfreies Single Sign-On
• 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)