Erweiterung der Virtuellen Universität um einen LDAP Directory Service

Inhaltsverzeichnis

Erklärung

Abbildungsverzeichnis

1 Einleitung
1.1 Die Inhalte im Überblick
1.2 Die Virtuelle Universität
1.3 Directory Services
1.4 Standards für Directories: X.500 und LDAP
1.5 Weitere Begriffe und Grundlagen

2 Die Funktionsweise von LDAP
2.1 Kommunikation zwischen Client und Server
2.2 Die LDAP-Modelle
2.2.1 Das Informationsmodell
2.2.2 Das Namensmodell
2.2.3 Das Funktionsmodell
2.2.4 Das Sicherheitsmodell

3 Directory vs. Datenbank
3.1 Verhältnis von Lese- bzw. Such- zu Schreibzugriffen
3.2 Komplexität
3.2.1 Operationen
3.2.2 Anwendungslogik auf dem Server
3.2.3 Unterstützung von Transaktionen
3.2.4 Beziehungen
3.2.5 Zusammenfassung
3.3 Kapselung
3.4 Standardisierung
3.4.1 Standardisierung von Datenmodell und Schema
3.4.2 Standardisierung der Kommunikationsschnittstellen
3.4.3 Ergebnis
3.5 Verteilung von Datenbeständen auf mehrere Server
3.6 Redundante Allokation
3.7 Zugang für Internet-Anwendungen
3.7.1 Datenbank-Zugang über das Common Gateway Interface (CGI)
3.7.2 Datenbank-Zugang mit Application Programming Interfaces (APIs)
3.7.3 Andere Datenbank-Zugänge
3.7.4 Zugang zu Directory Services
3.7.5 Ergebnis
3.8 Modellierung
3.9 Flexibilität des Schemas
3.10 Zusammenfassung

4 Anwendungen
4.1 Klassische Authentifizierung
4.1.1 Klassische Authentifizierung ohne Directory Service
4.1.2 Klassische Authentifizierung mit Directory Service
4.1.3 Voraussetzungen
4.1.4 Benötigte Daten und LDAP-Operationen
4.1.5 Nebenbedingungen
4.1.6 Beurteilung
4.2 Sichere Authentifizierung und ihre Verwaltung
4.2.1 PKI ohne Directory Service
4.2.2 PKI mit Directory Service
4.2.3 Voraussetzungen
4.2.4 Benötigte Daten und LDAP-Operationen
4.2.5 Nebenbedingungen
4.2.6 Beurteilung
4.3 Zugriffskontrolle für Anwendungsserver
4.3.1 Zugriffskontrolle ohne Directory Service
4.3.2 Zugriffskontrolle mit Directory Service
4.3.3 Voraussetzungen
4.3.4 Benötigte Daten und LDAP-Operationen
4.3.5 Nebenbedingungen
4.3.6 Beurteilung
4.4 Adressierung und Verschlüsselung von Mails
4.4.1 Auskunft über Mail-Adressen
4.4.2 Bereitstellung von Zertifikaten
4.4.3 Mail Routing
4.4.4 Voraussetzungen
4.4.5 Benötigte Daten und LDAP-Operationen
4.4.6 Nebenbedingungen
4.4.7 Beurteilung
4.5 Organisationssystem für Personen und Objekte
4.5.1 Einsatzbereiche eines Organisationssystems
4.5.2 Potential eines Directory basierenden Organisationssystems
4.5.3 Voraussetzungen
4.5.4 Benötigte Daten und LDAP-Operationen
4.5.5 Nebenbedingungen
4.5.6 Beurteilung
4.6 Weitere Anwendungen
4.6.1 Verwaltung der Konfiguration von verteilten Diensten
4.6.2 Ortsunabhängigkeit des Arbeitsplatzes
4.6.3 Zugangsüberwachung mittels Kartenleser
4.6.4 Workflow-Anwendungen
4.7 Zusammenfassung
4.7.1 Zusammenstellung benötigter Daten und LDAP-Operationen
4.7.2 Zusammenfassende Beurteilung

5 Realisierung
5.1 Entwurf des Schemas
5.1.1 Vorgehensweise
5.1.2 Das Schema
5.2 Der Namensraum
5.2.1 Auswirkungen der Struktur des DIT
5.2.2 Strukturierung des DIT der FernUniversität
5.2.3 Benennung der Einträge
5.3 Partitionierung des DIT
5.4 Redundante Allokation
5.4.1 Einsatz redundanter Allokation
5.4.2 Replikationsverfahren
5.4.3 Übermittlung der Updates
5.4.4 Lastteilung und Ausfallsicherheit
5.4.5 Sonstige Anforderungen
5.4.6 Zusammenfassung
5.5 Änderung persönlicher Daten durch Benutzer
5.5.1 Änderung gemeinsamer Daten von Directory und Datenbank
5.5.2 Schnittstelle zur Änderung
5.6 Datenschutz und Datensicherheit
5.6.1 Zugriffskontrolle
5.6.2 Iterationen
5.6.3 Direkter Zugriff der Clients für Auskünfte
5.6.4 Gefahren ungesicherter Kommunikation
5.6.5 Zusammenfassung
5.7 Koexistenz des Directories mit anderen Datenquellen
5.7.1 Berücksichtigte Daten und Datenquellen
5.7.2 Grundsätzliche Alternativen der Koexistenz
5.7.3 Realisierung der Synchronisation
5.7.4 Zusammenfassung
5.8 Zusammenfassung des Modells

6 Zusammenfassung und Ausblick
6.1 Zusammenfassung der Ergebnisse
6.2 Angrenzende Themen und weitere Entwicklung

Anhang A

Literatur A

1 Einleitung

Durch die permanent wachsende Bedeutung des Internets für alle Bereiche des tägli- chen Lebens, rücken auch die im Internet verwendeten Technologien immer weiter in den Mittelpunkt des informationstechnischen Interesses. Besonders hervorgetan hat sich diesbezüglich in letzter Zeit die Technologie der LDAP Directory Services, die - schenkt man der einschlägigen Fachliteratur Glauben - im Begriff sind eine zentrale Position in modernen informationstechnischen Infrastrukturen einzunehmen. Dort wer- den sie als universelle zentrale Auskunftssysteme eingesetzt, um die Verwaltung von Benutzerdaten, Mail-Adressen, Sicherheitsinformationen u.a. zu vereinfachen.

Im Rahmen dieser Diplomarbeit wird untersucht, inwiefern der Einsatz eines LDAP Directory Service für die Virtuelle Universit ä t der FernUniversität Hagen, als einer auf dem Internet basierenden Infrastruktur zur Unterstützung von Fernstudien, sinnvoll und realisierbar ist. Dazu muss zunächst geklärt werden, wie ein LDAP Directory Service funktioniert, worin er sich von ähnlichen Systemen unterscheidet und was die wesentli- chen Vorteile seiner Verwendung sind. Darauf aufbauend können dann Einsatzmög- lichkeiten bei der Virtuellen Universität identifiziert, untersucht und beurteilt werden. Die dabei gewonnenen Erkenntnisse dienen schließlich als Grundlage für den Entwurf eines entsprechenden Directory Service.

1.1 Die Inhalte im Überblick

Dementsprechend beschäftigt sich Kapitel 2 „Die Funktionsweise von LDAP“ mit dem Protokoll, das zur Kommunikation mit dem Directory Service eingesetzt wird und dadurch seine Charakteristik maßgeblich prägt.

Um die typischen Eigenschaften eines LDAP Directory Service genauer zu spezifizieren und mögliche Einsatzbereiche abgrenzen zu können, werden in Kapitel 3 „Directory vs. Datenbank“ Directories mit den Systemen verglichen, denen sie am ähnlichsten sind, nämlich mit Datenbanken.

In Kapitel 4 „Anwendungen“ folgt dann eine detaillierte Untersuchung und Beurteilung möglicher Verwendungen eines LDAP Directory Service im Umfeld der Virtuellen Universität, einschließlich der Voraussetzungen und Nebenbedingungen, die ihre Umsetzung für den Directory Service bedeuten.

Mit den bis dahin gesammelten Erkenntnissen, wird es in Kapitel 5 „Realisierung“ anschließend möglich sein, die wesentlichen Kriterien für die Implementierung eines LDAP Directory Service zu spezifizieren.

Kapitel 6 „Zusammenfassung und Ausblick“ dient schließlich der Zusammenfassung der Ergebnisse sowie dem Ausblick auf angrenzende Themen und die weitere Entwick- lung.

Zunächst aber, wird in den folgenden Abschnitten dieses einleitenden Kapitels die Virtuelle Universität der FernUniversität Hagen kurz vorgestellt und der Begriff des Directory Service sowie seine Entwicklung und Benutzung beleuchtet. Ferner werden grundlegende Begriffe und Zusammenhänge aus dem informationstechnischen Umfeld, die für das Verständnis der weiteren Ausführungen erforderlich oder zumindest hilf- reich sind, erläutert.

1.2 Die Virtuelle Universität

Die Virtuelle Universität ist ein integriertes Online-System, das an der FernUniversi- tät Hagen entwickelt wurde, um den Studenten weitestgehende räumliche und zeitliche Unabhängigkeit für ihr Studium zu bieten. Diese Zielsetzung ist insbesondere vor dem Hintergrund der Situation der Fernstudenten zu sehen, die in der Regel neben einer be- ruflichen Tätigkeit ihrem Studium nachgehen und deshalb die Dienstleistungen der FernUniversität von Zuhause aus und zu individuell unterschiedlichen Zeiten in An- spruch nehmen möchten. Das ideale Medium zur Realisierung dieser beiden Ziele bietet das Internet, das heutzutage flächendeckend und rund um die Uhr verschiedenste Diens- te zur Verfügung stellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.2-1: Oberfläche der Virtuellen Universität im Browser

Inhalte und Funktionen

Die Studenten erhalten über die Virtuelle Universität Zugang zu allen Informationen und Funktionen, die mit ihrem Studium zusammenhängen [BMS96a], [BMS96b]: neben dem Zugang zu Lehrmaterialien wie z.B. Textkursen, Computer Based Trainings, Vi- deos, Animationen und Simulationen, können sie an interaktiven Lehrveranstaltungen, Übungsgruppen und Praktika teilnehmen. Sie sind in der Lage administrative Funktio- nen wie das Belegen von Kursen, die Rückmeldung zum nächsten Semester oder die Änderung der persönlichen Daten zu erledigen. Alle wichtigen Informationen rund um das Fernstudium stehen in strukturierter Form zur Verfügung. In der Bibliothek der FernUniversität können die Studenten online Bücher suchen und zur Fernausleihe be- stellen bzw. online verfügbare Veröffentlichungen auf ihren PC laden. Forschende ha- ben Zugriff auf Papers und Berichte zu Forschungsprojekten an der FernUniversität.

Schließlich gibt es durch alle Bereiche hindurch die Möglichkeit sich über Schwarze Bretter, Chat, Videokonferenz oder Mail mit Kommilitonen, Tutoren und Professoren auszutauschen, um so die soziale Isolation des Fernstudiums zu überwinden.

Technische Voraussetzungen

Um die Virtuelle Universität nutzen zu können, benötigt man neben einem PC einen Zugang zum Internet. Dieser kann z.B. über das Projekt „Uni@home“ eingerichtet wer- den, das den Studenten einen bundesweiten Netzzugang zum Ortstarif ermöglicht [FUH99]. Darüber hinaus ist eine Browser-Software erforderlich, die mit Hilfe von in- tegrierten sogenannten „Helper Applications“ die Funktionen realisiert [BMS96a]. Um den Missbrauch durch Unberechtigte zu verhindern, erfolgt die Kommunikation mittels einer „sicheren Verbindung“ über Secure Socket Layer (SSL, siehe 1.5 „Weitere Begrif- fe und Grundlagen“) und ist durch eine Benutzerkennung und ein Kennwort geschützt.

1.3 Directory Services

Der Begriff Directory Service bedeutet auf deutsch Verzeichnisdienst. Daraus wird deutlich, dass es sich um einen (Computer-)Dienst handelt, der ein Verzeichnis zur Ver- fügung stellt. Verzeichnissen begegnet man überall im täglichen Leben. Die letzte Be- gegnung mit einem Verzeichnis hatte der Leser vor wenigen Seiten: das Inhaltsverzeichnis dieser Diplomarbeit. Andere Beispiele sind Telefonbücher, Mitarbei- terverzeichnisse, Vorlesungsverzeichnisse usw. Dabei bestehen Verzeichnisse immer aus einer Anzahl von Einträgen, die jeweils verschiedene Informationen zu einem Ob- jekt enthalten und nach bestimmten Kriterien gruppiert sein können. So enthält das In- haltsverzeichnis dieser Diplomarbeit Einträge, in denen die Kapitel- und Abschnittüberschriften sowie deren Seitenzahlen zu finden sind. Die Einträge sind nach Kapitel gruppiert und nach Seitenzahlen sortiert. Ein Telefonbuch hingegen enthält Ein- träge, die neben dem Namen und der Telefonnummer von Personen ggf. noch weitere Informationen wie Adresse oder Beruf enthalten können. Die Einträge sind dort nach Orten gruppiert und innerhalb der Orte alphabetisch nach Namen sortiert.

Arten von Directories

Analog zu den gedruckten „Papierverzeichnissen“, gibt es elektronische Verzeichnisse (Directories), die von Computern zur Verfügung gestellt werden. Es handelt sich dabei um spezielle Datenbanken, die getypte Informationen zu Objekten wie z.B. Personen, Gruppen, Computern, Druckern usw. speichern. Die ersten Directories tauchten bereits in den frühen 70‘er Jahren auf und dienten auf Großrechnersystemen der Benutzerverwaltung. Seitdem gab es eine Vielzahl von Entwicklungen, die die Einsatzmöglichkeiten von Directories erheblich erweiterten:

- Directories werden als integrierter Bestandteil von Mail- und Groupware-Produkten wie z.B. Lotus Notes, Novell GroupWise oder Microsoft Exchange zur Verwaltung von Benutzern und Gruppen eingesetzt.
- Internet Directories wie z.B. Yahoo’s Four11 Directory (http://www.four11.com) dienen als zentrale Auskunftssysteme für Benutzer des Internets, die Mail-Adressen, Telefonnummern etc. suchen.
- Directories werden in Netzwerkbetriebsystemen eingesetzt, um Netzwerkressourcen zu verwalten. Beispiele sind die Novell Directory Services (NDS) in Novell’s Netware und das Active Directory in Microsoft’s Windows 2000.

Während diese Directories nur bestimmte Objekte für bestimmte Aufgaben verwalten und/oder nur in einer homogenen Umgebung, d.h. mit Hilfe der speziellen Software eines bestimmten Herstellers zugänglich sind, gibt es auch Directories, die diese Einschränkungen überwinden. Sie sind in der Lage verschiedenste Objekte und ihre Eigenschaften zu speichern, um damit beliebige Anwendungen zu bedienen. Der Aufbau solcher Directories und der Zugriff auf sie ist durch Standards geregelt, die von einer Vielzahl von Herstellern unterstützt werden und dadurch auch in heterogenen Umfeldern nutzbar sind. Beispiele für solche Standards sind X.500 und LDAP, die im weiteren Verlauf dieses Kapitels noch betrachtet werden.

Verwendung

Ein Benutzer kann die Einträge von standardisierten Mehrzweck-Directories nach beliebigen Kriterien durchsuchen und auf die Informationen der passenden Objekte zu- greifen. Dabei spielt es keine Rolle, welche Software er dazu verwendet, solange diese den Standard unterstützt. Wenn er z.B. den Namen einer Person weiß, kann er ein Mit- arbeiterverzeichnis nach dieser Person durchsuchen, um die Mail-Adresse zu ermitteln. Hat er den Namen vergessen, reicht auch eine beliebige andere Information, wie die Zimmernummer des Gesuchten. In einem Verzeichnis der Netzwerkressourcen eines Unternehmens kann er sehr effizient den räumlich nächsten Netzwerkdrucker mit einer Duplexeinheit ermitteln, um einen Druckjob dorthin zu schicken. Die Einsatzmöglich- keiten sind dabei kaum begrenzt und werden ein zentrales Thema dieser Diplomarbeit sein.

Abschließend sollte sich der Leser ein erstes Bild von der einfachen und intuitiven Verwendung eines Directory Service machen. Hierzu ist - abgesehen von einem PC mit Internet-Zugang - nichts weiter nötig, als ein Browser wie z.B. der Netscape Communi- cator oder der Microsoft Internet Explorer in einer aktuellen Version. In diesen Brow- sern sind bereits einige Directory Services vorkonfiguriert. Beim Internet Explorer ruft man lediglich „Bearbeiten - Verzeichnis durchsuchen“ auf und wählt im folgenden Dia- log den Directory Service und die Suchkriterien aus, vgl. Abbildung 1.3-1. Nach erfolg- reicher Suche werden die Ergebnisse dann im unteren Listenfenster angezeigt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.3-1: Directory-Zugriff mit einem Browser

1.4 Standards für Directories: X.500 und LDAP

In der Welt der Directories haben sich insbesondere zwei Standards etabliert: X.500 und LDAP. Im Folgenden werden die Entwicklung dieser Standards und die Merkmale, die sie unterscheiden, dargestellt.

Der X.500-Standard

Der X.500-Standard wurde 1988 vom CCITT (Consultative Committee on Internati- onal Telephony and Telegraphy) - der heutigen ITU-T (International Telecommunica- tions Union - Telecommunication Standardization Section) - definiert. Er besteht aus einer Reihe von Spezifikationen (X.500 - X.525) und behandelt alle im Zusammenhang mit einem standardisierten Directory Service relevanten Themen wie z.B. Datentypen, Datenorganisation, Operationen, Replikation und Sicherheitsmechanismen [ITU93], [ITU97].

Wie im vorigen Abschnitt dargestellt, greifen Benutzer mittels Anwendungspro- grammen auf den Directory Service zu. Da der Directory Service sinnvollerweise allen Benutzern in einer Institution dienen soll, wird er auf einem oder mehreren Netzwerk- server(n) installiert. Der Zugriff des Benutzers erfolgt dann von seinem Client- Computer aus über das Netzwerk. Die technischen Einzelheiten der Kommunikation zwischen Client und Server sind in Protokollen geregelt. Für den X.500 Standard er- folgte dies in der X.519-Spezifikation, die die Kommunikation zwischen Directory- Client und -Server durch das Directory Access Protocol (DAP) festlegt.

X.500 und seine Weiterentwicklungen definieren einen sehr mächtigen und leis- tungsfähigen Directory Service und wurden daher von vielen Herstellern unterstützt. Es zeigten sich jedoch auch relativ bald einige Schwächen. Dazu gehörte insbesondere das DAP. DAP-Clients waren aufwendig und komplex zu entwickeln, benötigten viele Res- sourcen sowie einen vollständigen OSI-Protokoll-Stack (siehe 1.5 „Weitere Begriffe und Grundlagen“) und ihre Performanz ließ zu wünschen übrig [HSG99, S. 50-52]. Dies behinderte die Entwicklung von Directory-fähigen Anwendungen und beschränkte ihre Verbreitung auf leistungsstarke Geräte, wodurch die damaligen Desktops ausgeschlos- sen wurden.

Die Entwicklung von LDAP

Um den geschilderten Problemen zu begegnen, wurde das Lightweight Directory Access Protocol (LDAP) entwickelt¹. Es ist - wie der Name schon sagt - ein leichtgewichtiges DAP, also ein Protokoll, das es dem Client ermöglicht einfach und effizient Queries an einen Directory-Server zu übermitteln. Folgende Unterschiede zum DAP sorgten für die „Gewichtsreduzierung“ [YHK95], [WHK97]:

- LDAP läuft direkt über TCP (siehe 1.5 „Weitere Begriffe und Grundlagen“) anstatt über den OSI-Protokoll-Stack. Dadurch wird der Overhead, der beim DAP in den oberen OSI-Schichten für den Verbindungsaufbau und die Pakethandhabung ent- steht, reduziert [How95, S. 4]. Ein Client benötigt für die Kommunikation mit dem Server nur noch TCP/IP, das auf (fast) allen Client-Plattformen bereits mitgeliefert wird.
- Die Datenrepräsentation wurde durch weitgehende Verwendung einfacher Strings deutlich vereinfacht.
- Wenig benutzte X.500-Features, die viel Aufwand produzieren, wurden weggelas- sen bzw. mit anderen Operationen emuliert².
- Die Codierung der Daten für den Transport über das Netzwerk wurde gegenüber DAP vereinfacht, indem man nur noch eine Teilmenge der X.500 Codierungsregeln verwendete.

Nach der ersten Version von 1993 [YHK93], war LDAP Version 2 (LDAPv2) die erste weitverbreitet verwendete Fassung von LDAP. Damit war nun im Vergleich zu DAP eine leichtere Implementierung und verbesserte Performanz von Directory-fähigen Anwendungen möglich, wie [How95, Kapitel 6] deutlich zeigt. Hierfür war nicht zuletzt das an der Universität von Michigan entwickelte LDAPv2-Client-API [HoS95] verant- wortlich, das dazu beitrug, dass auf praktisch allen Plattformen in relativ kurzer Zeit eine große Anzahl von Directory-Tools und Directory-fähigen Anwendungen entwi- ckelt wurden. Heute erfährt LDAP breite Unterstützung durch eine große Zahl von Her- stellern und selbst viele nicht standardisierte Directories, wie z.B. das im Microsoft Exchange-Server integrierte Directory, bieten LDAP als zusätzliches Protokoll an. Dadurch ist LDAP zum quasi-Standard für Directory Service Protokolle geworden [JBH98] [HSG99], obwohl die IETF LDAPv2 nur als „Draft Standard“ und die aktuelle Version 3 (LDAPv3) sogar nur als „Proposed Standard“ führt (vgl. hierzu auch 1.5 „Weitere Begriffe und Grundlagen“)

Die Spezifikation von LDAP erfolgte jeweils durch sogenannte Requests for Com- ments (RFCs) (vgl. ebenfalls Abschnitt 1.5), deren Inhalte und die sich daraus ergeben- de Funktionsweise des Protokolls in Kapitel 2 „Die Funktionsweise von LDAP“ untersucht werden. Soweit nicht ausdrücklich erwähnt, wird in dieser Arbeit die Version 3 (LDAPv3) zugrunde gelegt.

1.5 Weitere Begriffe und Grundlagen

In diesem Abschnitt werden grundlegende Begriffe und Zusammenhänge, die für das Verständnis der weiteren Ausführungen erforderlich oder zumindest hilfreich sind, erläutert. Der kundige Leser kann ihn daher überfliegen oder sogar auslassen.

Standards

Die Internet Engineering Task Force (IETF) ist eine Tochterinstitution des Internet Architecture Board (IAB) und besteht aus einer internationalen offenen Gruppe von Netzwerk-Spezialisten. Jeder Interessierte kann ihr beitreten. Sie beschäftigt sich mit der Weiterentwicklung und Standardisierung von Protokollen für das Internet. Jedes neue Protokoll wird von den Mitgliedern zunächst als sogenannter Internet Draft spe- zifiziert, dann ausführlich diskutiert und verbessert. Wenn es bestimmte Anforderungen erfüllt, wird es anschließend in einem sogenannten Request for Comments (RFC) veröf- fentlicht und erhält eine eindeutige RFC-Nummer. Alle RFCs sind frei erhältlich, z.B. unter http://www.rfc-editor.org. Jedes Protokoll durchläuft dann auf seinem wei- teren Weg zum Standard verschiedene Stufen (Proposed Standard, Draft Standard und Internet Standard). Im Verlauf dieses Prozesses wird es weiter diskutiert, imple- mentiert, intensiv getestet und verbessert. Als fertiger Standard erhält es schließlich eine STD-Nummer. Die Beschreibung des Standardisierungsprozesses und der aktuelle Status der einzelnen Protokolle finden sich in [PoRe99].

Eine andere Organisation, die sich mit Netzwerk-Standards beschäftigt, ist die Inter- national Standards Organization (ISO). Sie entwickelte das sogenannte OSI-Modell (Open Systems Interconnection) als Referenzmodell für die Festlegung von Kommuni- kationsstandards für offene Systeme. Nach dem OSI-Modell hat ein Protokoll sieben Schichten, die sukzessive von den physikalischen Details der Datenübertragung abstra- hieren:

1. Physikalische Schicht: Kabel, Stecker und elektrische Signalgebung
2. Schicht der Datenverbindung: Packetierung der Daten vor der Übertragung
3. Netzwerk-Schicht: Verbindungen zwischen zwei getrennten Systemen
4. Transport-Schicht: Umwandlung der Daten zur Übertragung über das Netzwerk
5. Session-Schicht: Festlegung von Übertragungsbeginn und -ende
6. Präsentations-Schicht: Rück-Umwandlung der Daten beim Empfänger
7. Anwendungs-Schicht: Festlegung der Nachrichten zwischen verschiedenen Pro- grammen

Die Schichten sind jeweils funktionsorientiert definiert und bedürfen der genauen Regelung durch spezielle Standards. Schwächen des Modells sind die schlecht strukturierte und überladene Anwendungsschicht und die aufwendige Implementierung solcher geschichteter Protokolle [Dadam96].

Protokolle

TCP/IP ist eigentlich nicht nur ein sondern es sind zwei Protokolle, nämlich das Transmission Control Protocol (TCP) [Post81a], das Daten zum Transport zwischen Rechnern in Pakete aufteilt, diese überträgt und beim Empfänger wieder zusammenfügt sowie das Internet Protocol (IP) [Post81b], das die Wegfindung der Pakete durch das Internet (das sogenannte Routing) regelt. TCP/IP ist einfacher strukturiert als das o.a. ISO/OSI-Referenzmodell und dadurch leichter zu implementieren [Hart97]:

Abbildung in dieser Leseprobe nicht enthalten

Ferner ist TCP/IP frei verfügbar und auch deshalb heute in allen gängigen Betriebs- systemen enthalten. Es ist das Standardprotokoll für das Internet und Intranets und bil- det die Grundlage für weitere Internet-Anwendungsprotokolle wie FTP, HTTP, SMTP oder LDAP.

Das File Transfer Protocol (FTP) [PoRe85] regelt die Übertragung von Dateien von einem Rechner zu einem anderen. Der Vorteil des Zugriffs auf Dateien via FTP ist die Plattformunabhängigkeit: Clients können mit einfachen und frei verfügbaren FTP-Tools auf FTP-Server zugreifen, unabhängig davon, welches Betriebs- und Dateisystem der Server verwendet. Dabei kann der Zugriff generell oder bestimmte Zugriffsarten durch eine Benutzerkennung und ein Kennwort geschützt werden.

Das Hypertext Transfer Protocol (HTTP) [FGM99] ist heute das wohl populärste Anwendungsprotokoll und ohne Zweifel mit verantwortlich für den großen Erfolg des Internet. Wie der Name bereits sagt, handelt es sich dabei um ein Protokoll, das hauptsächlich zum Transfer von Hypertext-Dokumenten von Internet-Servern zu Clients verwendet wird. Hypertext-Dokumente sind Dokumente, wie sie im World Wide Web verwendet werden. Sie bieten eine große Flexibilität hinsichtlich integrierbarer multimedialer und interaktiver Elemente und werden in einer Seitenbeschreibungssprache, der Hypertext Markup Language (HTML) [BeCo95] verfasst.

Zur Handhabung von elektronischer Post werden im Internet verschiedene Protokolle eingesetzt. Das Simple Mail Transfer Protocol (SMTP) [Post82] dient der Übertragung von Nachrichten zwischen mehreren Rechnern. Ein Benutzer, der eine Nachricht auf seinem PC geschrieben hat, liefert die Nachricht mittels seines Mail-Programms und des SMTP-Protokolls an den für ihn zuständigen SMTP-Serverdienst ab. Dieser leitet die Nachricht dann analog an den Mail-Server des Empfängers weiter. Zum Abholen von Nachrichten und Verwalten von Postfächern auf ihrem Mail-Server können Benut- zer entweder das Post Office Protocol Version 3 (POP3) [MyRo96] oder das Internet Message Access Protocol Version 4 (IMAP4) [Cris94] verwenden. Die meisten Mail- Programme und Mail-Server beherrschen heute beide Protokolle, so dass der Benutzer dies nicht problematisieren muss. In jedem Fall wird jedoch ein Missbrauch durch Au- thentifizierung der Benutzer verhindert.

Im Gegensatz zu elektronischer Post, die von einem Benutzer an einzelne andere Benutzer verschickt wird, steht die Kommunikation in Diskussionsgruppen einem größeren Personenkreis oder sogar der Allgemeinheit offen. Diskussionsgruppen werden von News-Servern zur Verfügung gestellt. Zur Kommunikation zwischen Server und Client wird das Network News Transfer Protocol (NNTP) [KaLa86] verwendet.

Eine weitere Art der elektronischen Kommunikation ist der sogenannte Internet Re- lay Chat. Es handelt sich dabei um ein Konferenzsystem, bei dem sich Clients unter Zuhilfenahme spezieller Software an einem Chat-Server anmelden können, um online Textnachrichten auszutauschen. Dabei kommt das Internet Relay Chat Protocol (IRCP) [OiRe93] zum Einsatz. Soll die Konferenz nicht nur über Textnachrichten, sondern mit Video- oder Audiounterstützung realisiert werden, so kommen spezielle Videokonfe- renz-Server zum Einsatz. Diese arbeiten meist unter Verwendung des User Datagram Protocol (UDP) [Post80], einem transaktionsorientierten Protokoll, das mit einem Mi- nimum an Protokoll-Mechnismen auskommt und deshalb sehr effizient arbeitet, ande- rerseits jedoch keine geordnete Zustellung der Datenpakete garantieren kann. Hierbei schwankt die Wiedergabequalität mit der Bandbreite der Kommunikationsverbindung. Sinnvollerweise sollte mindestens eine ISDN-Verbindung zur Verfügung stehen.

Sicherheit

Zur Gewährleistung der Sicherheit bei der Kommunikation mit Internet-Servern, un- terstützen diese heutzutage durchgängig verschiedene Sicherheitsmechanismen, vgl. z.B. [Micr96]. Dabei spielen insbesondere Secure Sockets Layer (SSL) und sein „Nach- folger“Transport Layer Security (TLS) eine wesentliche Rolle. Es handelt sich dabei um Protokolle, die als Protokollschicht zwischen der TCP/IP-Schicht und der Anwen- dungsschicht (z.B. HTTP) die Sicherheit von Daten gewährleisten. Dazu bieten sie Ver- schlüsselung, Server- und/oder Client-Echtheitsbestätigung und Datenintegrität für eine TCP/IP-Verbindung. Dabei verschlüsselt das SSL- bzw. TLS-Protokoll den Datenstrom des Anwendungsprotokolls, ohne die Charakteristika des Anwendungsprotokolls selbst zu verändern. Das Ergebnis ist, dass die Kommunikation von Dritten nicht mehr „abgehört“ werden kann. SSL-fähige Clients sind z.B. gängige Browser wie der Microsoft Internet Explorer oder der Netscape Navigator.

Generell unterscheidet man symmetrische und asymmetrische Verschl ü sselungsver- fahren. Erstere verschlüsseln mit einem einzigen geheimen Schlüssel, den beide Partei- en besitzen. Das Problem hierbei ist der sichere Austausch des Schlüssels. Die zweite Gruppe benutzt zur Verschlüsselung einen öffentlichen und zur Entschlüsselung einen privaten Schlüssel. Der private Schlüssel verbleibt ausschließlich beim Besitzer und wird nicht übertragen. Der öffentliche Schlüssel hingegen ist frei verfügbar und kann deshalb problemlos auch über unsichere Netze wie das Internet übertragen werden. Um die Zugehörigkeit eines öffentlichen Schlüssels zu einer Person oder einer Institution nachzuweisen, wird er in einem sogenannten Zertifikat verbreitet. Dieses enthält neben dem Schlüssel und Angaben zum Subjekt auch eine Prüfsumme und die digitale Unter- schrift³ einer vertrauenswürdigen Institution (Certification Authority, CA)⁴, welche die Integrität des Zertifikats sicherstellen. Wird ein Zertifikat durch einen Dritten abgefan- gen, so nützt es ihm nichts, da er nicht über den privaten Schlüssel verfügt, der zum öffentlichen Schlüssel im Zertifikat gehört und somit die verschlüsselte Kommunikation nicht entschlüsseln kann.

Der Nachteil der asymmetrischen Verschlüsselung ist, dass sie deutlich langsamer arbeitet als die symmetrische Verschlüsselung [Michl98]. Bei SSL / TLS werden des- halb die beiden Verfahren kombiniert, um die jeweiligen Vorteile zu nutzen ohne die Nachteile in Kauf nehmen zu müssen: man verwendet das asymmetrische Verfahren nur zur Authentifizierung und um einen geheimen Schlüssel verschlüsselt zu übertragen. Dieser ist dann für die Dauer der Verbindung zwischen Client und Server gültig und dient zur (schnellen) symmetrischen Verschlüsselung der weiteren Kommunikation. Sollen sich beide Parteien gegenseitig authentifizieren, müssen sie also jeweils ein eigenes Zertifikat besitzen, das von einer Zertifizierungsstelle ausgestellt wurde. Ferner müssen sie das Zertifikat der entsprechenden CA besitzen, um überprüfen zu können, ob die digitale Unterschrift im Zertifikat der anderen Partei korrekt ist.

Neben SSL/TLS kann zur digitalen Signierung und/oder Verschlüsselung auch das frei erhältliche Pretty Good Privacy (PGP) verwendet werden, das sehr ähnlich zu SSL arbeitet. Auch hier werden asymmetrische und symmetrische Verschlüsselung in einem zweistufigen Verfahren kombiniert. Der wesentliche Unterschied zwischen beiden ist, dass PGP selbst in der Anwendungsschicht des OSI-Modells beheimatet ist. Dies be- deutet, dass eine Anwendung selbst die Ver- bzw. Entschlüsselung und das Signieren bzw. Verifizieren beherrschen muss. Dazu sind unter Umständen Plug-Ins, Applets, CGI-Skripts usw. zur Erweiterung der Anwendungen erforderlich, wie z.B. das entspre- chende Plug-In für den Netscape Communicator. PGP hat hauptsächlich bei der Versendung von Mails breite Verwendung gefunden.

Eine weitere Alternative stellt die sogenannte Secure Shell (ssh) dar. Auch sie dient zur Übertragung von Kennwörtern und Daten über einen sicheren - weil verschlüsselten - Datenkanal. Dabei kommen ebenfalls private und öffentliche Schlüssel zum Einsatz. ssh wird hauptsächlich als Ersatz für telnet, rlogin, rsh und rcp verwendet. Man kann es aber auch einsetzen, um die Übertragung des Kennworts im Rahmen der Anmeldung bei einem POP3- oder FTP-Server und die anschließende Kommunikation zu verschlüs- seln, vgl. [Wenz98b].

Ebenfalls aus dem Bereich Netzwerksicherheit stammt der Begriff Firewall, mit dem ein System bezeichnet wird, das unerwünschte Zugriffe auf Computer im internen Netzwerk einer Institution durch externe Personen über eine Netzwerkverbindung zum Internet verhindert. Eine andere Möglichkeit zur Einschränkung möglicher Netzwerk- zugriffe sind sogenannte Virtual Local Area Networks (VLANs). Dabei handelt es sich um eine logische Gruppe von Computern, die unabhängig von ihrer physikalischen An- ordnung zusammengefasst werden, um insbesondere von Zugriffen durch andere Com- puter isoliert zu sein.

Sonstiges

Uniform Resource Locator (URL) werden verwendet, um Ressourcen im Internet eindeutig zu bezeichnen. Das kann z.B. eine Seite im World Wide Web oder eine Datei auf einem FTP-Server sein. Ein URL setzt sich aus der Bezeichnung des Anwendungs- protokolls und der Adresse der Ressource zusammen (Beispiel: http://www.fernuni- hagen.de oder ldap://dirsrv.fernuni-hagen.de).

2 Die Funktionsweise von LDAP

Die Spezifikation von LDAP durch erfolgte RFCs. Die Version 2 (LDAPv2) ist in den RFCs 1777-1779,1959 und 1960 beschrieben. Die weiterentwickelte Version 3 (LDAPv3) in den RFCs 2251-2256. Daneben gibt es diverse Internet Drafts, die diese Spezifikationen erweitern. Die wesentlichen Inhalte der genannten RFCs sind:

- RFC 2251 (1777): das Kommunikationsprotokoll selbst.
- RFC 2252 (1778): die Syntax von Attributen und die Darstellung ihrer Werte mit Hilfe von Strings
- RFC 2253 (1779): die Darstellung der eindeutigen Bezeichner der Directory- Einträge (der sogenannten Distinguished Names, DNs) durch Strings.
- RFC 2254 (1960): die Darstellung von Suchfiltern durch leicht lesbare Strings.
- RFC 2255 (1959): das Stellen von Anfragen an einen LDAP-Server durch einen URL.
- RFC 2256: Attributtypen und Objektklassen (siehe unten) aus dem X.500-Standard, die ein LDAP-Server kennen sollte.

Im Folgenden sollen die wesentlichen Inhalte dieser RFCs und die sich daraus ergebende Funktionsweise von LDAP näher untersucht werden. Dabei wird soweit nicht ausdrücklich erwähnt, die aktuelle Version 3 (LDAPv3) zugrunde gelegt.

2.1 Kommunikation zwischen Client und Server

LDAP ist ein Kommunikationsprotokoll, das auf TCP/IP aufsetzt. Es legt fest, wie ein LDAP-Client mit einem LDAP-Server kommuniziert, um auf Informationen im Di- rectory zuzugreifen. Die Kommunikation erfolgt dabei durch eine Menge von Nachrich- ten, die zwischen Client und Server ausgetauscht werden. Voraussetzung für eine Kommunikation ist gewöhnlich das Bestehen einer TCP/IP-Verbindung zwischen Cli- ent und Server⁵. Der typische Verlauf der Kommunikation stellt sich wie folgt dar, vgl. auch Abbildung 2.1-1:

- Zunächst stellt der Client eine TCP-Verbindung zum LDAP-Server her. Dies erfolgt auf Port 389. Der Client überträgt eine Nachricht mit der LDAP-Operation Bind, mit der er sich entweder anonym oder als ein bestimmter Benutzer beim Server anmeldet. Sofern die Anmeldung nicht anonym erfolgt, gibt er zur Authentifizierung entweder ein Kennwort oder ein digitales Zertifikat mit.

- Erfolg oder Misserfolg der Anmeldung wird dem Client mitgeteilt.
- Nach erfolgreicher Anmeldung, kann der Client auf die Informationen im Directory zugreifen.
- Schließlich sendet der Client eine Nachricht mit der LDAP-Operation Unbind an den Server, um sich abzumelden, woraufhin dieser die Verbindung beendet.

Abbildung in dieser Leseprobe nicht enthalten

Abbau der Verbindung LDAP-Server

Abbildung 2.1-1: Typischer Verlauf einer LDAP-Kommunikation

Der Zugriff auf die Informationen des Directories erfolgt ebenfalls durch den Austausch von Nachrichten. Der Ablauf wird anhand eines Beispiels [HSG99, S. 71 ff.] deutlich, vgl. Abbildung 2.1-2:

- Ein Client, der nach Einträgen im Directory sucht, schickt nach erfolgreichem Ver- bindungsaufbau eine Nachricht an den Server. Diese Nachricht enthält eine Suchan- frage.
- Der Server sucht die passenden Einträge in seinem Datenbestand, verpackt diese jeweils in eine Nachricht und schickt sie zurück an den Client.
- Schließlich schickt der Server eine separate Nachricht mit einem Ergebniscode an den Client, der z.B. den Erfolg der Operation anzeigt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1-2: Nachrichtenaustausch zwischen Client und Server

Eigenschaften

Dieses Vorgehen erlaubt es einem Client, mehrere Anfragen gleichzeitig zu stellen. Dabei werden die Anfragen durch Nachrichten-IDs unterschieden. Der Server fügt dann jeder Nachricht, die er an den Client zurückschickt, die entsprechende Nachrichten-ID der Anfrage an, auf die sich die Antwort bezieht. So ist es unkritisch, wenn sich Nachrichten überholen, da eine eindeutige Zuordnung jederzeit möglich ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1-3: Parallele Suchanfragen

Ein weiterer Vorteil dieses Vorgehens ist, dass mehrere Operationen gleichzeitig ü ber eine Verbindung abgewickelt werden können. Dadurch wird die Anzahl der Verbindungen, die der Server gleichzeitig bedienen muss, und damit der Verwaltungsaufwand gering gehalten.

Softwareanbindung und Tools

Die Verwendung von LDAP-Operationen in Softwareprogrammen wird durch den Einsatz entsprechender Entwicklungsumgebungen für LDAP⁶ möglich. Dazu enthalten die SDKs eine LDAP Client Library, welche über ein Application Programming Inter- face (API) ansprechbar ist und Nachrichten für alle Operationen erzeugen kann sowie einige Hilfsroutinen implementiert (vgl. Abbildung 2.1-4). Dadurch ist es möglich, aus beliebigen Programmen heraus über ein API auf einen LDAP-Server zuzugreifen.

Leider ist es bei LDAP nicht möglich, die Kommunikation zwischen Client und Ser- ver so einfach zu testen, wie dies beispielsweise bei HTTP, POP oder SMTP (vgl. 1.5 „Weitere Begriffe und Grundlagen“) funktioniert, indem man sich über ein Telnet-Tool mit dem LDAP-Port des Servers verbindet, weil LDAP kein textbasiertes Protokoll ist. Allerdings gibt es dafür sogenannte Command Line Tools, die in den meisten SDKs für LDAP enthalten sind. Mit diesen Tools kann man an der Eingabeaufforderung oder über eine grafische Benutzeroberfläche LDAP-Operationen ausführen, wobei auch Details, wie z.B. die o.a. Nachrichten-IDs, sichtbar gemacht werden können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1-4: Zugriff auf einen LDAP-Server über ein LDAP-API

Ferner gibt es inzwischen eine Vielzahl von fertigen Software-Tools, die entsprechende Möglichkeiten bieten auf einen LDAP Directory Service zuzugreifen. Dazu kann man auch die heute gängigen Browser zählen, über die durch direkte Eingabe eines speziellen URLs bzw. über entsprechende Links genau spezifizierte Einträge eines Directories gefunden und angezeigt werden können.

2.2 Die LDAP-Modelle

LDAP basiert auf vier Modellen, die im Folgenden näher beleuchtet werden:

- ein Informationsmodell, das den Aufbau der elementaren Informationseinheiten des Directories spezifiziert
- ein Namensmodell, das die Organisation und Referenzierung der Daten in einem Directory beschreibt
- ein Funktionsmodell, das festlegt, welche Operationen auf den Daten ausgeführt werden können
- und schließlich ein Sicherheitsmodell, das die Daten im Directory vor unberech- tigten Zugriffen schützt.

2.2.1 Das Informationsmodell

Das LDAP Informationsmodell legt fest, wie die elementaren Datenelemente des Di- rectories aufgebaut sind. Dazu werden insbesondere Einträge, Attribute und Objektklas- sen verwendet.

Eintr ä ge und Attribute

Die Informationen zu einem (Realwelt-) Objekt wie z.B. einer Person, einem Dru- cker oder einem Server, sind in einem LDAP-Directory zu einem Eintrag zusammenge- fasst. Der Aufbau von Einträgen richtet sich - ähnlich wie auch bei Datenbanken - nach den Festlegungen eines Schemas. Ein Eintrag besitzt Attribute, die die Eigenschaften des Objekts repräsentieren. Dabei hat jedes Attribut einen Typ und kann einen oder mehrere Werte annehmen. Der Typ eines Attributs wird durch eine Syntax festgelegt. Die Syntax bestimmt neben den möglichen Werten eines Attributs auch deren „Verhal- ten“ bei Operationen, wie z.B. ob Groß-/Kleinschreibung eines Strings bei der Suche nach einem bestimmten Wert berücksichtigt wird oder nicht (Syntax ces = case exact string bzw. cis = case ignore string). Typische Standardattribute mit der Syntax cis sind z.B.⁷:

- commonName, abgekürzt cn, für den gesamten Namen einer Person
- surname, abgekürzt sn, für den Nachnamen einer Person
- organization, abgekürzt o, für den Namen einer Organisation
- organizationalUnitName, abgekürzt ou, für den Namen einer Organisationseinheit
- CountryName, abgekürzt c, für den Namen eines Landes
- DomainComponent, abgekürzt dc, für den Teil eines Domänennamens

Neben solchen „normalen“ Attributen, gibt es auch Attribute, die für spezielle Zwe- cke verwendet werden, wie das modifyTimestamp Attribut, das die Zeit der letzten Ver- änderung des Eintrags wiedergibt und automatisch vom Server gesetzt wird. Um die Anzahl oder die Größe eines Attributs zu begrenzen, können entsprechende Einschrän- kungen festgelegt werden. Ferner kann die Belegung eines Attributs verbindlich oder freiwillig sein.

Objektklassen

Die Menge der verbindlichen und freiwilligen Attribute einer Objektart, deren Typ und Einschränkungen werden durch eine Objektklasse definiert. Wie z.B. aus der ob- jektorientierten Programmierung bekannt, gibt es auch hier Vererbung bzw. Subclassing, d.h. eine Objektklasse kann von einer anderen Objektklasse abgeleitet werden, wobei die Subklasse im Vergleich zur Superklasse zusätzliche (allerdings nicht weniger) Attribute enthalten kann⁸. Mehrfachvererbung ist nicht möglich.

Jeder Eintrag gehört zu mehreren Objektklassen, die in dem speziellen Attribut ob- jectClass hinterlegt sind. Dieses Attribut hat mindestens zwei Werte: einen, der die Art des Objekts für den der Eintrag steht (z.B. Person) eindeutig bestimmt und deshalb nicht geändert werden kann, die sogenannte strukturelle Objektklasse. Der zweite legt fest, ob es sich bei dem Eintrag um einen Alias-Eintrag (vgl. „Das Namensmodell“ im nächsten Abschnitt) handelt (Wert alias) oder nicht (Wert top), was man als abstrakte Objekt- klasse bezeichnet. Darüber hinaus kann man einem Eintrag über weitere sogenannte Hilfs -Objektklassen zusätzliche Attribute und Eigenschaften zuordnen. Ferner ist eine flexible Erweiterung einzelner Einträge möglich, indem man dem Eintrag die spezielle Objektklasse extensibleObject zuordnet, die bewirkt, dass beliebige Attribute im Eintrag gespeichert werden können.

Schemata und Standardisierung

Die Objektklassen, die ein LDAP-Server verarbeiten kann, ergeben sich aus einem Schema. Bei der Definition dieses Schemas, ist es dem Betreiber eines Directories wei- testgehend freigestellt eigene Objektklassen zu definieren. Diese Freiheit sollte jedoch mit Zurückhaltung wahrgenommen werden, denn sie behindert natürlich den Informati- onsaustausch zwischen mehreren Directories: bevor ein neuer oder veränderter Eintrag im Directory gespeichert wird, wird durch Überprüfung des Schemas sichergestellt, dass kein Eintrag die Festlegungen des Schemas missachtet. Dies stellt die Qualität der Daten im Directory sicher. Je mehr sich die Schemata der Directories gleichen, um so einfacher ist deshalb offensichtlich ihre Zusammenarbeit. Aus diesem Grund gibt es Vorschläge für standardisierte Schemata z.B. in den RFCs 2252 [WCHK97] und 2256 [Wahl97], die soweit wie möglich verwendet werden sollten. Wenn man z.B. Informati- onen zu Personen in einem LDAP-Directory speichern möchte, sollte man die entspre- chende Standard-Objektklasse person verwenden:

Abbildung in dieser Leseprobe nicht enthalten

2.2.2 Das Namensmodell

Das LDAP Namensmodell beschreibt, wie die Einträge des Directories logisch angeordnet werden können und wie man auf die einzelnen Einträge zugreifen kann. Dazu wird eine Baumstruktur verwendet, die individuell angepasst und sogar auf mehrere Server verteilt werden kann.

Der Directory Information Tree

Einträge werden in einem Directory in einer baumartigen Struktur organisiert, dem sogenannten Directory Information Tree (DIT), vgl. Abbildung 2.2-1. Jeder Eintrag hat

eine eindeutige Bezeichnung, einen Distinguished Name (DN), der sich aus der Position des Eintrags im DIT ergibt. Der Distinguished Name besteht aus einer Folge von Rela- tive Distinguished Names (RDNs), die jeweils einer Verzweigung im DIT entsprechen, wobei die RDNs aus einem Attribut-Namen, dem Gleichheitszeichen und dem Wert des Attributs gebildet werden⁹. Bei der Bildung des DN werden die RDNs durch Kommata getrennt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2-1: Vereinfachtes theoretisches Beispiel für einen DIT

Die Ähnlichkeit eines typischen DIT mit einem Dateisystem, wie man es von UNIX oder Windows her kennt, fällt sofort auf. Dabei entspricht ein RDN dem Namen einer Datei oder eines Verzeichnisses und ein DN einem absoluten Pfad. Über den DN kann gezielt auf jeden Eintrag zugegriffen werden. Im Gegensatz zu einem Dateisystem kön- nen jedoch in einem DIT nicht nur die Blätter Daten enthalten, sondern alle Baumkno- ten respektive Einträge. Ein Eintrag entspricht also einem Verzeichnis und/oder einer

Datei. Ferner werden beim DIT die RDNs in Richtung zur Wurzel hin zum DN zusam- mengesetzt, d.h. das Ende eines DN wird immer aus einem Eintrag der obersten Ebene unter der Wurzel gebildet, die man deshalb suffix nennt (vgl. Abbildung 2.2-1). Dage- gen geht der absolute Pfad in einem Dateisystem immer von root aus. Schließlich gibt es im DIT keine echte Entsprechung zum root-Verzeichnis eines Dateisystems. Es gibt zwar einen speziellen Eintrag in der Wurzel des Baums, den sogenannten root DSE, (Directory Server Specific Entry) der aber keine Benutzerdaten aufnehmen kann. Viel- mehr werden hier Informationen über das Schema des Servers, die unterstützte(n) LDAP-Version(en), die suffixes etc. gespeichert, die von einem Client abgefragt werden können¹⁰.

Strukturierung des DIT

Die Strukturierung des DIT bleibt dem Betreiber des Directories freigestellt. Sie ori- entiert sich in der Regel an der geographischen Lage und an organisatorischen Vorga- ben einer Institution wie z.B. Abteilungen¹¹. Je nach spezifischen Gegebenheiten kann der Baum entarten, so dass ganz flache Namensräume denkbar sind. Darüber hinaus kann man mit einem sogenannten Alias von einem Eintrag auf einen beliebigen anderen Eintrag im DIT verweisen und dadurch sogar zyklusartige Strukturen schaffen (vgl. erneut Abbildung 2.2-1). Der Sinn eines Alias ist es, ein Objekt in verschiedene logi- sche Gruppierungen einordnen zu können, ohne Datenredundanz zu erzeugen (Beispiel: eine Person gehört zu mehreren Personengruppen, soll aber nur einmal tatsächlich ge- speichert werden). Ein Alias ist letztlich nur ein Eintrag mit der Objektklasse alias und einem Attribut aliasedObjectName, das als Wert den DN des referenzierten Eintrags enthält¹².

Verteilte Directories

Wenn der DIT nicht von einem einzigen sondern von mehreren Servern zur Verfü- gung gestellt wird, was z.B. aus Gründen der Performanz, der Verfügbarkeit oder der geteilten Verantwortlichkeit für die Daten der Fall sein kann, dann nennt man dies ein verteiltes Directory. In obigem (theoretischen) Beispiel erkennt man ohne weiteres, dass nicht ein einziger Server die Informationen mehrerer Institutionen über Ländergrenzen hinweg aufnehmen sollte. Es ist jedoch aus den genannten Gründen sogar durchaus üb- lich, mehrere Server innerhalb einer Institution einzusetzen. Zur Realisierung macht man gedanklich einen „Schnitt“ durch den DIT und nennt dies Partitionierung. Man verwendet den Eintrag unterhalb des Schnitts als suffix für den zweiten Server, der den darunter liegenden Teilbaum aufnimmt.

Wenn man das obige Beispiel weiterführt, ist es einleuchtend, dass die FernUniversität einen eigenen (Haupt-)Server für ihren Teilbaum des DIT hat. Ferner könnte man sich z.B. vorstellen, dass die Informationen über die Personen der FernUniversität von einem gesonderten Server zur Verfügung gestellt werden. Die sich ergebende Partitionierung ist in Abbildung 2.2-2 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2-2: Partitionierung eines DIT

Um auch hier auf den gesamten DIT zugreifen zu können, ist eine gegenseitige logi- sche Verbindung zwischen den Servern erforderlich. Dazu wird in dem Eintrag oberhalb des Schnitts auf dem ersten Server ein Verweis auf den zweiten Server eingerichtet, indem man die Objektklasse referral hinzufügt, sowie ein Attribut ref, das als Wert den LDAP-URL¹³ des zweiten Servers hat. Der Verweis (Referral) wirkt wie ein Zeiger auf den zweiten Server, sobald auf einen Eintrag unterhalb des Schnitts zugegriffen wird. Auf dem zweiten Server wird ein Verweis auf den ersten, logisch gesehen übergeordne- ten Server, durch einen Eintrag in seiner Konfigurationsdatei realisiert. Dadurch kann der untergeordnete Server an den übergeordneten Server verweisen, wenn sich der ge- suchte Eintrag oberhalb seines Namenraums befindet (Beispiel: wird versucht auf dem LDAP-Server 2 auf einen Eintrag zuzugreifen, dessen DN zwar „o=FernUni Hagen, c=DE“ enthält, nicht aber „ou=Personen“, dann kann dieser Eintrag nur über den LDAP-Server 1 zu finden sein).

Die Aufl ö sung der Verweise beim Zugriff durch einen Client wird entweder durch sogenanntes Chaining oder durch die Rückgabe des Verweises an den Client erreicht. Beim Chaining sammelt der vom Client angesprochene Server die bei Ihm nicht vor- handenen Einträge bei den mit ihm verbundenen Servern und liefert dem Client das fertige Ergebnis. Dies entlastet den Client. Bei der zweiten Variante liefert der Server nur einen Verweis auf einen anderen Server, der den Eintrag enthalten könnte, so dass der Client eine erneute Anfrage stellen muss. Dies entlastet den Server. Im Gegensatz zum X.500-Standard, der standardmäßig Chaining vorsieht (aber auch Referrals zuläßt), unterstützen LDAP-Server der Version 3 meistens nur Referrals [HSG99, Kapitel 9], obwohl die Unterstützung von Chaining im Protokoll nicht ausdrücklich ausgeschlossen ist¹⁴.

Das Erstellen neuer Einträge, das Löschen von Einträgen und andere Zugriffe wie z.B. das Verschieben von Einträgen innerhalb des DIT werden im folgenden Abschnitt untersucht.

2.2.3 Das Funktionsmodell

Die Syntax und Semantik der Operationen, mittels derer man via LDAP auf die Ein- träge im Directory zugreifen kann, werden durch das Funktionsmodell festgelegt. Die Operationen wurden in RFC 2251 [WHK97] spezifiziert und lassen sich in vier Katego- rien gruppieren:

- Operationen zur Auswertung
- Operationen zur Datenänderung
- Operationen zur Authentifizierung und Kontrolle
- Erweiterungen

Im Nachfolgenden werden die Operationen dieser Kategorien etwas näher beleuch- tet.

Operationen zur Auswertung

Zu dieser Kategorie gehören die Operationen Search und Compare, mit denen man Einträge suchen und Attributwerte kontrollieren kann.

Search

Search ist die am häufigsten verwendete LDAP-Operation. Mit ihr können Einträge im Directory gefunden und gelesen werden, die bestimmte Kriterien erfüllen. Folgende Parameter stehen zur Verfügung:

Abbildung in dieser Leseprobe nicht enthalten

Da diese Beschreibung recht kompliziert aussieht, sei an dieser Stelle nochmals erwähnt, dass der normale Endanwender - sofern er überhaupt direkt und wissentlich auf einen LDAP-Server zugreift - dazu nicht die obige Syntax kennen muss. Vielmehr verwendet er eine grafische Benutzeroberfläche wie die in 1.3 „Directory Services“ kennengelernte, die den größten Teil der Komplexität absorbiert.

Compare

Compare wird verwendet, um zu überprüfen, ob ein bestimmter Eintrag einen be- stimmten Wert für ein bestimmtes Attribut enthält. Dazu wird der DN des Eintrags, der Name des Attributs und der zu testende Wert übergeben. Der Server gibt einen entspre- chenden boolschen Wert zurück. Derselbe Effekt könnte zwar auch mit einer Search- Operation erreicht werden (mit scope = baseObject und einem Filter Attribut=Wert wird der Eintrag bei Übereinstimmung zurückgegeben). Compare unterscheidet im Gegen- satz zu Search allerdings, ob das angegebene Attribut einen anderen Wert hat oder evtl. gar nicht im Eintrag vorhanden ist.

Operationen zur Daten ä nderung

Hierzu zählen Add, Delete, Modify und Modify DN, mit denen man Einträge hinzufügen, löschen, verändern und umbenennen bzw. verschieben kann.

Add

Mit Add kann man dem Directory einen Eintrag hinzufügen. Dazu gibt man den DN des Eintrags und eine Menge von Attributen und zugehörigen Werten an, aus denen der Eintrag erstellt werden soll. Sofern der Client zum Einfügen berechtigt ist, der DN in die bestehende Struktur des DIT passt (d.h. der Vater des Eintrags muss existieren und der DN darf nicht bereits belegt sein) und der neue Eintrag nicht gegen die Festlegun- gen des Schemas verstößt, wird der neue Eintrag angelegt und der Client erhält eine Erfolgsmeldung.

Delete

Mit Delete kann man einzelne Einträge (d.h. der Eintrag darf keine Kinder haben¹⁵ ) löschen, sofern man dazu berechtigt ist. Dazu gibt man einfach den DN des Eintrags an.

Modify DN

Mit dieser Operation kann man Einträge umbenennen und/oder innerhalb des DIT verschieben. Umbenennung und Verschiebung eines Eintrages sind im LDAP deshalb verwandte Operationen, weil der DN eines Eintrags mit seiner Position im DIT korres- pondiert (vgl. 2.2.2 „Das Namensmodell“). Voraussetzung für die Ausführung der Ope- ration ist, neben der erforderlichen Berechtigung des Benutzers, dass der neue DN nicht bereits verwendet wird. Das Verschieben auf einen anderen Server ist unzulässig. Die Operation hat vier Parameter:

Abbildung in dieser Leseprobe nicht enthalten

Das nachfolgende Beispiel zeigt die gleichzeitige Umbenennung und Verschiebung eines Eintrags. Dabei verändert sich der DN des Eintrags von

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2-3: Gleichzeitige Umbenennung und Verschiebung eines Eintrags

Durch Modify DN wird nicht nur der angegebene Eintrag verschoben, sondern der gesamte Teilbaum, dessen Wurzel er darstellt¹⁶.

Modify

Modify erlaubt die Änderung von Attributen bestehender Einträge. Dazu werden nur der DN des Eintrags und die Menge der Änderungen angegeben. Voraussetzung dafür ist natürlich, dass alle Änderungen die Restriktionen des Schemas beachten. Verstößt eine Änderung gegen das Schema, wird keine Änderung durchgeführt. Die Modify- Operation wird insoweit also als atomare Einheit angesehen. Es gibt drei Typen mögli- cher Änderungen:

add: Fügt dem Eintrag Attribute und/oder Attribut-Werte hinzu.

delete: Löscht Attribute und/oder Attribut-Werte des Eintrags.

replace: Ersetzt die existierenden Werte eines Attributs durch die als Parameter mitgegebenen.

Operationen zur Authentifizierung und Kontrolle

Zu dieser Kategorie von LDAP-Operationen zählen Bind, Unbind und Abandon, die das Auf- und Abbauen einer Verbindung zum LDAP-Server sowie das Abbrechen einer laufenden Operation ermöglichen.

Bind

Diese Operation dient hauptsächlich dazu, eine Verbindung zwischen Client und Server aufzubauen. Der Client hat dabei mehrere Möglichkeiten, sich zu authentifizie- ren:

- Er kann sich anonym anmelden, was i.d.R. zur Folge hat, dass er nur lesenden Zu- griff auf allgemein zugängliche Informationen erhält.
- Er kann sich unverschl ü sselt anmelden, indem er einen DN und ein Kennwort an- gibt, das daraufhin im Klartext zum Server übertragen wird. Dort wird es mit dem Wert des Attributs userpassword im zugehörigen Eintrag verglichen.
- Um das potentielle Abfangen seines im Klartext übertragenen Kennworts zu verhin- dern, kann der Client seit LDAPv3 ein sogenanntes SASL Bind verwenden, um Mechanismen zur sicheren Authentifizierung und Kommunikation mit dem Server, wie z.B. SSL oder TLS, zu vereinbaren.

Bis zum nächsten Bind oder Unbind (siehe unten) ist die Verbindung zwischen Cli- ent und Server nun an die Identität des bei der Authentifizierung verwendeten DN „ge- bunden“. Dadurch können dem Client Rechte zugestanden werden, die zu dem entsprechenden Eintrag gehören. Insofern können mehrere Binds während einer Ver- bindung durchaus sinnvoll sein, wenn man zur Ausführung von Operationen zusätzliche Zugriffsrechte erhalten (oder abgeben) möchte und sich dazu mit einer anderen Identität beim Server meldet.

Neben Identifikation und Authentifizierung wird beim Bind auch die unterstützte Version übertragen, wodurch Server und Client erkennen, ob ihr gegenüber „dieselbe Sprache spricht“. Die Kommunikation zwischen einem LDAPv2 Client und einem LDAPv3 Server ist dabei relativ unkritisch, weil letzterer abwärtskompatibel sein muss. Umgekehrt wird aber ein LDAPv3 Client die Kommunikation mit einem LDAPv2 Server abbrechen, wenn für ihn wichtige Features nicht verfügbar sind.

Unbind

Durch Aufruf dieser Operation wird die Verbindung zwischen Client und Server ab- gebaut. Alle noch ausstehenden Operationen, die zu dieser Verbindung gehören, werden abgebrochen.

Abandon

Abandon wird verwendet, um eine zuvor gestartete Operation vorzeitig abzubrechen, insbesondere weil sie dem Client zu lange dauert. Die abzubrechende Operation wird durch die Nachrichten-ID der Operation bezeichnet (vgl. 2.1 „Kommunikation zwischen Client und Server“).

Erweiterungen

Über die bisher beschriebenen Operationen hinaus, gibt es in LDAPv3 die Möglich- keit neue sogenannte erweiterte LDAP Operationen zu definieren und das Verhalten vorhandener Operationen mit sogenannten Controls zu beeinflussen, ohne das eigentli- che Protokoll zu verändern. Ein Beispiel für eine erweiterte LDAP Operation ist das Kommando StartTLS, das den Server dazu veranlasst die weitere Kommunikation mit- tels TLS zu verschlüsseln. Ein Beispiel für ein Control ist das „Tree Delete Control“ [Armi99] im Windows 2000 Active Directory, das es erlaubt ganze Teilbäume von Ein- trägen mit einer Operation zu löschen. Die von einem Server unterstützten erweiterten Operationen und Controls werden in seinem root DSE bekanntgegeben (vgl. 2.2.2 „Das Namensmodell“).

2.2.4 Das Sicherheitsmodell

Das Sicherheitsmodell von LDAP dient dem Zweck, die im Directory gespeicherten Informationen vor unberechtigten Zugriffen zu schützen. Dazu werden insbesondere die Authentifizierung der Clients und eine Zugriffskontrolle verwendet.

Authentifizierung

Die Authentifizierung der Clients erfolgt mittels der im vorigen Abschnitt beschrie- benen Operation Bind. Neben den dort beschriebenen Methoden, unterstützt LDAPv3 auch ein Bind mit der Simple Authentication and Security Layer (SASL) [Myers97]. Dabei handelt es sich um ein erweiterbares, protokollunabhängiges System, das es er- möglicht eine Authentifizierungsmethode sowie eine Sicherheitsschicht zur Verschlüs- selung der Kommunikation zwischen Client und Server auszuhandeln und die Authentifizierung abzuwickeln. Es arbeitet mit verbindungsorientierten Anwendungs- protokollen wie IMAP4, POP3, SMTP (vgl. 1.5 „Weitere Begriffe und Grundlagen“) oder LDAP zusammen. Der Vorteil des SASL Bind liegt darin, dass Clients nicht mehr auf einzelne Protokolle zur Authentifizierung festgelegt werden. Ferner können neue Methoden zur Authentifizierung eingebunden werden, ohne LDAP selbst zu ändern.

Welche Mechanismen über SASL auf einem LDAP-Server verfügbar sind, macht dieser über seinen root DSE bekannt. Verwendet werden insbesondere SSL bzw. TLS, die die gesamte Kommunikation zwischen Client und Server verschlüsseln, im übrigen jedoch die Funktionalität von LDAP nicht verändern (vgl. 1.5 „Weitere Begriffe und Grundlagen“). Lediglich der verwendete TCP-Port ändert sich von 389 in 636 und LDAP-URLs beginnen mit „ldaps://“ statt mit „ldap://“. In Betracht kommen ferner z.Zt. Kerberos, S/Key, GSSAPI, CRAM-MD5, GSS-SPNEGO sowie OTP, vgl. [ISI99].

Zugriffskontrolle

Um den Schutz der Daten im Directory sicher zu stellen, muss gewährleistet werden, dass ein Client nur im Rahmen seiner Berechtigungen auf Daten im Directory zugreifen kann. Die übliche Vorgehensweise bei der Realisierung einer solchen Zugriffskontrolle ist, für die Objekte (Einträge oder sogar Attribute) festzulegen, wer (Distinguished Name einer Person oder Gruppe) in welcher Weise (lesen, schreiben, löschen etc.) auf sie zugreifen darf. Solche Festlegungen werden Access Control List (ACL) genannt und bei dem entsprechenden Objekt gespeichert.

Bedauerlicherweise ist die Zugriffskontrolle jedoch (noch) kein Bestandteil der LDAP-Spezifikationen, sodass ihre Implementierung im Bezug auf Syntax und Seman- tik herstellerabh ä ngig ist. Wie wir noch sehen werden, führt dies zu verschiedenen Problemen. Insbesondere wird die Replikation und Verteilung von Daten zwischen LDAP-Servern verschiedener Hersteller und die Entwicklung von sicherheitsrelevanten Anwendungen, die mit unterschiedlichen LDAP-Produkten kommunizieren sollen, hierdurch erheblich erschwert oder sogar unmöglich. Ferner ist ein Umstieg von einem Serverprodukt auf ein anderes meist sehr aufwendig, da die direkte Übernahme der Da- ten inklusive aller Berechtigungen in der Regel nicht möglich ist. Um diese Probleme in der Zukunft zu vermeiden, gibt es Bemühungen die Zugriffskontrolle für LDAP zu standardisieren. Diese sind allerdings noch nicht über das Stadium des Internet Drafts hinausgekommen [SB99a], [SB99b].

3 Directory vs. Datenbank

Directories werden oft als spezielle Datenbanken bezeichnet. Dies spiegelt sich auch in den vielen Gemeinsamkeiten wider, auf die teilweise bei der Darstellung der Funktionsweise von LDAP bereits hingewiesen wurde. Diese Tatsache erleichtert einerseits den Zugang zu Directories, da etwaige Vorkenntnisse aus der Welt der Datenbanken eingebracht werden können. Andererseits gibt es jedoch einige gravierende Unterschiede, die beachtet werden müssen, wenn man Directory Services sinnvoll nutzen möchte. Hierbei gilt es insbesondere die Frage zu beantworten, wann es sinnvoll ist, Daten in einem Directory abzulegen statt in einer Datenbank bzw. umgekehrt und welche Auswirkungen sich bei der Benutzung der Daten daraus ergeben.

Dieses Kapitel soll ebensowenig der eingehenden Darstellung der Funktionsweise von Datenbankmanagementsystemen (DBMS) dienen, wie dem Vergleich relationaler und objektorientierter Datenbanksysteme (OODBS). Dies ist nicht Gegenstand dieser Diplomarbeit und würde ihren Rahmen bei weitem sprengen¹⁷. Es sollen vielmehr diejenigen Aspekte (verteilter) Datenbanken betrachtet werden, die für den Vergleich mit Directories relevant sind. Themen dieses Vergleichs werden sein:

- das Verhältnis von Lese- bzw. Such- zu Schreibzugriffen,
- die Komplexität von Operationen und Datenbeziehungen,
- die Möglichkeiten zur Realisierung von Kapselung,
- die Standardisierung der Datenrepräsentation und der Schnittstellen,
- die Verteilung von Datenbeständen auf mehrere Server,
- die Eigenschaften redundanter Allokation von Daten,
- der Zugriff von Internet-Anwendungen auf die Daten,
- die Möglichkeiten zur Modellierung von Objekten der Realwelt sowie
- die Flexibilität des Schemas.

3.1 Verhältnis von Lese- bzw. Such- zu Schreibzugriffen

Das in der Literatur am häufigsten genannte Kriterium zur Abgrenzung eines Direc- tory Service von einem DBMS, ist das Verhältnis von Lese- bzw. Such- zu Schreibzu- griffen von Clients (vgl. z.B. [HSG99, S.13], [JBH98, S. 2], [Netsc97, S. 2] oder [LüKi99, S. 156]).

Zugriffsverh ä ltnis in Directories

Die Daten in einem Directory werden typischerweise wesentlich öfter gelesen bzw. durchsucht als verändert. Ein Verhältnis von 10.000 : 1 zwischen Lese- bzw. Such- und Schreibzugriffen ist dabei in großen Directories mit z.B. 100 Mio. Einträgen¹⁸ durchaus üblich [Netsc97]. Aus diesem Grund ist ein Directory Service speziell f ü r Lesezugriffe

optimiert. Dadurch werden Such-Operationen auch in sehr großen Datenbeständen ver- hältnismäßig schnell ausgeführt. Andererseits kann natürlich keine entsprechende Op- timierung von Schreibzugriffen realisiert werden, weshalb diese relativ langsam sind.

Zugriffsverh ä ltnis in Datenbanken

Eine Datenbank kann selbstverständlich auch mit vergleichbarem Lese- / Schreib- verhältnis eingesetzt werden. Es gibt allerdings kein typisches Verhältnis, da Datenban- ken für sehr verschiedene Arten von Anwendungen verwendet werden. Darunter sind auch Anwendungen, die praktisch ausschließlich schreiben und nur gelegentlich lesen, wie etwa die Aufzeichnung statistischer Daten, die z.B. nur einmal pro Quartal ausge- wertet werden. Deshalb erfolgt die Optimierung in DBMS f ü r Lese- und Schreibopera- tionen gleicherma ß en, wobei ein Kompromiss zwischen Lese- und Schreibleistung gefunden werden muss.

Ergebnis

Demnach eignet sich ein Directory Service eher für die Zusammenarbeit mit Anwen- dungen, die auf statischen Daten arbeiten. Das sind Daten, die sich (im Verhältnis zur Anzahl lesender Zugriffe) nur selten ändern. Ein klassisches Beispiel für statische Daten sind Mail-Adressen in einem Adressenverzeichnis: eine Mail-Adresse wird gewöhnlich viele tausendmal gelesen (von anderen Benutzern, die der Person eine Mail schicken wollen), bevor sie sich einmal ändert, was in der Regel nur in einem Abstand von Jah- ren vorkommt.

Dagegen ist ein Directory Service nicht geeignet für Anwendungen, die häufig schreiben (dynamische Daten) sowie für Anwendungen, die große Datenmengen schrei- ben oder auf schnelles Schreiben angewiesen sind. Dazu sollte man ein Datenbanksys- tem verwenden.

3.2 Komplexität

DBMS und Directory Services unterscheiden sich durch das Maß an Komplexität, das in beiden Systemen im Hinblick auf Operationen und Datenbeziehungen vorkommt. Bei den Operationen gilt dies sowohl für die Operationen, durch die Clients auf Daten zugreifen, als auch für die auf dem Server implementierbare Anwendungslogik und die Unterstützung von Transaktionen. Diese Unterschiede werden hier aufgezeigt. Darüber hinaus werden die sich aus den Unterschieden ergebenden Schlussfolgerungen für den Einsatz beider Systeme gezogen.

3.2.1 Operationen

Sowohl DBMS als auch Directory Services bieten ihren Clients Operationen, über die auf die abgelegten Daten zugegriffen werden kann. Für LDAP Directory Services wurden diese bereits unter 2.2.3 „Das Funktionsmodell“ beschrieben.

DBMS Operationen

Der Zugriff eines Clients auf relationale Datenbanken erfolgt über eine SQL - Schnittstelle (Structured Query Language) des DBMS. Das objektorientierte Pendant heißt OQL. Diese Schnittstellen sind ausgesprochen mächtig und erlauben sehr umfang- reiche und komplexe Operationen, die im Prinzip beliebig tief verschachtelt sein kön- nen. Der Preis für diese Leistungsfähigkeit ist eine entsprechend komplexe Implementierung und Anfrageoptimierung auf dem Client- und dem Serversystem. Dies gilt umso mehr für verteilte Datenbanken, also Datenbanken, deren Daten auf mehrere Server verteilt sind (z.B. für die Anfrageoptimierung, vgl. [Dadam96, Kapitel 6]).

LDAP Operationen

Der Zugriff auf ein Directory erfolgt hingegen mittels LDAP. Wie wir in Kapitel 2.2.3 „Das Funktionsmodell“ gesehen haben, verfügt LDAP nur über wenige einfache Operationen. Außer Search und Modify DN beziehen sich alle Operationen immer nur auf einen Eintrag. Damit ist es z.B. im Gegensatz zu SQL nicht möglich mit einer Ope- ration „in allen Einträgen mit der Eigenschaft x die Änderung y durchzuführen“. Dafür ist der Einsatz von LDAP aber auch entsprechend einfach zu handhaben, was insbeson- dere beim Zugriff auf die Daten einzelner Objekte der Realwelt effektiv ist.

Dies spiegelt sich auch in der Leistungsfähigkeit der Systeme wieder: während typische große Datenbanken hunderte von Aktionssequenzen („Transaktionen“) pro Sekunde bewältigen, kann ein typischer großer Directory Service insgesamt tausende oder sogar zehntausende Anfragen pro Sekunde verarbeiten [HSG99, S. 19] [Netsc97], die dafür natürlich wesentlich weniger komplex und umfangreich sind.

Ergebnis

Ein Directory Service sollte eher dann eingesetzt werden, wenn es darum geht An- wendungen zu bedienen, die viele einfache und schnelle Datenzugriffe benötigen. Komplexe Informationssysteme mit hohen Ansprüchen an Auswertungsmöglichkeiten überfordern hingegen das Funktionsmodell von LDAP und sollten Datenbanken vorbe- halten bleiben.

3.2.2 Anwendungslogik auf dem Server

Anwendungslogik auf dem Server wird zum einen verwendet, um Daten vor unkon- trollierten Änderungen zu schützen, die erforderliche Integritätsbedingungen der Daten verletzen würden. Dieser Aspekt wird im Laufe dieses Kapitels noch ausführlicher be- trachtet werden. Zum anderen dient sie auch der Reduzierung von Zugriffen der Clients. Dazu werden in Prozeduren und Funktionen, die auf dem Server gespeichert sind, viele einzelne Operationen zusammengefasst. Es erfolgt lediglich ein Aufruf durch den Client für die gesamte Sequenz, anstatt eines Aufrufs für jede einzelne Operation. Zurückge- geben wird ebenfalls lediglich ein Returncode bzw. ein Ergebnis(-objekt) anstatt vieler Zwischenergebnisse. Dadurch wird das Netzwerk weniger belastet und der Client wird von Komplexität befreit.

Anwendungslogik auf dem Datenbank Server

DBMS bieten vielfältige Möglichkeiten Anwendungslogik auf dem Server zu im- plementieren. Hierzu zählen Methoden bzw. Stored Procedures und Stored Functions. Dabei handelt es sich um Prozeduren und Funktionen, die vom Client aufgerufen und dann vom DBMS ausgeführt werden. Ferner gibt es sogenannte Trigger, die im Gegen- satz dazu implizit durch ein bestimmtes Ereignis, wie z.B. die Änderung eines bestimm- ten Objekts, aktiviert werden.

Nachteilig bei der Verwendung von Stored Procedures, Stored Functions und Trig- gern ist, dass sie proprietär sind. Dies liegt daran, dass es praktisch von jedem DBMS- Hersteller einen eigenen „SQL-Dialekt“ gibt. Zwar wurde dies bereits frühzeitig als problematisch erkannt, sodass 1992 durch die ANSI (American National Standards In- stitute) ein SQL-Standard verabschiedet wurde. Allerdings waren die genannten Kon- strukte nicht Teil dieses Standards [Dick97] und sind erst für den noch nicht verfügbaren Nachfolgestandard SQL3 vorgesehen [NCITS99], [JCC99]. Damit bindet

man sich durch die Verwendung von Stored Procedures, Stored Functions und Triggern zur Zeit noch an ein bestimmtes Produkt.

Anwendungslogik auf dem Directory Server

Ein Directory Service verfügt - als in etwa mit Stored Procedures und Stored Func- tions vergleichbares Konstrukt - über erweiterte LDAP-Operationen. Ferner bieten ei- nige Implementierungen Konstrukte an, die mit Triggern vergleichbar sind. So gibt es z.B. für den Netscape Directory Server die Möglichkeit, mit sogenannten Plug-Ins eige- ne Server-Funktionen zu schreiben [Netsc98]. Plug-Ins können verwendet werden, um Daten vor oder nach einer LDAP Operation zu untersuchen und ggf. zu verändern, er- weiterte LDAP Operationen auszuführen, den Directory Server an bestimmte Daten- banken anzubinden u.v.m.

Allerdings werden durch erweiterte LDAP Operationen und Konstrukte wie die Netscape Plug-Ins natürlich nicht das LDAP erweitert. Zwar ist immerhin die Handhabung von erweiterten Operationen in LDAPv3 spezifiziert [WHK97, S. 38], was (noch) ein Vorteil gegenüber SQL darstellt. Die Operationen als solche und erst recht die PlugIns sind jedoch - genau wie Stored Procedures, Stored Functions und Trigger - proprietär. Daher geht bei Nutzung dieser Möglichkeiten der Vorteil der Standardisierung des Protokolls verloren. Darüber hinaus werden erweiterte Operationen und Plug-Ins nicht an bestimmte (Gruppen von) Einträge(n) gebunden, was ihre Verwendung für die eingangs beschriebenen Zwecke unübersichtlich macht.

Ergebnis

Die extensive Nutzung von Anwendungslogik auf dem Server ist trotz der damit ver- bundenen Herstellerabhängigkeit ein typisches Merkmal von Datenbank-Anwendungen. Sofern jedoch eine Anwendung unbedingt Prozeduren oder Funktionen auf dem Server benötigt, andererseits vom Typ her eher für einen Directory Service geeignet ist, kann dies durchaus realisiert werden. Aber auch hier handelt es sich dann um eine proprietäre Lösung, welche die Produktwahl für den Directory Service beeinflusst, da nur wenige Produkte wirklich leistungsfähige Konstrukte wie die Netscape Directory Server Plug- Ins zur Verfügung stellen¹⁹.

3.2.3 Unterstützung von Transaktionen

Transaktionen sind Sequenzen von Aktionen, die als Einheit behandelt werden, d. h. es werden entweder alle Aktionen erfolgreich ausgeführt oder keine, wobei im zweiten Fall alle zum Zeitpunkt des Abbruchs der Transaktion bereits durchgeführten Aktionen wieder rückgängig gemacht werden. Während einer Transaktion sind keine Zwischen- zustände nach außen hin sichtbar. Transaktionen werden eingesetzt, um zu verhindern, dass nach einem Abbruch der Sequenz oder bei einem plötzlichen Systemausfall inkon- sistente Daten verarbeitet werden bzw. während der Abarbeitung der Sequenz von Ak- tionen inkonsistente Zwischenergebnisse sichtbar sind und weiterverarbeitet werden können. Das klassische Beispiel für die Verwendung von Transaktionen ist die Über- weisung von einem Bankkonto auf ein anderes. Die Transaktion besteht in diesem Falle aus der Belastung des ersten Kontos und der Gutschrift des Betrags auf dem zweiten Konto. Wird nun z.B. die Transaktion abgebrochen, nachdem das erste Konto belastet wurde, aber bevor die Gutschrift beim zweiten Konto erfolgreich abgeschlossen wurde, muss der Betrag wieder auf das erste Konto gutgeschrieben werden, bevor andere Ope- rationen die beiden Konten wieder sehen, da das Geld ansonsten „verschwindet“, d.h. eine Inkonsistenz auftritt²⁰.

Transaktionen im DBMS

DBMS unterst ü tzen komplexe Transaktionen, die sich unter Umständen auf viele verschiedene Datenelemente und Operationen beziehen können. Verteilte DBMS unter- stützen sogar Transaktionen, die Objekte auf verschiedenen Servern ändern (ohne dass der Anwender dies wissen muss). Dazu wird das sogenannte Two-Phase-Commit- Protocol (2PC-Protocol) verwendet [Dadam96, Kapitel 7]. Darüber hinaus werden teil- weise noch weiterführende Transaktionskonzepte wie z.B. geschachtelte Transaktionen unterstützt, welche es erlauben aus einer Transaktion heraus andere Transaktionen an- zustoßen oder lange Transaktionen, die im wissenschaftlich/technischen Bereich einge- setzt werden, um Arbeitseinheiten nachzubilden, die von einigen Stunden bis zu mehreren Monaten dauern können [Dadam96, Kapitel11]. Je komplexer die Transakti- onskonzepte und die damit zusammenhängenden Konzepte wie z.B. Synchronisations- verfahren werden, desto schwieriger ist allerdings auch die Implementierung eines effizienten (verteilten) DBMS.

Transaktionen im Directory Service

Directory Services unterst ü tzen i.d.R. keine Transaktionen in der beschriebenen Weise²¹. Größte atomare Einheiten sind ein Eintrag und eine Operation. Bei einer ModifyOperation werden z. B. entweder alle Änderungen in dem bearbeiteten Eintrag durchgeführt oder - wenn dies aufgrund eines Schema-Konflikts oder wegen Abbruchs der Operation durch den Benutzer nicht möglich ist - keine, vgl. 2.2.3 „Das Funktionsmodell“. Mehrere Operationen werden jedoch unabhängig voneinander betrachtet. Bei Änderung mehrerer Einträge besteht daher die Gefahr, dass ein Client währenddessen eine Suchanfrage stellt und einen inkonsistenten Zwischenzustand sieht, in dem einige Einträge bereits geändert sind, andere aber noch nicht.

Ergebnis

Folglich sollten Anwendungen, die zwingend auf Transaktionen angewiesen sind, wie z.B. Kontoführungssysteme für Banken oder Reservierungssysteme für Fluglinien, ihre Daten in einer Datenbank ablegen. Anwendungen, die ihre Daten in einem Directo- ry ablegen, dürfen durch vorübergehende Inkonsistenzen dieser Daten nicht destabili- siert werden.

3.2.4 Beziehungen

Objekte der Realwelt stehen häufig in vielfältigen Beziehungen zueinander. Dabei handelt es sich um organisatorische, körperliche, rechtliche oder andere Beziehungen zwischen Personen und / oder Dingen, die mit unterschiedlich komplexen Eigenschaften und Bedingungen verbunden sein können. Bildet man die Objekte der Realwelt auf Datenobjekte ab, liegt es nahe auch die für eine Anwendung benötigten Beziehungen zwischen den Objekten abzubilden.

Beziehungen zwischen Datenbankobjekten

In Datenbanken haben Objekte i.d.R. komplexe Beziehungen untereinander, die für aufwendige Abfragen effizient eingesetzt werden können. Dabei können Beziehungen auch eigene Attribute haben. In relationalen Datenbanken kann durch Verwendung von Fremdschlüsseln referentielle Integrit ä t erreicht werden. Das bedeutet, dass in einem Tupel nur solche Werte für ein Attribut verwendet werden können, die als Primärschlüssel eines Tupels einer anderen Relation tatsächlich existieren.

Beziehungen zwischen Directory-Eintr ä gen

In einem Directory sind Objekte grunds ä tzlich unabh ä ngig voneinander. Beziehungen zwischen den entsprechenden Einträgen können zwar durch einen Alias, Referral oder ein Attribut wie seeAlso realisiert werden. Dabei handelt es sich jedoch um einfa che Zeiger, deren Werte DNs bzw. URLs sind, vgl. 2.2.2 „Das Namensmodell“. Sie werden allerdings eher selten benutzt, da sie nicht so effizient verwendbar sind wie Beziehungen in einer Datenbank [Kille98]. Das liegt daran, dass hierzu in LDAP keine entsprechenden Konstrukte (wie z.B. JOIN oder direkte Referenzierung innerhalb einer Suchanfrage) vorgesehen sind. Die Verwendung ist eher navigierender Art. Dementsprechend kann hierüber auch keine referentielle Integrit ä t realisiert werden, d. h. in einem Alias kann ein nicht existierender DN stehen²².

Ergebnis

Als Ergebnis kann man festhalten, dass Anwendungen, die komplex verbundene Daten benötigen, für die unter Umständen sogar referentielle Integrität erforderlich ist, nicht für Directories geeignet sind. Daten, für die aufwendige Analysen oder Berichte erstellt werden müssen, sollten in einer Datenbank gespeichert werden.

3.2.5 Zusammenfassung

Mit DBMS sind sowohl im Hinblick auf die zur Verfügung stehenden Operationen als auch auf die Beziehungen zwischen den Daten komplexere Lösungen realisierbar, als mit LDAP Directory Services. Diese Komplexität wirkt sich allerdings entsprechend auf den Aufwand für die Implementierung und die Administration der Systeme aus.

3.3 Kapselung

Insbesondere bei Objekten mit komplexen internen Strukturen und/oder Algorithmen möchte man deren Implementierung nicht nach außen sichtbar werden lassen, um zu verhindern, dass Anwendungen, die diese Objekte benutzen, bei einer Änderung der Objektimplementierung ebenfalls geändert werden müssen. Ein weiteres Anliegen be- steht darin, den Zugriff auf die Attribute des Objekts nur in bestimmter vorgegebener Weise zu ermöglichen, um Integritätsbedingungen einzuhalten. Man spricht in diesem Zusammenhang von Kapselung.

DBMS und Kapselung

Bei objektorientierten Datenbanksystemen ist der Zugriff auf den Zustand eines Ob- jekts nur über die dazu angebotenen Operationen - die sogenannten Methoden - mög- lich. Dadurch wird hervorragend von der internen Realisierung des Objekts abstrahiert. Im relationalen Modell kann man dem - wenn auch sicher nicht gleichwertig - Sichten und Stored Procedures gegenüberstellen. Sichten bieten bestimmten Benutzern eine vordefinierte Auswahl der Daten, auf denen sie dann arbeiten können und realisieren so eine beschränkte Abstraktion vom konzeptuellen Schema einer Datenbank. Die Ände- rung eines Attributs erfolgt jedoch normalerweise weiterhin durch unmittelbaren Zu- griff. Um nur noch einen kontrollierten Zugriff auf Attributwerte zuzulassen, kann man zur ausschließlichen Verwendung von Stored Procedures f ü r Datenzugriffe übergehen. Damit ist auch die implizite Änderung anderer Objekte zur Einhaltung von Integritäts- bedingungen möglich, ohne dass der Benutzer dies erkennt.

Directory Services und Kapselung

Beim Directory Service ist einer Sicht bestenfalls eine Search-Operation hinsichtlich der Filterung von Attributen vergleichbar. Allerdings kann eine Search-Operation im Gegensatz zu einer Sicht keine Basis für weitere Operationen sein. Es gibt Attribute (Bsp.: modifyTimestamp), die nur bei ausdrücklicher Anforderung durch für den Client sichtbar sind. Diese können durch den Client jedoch nicht kontrolliert geändert werden. Ein effektives Verbergen der Datenstruktur vor dem Benutzer, ist generell nur durch den Entzug der Berechtigung für einzelne Attribute realisierbar. Dann ist aber auch in- soweit kein kontrollierter Zugriff für den Benutzer mehr möglich. Die Änderung des Zustands eines Objekts erfolgt durch direkten Zugriff auf die Attribute ohne semantische Prüfung, lediglich mit einer Typprüfung. Implizite Änderungen an anderen Attributen und/oder Objekten sind nur sehr beschränkt mittels Controls, erweiterten LDAP Opera- tionen oder Plug-Ins möglich. Insoweit gilt hier das bereits unter 3.2.2 „Anwendungslogik auf dem Server“ Festgestellte.

Ergebnis

Insgesamt sind die M ö glichkeiten zur Kapselung bei Directory Services wesentlich schlechter, als bei DBMS. Daher sollten Objekte mit komplexer interner Struktur und Integritätsbedingungen, deren Implementationsdetails nicht sichtbar sein sollen, in einer Datenbank gespeichert werden. Einfache Objekte, die direkt abgefragt und ggf. geändert werden sollen, ohne dass dabei Integritätsbedingungen eine große Rolle spielen, lassen sich dagegen unkomplizierter in einem Directory ablegen. Gerade dies entspricht der Intension eines Directory Service, nämlich Informationen auf einfache und standardi- sierte Weise einer Vielzahl unterschiedlichster Anwendungen gemeinsam zur Verfü- gung zu stellen.

3.4 Standardisierung

In immer kürzeren Abständen kommen neue Produkte verschiedener Hersteller auf den Markt und machen die IT-Landschaft in allen Bereichen heterogener. Dies hat für den Einsatz von Datenbanken und Directories folgende Auswirkungen:

- Jede Anwendung die Daten ablegt, wird von der Art und Weise wie die Ablage und der anschließende Zugriff auf die Daten erfolgen geprägt. Unterscheiden sich Da- tenablage und -zugriff von Produkt zu Produkt, muss man beim Wechsel des Pro- dukts mit Umstellungsaufwand für die darauf basierenden Anwendungen rechnen.
- Derselbe Effekt tritt ein, wenn eine Anwendung in der Lage sein soll, ihre Daten in Datenbanken bzw. Directories verschiedener Hersteller abzulegen. Auch hier ist der Aufwand f ü r die Portierung der Anwendung abhängig von der Homogenität der Produkte.
- Sollen Datenbestände auf verschiedene Systeme verteilt werden, ist für eine erfolg- reiche Kooperation und Integration der Systeme entscheidend, dass die Schnittstellen, über die Daten ausgetauscht werden, kompatibel sind.
- Kompatible Schnittstellen sind ferner die Voraussetzung dafür, dass die redundante Speicherung von Daten und die damit verbundenen Probleme hinsichtlich Konsistenz und Wartungsaufwand, durch den Zugriff auf integrierte, zentrale Datenbestände vermieden werden kann.
- Um die Produktwahl f ü r Client- und Serversysteme voneinander unabh ä ngig treffen zu können, muss die Schnittstelle zwischen beiden herstellerunabhängig sein. Dies hat den Vorteil, dass für die Systeme auf beiden Seiten individuelle Entscheidungen entsprechend den jeweiligen Anforderungen möglich sind und ein Produktwechsel auf einer Seite keine Auswirkungen auf die Systeme der anderen Seite hat²³.

Um den Umstellungsaufwand zu minimieren und Produkte individuell nach ihrer Leistungsfähigkeit anstatt nach den Bindungen an einen bestimmten Hersteller auswählen zu können, ohne andererseits Informationsinseln zu schaffen, die untereinander nicht kooperieren, sollten allgemein anerkannte, m ö glichst offene Standards verwendet werden. Aufgrund ihrer zentralen Bedeutung für diese Ziele, ist dabei eine Standardisierung insbesondere f ü r das Datenmodell und das Schema der Systeme sowie die Schnitt stelle zur Kommunikation mit den Systemen wichtig.

3.4.1 Standardisierung von Datenmodell und Schema

Die Standardisierung von Datenmodell und Schema, dient der einheitlichen Repräsentation von Informationen in Produkten verschiedener Hersteller.

Standardisierung von Datenmodell und Schema bei Datenbanken

In Datenbanken kommen unterschiedliche Datenmodelle zum Einsatz, um die logi- sche Gesamtsicht der Datenbank zu erstellen. Gängige Datenmodelle sind das hierarchi- sche Datenmodell, das Netzwerk-Datenmodell und vor allem das relationale und das objektorientierte Datenmodell. Da sich diese Datenmodelle zum Teil stark voneinander unterscheiden, ist ein Wechsel zu einem DBMS mit unterschiedlichem Modell nur durch aufwendige Modell-Transformationen und oft nur unter Verlust von Funktionali- tät möglich, vgl. [Dadam96, Kapitel 5]. Die Gestaltung des Schemas der Datenbank, erfolgt ferner nach den individuellen Bedürfnissen des Einzelfalls. Da hierfür keine Standards existieren, werden semantisch gleichwertige Daten ggf. strukturell unter- schiedlich dargestellt. Bei einem Austausch von Daten zwischen verschiedenen Daten- banksystemen muss dann zunächst die Semantik geklärt und beim Zugriff ggf. eine Schema-Transformation zur Anpassung durchgeführt werden. Dies hat negativen Ein- fluss auf den Aufwand zur Implementierung und Pflege eines solchen Datenaustauschs.

[...]

---

¹ Vorläufer von LDAP als effizientem Directory-Protokoll waren der Directory Assistance Service (DAS), definiert in [Rose91] und das Directory Interface to X.500 Implemented Efficiently (DIXIE), definiert in [HSB91], die beide direkt über TCP/IP einen Gateway-Server ansprachen, der seinerseits die Kommunikation mit dem X.500-Server übernahm. Dieser Ansatz wurde zunächst auch für LDAP übernommen. 1995 folgte dann aber ein stand-alone LDAP-Server, der das Directory selbst in einer eigenen Datenbank speicherte und somit unabhängig von einem X.500-Server war.

² Beispielsweise wurde die Möglichkeit Operationen zu signieren gänzlich gestrichen, während die Operationen Read und List durch die Operation Search emuliert werden.

³ Bei der digitalen Unterschrift wird das Schlüsselpaar umgekehrt verwendet: der Absender erzeugt für sein Dokument eine Prüfsumme und verschlüsselt diese (zusammen mit weiteren Informationen) mit seinem privaten Schlüssel. Dadurch ist die Urheberschaft und die Integrität des Dokuments eindeutig, da nur er diesen Schlüssel besitzt. Der Empfänger kann die digitale Unterschrift dann mit dem öffentlichen Schlüssel des Absenders wieder entschlüsseln und die Prüfsumme kontrollieren.

⁴ Der genaue Aufbau eines SSL-Zertifikats ist im Standard X.509 [ITU93] geregelt. Die FernUniversität Hagen tritt selbst als CA auf und stellt Zertifikate für interessierte Benutzer aus [FUCA99a].

⁵ Neben der hier beschriebenen Kommunikation über TCP und der dabei benötigten Verbindung zwischen Client und Server, kann eine LDAP-Kommunikation auch über UDP erfolgen. Man spricht dann von connectionless LDAP (CLDAP). CLDAP [You95] wird eingesetzt, wenn der Verwaltungsaufwand für den Verbindungsaufbau und -abbau unverhältnismäßig ist, weil man geringe Mengen an Information sehr schnell transportieren muß [How95, Kapitel 5].

⁶ Software Development Kits (SDKs) sind für fast alle gängigen Programmiersprachen wie C, C++, Java, JavaScript, Perl oder Visual Basic erhältlich, vgl. z.B. [UMI96], [IBM98], [Netsc99a], [Moz99].

⁷ Attribute besitzen neben einem Namen aus Gründen der Kompatibilität zu X.500-Directories auch einen eindeutigen sogenannten Object Identifier (OID), der statt des Attributnamens verwendet werden kann. Ein OID setzt sich aus durch Punkte getrennte Integer-Zahlen zusammen, vgl. [WCHK97]. Da die Verwendung von Attributnamen allerdings offensichtlich benutzerfreundlicher ist, werden im Rahmen dieser Arbeit ausschließlich Namen verwendet.

⁸ Einige LDAP-Implementierungen unterstützen auch Attribut-Subtypen. Da dies allerdings überwiegend nicht der Fall ist, sollte man von deren Verwendung Abstand nehmen, vgl. [HSG99, S. 194].

⁹ Reicht ein Attribut nicht aus, um einen RDN eindeutig zu bestimmen, weil z.B. mehrere benachbarte Einträge identische Werte für dasselbe Attribut besitzen, kann ein RDN auch aus mehreren Attributen gebildet werden, die dann durch ein Pluszeichen getrennt werden. Weitere Besonderheiten sind zu beachten, wenn Sonderzeichen in Attribut-Werten enthalten sind. Die exakte Syntax bei der Bildung eines DN ergibt sich aus RFC 2253 [WKH97].

¹⁰ Dies kann man ganz einfach ausprobieren, indem man bei einem Browser, der LDAP unterstützt, den LDAP-URL (siehe unten) „ldap://servername.domäne/“ eingibt. Dadurch wird der root DSE des Servers angezeigt.

¹¹ Diese Freiheit ist ein Vorteil im Vergleich zu X.500-Directories, deren Namensmodell wesentlich restriktiver ist. Dort sind z.B. als suffixes nur Länder, Regionen oder Organisationen erlaubt.

¹² Nicht alle LDAP-Server-Implementationen unterstützen Aliase, da sie auch Server-übergreifend verwendbar sind und dabei zu erheblichen Einbußen in der Performanz bei Suchoperationen führen können, vgl. [HSG99, S. 88].

¹³ Der Aufbau eines LDAP-URLs ist in RFC 2255 [HoS97b] geregelt: er besteht aus dem Namen des Servers und seinem Port (i.d.R. 389) sowie (optional) dem DN auf den zugegriffen werden soll. Dabei ist insbesondere zu beachten, dass Sonderzeichen, die in URLs unzulässig sind, korrekt codiert werden, wie z.B. das Leerzeichen durch ‚%20‘. Beispiel: ldap://srv2.fernuni-hagen.de:389/ou=Personen,o=FernUni%20Hagen,c=DE

¹⁴ In der Version 2 von LDAP war dies noch ganz anders: ein LDAPv2-Server gibt keine Referrals zurück, sondern verfolgt Verweise selbst und gibt dem Client entweder ein Ergebnis oder eine Fehlermeldung. Als man erkannte, dass Referrals für LDAP sinnvoller sind als Chaining, wollte man den LDAPv2- Standard nicht mehr ändern und brachte den Referral übergangsweise (bis zu einer formellen Aufnahme in LDAPv3) in einem Feld der Fehlermeldung unter.

¹⁵ Es gibt einzelne Directory Produkte, in denen ganze Teilbäume von Einträgen mit einer Operation gelöscht werden können, vgl. z.B. [Armi99]. Dies ist aber die Ausnahme.

¹⁶ In LDAPv2 gibt es keine Operation Modify DN, sondern lediglich eine Operation Modify RDN. Damit ist es nicht möglich einen Eintrag oder sogar einen kompletten Teilbaum zu verschieben. Um zum selben Ergebnis zu kommen, muss man statt dessen sämtliche Einträge an ihren neuen Platz im DIT kopieren und an der alten Stelle löschen. Daraus wird deutlich, warum diese neue Operation in LDAPv3 hinzuge- fügt wurde.

¹⁷ Insofern wird auf entsprechende Veröffentlichungen wie z.B. [Matt98], [Schla96] oder [Dadam96] verwiesen.

¹⁸ Die Anzahl der möglichen Einträge in einem Directory ist bei Verteilung auf mehrere Server theoretisch unbegrenzt. Die maximale Kapazität eines einzelnen Servers hängt vom eingesetzten Produkt ab. Im Oracle Internet Directory [Orac99b] können sich beispielsweise auf einem einzigen Server über 500 Millionen Einträge befinden.

¹⁹ Bei durchaus namhaften Produkten wie dem IBM eNetwork LDAP Directory V.2.1 [IBM98] oder den Sun Directory Services 3.1 [Sun98], sucht man hiernach beispielsweise vergeblich.

²⁰ Nähere Informationen zu Transaktionen finden sich in [Schla96], [Dadam96], [Matt98] oder anderen Büchern zu Datenbanken.

²¹ Die LDAP Spezifikationen sehen keine Transaktionen vor. Es gibt jedoch die Möglichkeit, mit Hilfe von erweiterten LDAP Operationen wie BeginTransaction, CommitTransaction, und AbortTransaction Transaktionen mit LDAP zu realisieren, was allerdings nur eine proprietäre Lösung darstellt.

²² Dies ist letztlich nicht weiter verwunderlich, da ein Alias ja sogar auf einen anderen Server zeigen kann. Dies würde in Directories Konstrukte wie z.B. Löschweitergabe und Aktualisierungsweitergabe, die in relationalen Datenbanken dafür sorgen, dass die referentielle Integrität auch beim Löschen eines Tupels bzw. bei der Änderung seines Primärschlüssels erhalten bleibt, nicht unerheblich komplizieren. Gerade dies soll aber im Directory vermieden werden, um die Implementierung einfach zu halten.

²³ Gerade dies war ein Schlüsselfaktor für den Erfolg des World Wide Web, in dem extrem heterogene Client- und Serversysteme kommunizieren können, weil sie hierzu standardisierte Protokolle verwenden (nämlich TCP/IP und HTTP, vgl. 1.5 „Weitere Begriffe und Grundlagen“).