Discussion :

[loicmillion]

Bonjour à toute la communauté...
Peut-être n'est-ce pas le bon endroit pour poster ce message, mais je pense que l'on me le signalera si c'est le cas...

Ma question : est la suivante : "quel est l'intérêt d'un annuaire LDAP ?"
Le fondement de cette question vient du fait que mon entreprise doit se doter d'un annuaire afin de mettre en ligne un organigramme précis contenant les différents employés et permettant de voir leur fonction, leur adresse mail et leur téléphone...
Dans notre cas, nous sommes déjà doté :
- d'un côté un Active Directory qui nous donne une vue plus technique qu'organisationnelle (donc orienté système) ;
- d'un autre côté une base de données R.H., ayant une vue plus gestion humaine (avec notamment la fonction de chaque employé)...

L'intérêt est bien sûr de fédérer l'ensemble de ces informations dans une structure unique...

Mais alors : pourquoi ne pas utiliser une base de données plutôt qu'un annuaire ? L'annuaire est à mon avis plus complexe à appréhender au niveau structure, de plus, il n'y a pas de notions de relations comme dans un Oracle ou MySQL....

et y a-t-il VRAIMENT un avantage alors à déployer un annuaire LDAP ?? Qu'apporte réellement LDAP en terme de services ?

le débat est lancé...Merci....

[loicmillion]

Est-ce que ma question est trop générale ? ou peut-être trop bête ?

[berceker united]

Il me semble qu'un LDAP est plus ancien que le principe de base de données. Evidement, une base de données peut reproduire une structure d'un annuaire. L'annuaire répond à certaine norme déjà existant, d'après ce qu'ont m'a expliqué, ce qui fait qu'il y a une justesse de l'information.
Personnellement, il me semble que c'est les très grosses boite utilisant cela et ne veuille changé car trop lourd.

[loicmillion]

Merci pour ta réponse.
Effectivement, je pense aussi qu'un atout de LDAP est qu'il reste un standard, donc le mot qui me vient à l'esprit c'est interopérabilité.
Mais une autre question me vient : qu'en est-il des contraintes d'intégrités ?
Exemple : Je veux gérer des utilisateurs et des droits d'accès sur des applis, avec pour un utilisateur plusieurs droits d'accès :
- en base de données : une ligne dans la table utilisateurs <-> plusieurs lignes dans la table application, et c'est tout bon.
- en LDAP : si un utilisateur a le droit à plusieurs applications, il faut qu'il soit donc dans plusieurs endroits de l'arbre, donc il y a doublons...
Autre exemple : pour un annuaire (dans le sens "annuaire france telecom"), un employé qui pourrait être dans plusieurs services à la fois...

Est-ce que ca se gère bien ??

[berceker united]

Là, je ne serais pas t'aider je connais pas assez dans le LDAP. Je sais qu'il y a des livres expliquants le fonctionnement sinon tu peux aller voir aussi sur le site de commentçamarche il y a un article dessus.

[DegubError]

LDAP est un protocol d'accès aux annuaires, c'est en quelques sortes une normes qui ne décrit d'ailleurs pas que l'accès aux annuaires (réplication, norme nommage, modèle, sécurité ...).

Qui dit annuaire dit forcement base de données, donc il est naturel que le parallélisme avec les bases de données est proche (d'ailleurs la pluspart s'appuyent en arrière plan sur un SGBD)

Microsoft (via AD) utilise LDAP pour son système de sécurité notamment. Ainsi si un utilisateur ne peut être que dans une OU à la fois, il peut par contre être dans plusieurs groupe à la fois (la sécurité de windows étant axé principalement sur les groupes et non les OU) mais ça ne veut pas dire que l'on ne peut pas le faire, d'autres implémentation d'annuaire LDAP le permet (Novell par exemple) avec les allias. (en gros chaque applis utilise LDAP en fonction de ses besoins).

Pour répondre à tes questions LDAP, tu peux très bien mettre un employé dans plusieurs services (tout dépend comment tu vois ton service, groupe sous AD, OU sous d'autres). Chaque object sous LDAP a un ID unique donc aucun doublon possible (d'où la notion d'allias sous Novell).

Le problème c'est que pour LDAP il faut que tout soit compatible LDAP (sinon il faut un méta annuaire avec des connecteurs spécifique) ou sinon un EAI

Je ne veux pas trop m'étendre mais ce type de projet touche d'épineux problèmes : par exemple les gens de la RH ne voudront surement pas que certaines informations (salaires par exemples ) soient visible par les personnes de l'équipe informatique (si tu met tout dans Active Directory par exemple) et à l'inverse les informaticiens ne voudront peut être pas modifier AD pour le logiciel de la RH (si d'ailleurs le logiciel le permet). La solution intermédiaire étant le meta-annuaire ou un EAI. Et on va dire que ce n'est pas le type de projet le plus facile à réaliser

Sinon si c'est juste pour mettre le mail, téléphone et fonction ... AD conviendrait parfaitement, les objets utilisateurs (Person ou inetOrgPerson) contiennent tout ces champs de mémoire (à vérifier pour la fonction)

[loicmillion]

Merci pour ces réponses.

Mais alors LDAP a-t-il vraiment un intérêt en soi, si ce n'est offrir une standardisation d'accès à une information de type annuaire ?

Puisqu'en fait, pour l'accès aux informations LDAP se fera par le biais d'un connecteur, on peut très bien créer alors un connecteur accédant à une simple base de données MySQL...

J'ai l'impression quand je développe un page PHP accédant à mon OpenLDAP de revenir en arrière au point de vue technologie : exemple : pour afficher l'ensemble de mon organigramme, parcours de l'arbre "à la main"....

[berceker united]

Merci pour ces réponses.

Mais alors LDAP a-t-il vraiment un intérêt en soi, si ce n'est offrir une standardisation d'accès à une information de type annuaire ?

Puisqu'en fait, pour l'accès aux informations LDAP se fera par le biais d'un connecteur, on peut très bien créer alors un connecteur accédant à une simple base de données MySQL...

J'ai l'impression quand je développe un page PHP accédant à mon OpenLDAP de revenir en arrière au point de vue technologie : exemple : pour afficher l'ensemble de mon organigramme, parcours de l'arbre "à la main"....

Je pense que c'est à toi de définir tes besoins. Si tu penses qu'avec une simple base de données tu arrives à bien shématiser ton organisation, il n'est peut être pas nécessaire d'utiliser un LDAP. Personnellement, les LDAP j'en entend de moin en moin dans des projets de ce type. Bon, il faut dire que je ne suis pas "awar" dans le domaine