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 virtuel

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.

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 deuxième méthode d’authentification.

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.

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.