RFC 4516 - Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator
- Status: Proposed Standard
- Veröffentlicht: June 2006
- Stream: IETF
- Ersetzt: RFC2255
- Errata: Keine Errata
Zusammenfassung
Dieses Dokument beschreibt ein Format für einen Lightweight Directory Access Protocol (LDAP) Uniform Resource Locator (URL). Eine LDAP-URL beschreibt eine LDAP-Suchoperation, die verwendet wird, um Informationen aus einem LDAP-Verzeichnis abzurufen, oder im Kontext eines LDAP-Verweises oder einer Referenz beschreibt eine LDAP-URL einen Dienst, bei dem eine LDAP-Operation fortgesetzt werden kann.
Inhaltsverzeichnis
- Einführung
- URL-Definition 2.1. Prozent-Codierung
- Standardwerte für Felder der LDAP-URL
- Beispiele
- Sicherheitsüberlegungen
- Normative Verweise
- Informative Verweise
- Danksagungen Anhang A: Änderungen seit RFC 2255
1. Einführung
LDAP ist das Lightweight Directory Access Protocol [RFC4510]. Dieses Dokument spezifiziert das LDAP-URL-Format für Version 3 von LDAP und stellt klar, wie LDAP-URLs aufgelöst werden. Dieses Dokument definiert auch einen Erweiterungsmechanismus für LDAP-URLs. Dieser Mechanismus kann verwendet werden, um Zugriff auf neue LDAP-Erweiterungen bereitzustellen.
Beachten Sie, dass nicht alle Parameter der in [RFC4511] beschriebenen LDAP-Suchoperation unter Verwendung des in diesem Dokument definierten Formats ausgedrückt werden können. Beachten Sie auch, dass URLs verwendet werden können, um Referenzwissen darzustellen, einschließlich solcher für Nicht-Suchoperationen.
Dieses Dokument ist ein integraler Bestandteil der technischen Spezifikation von LDAP [RFC4510], die die zuvor definierte technische Spezifikation von LDAP, RFC 3377, in ihrer Gesamtheit ersetzt.
Dieses Dokument ersetzt RFC 2255. Siehe Anhang A für eine Liste der Änderungen im Vergleich zu RFC 2255.
2. URL-Definition
Eine LDAP-URL beginnt mit dem Protokollpräfix "ldap" und wird durch die folgende Grammatik definiert, die der in [RFC4234] definierten ABNF-Notation folgt.
ldapurl = scheme COLON SLASH SLASH [host [COLON port]]
[SLASH dn [QUESTION [attributes]
[QUESTION [scope] [QUESTION [filter]
[QUESTION extensions]]]]]
; <host> and <port> are defined
; in Sections 3.2.2 and 3.2.3
; of [RFC3986].
; <filter> is from Section 3 of
; [RFC4515], subject to the
; provisions of the
; "Percent-Encoding" section
; below.
scheme = "ldap"
dn = distinguishedName ; From Section 3 of [RFC4514],
; subject to the provisions of
; the "Percent-Encoding"
; section below.
attributes = attrdesc *(COMMA attrdesc)
attrdesc = selector *(COMMA selector)
selector = attributeSelector ; From Section 4.5.1 of
; [RFC4511], subject to the
; provisions of the
; "Percent-Encoding" section
; below.
scope = "base" / "one" / "sub"
extensions = extension *(COMMA extension)
extension = [EXCLAMATION] extype [EQUALS exvalue]
extype = oid ; From section 1.4 of [RFC4512].
exvalue = LDAPString ; From section 4.1.2 of
; [RFC4511], subject to the
; provisions of the
; "Percent-Encoding" section
; below.
EXCLAMATION = %x21 ; exclamation mark ("!")
SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?")
Das Präfix "ldap" bezeichnet einen Eintrag oder Einträge, auf die vom LDAP-Server zugegriffen werden kann, der auf dem angegebenen Hostnamen unter der angegebenen Portnummer ausgeführt wird. Beachten Sie, dass der <host> literale IPv6-Adressen enthalten kann, wie in Abschnitt 3.2.2 von [RFC3986] angegeben.
Der <dn> ist ein LDAP Distinguished Name unter Verwendung des in [RFC4514] beschriebenen Zeichenfolgenformats. Er identifiziert das Basisobjekt der LDAP-Suche oder das Ziel einer Nicht-Suchoperation.
Das Konstrukt <attributes> wird verwendet, um anzugeben, welche Attribute aus dem Eintrag oder den Einträgen zurückgegeben werden sollen.
Das Konstrukt <scope> wird verwendet, um den Umfang der Suche anzugeben, die auf dem angegebenen LDAP-Server durchgeführt werden soll. Die zulässigen Bereiche sind "base" für eine Basisobjektsuche, "one" für eine Suche auf einer Ebene oder "sub" für eine Teilbaumsuche.
Der <filter> wird verwendet, um den Suchfilter anzugeben, der während der Suche auf Einträge innerhalb des angegebenen Bereichs angewendet werden soll. Er hat das in [RFC4515] angegebene Format.
Das Konstrukt <extensions> stellt der LDAP-URL einen Erweiterbarkeitsmechanismus zur Verfügung, der es ermöglicht, die Fähigkeiten der URL in Zukunft zu erweitern. Erweiterungen sind eine einfache kommagetrennte Liste von type=value-Paaren, wobei der Teil =value für Optionen, die ihn nicht erfordern, weggelassen werden KANN (MAY). Jedes type=value-Paar ist eine separate Erweiterung. Diese LDAP-URL-Erweiterungen stehen nicht unbedingt im Zusammenhang mit einem der LDAP-Erweiterungsmechanismen. Erweiterungen können vom Client, der die URL auflöst, unterstützt oder nicht unterstützt werden. Eine Erweiterung, der ein '!'-Zeichen (ASCII 0x21) vorangestellt ist, ist kritisch. Eine Erweiterung, der kein '!'-Zeichen vorangestellt ist, ist nicht kritisch.
Wenn eine LDAP-URL-Erweiterung implementiert ist (d. h., wenn die Implementierung sie versteht und verwenden kann), MUSS (MUST) die Implementierung sie verwenden. Wenn eine Erweiterung nicht implementiert ist und als kritisch markiert ist, DARF die Implementierung die URL NICHT (MUST NOT) verarbeiten. Wenn eine Erweiterung nicht implementiert ist und nicht als kritisch markiert ist, MUSS (MUST) die Implementierung die Erweiterung ignorieren.
Der Erweiterungstyp (<extype>) KANN (MAY) unter Verwendung der numerischen OID <numericoid>-Form (z. B. 1.2.3.4) oder der Deskriptor <descr>-Form (z. B. myLDAPURLExtension) angegeben werden. Die Verwendung der <descr>-Form SOLLTE (SHOULD) auf registrierte beschreibende Namen von Objektbezeichnern beschränkt sein. Siehe [RFC4520] für Registrierungsdetails und Verwendungsrichtlinien für beschreibende Namen.
In diesem Dokument sind keine LDAP-URL-Erweiterungen definiert. Andere Dokumente oder eine zukünftige Version dieses Dokuments KÖNNEN (MAY) eine oder mehrere Erweiterungen definieren.
2.1. Prozent-Codierung
Eine generierte LDAP-URL MUSS (MUST) nur aus dem eingeschränkten Satz von Zeichen bestehen, die in einer der folgenden drei in [RFC3986] definierten Produktionen enthalten sind:
<reserved>
<unreserved>
<pct-encoded>
Implementierungen SOLLTEN (SHOULD) andere gültige UTF-8-Zeichenfolgen [RFC3629] als Eingabe akzeptieren. Ein Oktett MUSS (MUST) in jeder der folgenden Situationen unter Verwendung des in Abschnitt 2.1 von [RFC3986] beschriebenen Prozent-Codierungsmechanismus codiert werden:
- Das Oktett befindet sich nicht in dem in Abschnitt 2.2 von [RFC3986] definierten reservierten Satz oder in dem in Abschnitt 2.3 von [RFC3986] definierten nicht reservierten Satz.
- Es ist das einzelne reservierte Zeichen '?' und kommt innerhalb eines
<dn>,<filter>oder eines anderen Elements einer LDAP-URL vor. - Es ist ein Kommazeichen ',', das innerhalb eines
<exvalue>vorkommt.
Beachten Sie, dass die Erweiterungskomponente der LDAP-URL vor der Anwendung des Prozent-Codierungsmechanismus ein oder mehrere Null- (Zero-) Bytes enthalten kann. Keine andere Komponente darf dies.
3. Standardwerte für Felder der LDAP-URL
Einige Felder der LDAP-URL sind optional, wie oben beschrieben. In Ermangelung einer anderen Spezifikation SOLLTEN (SHOULD) die folgenden allgemeinen Standardwerte verwendet werden, wenn ein Feld fehlt. Beachten Sie, dass andere Dokumente abweichende Standardregeln festlegen KÖNNEN (MAY); beispielsweise spezifiziert Abschnitt 4.1.10 von [RFC4511] eine andere Regel zur Bestimmung des korrekten DN, der verwendet werden soll, wenn er in einer LDAP-URL fehlt, die als Verweis zurückgegeben wird.
<host>
Wenn kein <host> angegeben ist, muss der Client über ein gewisses A-priori-Wissen über einen geeigneten LDAP-Server verfügen, der kontaktiert werden soll.
<port>
Der Standard-LDAP-Port ist TCP-Port 389.
<dn>
Wenn kein <dn> angegeben ist, ist der Standard der DN mit der Länge Null, "".
<attributes>
Wenn der Teil <attributes> weggelassen wird, sollten alle Benutzerattribute des Eintrags oder der Einträge angefordert werden (z. B. durch Setzen des Attributfelds AttributeDescriptionList in der LDAP-Suchanforderung auf eine NULL-Liste oder durch Verwendung des speziellen <alluserattrs>-Selektors "*").
<scope>
Wenn <scope> weggelassen wird, wird ein <scope> von "base" angenommen.
<filter>
Wenn <filter> weggelassen wird, wird ein Filter von "(objectClass=*)" angenommen.
<extensions>
Wenn <extensions> weggelassen wird, werden keine Erweiterungen angenommen.
4. Beispiele
Im Folgenden finden Sie einige Beispiele für LDAP-URLs, die das oben definierte Format verwenden. Das erste Beispiel ist eine LDAP-URL, die auf den Eintrag der University of Michigan verweist, der von einem LDAP-Server nach Wahl des Clients verfügbar ist:
ldap:///o=University%20of%20Michigan,c=US
Das nächste Beispiel ist eine LDAP-URL, die auf den Eintrag der University of Michigan in einem bestimmten LDAP-Server verweist:
ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
Beide URLs entsprechen einer Basisobjektsuche des Eintrags "o=University of Michigan,c=US" unter Verwendung eines Filters von "(objectclass=*)", wobei alle Attribute angefordert werden.
Das nächste Beispiel ist eine LDAP-URL, die nur auf das Attribut postalAddress des Eintrags der University of Michigan verweist:
ldap://ldap1.example.net/o=University%20of%20Michigan,
c=US?postalAddress
Die entsprechende LDAP-Suchoperation ist dieselbe wie im vorherigen Beispiel, außer dass nur das Attribut postalAddress angefordert wird.
Das nächste Beispiel ist eine LDAP-URL, die auf den Satz von Einträgen verweist, die durch Abfragen des angegebenen LDAP-Servers auf Port 6666 und Durchführen einer Teilbaumsuche der University of Michigan nach jedem Eintrag mit einem gemeinsamen Namen von "Babs Jensen" gefunden wurden, wobei alle Attribute abgerufen werden:
ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
c=US??sub?(cn=Babs%20Jensen)
Das nächste Beispiel ist eine LDAP-URL, die auf alle Kinder des Eintrags c=GB verweist:
LDAP://ldap1.example.com/c=GB?objectClass?ONE
Das Attribut objectClass wird zusammen mit den Einträgen zurückgegeben, und es wird der Standardfilter "(objectclass=*)" verwendet.
Das nächste Beispiel ist eine LDAP-URL zum Abrufen des Attributs mail für den LDAP-Eintrag mit dem Namen "o=Question?,c=US", was die Verwendung des Prozent-Codierungsmechanismus für das reservierte Zeichen '?' veranschaulicht.
ldap://ldap2.example.com/o=Question%3f,c=US?mail
Das nächste Beispiel (das zur besseren Lesbarkeit in zwei Zeilen aufgeteilt ist) veranschaulicht die Interaktion zwischen der LDAP-Zeichenfolgendarstellung des Filter-Zitier-Mechanismus und den URL-Zitier-Mechanismen.
ldap://ldap3.example.com/o=Babsco,c=US
???(four-octet=%5c00%5c00%5c00%5c04)
Der Filter in diesem Beispiel verwendet den LDAP-Maskierungsmechanismus von , um drei Null- oder Zero-Bytes im Wert zu codieren. In LDAP würde der Filter als (four-octet=\00\00\00\04) geschrieben. Da das Zeichen \ in einer URL maskiert werden muss, werden die \ in der URL-Codierung als %5c (oder %5C) prozentcodiert.
Das nächste Beispiel veranschaulicht die Interaktion zwischen der LDAP-Zeichenfolgendarstellung des DN-Zitier-Mechanismus und den URL-Zitier-Mechanismen.
ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
Der in der obigen URL codierte DN ist:
o=An Example\2C Inc.,c=US
Das heißt, der RDN-Wert ganz links ist:
An Example, Inc.
Die folgenden drei URLs sind äquivalent, vorausgesetzt, dass die in Abschnitt 3 dieses Dokuments angegebenen Standardregeln verwendet werden:
ldap://ldap.example.net
ldap://ldap.example.net/
ldap://ldap.example.net/?
Diese drei URLs verweisen auf den Root-DSE auf dem Server ldap.example.net.
Die letzten beiden Beispiele zeigen die Verwendung einer hypothetischen, experimentellen Bind-Name-Erweiterung (der mit der Erweiterung verknüpfte Wert ist ein LDAP-DN).
ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
Die beiden URLs sind gleich, außer dass die zweite die e-bindname-Erweiterung als kritisch markiert. Beachten Sie die Verwendung des Prozent-Codierungsmechanismus zum Codieren der Kommas innerhalb des Distinguished Name-Werts in der e-bindname-Erweiterung.
5. Sicherheitsüberlegungen
Die in [RFC3986] erörterten allgemeinen URL-Sicherheitsüberlegungen sind für LDAP-URLs relevant.
Die Verwendung von Sicherheitsmechanismen bei der Verarbeitung von LDAP-URLs erfordert besondere Sorgfalt, da Clients über URLs auf viele verschiedene Server stoßen können und da URLs wahrscheinlich automatisch und ohne Benutzereingriff verarbeitet werden. Ein Client SOLLTE (SHOULD) über eine vom Benutzer konfigurierbare Richtlinie verfügen, die steuert, mit welchen Servern der Client LDAP-Sitzungen aufbaut und mit welchen Sicherheitsmechanismen, und SOLLTE KEINE (SHOULD NOT) LDAP-Sitzungen aufbauen, die mit dieser Richtlinie unvereinbar sind. Wenn ein Client beschließt, eine vorhandene LDAP-Sitzung beim Auflösen einer oder mehrerer LDAP-URLs wiederzuverwenden, MUSS (MUST) er sicherstellen, dass die Sitzung mit der URL kompatibel ist und keine Sicherheitsrichtlinien verletzt werden.
Das Senden von Authentifizierungsinformationen, unabhängig vom Mechanismus, kann die Datenschutzanforderungen eines Benutzers verletzen. In Ermangelung einer spezifischen Richtlinie, die das Senden von Authentifizierungsinformationen an einen Server erlaubt, sollte ein Client eine anonyme LDAP-Sitzung verwenden. (Beachten Sie, dass Clients, die früheren LDAP-URL-Spezifikationen entsprechen, bei denen alle LDAP-Sitzungen anonym und ungeschützt sind, mit dieser Spezifikation übereinstimmen; sie haben einfach die Standardsicherheitsrichtlinie.) Das bloße Öffnen einer Transportverbindung zu einem anderen Server kann die Datenschutzanforderungen einiger Benutzer verletzen, daher sollten Clients dem Benutzer eine Möglichkeit bieten, die URL-Verarbeitung zu steuern.
Einige Authentifizierungsmethoden, insbesondere wiederverwendbare Passwörter, die an den Server gesendet werden, können dem Remote-Server oder Lauschern während der Übertragung leicht missbrauchbare Informationen preisgeben und sollten bei der URL-Verarbeitung nicht verwendet werden, es sei denn, sie sind durch die Richtlinie ausdrücklich zulässig. Die Bestätigung der Verwendung von Authentifizierungsinformationen durch den menschlichen Benutzer ist unter vielen Umständen angemessen. Die Verwendung starker Authentifizierungsmethoden, die keine sensiblen Informationen preisgeben, wird bevorzugt. Wenn die URL einen Verweis für eine Aktualisierungsoperation darstellt, SOLLTEN (SHOULD) starke Authentifizierungsmethoden verwendet werden. Weitere Informationen finden Sie im Abschnitt Sicherheitsüberlegungen von [RFC4513].
Das LDAP-URL-Format ermöglicht die Spezifikation einer beliebigen LDAP-Suchoperation, die bei der Auswertung der LDAP-URL ausgeführt werden soll. Das Verfolgen einer LDAP-URL kann zu unerwarteten Ergebnissen führen, z. B. zum Abrufen großer Datenmengen oder zum Initiieren einer langlebigen Suche. Die Sicherheitsauswirkungen der Auflösung einer LDAP-URL sind dieselben wie die der Auflösung einer LDAP-Suchabfrage.
6. Normative Verweise
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
- [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
- [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
- [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
- [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
- [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
- [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
- [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
- [RFC4515] Smith, M. Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters", RFC 4515, June 2006.
7. Informative Verweise
- [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
- [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
8. Danksagungen
Das LDAP-URL-Format wurde ursprünglich an der University of Michigan definiert. Dieses Material basiert auf Arbeiten, die von der National Science Foundation unter Grant Nr. NCR-9416667 unterstützt wurden. Die Unterstützung sowohl der University of Michigan als auch der National Science Foundation wird dankbar anerkannt.
Dieses Dokument macht RFC 2255 von Tim Howes und Mark Smith obsolet. Änderungen in dieser überarbeiteten Spezifikation basieren auf Diskussionen zwischen den Autoren, Diskussionen innerhalb der LDAP (v3) Revision Working Group (ldapbis) und Diskussionen innerhalb anderer IETF Working Groups. Die Beiträge von Einzelpersonen in diesen Arbeitsgruppen werden dankbar anerkannt. Insbesondere haben mehrere Personen wertvolle Kommentare zu diesem Dokument abgegeben: RL "Bob" Morgan, Mark Wahl, Kurt Zeilenga, Jim Sermersheim und Hallvard Furuseth verdienen besonderen Dank für ihre Beiträge.