X.500 wird im allgemeinen als Sammelbegriff für eine Reihe von Standards der internationalen Normierungsgremien ISO und ITU-T verwendet. Der Standard ist vom benutzten Computersystem unabhängig. Er stellt ein beliebig verteilbares und weltweit zugängliches Datenbankkonzept zur Verfügung. In dieses können hierarchisch darstellbare Informationen abgelegt werden.

Bisher sind zwei vollständige Versionen des Standards erschienen, benannt nach ihrem Erscheinungsjahr 1988 beziehungsweise 1993. Bereits der 88er Standard stellte umfassende Spezifikationen zum Aufbau eines globalen Verzeichnisses bereit. Eine überarbeite Version mit neuen Funktionen verabschiedeten die Standardisierungsgremien 1993. Und die nächste Version der Spezifikation ist bereits in Arbeit. Zu den geplanten Neuerungen zählt unter anderem das Remote-Management von Directory System Agents (DSAs) sowie eine Internationalisierung, die die Verwendung verschiedener Sprachen und Zeichensätze im Verzeichnis standardisiert. Des weiteren stehen im Pflichtenheft Punkte wie die Definition entsprechender Attribute, um die Stellung von X.500 als Speicherort für sicherheitsrelevante Informationen zu stärken.

Damit die X.500-Konzepte leichter zu erfassen sind, definiert der Standard verschiedene Modelle. Eines davon, das "Directory Information Model", beschreibt die Sichtweise des Verzeichnisses als eine einzelne zentrale Datenbank. In diesem Modell lassen sich die Einträge im Verzeichnis mit denen eines herkömmlichen Datenbanksystems vergleichen, wenn auch die verwendete Terminologie eine andere ist. Jeder Eintrag im Verzeichnis setzt sich aus einem oder mehreren Attributen zusammen, von denen jedes einen oder mehrere Werte besitzen kann. Welche Werte ein Attribut annehmen darf, legt die zugeordnete Attributssyntax fest. Ein herauszuhebendes Attribut ist die Objektklasse, diese spezifiziert den Typ eines Eintrags näher und legt fest, welche Attribute im Eintrag zwingend erforderlich sind und welche optional angegeben werden können.

Alle Verzeichniseinträge sind im "Directory Information Tree" (DIT) hierarchisch angeordnet. Knoten bezeichnen DIT-Einträge, unterhalb derer sich noch weitere Einträge befinden. Ein Personeneintrag (commonName = Hans Mustermann) ist beispielsweise unterhalb der Organisation (organization = Univ. XY) angeordnet, in der die Person tätig ist. Dieser Eintrag ist wiederum unterhalb des Landes (country = DE) angesiedelt, in der die Organisation beheimatet ist. Bestimmte Attributswerte eines Eintrags sind dabei hervorgehoben, da sie den "Relative Distinguished Name" (RDN) dieses Eintrags bilden. Dieser muß gemäß Definition innerhalb der betrachteten Hierarchieebene eindeutig sein. Zusammen mit den im DIT übergeordneten RDNs ergibt sich der eindeutige "Distinguished Name" (DN) des Eintrags. Im Beispiel führt dies zu folgender DN: cn = Hans Mustermann, o = Univ. XY, c = DE. Neben den reinen Benutzerdaten speichert das Verzeichnis noch weitere, administrative Daten. Diese umfassen etwa Angaben über die Art von Informationen, die in einem bestimmten Teilbereich des DITs abgelegt werden können, oder Angaben zur Zugriffskontrolle.

Bei der obigen Betrachtung spielte die Verteilung der Daten auf verschiedene Server DSAs beziehungsweise deren Replikation noch keine Rolle. Teilbereiche des DITs können aber beliebig auf verschiedene DSAs übertragen sowie Kopien der Daten auf weitere DSAs verteilt werden. In diesem "DSA Information Model" kennt jeder DSA zunächst nur die von ihm selbst vorgehaltenen Einträge. Dies mag im lokalen Umfeld, beispielsweise innerhalb einer Organisation, ausreichen, nicht jedoch für die Einordnung im globalen DIT. Hierzu sind weitere Informationen erforderlich. Ein typischer DSA enthält deshalb neben seinen (Master-)Einträgen noch Daten darüber, wo diese Einträge im globalen DIT angesiedelt sind, sowie Informationen zur Replikation von Daten.

Nachdem bisher das Augenmerk der Datenspeicherung und deren Verteilung im X.500-Verzeichnis galt, ist abschließend zum vollständigen Verständnis noch der Informationsaustausch beziehungsweise -zugriff zu erklären. Um einem Benutzer den Zugriff auf die Daten zu ermöglichen, definiert der X.500-Standard den Begriff des "Directory User Agent" (DUA), mit dem über das "Directory Access Protocol" (DAP) Daten gesucht, geändert, aber auch gelöscht und angelegt werden können. Ist ein DSA (A) nicht in der Lage, die an ihn gestellte Anfrage zu beantworten, leitet er die Anfrage mittels des "Directory System Protocol" (DSP) an einen kooperierenden DSA (B) weiter. Von diesem erhält er die Antwort und gibt sie an den anfragenden DUA zurück. Sollte DSA (B) die Anfrage nicht beantworten, kontaktiert A eventuell einen DSA (C), um die Informationen zu bekommen. Schlägt dies fehl, wird eine entsprechende Fehlermeldung zurückgegeben. Dieser als "Chaining" bezeichnete Prozeß, verbirgt vor dem DUA die Tatsache, daß das Verzeichnis verteilt ist. Anders ist dies, wenn der DSA die Anfrage nicht weiterleitet, sondern vielmehr dem DUA (oder DSA) einen "Referral" auf den DSA zurückliefert, der im Falle des "Chainings" kontaktiert worden wäre. Die Verteilung der Daten auf mehrere Server ist sichtbar.

Das "Directory Information Shadowing Protocol" (DISP) von X.500 stellt ein vollständiges Replikationsmodell bereit. Replikation funktioniert grundsätzlich in zwei Richtungen: Zum einem können die eigenen Daten an andere DSAs weitergegeben, zum anderen können Kopien der Daten anderer DSAs bezogen werden. Voraussetzung für die Replikation ist immer, daß zwischen dem DSA, der die Daten bereitstellt, ("Supplier"-DSA), und dem DSA, der die Informationen entgegen nimmt ("Consumer"-DSA), ein "Shadowing Agreement" besteht. Solche Vereinbarungen legen fest, welche DIT-Bereiche zu replizieren sind. Ebenso definieren sie die Parameter zur gegenseitigen Authentifizierung der korrespondierenden DSAs sowie den Modus, nach dem die Replikation erfolgt.

Neben den oben beschriebenen Eigenschaften legten die X.500-Väter großen Wert auf sicherheitsrelevante Fragen. Die Sicherheit der im Verzeichnis gespeicherten Informationen gewährleistet die Authentifizierung und die Vergabe von Zugriffsrechten. Bei der einfachen Authentifizierung werden DN und Paßwort im Klartext (daher sehr unsicher) oder durch eine Hash-Funktion geschützt übermittelt. Im Gegensatz dazu finden bei der strengen Authentifizierung kryptografische Verfahren Anwendung, die den Austausch öffentlicher Schlüssel voraussetzen - so zum Beispiel bei Pretty Good Privacy (PGP), die natürlich jederzeit abrufbar sein müssen.

X.500 als Ablage für Sicherheitsschlüssel

Es versteht sich von selbst, daß ein X.500-Verzeichnis für die Ablage der Schlüssel bestens geeignet ist. Benutzerabhängige Zugriffsrechte sind so sehr detailliert definierbar. Dabei können bestimme Rechte nicht nur für ganze Einträge, sondern auch beschränkt auf einzelne Attribute innerhalb eines Eintrags vergeben werden. Des weiteren lassen sich Bereiche definieren, für die ein authentifizierter Benutzer bestimmte Rechte besitzt.

Neben den klassischen X.500-Protokollen unterstützen neuere DSA-Produkte auch direkt das "Lightweight Directory Access Protocol"(LDAP). LDAP wurde Anfang der 90er Jahre an der University of Michigan entwickelt und später als Proposed Internet Standard (LDAPv2, RFC 1777) veröffentlicht. Ursprünglich nur als Ergänzung zu DAP gedacht, entwickelte sich LDAP schnell zu einem quasi eigenen Dienst. So ersetzten die Entwickler den DSA durch eine Datenbank, mit der LDAP direkt kommunizierte. Damit war ein "schlanker" Stand-alone-LDAP-Server (SALDP) geboren. Die aktuelle LDAP-Version 3.0 (RFC 2251) beseitigte dann einige vorhandene Beschränkungen von LDAP v2 und definierte eine Reihe von Erweiterungen. Diese ermöglichen es, neue Funktionen einfach zu implementieren.

LDAP findet inzwischen mehr und mehr Anerkennung und wird von vielen großen Softwareherstellern (Netscape, Lotus, Microsoft, Novell) in den gängigen Produkten unterstützt. Diese Popularität kann jedoch nicht darüber hinwegtäuschen, daß in LDAP nicht alle Belange für den Aufbau eines allein hierauf basierenden globalen Verzeichnisses definiert sind. Während im X.500 alle Mechanismen für ein globales interoperables Verzeichnis standardisiert sind, wird bei LDAP die Existenz eines Verzeichnismodells nur angenommen. Wichtige Gesichtspunkte wie Zugriffskontrolle und Referral-Informationen sind zwar berücksichtigt, Methoden wie diese Informationen im Verzeichnis repräsentiert werden können, sind aber bislang nicht standardisiert. Zudem fehlt noch ein Modell zur Replikation. Zwei IETF-Arbeitsgruppen (ldapext, ldup) beschäftigen sich im Moment mit diesen Problemen und haben ihre Ergebnisse in verschiedenen Internet-Drafts veröffentlicht. Entsprechende Request for Comment (RFCs) existieren aber noch nicht. Einige Hersteller setzen deshalb teilweise auf proprietäre Lösungen oder verwenden etwa bei der Replikation produktspezifische Mechanismen wie die Novell Director Services (NDS) oder die Active Directory Services (ADS) von Microsoft. Mit der Verfügbarkeit dieser Produkte steigt leider die Gefahr, daß immer mehr Verzeichnisinseln entstehen. Solange der Anwender nur Produkte eines Herstellers verwendet, lassen sich einzelne Inseln zwar miteinander verbinden, eine Integration in das globale X.500-Verzeichnis bleibt aber außen vor.

Beide Ansätze, X.500 und LDAP, haben ihre Vor- und Nachteile. Die Entscheidung, welches System letztendlich zum Einsatz kommt, sollte sich an der Anwendung orientieren und ist im Vorfeld gut zu überdenken..

Angeklickt

Einer der wohl ältesten Verzeichnisdienste ist X.500. Sein Alter ist in der schnellebigen DV-Zeit ausnahmsweise ein Vorteil. Über die Jahre reifte X.500 zu einem computerunabhängigen Verzeichnisdienst, der zudem den Standardsegen der Organisationen ISO und ITU-T hat. Kämpft sich der Anwender durch die etwas komplizierte Struktur des Dienstes, so steht ihm ein universell nutzbares Verzeichnis zur Verfügung, das auch den modernen Aspekten (E-Commerce) der Datenverarbeitung gerecht wird. Allerdings erwächst X.500 in Form von LDAP ein Konkurrent, der dem Oldie seinen Platz streitig machen könnte. Noch fehlen LDAP zwar einige grundlegende Eigenschaften von X.500, doch die Entwickler arbeiten konsequent daran. Für LDAP spricht vor allem der schlankere Aufbau.

*Ralf Schneider ist an der Universität Tübingen am Zentrum für Datenverarbeitung tätig.

Abb.1: Directory-Struktur

Attribute definieren in X.500 die Eigenschaften der gespeicherten Objekte (etwa Anwender). Quelle: Schneider

Abb.2: Verzeichnisbaum

Im Directory Information Tree sind alle Einträge hierarchisch geordnet. Quelle: Schneider