Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
de:aai:eduid:architektur [2020/01/07 04:37] – Wolfgang Pempe | de:aai:eduid:architektur [2021/05/01 18:13] (aktuell) – Wolfgang Pempe | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | ====== edu-ID – Versuch einer Architektur ====== | + | ~~NOTOC~~ |
+ | ====== edu-ID – Architektur ====== | ||
+ | (zurück zur [[de: | ||
+ | |||
+ | Siehe auch [[de: | ||
Die folgenden Ausführungen basieren auf den Ergebnissen des [[de: | Die folgenden Ausführungen basieren auf den Ergebnissen des [[de: | ||
Zeile 8: | Zeile 13: | ||
* Account Linking, Aggregation von Attributen und Identitäten („Affiliations“) | * Account Linking, Aggregation von Attributen und Identitäten („Affiliations“) | ||
* Nutzung lokaler bzw. einrichtungsspezifischer Service Provider muss weiterhin möglich sein | * Nutzung lokaler bzw. einrichtungsspezifischer Service Provider muss weiterhin möglich sein | ||
- | * Einrichtungsunabhängiges, | ||
* Idealerweise ein einziger IdP als Authentifizierungsquelle (also nicht edu-ID-IdP versus Heimat-IdP) | * Idealerweise ein einziger IdP als Authentifizierungsquelle (also nicht edu-ID-IdP versus Heimat-IdP) | ||
* Vergabe/ | * 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:// |