Network Working Group R. Weltman
Request for Comments: 3829 America Online
Category: Informational M. Smith
Pearl Crescent, LLC
M. Wahl
July 2004
Network Working Group R. Weltman
Request for Comments: 3829 America Online
Category: Informational M. Smith
Pearl Crescent, LLC
M. Wahl
July 2004
Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls
轻型目录访问协议（LDAP）授权标识请求和响应控制
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document extends the Lightweight Directory Access Protocol (LDAP) bind operation with a mechanism for requesting and returning the authorization identity it establishes. Specifically, this document defines the Authorization Identity Request and Response controls for use with the Bind operation.
本文档使用一种机制扩展了轻量级目录访问协议（LDAP）绑定操作，该机制用于请求和返回它所建立的授权标识。具体而言，本文档定义了用于绑定操作的授权标识请求和响应控件。
This document defines support for the Authorization Identity Request Control and the Authorization Identity Response Control for requesting and returning the authorization established in a bind operation. The Authorization Identity Request Control may be submitted by a client in a bind request if authenticating with version 3 of the Lightweight Directory Access Protocol (LDAP) protocol [LDAPv3]. In the LDAP server's bind response, it may then include an Authorization Identity Response Control. The response control contains the identity assumed by the client. This is useful when there is a mapping step or other indirection during the bind, so that the client can be told what LDAP identity was granted. Client authentication with certificates is the primary situation where this applies. Also, some Simple Authentication and Security Layer [SASL] authentication mechanisms may not involve the client explicitly providing a DN, or may result in an authorization identity which is different from the authentication identity provided by the client [AUTH].
本文档定义了对授权标识请求控制和授权标识响应控制的支持，用于请求和返回绑定操作中建立的授权。如果使用轻型目录访问协议（LDAP）协议[LDAPv3]的版本3进行身份验证，则授权标识请求控制可由客户端在绑定请求中提交。在LDAP服务器的绑定响应中，它可能会包含一个授权标识响应控件。响应控件包含客户端假定的标识。当绑定过程中存在映射步骤或其他间接寻址时，这非常有用，这样可以告诉客户机授予了什么LDAP标识。使用证书的客户端身份验证是适用于此的主要情况。此外，一些简单身份验证和安全层[SASL]身份验证机制可能不涉及客户端显式提供DN，或者可能导致授权标识不同于客户端[AUTH]提供的身份验证标识。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" used in this document are to be interpreted as described in [RFCKeyWords].
本文件中使用的关键词“必须”、“不得”、“应该”、“不应该”和“可能”应按照[RFCKeyWords]中所述进行解释。
2. Publishing support for the Authorization Identity Request Control and the Authorization Identity Response Control
2. 发布对授权标识请求控件和授权标识响应控件的支持
Support for the Authorization Identity Request Control and the Authorization Identity Response Control is indicated by the presence of the Object Identifiers (OIDs) 2.16.840.1.113730.3.4.16 and 2.16.840.1.113730.3.4.15, respectively, in the supportedControl attribute [LDAPATTRS] of a server's root DSA-specific Entry (DSE).
通过在服务器根DSA特定条目（DSE）的supportedControl属性[LDAPATTRS]中分别存在对象标识符（OID）2.16.840.1.113730.3.4.16和2.16.840.1.113730.3.4.15来表示对授权标识请求控制和授权标识响应控制的支持。
This control MAY be included in any bind request which specifies protocol version 3, as part of the controls field of the LDAPMessage as defined in [LDAPPROT]. In a multi-step bind operation, the client MUST provide the control with each bind request.
此控件可以包含在指定协议版本3的任何绑定请求中，作为[LDAPROT]中定义的LDAPMessage控件字段的一部分。在多步骤绑定操作中，客户端必须为每个绑定请求提供控件。
The controlType is "2.16.840.1.113730.3.4.16" and the controlValue is absent.
controlType为“2.16.840.1.113730.3.4.16”，没有controlValue。
This control MAY be included in any final bind response where the first bind request of the bind operation included an Authorization Identity Request Control as part of the controls field of the LDAPMessage as defined in [LDAPPROT].
此控件可包含在任何最终绑定响应中，其中绑定操作的第一个绑定请求包含授权标识请求控件，作为[LDAPROT]中定义的LDAPMessage控件字段的一部分。
The controlType is "2.16.840.1.113730.3.4.15". If the bind request succeeded and resulted in an identity (not anonymous), the controlValue contains the authorization identity (authzId), as defined in [AUTH] section 9, granted to the requestor. If the bind request resulted in an anonymous association, the controlValue field is a string of zero length. If the bind request resulted in more than one authzId, the primary authzId is returned in the controlValue field.
控制类型为“2.16.840.1.113730.3.4.15”。如果绑定请求成功并产生一个标识（非匿名），则controlValue包含[AUTH]第9节中定义的授予请求者的授权标识（authzId）。如果绑定请求导致匿名关联，则controlValue字段是长度为零的字符串。如果绑定请求产生多个authzId，则在controlValue字段中返回主authzId。
The control is only included in a bind response if the resultCode for the bind operation is success.
只有当绑定操作的resultCode成功时，该控件才会包含在绑定响应中。
If the server requires confidentiality protections to be in place prior to use of this control (see Security Considerations), the server reports failure to have adequate confidentiality protections in place by returning the confidentialityRequired result code.
如果服务器在使用此控件之前要求提供保密保护（请参阅安全注意事项），则服务器将通过返回机密性要求的结果代码来报告未提供足够的保密保护。
If the client has insufficient access rights to the requested authorization information, the server reports this by returning the insufficientAccessRights result code.
如果客户端对请求的授权信息没有足够的访问权限，则服务器将通过返回insufficientAccessRights结果代码来报告此情况。
Identities presented by a client as part of the authentication process may be mapped by the server to one or more authorization identities. The bind response control can be used to retrieve the primary authzId.
作为认证过程的一部分由客户端呈现的身份可以由服务器映射到一个或多个授权身份。绑定响应控件可用于检索主authzId。
For example, during client authentication with certificates [AUTH], a client may possess more than one certificate and may not be able to determine which one was ultimately selected for authentication to the server. The subject DN field in the selected certificate may not correspond exactly to a DN in the directory, but rather have gone through a mapping process controlled by the server. Upon completing the certificate-based authentication, the client may issue a SASL [SASL] bind request, specifying the EXTERNAL mechanism and including an Authorization Identity Request Control. The bind response MAY include an Authorization Identity Response Control indicating the DN in the server's Directory Information Tree (DIT) which the certificate was mapped to.
例如，在使用证书[AUTH]进行客户端身份验证期间，客户端可能拥有多个证书，并且可能无法确定最终选择哪个证书进行服务器身份验证。所选证书中的subject DN字段可能与目录中的DN不完全对应，而是经过了由服务器控制的映射过程。在完成基于证书的认证后，客户端可以发出SASL[SASL]绑定请求，指定外部机制并包括授权标识请求控制。绑定响应可以包括授权标识响应控件，该控件指示证书映射到的服务器目录信息树（DIT）中的DN。
The LDAP "Who am I?" [AUTHZID] extended operation provides a mechanism to query the authorization identity associated with a bound connection. Using an extended operation, as opposed to a bind response control, allows a client to learn the authorization identity after the bind has established integrity and data confidentiality protections. The disadvantages of the extended operation approach are coordination issues between "Who am I?" requests, bind requests, and other requests, and that an extra operation is required to learn the authorization identity. For multithreaded or high bandwidth server application environments, the bind response approach may be preferable.
LDAP“我是谁？”[AUTHZID]扩展操作提供了一种查询与绑定连接关联的授权标识的机制。与绑定响应控制相反，使用扩展操作允许客户端在绑定建立完整性和数据机密性保护后了解授权标识。扩展操作方法的缺点是“我是谁？”请求、绑定请求和其他请求之间的协调问题，并且需要额外的操作来了解授权标识。对于多线程或高带宽服务器应用程序环境，绑定响应方法可能更可取。
The Authorization Identity Request and Response Controls are subject to standard LDAP security considerations. The controls may be passed over a secure as well as over an insecure channel. They are not protected by security layers negotiated by the bind operation.
授权标识请求和响应控制受标准LDAP安全注意事项的约束。控制可以通过安全通道传递，也可以通过不安全通道传递。它们不受绑定操作协商的安全层保护。
The response control allows for an additional authorization identity to be passed. In some deployments, these identities may contain confidential information which require privacy protection. In such deployments, a security layer should be established prior to issuing a bind request with an Authorization Identity Request Control.
响应控件允许传递额外的授权标识。在某些部署中，这些身份可能包含需要隐私保护的机密信息。在此类部署中，应在发出具有授权标识请求控制的绑定请求之前建立安全层。
The OIDs 2.16.840.1.113730.3.4.16 and 2.16.840.1.113730.3.4.15 are reserved for the Authorization Identity Request and Response Controls, respectively. The Authorization Identity Request Control has been registered as an LDAP Protocol Mechanism [IANALDAP].
OID 2.16.840.1.113730.3.4.16和2.16.840.1.113730.3.4.15分别保留用于授权标识请求和响应控制。授权标识请求控件已注册为LDAP协议机制[IANALDAP]。
[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月。
[LDAPPROT] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[LDAPPROT]Wahl，M.，Howes，T.和S.Kille，“轻量级目录访问协议（v3）”，RFC 2251，1997年12月。
[RFCKeyWords] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFCKeyWords]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]迈尔斯，J.，“简单认证和安全层（SASL）”，RFC22221997年10月。
[LDAPATTRS] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
[LDAPATTRS]Wahl，M.，Coulbeck，A.，Howes，T.和S.Kille，“轻量级目录访问协议（v3）：属性语法定义”，RFC2252，1997年12月。
[IANALDAP] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[IANALDAP]Hodges，J.和R.Morgan，“轻量级目录访问协议（v3）：技术规范”，RFC3372002年9月。
[AUTHZID] Zeilenga, K., "LDAP 'Who am I?' Operation", Work in Progress, April 2002.
[AUTHZID]Zeilenga，K.，“LDAP‘我是谁？’操作”，正在进行的工作，2002年4月。
Rob Weltman America Online 360 W. Caribbean Drive Sunnyvale, CA 94089 USA
Rob Weltman America Online美国加利福尼亚州桑尼维尔加勒比大道西360号，邮编94089
Phone: +1 650 937-3194
EMail: robw@worldspot.com
Phone: +1 650 937-3194
EMail: robw@worldspot.com
Mark Smith Pearl Crescent, LLC 447 Marlpool Drive Saline, MI 48176 USA
马克·史密斯珍珠新月有限责任公司，美国密歇根州马尔普尔大道447号，邮编：48176
Phone: +1 734 944-2856
EMail: mcs@pearlcrescent.com
Phone: +1 734 944-2856
EMail: mcs@pearlcrescent.com
Mark Wahl PO Box 90626 Austin, TX 78709-0626 USA
美国德克萨斯州奥斯汀市马克·瓦尔邮政信箱90626号，邮编78709-0626
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。