Directory Services - LDAP, JNDI

Präsentation zum Thema: "Directory Services - LDAP, JNDI"—  Präsentation transkript:

1 Directory Services - LDAP, JNDI
Thomas Friese Directories allgemein Beziehung zu Datenbanken LDAP LDIF JNDI Seminar: Verteilte Informationssysteme Fachbereich Mathematik - Fachgebiet Informatik Philipps Universität Marburg, September 2000

2 Gemeinsame Eigenschaften
Was sind Directories? Beispiele Telefonbuch Fernsehzeitung Versandhauskatalog Kundenkartei Lieferantenkartei Gemeinsame Eigenschaften Es sind Sammlungen von Einträgen Es erfolgen häufig Anfragen nach bestimmten Einträgen Die Einträge sollten sinnvoll gegliedert sein Änderungen der Einträge sind seltener als Abfragen

3 Elektronische Directories
Oftmals auch als „on-line“-Directories bezeichnet, bieten sie einige Vorteile gegenüber klassischen Directories: Suche: Durch den Computereinsatz kann die Suche erheblich vereinfacht und beschleunigt werden. Flexibilität: Information kann jederzeit aktualisiert werden. Anwendungsnähe: Die Information kann leichter mit dem Computer verarbeitet werden. Wiederverwendbarkeit: EIN Datenbestand kann für viele Anwendungen verwendet werden. Sicherheit: Es ist leichter eine einheitliche Sicherheitspolitik mit einem (zentralen) elektronischen Directory durchzusetzen.

4 Beispiele elektronischer Directories
DNS - Das Domain Name System des Internet Einer der ältesten und größten Directory Dienste. Untrennbar mit dem Internet verknüpft. Speichert in vielen verteilten Verzeichnissen Informationen über IP-Adressen und Host-/Domain- Namen. NIS+ - Network Information System von Sun Directory Dienst von Solaris (ursprünglich SunOS). Ein zentraler Server verwaltet Informationen über die in einer NIS-Domain zusammengefassten Rechner. NIS ist inzwischen Bestandteil fast jeder UNIX-Variante. NDS - Novell Directory Services Windows-Unix-Integration, Corporate Directory, implementiert LDAP.

5 Das Verhältnis zwischen Datenbanken und Directories
Man kann Directories als spezielle Datenbankanwendungen betrachten. Die Speicherung der Daten eines Directories wird typischerweise von einem Datenbank-Backend erledigt. Unterschiede zwischen Directories und Datenbanken Verhältnis zwischen Schreib- und Lesezugriffen Erweiterbarkeit (Typdefinitionen, „schemas“ etc.) Verteilte Information (Ausnutzen der hierarchischen Gliederung) Standardisierung (LDAP) Replikation (Zuverlässigkeit, Verfügbarkeit, Lokalität, Leistung) Leistung (kleinere Datensätze, dafür mehr Anfragen bei Directories) Directories unterstützen keine Transaktionen Directories sind nicht gedacht für komplexe Anfragen (Joins...)

6 Leightweight Directory Access Protocol
Neben dem Zugriffsprotokoll auf ein Directory werden von LDAP vier „Modelle“ definiert, die bei der Planung und Implementierung von Directory-Diensten helfen. Diese LDAP-Modelle sind: Information Model Naming Model Functional Model Security Model LDAP wird immer häufiger unterstützt und verwendet. Ist wesentlich einfacher als das früher definierte X.500 DAP (deswegen auch „Leightweight“ im Namen). Anders als beispielsweise HTTP und SMTP arbeitet es aber nicht mit leicht für Menschen verständlichen Befehlen, sondern Befehlscodes. Der aktuelle Standard beschreibt LDAP Version 3 (LDAPv3).

7 LDAP Information Model
Directory Eintrag (entry) Ein Directory besteht aus Einträgen. Attribut Ein Eintrag besteht aus einem oder mehreren Attributen. Typ Wert Ein Attribut hat einen Typ und einen oder mehrere Werte.

8 LDAP Information Model
Einzelne Einträge können einer oder mehreren Objektklassen zugeordnet werden. Diese beschreiben, welche Attribute ein Eintrag haben muß und welche er haben kann. Informationen über Attributtypen und Objektklassen werden in „schemas“ festgelegt. Viele sinnvolle Attributtypen und Objektklassen sind bereits durch die IETF und verschiedene Hersteller von Directory-Software wie Netscape und Microsoft definiert worden. Beispiele: cn - Common Name dc - Domain Component sn - Surname uid - User ID Attributtypen person organization uidObject simpleSecurityObject Objektklassen

9 Schema-Definition Attributtypen (<oid> NAME <name>
Verschiedene Standards und LDAP Implementierungen verwenden sehr unterschiedliche Formate zur Schemabeschreibung. LDAPv3 fordert, daß Directoryserver unterstützte schemas mittels LDAP übertragen können - und möglichst auch verändern lassen. Attributtypen (<oid> NAME <name> [DESC <desc>] [SUP <supoid>] [EQUALITY <equalitymatchoid>] [ORDERING <ordmatchoid>] [SUBST <submatchoid>] [SYNTAX <synoid>] [SINGLE-VALUE]) Objekt-ID und Name (eindeutig) Beschreibung (String in Hochkommata) Vatertyp (ID des Typs aus, dem abgeleitet wird) IDs der Methoden zum Stringvergleich und für die verwendete Syntax. Ein Attribut ist „multi-valued“ solange nicht anders gefordert.

10 ( <oid> NAME <name> [DESC] <desc> [SUP] <oid>
Objektklassen ( <oid> NAME <name> [DESC] <desc> [SUP] <oid> [ABSTRACT | AUXILIARY | STRUCTURAL] [MUST <attributeset>] [MAY <attributeset>] ) Objekt-ID und Name (eindeutig) Beschreibung (String in Hochkommata) Superklasse (ID der Klasse, aus der abgeleitet wird) Erforderliche.... ...mögliche Attribute Format für „attributeset“: ( <name | oid> $ <name | oid> $ ... ) Objekt-IDs können voneinander abgeleitet werden. Jeder, der eine OID besitzt, kann eine neue vergeben, indem er sie „erweitert“ und dies registriert. Es sind Folgen von durch Punkte getrennte Zahlen. Beispiel: ist die OID für Attributtypen der Universität von Michigan ( wäre dann der erste Typ der zweite Typ usw.)

11 Beispiele attributetype ( 2.5.4.41 NAME 'name'
EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX {32768} ) attributetype ( NAME ( 'cn' 'commonName' ) SUP name ) objectclass ( NAME 'organization' SUP top STRUCTURAL MUST o MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) )

12 LDAP Naming Model Um jeden Eintrag eines Directories ansprechen zu können, wird ihm ein eindeutiger Name zugeordnet, der „Distinguished Name“ (DN). Man nutzt hier die hierarchische Struktur eines Directories aus und beschreibt den Pfad vom Eintrag bis zur Wurzel des Directories. Den am Anfang dieser - durch Komma getrennten - Liste stehenden Eintrag bezeichnet man als: „Relative Distinguished Name“ (RDN). Hieraus erkennt man leicht, daß der RDN für zwei Einträge mit identischem übergeordneten Eintrag nicht gleich sein darf.

13 Beispiel dn: dc=uni-mr, dc=de o: Uni-Marburg.de
dn: dc=mathematik, dc=uni-mr, dc=de dc: mathematik dn: dc=physik, dc=uni-mr, dc=de dc: physik dn: ou=people, ou=mathematik, dc=uni-mr, dc=de ou: people dn: ou=devices, ou=mathematik, dc=uni-mr, dc=de ou: devices dn: cn=spitzweg, ou=devices, ou=mathematik, dc=uni-mr, dc=de cn: spitzweg resolution: 1200 description: LaserJet 4000N in Raum D4416 dn: uid=friese, ou=people, ou=mathematik, dc=uni-mr, dc=de cn: Thomas Friese sn: Friese

14 LDAP Functional Model Interrogation operations
Es beschreibt eine Reihe von Operationen, die in drei Klassen eingeteilt werden: Interrogation operations dienen dazu, Informationen im Directory zu suchen oder aus dem Directory abzufragen. Update operations erlauben es, Daten zu verändern, löschen, verschieben oder hinzuzufügen. Authentication operations ermöglichen es einem Client, sich beim Directoryserver zu authentifizieren und so das Verhalten während einer Session zu steuern.

15 LDAP Security Model Die Verbindungsorientiertheit des Protokolls wird ausgenutzt. Prinzipiell authentifiziert sich ein Client nach dem Aufbau einer Verbindung und verwendet dann diese Verbindung für alle folgenden Operationen. LDAP bis Version 2 erlaubt nur Kerberos- und eine einfache Authentifizierung. Ab Version 3 besteht die Möglichkeit mittels des SASL Frameworks (Simple Authentication and Security Layer) auch andere Mechanismen zu integrieren. LDAP selbst definiert (noch) keinen Mechanismus zur Verwaltung von Zugriffsrechten.

16 LDIF - LDAP Data Interchange Format
Wird verwendet, um große Mengen von Einträgen textuell zu repräsentieren. Format: [<id>] dn: <distinguished name> objectClass: <object class> ... <attribute type>[;lang-TAG]:<attribute value> Mehrere Einträge in einer LDIF-Datei werden durch Leerzeilen getrennt.

17 Verteilte Directories
Oftmals erscheint es sinnvoll, die Informationen nicht in einem einzigen, sondern mehreren verbundenen Servern zu speichern. Hierzu nutzt man oft die hierarchische Anordnung der Einträge aus. Auch die Netzwerktopologie oder organisatorische sowie topographische Aufteilung einer Organisation können hier für eine Aufteilung sprechen. Man betrachtet oft den gesamten „Directory Information Tree“ und teilt diesen dann in Partitionen auf, die auf verschiedene Server verteilt werden können. Daneben kann man ein Directory auf mehreren Servern in identischen Kopien speichern (Replikation).

18 Beispiele dc=uni-marburg, dc=de ou=physik ou=HRZ ou=personen ou=geräte
ou=mathematik dc=company dc=com dc=america dc=europe dc=afrika ou=people ou=devices

19 Verbindung zwischen den Directories
Server 1 Server 1 Server 3 Server 2 Client Verbindung mittels „Chaining“ Kann ein Server die Anfrage eines Clients nicht beantworten, befragt er einen anderen Server von dem er eine Antwort erwartet, oder der genauso „weiter fragt“... Server 2 Server 3 Client Verbindung mittels „Referral“ Kann ein Server die Anfrage eines Clients nicht beantworten, leitet er ihn an einen anderen Server weiter, der die Antwort geben kann, oder weiterleitet...

20 Typische Anwendungen „White Pages“
„Ich suche Adresse und Telefonnummer von....“ „Yellow Pages“ „Ich brauche eine Liste aller Drucker....“ „Attribute Mapping“ „Welche -Adresse hat der Benutzer mit UID....“ „Welche IP-Adresse hat der Rechner pc12345.mathematik....“ Adressregister und die Unterstützung von Netzwerk-Betriebssystemen sind die häufigsten Anwendungen.

21 Directory Server - „nur die halbe Miete“
Neben den eigentlichen „Directory Services“ - also der Software auf einem (oder mehreren) Servern, müssen auch die Clients mit dem Directory in Kontakt treten können! Hier ist LDAP als Standard hilfreich. Viele Applikationen sind schon „directory aware“. Die Hersteller von Server-Software bieten (meist kostenlos) für alle gängigen Programmiersprachen SDKs an. Damit ist es relativ einfach eigene Applikationen mit Directory- Unterstützung zu entwickeln. Für JAVA gibt es das „Java Naming and Directory Interface“ (JNDI). Aber das JNDI ist mehr als ein simples LDAP-SDK!

22 JNDI - Java Naming and Directory Interface
JAVA Applikation JNDI API JNDI Naming Manager JNDI SPI LDAP NDS SPI - Service Provider Interface

23 Wichtige Interfaces und Methoden
Context repräsentiert einen Namensraum und stellt damit das wichtigste Interface des JNDI dar. lookup(String/Name) schlägt einen Eintrag des Directories nach. bind(Name,Object) bindet Objekt an Namen. DirContext erweitert Context um Eigenschaften, die für den Umgang mit Directories typisch sind. search(...) erlaubt suche im Directory. bind(Name,Object,Attributes) bindet Objekt an Namen unter berücksichtigung der Attribute. getSchema(String/Name) ermittelt das Schema, welches mit dem Objekt assoziiert ist. Name Interface zur Repräsentation eines generischen Namens.