[LDAPGTF] Article "Faut-il sacrifier LDAP ?"
Emmanuel Lecharny
elecharny at gmail.com
Jeu 24 Juin 10:50:04 CEST 2010
On 6/24/10 10:15 AM, Ludovic Poitou wrote:
> Salut,
>
> Pour la matière et les arguments, il faut regarder et écouter ce que fait Kim Cameron avec System.identity.
> Je pense qu'il y a des besoins de services au dessus de LDAP pour fédérer les annuaires entre les entreprises, tout en respectant les contraintes de données privées et confidentielles.
> Est-ce que System.identity sera LA solution ? Je ne sais pas, c'est trop tôt pour le dire et surtout, les descriptions sont très générales et les spécifications par encore formalisées.
> A suivre !
>
Je rejoins Ludo.
Il me semble que cet article ne fait que poser des questions générales,
sans apporter de réponses. Quelques points cependant méritent une réponse :
- concernant les hiérarchies multiples :
les spécifications LDAP permettent tout à fait de disposer de plusieurs
hiérarchies (NameSpace), chacune disposant de son propre schéma. ce
n'est pas parce que M$ n'a pas implémenté la spec dans sa totalité que
celle ci est lacunaire...
- concernant la répartition des données sur plusieurs bases :
il existe des système (Referrals) permettant d'atteindre plusieurs
bases, et par ailleurs, la RFC 4533 décrit comment doit s'effectuer la
réplication de server à server (MMR), sachant que cette réplication peut
ne porter que sur un sous-ensemble de la hiérarchie d'un serveur. Par
ailleurs, s'il s'agit de récupérer des informations éparses pour une
entrée, sans dupliquer ces informations, les alias sont la solution
Je ne suis pas sûr que les points critiqués soient réellement
pertinents, en tout cas dans l'article français.
Maintenant, si on regarde LDAP et si on essaye de voir ce qui pourrait
être améliorer, il est assez rapide de définir une liste (non
exhaustive) de ce qui rend la vie difficile aux utilisateurs et
administrateurs :
- un schéma trop complexe. Au lieu de définir des types de base (int,
char, structure), on dispose juste d'un ensemble de syntaxes limité qui
n'est pas adapté à la réalité de ce que l'on veut stocker. De plus, il
n'y a pas de mécanisme standard de définition de nouvelles syntaxes.
- une réplication non standardisée jusqu'à 2006, et non encore
implémentée (sauf par OpenLDAP et avec douleur par ApacheDS). Par
aileurs, cette réplication ne porte que sur les entrées, sans gérer les
modifications concurrentes sur une entrée
- pas de mode transactionnel
- pas de gestion des accès aux données standardisée
En ce qui me concerne, je considère que les points 2 et 4 sont les plus
pénalisants. Le point 1 est clairement un obstacle, mais cela n'empêche
pas de vivre, sachant que l'on ne modifie pas sont schéma tous les jours...
Il y a beaucoup à dire sur les bases LDAP, il y a certainement de la
place pour quelque chose de plus 'moderne', mais il semble quand même
que depuis bientôt 20 ans que X500 a vu le jour, il n'y a pas eu tant
d'évolution que cela, c'est peut-être la preuve que le système est à peu
près stabilisé...
Quand à un big-bang, un peu type le mouvement no-sql, un no-ldap en qq
sorte,j e pense qu'il aura du mal à prendre, et s'il prend, ce sera
comme no-sql : un jour ou l'autre, on reviendra en arrière. C'est
périodique, l'homme a toujours envie de faire la révolution, mais après
avoir fait son 360, il revient sur ses pas ... (avec juste la tête qui
tourne pendant quelques temps ;)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
More information about the LDAPGTF
mailing list