Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
de:aai:eduid:eduid_intern:req_tec [2019/08/15 16:37]
Wolfgang Pempe
de:aai:eduid:eduid_intern:req_tec [2019/12/05 11:22] (aktuell)
Wolfgang Pempe
Zeile 1: Zeile 1:
 ~~NOTOC~~ ~~NOTOC~~
 ====== Technische Anforderungen an ein edu-ID System====== ====== Technische Anforderungen an ein edu-ID System======
-(zurück zur [[de:aai:eduid_intern:​start|Übersicht]])+(zurück zur [[de:aai:eduid:​start|Übersicht]])
 <callout type="​danger"​ title="​Work in Progress">​ <callout type="​danger"​ title="​Work in Progress">​
 Wolfgangs Baustelle (Ergänzungen sind aber stets willkommen :-) ) Wolfgangs Baustelle (Ergänzungen sind aber stets willkommen :-) )
Zeile 19: Zeile 19:
 <​datatables paging="​false"​ info="​false">​ <​datatables paging="​false"​ info="​false">​
 ^ Nr. ^ Kategorie ^ Anforderung ^ Bemerkungen/​Fragen ^ Feature \\ SWITCH edu-ID ^ ^ Nr. ^ Kategorie ^ Anforderung ^ Bemerkungen/​Fragen ^ Feature \\ SWITCH edu-ID ^
-| {{anchor:​t01:​T01}} | allgemein | Hochverfügbarkeit | Sollte das Konzept jemals realisiert werden, ist mit sehr hohen Zugriffszahlen zu rechnen | ja | +| {{anchor:​t01:​T01}} | allgemein | Hochverfügbarkeit | Sollte das Konzept jemals realisiert werden, ist mit sehr hohen Zugriffszahlen zu rechnen | ja, in Umsetzung ​
-| {{anchor:​t02:​T02}} | integrity | Dublettenvermeidung,​ \\ Zusammenführen von edu-ID Accounts | Zusammenführen als separate Anforderung?​| ja | +| {{anchor:​t02:​T02}} | integrity | Dublettenvermeidung,​ \\ Zusammenführen von edu-ID Accounts | Zusammenführen als separate Anforderung?​| ja, wurde als nutzergesteuerter Prozess umgesetzt, betroffene SPs werden informiert ​
-| {{anchor:​t03:​T03}} | integrity | Aktualität self-asserted Attributes | Regelmäßige Kontrolle, ob E-Mail-Adressen(n) und sonstige Angaben noch stimmen, existiert die Person überhaupt noch? | ja | +| {{anchor:​t03:​T03}} | integrity | Aktualität self-asserted Attributes | Regelmäßige Kontrolle, ob E-Mail-Adressen(n) und sonstige Angaben noch stimmen, existiert die Person überhaupt noch? | ja, aktuell implementiert sind lediglich Inaktivitätsreminder per Mail, aktuell werden keine Re-Verifikationen gefordert ​
-| {{anchor:​t04:​T04}} | assurance | Validierung self-asserted Attributes | Zu prüfen, ob die von SWITCH implementierten Mechanismen für uns ausreichen | ja | +| {{anchor:​t04:​T04}} | assurance | Validierung self-asserted Attributes | Zu prüfen, ob die von SWITCH implementierten Mechanismen für uns ausreichen | ja, automatisierte Prozesse für Mail und Handy-Nr, automatische Anhebung des Qualitätsniveaus bei Attributübernahme von einer Affiliation ​
-| {{anchor:​t05:​T05}} | assurance | Übermittlung der Information,​ welche Attribute welche Verlässlichkeitsstufe haben | Zu prüfen, ob die von SWITCH implementierten Mechanismen für uns ausreichen. Wenn irgend möglich an [[https://​refeds.org/​assurance|RAF]] orientieren. | ja | +| {{anchor:​t05:​T05}} | assurance | Übermittlung der Information,​ welche Attribute welche Verlässlichkeitsstufe haben | Zu prüfen, ob die von SWITCH implementierten Mechanismen für uns ausreichen. Wenn irgend möglich an [[https://​refeds.org/​assurance|RAF]] orientieren. | ja, implementiert für die Basisattribute im [[https://​www.switch.ch/​edu-id/​services/​attributes/​extended-model/​|"​Extended Model"​]] ​
-| {{anchor:​t06:​T06}} | security | Absicherung des edu-ID Accounts mit zweitem Faktor | Zu prüfen, ob die von SWITCH implementierten Mechanismen für uns ausreichen. Unterstützung [[https://​refeds.org/​profile/​mfa|REFEDS MFA]] | ja | +| {{anchor:​t06:​T06}} | security | Absicherung des edu-ID Accounts mit zweitem Faktor | Zu prüfen, ob die von SWITCH implementierten Mechanismen für uns ausreichen. Unterstützung [[https://​refeds.org/​profile/​mfa|REFEDS MFA]] | ja, nutzergesteuert und servicegesteuert siehe [[https://​www.switch.ch/​de/​edu-id/​services/​two-step-login/​|hier]] ​
-| {{anchor:​t07:​T07}} | security | Mindestanforderungen an Passwörter | Zu prüfen, ob die von SWITCH implementierten Mechanismen für uns ausreichen. Unterstützung [[https://​refeds.org/​profile/​sfa|REFEDS SFA]]. Wichtig auch die Prozesse und Policies zur Account-Erstellung und Credential-Vergabe => organisatorische Anforderungen | ja | +| {{anchor:​t07:​T07}} | security | Mindestanforderungen an Passwörter | Zu prüfen, ob die von SWITCH implementierten Mechanismen für uns ausreichen. Unterstützung [[https://​refeds.org/​profile/​sfa|REFEDS SFA]]. Wichtig auch die Prozesse und Policies zur Account-Erstellung und Credential-Vergabe => organisatorische Anforderungen | ja, basierend auf aktuellen NIST-Empfehlungen siehe [[https://​www.switch.ch/​export/​sites/​default/​edu-id/​.galleries/​files/​09-Secrets-of-eduID-password.pdf|hier]] ​
-| {{anchor:​t08:​T08}} | security | Technische Maßnahmen zur Betriebs-/​Informationssicherheit | kritische Infrastruktur?​ \\ => Audit/​Zertifizierung,​ Datenschutz-Folgenabschätzung | ja | +| {{anchor:​t08:​T08}} | security | Technische Maßnahmen zur Betriebs-/​Informationssicherheit | kritische Infrastruktur?​ \\ => Audit/​Zertifizierung,​ Datenschutz-Folgenabschätzung | ja, ISMS/​ISO27001 vorgesehen
-| {{anchor:​t09:​T09}} | assurance | Übermittlung der Information,​ welches Authentication Profile zum Einsatz kam | Hierfür existieren Mechanismen in SAML und OIDC | ? | +| {{anchor:​t09:​T09}} | assurance | Übermittlung der Information,​ welches Authentication Profile zum Einsatz kam | Hierfür existieren Mechanismen in SAML und OIDC | Ja, (wird für MFA eingesetzt?
-| {{anchor:​t10:​T10}} | user | Kontrolle über die Weitergabe sämtlicher Attribute (User Consent) | Zu überprüfen,​ ob hier auch andere Rechtsgrundlagen als Art. 6.1 a) zur Anwendung kommen sollen => juristische Anforderungen | ja | +| {{anchor:​t10:​T10}} | user | Kontrolle über die Weitergabe sämtlicher Attribute (User Consent) | Zu überprüfen,​ ob hier auch andere Rechtsgrundlagen als Art. 6.1 a) zur Anwendung kommen sollen ​(evtl f)?) => juristische Anforderungen | ja, konsequentes Einholen von User Consent (ausser bei extended model, dort sollen zusätzliche vertraglichen Absicherungen mit SP erfolgen) ​
-| {{anchor:​t11:​T11}} | homeorg | edu-ID im IdM der teilnehmenden Heimateinrichtungen | Voraussetzung für praktisch alle Use Cases | ja |+| {{anchor:​t11:​T11}} | homeorg | edu-ID im IdM der teilnehmenden Heimateinrichtungen | Voraussetzung für praktisch alle Use Cases; auch organisatorische Anforderung ([[de:​aai:​eduid:​eduid_intern:​req_org#​o03|O03]]) ​| ja |
 | {{anchor:​t12:​T12}} | homeorg | IdPs der teilnehmenden Heimateinrichtungen als Attributquellen,​ Attribute-Pull vs. Attribute-Push | Prüfen, ob die von SWITCH implementierten Mechanismen für uns passen | ja | | {{anchor:​t12:​T12}} | homeorg | IdPs der teilnehmenden Heimateinrichtungen als Attributquellen,​ Attribute-Pull vs. Attribute-Push | Prüfen, ob die von SWITCH implementierten Mechanismen für uns passen | ja |
 | {{anchor:​t13:​T13}} | aggreg | Der edu-ID Service muss in der Lage sein, Attribute aus verschiedenen vertrauenswürdigen Quellen zu aggregieren. Das müssen nicht nur die Nutzerverzeichnisse der Heimateinrichtungen sein... ​ | <​WRAP>​ | {{anchor:​t13:​T13}} | aggreg | Der edu-ID Service muss in der Lage sein, Attribute aus verschiedenen vertrauenswürdigen Quellen zu aggregieren. Das müssen nicht nur die Nutzerverzeichnisse der Heimateinrichtungen sein... ​ | <​WRAP>​
Zeile 37: Zeile 37:
   * Wie kann sichergestellt werden, ob die Daten noch aktuell sind?    * Wie kann sichergestellt werden, ob die Daten noch aktuell sind? 
   * Ehemalige Affiliationen unbegrenzt speichern?   * Ehemalige Affiliationen unbegrenzt speichern?
-</​WRAP>​ | ja |+  * Gruppenmanagement / Virtuelle Organisationen 
 + 
 +Generelle Frage: "​muss"​ edu-ID das leisten, oder soll edu-ID dies ermöglichen? ​ Im letzteren Fall würde die edu-ID deutlich schlanker und die Zusammenführung könnte in einem oder vielen externen Diensten erfolgen. 
 +</​WRAP>​ | ja, Dritte können über speziell vereinbarte Prozesse servicespezifische Entitlements setzen, weitere Attributquellen (wie z.B. Gruppeninfirmationen) aktuell nicht implementiert | 
 +| {{anchor:​t14:​T14}} | common | System muss offen sein auch für SP außerhalb der "​Hochschulwelt"​ | Voraussetzung wäre wahrscheinlich Teilnahme DFN-AAI? | ja, über SWITCH AAI geregelt | 
 +| {{anchor:​t15:​T15}} | common | System muss die Möglichkeit bieten, "​Gast"​ Nutzer zu beherbergen. (Use Case Homeless) | Oft werden hierzu "​social"​ IdPs (google, o.ä. eingesetzt | Ja, Gäste können sich eine edu-ID erstellen. Nein, keine Einbindung von "​social IdPs" (fehlende Use Cases) | 
 +| {{anchor:​t16:​T16}} | allgemein | Deprovisionierung:​ Möglichkeit,​ Dienste über das Ausscheiden eines Nutzers zu informieren | Ausscheiden aus <​WRAP>​ 
 +  * Heimateinrichtung 
 +  * Akademischer Sektor 
 +  * Gruppe / Virtuelle Organisation 
 +  * ... 
 +</​WRAP>​ | Ja, Deprovisionierung der Affiliation in edu-ID durch Heimateinrichtung bei Push-Modell,​ oder durch edu-ID bei periodischer Prüfung über Backchannel,​ zudem Information ausgewählter SPs durch edu-ID mitels "​Notifications" ​|
 </​datatables>​ </​datatables>​
  
  
  • Zuletzt geändert: vor 4 Monaten