[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