RFC 4516 - LDAP: 统一资源定位符
- 状态: Proposed Standard
- 发布日期: June 2006
- Stream: IETF
- 废弃了: RFC2255
- 勘误: 无勘误
Network Working Group M. Smith, Ed. Request for Comments: 4516 Pearl Crescent, LLC Obsoletes: 2255 T. Howes Category: Standards Track Opsware, Inc. June 2006
Lightweight Directory Access Protocol (LDAP):
Uniform Resource Locator
本文档状态
本文档为 Internet 社区指定了一项 Internet 标准跟踪协议,并请求讨论与改进建议.请参阅当前版 "Internet Official Protocol Standards" (STD 1) 以了解本协议的标准化状态.本文档的分发不受限制.
版权声明
Copyright (C) The Internet Society (2006).
摘要
本文档描述了轻量级目录访问协议 (Lightweight Directory Access Protocol, LDAP) 统一资源定位符 (Uniform Resource Locator, URL) 的格式.LDAP URL 描述用于从 LDAP 目录检索信息的 LDAP 搜索操作;或者,在 LDAP 转介 (referral) 或引用 (reference) 的上下文中,LDAP URL 描述可在其上继续进行 LDAP 操作的服务.
目录
- 引言
- URL 定义 2.1. 百分号编码
- LDAP URL 字段的默认值
- 示例
- 安全考虑
- 规范性引用
- 资料性引用
- 致谢 附录 A: 相对于 RFC 2255 的变更 A.1. 技术变更 A.2. 编辑变更 作者地址 完整版权声明 知识产权 致谢
1. 引言
LDAP 是轻量级目录访问协议 [RFC4510].本文档为 LDAP 版本 3 指定了 LDAP URL 格式,并阐明了如何解析 LDAP URL.本文档还定义了 LDAP URL 的扩展机制.该机制可用于提供对新 LDAP 扩展的访问.
请注意, [RFC4511] 中描述的 LDAP 搜索操作的并非所有参数都能使用本文档定义的格式来表达.还请注意, URL 可用于表示引用知识,包括非搜索操作的引用知识.
本文档是 LDAP 技术规范 [RFC4510] 的组成部分,该规范整体废弃了先前定义的 LDAP 技术规范 RFC 3377.
本文档取代 RFC 2255.相对于 RFC 2255 的变更列表见附录 A.
本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" 和 "OPTIONAL" 应按照 BCP 14 [RFC2119] 的说明进行解释.
2. URL 定义
LDAP URL 以协议前缀 "ldap" 开头,并由以下语法定义,该语法遵循 [RFC4234] 中定义的 ABNF 记法.
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 ("?")
"ldap" 前缀表示可从在给定主机名与端口号上运行的 LDAP 服务器访问的一个或多个条目.请注意, <host> 可包含 [RFC3986] 第 3.2.2 节所指定的字面 IPv6 地址.
<dn> 是使用 [RFC4514] 中描述的字符串格式的 LDAP 可分辨名称 (Distinguished Name).它标识 LDAP 搜索的基对象,或非搜索操作的目标.
<attributes> 构造用于指明应从一个或多个条目返回哪些属性.
<scope> 构造用于指定在给定 LDAP 服务器上执行的搜索范围.允许的范围是: "base" 表示基对象搜索, "one" 表示一级搜索, 或 "sub" 表示子树搜索.
<filter> 用于指定在搜索期间应用于指定范围内条目的搜索过滤器.其格式在 [RFC4515] 中指定.
<extensions> 构造为 LDAP URL 提供可扩展性机制,使 URL 的能力可在将来扩展.扩展是简单的逗号分隔的 type=value 对列表,对于不需要值的选项, =value 部分 MAY 被省略.每个 type=value 对是一个单独的扩展.这些 LDAP URL 扩展不一定与任何 LDAP 扩展机制相关.解析 URL 的客户端可以支持或不支持扩展.以 '!' 字符 (ASCII 0x21) 为前缀的扩展是关键的 (critical).不以 '!' 字符为前缀的扩展是非关键的 (non-critical).
如果实现了某个 LDAP URL 扩展 (即实现理解该扩展并能够使用它), 则实现 MUST 使用它.如果某个扩展未实现且被标记为关键, 则实现 MUST NOT 处理该 URL.如果某个扩展未实现且未被标记为关键, 则实现 MUST 忽略该扩展.
扩展类型 (<extype>) MAY 使用数值 OID <numericoid> 形式 (例如 1.2.3.4) 或描述符 <descr> 形式 (例如 myLDAPURLExtension) 来指定. <descr> 形式的使用 SHOULD 限于已注册的对象标识符描述性名称.有关描述性名称的注册详情与使用指南, 见 [RFC4520].
本文档未定义任何 LDAP URL 扩展.其他文档或本文档的未来版本 MAY 定义一个或多个扩展.
2.1. 百分号编码
生成的 LDAP URL MUST 仅由 [RFC3986] 中定义的以下三种产生式之一所包含的受限字符集组成:
<reserved>
<unreserved>
<pct-encoded>
实现 SHOULD 接受其他有效的 UTF-8 字符串 [RFC3629] 作为输入.在以下任一情况下, 八位组 MUST 使用 [RFC3986] 第 2.1 节中描述的百分号编码机制进行编码:
- 该八位组不在 [RFC3986] 第 2.2 节定义的 reserved 集合中, 也不在 [RFC3986] 第 2.3 节定义的 unreserved 集合中.
- 它是单个 Reserved 字符 '?', 并且出现在
<dn>,<filter>或 LDAP URL 的其他元素内部. - 它是出现在
<exvalue>内部的逗号字符 ','.
请注意, 在应用百分号编码机制之前, LDAP URL 的扩展组件可能包含一个或多个 null (零) 字节.其他组件不得包含.
3. LDAP URL 字段的默认值
如上所述, LDAP URL 的某些字段是可选的.在没有任何其他规范的情况下, 当某个字段缺失时, SHOULD 使用以下通用默认值.请注意, 其他文档 MAY 指定不同的默认规则; 例如, [RFC4511] 第 4.1.10 节为作为转介返回的 LDAP URL 中 DN 缺失时如何确定正确的 DN 指定了不同的规则.
<host>
若未给出 <host>, 客户端必须事先掌握应联系的适当 LDAP 服务器的相关知识.
<port>
默认 LDAP 端口是 TCP 端口 389.
<dn>
若未给出 <dn>, 默认是零长度 DN, "".
<attributes>
若省略 <attributes> 部分, 则应请求一个或多个条目的所有用户属性 (例如, 通过将 LDAP 搜索请求中的 attributes 字段 AttributeDescriptionList 设为 NULL 列表, 或使用特殊的 <alluserattrs> 选择器 "*").
<scope>
若省略 <scope>, 则假定 <scope> 为 "base".
<filter>
若省略 <filter>, 则假定过滤器为 "(objectClass=*)".
<extensions>
若省略 <extensions>, 则假定没有扩展.
4. 示例
以下是使用上文定义格式的一些 LDAP URL 示例.第一个示例是引用密歇根大学条目的 LDAP URL, 该条目可从客户端选择的 LDAP 服务器获得:
ldap:///o=University%20of%20Michigan,c=US
下一个示例是引用特定 ldap 服务器中密歇根大学条目的 LDAP URL:
ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
这两个 URL 都对应于对 "o=University of Michigan,c=US" 条目进行基对象搜索, 使用过滤器 "(objectclass=*)", 并请求所有属性.
下一个示例是仅引用密歇根大学条目的 postalAddress 属性的 LDAP URL:
ldap://ldap1.example.net/o=University%20of%20Michigan,
c=US?postalAddress
对应的 LDAP 搜索操作与前一示例相同, 只是仅请求 postalAddress 属性.
下一个示例是引用通过在端口 6666 上查询给定 LDAP 服务器, 并对密歇根大学执行子树搜索以查找 common name 为 "Babs Jensen" 的任何条目所找到的条目集合的 LDAP URL, 检索所有属性:
ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
c=US??sub?(cn=Babs%20Jensen)
下一个示例是引用 c=GB 条目的所有子条目的 LDAP URL:
LDAP://ldap1.example.com/c=GB?objectClass?ONE
请求与条目一起返回 objectClass 属性, 并使用默认过滤器 "(objectclass=*)".
下一个示例是检索名为 "o=Question?,c=US" 的 LDAP 条目的 mail 属性的 LDAP URL, 说明了对保留字符 '?' 使用百分号编码机制:
ldap://ldap2.example.com/o=Question%3f,c=US?mail
下一个示例 (为便于阅读拆成两行) 说明了过滤器引用机制的 LDAP 字符串表示与 URL 引用机制之间的交互:
ldap://ldap3.example.com/o=Babsco,c=US
???(four-octet=%5c00%5c00%5c00%5c04)
此示例中的过滤器使用 LDAP 转义机制 \ 对值中的三个零或 null 字节进行编码.在 LDAP 中, 该过滤器写为 (four-octet=\00\00\00\04).由于 \ 字符在 URL 中必须被转义, 因此在 URL 编码中 \ 被百分号编码为 %5c (或 %5C).
下一个示例说明了 DN 引用机制的 LDAP 字符串表示与 URL 引用机制之间的交互:
ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
上述 URL 中编码的 DN 是:
o=An Example\2C Inc.,c=US
也就是说, 最左侧的 RDN 值是:
An Example, Inc.
假定使用本文档第 3 节指定的默认规则, 则以下三个 URL 等价:
ldap://ldap.example.net
ldap://ldap.example.net/
ldap://ldap.example.net/?
这三个 URL 都指向 ldap.example.net 服务器上的根 DSE.
最后两个示例展示了假设的实验性 bind name 扩展的使用 (与该扩展关联的值是 LDAP DN):
ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
这两个 URL 相同, 只是第二个将 e-bindname 扩展标记为关键.请注意使用百分号编码机制对 e-bindname 扩展中可分辨名称值内的逗号进行编码.
5. 安全考虑
[RFC3986] 中讨论的一般 URL 安全考虑与 LDAP URL 相关.
在处理 LDAP URL 时使用安全机制需要特别小心, 因为客户端可能通过 URL 遇到许多不同的服务器, 并且 URL 很可能在没有用户干预的情况下被自动处理.客户端 SHOULD 具有用户可配置的策略, 以控制客户端将与哪些服务器建立 LDAP 会话以及使用哪些安全机制, 并且 SHOULD NOT 建立与该策略不一致的 LDAP 会话.如果客户端在解析一个或多个 LDAP URL 时选择重用现有 LDAP 会话, 则它 MUST 确保该会话与 URL 兼容, 并且不违反任何安全策略.
无论使用何种机制, 发送认证信息都可能违反用户的隐私要求.在没有允许向服务器发送认证信息的具体策略的情况下, 客户端应使用匿名 LDAP 会话. (请注意, 符合先前 LDAP URL 规范的客户端——其中所有 LDAP 会话都是匿名且不受保护的——与本规范一致; 它们只是具有默认安全策略.) 仅仅打开到另一服务器的传输连接就可能违反某些用户的隐私要求, 因此客户端应为用户提供控制 URL 处理的方式.
某些认证方法, 特别是发送到服务器的可重用口令, 可能向远程服务器或传输途中的窃听者泄露易于被滥用的信息, 除非策略明确允许, 否则不应在 URL 处理中使用.在许多情况下, 由人类用户确认认证信息的使用是适当的.更推荐使用不泄露敏感信息的强认证方法.如果 URL 表示更新操作的转介, 则 SHOULD 使用强认证方法.更多信息请参阅 [RFC4513] 的安全考虑一节.
LDAP URL 格式允许在对 LDAP URL 求值时指定要执行的任意 LDAP 搜索操作.跟随 LDAP URL 可能导致意外结果, 例如检索大量数据或启动长时间运行的搜索.解析 LDAP URL 的安全影响与解析 LDAP 搜索查询相同.
6. 规范性引用
- [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. 资料性引用
- [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. 致谢
LDAP URL 格式最初在密歇根大学定义.本材料基于国家科学基金会 (National Science Foundation) 在 Grant No. NCR-9416667 下支持的工作.谨此感谢密歇根大学与国家科学基金会的支持.
本文档废弃了 Tim Howes 与 Mark Smith 的 RFC 2255.本修订规范中包含的变更基于作者之间的讨论, LDAP (v3) Revision Working Group (ldapbis) 内部的讨论, 以及其他 IETF Working Group 内部的讨论.谨此感谢这些工作组中个人的贡献.尤其是以下人员对本文件提出了宝贵意见: RL "Bob" Morgan, Mark Wahl, Kurt Zeilenga, Jim Sermersheim 与 Hallvard Furuseth, 特此致谢.
附录 A: 相对于 RFC 2255 的变更
A.1. 技术变更
对 "URL 定义" 一节的内容做了以下技术变更:
修订了所有 ABNF, 以使用 [RFC4512] 中的公共产生式.
将引用 [RFC2396] 替换为引用 [RFC3986] (这允许在 URL 的 <host> 部分内使用字面 IPv6 地址, 并添加了注释以提醒读者注意此项增强).引用 [RFC3986] 要求对 ABNF 与文本进行更改, 以便不再使用 [RFC3986] 中未定义的产生式.例如, <hostport> 不是由 [RFC3986] 定义的, 因此已被替换为 host [COLON port].请注意, [RFC3986] 包含对 "Reserved" 与 "Unreserved" 字符集的新定义, 最终结果是, 当以下两个额外字符出现在用于构造 LDAP URL 的数据中的任何位置时, 应当进行百分号编码: "[" 与 "]" (这两个字符首先由 RFC 2732 加入 Reserved 集合).
更改了 <attrdesc> 的定义, 以引用 [RFC4511] 中的 <attributeSelector>.这允许在 URL 的 <attrdesc> 部分使用 "*".据信 RFC 2255 的现有实现已经支持这一点.
避免在 <dn>, <host>, <attrdesc> 与 <exvalue> 规则中使用 <prose-val> (方括号字符串) 产生式.
更改了 <ldapurl> 的 ABNF, 将 <dn> 组件与其前的 <SLASH> 分组在一起.
将 <extype> 规则更改为来自 [RFC4512] 的 <oid>.
更改了关于扩展类型的文本, 使其引用 [RFC4520].重新排列了规则顺序, 使其更贴近元素在 URL 中出现的顺序.
"Bindname Extension": 因缺乏已知实现而移除.
A.2. 编辑变更
更改文档标题以包含 "LDAP:" 前缀.
IESG Note: 移除了关于缺乏令人满意的强制认证机制的说明.
"Status of this Memo" 一节: 更新样板文本以符合当前 I-D 指南.
"Abstract" 一节: 与引言材料分离.
"Table of Contents" 与 "Intellectual Property" 一节: 已添加.
"Introduction" 一节: 新章节; 与摘要分离.更改文本以表明本文档取代 RFC 2255 (而不是 RFC 1959).添加文本以表明 LDAP URL 用于引用与转介.修正笔误 (将无意义短语 "to perform to retrieve" 替换为 "used to retrieve").添加注释, 让读者知道 [RFC4511] 中描述的 LDAP 搜索操作的并非所有参数都能使用此格式表达.
"URL Definition" 一节: 移除了第二份 <ldapurl> 语法及其后两段 (RFC 2255 中的编辑错误).修正了 '!' 序列内的换行.重新格式化 ABNF 以提高可读性, 对齐注释并添加一些空行.在紧接 ABNF 之后的句子中, 将 "residing in the LDAP server" 替换为 "accessible from the LDAP server".移除了句子 "Individual attrdesc names are as defined for AttributeDescription in [RFC4511].", 因为现在在 ABNF 中直接使用 [RFC4511] 的 <attributeSelector>.重写了最后一段, 以澄清哪些字符必须进行百分号编码.添加文本以表明 LDAP URL 用于引用与转介.添加引用 RFC 4234 的 ABNF 的文本.澄清并加强了关于处理包含已实现与未实现扩展的 URL 的要求 (现在的方法与 [RFC4511] 为 LDAP 控件指定的方法密切匹配).
"Defaults for Fields of the LDAP URL" 一节: 已添加; 通过将关于默认值的文本从 "URL Definition" 一节移出而形成.将对属性名 "" 的直接引用替换为对 [RFC4511] 中定义的特殊 <alluserattrs> 选择器 "" 的引用.
"URL Processing" 一节: 已移除.
"Examples" 一节: 修改示例以使用 example.com 与 example.net 主机名.在其过滤器包含三个 null 字节的 LDAP URL 示例中添加了缺失的 '?'.移除了 DN 中某个逗号后的空格.修订 bindname 示例以使用 e-bindname.将一个示例中使用的属性名从 "int" 更改为 "four-octet", 以避免潜在混淆.添加了演示 DN 转义与 URL 百分号编码之间交互的示例.添加了一些示例以展示相对于 URL 的 <dn> 部分的 URL 等价性.在某些示例中使用大写, 以提醒读者某些记号不区分大小写.
"Security Considerations" 一节: 添加了关于连接重用的说明.添加了关于更新操作使用强认证方法的说明.添加了对 [RFC4513] 的引用.添加了说明: 仅仅打开连接就可能违反某些用户的隐私要求.采用工作组修订的 LDAP 术语规范, 将 "connection" 一词酌情替换为 "LDAP session" 或 "LDAP connection".
"Acknowledgements" 一节: 添加了本文档废弃 RFC 2255 的声明.添加了 Kurt Zeilenga, Jim Sermersheim 与 Hallvard Furuseth.
"Normative References" 一节: 按新 RFC 指南从 "References" 重命名.在整篇文档中将 [1] 风格更改为 [RFC4511] 风格.添加了对 RFC 4234 与 RFC 3629 的引用.将所有 RFC 1738 引用更新为指向 [RFC3986] 中的相应章节.将 LDAP 引用更新为指向 LDAPBis WG 文档.移除了对 LDAP Attribute Syntaxes 文档的引用, 并添加了对 [RFC4513], [RFC4520] 与 [RFC4510] 文档的引用.
"Informative References" 一节: 已添加.
页眉与 "Authors' Addresses" 一节: 在 Mark Smith 的姓名旁添加了 "editor".更新了所属单位与联系信息.
版权: 更新了年份.
全文: 在描述性文本中使用 ABNF 产生式名称时, 用 "<" 与 ">" 将其括起.
作者地址
Mark Smith, Editor
Pearl Crescent, LLC
447 Marlpool Dr.
Saline, MI 48176
USA
Phone: +1 734 944-2856
EMail: [email protected]
Tim Howes
Opsware, Inc.
599 N. Mathilda Ave.
Sunnyvale, CA 94085
USA
Phone: +1 408 744-7509
EMail: [email protected]
完整版权声明
Copyright (C) The Internet Society (2006).
本文档受 BCP 78 中所含权利, 许可与限制的约束; 除其中另有规定外, 作者保留其所有权利.
本文档及其中所含信息按 "AS IS" 基础提供, 贡献者, 其所代表或赞助的组织 (如有), INTERNET SOCIETY 以及 INTERNET ENGINEERING TASK FORCE 否认所有明示或暗示的保证, 包括但不限于对本文所含信息的使用不侵犯任何权利的任何保证, 或对特定用途的适销性或适用性的任何暗示保证.
知识产权
IETF 对可能被主张与本文档所述技术的实现或使用有关的任何知识产权或其他权利的有效性或范围, 或此类权利下的任何许可是否可能可用, 不采取任何立场; 也不表示已做出任何独立努力以识别任何此类权利.有关 RFC 文档中权利程序的信息, 见 BCP 78 与 BCP 79.
向 IETF 秘书处做出的 IPR 披露副本, 以及关于将提供许可的任何保证, 或实现者或本规范用户为使用此类专有权利而试图获得一般许可或许可的结果, 可从 IETF 在线 IPR 知识库 http://www.ietf.org/ipr 获得.
IETF 邀请任何相关方提请其注意可能涵盖实现本标准所需技术的任何版权, 专利或专利申请, 或其他专有权利.请将信息发送至 IETF: [email protected].
致谢
RFC Editor 职能的资金由 IETF Administrative Support Activity (IASA) 提供.
相关资源
- 官方文本: RFC 4516
- 官方页面: RFC 4516 DataTracker