~~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 =====
  * 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

==== 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]]