Enterprise-Anwendungen sind verteilte Anwendungen und das Auffinden von Ressourcen stützt sich dabei auf Namens- und Verzeichnisdienste. Dieser Artikel gibt eine Einführung in das Java Naming and Directory API (JNDI) und zeigt seine Anwendung anhand des freien LDAP-Servers OpenLDAP.
Jede Technologie hat ihre eigene Begriffswelt, und leider werden gleiche Begriffe immer wieder für unterschiedliche Dinge verwendet. Deshalb sollen hier zu Beginn die im Umfeld von JNDI benutzten Begriffe eingeführt werden.
Ein Namensdienst ( naming service) ist ein Dienst, der Namen mit Objekten assoziiert und Objekte anhand ihrer Namen findet. Hauptzweck ist die Vereinfachung für die Benutzer. Den Namen www.linux-magazin.de kann man sich leichter merken als die IP-Adresse, die dahinter steckt. Der Namensdienst DNS sorgt für die Zuordnung und Auflösung.
Namen innerhalb eines Namensdienstes folgen gewissen Syntaxregeln ( naming conventions). Bei DNS-Namen sind dies durch Punkte getrennte Zeichenfolgen, Dateinamen verwenden den Slash oder Backslash, LDAP-Namen dagegen durch Komma getrennte Folgen von Key=value-Paaren. Bei Namen unterscheidet man noch atomic names, compound names und composite names.
In dem oben aufgeführten Beispiel ist linux-magazin ein atomic name, während www.linux-magazin.de ein compound name ist. Dagegen ist http://www.linux-magazin.de ein composite name, da hier das DNS-Namenssystem verknüpft wird mit dem Protokoll-Namenssystem. Die Abgrenzung zwischen compound und composite ist aber von der Definition des Namensdienstes abhängig.
Die Zuordnung von Objekten zu Namen heißt binding. Manchmal lassen sich Objekte nicht direkt speichern, sondern nur eine Referenz ( reference). Das ist die Information darüber, wie man an das Objekt rankommt, gewissermaßen eine Adresse im weitesten Sinn.
Ein zentraler Begriff im JNDI ist der Context. Das ist eine Menge von Zuordnungen zwischen Namen und Objekten. Ein Beispiel, das auch die oben angesprochene Namensverwirrung zeigt, ist ein Verzeichnis (hier nicht im Sinne eines Verzeichnisdienstes) im Dateisystem, zum Beispiel /home. Alle Dateien innerhalb dieses Verzeichnisses bilden einen Context, da hier Dateinamen den entsprechenden Dateien zugeordnet sind. Context-Objekte stellen Methoden für das Auffinden von Objekten ( lookup) zur Verfügung, zusätzlich dazu noch Verfahren für das Erstellen und Löschen von bindings und deren Auflistung.
Ein Name in einem Context kann an ein weiteres Context-Objekt gebunden werden (ein so genannter Subcontext, im obigen Beispiel ein Unterverzeichnis), wodurch ein hierarchisches System entsteht. Sind alle Context-Objekte vom selben Typ, spricht man von einem naming system, das über seine Methoden den naming service bereitstellt.
Jeder Namensdienst hat sein eigenes Interface und die Entwicklerin muss deshalb die verschiedensten APIs beherrschen. Wenn auch DNS-Abfragen in einem Programm nicht zu den Kandidaten gehören, die durch andere Namensdienste ersetzt werden, so ist es durchaus denkbar, dass Objekte in einer ersten Programmversion über die RMI-Registry gefunden werden, in einer späteren Version aber auf CORBA umgestellt wird, mit den entsprechenden Folgen für den Code. Das JNDI sorgt hier für eine einheitliche Schnittstelle für die Anwendungsentwicklerin, so dass der Zugriff auf den Namensdienst transparent geschieht. Die Details werden im Abschnitt " Ein Blick in das API" erläutert.
Verzeichnisdienste ( directory services) sind erweiterte Namensdienste. Neben der Zuordnung von Namen zu Objekten erlaubt ein Verzeichnisdienst auch die Zuordnung von Attributen zu den Objekten. Das Interface wird dadurch mächtiger: Objekte können wie bisher über ihren Namen gefunden werden, zusätzlich aber auch über ihre Attribute. Diese können gesetzt, gelöscht oder gelistet werden.
Ein Verzeichnis ( directory) ist eine zusammengehörige Menge von Verzeichnisobjekten ( directory objects, auch directory entries genannt). Diese können Attribute besitzen. Ein Attribut ist dabei eine Zuordnung zwischen einem Attribut-Namen ( attribute identifier) und einem Satz von Werten ( attribute values). Klassisches Beispiel ist ein Telefonbuch (Verzeichnis) eines Ortes. Dort sind Personen (Verzeichnisobjekte) anhand ihrer Namen aufgeführt. Die Personen haben in der Regel zwei Attribute, die Straße (optional) und die Telefonnummer. Dieses Attribut kann einen oder mehrere Werte haben.
Verzeichnisdienste spielen in vielen vernetzten Umgebungen eine wichtige Rolle. Deshalb haben sich hier die verschiedensten Implementationen entwickelt, zum Beispiel die Novell Directory Services oder das NIS-System ( Network Information System). Informationen zu LDAP sind im Kasten "LDAP und X.500" aufgeführt. Das Verhältnis zwischen Verzeichnissen und Datenbanken wird im Kasten "Verzeichnisse und Datenbanken" näher erläutert.
|
LDAP und |
|---|
| Der Standard ITU X.500 definiert sowohl ein Datenmodell als auch ein Zugriffsprotokoll zu diesen Daten (X.500 Directory Access Protocol, DAP). Dieses Protokoll hatte ähnlich wie SGML den Nachteil, dass es umfassend, aber kompliziert war. Deshalb wurde zuerst von der Universität von Michigan das Lightweight Directory Access Protocol, kurz LDAP entwickelt. Mittlerweile ist es ein IETF-Standard und die entsprechenden Dokumente sind als RFCs verfügbar. Da LDAP ursprünglich nur als Zugriffsprotokoll ausgelegt war, definierte es kein eigenes Datenmodell. Mit der Evolution des LDAP-Standards hat sich das geändert, allerdings wurde das Basis-Schema praktisch unverändert von X.500 übernommen. Pionier für kommerzielle LDAP-Produkte war Netscape, dessen erste Version 1996 verfügbar wurde (Netscape hatte einfach das LDAP-Team der Universität von Michigan abgeworben). Momentan ist die Version 3 des LDAP-Protokolls aktuell. Weiterentwicklungen sind vor allem in Richtung einer Standardisierung der Authentifizierung, Zugriffskontrolle und Server-Server-Kommunikation (zur Replikation) zu erwarten. Daten sind im LDAP-Verzeichnis in einem hierarchischen Directory Tree (DT) angeordnet. Jeder Eintrag besteht aus einem oder mehreren Attributen. Ein Eintrag wird identifiziert durch seinen so genannten distinguishing name, dem DN. Ein DN wird aus einer geordneten Liste von Attribute-Werte-Paaren gebildet. Jedes Paar in der Liste ist ein Zweig im DT, mit dem Paar ganz rechts als Wurzel. Hier ein einfaches Beispiel: cn=Bernhard Bablok, o=Coffee-Shop Productions, c=DE
Um die Struktur des Verzeichnisses zu definieren, braucht es drei Komponenten: Syntax-Definitionen (Wert-Typen, z.B. Binary oder Case Exact String), Attribut-Definitionen und Klassen für Verzeichniseinträge. Attribut-Definitionen legen fest, welcher Syntax die Wertausprägungen folgen. Darüber hinaus werden so genannte matching rules für Datenvergleiche (wichtig für die Suche) definiert. Ein Beispiel ist die Art und Weise, wie Whitespace behandelt wird. Attribute erlauben Vererbung, das heißt, dass ein neues Attribut ein bestehendes erweitern kann (die Syntax darf dabei aber nicht geändert werden). Jeder Verzeichniseintrag gehört einer oder mehreren Klassen an. Eine Klasse definiert die nötigen und optionalen Attribute dieses Eintrags. Auch Klassen werden über eine Hierarchie definiert. Die oberste Klasse ist die Klasse Top mit dem Attribute objectClass. Der Wert dieses Attributs ist die Liste aller Objekt-Klassen, die für diesen Eintrag gelten. Alle Klassen bilden zusammen das Schema. Wichtigstes Schema ist das User Schema, eine Zusammenfassung davon findet sich im RFC 2256 (X.500(96) User Schema). Will man eigene Objekte speichern, muss man entweder die Schema-Überprüfung im LDAP-Server ausschalten oder die neuen Klassen bekannt machen. Je nach LDAP gibt es dafür unterschiedliche Wege (bei OpenLDAP werden die Klassendefinitionen einfach in die Konfigurationsdatei eingefügt). Die Topologie eines Verzeichnisses kann partitioniert, repliziert oder eine Mischform sein. Im ersten Fall ist ein Eintrag nur einmal in einem einzelnen Server vorhanden. Anfragen, die ein Server nicht beantworten kann, werden an andere Server weitergeleitet ( referrals). Das kann Server-basiert geschehen oder durch den Client (der eine entsprechende Antwort vom Server bekommt und dann selbst entscheiden muss, die Anfrage weiterzugeben oder nicht). Ein Spezialfall von Referrals sind continuations. Diese implementieren die verteilte Suche. Eine replizierte Topologie wird von LDAP ebenfalls unterstützt. Dabei sind zwei Modelle möglich: Master/ Slave und Peer to Peer. Für die Replikation existiert noch kein endgültiger Standard. Der Zugriff auf LDAP-Server erfolgt über LDAP-Urls (definiert in RFC 2255). Hier ein Beispiel ldap://localhost/o=Coffee-Shop%20Productions,c=DE
|
Wie schon bei den Namensdiensten erwähnt hat jeder Verzeichnisdienst sein eigenes Interface. Auch hier führt die Verwendung des JNDI zu einer standardisierten Schnittstelle.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
