Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision | ||
de:aai:eduid:architektur [2020/01/07 04:33] – angelegt Wolfgang Pempe | de:aai:eduid:architektur [2020/01/20 14:31] – Pfeiffer, Ramon | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
+ | ~~NOTOC~~ | ||
====== edu-ID – Versuch einer Architektur ====== | ====== edu-ID – Versuch einer Architektur ====== | ||
- | Die im folgenden | + | Die folgenden |
+ | ==== Kernanforderungen an ein edu-ID System ===== | ||
+ | * Unterstützung zentraler edu-ID Use Cases | ||
+ | * Onboarding | ||
+ | * „Wiedererkennen“, | ||
+ | * 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/ | ||
+ | |||
+ | ==== Anforderungen an Heimat-IdPs ==== | ||
+ | (werden durch ein edu-ID System nicht überflüssig, | ||
+ | * Müssen edu-ID (den Identifier) lokal im IdM führen | ||
+ | * …und in der Lage sein, Attribute mit dem edu-ID-System zu synchronisieren, | ||
+ | * 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). | ||
+ | | ||
+ | ==== Optionen für eine technische Lösung ==== | ||
+ | * Modell SWITCH: Ein zentraler IdP, der in der Lage ist, die IdPs der teilnehmenden Heimateinrichtungen zu emulieren | ||
+ | * Hybrid-Modell: | ||
+ | * Dezentrales Modell: edu-ID-System liefert lediglich den Identifier und die von den Usern zur Verfügung gestellten Kernattribute | ||
+ | |||
+ | ==== Favorisiertes Lösungsmodell ==== | ||
+ | * 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“, | ||
+ | * Attribut- und Identitäts-Aggregator | ||
+ | * Von edu-ID abgeleitete Identifier: | ||
+ | * (targeted) pairwise-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, | ||
+ | * 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) | ||
+ | |||
+ | ==== Registrierung und erstes Onboarding ==== | ||
+ | {{de: | ||
+ | |||
+ | ==== Account Linking und Attribut/ | ||
+ | {{de: | ||
+ | |||
+ | ==== edu-ID-System als Proxy ==== | ||
+ | {{de: | ||
+ | |||
+ | ==== Ressourcen & Links ==== | ||
+ | Informationen zu [[http:// |