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 systèmes utilisés.

OAuthSD offre les systèmes d’identification suivants :

- 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 développe votre propre TOTP pour plus de sécurité).

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

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 :

Implémentation des méthodes d’identification dans le serveur OAuthSD

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 ?

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

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 sous forme cryptée dans une variable de session $_SESSION[’user_claims’] .

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’utilisateurdé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 cette fonctionnalité ne fait pas partie du "standard" OpenID Connect, le serveur OAuthSD est donc conforme en l’état.

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

  publié le par DnC

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

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 ?

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.

2FA pour les développeurs

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.