Lightweight Directory Access Protocol (LDAP)

Les différents types d'architectures

Un serveur LDAP peut constituer un SPOF dans l'architecture logicielle d'une entreprise, dans la mesure où la plupart des applications s'appuient sur l'annuaire LDAP pour l'authentification et la récupération d'informations concernant les utilisateurs et le matériel.

Aussi, un document de référence a été agréé par l'IETF, pour définir les algorithmes et principales règles qui devraient être suivies pour implémenter une réplication d'annuaires LDAP. Cependant, force est de constater que les implémentations de ces recommandations ont divergées, et qu'il est difficile, voir impossible, de mettre en place un serveur répliqué qui n'utilise pas le même logiciel serveur que l'annuaire à répliquer.

La norme spécifie cinq modèles assurant la cohérence des informations lors des opérations de réplication :

• Modèle 1 : Cohérence transactionnelle (ACID - Atomicity, Consistency, Isolation, Durability, comme pour les SGBDR).
• Modèle 2 : Cohérence transitoire - les partenaires se mettent d'accord sur la façon dont les mises à jour seront propagées à tous.
• Modèle 3 : Cohérence probabiliste à effort limité - comme le modèle 3, mais avec abandon de l'opération en cas de timeout, laissant certains serveurs non mis à jour.
• Modèle 4 : Loosest Consistency - Les données sont lues dans un cache simple ou opportuniste, jusqu'à ce qu'elles soient remplacées.
• Modèle 5 : Ad Hoc - chaque serveur possède une copie de l'annuaire, valide jusqu'à ce qu'il soit remplacé. Tous les serveurs ne sont pas à jour en même temps.

De plus, elle spécifie trois modèles de collaboration entre les serveurs LDAP :

Maître-esclave(s) (ou Single Master Replication)

Dans ce modèle, le maître unique est le seul annuaire sur lequel les modifications peuvent être opérées. Les esclaves ne permettent que la lecture d'informations, par exemple pour l'authentification des utilisateurs, ou pour les applications ne stockant pas d'information dans l'annuaire.

Multi-maîtres (ou Multiple Master Replication)

Dans ce modèle, plusieurs maîtres cohabitent ensemble sur le réseau. Des modifications peuvent être réalisées sur tous les annuaires du réseau, et les mises à jour sont donc bidirectionnelles. Dans ce cas, il est conseillé de mettre en oeuvre un modèle de cohérence d'informations basé sur les modèles 1, 2 ou 3 définis précédemment.

Architecture mixte

Dans ce modèle, on fait cohabiter plusieurs maîtres avec un modèle maître esclave. Dans ce cas, les modifications sont bidirectionnelles entre les maîtres LDAP, et unidirectionnelle entre les maîtres et les esclaves.

Dans ce cas de configuration, on peut alors prévoir des annuaires maîtres modifiables par les serveurs d'applications et les administrateurs, et des serveurs esclaves dédiés aux processus de login, et de consultation d'informations issues de l'annuaire.

Les formats d'exportation/importation

Deux formats ont été standardisés pour l'importation et l'exportation d'entrées LDAP. Ces formats sont, le plus souvent, utilisés pour la synchronisation de deux annuaires pour les architectures décrites dans la section précédente. Ces deux formats sont :

• LDAP Interchange Format (LDIF) - standardisé par la RFC 2849
• Directory Services Markup Language (DSML) - standardisé par l'OASIS

Dans le cas de LDIF, les données sont présentées en texte brut, et encodées au besoin en base64 (par exemple lorsqu'une chaîne UTF-8 doit être transmise). Un exemple d'entrée, au format LDIF, décrivant une unité organisationnelle "employés" est présentée ci-après :

dn:: b3U9RW1wbG95w6lzLGRjPWV4YW1wbGUsZGM9Y29t
objectClass: organizationalUnit
objectClass: top
ou:: RW1wbG95w6lz
				

On remarque que les champs DN et OU sont encodés en base64, car le caractère "é" a été traduit en UTF-8, ce qui est souligné par la présence de deux séries de double points ":" au lieu d'une seule.

Voici la même entrée en DSML (encodage utilisé pour l'affichage: ISO-8859-1), avec une syntaxe basée sur le langage XML :

<?xml version="1.0" encoding="UTF-8"?>
<dsml>

   <directory-entries>

     <entry dn="ou=Employés">
        <objectclass>
           <oc-value>organizationalUnit</oc-value>
        </objectclass>
        <attr name="ou"><value>Employés</value></attr>
     </entry>
   
   </directory-entries>
</dsml>
				

Remarque : DSML n'est pas seulement un langage pour l'importation/exportation de données LDAP. Il permet également d'exécuter des commandes (ajout/modification/suppression...) et peut donc, à ce titre, être considéré comme un langage de création de procédures automatisées.

Technologies Complémentaires et Intégration

Les annuaires électroniques peuvent être utilisés en conjonction avec d'autres applications qui les utilisent pour le stockage d'informations liées aux utilisateurs. Notamment, les technologies suivantes utilisent LDAP comme repository d'informations :

• Public Key Infrastructure (PKI) - Pour stocker les certificats et clefs publics des utilisateurs
• Microsoft Exchange - Pour stocker les informations sur la messagerie de l'utilisateur

Aussi, la mise en place d'un serveur LDAP permet souvent d'intégrer plus facilement de nouvelles applications dans l'architecture de l'entreprise, mais peut également nécessiter de nombreuses modifications pour migrer les applications existantes vers l'utilisation de LDAP.

Etant donné l'important taux d'adoption de LDAP, toute application dont l'accès nécessite une authentification devrait pouvoir s'intégrer à un annuaire LDAP, pour proposer une intégration simple à n'importe quelle architecture réseau d'entreprise.

Suite [Authentification] >>>