Cerbère (en grec ancien Κέρϐερος / Kérberos).

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

Comparaison fonctionnelle OIDC / Kerberos

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

Correspondance des Concepts

Correspondance des Concepts des deux systèmes [3].

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 :

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

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

[2] Donc n’importe quelle application, y compris un malware : on ne sait pas où vont les données !

[3] Il 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"

[4] A 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.

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

[6] A 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.

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

Publié par Bertrand Degoy le 07 juillet 2021 dans https://oa.dnc.global/-fr-.html?lang=fr

https://oa.dnc.global/-fr-.html?lang=fr

clear1>

Pour en savoir plus :

– Identification par OpenID Connect des utilisateurs identifiés avec Kerberos le 07 juillet 2021
– Innovation : i-Tego (Nogent-52), la start-up qui (r)assure le 02 novembre 2021
– Zoom sur i-Tego le 01 décembre 2021
– i-Tego présente son activité à l’équipe municipale de Nogent le 02 mars 2022
– i-Tego sécurise l’usine du futur le 27 mai 2022.
– Cybersécurité : Bruxelles s’attaque aux objets connectés le 15 septembre 2022
– Les innovations de l’offre d’i-Tego le 02 decembre 2022
– Cybersécurité et résilience de l’Usine du Futur le 08 décembre 2022