Network Working Group R. Weltman
Request for Comments: 4370 Yahoo!, Inc.
Category: Standards Track February 2006
Network Working Group R. Weltman
Request for Comments: 4370 Yahoo!, Inc.
Category: Standards Track February 2006
Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control
轻量级目录访问协议（LDAP）代理授权控制
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document defines the Lightweight Directory Access Protocol (LDAP) Proxy Authorization Control. The Proxy Authorization Control allows a client to request that an operation be processed under a provided authorization identity instead of under the current authorization identity associated with the connection.
本文档定义了轻量级目录访问协议（LDAP）代理授权控制。代理授权控制允许客户端请求在提供的授权标识下而不是在与连接关联的当前授权标识下处理操作。
Proxy authorization allows a client to request that an operation be processed under a provided authorization identity instead of under the current authorization identity associated with the connection. This document defines support for proxy authorization using the Control mechanism [RFC2251]. The Lightweight Directory Access Protocol [LDAPV3] supports the use of the Simple Authentication and Security Layer [SASL] for authentication and for supplying an authorization identity distinct from the authentication identity, where the authorization identity applies to the whole LDAP session. The Proxy Authorization Control provides a mechanism for specifying an authorization identity on a per-operation basis, benefiting clients that need to perform operations efficiently on behalf of multiple users.
代理授权允许客户端请求在提供的授权标识下而不是在与连接关联的当前授权标识下处理操作。本文档定义了使用控制机制[RFC2251]对代理授权的支持。轻量级目录访问协议[LDAPV3]支持使用简单身份验证和安全层[SASL]进行身份验证，并提供不同于身份验证标识的授权标识，其中授权标识应用于整个LDAP会话。代理授权控制提供了一种基于每个操作指定授权标识的机制，有利于需要代表多个用户高效执行操作的客户端。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" used in this document are to be interpreted as described in [KEYWORDS].
本文件中使用的关键词“必须”、“不得”、“应该”、“不应该”和“可能”应按照[关键词]中所述进行解释。
Support for the Proxy Authorization Control is indicated by the presence of the Object Identifier (OID) "2.16.840.1.113730.3.4.18" in the supportedControl attribute [RFC2252] of a server's root DSA-specific Entry (DSE).
通过在服务器根DSA特定条目（DSE）的supportedControl属性[RFC2252]中存在对象标识符（OID）“2.16.840.1.113730.3.4.18”来表示对代理授权控制的支持。
A single Proxy Authorization Control may be included in any search, compare, modify, add, delete, or modify Distinguished Name (DN) or extended operation request message. The exception is any extension that causes a change in authentication, authorization, or data confidentiality [RFC2829], such as Start TLS [LDAPTLS] as part of the controls field of the LDAPMessage, as defined in [RFC2251].
任何搜索、比较、修改、添加、删除或修改可分辨名称（DN）或扩展操作请求消息中都可以包含单个代理授权控制。例外情况是导致身份验证、授权或数据机密性[RFC2829]发生更改的任何扩展，如[RFC2251]中定义的启动TLS[LDAPTLS]作为LDAPMessage控制字段的一部分。
The controlType of the proxy authorization control is "2.16.840.1.113730.3.4.18".
代理授权控制的控制类型为“2.16.840.1.113730.3.4.18”。
The criticality MUST be present and MUST be TRUE. This requirement protects clients from submitting a request that is executed with an unintended authorization identity.
关键性必须存在且必须真实。此要求可防止客户端提交使用非预期授权标识执行的请求。
Clients MUST include the criticality flag and MUST set it to TRUE. Servers MUST reject any request containing a Proxy Authorization Control without a criticality flag or with the flag set to FALSE with a protocolError error. These requirements protect clients from submitting a request that is executed with an unintended authorization identity.
客户端必须包含临界标志，并且必须将其设置为TRUE。服务器必须拒绝任何包含代理授权控制的请求，该请求没有关键性标志，或者标志设置为FALSE并带有protocolError错误。这些要求可防止客户端提交使用非预期授权标识执行的请求。
The controlValue SHALL be present and SHALL either contain an authzId [AUTH] representing the authorization identity for the request or be empty if an anonymous association is to be used.
controlValue应存在，并且应包含表示请求授权标识的authzId[AUTH]，或者如果要使用匿名关联，则应为空。
The mechanism for determining proxy access rights is specific to the server's proxy authorization policy.
确定代理访问权限的机制特定于服务器的代理授权策略。
If the requested authorization identity is recognized by the server, and the client is authorized to adopt the requested authorization identity, the request will be executed as if submitted by the proxy authorization identity; otherwise, the result code 123 is returned.
如果所请求的授权标识被服务器识别，并且客户端被授权采用所请求的授权标识，则该请求将被执行，如同由代理授权标识提交一样；否则，返回结果代码123。
One possible interaction of proxy authorization and normal access control is illustrated here. During evaluation of a search request, an entry that would have been returned for the search (if submitted by the proxy authorization identity directly) may not be returned if
这里说明了代理授权和正常访问控制的一种可能交互。在搜索请求评估期间，如果出现以下情况，则可能不会返回搜索时返回的条目（如果由代理授权标识直接提交）
the server finds that the requester does not have the right to assume the requested identity for searching the entry, even if the entry is within the scope of a search request under a base DN that does imply such rights. This means that fewer results, or no results, may be returned than would be if the proxy authorization identity issued the request directly. An example of such a case may be a system with fine-grained access control, where the proxy right requester has proxy rights at the top of a search tree, but not at or below a point or points within the tree.
服务器发现请求者无权使用请求的标识来搜索条目，即使条目在包含此类权限的基本DN下的搜索请求范围内。这意味着返回的结果可能比代理授权标识直接发出请求时少，或者没有结果。这种情况的一个示例可以是具有细粒度访问控制的系统，其中代理权请求者在搜索树的顶部具有代理权，但不在树内的一个或多个点的位置或下方。
The Proxy Authorization Control method is subject to general LDAP security considerations [RFC2251] [AUTH] [LDAPTLS]. The control may be passed over a secure channel as well as over an insecure channel.
代理授权控制方法受一般LDAP安全注意事项[RFC2251][AUTH][LDAPTLS]的约束。控制可以通过安全通道以及不安全通道传递。
The control allows for an additional authorization identity to be passed. In some deployments, these identities may contain confidential information that requires privacy protection.
该控件允许传递额外的授权标识。在某些部署中，这些身份可能包含需要隐私保护的机密信息。
Note that the server is responsible for determining if a proxy authorization request is to be honored. "Anonymous" users SHOULD NOT be allowed to assume the identity of others.
请注意，服务器负责确定是否执行代理授权请求。不应允许“匿名”用户冒充他人的身份。
The OID "2.16.840.1.113730.3.4.18" is reserved for the Proxy Authorization Control. It has been registered as an LDAP Protocol Mechanism [RFC3383].
OID“2.16.840.1.113730.3.4.18”保留用于代理授权控制。它已注册为LDAP协议机制[RFC3383]。
A result code (123) has been assigned by the IANA for the case where the server does not execute a request using the proxy authorization identity.
IANA已经为服务器不使用代理授权标识执行请求的情况分配了结果代码（123）。
Mark Smith, formerly of Netscape Communications Corp., Mark Wahl, formerly of Sun Microsystems, Inc., Kurt Zeilenga of OpenLDAP Foundation, Jim Sermersheim of Novell, and Steven Legg of Adacel have contributed with reviews of this document.
Mark Smith，前Netscape Communications Corp.，Mark Wahl，前Sun MyStand公司，OpenLDAP基金会的Kurt Zeilenga，Novell的Jim Sermersheim，和AdACEL的Steven Legg都贡献了这份文件的评论。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[LDAPV3] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[LDAPV3]Hodges，J.和R.Morgan，“轻量级目录访问协议（v3）：技术规范”，RFC3372002年9月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]迈尔斯，J.，“简单认证和安全层（SASL）”，RFC22221997年10月。
[AUTH] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan, "Authentication Methods for LDAP", RFC 2829, May 2000.
[AUTH]Wahl，M.，Alvestrand，H.，Hodges，J.，和R.Morgan，“LDAP的身份验证方法”，RFC 28292000年5月。
[LDAPTLS] Hodges, J., Morgan, R., and M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000.
[LDAPTLS]Hodges，J.，Morgan，R.，和M.Wahl，“轻量级目录访问协议（v3）：传输层安全扩展”，RFC 2830，2000年5月。
[RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251]Wahl，M.，Howes，T.，和S.Kille，“轻量级目录访问协议（v3）”，RFC 2251，1997年12月。
[RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
[RFC2252]Wahl，M.，Coulbeck，A.，Howes，T.，和S.Kille，“轻量级目录访问协议（v3）：属性语法定义”，RFC2252，1997年12月。
[RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan, "Authentication Methods for LDAP", RFC 2829, May 2000.
[RFC2829]Wahl，M.，Alvestrand，H.，Hodges，J.，和R.Morgan，“LDAP的身份验证方法”，RFC 28292000年5月。
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
[RFC3383]Zeilenga，K.，“轻量级目录访问协议（LDAP）的互联网分配号码管理局（IANA）注意事项”，BCP 64，RFC 3383，2002年9月。
Author's Address
作者地址
Rob Weltman Yahoo!, Inc. 701 First Avenue Sunnyvale, CA 94089 USA
Rob Weltman Yahoo！，美国加利福尼亚州桑尼维尔第一大道701号，邮编94089
Phone: +1 408 349-5504
EMail: robw@worldspot.com
Phone: +1 408 349-5504
EMail: robw@worldspot.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。