RFC 4516 - Lightweight Directory Access Protocol (LDAP) : Uniform Resource Locator
- Statut: Proposed Standard
- Publié: June 2006
- Stream: IETF
- Remplace: RFC2255
- Errata: Pas d'errata
Résumé
Ce document décrit un format pour un localisateur de ressources uniformes (URL) du protocole LDAP (Lightweight Directory Access Protocol). Une URL LDAP décrit une opération de recherche LDAP utilisée pour récupérer des informations d'un annuaire LDAP ou, dans le contexte d'un renvoi ou d'une référence LDAP, une URL LDAP décrit un service où une opération LDAP peut être poursuivie.
Table des matières
- Introduction
- Définition de l'URL 2.1. Encodage en pourcentage
- Valeurs par défaut pour les champs de l'URL LDAP
- Exemples
- Considérations de sécurité
- Références normatives
- Références informatives
- Remerciements Annexe A : Changements depuis la RFC 2255
1. Introduction
LDAP est le protocole d'accès aux annuaires légers (Lightweight Directory Access Protocol) [RFC4510]. Ce document spécifie le format d'URL LDAP pour la version 3 de LDAP et clarifie la manière dont les URL LDAP sont résolues. Ce document définit également un mécanisme d'extension pour les URL LDAP. Ce mécanisme peut être utilisé pour fournir un accès aux nouvelles extensions LDAP.
Notez que tous les paramètres de l'opération de recherche LDAP décrits dans [RFC4511] ne peuvent pas être exprimés en utilisant le format défini dans ce document. Notez également que les URL peuvent être utilisées pour représenter des connaissances de référence, y compris celles pour des opérations autres que la recherche.
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 2255. Voir l'annexe A pour une liste des changements par rapport à la RFC 2255.
2. Définition de l'URL
Une URL LDAP commence par le préfixe de protocole "ldap" et est définie par la grammaire suivante, suivant la notation ABNF définie dans [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 ("?")
Le préfixe "ldap" indique une ou plusieurs entrées accessibles à partir du serveur LDAP exécuté sur le nom d'hôte donné au numéro de port donné. Notez que <host> peut contenir des adresses IPv6 littérales comme spécifié dans la section 3.2.2 de [RFC3986].
Le <dn> est un nom distinctif LDAP utilisant le format de chaîne décrit dans [RFC4514]. Il identifie l'objet de base de la recherche LDAP ou la cible d'une opération autre que la recherche.
La construction <attributes> est utilisée pour indiquer quels attributs doivent être retournés à partir de l'entrée ou des entrées.
La construction <scope> est utilisée pour spécifier la portée de la recherche à effectuer dans le serveur LDAP donné. Les portées autorisées sont "base" pour une recherche d'objet de base, "one" pour une recherche d'un niveau, ou "sub" pour une recherche de sous-arbre.
Le <filter> est utilisé pour spécifier le filtre de recherche à appliquer aux entrées dans la portée spécifiée pendant la recherche. Il a le format spécifié dans [RFC4515].
La construction <extensions> fournit à l'URL LDAP un mécanisme d'extensibilité, permettant d'étendre les capacités de l'URL à l'avenir. Les extensions sont une simple liste séparée par des virgules de paires type=valeur, où la partie =valeur PEUT être omise pour les options qui ne la nécessitent pas. Chaque paire type=valeur est une extension distincte. Ces extensions d'URL LDAP ne sont pas nécessairement liées aux mécanismes d'extension LDAP. Les extensions peuvent être prises en charge ou non par le client résolvant l'URL. Une extension préfixée par un caractère '!' (ASCII 0x21) est critique. Une extension non préfixée par un caractère '!' est non critique.
Si une extension d'URL LDAP est implémentée (c'est-à-dire si l'implémentation la comprend et est capable de l'utiliser), l'implémentation DOIT l'utiliser. Si une extension n'est pas implémentée et est marquée comme critique, l'implémentation NE DOIT PAS traiter l'URL. Si une extension n'est pas implémentée et n'est pas marquée comme critique, l'implémentation DOIT ignorer l'extension.
Le type d'extension (<extype>) PEUT être spécifié en utilisant la forme numérique OID <numericoid> (par exemple, 1.2.3.4) ou la forme descripteur <descr> (par exemple, myLDAPURLExtension). L'utilisation de la forme <descr> DEVRAIT être limitée aux noms descriptifs d'identificateurs d'objets enregistrés. Voir [RFC4520] pour les détails d'enregistrement et les directives d'utilisation des noms descriptifs.
Aucune extension d'URL LDAP n'est définie dans ce document. D'autres documents ou une future version de ce document PEUVENT définir une ou plusieurs extensions.
2.1. Encodage en pourcentage
Une URL LDAP générée DOIT être constituée uniquement de l'ensemble restreint de caractères inclus dans l'une des trois productions suivantes définies dans [RFC3986] :
<reserved>
<unreserved>
<pct-encoded>
Les implémentations DEVRAIENT accepter d'autres chaînes UTF-8 valides [RFC3629] en entrée. Un octet DOIT être encodé en utilisant le mécanisme d'encodage en pourcentage décrit dans la section 2.1 de [RFC3986] dans l'une de ces situations :
- L'octet n'est pas dans l'ensemble réservé défini dans la section 2.2 de [RFC3986] ou dans l'ensemble non réservé défini dans la section 2.3 de [RFC3986].
- C'est le caractère réservé unique '?' et il apparaît à l'intérieur d'un
<dn>,<filter>, ou autre élément d'une URL LDAP. - C'est un caractère virgule ',' qui apparaît à l'intérieur d'une
<exvalue>.
Notez qu'avant l'application du mécanisme d'encodage en pourcentage, le composant extensions de l'URL LDAP peut contenir un ou plusieurs octets nuls (zéro). Aucun autre composant ne le peut.
3. Valeurs par défaut pour les champs de l'URL LDAP
Certains champs de l'URL LDAP sont facultatifs, comme décrit ci-dessus. En l'absence de toute autre spécification, les valeurs par défaut générales suivantes DEVRAIENT être utilisées lorsqu'un champ est absent. Notez que d'autres documents PEUVENT spécifier des règles de défaut différentes ; par exemple, la section 4.1.10 de [RFC4511] spécifie une règle différente pour déterminer le DN correct à utiliser lorsqu'il est absent dans une URL LDAP renvoyée en tant que référence.
<host>
Si aucun <host> n'est donné, le client doit avoir une connaissance a priori d'un serveur LDAP approprié à contacter.
<port>
Le port LDAP par défaut est le port TCP 389.
<dn>
Si aucun <dn> n'est donné, la valeur par défaut est le DN de longueur nulle, "".
<attributes>
Si la partie <attributes> est omise, tous les attributs utilisateur de l'entrée ou des entrées devraient être demandés (par exemple, en définissant le champ d'attributs AttributeDescriptionList dans la demande de recherche LDAP sur une liste NULL, ou en utilisant le sélecteur spécial <alluserattrs> "*").
<scope>
Si <scope> est omis, un <scope> de "base" est supposé.
<filter>
Si <filter> est omis, un filtre de "(objectClass=*)" est supposé.
<extensions>
Si <extensions> est omis, aucune extension n'est supposée.
4. Exemples
Ce qui suit sont quelques exemples d'URL LDAP qui utilisent le format défini ci-dessus. Le premier exemple est une URL LDAP faisant référence à l'entrée de l'Université du Michigan, disponible à partir d'un serveur LDAP choisi par le client :
ldap:///o=University%20of%20Michigan,c=US
L'exemple suivant est une URL LDAP faisant référence à l'entrée de l'Université du Michigan dans un serveur ldap particulier :
ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
Ces deux URL correspondent à une recherche d'objet de base de l'entrée "o=University of Michigan,c=US" utilisant un filtre de "(objectclass=*)", demandant tous les attributs.
L'exemple suivant est une URL LDAP faisant référence uniquement à l'attribut postalAddress de l'entrée de l'Université du Michigan :
ldap://ldap1.example.net/o=University%20of%20Michigan,
c=US?postalAddress
L'opération de recherche LDAP correspondante est la même que dans l'exemple précédent, sauf que seul l'attribut postalAddress est demandé.
L'exemple suivant est une URL LDAP faisant référence à l'ensemble des entrées trouvées en interrogeant le serveur LDAP donné sur le port 6666 et en effectuant une recherche de sous-arbre de l'Université du Michigan pour toute entrée avec un nom commun de "Babs Jensen", récupérant tous les attributs :
ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
c=US??sub?(cn=Babs%20Jensen)
L'exemple suivant est une URL LDAP faisant référence à tous les enfants de l'entrée c=GB :
LDAP://ldap1.example.com/c=GB?objectClass?ONE
L'attribut objectClass est demandé pour être renvoyé avec les entrées, et le filtre par défaut de "(objectclass=*)" est utilisé.
L'exemple suivant est une URL LDAP pour récupérer l'attribut mail pour l'entrée LDAP nommée "o=Question?,c=US", illustrant l'utilisation du mécanisme d'encodage en pourcentage sur le caractère réservé '?'.
ldap://ldap2.example.com/o=Question%3f,c=US?mail
L'exemple suivant (qui est divisé en deux lignes pour la lisibilité) illustre l'interaction entre la représentation de chaîne LDAP du mécanisme de citation des filtres et les mécanismes de citation d'URL.
ldap://ldap3.example.com/o=Babsco,c=US
???(four-octet=%5c00%5c00%5c00%5c04)
Le filtre dans cet exemple utilise le mécanisme d'échappement LDAP de \ pour encoder trois octets zéro ou nul dans la valeur. En LDAP, le filtre serait écrit comme (four-octet=\00\00\00\04). Parce que le caractère \ doit être échappé dans une URL, les \ sont encodés en pourcentage comme %5c (ou %5C) dans l'encodage de l'URL.
L'exemple suivant illustre l'interaction entre la représentation de chaîne LDAP du mécanisme de citation des DN et les mécanismes de citation d'URL.
ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
Le DN encodé dans l'URL ci-dessus est :
o=An Example\2C Inc.,c=US
C'est-à-dire que la valeur RDN la plus à gauche est :
An Example, Inc.
Les trois URL suivantes sont équivalentes, en supposant que les règles de défaut spécifiées dans la section 3 de ce document sont utilisées :
ldap://ldap.example.net
ldap://ldap.example.net/
ldap://ldap.example.net/?
Ces trois URL pointent vers le DSE racine sur le serveur ldap.example.net.
Les deux derniers exemples montrent l'utilisation d'une extension hypothétique et expérimentale de nom de liaison (la valeur associée à l'extension est un DN LDAP).
ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
Les deux URL sont les mêmes, sauf que la seconde marque l'extension e-bindname comme critique. Notez l'utilisation du mécanisme d'encodage en pourcentage pour encoder les virgules dans la valeur du nom distinctif dans l'extension e-bindname.
5. Considérations de sécurité
Les considérations générales de sécurité des URL discutées dans [RFC3986] sont pertinentes pour les URL LDAP.
L'utilisation de mécanismes de sécurité lors du traitement des URL LDAP nécessite une attention particulière, car les clients peuvent rencontrer de nombreux serveurs différents via des URL, et comme les URL sont susceptibles d'être traitées automatiquement, sans intervention de l'utilisateur. Un client DEVRAIT avoir une politique configurable par l'utilisateur qui contrôle avec quels serveurs le client établira des sessions LDAP et avec quels mécanismes de sécurité, et NE DEVRAIT PAS établir de sessions LDAP qui sont incompatibles avec cette politique. Si un client choisit de réutiliser une session LDAP existante lors de la résolution d'une ou plusieurs URL LDAP, il DOIT s'assurer que la session est compatible avec l'URL et qu'aucune politique de sécurité n'est violée.
L'envoi d'informations d'authentification, quel que soit le mécanisme, peut violer les exigences de confidentialité d'un utilisateur. En l'absence de politique spécifique permettant l'envoi d'informations d'authentification à un serveur, un client devrait utiliser une session LDAP anonyme. (Notez que les clients conformes aux spécifications d'URL LDAP précédentes, où toutes les sessions LDAP sont anonymes et non protégées, sont conformes à cette spécification ; ils ont simplement la politique de sécurité par défaut.) Le simple fait d'ouvrir une connexion de transport vers un autre serveur peut violer les exigences de confidentialité de certains utilisateurs, les clients devraient donc fournir à l'utilisateur un moyen de contrôler le traitement des URL.
Certaines méthodes d'authentification, en particulier les mots de passe réutilisables envoyés au serveur, peuvent révéler des informations facilement abusées au serveur distant ou aux espions en transit et ne devraient pas être utilisées dans le traitement des URL à moins qu'elles ne soient explicitement autorisées par la politique. La confirmation par l'utilisateur humain de l'utilisation des informations d'authentification est appropriée dans de nombreuses circonstances. L'utilisation de méthodes d'authentification fortes qui ne révèlent pas d'informations sensibles est de loin préférable. Si l'URL représente un renvoi pour une opération de mise à jour, des méthodes d'authentification fortes DEVRAIENT être utilisées. Veuillez vous référer à la section Considérations de sécurité de [RFC4513] pour plus d'informations.
Le format d'URL LDAP permet de spécifier une opération de recherche LDAP arbitraire à effectuer lors de l'évaluation de l'URL LDAP. Suivre une URL LDAP peut entraîner des résultats inattendus, par exemple, la récupération de grandes quantités de données ou le lancement d'une recherche de longue durée. Les implications de sécurité de la résolution d'une URL LDAP sont les mêmes que celles de la résolution d'une requête de recherche LDAP.
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.
- [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. Références informatives
- [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. Remerciements
Le format d'URL LDAP a été défini à l'origine à l'Université du Michigan. Ce matériel est basé sur des travaux soutenus par la National Science Foundation sous la subvention n° NCR-9416667. Le soutien de l'Université du Michigan et de la National Science Foundation est reconnu avec gratitude.
Ce document rend obsolète la RFC 2255 de Tim Howes et Mark Smith. Les changements inclus dans cette spécification révisée sont basés sur des discussions entre les auteurs, des discussions au sein du groupe de travail de révision LDAP (v3) (ldapbis) et des discussions au sein d'autres groupes de travail de l'IETF. Les contributions des individus dans ces groupes de travail sont reconnues avec gratitude. Plusieurs personnes en particulier ont fait des commentaires précieux sur ce document : RL "Bob" Morgan, Mark Wahl, Kurt Zeilenga, Jim Sermersheim et Hallvard Furuseth méritent des remerciements particuliers pour leurs contributions.