Accueil > OpenID Connect OAuth Server par DnC > Développer > Identifier l’utilisateur final

L’identification est la partie de l’authentification au cours de laquelle l’utilisateur final s’identifie ou est identifié.

OAuthSD distingue les fournisseurs d’identité primaire et, si l’identification à deux facteurs (2FA) est activée, les secondaires. Les constantes de configuration IDENTITY_PROVIDER et TFA_PROVIDER permettent de définir quel seront les méthodes utilisées.

OAuthSD offre les méthodes d’identification suivantes :

- Identification primaire (constante IDENTITY_PROVIDER) :

’password’ : identification classique par login et mot de passe,
’ghostkeys’ : identification par login et mot de passe entré dans une grille aléatoire.

- Identification secondaire (constante TFA_PROVIDER) :

’checkbysms’ : la classique vérification par SMS,
’gangsta’ : identification de type TOTP (Time-based One-time Password) avec Google Authenticator (DnC peut développer votre propre TOTP pour plus de sécurité et de confidentialité).

DnC développe également la méthode SmartConnect qui supprime les mots de passe en les remplaçant par une procédure d’identification fondée sur le smartphone de l’utilisateur.

Enfin, OAuthSD peut utiliser un système d’identification tiers tel qu’un lecteur de carte ou un annuaire tel que Active Directory / Kerberos et intégrer au jeton d’identité des données issues de ces systèmes.

(plus à venir ...)

Systèmes d’identification intégrés à OAuthSD

  publié le par DnC

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.

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 par un malware,
- 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 :

Il existe des informations complémentaires, connectez vous pour les voir.

La fin des mots de passe : SmartConnect

  publié le par DnC

DnC développe SmartConnect pour le serveur OAuthSD, une application de mobile permettant une identification très sécurisée de l’utilisateur final sans mot de passe.

Fondée sur les meilleures pratiques cryptographiques, cette méthode est fermée à une utilisation publique et se trouve donc particulièrement adaptée à la sécurisation des accès aux données dans un domaine d’entreprise.

OAuthSD + SmartConnect est une solution idéale pour sécuriser les accès aux applications des entreprises dans le cadre du télétravail.

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

 

 

Pour fonctionner, SmartConnect nécessite :
- l’application mobile SmartConnect 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 SmartConnect.
Les applications compatibles OpenID Connect n’ont pas besoin d’être modifiées.

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

Les avantages de SmartConnect :

- productivité : SmartConnect 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 : SmartConnect est installé sur un mobile ordinaire [1] 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. SmartConnect les remplace par des informations cryptographiques robustes.
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 SmartConnect, ni a fortiori leurs liaisons publiques, ce qui permet d’éviter deux cibles d’attaques particulièrement vulnérables.

- 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 maintenant équipés de système de reconnaissance biométrique. 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 SmartConnect 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 SmartConnect 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 SmartConnect.

- Authentification : SmartConnect 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 de l’identifier 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 ...

Ah oui, c’est un TOTP comme Google Authenticator !
Eh bien non :

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

SmartConnect 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 SmartConnect protège l’entreprise propriétaire du serveur OAuthSD.

OAuthSD propose 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 SmartConnect échange des données cryptées sur un canal sécurisé avec SSL/TLS.

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

C’est assez proche en apparence, mais très différent : SmartConnect 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 que 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, 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 SmartConnect est fait à l’initiative et sous le contrôle d’un administrateur de l’entreprise, ce qui permet d’enregistrer dans le serveur OpenID Connect l’identité réelle de l’utilisateur.

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, SmartConnect 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 SmartConnect à un ou plusieurs postes de travail, c’est l’un des avantages de scanner le QR-Code affiché par le poste de travail !

Il existe des informations complémentaires, connectez vous pour les voir.

Notes

[1Actuellement sur système Android, IOS en cours de développement.

Identification par OpenID Connect des utilisateurs identifiés avec Kerberos

  publié le par DnC

L’utilisateur Windows qui a créé une session avec Active Directory (il a déjà fourni son login et son mot de passe) pourra se connecter aux applications Web protégées par OAuthSD sans avoir à entrer dans une nouvelle procédure d’identification.

Kerberos agit alors vis-à-vis du serveur OIDC comme un Fournisseur d’identité OIDC (OIDC Identity Provider).

La solution décrite s’adresse au serveur Kerberos sans passer pas la passerelle Navigateur->Apache->application (mod_auth_kerb) qui est peu portable et instable.

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 :

Comparaison fonctionnelle OIDC / Kerberos
OIDC Kerberos
Objectif Authentification des internautes par les applications Web identification des utilisateurs, des machines et des ressources sur le réseau local
Niveau de communication Web Réseau local
Protocole HTTP TCP
Le client est Une application ouverte sur le serveur HTTP, sur l’user-agent ou native capable de protocole HTTP Toute application native fonctionnant sur la machine de l’utilisateur final (ordinateur client) capable d’ouvrir un socket [1]
Le sujet est L’utilisateur final (ou l’application si elle demande l’authentification pour elle-même) L’utilisateur ayant ouvert la session Windows

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

Correspondance des Concepts
Auth2 Kerberos
Serveur d’autorisation (AS) Centre de distribution de clés (KDC)
Authentication controller Authentication service (AS)
Authorization Code Ticket to Get Tickets ou Ticket-Granting Ticket (TGT)
Token controller Ticket Granting Service (TGS)
Access token Service ticket
URL de la ressource Service Principal Name (ou simplement Principal), SPN

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 s’adresse directement au serveur Kerberos du domaine.

Voici l’implémentation d’OAuthSD :

Il existe des informations complémentaires, connectez vous pour les voir.

Notes

[1Ce qui inclut les applications ouvertes sur le serveur HTTP mentionnées à gauche, pourvu qu’il puisse accéder au serveur Kerberos du domaine.

[2Il ne s’agit pas d’identité puisque le niveau de communication et le sujet de l’authentification ne sont pas les mêmes d’un côté à l’autre. Il faut lire le tableau comme "Dans OIDC xxx joue le rôle du yyy de Kerberos"

[3A partir de ce moment, la session SLI d’OAuthSD et démarrée. Dans l’état actuel du développement, elle vivra indépendamment de la session Active Directory.

[4Dans l’état actuel du développement, OAuthSD ne traite que les identifications Kerberos et Login/Password.

[5A partir de ce moment, la session SLI d’OAuthSD et démarrée. Dans l’état actuel du développement, elle vivra indépendamment de la session Active Directory.

[6Dans l’état actuel du développement, OAuthSD ne traite que les identifications Kerberos et Login/Password.

Identification OpenID Connect avec ID Card : Aramis

  publié le par DnC

Les grandes organisations possèdent généralement leur propre système d’identification attaché à chaque poste de travail, le plus commun étant le lecteur d’ID card.

OAuthSD a permis par exemple d’intégrer le système de lecteur de carte Aramis. Ainsi, un utilisateur identifié par ce moyen l’est également par les applications Web clientes du serveur OAuthSD, auxquelles le jeton d’identité JWT transmettra le profil Aramis de l’utilisateur.

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 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.

Il existe des informations complémentaires, connectez vous pour les voir.

Validation en 2 étapes (Two Factor Authentication, 2FA)

  publié le par DnC

Un nouveau règlement de l’UE ( en vigueur depuis septembre 2019 ) exige une authentification de paiement à deux facteurs, appelée « Authentification client forte » (SCA).

Le besoin de la validation à 2 étapes se fait également sentir pour la connexion des utilisateurs aux applications sensibles. Le principe de la validation à 2 étapes (Two Factor Authentication, 2FA) est bien connu depuis plusieurs années et mis en oeuvre de différentes manières, La plus courante étant le code envoyé par SMS.

OAuthSD implémente l’authentification à deux facteurs par SMS ou avec Google Authenticator.

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 a sur lui, c’est-à-dire un élément d’information qu’il devrait connaître ou avoir immédiatement sous la main - comme un jeton physique.

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 ... à condition qu’il n’y ait pas de fuite de suivi ailleurs dans cette application !

Et ensuite ?
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.

TFA avec SmartConnect

Nous développons 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 SmartConnect installée sur votre mobile, il vous suffit de scanner le QR-Code présenté par l’application pour ouvrir votre session OpenID Connect :

Il existe des informations complémentaires, connectez vous pour les voir.

Notes

[1La méthode d’identification par SMS échouera donc si aucun numéro n’a été enregistré pour l’utilisateur qui tente de s’identifier.

[2Notons que c’est bien OAuthSD qui est enregistré sur Google Authenticator, et non les applications clientes. On conserve donc tout l’avantage de la délégation d’authentification pour interdire le tracking de la navigation des utilisateurs finaux.

Utiliser SPIP comme pourvoyeur d’identité d’OIDC

  publié le par DnC

De nombreuses applications avancées peuvent être construites en intégrant un serveur OIDC dans un gestionnaire de contenu (Content Management System, CMS) ou un framework. Soit que le CMS serve d’hôte pour développer l’environnement de gestion du serveur OIDC, soit que l’authentification serve, par exemple, à construire un système de distribution d’applications en tant que service (Software as Service, SaaS).
Chez DnC, nous utilisons le CMS SPIP pour ces deux approches, et d’autres applications encore [1].
Cependant, il existe une difficulté : le CMS possède déjà son propre système d’identification des utilisateurs (les ’auteurs’), comment éviter de doublonner avec les utilisateurs finaux enregistrés sur le serveur OIDC ?

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.

Quelques restrictions

Nous avons l’expérience du fonctionnement du serveur OAuthSD avec une table ’users’ vide, par exemple l’utilisation de Kerberos ou d’Aramis comme pourvoyeurs d’identité.

Sans modification du serveur OAuthSD, ceci implique seulement quelques restrictions des fonctionnalités du serveur OIDC (dont nous n’aurons généralement pas besoin) :
- La ré-identification avec id_token_hint ne peut fonctionner,
- le contrôleur UserInfo ne peut fonctionner.

Les modules d’identification secondaires (TFA) devront également être modifiés pour s’appuyer sur les données de la table ’auteurs’ de SPIP.

Notes

[1Cet article est le premier d’une série à venir qui développera l’intégration d’un serveur OIDC dans SPIP et les usages qui peuvent en être faits.

acr_values (Requested Authentication Context Class Reference)

  publié le par DnC

OAuthSD met en oeuvre acr_values et résoud un problème de sécurité lié à la définition de la méthode d’identification éventuellement imposée par un client.

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éfini 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 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.
- Lorsque authorize vérifie le cookie SLI, si l’acr demandé par l’application est supérieur à l’acr du cookie SLI, 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.