Identifier l’utilisateur final

Il s’agit d’identifier une personne, pourquoi alors choisir un masque comme logo de cet article ? C’est parce que la plupart des techniques n’identifient pas une personne avec certitude, sauf quand on utilise des procédés biométriques : de la même manière que l’on peut reconnaître une personne masquée par ses yeux. C’est aussi parce que l’enjeu est de démasquer les intrus.

Les systèmes d’identification intégrés au serveur offrent une sécurité maximale puisqu’ils sont sanctuarisés dans l’espace physique de l’organisation.

Les fenêtres de dialogue nécessaires à l’identification sont produites par le serveur et exécutées dans son environnement : le navigateur de l’utilisateur final a été redirigé vers le domaine du serveur.

OAuthSD offre différentes méthodes d’identification est peut facilement en intégrer de nouvelles grâce à son organisation modulaire.

Identification classique : login/Mot de passe

La méthode se passe de commentaire. Si ce n’est pour dire qu’il faut absolument l’éviter, ainsi que toutes ses semblables exigeant l’entrée au clavier d’un code quelconque, fut-il éphémère !

Goshtkeys : clavier fantôme

Cette méthode affiche une grille dans laquelle l’utilisateur devra cliquer sur des chiffres disposés de façon aléatoire à chaque affichage du formulaire de connexion.
Cette méthode offre de grands avantages de sécurité :
 le mot de passe est matérialisé sous une forme codée et variable, ce qui interdit sa réutilisation en cas d’interception,
 les robots seront éliminés, ce formulaire étant équivalent à un Captcha.

Après l’identification

Après identification, il est possible d’effectuer une Validation en 2 étapes (Two Factor Authentication, 2FA) .

Enfin, le consentement de l’utilisateur pour l’accès de l’application à ses données personnelles est demandé comme nécessaire :

La vidéo suivante montre comment ouvrir une session OpenID Connect en un clic et sans mot de passe :

Pour fonctionner, NoPassConnect nécessite :
 l’application mobile NoPassConnect installée sur un smartphone. Celui-ci doit être connecté à Internet ou connecté au réseau WiFi de l’entreprise ce qui permet une utilisation sanctuarisée dans un espace restreint.
 un serveur OAuthSD avec le module d’identification NoPassConnect.
Les applications compatibles OpenID Connect n’ont pas besoin d’être modifiées.

OAuthSD peut intégrer NoPassConnect comme méthode d’identification primaire, qui remplacera avantageusement des systèmes fondés sur des lecteurs de carte par exemple.
NoPassConnect peut également être utilisé comme identification secondaire (Identification à deux facteurs, TFA).

Les avantages de NoPassConnect :

 Productivité : NoPassConnect permet une connexion ultra-rapide en mode SSO : il suffit de scanner un QR-Code présenté à l’écran par OAuthSD (une fois au début d’une séance de travail), le reste est automatique.
SmartConnect élimine le besoin de mot de passe et épargne le temps perdu à rétablir les identifiants égarés.

 Economie : NoPassConnect est installé sur un mobile ordinaire [2] sans nécessiter de matériel supplémentaire ni de protocoles d’installation complexes. Une entreprise peut envisager d’équiper un très grand nombre d’utilisateurs, y compris extérieurs, pour une fraction du prix d’un système d’identification matériel, avec un gain de temps pour l’administration et la maintenance. C’est l’idéal pour le télétravail !

 Faible surface d’attaque : les mots de passe sont le maillon faible de l’identification. NoPassConnect les remplace par des informations cryptographiques robustes, à usage unique.
Les échanges sont limités à une liaison cryptée mobile-serveur OAuthSD.
Il n’y a pas de logiciel à installer sur les stations de travail ou sur les navigateurs (contrairement à un lecteur d’ID card) ; ceux-ci n’interviennent pas dans le protocole d’identification de NoPassConnect, ni a fortiori leurs liaisons publiques, ce qui permet d’éviter deux cibles d’attaques particulièrement vulnérables.

De plus :
NoPassConnect est fondé sur une communication par le réseau de données mobiles (et non l’Internet) entre un mobile connecté et le serveur d’authentification (OP) auquel les applications ont délégué l’identification des utilisateurs.

NoPassConnect ne répond jamais à une demande et ne nécessite pas d’entrée au clavier (pas d’identifiant, de mot de passe ou de code) ce qui ferme la plupart des possibilité d’attaques et distingue la solution de ses concurrentes.

Ces deux caractéristiques sont innovantes et constituent un apport original.

 Sécurité : Mieux qu’un mot de passe qui peut être compromis, un smartphone est un objet très personnel, mieux gardé par son propriétaire que tout autre objet. Sa perte ou son vol sont rapidement constatés (alors qu’il n’y a généralement pas moyen de savoir si un mot de passe a été compromis), ce qui permet à un administrateur d’invalider rapidement son enregistrement sur le serveur OAuthSD.

De plus, les smartphones sont équipés de systèmes de reconnaissance biométrique de plus en plus performants. L’identification au moyen du smartphone permet donc de préjuger valablement de l’identité de l’utilisateur final.

 Segmentation géographique : Par défaut, l’usage de NoPassConnect peut se faire à partir de n’importe quelle connexion de données, qu’il s’agisse du réseau d’un opérateur ou d’un réseau WiFi. L’usage de NoPassConnect peut-être limité au réseau WiFi de l’entreprise, jusqu’à sélectionner par leur IP locale les bornes autorisées. Il serait également possible d’autoriser une connexion domestique donnée pour permettre le travail à domicile. Il est également possible, sur un réseau d’entreprise, de définir les postes de travail capables ou non de se connecter avec NoPassConnect .

 Authentification : NoPassConnect impose l’identifiant OpenID de l’utilisateur, qui est intégré au moment de la configuration initiale du mobile sous le contrôle d’un administrateur. Au cours de cette opération, le mobile doit scanner un QR-Code présenté par l’administrateur, ce qui permet d’identifier l’utilisateur avec rigueur ( à l’opposé de l’enregistrement à distance tel que pratiqué par WebAuthn par exemple ).

Les administrateurs peuvent affecter en temps réel les autorisations ou dénier les accès. Plusieurs dispositifs permettent de détecter et de bloquer automatiquement des usages détournés, comme par exemple l’utilisation d’une autre station de travail que celles qui auront été autorisées, etc.

En résumé, les avantages déterminants pour la sécurité des données d’une entreprise sont : l’utilisation de moyens privés, l’identification de l’utilisateur assurée par un administrateur, la possibilité de limiter l’usage à des lieux déterminés.

Entendu ...

Bah, trop simple le QR-Code qui sert de mot de passe !

Pas du tout : le QR-Code n’est qu’un identifiant de session pour les échanges qui vont suivre entre le serveur et le smartphone. Il est éphémère et ne peut donc être réutilisé. L’authentification résulte d’un échange de données faisant appel à des techniques cryptographiques fortes. Le navigateur n’intervient pas dans les échanges qui se font directement entre le smartphone et le serveur OAuthSD.

Ah oui, c’est un Time-based One-time Password (TOTP) comme Google Authenticator !
Eh bien non :

NoPassConnect est un dispositif privé, ne faisant pas appel à des systèmes tiers, pour une meilleure sécurité et une parfaite confidentialité.

NoPassConnect impose l’identité de l’utilisateur de l’entreprise, configurée par un administrateur. Un TOTP ne fait que vérifier que l’utilisateur est bien celui qui s’est inscrit lui-même sur le système. En somme, un TOTP protège l’utilisateur tandis que NoPassConnect protège l’entreprise propriétaire du serveur OAuthSD.

OAuthSD propose le TOTP Google Authenticator pour l’authentification à deux facteurs : jugez de la différence par vous même.

Ah oui, c’est comme la confirmation par SMS !
Eh bien non :

Le 2FA par SMS n’est pas sécurisé, alors que NoPassConnect échange des données cryptées sur un canal sécurisé avec SSL/TLS.

De plus le code reçu par SMS doit être retourné par le même canal (le navigateur), ce qui ouvre la porte à de nombreuses techniques d’interception telles que le l’ingénierie sociale, l’interception de trafic, le key-login ; avec NoPassConnect le navigateur n’intervient pas dans ces échanges, l’identification se fait entre le smartphone et le serveur OAuthSD.

Et si c’est l’utilisateur final lui-même qui a fourni son numéro de portable au moment de son inscription, on n’a absolument aucune information sur son identité réelle ! NoPassConnect impose la configuration du smartphone sous le contrôle d’un administrateur.

J’ai trouvé : c’est comme WebAuthn !

C’est assez proche en apparence, mais très différent : NoPassConnect concoure à l’ouverture et à la fermeture d’une session OpenID Connect à partir d’une application qui lui est extérieure, tandis que WebAuthn se limite à l’identification directe de son porteur.

C’est également très différent en termes de sécurité :

WebAuthn présente un désavantage important pour la sécurité d’une entreprise : comme la plupart des système de login, WebAuthn est un système public dans le sens où c’est l’utilisateur qui enregistre de façon anonyme son mobile, rien ne permet de l’identifier. Permettre à un utilisateur de s’enregistrer sans qu’il y ait une étape d’identification physique, c’est exactement comme lui permettre de fabriquer lui-même sa carte d’identité, et encore : en remplaçant son nom par un pseudo.

A l’inverse, l’enregistrement d’un mobile NoPassConnect est fait à l’initiative et sous le contrôle d’un administrateur de l’entreprise, en présentiel, ce qui permet d’enregistrer dans le serveur OpenID Connect l’identité réelle de l’utilisateur.

Enfin, répétons-le : avec NoPassConnect, le navigateur n’intervient pas dans le processus d’identification qui se fait directement entre le smartphone et le serveur OAuthSD.

Ah oui, c’est un peu comme un lecteur d’ID card ...
Presque ! En mieux :

C’est plus économique, plus facile à déployer, moins vulnérable.

De plus, NoPassConnect n’étant pas lié physiquement à un poste de travail, il peut être déployé hors du périmètre de l’entreprise. Cela n’interdit pas de limiter l’utilisation de NoPassConnect à un ou plusieurs postes de travail, c’est l’un des avantages de scanner le QR-Code affiché par le poste de travail !

Enfin, si un utilisateur peut oublier sa carte dans le lecteur en quittant le bureau, il est probable qu’il n’oubliera pas de prendre son smartphone avec lui...

A propos du logo de Kerberos : dans la mythologie grecque, Cerbère (en grec ancien Κέρϐερος / Kérberos) est le chien à trois têtes gardant l’entrée des Enfers (Wikipedia). Ce logo est adopté par le MIT pour son protocole krb5 qui est utilisé ici.

Objectif

L’utilisateur qui s’est identifié sur le réseau local avec Active Directory est inscrit sur le serveur Kerberos du domaine.

Il s’agit de faire en sorte que cet utilisateur soit également identifié par OIDC, donc sans avoir à suivre une nouvelle procédure de login dans les applications clientes du serveur OAuthSD de l’organisation.

On peut donc dire que le "SSO" d’OauthSD (la connexion unique) héritera de celui de Kerberos.

Solution s’adressant directement au serveur Kerberos

Cette approche est complète car elle permet d’obtenir non seulement le login de l’utilisateur mais également des informations permettant son identification.

De plus, elle ne fait pas appel à la passerelle entre Kerberos et le navigateur, ce qui permet :
 d’éviter des problèmes de configuration des navigateurs des utilisateurs,
 d’améliorer la sécurité en restant dans une liaison serveur-serveur (le navigateur ne voit pas passer d’information d’authentification).

Concepts

Le protocole Kerberos définit la façon dont les utilisateurs interagissent avec un service réseau pour avoir accès aux ressources du réseau.

Pour une présentation générale de Kerberos, voyez : Exploration du protocole KERBEROS

Dans Windows, l’ordinateur client est membre d’un domaine AD DS (Active Directory Domain Services) et le ticket TGT prouve que le contrôleur de domaine Kerberos a authentifié les informations d’identification fournies par l’utilisateur de l’ordinateur client.

Si la finalité et le fonctionnement de Kerberos ressemblent à ceux d’OpenID Connect (OIDC), leur niveau fonctionnel (au sens couches ISO du terme) n’est pas le même :

Le tableau suivant met en parallèle les concepts des deux systèmes [3].

Note à propos de la sécurité

Notons que OIDC opère au niveau applicatif (et non au niveau du réseau), ce qui contribue à l’approche "accès zéro-confiance au réseau" (ZTNA).
Donc il ne faudrait pas utiliser Kerberos ? Ici, nous utilisons Kerberos pour l’identification et l’autorisation de l’utilisateur. L’accès à l’application (ou de l’application aux ressources protégées) reste contrôlé au niveau applicatif.

Pourquoi ne pas utiliser mod_auth_kerb ?

Pour réaliser l’intégration de Kerberos comme pourvoyeur d’identité au profit d’OpenID Connect, un premier problème à résoudre consiste à passer les informations Kerberos de la couche de transport TCP à la couche protocole HTTP.

Quand on cherche comment le problème est résolu, on trouve généralement des applications de l’extension Apache mod_auth_kerb.

mod_auth_kerb définit la variable d’environnement REMOTE_USER avec l’identification du client, ce que l’on peut récupérer dans l’application. Cela suppose l’intégration des informations Kerberos dans le Header de la requête HTTP.

Les principaux inconvénients sont les suivants :
 Pour fonctionner, cela exige de configurer le navigateur Web pour qu’il utilise réellement l’authentification HTTP Negotiate, dont les détails varient d’un navigateur à l’autre. Certains navigateurs n’implémentent pas cette fonctionnalité.
 La mise à jour ou la reconfiguration du poste de travail de l’utilisateur peut écraser la configuration ou changer le navigateur par défaut.
 Le serveur Apache est nécessaire, Nginx ne semble pas pouvoir être utilisé.

Nous considérerons donc que la solution n’est ni portable ni stable.

Le flux décrit ci-dessous, qui s’adresse directement au serveur Kerberos du domaine, évite les difficultés et présente une meilleurs sécurité en évitant de passer par le navigateur .

Voici l’implémentation d’OAuthSD :

S’il fallait résumer les avantages de la solution OAuthSD + ARAMIS, le mieux serait :

La conjonction d’OAuthSD et d’ARAMIS permet d’assurer l’authentification des utilisateurs par les applications extérieures, sans procédure de login/mot de passe, tout en sanctuarisant les données sensibles des utilisateur sur le réseau interne de l’entité, sans rien changer à ces données, les comptes et les droits restant gérés exclusivement par ARAMIS.

Les avantages vont donc bien au-delà d’un simple système de connexion unique (Single Sign On, SSO).

La gestion des utilisateurs est effectuée exclusivement par Aramis

Dans cette configuration, c’est le système Aramis qui gère les données relatives aux utilisateurs et fournit l’User ID : Le serveur OAuthSD fonctionne avec la table ’users’ vide !

L’identifiant de l’utilisateur final est fourni par le système Aramis. C’est cet identifiant qui figurera dans la déclaration ’sub’ du jeton d’identité JWT.

OAuthSD permet donc d’intégrer un système d’identification existant sans nécessité d’une double maintenance ou d’une synchronisation des tables des utilisateurs.

Incorporation des données Aramis dans le jeton d’identité JWT

OAuthSD permet d’incorporer dans le jeton d’identité des données supplémentaires issues d’Aramis. Le mécanisme général est décrit ici : Incorporer au jeton JWT des déclarations supplémentaires.

Un système d’identification xxx propre à une application OAuthSD dédiée est intégré au moyen d’un script /oidc/identification/xxx/login.php particulier. Ce script place les données de l’utilisateur issues du système dans une variable de session $_SESSION[’user_claims’], sous forme cryptée.

Les données seront automatiquement incorporées au jeton d’identité JWT sous la forme d’une déclaration supplémentaire pour chaque membre de premier niveau de l’array ’user_claims’.

Il est ainsi possible de passer de façon sûre des données de profil de l’utilisateur final authentifié qui permettront aux applications destinataires du jeton JWT de gérer l’accès en fonction des droits de l’utilisateur qui auront été définis au niveau d’Aramis.

Userinfo

La table users étant vide, le contrôleur UserInfo ne peut retourner les données de l’utilisateur sans modification du code. Si nécessaire, un nouveau contrôleur UserInfo devra être créé pour retourner les données extraites de la carte Aramis. Notons cependant que la fonctionnalité Userinfo ne faisant pas partie du "standard" OpenID Connect, le serveur OAuthSD est donc conforme en l’état.

Le développement réalisé pour la CRAMIF

L’objectif de la CRAM Ile-de-France (CRAMIF) était de sécuriser la connexion des utilisateurs de son application de signature électronique, le SAAS Web "Lex Persona", à partir des postes de travail internes aussi bien que depuis le Web. Pour cela, nous avons installé notre serveur OpenID Connect "OAuthSD" sur l’infrastructure informatique de la CRAM Ile-de-France (CRAMIF).

Le système d’identification par carte "Aramis" a été intégré au serveur OAuthSD : les utilisateurs sont gérés par le système existant, et les autorisations pré-établies des différents acteurs sont automatiquement intégrées au jeton d’identité et transmises à Lex Persona au moyen de celui-ci.
Notons que cette technique dispense totalement l’utilisateur de tout dialogue de connexion, ce qui procure un confort et un gain de temps appréciables.

OAuthSD peut intégrer tout pourvoyeur d’identité

La structure modulaire d’OAuthSD permet d’intégrer tout pourvoyeur d’identité, Aramis n’étant qu’un exemple.

Il est également possible d’intégrer plusieurs systèmes simultanément.

En particulier, remarquant qu’une identification par carte identifie la carte, pas le porteur, il est opportun de demander une deuxième authentification (TFA), cette dernière requérant un élément dans la possession de l’utilisateur à authentifier.

Qu’est-ce que 2FA ?

La sécurité apportée par un simple mot de passe n’est pas toujours suffisante.

L’authentification à deux facteurs, également connue sous le nom de 2FA, vérification en deux étapes ou TFA, est une couche de sécurité supplémentaire appelée « authentification à plusieurs facteurs », qui requiert non seulement un mot de passe et un nom d’utilisateur, mais aussi quelque chose que cet utilisateur possède, qui est avec lui et que personne d’autre ne possède ou ne connait.

Après le login, donnez une deuxième preuve de votre identité

Le processus commence comme d’habitude, l’utilisateur final donnant son identifiant et son mot de passe :

Il lui est demandé de fournir une deuxième preuve d’identité : OAuthSD propose la méthode classique par SMS ou l’identification avec Google Authenticator.

2FA par SMS

Si cette première étape se termine avec succès, OAuthSD enchaîne sur une demande de code par SMS :

Le SMS est envoyé au numéro de smartphone enregistré avec le profil de l’utilisateur [1].

Après confirmation, le consentement est demandé si nécessaire, comme d’habitude :

2FA avec Google Authenticator

Google Authenticator est un système de 2FA qui génère un TOTP.

Qu’est-ce que TOTP ?

TOTP est une forme abrégée de "Time-based One-time Password " ou "mot de passe à utilisation unique à durée déterminée". Il s’agit d’un mot de passe qui ne peut être utilisé qu’une seule fois et qui ne peut être utilisé que dans une plage de temps définie. Généralement, les générateurs TOTP génèrent de nouveaux mots de passe toutes les quelques dizaines de secondes tel que défini.

Après le login, donnez une deuxième preuve de votre identité avec Google Authenticator

Le processus commence comme d’habitude, l’utilisateur final donnant son identifiant et son mot de passe comme précédemment.

Il lui est demandé de fournir une deuxième preuve d’identité : Google Authenticator qu’il ou elle a installé sur son smartphone lui donnera le code nécessaire.

Cela nécessite d’enregistrer OAuthSD sur Google Authenticator en tant qu’application [2]. C’est pour cela que le QRCode est utilisé. Voir de nombreux tutoriels sur le Web. C’est une action unique pour la vie du smartphone : une fois que c’est fait, GA affichera un code toutes les 30 secondes : rien à retenir !

Après confirmation, le consentement est demandé si nécessaire, comme d’habitude.

Pourquoi Google Authenticator ?

Qu’en est-il du suivi (tracking) ? Les applications délèguent l’identification de l’utilisateur à OAuthSD. Cela signifie que Google voit le serveur OAuthSD et non les applications. Google sait qu’un utilisateur est lié à OAuthSD, mais ne voit pas la relation avec l’application : il n’y a donc pas de suivi de l’activité de l’internaute sur l’application (tracking) ... à condition qu’il n’y ait pas de fuite de suivi ailleurs dans cette application !

TFA avec NoPassConnect

Nous développons NoPassConnect (précédemment SmartConnect), une application de mobile sans mot de passe (passwordless) qui peut être utilisée comme première méthode d’authentification aussi bien qu’en deuxième.

Avec l’application NoPassConnect installée sur votre mobile, il vous suffit de scanner le QR-Code présenté par l’application pour ouvrir votre session OpenID Connect :

Configurer TFA sur OAuthSD

Une demande de deuxième validation est présentée à l’utilisateur final :
 Si la constante de configuration LOGIN_WITH_TFA est définie sur true, le formulaire 2FA sera toujours présenté à l’utilisateur final après le formulaire de connexion.
 sinon, le scope réservé "tfa" doit être présent dans la demande d’autorisation ; l’application devra donc avoir été enregistrée sur le serveur avec le scope ’tfa’.
 la constante de configuration TFA_PROVIDER permet de définir le deuxième mode d’identification (’gangsta’, ’checkbysms’, ’smartconnect’ ...).

Et ensuite ?

Dans l’état actuel du développement, il existe trois méthodes disponibles pour 2FA : TFA par SMS (la solution classique !), Google Authenticator et DnC NoPassConnect.

D’autres fournisseurs d’identités suivront bientôt, y compris le nôtre (= votre serveur privé) pour une sécurité de niveau supérieur.

Nous pouvons développer tout système privé adapté aux besoins particuliers de nos clients, comme nous l’avons fait avec l"’Identification OpenID Connect avec ID Card : Aramis .

Synchroniser les tables ’auteurs’ et ’users’ ou se passer de la table ’users’ ?

En l’état nous avons deux tables : ’users’ pour OIDC et ’auteurs’ pour SPIP. Le problème à résoudre est donc d’unifier les données.
Deux solutions sont possibles :
 la mauvaise : assurer la synchronisation de la table ’users’ à partir de données de la table ’auteurs’ de SPIP : tout enregistrement de données sur la table ’auteurs’ est répercuté sur la table ’users’, et vice-et-versa.
 la bonne : utiliser uniquement les données de SPIP.

Utiliser SPIP comme pourvoyeur d’identité

Dans cette deuxième solution, les données de SPIP sont utilisées pour réaliser la fonction d’identification du serveur OIDC. Cela nécessite donc un nouveau module d’identification ’spip’ comprenant des scripts login.php et login_return.php qui utiliseront les données de la table auteurs de SPIP.

Et le serpent se mord la queue...

Une fois le serveur OAuthSD intégré à SPIP comme indiqué, il peut non seulement être utilisé pour l’authentification des utilisateurs d’applications tierces ou l’accès aux ressources protégées (ce pour quoi est fait un serveur OIDC), mais également pour authentifier les utilisateurs (auteurs) de SPIP en se substituant au module d’authentification standard de ce CMS.

Traduction d’extraits de OpenID Connect Core 1.0.
Dans la section ’2. ID Token’ :

 acr
OPTIONNEL. Référence de classe de contexte d’authentification. Chaîne spécifiant une valeur de référence de classe de contexte d’authentification qui identifie la classe de contexte d’authentification satisfaite par l’authentification. La valeur "0" indique que l’authentification de l’utilisateur final ne répond pas aux exigences du niveau 1. ISO / IEC 29115 [ISO29115]. L’authentification à l’aide d’un cookie de navigateur de longue durée, par exemple, est un exemple où l’utilisation du "niveau 0" est approprié. Les authentifications de niveau 0 NE DEVRAIENT PAS être utilisées pour autoriser l’accès à toute ressource de quelque valeur monétaire que ce soit. (Cela correspond au PAPIER OpenID 2.0 [OpenID.PAPE] nist_auth_level 0.) Un URI absolu ou un nom enregistré RFC 6711 [RFC6711] DEVRAIT être utilisé comme valeur acr ; les noms enregistrés NE DOIVENT PAS être utilisés avec une signification différente de celle qui est enregistrée. Les parties utilisant cette allégation devront s’entendre sur la signification des valeurs utilisées, qui peuvent être spécifiques au contexte. La valeur acr est une chaîne sensible à la casse.

dans la section ’3.1.2.1. Authentication Request’ :

 acr_values
OPTIONNEL. Valeur de "Requested Authentication Context Class Reference". Chaîne séparée par des espaces spécifiant les valeurs acr que le serveur d’autorisations est invité à utiliser pour traiter cette demande d’authentification, les valeurs apparaissant par ordre de préférence. La classe de contexte d’authentification satisfaite par l’authentification effectuée est renvoyée sous la valeur de revendication acr, comme spécifié à la section 2. La revendication acr est demandée en tant que revendication volontaire par ce paramètre.

Niveaux d’acr

OAuthSD définit quatre niveaux d’acr (au moins, le nombre n’est pas limité) attachés aux méthodes d’authentification et définis par un nombre entier, par ordre croissant de sécurité du procédé :
0 : procédé insuffisant
1 : procédé normal : "une étoile" : login/MdP, délégation de l’identification sans TFA.
2 : procédé "deux étoiles",
3 : procédé "trois étoiles".

En cas d’authentification à deux facteurs (TFA) réussie, les niveaux des deux méthodes sont ajoutés, sinon le niveau est 0 si le TFA échoue.

Les méthodes d’authentification et leur acr sont définis dans le fichier de configuration configure_oidc.php.

Le niveau d’acr est inscrit dans le cookie SLI et est retourné dans la charge utile du jeton JWT.

Méthode d’authentification imposée par le client

OAuthSD permet à un client de spécifier des exigences particulières en matière d’identification de l’utilisateur final afin d’atteindre un niveau acr (Authentication Context Class Reference) suffisant.

Cela est défini par deux champs OPTIONNELS de la table des clients, renseignés au moment de l’inscription de l’application sur le serveur OAuthSD :

 identity_provider : nom d’une méthode d’identification principale spécifique (password, ghostkeys, kerberos, etc.).
S’il n’est pas défini, le fournisseur d’identité est celui qui est défini par défaut au moyen de la constante de configuration IDENTITY_PROVIDER.

 required_acr : valeur d’acr minimale requise par le client (Requested Authentication Context Class Reference). Si le client ne définit pas de valeur d’acr minimale, celle-ci est définie à 0.

Problématique de sécurité et solution

Il se pose alors un problème de sécurité : si une session OIDC est créée avec une méthode faible, le cookie SLI ou le jeton d’identité JWT permettraient d’accéder à une application requérant une méthode plus forte.
Afin de prévenir cela :
 Lorsqu’une authentification est effectuée, la valeur de l’acr est inscrite dans le cookie SLI et le jeton d’identité.
 Lorsque authorize vérifie le cookie SLI ou le JWT, si l’acr demandé par l’application est supérieur à l’acr du cookie SLI ou du JWT, on invalidera le cookie, ce qui provoquera une nouvelle authentifiction.
Une application ne déclare pas nécessairement l’acr requis, le niveau étant alors 0.