RFC 4515 - Lightweight Directory Access Protocol (LDAP): Zeichenfolgendarstellung von Suchfiltern
- Status: Proposed Standard
- Veröffentlicht: June 2006
- Stream: IETF
- Ersetzt: RFC2254
- Errata: Keine Errata
Zusammenfassung
Lightweight Directory Access Protocol (LDAP)-Suchfilter werden im LDAP-Protokoll unter Verwendung einer binären Darstellung übertragen, die für die Verwendung im Netzwerk geeignet ist. Dieses Dokument definiert eine menschenlesbare Zeichenfolgendarstellung von LDAP-Suchfiltern, die für die Verwendung in LDAP-URLs (RFC 4516) und in anderen Anwendungen geeignet ist.
Inhaltsverzeichnis
- Einführung
- LDAP-Suchfilter-Definition
- Zeichenfolgen-Suchfilter-Definition
- Beispiele
- Sicherheitsüberlegungen
- Normative Verweise
- Informative Verweise
- Danksagungen Anhang A: Änderungen seit RFC 2254
1. Einführung
Das Lightweight Directory Access Protocol (LDAP) [RFC4510] definiert eine Netzwerkdarstellung eines Suchfilters, der an einen LDAP-Server übertragen wird. Einige Anwendungen finden es möglicherweise nützlich, eine gemeinsame Möglichkeit zu haben, diese Suchfilter in einer menschenlesbaren Form darzustellen; LDAP-URLs [RFC4516] sind ein Beispiel für eine solche Anwendung. Dieses Dokument definiert ein menschenlesbares Zeichenfolgenformat zur Darstellung des gesamten Bereichs möglicher LDAP-Version-3-Suchfilter, einschließlich erweiterter Übereinstimmungsfilter.
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 2254. Änderungen an RFC 2254 sind in Anhang A zusammengefasst.
2. LDAP-Suchfilter-Definition
Ein LDAP-Suchfilter ist in Abschnitt 4.5.1 von [RFC4511] wie folgt definiert:
Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF filter Filter,
or [1] SET SIZE (1..MAX) OF filter Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion }
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
-- initial and final can occur at most once
substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
initial [0] AssertionValue,
any [1] AssertionValue,
final [2] AssertionValue } }
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
AttributeDescription ::= LDAPString
-- Constrained to <attributedescription>
-- [RFC4512]
AttributeValue ::= OCTET STRING
MatchingRuleId ::= LDAPString
AssertionValue ::= OCTET STRING
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- [Unicode] characters
Die AttributeDescription, wie in [RFC4511] definiert, ist eine Zeichenfolgendarstellung der Attributbeschreibung, die in [RFC4512] erörtert wird. Der AttributeValue und AssertionValue OCTET STRING haben die in [RFC4517] definierte Form. Der Filter wird für die Übertragung über ein Netzwerk unter Verwendung der in [X.690] definierten Basic Encoding Rules (BER) codiert, mit den in [RFC4511] beschriebenen Vereinfachungen.
3. Zeichenfolgen-Suchfilter-Definition
Die Zeichenfolgendarstellung eines LDAP-Suchfilters ist eine Zeichenfolge von UTF-8 [RFC3629] codierten Unicode-Zeichen [Unicode], die durch die folgende Grammatik definiert ist, die der in [RFC4234] definierten ABNF-Notation folgt. Die verwendeten Produktionen, die hier nicht definiert sind, sind in Abschnitt 1.4 (Allgemeine ABNF-Produktionen) von [RFC4512] definiert, sofern nicht anders angegeben. Das Filterformat verwendet eine Präfix-Notation.
filter = LPAREN filtercomp RPAREN
filtercomp = and / or / not / item
and = AMPERSAND filterlist
or = VERTBAR filterlist
not = EXCLAMATION filter
filterlist = 1*filter
item = simple / present / substring / extensible
simple = attr filtertype assertionvalue
filtertype = equal / approx / greaterorequal / lessorequal
equal = EQUALS
approx = TILDE EQUALS
greaterorequal = RANGLE EQUALS
lessorequal = LANGLE EQUALS
extensible = ( attr [dnattrs]
[matchingrule] COLON EQUALS assertionvalue )
/ ( [dnattrs]
matchingrule COLON EQUALS assertionvalue )
present = attr EQUALS ASTERISK
substring = attr EQUALS [initial] any [final]
initial = assertionvalue
any = ASTERISK *(assertionvalue ASTERISK)
final = assertionvalue
attr = attributedescription
; The attributedescription rule is defined in
; Section 2.5 of [RFC4512].
dnattrs = COLON "dn"
matchingrule = COLON oid
assertionvalue = valueencoding
; The <valueencoding> rule is used to encode an <AssertionValue>
; from Section 4.1.6 of [RFC4511].
valueencoding = 0*(normal / escaped)
normal = UTF1SUBSET / UTFMB
escaped = ESC HEX HEX
UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F
; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
; RPAREN, ASTERISK, and ESC.
EXCLAMATION = %x21 ; exclamation mark ("!")
AMPERSAND = %x26 ; ampersand (or AND symbol) ("&")
ASTERISK = %x2A ; asterisk ("*")
COLON = %x3A ; colon (":")
VERTBAR = %x7C ; vertical bar (or pipe) ("|")
TILDE = %x7E ; tilde ("~")
Beachten Sie, dass, obwohl sowohl die <substring>- als auch die <present>-Produktionen in der obigen Grammatik das Konstrukt "attr=*" erzeugen können, dieses Konstrukt nur zur Bezeichnung eines Anwesenheitsfilters verwendet wird.
Die <valueencoding>-Regel stellt sicher, dass die gesamte Filterzeichenfolge eine gültige UTF-8-Zeichenfolge ist, und sieht vor, dass die Oktette, die die ASCII-Zeichen "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII 0x29), "" (ASCII 0x5c) und NUL (ASCII 0x00) darstellen, als Backslash "" (ASCII 0x5c) gefolgt von den zwei Hexadezimalziffern dargestellt werden, die den Wert des codierten Oktetts darstellen.
Dieser einfache Maskierungsmechanismus eliminiert Mehrdeutigkeiten bei der Filteranalyse und ermöglicht es, jeden Filter, der in LDAP dargestellt werden kann, als NUL-terminierte Zeichenfolge darzustellen. Andere Oktette, die Teil des <normal>-Satzes sind, können mit diesem Mechanismus maskiert werden, z. B. nicht druckbare ASCII-Zeichen.
Für AssertionValues, die UTF-8-Zeichendaten enthalten, wird jedes Oktett des zu maskierenden Zeichens durch einen Backslash und zwei Hex-Ziffern ersetzt, die ein einzelnes Oktett im Code des Zeichens bilden. Zum Beispiel würde der Filter, der prüft, ob das Attribut "cn" einen Wert mit dem Zeichen "" an einer beliebigen Stelle enthält, als "(cn=\2a*)" dargestellt.
Wie durch die <valueencoding>-Regel angegeben, MÜSSEN Implementierungen alle Oktette größer als 0x7F maskieren, die nicht Teil einer gültigen UTF-8-Codierungssequenz sind, wenn sie eine Zeichenfolgendarstellung eines Suchfilters generieren. Implementierungen SOLLTEN Eingabezeichenfolgen akzeptieren, die keine gültigen UTF-8-Zeichenfolgen sind. Dies ist notwendig, da RFC 2254 den Begriff "Zeichenfolgendarstellung" nicht klar definiert hat (und insbesondere nicht erwähnt hat, dass die Zeichenfolgendarstellung eines LDAP-Suchfilters eine Zeichenfolge von UTF-8-codierten Unicode-Zeichen ist).
4. Beispiele
Dieser Abschnitt enthält einige Beispiele für Suchfilter, die in dieser Notation geschrieben sind.
(cn=Babs Jensen)
(!(cn=Tim Howes))
(&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
(o=univ*of*mich*)
(seeAlso=)
Die folgenden Beispiele veranschaulichen die Verwendung von erweitertem Matching.
(cn:caseExactMatch:=Fred Flintstone)
(cn:=Betty Rubble)
(sn:dn:2.4.6.8.10:=Barney Rubble)
(o:dn:=Ace Industry)
(:1.2.3:=Wilma Flintstone)
(:DN:2.4.6.8.10:=Dino)
Das erste Beispiel zeigt die Verwendung der Matching-Regel "caseExactMatch".
Das zweite Beispiel zeigt die Verwendung einer MatchingRuleAssertion-Form ohne matchingRule.
Das dritte Beispiel veranschaulicht die Verwendung der Notation ":oid", um anzugeben, dass die durch die OID "2.4.6.8.10" identifizierte Matching-Regel beim Vergleich verwendet werden soll und dass die Attribute des Distinguished Name (DN) eines Eintrags bei der Auswertung der Übereinstimmung als Teil des Eintrags betrachtet werden sollen (angezeigt durch die Verwendung von ":dn").
Das vierte Beispiel bezeichnet eine Gleichheitsübereinstimmung, außer dass DN-Komponenten beim Vergleich als Teil des Eintrags betrachtet werden sollen.
Das fünfte Beispiel ist ein Filter, der auf jedes Attribut angewendet werden sollte, das die angegebene Matching-Regel unterstützt (da das <attr> weggelassen wurde).
Das sechste und letzte Beispiel ist ebenfalls ein Filter, der auf jedes Attribut angewendet werden sollte, das die angegebene Matching-Regel unterstützt. Attribute, die die im DN enthaltene Matching-Regel unterstützen, sollten ebenfalls berücksichtigt werden.
Die folgenden Beispiele veranschaulichen die Verwendung des Maskierungsmechanismus.
(o=Parens R Us \28for all your parenthetical needs\29)
(cn=*\2A*)
(filename=C:\5cMyFile)
(bin=\00\00\00\04)
(sn=Lu\c4\8di\c4\87)
(1.3.6.1.4.1.1466.0=\04\02\48\69)
5. Sicherheitsüberlegungen
Dieses Dokument beschreibt eine Zeichenfolgendarstellung von LDAP-Suchfiltern. Während die Darstellung selbst keine bekannten Sicherheitsauswirkungen hat, haben LDAP-Suchfilter diese. Sie werden von LDAP-Servern interpretiert, um Einträge auszuwählen, von denen Daten abgerufen werden. LDAP-Server sollten darauf achten, die von ihnen verwalteten Daten vor unbefugtem Zugriff zu schützen.
Weitere Informationen finden Sie in den Abschnitten zu Sicherheitsüberlegungen von [RFC4511] und [RFC4513].
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.
- [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.
- [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
- [Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2."
7. Informative Verweise
- [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 2006.
- [X.690] Specification of ASN.1 encoding rules: Basic, Canonical, and Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994.
8. Danksagungen
Dieses Dokument ersetzt RFC 2254 von Tim Howes. RFC 2254 war ein Produkt der IETF ASID Working Group.