non, le modèle de données est différent, on ne peut pas appliquer à LDAP le modèle de données relationnel, ni même essayer de le traduire. Il faut repartir des specs initiales.
En LDAP, les données sont hiérarchisées : l'annuaire a une racine, sous laquelle on peut mettre d'autres entrées, sous lesquelles on peut en mettre encore d'autres. Tu te constitues donc un annuaire avec des branches en plaçant sous la racine un objet de type "unité organisationnelle", que tu appelles par exemple "users", sous lequel tu places tes utiisateurs, qui sont eux de type "inetOrgPerson"
Le type d'une entrée est une classe, qui définit quels attributs l'entrée doit ou peut implémenter. Selon la spécification de la classe utilisée, il n'est pas toujours obligatoire de renseigner une valeur (par exemple, le champ 'secretary' de inetOrgPerson n'est pas renseigné si la personne n'a pas de secrétaire), et on peut souvent renseigner plusieurs valeurs (par exemple si tu as plusieurs adresses email, tu renseigne plusieurs fois le champ mail.
Ce dernier concept (les attributs multi-valués) est étranger aux SGBDR et permet souvent d'avoir un équivalent d'une distribution des données sur plusieurs tables dans un SGBD (par exemple, pour renseigner toutes les adresses emails d'une personne tu devrais avoir une table personne, et une table mail avec ID_personne et email. Ici tout est dans les infos de la personne). De plus tu peux ainsi tout récupérer en une seule requête de recherche.
Une grosse différence est aussi le système d'authentification. Avec LDAP, toute entrée de l'annuaire peut servir d'identifiant, du moment qu'elle a un mot de passe (champ 'userPassword') ou quel est référencée dans le système d'authentification utilisé.
Donc c'est naturellement que tout utilisateur peut s'authentifier, grace à l'opération LDAP du bind. Inutile d'aller chercher dans la base qui a ce login et qui a ce mot de passe.
Euh... c'était quoi la question ? Ah, oui. Et bien, donne nous un exemple, on verra ce qu'on peut faire.
LDAP ne peut dans la plupart des cas pas remplacer une base de donées relationnelle. Il est fait pour être complémentaire de celle-ci, et principalement :
- stocker des informations (et non des relations)
- assumer la fonction d'authentification
- stocker les données d'autorisation (exemple : groupes, objets)
Donc si tes relations servent à autoriser des personnes à accéder à des fonctionnalités ou à des données, c'est transcriptible sous LDAP. Pour le reste, il faut voir dans le détail. Tu peux toujours utiliser dans ta base des références vers les identifiants LDAP des utilisateurs, et mixer les deux dans ton appli PHP.
[^] # Re: Partager les comptes utilisateurs entre différentes applications
Posté par Nap . En réponse au journal Partager les comptes utilisateurs entre différentes applications. Évalué à 1.
En LDAP, les données sont hiérarchisées : l'annuaire a une racine, sous laquelle on peut mettre d'autres entrées, sous lesquelles on peut en mettre encore d'autres. Tu te constitues donc un annuaire avec des branches en plaçant sous la racine un objet de type "unité organisationnelle", que tu appelles par exemple "users", sous lequel tu places tes utiisateurs, qui sont eux de type "inetOrgPerson"
Le type d'une entrée est une classe, qui définit quels attributs l'entrée doit ou peut implémenter. Selon la spécification de la classe utilisée, il n'est pas toujours obligatoire de renseigner une valeur (par exemple, le champ 'secretary' de inetOrgPerson n'est pas renseigné si la personne n'a pas de secrétaire), et on peut souvent renseigner plusieurs valeurs (par exemple si tu as plusieurs adresses email, tu renseigne plusieurs fois le champ mail.
Ce dernier concept (les attributs multi-valués) est étranger aux SGBDR et permet souvent d'avoir un équivalent d'une distribution des données sur plusieurs tables dans un SGBD (par exemple, pour renseigner toutes les adresses emails d'une personne tu devrais avoir une table personne, et une table mail avec ID_personne et email. Ici tout est dans les infos de la personne). De plus tu peux ainsi tout récupérer en une seule requête de recherche.
Une grosse différence est aussi le système d'authentification. Avec LDAP, toute entrée de l'annuaire peut servir d'identifiant, du moment qu'elle a un mot de passe (champ 'userPassword') ou quel est référencée dans le système d'authentification utilisé.
Donc c'est naturellement que tout utilisateur peut s'authentifier, grace à l'opération LDAP du bind. Inutile d'aller chercher dans la base qui a ce login et qui a ce mot de passe.
Euh... c'était quoi la question ? Ah, oui. Et bien, donne nous un exemple, on verra ce qu'on peut faire.
LDAP ne peut dans la plupart des cas pas remplacer une base de donées relationnelle. Il est fait pour être complémentaire de celle-ci, et principalement :
- stocker des informations (et non des relations)
- assumer la fonction d'authentification
- stocker les données d'autorisation (exemple : groupes, objets)
Donc si tes relations servent à autoriser des personnes à accéder à des fonctionnalités ou à des données, c'est transcriptible sous LDAP. Pour le reste, il faut voir dans le détail. Tu peux toujours utiliser dans ta base des références vers les identifiants LDAP des utilisateurs, et mixer les deux dans ton appli PHP.