Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- 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:aai:eduid:start|Übersicht]])
+Siehe auch [[de:aai:eduid:ag8|AG Technik]]
 Die folgenden Ausführungen basieren auf den Ergebnissen des [[de:aai:eduid:ws_nov_2019|Workshops im November 2019 in Bamberg]]. Siehe hierzu auch die seinerzeit erstellten [[https://pad.gwdg.de/pFJfGwNuQ_y7hrLvotYOCw|Notizen]] und das zugehörige [[https://doku.tid.dfn.de/_media/de:aai:eduid:skizze_bamberg.jpg|Tafelbild]].
-====== Kernanforderungen an ein edu-ID System ======
+==== Kernanforderungen an ein edu-ID System =====
   * Unterstützung zentraler edu-ID Use Cases
     * Onboarding
@@ Zeile 8: / Zeile 13: @@
     * 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).
+==== 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: 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
+==== 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“, 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)
+==== Registrierung und erstes Onboarding ====
+{{de:aai:eduid:registrierung_onboarding.png?800}}
+==== Account Linking und Attribut/ID-Aggregation ====
+{{de:aai:eduid:account-linking_sync.png?800}}
+==== edu-ID-System als Proxy ====
+{{de:aai:eduid:authn_proxy.png?800}}
+==== Ressourcen & Links ====
+Informationen zu [[http://www.simplecloud.info/|SCIM]]