Technische Anforderungen an ein edu-ID System

(zurück zur Übersicht)

Work in Progress

Wolfgangs Baustelle (Ergänzungen sind aber stets willkommen :-) )

Kategorien

Name Kürzel
Allgemein common
Nutzer*innen user
Heimateinrichtungen homeorg
Datenqualität (Integrität) integrity
Datenqualität (Assurance) assurance
Aggregation aggreg
Sicherheit security

Liste der Anforderungen

Nr. Kategorie Anforderung Bemerkungen/Fragen Feature
SWITCH edu-ID
T01 allgemein Hochverfügbarkeit Sollte das Konzept jemals realisiert werden, ist mit sehr hohen Zugriffszahlen zu rechnen ja, in Umsetzung
T02 integrity Dublettenvermeidung,
Zusammenführen von edu-ID Accounts
Zusammenführen als separate Anforderung? ja, wurde als nutzergesteuerter Prozess umgesetzt, betroffene SPs werden informiert
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
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
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 RAF orientieren. ja, implementiert für die Basisattribute im "Extended Model"
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 REFEDS MFA ja, nutzergesteuert und servicegesteuert siehe hier
T07 security Mindestanforderungen an Passwörter Zu prüfen, ob die von SWITCH implementierten Mechanismen für uns ausreichen. Unterstützung REFEDS SFA. Wichtig auch die Prozesse und Policies zur Account-Erstellung und Credential-Vergabe ⇒ organisatorische Anforderungen ja, basierend auf aktuellen NIST-Empfehlungen siehe hier
T08 security Technische Maßnahmen zur Betriebs-/Informationssicherheit kritische Infrastruktur?
⇒ Audit/Zertifizierung, Datenschutz-Folgenabschätzung
ja, ISMS/ISO27001 vorgesehen
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?)
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)
T11 homeorg edu-ID im IdM der teilnehmenden Heimateinrichtungen Voraussetzung für praktisch alle Use Cases; auch organisatorische Anforderung (O03) ja
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
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…
  • Prüfen, ob die von SWITCH implementierten Mechanismen für uns passen
  • Datenschutz
  • Dauer der Speicherung solcher Angaben? Dürfen sie von den Usern gelöscht werden?
  • Wie kann sichergestellt werden, ob die Daten noch aktuell sind?
  • Ehemalige Affiliationen unbegrenzt speichern?
  • 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.

ja, Dritte können über speziell vereinbarte Prozesse servicespezifische Entitlements setzen, weitere Attributquellen (wie z.B. Gruppeninfirmationen) aktuell nicht implementiert
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
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)
T16 allgemein Deprovisionierung: Möglichkeit, Dienste über das Ausscheiden eines Nutzers zu informieren Ausscheiden aus
  • Heimateinrichtung
  • Akademischer Sektor
  • Gruppe / Virtuelle Organisation
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“
  • Zuletzt geändert: vor 3 Tagen