Kennzeichen S(icherheit): Über den effizienten LDAP-Einsatz

Nicht immer ist es einfach, Server-Anwendungen auf LDAP-Basis so umzusetzen, dass das eigentlich asynchron arbeitende Protokoll tatsächlich effizient arbeitet.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 4 Min.
Von
  • Felix Gaehtgens

Nicht immer ist es einfach, Server-Anwendungen auf LDAP-Basis so umzusetzen, dass das eigentlich asynchron arbeitende Protokoll tatsächlich effizient arbeitet. Eine Erweiterung namens "Proxied Authorization Control" mag helfen, und Java-Entwickler erhalten seit letztem Jahr mit dem LDAP SDK der Firma Unbound ID eine einfach einzusetzende API.

Directory-Services mit LDAP kommen ziemlich häufig beim Speichern von Benutzerdaten zum Einsatz. Dadurch sind viele Entwickler mit der Aufgabe konfrontiert, Code zu schreiben, der auf die LDAP-Server zugreift. Hierfür gibt es einige APIs, die ihnen das Leben erleichtern. Zwar ist LDAP als asynchrones Protokoll sehr effizient, bedauerlicherweise gibt es jedoch einige Stolpersteine für Entwickler und in deren Folge nicht selten eine auf Benutzerdaten zugreifende Applikation, die schlecht skaliert oder schlichtweg viel zu langsam arbeitet.

Mehr Infos

Kennzeichen S(icherheit)

In der "Kennzeichen S(icherheit)"-Kolumne setzen sich die Analysten des Unternehmens KuppingerCole mit Themen wie Identity- und Access Management sowie IT-Governance aus Softwareentwicklungsperspektive auseinander. Es geht vor allem um die Frage, wie man Sicherheit für Anwendungen standardisieren und externalisieren kann, um Sicherheit und Nachvollziehbarkeit bei optimiertem Entwicklungsaufwand zu erreichen.

  1. Anwendungsentwicklung und Sicherheit
  2. An Ausbildung führt kein Weg vorbei
  3. Fünf Gründe für die Externalisierung der Sicherheit
  4. "Cloud-readiness" – Auswirkungen für Softwareentwickler
  5. U-Prove – Microsofts Technik für Datensicherheit
  6. Trends von der European Identity Conference
  7. Braucht es eine andere Softwareentwicklung für sichere Cloud-Anwendungen?
  8. Security bei der Entwicklung für die Cloud

Für viele Entwickler, die noch nicht viel Erfahrung mit LDAP gesammelt haben, setzt sich der Zugriff auf einen LDAP-Server wie folgt zusammen: zuerst die Verbindung mit dem Server, dann die Anmeldung über die BIND-Operation. Ist die Verbindung einmal authentiziert, lassen sich weitere LDAP-Protokoll-Operationen ausführen: SEARCH, MODIFY, DELETE, MODRDN und COMPARE, um die wichtigsten zu nennen. Oftmals ist jedoch der Verbindungsaufbau mit erfolgter Authentizierung wesentlich "kostspieliger" (in puncto Performance) als das Ausführen von weiteren Operationen. Dann mag es sinnvoller sein, eine bestehende Verbindung aufrechtzuerhalten – sofern das für die Applikation sinnvoll ist – und sie für mehrere Operationen zu verwenden.

Wenn schon von mehreren Operationen auf einer Verbindung die Rede ist, führt man diese am liebsten gleichzeitig aus. Da LDAP ein asynchrones Protokoll ist, ist es ohne weiteres möglich, mehrere Anfragen zu senden und die Resultate asynchron abzuarbeiten, wann immer sie ankommen. Gerade im Hinblick auf Multithreaded-Applikationen ist das sinnvoll. Auch bei Applikationen, die Abfragen über eine Anzahl von Nutzern ausführen müssen, kann das einen enormen Geschwindigkeitsvorteil bringen.

Oftmals ist es jedoch notwendig, LDAP-Operationen mit unterschiedlichen Befugnissen auszuführen, beispielsweise Operationen von Benutzern, die sich bei der Applikation angemeldet haben. Das wird oftmals so programmiert, dass bei jeder Anmeldung eines Benutzers eine neue Verbindung zum LDAP-Server hergestellt wird und danach die Operationen des Benutzers über diese Verbindung gesendet werden. Es gibt jedoch eine durch den RFC 4370 spezifizierte Erweiterung namens "Proxied Authorization Control", mit der sich auf einer Verbindung unterschiedliche Operationen unter den Credentials unterschiedlicher Benutzer ausführen lassen – und das natürlich asynchron. Voraussetzung dafür ist die Konfiguration eines bestimmten System-Accounts, der das darf, – und eines LDAP-Servers, der das unterstützt. Das kann fast jeder LDAP-Server – mit Ausnahme von Microsofts Active Directory, das leider bei dieser Neuerung im LDAP-Bereich nicht mitgehalten hat.

Nun ist es zwar einfach, über bessere Praktiken bei der Entwicklung von LDAP-Code zu schreiben, letztlich muss es aber auch APIs geben, die es erlauben, die Praktiken leicht umzusetzen. Hierin sah es in Vergangenheit nicht immer einfach aus. Das ist aber zumindest für Java-Entwickler spätestens durch die Freigabe des kostenlos erhältlichen LDAP SDK der Firma Unbound ID wesentlich einfacher geworden, eine erfrischende Neuerung, wesentlich effizienter und einfacher einzusetzen als gängige APIs wie JNDI oder die alte Netscape LDAP API, deren Entwicklung bereits vor vielen Jahren eingestellt wurde, trotzdem aber immer noch weite Verbreitung findet. Das LDAP SDK vereinfacht die Umsetzung der in diesem Artikel kurz umschriebenen Praktiken.

Felix Gaehtgens
ist Senior Analyst bei Kuppinger Cole, einem auf Identity Management, GRC, Cloud Computing und verwandten Themen spezialisierten Analystenunternehmen.
(ane)