edu-ID – Architektur

(zurück zur Übersicht)

Siehe auch AG Technik

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)

Informationen zu SCIM