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 :
| 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] [2]. |
| 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 [3].
| 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 |
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 :
RSS 2.0