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.
Kernanforderungen an ein edu-ID System
- 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
Anforderungen an Heimat-IdPs
(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).