edu-ID – 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)