RFC 4515 - Lightweight Directory Access Protocol (LDAP) : Représentation sous forme de chaîne des filtres de recherche
- Statut: Proposed Standard
- Publié: June 2006
- Stream: IETF
- Remplace: RFC2254
- Errata: Pas d'errata
Résumé
Les filtres de recherche du protocole LDAP (Lightweight Directory Access Protocol) sont transmis dans le protocole LDAP en utilisant une représentation binaire appropriée pour une utilisation sur le réseau. Ce document définit une représentation sous forme de chaîne lisible par l'homme des filtres de recherche LDAP, appropriée pour une utilisation dans les URL LDAP (RFC 4516) et dans d'autres applications.
Table des matières
- Introduction
- Définition du filtre de recherche LDAP
- Définition du filtre de recherche sous forme de chaîne
- Exemples
- Considérations de sécurité
- Références normatives
- Références informatives
- Remerciements Annexe A : Changements depuis la RFC 2254
1. Introduction
Le protocole LDAP (Lightweight Directory Access Protocol) [RFC4510] définit une représentation réseau d'un filtre de recherche transmis à un serveur LDAP. Certaines applications peuvent trouver utile d'avoir un moyen commun de représenter ces filtres de recherche sous une forme lisible par l'homme ; les URL LDAP [RFC4516] sont un exemple d'une telle application. Ce document définit un format de chaîne lisible par l'homme pour représenter la gamme complète des filtres de recherche LDAP version 3 possibles, y compris les filtres de correspondance étendue.
Ce document fait partie intégrante de la spécification technique LDAP [RFC4510], qui rend obsolète la spécification technique LDAP précédemment définie, RFC 3377, dans son intégralité.
Ce document remplace la RFC 2254. Les modifications apportées à la RFC 2254 sont résumées à l'annexe A.
2. Définition du filtre de recherche LDAP
Un filtre de recherche LDAP est défini dans la section 4.5.1 de [RFC4511] comme suit :
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
L'AttributeDescription, telle que définie dans [RFC4511], est une représentation sous forme de chaîne de la description d'attribut qui est discutée dans [RFC4512]. L'AttributeValue et l'AssertionValue OCTET STRING ont la forme définie dans [RFC4517]. Le filtre est codé pour la transmission sur un réseau en utilisant les règles de codage de base (BER) définies dans [X.690], avec les simplifications décrites dans [RFC4511].
3. Définition du filtre de recherche sous forme de chaîne
La représentation sous forme de chaîne d'un filtre de recherche LDAP est une chaîne de caractères Unicode [Unicode] encodés en UTF-8 [RFC3629] qui est définie par la grammaire suivante, suivant la notation ABNF définie dans [RFC4234]. Les productions utilisées qui ne sont pas définies ici sont définies dans la section 1.4 (Productions ABNF communes) de [RFC4512], sauf indication contraire. Le format de filtre utilise une notation préfixée.
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 ("~")
Notez que bien que les productions <substring> et <present> dans la grammaire ci-dessus puissent produire la construction "attr=*", cette construction n'est utilisée que pour désigner un filtre de présence.
La règle <valueencoding> garantit que la chaîne de filtre entière est une chaîne UTF-8 valide et prévoit que les octets représentant les caractères ASCII "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII 0x29), "" (ASCII 0x5c) et NUL (ASCII 0x00) sont représentés par une barre oblique inverse "" (ASCII 0x5c) suivie des deux chiffres hexadécimaux représentant la valeur de l'octet codé.
Ce mécanisme d'échappement simple élimine les ambiguïtés d'analyse des filtres et permet à tout filtre pouvant être représenté dans LDAP d'être représenté sous forme de chaîne terminée par NUL. D'autres octets faisant partie de l'ensemble <normal> peuvent être échappés à l'aide de ce mécanisme, par exemple les caractères ASCII non imprimables.
Pour les AssertionValues qui contiennent des données de caractères UTF-8, chaque octet du caractère à échapper est remplacé par une barre oblique inverse et deux chiffres hexadécimaux, qui forment un seul octet dans le code du caractère. Par exemple, le filtre vérifiant si l'attribut "cn" contenait une valeur avec le caractère "" n'importe où serait représenté par "(cn=\2a*)".
Comme indiqué par la règle <valueencoding>, les implémentations DOIVENT échapper tous les octets supérieurs à 0x7F qui ne font pas partie d'une séquence de codage UTF-8 valide lorsqu'elles génèrent une représentation sous forme de chaîne d'un filtre de recherche. Les implémentations DEVRAIENT accepter en entrée des chaînes qui ne sont pas des chaînes UTF-8 valides. Ceci est nécessaire car la RFC 2254 n'a pas clairement défini le terme "représentation sous forme de chaîne" (et en particulier n'a pas mentionné que la représentation sous forme de chaîne d'un filtre de recherche LDAP est une chaîne de caractères Unicode encodés en UTF-8).
4. Exemples
Cette section donne quelques exemples de filtres de recherche écrits à l'aide de cette notation.
(cn=Babs Jensen)
(!(cn=Tim Howes))
(&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
(o=univ*of*mich*)
(seeAlso=)
Les exemples suivants illustrent l'utilisation de la correspondance étendue.
(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)
Le premier exemple montre l'utilisation de la règle de correspondance "caseExactMatch".
Le deuxième exemple montre l'utilisation d'une forme MatchingRuleAssertion sans matchingRule.
Le troisième exemple illustre l'utilisation de la notation ":oid" pour indiquer que la règle de correspondance identifiée par l'OID "2.4.6.8.10" doit être utilisée lors des comparaisons, et que les attributs du nom distinctif (DN) d'une entrée doivent être considérés comme faisant partie de l'entrée lors de l'évaluation de la correspondance (indiqué par l'utilisation de ":dn").
Le quatrième exemple désigne une correspondance d'égalité, sauf que les composants DN doivent être considérés comme faisant partie de l'entrée lors de la correspondance.
Le cinquième exemple est un filtre qui doit être appliqué à tout attribut prenant en charge la règle de correspondance donnée (puisque <attr> a été omis).
Le sixième et dernier exemple est également un filtre qui doit être appliqué à tout attribut prenant en charge la règle de correspondance donnée. Les attributs prenant en charge la règle de correspondance contenue dans le DN doivent également être pris en compte.
Les exemples suivants illustrent l'utilisation du mécanisme d'échappement.
(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. Considérations de sécurité
Ce document décrit une représentation sous forme de chaîne des filtres de recherche LDAP. Bien que la représentation elle-même n'ait aucune implication de sécurité connue, les filtres de recherche LDAP en ont. Ils sont interprétés par les serveurs LDAP pour sélectionner les entrées à partir desquelles les données sont récupérées. Les serveurs LDAP doivent veiller à protéger les données qu'ils conservent contre tout accès non autorisé.
Veuillez vous référer aux sections Considérations de sécurité de [RFC4511] et [RFC4513] pour plus d'informations.
6. Références normatives
- [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. Références informatives
- [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. Remerciements
Ce document remplace la RFC 2254 par Tim Howes. La RFC 2254 était un produit du groupe de travail IETF ASID.