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/12/05 11:22]
Wolfgang Pempe
de:aai:eduid:eduid_intern:req_tec [2020/02/12 10:19] (aktuell)
Wolfgang Pempe
Zeile 23: Zeile 23:
 | {{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: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, automatisierte Prozesse für Mail und Handy-Nr, automatische Anhebung des Qualitätsniveaus bei Attributübernahme von einer Affiliation | | {{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, implementiert für die Basisattribute im [[https://www.switch.ch/edu-id/services/attributes/extended-model/|"Extended Model"]] |+| {{anchor:t05:T05}} | assurance | Übermittlung der Information, welche Attribute welche Verlässlichkeitsstufe haben | Zu prüfen, ob die von [[https://www.switch.ch/edu-id/services/attributes/quality-levels/|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, nutzergesteuert und servicegesteuert siehe [[https://www.switch.ch/de/edu-id/services/two-step-login/|hier]] | | {{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, 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: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]] |
Zeile 42: Zeile 42:
 </WRAP> | ja, Dritte können über speziell vereinbarte Prozesse servicespezifische Entitlements setzen, weitere Attributquellen (wie z.B. Gruppeninfirmationen) aktuell nicht implementiert | </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: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: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> | {{anchor:t16:T16}} | allgemein | Deprovisionierung: Möglichkeit, Dienste über das Ausscheiden eines Nutzers zu informieren | Ausscheiden aus <WRAP>
   * Heimateinrichtung   * Heimateinrichtung
  • Zuletzt geändert: vor 11 Monaten