Accueil > OpenID Connect OAuth Server par DnC > Développer > Identification par OpenID Connect des utilisateurs identifiés avec (...)

Identification par OpenID Connect des utilisateurs identifiés avec Kerberos

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.