Séparation de l’authentification et de l’identification

Comme je l’ai évoqué, la génération dynamique du service LDAP a eu pour effet de bord de devoir stocker le mot de passe de chaque utilisateur dans la base de données. Cette solution insatisfaisante d’un point de vue de la sécurité nous a poussés à réfléchir à une solution pour extraire les données d’authentification de notre référentiel au profit des données d’identification.

J’ai donc effectué une recherche sur les différentes technologies d’authentification que nous pouvions implémenter dans notre environnement et ai dirigé rapidement mon analyse vers la technologie Kerberos [RFC 4120] [12].

Kerberos est un protocole d'authentification distribué développé par le Massachusetts Institute of Technology (MIT). Kerberos offre une authentification sécurisée pour les échanges client/serveur reposant sur un mécanisme de clés secrètes et d'utilisation de tickets. Il permet ainsi de chiffrer les échanges entre les clients (utilisateurs, services ou machines), le serveur d’authentification Kerberos (le KDC, Kerberos Distribution Center) et les ressources auxquelles les clients souhaitent accéder.

L’avantage principal est d’éviter la circulation des mots de passe en clair sur le réseau, évitant ainsi le risque d'interception frauduleuse des mots de passe des utilisateurs.

Les informations qui sont échangées pour prouver une identité sont appelées tickets. Les informations utilisées pour chiffrer les tickets et les communications qui en découlent sont appelées clefs. Une fois l’identité d’un client vérifiée, le client reçoit un jeton qui peut être utilisé par tous les services compatibles avec Kerberos pour vérifier son identité.

Pour des raisons de sécurité, les jetons sont horodatés ainsi, ils expirent automatiquement à moins qu’ils ne soient renouvelés par un utilisateur ou un service. Les horodatages contenus dans les jetons et les tickets ne peuvent être vérifiés que si les heures et les dates sont synchronisées entre les clients et le KDC. L’authentification Kerberos échouera si les horloges se désynchronisent de plus de cinq minutes.

Plusieurs implémentations de Kerberos existent, dont par exemple l’implémentation Heimdal, créé à l’origine pour s’affranchir des restrictions à l’exportation des Etats-Unis (aujourd’hui abandonnées). Nous avons privilégié l’implémentation du MIT qui nous paraissait la plus répandue dans le monde Linux, et fournie nativement sur nos systèmes d’exploitation Red Hat Enterprise Linux.

Dans le cadre de notre projet, nous avons étudié les impacts de l’intégration de la technologie Kerberos sur notre architecture. Premièrement, nous devions extraire les mots de passe des utilisateurs de notre référentiel unique, et donc ne plus en disposer pour générer la configuration du LDAP. Cette politique de séparation de l’authentification et de l’identification a eu pour incidence de mettre en place une seconde base de vérité indépendante du référentiel unique d’identification (service d’authentification Kerberos).

La sécurité de l’authentification a également été renforcée par la circulation cryptée des mots de

passe sur le réseau entre les clients kerbérisés et le service d’authentification. Cependant, les services

non « kerbérisés » ont dû être passés en LDAPS pour éviter toute circulation de mots de passe en clair. Pour cela, nous avons supprimé la possibilité d’accéder au LDAP de façon non sécurisée (filtrage par pare-feu logiciel du serveur).

D’autre part, l’utilisation du mécanisme d’authentification SASL (mise en place du service saslauthd sur le serveur LDAP) pour interconnecter les services LDAP et Kerberos a permis de conserver l’unicité des

mots de passe en permettant aux services non kerbérisés de s’authentifier auprès du service LDAP.

LDAP utilisait le connecteur SASL pour réaliser lui-même l’authentification auprès du service Kerberos et renvoyer le résultat au client, comme s’il s’agissait d’une authentification locale.

Figure 16 : Authentification en environnement hétérogène

Enfin, cette mise en œuvre a apporté des fonctionnalités nouvelles (Figure 16) que nous n’avons pas implémentées dans ce projet, comme la fédération d’identités ou l’interconnexion avec les annuaires Microsoft (Active Directory).

En effet, la mise en œuvre de notre référentiel Kerberos offrait la possibilité d’utiliser les bases d’authentification pour participer à des fédérations d’identités (CAS, SSO), utiles pour les échanges de services entre les laboratoires (par exemple, accès à la grappe de calcul du L.A.).

Dans le cas des annuaires Active Directory (AD), nous avions la possibilité d’offrir une authentification unique à tous les services quelque soit l’environnement de l’utilisateur et ce dès la connexion à son poste de travail.

La migration vers Kerberos a été réalisée grâce aux nouvelles IHM. Le principal problème rencontré lors de l’intégration de Kerberos au système d’information était qu’il fallait migrer l’authentification du service d’annuaire (LDAP) vers le service d’authentification (Kerberos). Cette migration a été réalisée en intégrant au code des nouvelles IHM une réécriture des mots de passe dans ces deux services.

Pour cela, lors de sa première connexion au nouveau système, l’utilisateur authentifié non enregistré dans le référentiel d’authentification se voyait proposer de changer son mot de passe. Celui-ci n’était pas enregistré dans le service LDAP mais directement dans le service Kerberos. Le service LDAP recevait la chaine de connexion permettant de déléguer l’authentification vers le service Kerberos. A la connexion suivante, l’utilisateur accédait directement à ses services.

Pour basculer l’authentification des utilisateurs du service LDAP vers le service Kerberos, nous avons utilisé un algorithme permettant de basculer les utilisateurs progressivement, au fur et à mesure de leurs connexions sur leur espace personnel. La bascule des authentifications s’est donc déroulée sans arrêt de service.

L’algorithme de mise à jour des mots de passe utilisé a été le suivant : Si Authentification Kerberos = TRUE (utilisateur) Alors

Accéder aux IHM Sinon

# Authentification Kerberos = FALSE, utilisateur non reconnu ou absent du KDC Si Authentification LDAP = TRUE Alors

Enregistrer un nouveau mot de passe dans Kerberos Rediriger l’authentification du LDAP vers Kerberos via SASL Sinon

Refuser l’accès aux IHM FinSi

FinSi

Le seul point noir que nous avons rencontré avec la technologie Kerberos a été lié à la découverte d’une technologie compliquée à appréhender, implanter et maitriser. C’est le point technique sur lequel l’investissement de l’équipe informatique a été le plus important en termes de formation.