RFC 4515 - Lightweight Directory Access Protocol (LDAP): Rappresentazione in stringa dei filtri di ricerca
- Stato: Proposed Standard
- Pubblicato: June 2006
- Stream: IETF
- Sostituisce: RFC2254
- Errata: Nessun errata
Sommario
I filtri di ricerca del Lightweight Directory Access Protocol (LDAP) vengono trasmessi nel protocollo LDAP utilizzando una rappresentazione binaria appropriata per l'uso sulla rete. Questo documento definisce una rappresentazione in stringa leggibile dall'uomo dei filtri di ricerca LDAP appropriata per l'uso negli URL LDAP (RFC 4516) e in altre applicazioni.
Indice
- Introduzione
- Definizione del filtro di ricerca LDAP
- Definizione del filtro di ricerca in stringa
- Esempi
- Considerazioni sulla sicurezza
- Riferimenti normativi
- Riferimenti informativi
- Ringraziamenti Appendice A: Modifiche rispetto a RFC 2254
1. Introduzione
Il Lightweight Directory Access Protocol (LDAP) [RFC4510] definisce una rappresentazione di rete di un filtro di ricerca trasmesso a un server LDAP. Alcune applicazioni potrebbero trovare utile avere un modo comune per rappresentare questi filtri di ricerca in una forma leggibile dall'uomo; gli URL LDAP [RFC4516] sono un esempio di tale applicazione. Questo documento definisce un formato stringa leggibile dall'uomo per rappresentare l'intera gamma di possibili filtri di ricerca LDAP versione 3, inclusi i filtri di corrispondenza estesa.
Questo documento è parte integrante della specifica tecnica LDAP [RFC4510], che rende obsoleta la specifica tecnica LDAP precedentemente definita, RFC 3377, nella sua interezza.
Questo documento sostituisce RFC 2254. Le modifiche a RFC 2254 sono riassunte nell'Appendice A.
2. Definizione del filtro di ricerca LDAP
Un filtro di ricerca LDAP è definito nella Sezione 4.5.1 di [RFC4511] come segue:
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
La AttributeDescription, come definita in [RFC4511], è una rappresentazione in stringa della descrizione dell'attributo che viene discussa in [RFC4512]. La AttributeValue e AssertionValue OCTET STRING hanno la forma definita in [RFC4517]. Il filtro è codificato per la trasmissione su una rete utilizzando le regole di codifica di base (BER) definite in [X.690], con le semplificazioni descritte in [RFC4511].
3. Definizione del filtro di ricerca in stringa
La rappresentazione in stringa di un filtro di ricerca LDAP è una stringa di caratteri Unicode [Unicode] codificati in UTF-8 [RFC3629] che è definita dalla seguente grammatica, seguendo la notazione ABNF definita in [RFC4234]. Le produzioni utilizzate che non sono definite qui sono definite nella Sezione 1.4 (Produzioni ABNF comuni) di [RFC4512] se non diversamente specificato. Il formato del filtro utilizza una notazione prefissa.
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 ("~")
Si noti che sebbene entrambe le produzioni <substring> e <present> nella grammatica sopra possano produrre il costrutto "attr=*", questo costrutto viene utilizzato solo per denotare un filtro di presenza.
La regola <valueencoding> garantisce che l'intera stringa del filtro sia una stringa UTF-8 valida e prevede che gli ottetti che rappresentano i caratteri ASCII "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII 0x29), "" (ASCII 0x5c) e NUL (ASCII 0x00) siano rappresentati come una barra rovesciata "" (ASCII 0x5c) seguita dalle due cifre esadecimali che rappresentano il valore dell'ottetto codificato.
Questo semplice meccanismo di escape elimina le ambiguità di analisi del filtro e consente a qualsiasi filtro che può essere rappresentato in LDAP di essere rappresentato come una stringa con terminazione NUL. Altri ottetti che fanno parte del set <normal> possono essere sottoposti a escape utilizzando questo meccanismo, ad esempio i caratteri ASCII non stampabili.
Per AssertionValues che contengono dati di caratteri UTF-8, ogni ottetto del carattere da sottoporre a escape viene sostituito da una barra rovesciata e due cifre esadecimali, che formano un singolo ottetto nel codice del carattere. Ad esempio, il filtro che controlla se l'attributo "cn" conteneva un valore con il carattere "" ovunque in esso sarebbe rappresentato come "(cn=\2a*)".
Come indicato dalla regola <valueencoding>, le implementazioni DEVONO eseguire l'escape di tutti gli ottetti maggiori di 0x7F che non fanno parte di una sequenza di codifica UTF-8 valida quando generano una rappresentazione in stringa di un filtro di ricerca. Le implementazioni DOVREBBERO accettare come input stringhe che non sono stringhe UTF-8 valide. Ciò è necessario perché RFC 2254 non ha definito chiaramente il termine "rappresentazione in stringa" (e in particolare non ha menzionato che la rappresentazione in stringa di un filtro di ricerca LDAP è una stringa di caratteri Unicode codificati UTF-8).
4. Esempi
Questa sezione fornisce alcuni esempi di filtri di ricerca scritti utilizzando questa notazione.
(cn=Babs Jensen)
(!(cn=Tim Howes))
(&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
(o=univ*of*mich*)
(seeAlso=)
I seguenti esempi illustrano l'uso della corrispondenza estesa.
(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)
Il primo esempio mostra l'uso della regola di corrispondenza "caseExactMatch".
Il secondo esempio dimostra l'uso di una forma MatchingRuleAssertion senza matchingRule.
Il terzo esempio illustra l'uso della notazione ":oid" per indicare che la regola di corrispondenza identificata dall'OID "2.4.6.8.10" deve essere utilizzata quando si effettuano confronti e che gli attributi del nome distinto (DN) di una voce devono essere considerati parte della voce quando si valuta la corrispondenza (indicato dall'uso di ":dn").
Il quarto esempio denota una corrispondenza di uguaglianza, tranne per il fatto che i componenti DN dovrebbero essere considerati parte della voce quando si esegue la corrispondenza.
Il quinto esempio è un filtro che dovrebbe essere applicato a qualsiasi attributo che supporti la regola di corrispondenza data (poiché <attr> è stato omesso).
Il sesto e ultimo esempio è anche un filtro che dovrebbe essere applicato a qualsiasi attributo che supporti la regola di corrispondenza data. Devono essere considerati anche gli attributi che supportano la regola di corrispondenza contenuta nel DN.
I seguenti esempi illustrano l'uso del meccanismo di escape.
(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. Considerazioni sulla sicurezza
Questo documento descrive una rappresentazione in stringa dei filtri di ricerca LDAP. Sebbene la rappresentazione in sé non abbia implicazioni di sicurezza note, i filtri di ricerca LDAP lo hanno. Vengono interpretati dai server LDAP per selezionare le voci da cui vengono recuperati i dati. I server LDAP dovrebbero fare attenzione a proteggere i dati che mantengono da accessi non autorizzati.
Fare riferimento alle sezioni Considerazioni sulla sicurezza di [RFC4511] e [RFC4513] per ulteriori informazioni.
6. Riferimenti normativi
- [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. Riferimenti informativi
- [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. Ringraziamenti
Questo documento sostituisce RFC 2254 di Tim Howes. RFC 2254 era un prodotto del gruppo di lavoro IETF ASID.