Qualität der Authentifizierung (QoA)

Das QoA Konzept befasst sich mit den verschiedenen QoA Klassen und deren Definition und Einstufung. Dabei entspricht jede Authentifizierungsmethode (Credentials, mit oder ohne Zweitfaktor) genau einer definierten QoA Klasse.

Mit der Spezifikation der entsprechenden QoA Klasse im SAML-/OIDC-Föderationsprotokoll ergeben sich folgende Vorteile:

  • Eine Fachapplikation muss sich nicht um die aufwändige Konfiguration der verschiedenen Authentifizierungsmethoden kümmern.
  • Es muss lediglich entschieden werden, welche QoA Klasse für die zu integrierende Fachapplikation gewünscht, respektive gefordert ist. Mit der Spezifikation der entsprechenden QoA Klasse im Föderationsprotokoll, wird automatisch sichergestellt, dass dem Benutzer alle zugelassenen Authentifizierungsmethoden, die mindestens dieser QoA Klasse entsprechen, angeboten werden.
  • Neue Authentifizierungsmethoden, welche in das QoA Konzept aufgenommen werden, stehen so automatisch zur Verfügung, ohne dass die Anwendung angepasst werden muss.
  • Die Einführung von neuen Authentifizierungsmethoden wird so für die Fachapplikation transparent.
Grafik mit QoA Level für FED-LOGIN und BYOs
IdPs FED-LOGIN/BYOI und QoA (Credentials/Abklärungstypen)


IdP+Credential(s)+Abklärungstyp = Qualität digitale Identität

Sowohl die bei einer Anmeldung verwendeten Authentifizierungsverfahren (Credentials) als auch der Grad der Überprüfung (Abklärungstyp) einer Identität sind massgebend für die Qualität einer digitalen Identität. eIAM beschreibt dies als Quality of Authentication (QoA).

Für die QoA40, 50 & 60 gilt, dass die zugrundeliegende digitale Identität nicht einfach selbst registriert ist, sondern abgeklärt (Name, Vorname, Geburtsdatum, Ausweisart und Ausweisnummer). Abgeklärte elektronische Identitäten ermöglichen die Nachvollziehbarkeit, wer damit ausgerüstet wurde und somit wenn notwendig den Regress auf diese Personen.

Identitätsprüfungen haben immer gültige amtliche Lichtbildausweise zur Grundlage sowie die adäquate zeitgleiche Präsenz der damit abzugleichenden Person. Die Ausweise werden registriert

In welchen Fällen müssen Identitäten mit QoA 40, 50 und 60 eingesetzt werden?

  • Zugriff auf IKT-Ressourcen der Bundesverwaltung im Enterprise-Kontext (für interne und externe Mitarbeitende sowie Partner): Die Minimalanforderung ist QoA40.
  • Zugriff auf Daten mit erhöhtem Schutzbedarf. Laut aktueller Zonenpolicy ist QoA50 erforderlich. Dies ist nur mit Hardcrypto-Token wie die Smartcard*, die Access App's oder mittels FIDO-Sicherheitsschlüssel.
    *Der Smartcard-Zwang (QoA60), darf nur noch in begründeten Ausnahmefällen nach Konsultation der BK DTI verwendet werden.
  • Erfordernis des Geschäftsprozesses, die handelnde Person eindeutig identifizieren zu können (Regressfähigkeit): Die Minimalanforderung ist QoA40.
    In bestimmten Fällen kann dies auch durch die Zielapplikation erfolgen, indem beispielsweise eine Ausweiskopie in die Anwendung hochgeladen wird.


Unterschiedliche QoA-Klassen pro eIAM-Stage

Auf Kundenwunsch wurde die Flexibilität unterschiedlicher QoA-Klassen pro Stage in eIAM implementiert. Wenn ein Kunde in einer nicht produktiven Umgebung eine niedrigere QoA benötigt, kann dies unter Einhaltung der folgenden Regeln umgesetzt werden.

Regelung zur Qualität der Authentifizierung (QoA) ▼
×

  1. Verantwortung und Zuständigkeiten
    • Der Schutzbedarf der Applikation mit der resultierenden Schutzstufe definiert die Mindestqualität der Authentifizierung (QoA-Klasse) der produktiven Umgebung.
    • Der Anwendungsverantwortliche bestimmt mit dem zuständigen ISBO die erforderliche Mindestqualität der Authentifizierung (QoA-Klasse) für den Zugriff auf ihre Appliaktions-Instanzen (PROD, ABN und REF).

  2. Ausnahmen in nicht produktiven Umgebungen (ABN/REF)
    • Falls in einer nicht produktiven Umgebung abweichende QoA-Anforderungen gelten, muss dies schriftlich (signiertes Mail) durch den zuständigen ISBO an den eIAM SIE bestätigt werden.
    • Diese Ausnahme ist nur zulässig, wenn keine Daten mit hohem Schutzbedarf verarbeitet werden.

  3. Anforderung der QoA durch die Relying Party
    • Eine eIAM-integrierte Relying Party kann die minimale QoA-Klasse entweder:
      • während der Laufzeit in der Föderationsanfrage an eIAM anfordern.
      • bei der Integration (Definitionszeit) in eIAM festlegen.

  4. Ablehnung der Föderationsanfrage bei fehlender QoA-Angabe
    • Falls die Relying Party weder zur Definitionszeit noch zur Laufzeit eine QoA festlegt, lehnt eIAM die Föderationsanfrage ab.

  5. Durchsetzung der höchsten QoA-Anforderung
    • Falls zur Definitionszeit eine höhere QoA festgelegt wurde, MUSS eIAM diese auch dann durchsetzen, wenn die Relying Party zur Laufzeit eine niedrigere QoA erlaubt.
    • Falls zur Laufzeit eine höhere QoA als zur Definitionszeit gefordert wird, MUSS eIAM ebenfalls die höhere QoA durchsetzen.

  6. QoA in geschützten Zonen
    • Falls die Relying Party in einer Zone mit erhöhten Sicherheitsanforderungen (z. B. SZ+ Basic) betrieben wird, MUSS eIAM die QoA dieser Zone erfüllen.
    • Eine niedrigere QoA kann weder zur Definitionszeit noch zur Laufzeit zugelassen werden, da der RP-PEP (Relying Party Policy Enforcement Point) den Zugriff regelt.

  7. Einheitliches Integrationsmuster für produktive Umgebungen
    • Falls in der produktiven Umgebung eine Zone mit höheren QoA-Anforderungen genutzt wird, MUSS das gleiche Integrationsmuster (mit RP-PEP) in allen Betriebsumgebungen der Relying Party verwendet werden.
    • Auch wenn in tieferen Integrationsstufen (ABN/REF) keine RP-PEP-Zone erforderlich ist, setzt eIAM die produktiven QoA-Vorgaben in allen Umgebungen durch.

  8. QoA-Ausweis im Token
    • eIAM MUSS die QoA im Token an die Relying Party ausweisen.
    • Die Relying Party MUSS sicherstellen, dass die im Token ausgewiesene QoA ihren Anforderungen entspricht.

Spezifikationen

SAML QoA Spezifikation Bisher mussten die Applikationsowner . . .
OIDC QoA Spezifikation Bisher mussten die Applikationsowner . . .
Detail Informationen über QoA (Zugriff nur intern):