nur meine 2 cents, kein Erfahrungsbericht:
Prinzipiell halte ich LDAP für eine gute Idee. Ein hierarchisierter, replizierbarer Verzeichnisdienst, für den es von den meisten Plattformen eine standardisierte API gibt. Spezialisiert für schnelle READ-Zugriffe.
Man kann da Gruppen/Personen hinterlegen oder auch Factories für bestimmte Dienste.
Man hat damit aber z.B. keinen Single Sign On. Autorisierung/Authentifizierung ist davon getrennt. Man hat vielleicht eine gemeinsame Datenbank für User-Daten. Nur sind die meisten Systeme so aufgebaut, dass man da nicht einfach sagen kann: Heute haben wir diese 7 über Jahre gewachsenen Systeme und morgen kommt die Wende und alle benutzen magic ldap.
Nur hab ich da auch meine Zweifel wie Standard der Standard ist.
Hab jedenfalls viel Gejammer von Java-Leuten über MS-Active Directory gehört.
Die Versuchung für einen Hersteller, mit "seinem" LDAP Server die eigene Plattform zu übervorteilen und andere künstlich zu blockieren dürfte hoch sein.
Am glaubwürdigsten für Standardkonformität ist deshalb für mich openLDAP.
In der Frühphase von J2EE existierte - wie wir heute wissen - eine gewisse "wir können alles transparent über mehrere Server verteilen"-happiness. Man hat bestimmten code und meldet einen Einstiegspunkt für den code in LDAP ein. Da weiss jeder, wo man suchen muss und code wird besser wiederverwendbar.
Diese Verteilungs-Happiness hat aber auch deutliche Nachteile. Z.B. ist der LDAP Server ein point of failure (wenn er ausfällt, geht nichts mehr). Also braucht man den LDAP in einem Cluster für bessere Ausfallsicherheit.
Ausserdem sind calls gegen einen entfernten Server immer teurer als calls innerhalb eines Servers:
- pass by value statt pass by reference
- Netzwerk-Latenz
- Overhead durch Konvertierung method-call in Protokoll und zurück.
Eine Organisation sollte sich deshalb G.U.T. überlegen, wofür sie LDAP braucht.
Erinnert mich ein bischen an Suleiman über Message Oriented Middleware:
http://www.jroller.com/page/fate/?anchor=your_mom_sucks_and_doesnTraue niemanden und IT Architekten schon garnicht.
Axel