RFC 4516 - Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator
- Stato: Proposed Standard
- Pubblicato: June 2006
- Stream: IETF
- Sostituisce: RFC2255
- Errata: Nessun errata
Sommario
Questo documento descrive un formato per un Uniform Resource Locator (URL) del Lightweight Directory Access Protocol (LDAP). Un URL LDAP descrive un'operazione di ricerca LDAP utilizzata per recuperare informazioni da una directory LDAP o, nel contesto di un riferimento o riferimento LDAP, un URL LDAP descrive un servizio in cui è possibile far progredire un'operazione LDAP.
Indice
- Introduzione
- Definizione dell'URL 2.1. Codifica percentuale
- Valori predefiniti per i campi dell'URL LDAP
- Esempi
- Considerazioni sulla sicurezza
- Riferimenti normativi
- Riferimenti informativi
- Ringraziamenti Appendice A: Modifiche rispetto a RFC 2255
1. Introduzione
LDAP è il Lightweight Directory Access Protocol [RFC4510]. Questo documento specifica il formato URL LDAP per la versione 3 di LDAP e chiarisce come vengono risolti gli URL LDAP. Questo documento definisce anche un meccanismo di estensione per gli URL LDAP. Questo meccanismo può essere utilizzato per fornire accesso a nuove estensioni LDAP.
Si noti che non tutti i parametri dell'operazione di ricerca LDAP descritti in [RFC4511] possono essere espressi utilizzando il formato definito in questo documento. Si noti inoltre che gli URL possono essere utilizzati per rappresentare la conoscenza di riferimento, inclusa quella per operazioni non di ricerca.
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 2255. Vedere l'Appendice A per un elenco delle modifiche rispetto a RFC 2255.
2. Definizione dell'URL
Un URL LDAP inizia con il prefisso del protocollo "ldap" ed è definito dalla seguente grammatica, seguendo la notazione ABNF definita in [RFC4234].
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 ("?")
Il prefisso "ldap" indica una voce o voci accessibili dal server LDAP in esecuzione sul nome host specificato al numero di porta specificato. Si noti che <host> può contenere indirizzi IPv6 letterali come specificato nella Sezione 3.2.2 di [RFC3986].
Il <dn> è un Distinguished Name LDAP che utilizza il formato stringa descritto in [RFC4514]. Identifica l'oggetto di base della ricerca LDAP o la destinazione di un'operazione non di ricerca.
Il costrutto <attributes> viene utilizzato per indicare quali attributi devono essere restituiti dalla voce o dalle voci.
Il costrutto <scope> viene utilizzato per specificare l'ambito della ricerca da eseguire nel server LDAP specificato. Gli ambiti consentiti sono "base" per una ricerca dell'oggetto base, "one" per una ricerca di un livello o "sub" per una ricerca nel sottoalbero.
Il <filter> viene utilizzato per specificare il filtro di ricerca da applicare alle voci all'interno dell'ambito specificato durante la ricerca. Ha il formato specificato in [RFC4515].
Il costrutto <extensions> fornisce all'URL LDAP un meccanismo di estensibilità, consentendo di estendere le capacità dell'URL in futuro. Le estensioni sono un semplice elenco separato da virgole di coppie tipo=valore, in cui la parte =valore PUÒ (MAY) essere omessa per le opzioni che non la richiedono. Ogni coppia tipo=valore è un'estensione separata. Queste estensioni URL LDAP non sono necessariamente correlate a nessuno dei meccanismi di estensione LDAP. Le estensioni possono essere supportate o non supportate dal client che risolve l'URL. Un'estensione preceduta da un carattere '!' (ASCII 0x21) è critica. Un'estensione non preceduta da un carattere '!' non è critica.
Se viene implementata un'estensione URL LDAP (ovvero, se l'implementazione la comprende ed è in grado di utilizzarla), l'implementazione DEVE (MUST) utilizzarla. Se un'estensione non è implementata ed è contrassegnata come critica, l'implementazione NON DEVE (MUST NOT) elaborare l'URL. Se un'estensione non è implementata e non è contrassegnata come critica, l'implementazione DEVE (MUST) ignorare l'estensione.
Il tipo di estensione (<extype>) PUÒ (MAY) essere specificato utilizzando il modulo OID numerico <numericoid> (ad esempio, 1.2.3.4) o il modulo descrittore <descr> (ad esempio, myLDAPURLExtension). L'uso del modulo <descr> DOVREBBE (SHOULD) essere limitato ai nomi descrittivi degli identificatori di oggetto registrati. Vedere [RFC4520] per i dettagli di registrazione e le linee guida per l'uso dei nomi descrittivi.
Nessuna estensione URL LDAP è definita in questo documento. Altri documenti o una versione futura di questo documento POSSONO (MAY) definire una o più estensioni.
2.1. Codifica percentuale
Un URL LDAP generato DEVE (MUST) essere costituito solo dal set ristretto di caratteri inclusi in una delle seguenti tre produzioni definite in [RFC3986]:
<reserved>
<unreserved>
<pct-encoded>
Le implementazioni DOVREBBERO (SHOULD) accettare altre stringhe UTF-8 valide [RFC3629] come input. Un ottetto DEVE (MUST) essere codificato utilizzando il meccanismo di codifica percentuale descritto nella sezione 2.1 di [RFC3986] in una di queste situazioni:
- L'ottetto non è nel set riservato definito nella sezione 2.2 di [RFC3986] o nel set non riservato definito nella sezione 2.3 di [RFC3986].
- È il singolo carattere riservato '?' e si verifica all'interno di un
<dn>,<filter>o altro elemento di un URL LDAP. - È un carattere virgola ',' che si verifica all'interno di un
<exvalue>.
Si noti che prima dell'applicazione del meccanismo di codifica percentuale, il componente estensioni dell'URL LDAP può contenere uno o più byte nulli (zero). Nessun altro componente può farlo.
3. Valori predefiniti per i campi dell'URL LDAP
Alcuni campi dell'URL LDAP sono facoltativi, come descritto sopra. In assenza di qualsiasi altra specifica, i seguenti valori predefiniti generali DOVREBBERO (SHOULD) essere utilizzati quando un campo è assente. Si noti che altri documenti POSSONO (MAY) specificare regole di impostazione predefinita diverse; ad esempio, la sezione 4.1.10 di [RFC4511] specifica una regola diversa per determinare il DN corretto da utilizzare quando è assente in un URL LDAP restituito come riferimento.
<host>
Se non viene fornito alcun <host>, il client deve avere una certa conoscenza a priori di un server LDAP appropriato da contattare.
<port>
La porta LDAP predefinita è la porta TCP 389.
<dn>
Se non viene fornito alcun <dn>, il valore predefinito è il DN di lunghezza zero, "".
<attributes>
Se la parte <attributes> viene omessa, dovrebbero essere richiesti tutti gli attributi utente della voce o delle voci (ad esempio, impostando il campo attributi AttributeDescriptionList nella richiesta di ricerca LDAP su un elenco NULL o utilizzando lo speciale selettore <alluserattrs> "*").
<scope>
Se <scope> viene omesso, viene assunto uno <scope> di "base".
<filter>
Se <filter> viene omesso, viene assunto un filtro di "(objectClass=*)".
<extensions>
Se <extensions> viene omesso, non vengono assunte estensioni.
4. Esempi
Di seguito sono riportati alcuni URL LDAP di esempio che utilizzano il formato definito sopra. Il primo esempio è un URL LDAP che fa riferimento alla voce dell'Università del Michigan, disponibile da un server LDAP scelto dal client:
ldap:///o=University%20of%20Michigan,c=US
L'esempio successivo è un URL LDAP che fa riferimento alla voce dell'Università del Michigan in un particolare server ldap:
ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
Entrambi questi URL corrispondono a una ricerca dell'oggetto base della voce "o=University of Michigan,c=US" utilizzando un filtro di "(objectclass=*)", richiedendo tutti gli attributi.
L'esempio successivo è un URL LDAP che fa riferimento solo all'attributo postalAddress della voce dell'Università del Michigan:
ldap://ldap1.example.net/o=University%20of%20Michigan,
c=US?postalAddress
L'operazione di ricerca LDAP corrispondente è la stessa dell'esempio precedente, tranne per il fatto che viene richiesto solo l'attributo postalAddress.
L'esempio successivo è un URL LDAP che fa riferimento all'insieme di voci trovate interrogando il server LDAP specificato sulla porta 6666 ed eseguendo una ricerca nel sottoalbero dell'Università del Michigan per qualsiasi voce con un nome comune di "Babs Jensen", recuperando tutti gli attributi:
ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
c=US??sub?(cn=Babs%20Jensen)
L'esempio successivo è un URL LDAP che fa riferimento a tutti i figli della voce c=GB:
LDAP://ldap1.example.com/c=GB?objectClass?ONE
L'attributo objectClass deve essere restituito insieme alle voci e viene utilizzato il filtro predefinito di "(objectclass=*)".
L'esempio successivo è un URL LDAP per recuperare l'attributo mail per la voce LDAP denominata "o=Question?,c=US", che illustra l'uso del meccanismo di codifica percentuale sul carattere riservato '?'.
ldap://ldap2.example.com/o=Question%3f,c=US?mail
L'esempio successivo (che è suddiviso in due righe per leggibilità) illustra l'interazione tra la rappresentazione di stringa LDAP del meccanismo di citazione dei filtri e i meccanismi di citazione degli URL.
ldap://ldap3.example.com/o=Babsco,c=US
???(four-octet=%5c00%5c00%5c00%5c04)
Il filtro in questo esempio utilizza il meccanismo di escape LDAP di \ per codificare tre byte zero o nulli nel valore. In LDAP, il filtro verrebbe scritto come (four-octet=\00\00\00\04). Poiché il carattere \ deve essere sottoposto a escape in un URL, i \ sono codificati in percentuale come %5c (o %5C) nella codifica URL.
L'esempio successivo illustra l'interazione tra la rappresentazione di stringa LDAP del meccanismo di citazione dei DN e i meccanismi di citazione degli URL.
ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
Il DN codificato nell'URL sopra è:
o=An Example\2C Inc.,c=US
Cioè, il valore RDN più a sinistra è:
An Example, Inc.
I seguenti tre URL sono equivalenti, supponendo che vengano utilizzate le regole di impostazione predefinita specificate nella Sezione 3 di questo documento:
ldap://ldap.example.net
ldap://ldap.example.net/
ldap://ldap.example.net/?
Questi tre URL puntano al DSE radice sul server ldap.example.net.
Gli ultimi due esempi mostrano l'uso di un'ipotetica estensione sperimentale del nome di associazione (il valore associato all'estensione è un DN LDAP).
ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
I due URL sono gli stessi, tranne per il fatto che il secondo contrassegna l'estensione e-bindname come critica. Notare l'uso del meccanismo di codifica percentuale per codificare le virgole all'interno del valore del nome distinto nell'estensione e-bindname.
5. Considerazioni sulla sicurezza
Le considerazioni generali sulla sicurezza degli URL discusse in [RFC3986] sono rilevanti per gli URL LDAP.
L'uso di meccanismi di sicurezza durante l'elaborazione degli URL LDAP richiede particolare attenzione, poiché i client possono incontrare molti server diversi tramite URL e poiché è probabile che gli URL vengano elaborati automaticamente, senza l'intervento dell'utente. Un client DOVREBBE (SHOULD) disporre di una politica configurabile dall'utente che controlli con quali server il client stabilirà sessioni LDAP e con quali meccanismi di sicurezza, e NON DOVREBBE (SHOULD NOT) stabilire sessioni LDAP incoerenti con questa politica. Se un client sceglie di riutilizzare una sessione LDAP esistente durante la risoluzione di uno o più URL LDAP, DEVE (MUST) garantire che la sessione sia compatibile con l'URL e che non vengano violati i criteri di sicurezza.
L'invio di informazioni di autenticazione, indipendentemente dal meccanismo, può violare i requisiti di privacy dell'utente. In assenza di una politica specifica che consenta l'invio di informazioni di autenticazione a un server, un client dovrebbe utilizzare una sessione LDAP anonima. (Si noti che i client conformi alle precedenti specifiche URL LDAP, in cui tutte le sessioni LDAP sono anonime e non protette, sono coerenti con questa specifica; hanno semplicemente la politica di sicurezza predefinita.) La semplice apertura di una connessione di trasporto verso un altro server può violare i requisiti di privacy di alcuni utenti, quindi i client dovrebbero fornire all'utente un modo per controllare l'elaborazione degli URL.
Alcuni metodi di autenticazione, in particolare le password riutilizzabili inviate al server, possono rivelare informazioni facilmente abusate al server remoto o agli intercettatori in transito e non dovrebbero essere utilizzati nell'elaborazione degli URL a meno che non siano esplicitamente consentiti dalla politica. La conferma da parte dell'utente umano dell'uso delle informazioni di autenticazione è appropriata in molte circostanze. L'uso di metodi di autenticazione forte che non rivelano informazioni sensibili è molto preferito. Se l'URL rappresenta un riferimento per un'operazione di aggiornamento, DOVREBBERO (SHOULD) essere utilizzati metodi di autenticazione forte. Fare riferimento alla sezione Considerazioni sulla sicurezza di [RFC4513] per ulteriori informazioni.
Il formato URL LDAP consente la specifica di un'operazione di ricerca LDAP arbitraria da eseguire durante la valutazione dell'URL LDAP. Seguire un URL LDAP può causare risultati imprevisti, ad esempio il recupero di grandi quantità di dati o l'avvio di una ricerca a lunga durata. Le implicazioni sulla sicurezza della risoluzione di un URL LDAP sono le stesse della risoluzione di una query di ricerca LDAP.
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.
- [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. Riferimenti informativi
- [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. Ringraziamenti
Il formato URL LDAP è stato originariamente definito presso l'Università del Michigan. Questo materiale si basa sul lavoro supportato dalla National Science Foundation con la sovvenzione n. NCR-9416667. Si riconosce con gratitudine il supporto sia dell'Università del Michigan che della National Science Foundation.
Questo documento rende obsoleta la RFC 2255 di Tim Howes e Mark Smith. Le modifiche incluse in questa specifica rivista si basano su discussioni tra gli autori, discussioni all'interno del gruppo di lavoro di revisione LDAP (v3) (ldapbis) e discussioni all'interno di altri gruppi di lavoro IETF. I contributi delle persone in questi gruppi di lavoro sono riconosciuti con gratitudine. Diverse persone in particolare hanno fornito commenti preziosi su questo documento: RL "Bob" Morgan, Mark Wahl, Kurt Zeilenga, Jim Sermersheim e Hallvard Furuseth meritano un ringraziamento speciale per i loro contributi.