Qualité de l'authentification (QoA)

Le concept QoA traite des différentes classes QoA, de leur définition et de leur classification. Dans ce contexte, chaque méthode d'authentification (credentials avec ou sans second facteur) correspond exactement à une classe QoA définie.

En spécifiant la classe QoA correspondante dans le protocole de fédération SAML/OIDC, les avantages sont les suivants :

Une application métier ne doit pas se soucier de la configuration fastidieuse des différentes méthodes d'authentification.
Il suffit de décider quelle classe QoA est souhaitée ou exigée pour l'application métier à intégrer. En spécifiant la classe QoA correspondante dans le protocole de fédération, on s'assure automatiquement que l'utilisateur se voit proposer toutes les méthodes d'authentification autorisées qui correspondent au moins à cette classe QoA.
Les nouvelles méthodes d'authentification intégrées au concept QoA sont ainsi automatiquement disponibles, sans qu'il soit nécessaire d'adapter l'application.
L'introduction de nouvelles méthodes d'authentification devient ainsi transparente pour l'application métier.

: FIs FED-LOGIN/BYOI et QoA (Credentials/Types de vérification)

IdP+Credential(s)+Type de vérification = Qualité de l'identité électronique

Tant les procédures d'authentification (Credentials) utilisées lors d'une inscription que le degré de vérification (type de clarification) d'une identité sont déterminants pour la qualité d'une identité électronique. eIAM décrit cela comme Quality of Authentication (QoA).

Pour les QoA40, 50 & 60, la identité électronique sous-jacente n'est pas simplement enregistrée en tant que telle, mais clarifiée (nom, prénom, date de naissance, type et numéro de carte d'identité). Les identités électroniques clarifiées permettent de savoir qui a été équipé et donc, si nécessaire, d'exercer un recours contre ces personnes.

Les contrôles d'identité se basent toujours sur des pièces d'identité officielles valables avec photo et sur la présence simultanée adéquate de la personne à contrôler. Les pièces d'identité sont enregistrées.

Dans quels cas les identités avec QoA 40, 50 et 60 doivent-elles être utilisées ?

Accès aux ressources TIC de l'administration fédérale dans un contexte d'entreprise (pour les collaborateurs internes et externes ainsi que les partenaires) : L'exigence minimale est QoA40.
Accès aux données nécessitant une protection accrue Selon la politique de zone actuelle, QoA50 est requis. Ceci n'est possible qu'avec des tokens hardcrypto comme la carte à puce*, les Access App's ou au moyen de clés de sécurité FIDO.
*La contrainte de la carte à puce (QoA60), ne peut plus être utilisée que dans des cas exceptionnels et justifiés après consultation de la ChF TNI.
Exigence du processus commercial de pouvoir identifier clairement la personne qui agit (capacité de recours) : L'exigence minimale est QoA40.
Dans certains cas, cela peut également être fait par l'application cible, par exemple en téléchargeant une copie de carte d'identité dans l'application.

Différentes classes de QoA par eIAM-stage

À la demande du client, la flexibilité des différentes classes de QoA par eIAM-stage a été implémentée dans eIAM. Si un client a besoin d'un QoA inférieur dans un environnement non productif, cela peut être mis en œuvre en respectant les règles suivantes.

Règles relatives à la qualité de l'authentification (QoA) ▼

Responsabilités et compétences
- Le besoin de protection de l'application avec le [linktext:niveau de protection] qui en résulte définit la qualité minimale de l'authentification (classe QoA) de l'environnement de production.
- Le responsable de l'application détermine avec l'ISBO responsable la qualité minimale requise de l'authentification (classe QoA) pour l'accès à ses instances d'application (PROD, ABN et REF).
Exceptions dans les environnements non productifs (ABN/REF)
- Si des exigences QoA différentes s'appliquent dans un environnement non productif, cela doit être confirmé par écrit (e-mail signé) par l'ISBO responsable à l'eIAM SIE.
- Cette exception n'est autorisée que si aucune donnée nécessitant un niveau de protection élevé n'est traitée.
Demande de QoA par la Relying Party
- Une Relying Party intégrée à eIAM peut soit :
  - demander la classe QoA minimale à eIAM pendant la durée de la requête de fédération.
  - la définir dans eIAM lors de l'intégration (durée de définition).
Rejet de la demande de fédération en cas d'absence d'indication de QoA
- Si la Relying Party ne définit pas de QoA, ni au moment de la définition, ni au moment de l'exécution, eIAM rejette la demande de fédération.
Application de l'exigence de QoA la plus élevée
- Si un QoA plus élevé a été défini au moment de la définition, eIAM DOIT l'appliquer même si le Relying Party autorise un QoA inférieur au moment de l'exécution.
- Si un QoA plus élevé est exigé au moment de l'exécution qu'au moment de la définition, eIAM DOIT également appliquer le QoA plus élevé.
QoA dans les zones protégées
- Si le Relying Party est exploité dans une zone avec des exigences de sécurité accrues (par exemple SZ+ Basic), eIAM DOIT respecter le QoA de cette zone.
- Un QoA inférieur ne peut être autorisé ni au moment de la définition ni au moment de l'exécution, car le RP-PEP (Relying Party Policy Enforcement Point) régit l'accès.
Modèle d'intégration uniforme pour les environnements de production
- Si une zone avec des exigences QoA plus élevées est utilisée dans l'environnement de production, le même modèle d'intégration (avec RP-PEP) DOIT être utilisé dans tous les environnements d'exploitation de la partie utilisatrice.
- Même si aucune zone RP-PEP n'est nécessaire dans les niveaux d'intégration inférieurs (ABN/REF), eIAM applique les exigences de QoA de production dans tous les environnements.
Identification du QoA dans le jeton
- eIAM DOIT identifier le QoA dans le jeton pour le Relying Party.
- La Relying Party DOIT s'assurer que la QoA indiquée dans le jeton répond à ses exigences.

Spécifications

SAML spécification QoA
OIDC Spécification QoA
Informations détaillées sur QoA (accès interne uniquement) :