Qu’est-ce que LDAP résout?

Qu’est ce que LDAP? Quels sont les scénarios où LDAP est le bon choix?

À la base, LDAP est un protocole permettant d’accéder aux objects pouvant être stockés dans un répertoire. Que quelque chose soit “convenable” est une détermination entièrement subjective laissée aux implémenteurs, mais généralement cela signifie des collections de nombreux objects qui ont chacun des données rarement (ou jamais) mises à jour , où chaque object a une manière évidente ou canonique de rechercher:

• un annuaire téléphonique (recherche par nom ou par numéro de téléphone)
• titres dans une bibliothèque (rechercher par titre, auteur, etc.)
• locataires d’un immeuble (recherche par étage, suite, nom, etc.)

etc.

Notez que LDAP lui-même n’est qu’un protocole et ne fournit aucun stockage réel – de la même manière, HTTP n’implique rien pour savoir si vous utilisez Apache, Jetty, Tomcat, Mongrel, et al. en tant que serveur Web. (Un problème avec LDAP en général est la réutilisation déroutante des noms pour signifier différentes choses. Wikipedia a une bonne section à ce sujet.)

Les DIT sont un schéma de description hiérarchique qui se prête très bien aux algorithmes B-Tree, ce qui se traduit par des performances de recherche considérables dans la plupart des cas. Directory Server, comme OpenDS, renvoie les recherches indexées en micro-secondes, tandis que les systèmes SGBDR sont beaucoup plus lents. Les serveurs d’annuaire (souvent appelés serveurs LDAP) négocient des ressources (RAM, CPU) pour une réponse rapide en lecture. Les systèmes SGBDR offrent une plus grande fonctionnalité en termes de gestion des données en question. Besoin de vitesse avec peu ou pas de mises à jour, simplicité et petit protocole réseau? Utilisez un serveur d’annuaire. Besoin de capacités de gestion de données et d’exploration de données et / ou d’un taux de changement élevé de la firebase database avec des aspects relationnels définis entre les données? Utilisez un SGBDR (MySQL est votre meilleur pari ici).

LDAP a des performances de lecture O (1), en échange de performances d’écriture O (quelque chose de pire). Il est idéal pour les données fréquemment consultées mais rarement modifiées: répertoires de personnes, noms et adresses de machines, etc. (d’où l’acronyme: Lightweight Directory Access Protocol.)

LDAP est le bon choix lorsque la difficulté d’utiliser une firebase database non relationnelle, en termes de familiarité réduite du développeur et de caractéristiques de performance étranges, est inférieure au gain d’un access en lecture extrêmement rapide.

LDAP est une application qui se trouve au-dessus d’un magasin de persistance et une firebase database est un magasin de persistance. Les deux peuvent être utilisés pour stocker des informations utilisateur.

LDAP vous donne une hiérarchie plus difficile à faire dans une firebase database. Vous pouvez créer une hiérarchie dans une firebase database, mais il est plus difficile de faire des choses comme la délégation (ces lignes vous appartiennent uniquement) ou des ACL sur des lignes. Il est donc plus facile de repousser les problèmes de sécurité de la firebase database si vous utilisez LDAP pour stocker les identités des utilisateurs. Essayer de le résoudre dans la firebase database est bizarre.

Dans le même temps, LDAP est terrible pour la création de rapports (transformation de LDAP en firebase database pour la génération de rapports). Stocker les atsortingbuts au plus profond de l’arborescence devant faire l’object d’une recherche rapide peut être problématique pour les performances (ne le faites pas, ayez une firebase database à côté ou essayez d’aplanir la requête en redessinant votre DIT). Stocker des atsortingbuts partout dans un DIT vraiment profond est tout simplement une mauvaise conception LDAP ou système, mais il est parfois inévitable si vous êtes lié à un produit ou à une application héritée.

Ce lien explique LDAP http://blogs.oracle.com/raghuvir/entry/ldap

Nous utilisons LDAP dans notre bureau pour les recherches d’adresses de messagerie à l’échelle de l’entreprise. Nous l’utilisons également comme un service d’authentification unique pour nos applications internes.

Je travaille à temps partiel et à temps plein. Mon programme encourage (nécessite des lectures) de nombreux projets de groupe.

J’ai utilisé openLdap et phpLdapAdmin pour contrôler les access à mes repos Subversion et Mercurial, à mes projets Trac, à Hudson, etc.

Si vous avez des projets où de nombreux groupes de personnes doivent pouvoir utiliser différentes ressources, c’est un bon outil.

LDAP est juste un protocole, l’article de Wikipédia l’explique de manière adéquate http://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol

C’est un moyen d’interroger une structure organisationnelle sous-jacente telle que Microsoft Active Directory. Vous pouvez utiliser les requêtes LDAP pour obtenir toutes sortes d’informations sur les utilisateurs, l’utiliser pour définir des droits d’application, etc.

LDAP est un protocole d’access. il ne fournit qu’une API à la technologie sous-jacente pour laquelle vous essayez de trouver des applications – un service d’annuaire . OpenLDAP est l’un des services d’annuaire open source; Sun a une autre implémentation appelée OpenDS. Active Directory et Novell NDS sont deux autres couramment rencontrés sur le terrain.

Ce répertoire peut être utilisé pour stocker des informations sur tout type de ressource et les relations entre les ressources – par exemple, les droits d’un utilisateur sur un répertoire, une imprimante ou un périphérique d’access réseau.

Voir ce lien:

http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/1.html#RTFToC1

Ce qui explique profondément LDAP:

Par exemple, vous pouvez voir cette image dans cette documentation,

http://soffr.miximages.com/ldap/guide-51.gif

Dans l’un de mes anciens postes de travail, nous avons utilisé LDAP comme principal système d’authentification des utilisateurs.

Cela à son tour fourni à nos différents systèmes des informations sur le département. ils appartenaient à, où ils devraient monter leurs répertoires personnels, leurs coordonnées, la gestion des employés.

Pas nécessairement contrôlé par LDAP, mais d’autres éléments que nous avions mélangés pour travailler via LDAP étaient l’existence d’utilisateurs SQL, K4, Samba et la génération de comptes de messagerie.

Existe-t-il un bon document sur Internet pour expliquer toutes ces questions?

IBM a publié un excellent livre rouge sur LDAP. Le titre est: Comprendre LDAP – Conception et implémentation .

Il peut être téléchargé depuis le lien précédent.