Network Working Group K. Zeilenga
Request for Comments: 4532 OpenLDAP Foundation
Category: Standards Track June 2006
Network Working Group K. Zeilenga
Request for Comments: 4532 OpenLDAP Foundation
Category: Standards Track June 2006
Lightweight Directory Access Protocol (LDAP) "Who am I?" Operation
轻型目录访问协议（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 specification provides a mechanism for Lightweight Directory Access Protocol (LDAP) clients to obtain the authorization identity the server has associated with the user or application entity. This mechanism is specified as an LDAP extended operation called the LDAP "Who am I?" operation.
此规范为轻型目录访问协议（LDAP）客户端提供了一种机制，以获取服务器与用户或应用程序实体关联的授权标识。该机制被指定为LDAP扩展操作，称为LDAP“我是谁？”操作。
This specification describes a Lightweight Directory Access Protocol (LDAP) [RFC4510] operation that clients can use to obtain the primary authorization identity, in its primary form, that the server has associated with the user or application entity. The operation is called the "Who am I?" operation.
本规范描述了轻量级目录访问协议（LDAP）[RFC4510]操作，客户端可使用该操作以主要形式获取服务器与用户或应用程序实体关联的主要授权标识。这个手术叫做“我是谁？”手术。
This specification is intended to replace the existing Authorization Identity Controls [RFC3829] mechanism, which uses Bind request and response controls to request and return the authorization identity. Bind controls are not protected by security layers established by the Bind operation that includes them. While it is possible to establish security layers using StartTLS [RFC4511][RFC4513] prior to the Bind operation, it is often desirable to use security layers established by the Bind operation. An extended operation sent after a Bind operation is protected by the security layers established by the Bind operation.
本规范旨在取代现有的授权标识控制[RFC3829]机制，该机制使用绑定请求和响应控制来请求和返回授权标识。绑定控件不受包含它们的绑定操作所建立的安全层的保护。虽然可以在绑定操作之前使用StartTLS[RFC4511][RFC4513]建立安全层，但通常需要使用绑定操作建立的安全层。绑定操作后发送的扩展操作受绑定操作建立的安全层保护。
There are other cases where it is desirable to request the authorization identity that the server associated with the client separately from the Bind operation. For example, the "Who am I?" operation can be augmented with a Proxied Authorization Control [RFC4370] to determine the authorization identity that the server associates with the identity asserted in the Proxied Authorization Control. The "Who am I?" operation can also be used prior to the Bind operation.
在其他情况下，需要请求服务器与客户机关联的授权标识，而不是绑定操作。例如，“我是谁？”操作可以通过代理授权控制[RFC4370]进行扩充，以确定服务器与代理授权控制中断言的身份关联的授权身份。“我是谁？”操作也可以在绑定操作之前使用。
Servers often associate multiple authorization identities with the client, and each authorization identity may be represented by multiple authzId [RFC4513] strings. This operation requests and returns the authzId that the server considers primary. In the specification, the term "the authorization identity" and "the authzId" are generally to be read as "the primary authorization identity" and the "the primary authzId", respectively.
服务器通常将多个授权标识与客户端关联，每个授权标识可以由多个authzId[RFC4513]字符串表示。此操作请求并返回服务器认为主要的authzId。在说明书中，术语“授权标识”和“authzId”通常分别被理解为“主要授权标识”和“主要authzId”。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14[RFC2119]中所述进行解释。
The "Who am I?" operation is defined as an LDAP Extended Operation [RFC4511] identified by the whoamiOID Object Identifier (OID). This section details the syntax of the operation's whoami request and response messages.
“我是谁？”操作被定义为由whoamiOID对象标识符（OID）标识的LDAP扩展操作[RFC4511]。本节详细介绍操作的whoami请求和响应消息的语法。
whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
The whoami request is an ExtendedRequest with a requestName field containing the whoamiOID OID and an absent requestValue field. For example, a whoami request could be encoded as the sequence of octets (in hex):
whoami请求是一个扩展请求，其requestName字段包含whoamiOID和缺少的requestValue字段。例如，whoami请求可以编码为八位字节序列（十六进制）：
30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33
30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2
The whoami response is an ExtendedResponse where the responseName field is absent and the response field, if present, is empty or an authzId [RFC4513]. For example, a whoami response returning the authzId "u:xxyyz@EXAMPLE.NET" (in response to the example request) would be encoded as the sequence of octets (in hex):
whoami响应是一个扩展响应，其中responseName字段不存在，响应字段（如果存在）为空或authzId[RFC4513]。例如，whoami响应返回authzId“u:xxyyz@EXAMPLE.NET“（响应示例请求）将编码为八位字节序列（十六进制）：
30 21 02 01 02 78 1c 0a 01 00 04 00 04 00 8b 13 75 3a 78 78 79 79 7a 40 45 58 41 4d 50 4c 45 2e 4e 45 54
30 21 02 01 02 78 1c 0a 01 00 04 00 04 00 8b 13 75 3a 78 79 7a 40 45 58 41 4d 50 4c 45 2 E 4 E 45 54
The "Who am I?" operation provides a mechanism, a whoami Request, for the client to request that the server return the authorization identity it currently associates with the client. It also provides a mechanism, a whoami Response, for the server to respond to that request.
“我是谁？”操作提供了一种机制，即whoami请求，供客户端请求服务器返回当前与客户端关联的授权标识。它还提供了一种机制，即whoami响应，供服务器响应该请求。
Servers indicate their support for this extended operation by providing a whoamiOID object identifier as a value of the 'supportedExtension' attribute type in their root DSE. The server SHOULD advertise this extension only when the client is willing and able to perform this operation.
服务器通过在其根DSE中提供一个whoamiOID对象标识符作为“supportedExtension”属性类型的值来表示对该扩展操作的支持。只有当客户机愿意并且能够执行此操作时，服务器才应该公布此扩展。
If the server is willing and able to provide the authorization identity it associates with the client, the server SHALL return a whoami Response with a success resultCode. If the server is treating the client as an anonymous entity, the response field is present but empty. Otherwise, the server provides the authzId [RFC4513] representing the authorization identity it currently associates with the client in the response field.
如果服务器愿意并且能够提供与客户端关联的授权标识，则服务器应返回一个whoami响应，并返回一个success resultCode。如果服务器将客户端视为匿名实体，则响应字段存在但为空。否则，服务器将在响应字段中提供authzId[RFC4513]，表示当前与客户端关联的授权标识。
If the server is unwilling or unable to provide the authorization identity it associates with the client, the server SHALL return a whoami Response with an appropriate non-success resultCode (such as operationsError, protocolError, confidentialityRequired, insufficientAccessRights, busy, unavailable, unwillingToPerform, or other) and an absent response field.
如果服务器不愿意或无法提供与客户端关联的授权标识，则服务器应返回一个whoami响应，并返回相应的非成功结果代码（例如操作错误、协议错误、机密性要求、访问权限不足、忙、不可用、不愿意操作或其他）和一个缺席响应字段。
As described in [RFC4511] and [RFC4513], an LDAP session has an "anonymous" association until the client has been successfully authenticated using the Bind operation. Clients MUST NOT invoke the "Who am I?" operation while any Bind operation is in progress, including between two Bind requests made as part of a multi-stage
如[RFC4511]和[RFC4513]中所述，LDAP会话具有“匿名”关联，直到使用绑定操作成功验证客户端。当任何绑定操作正在进行时，客户机不得调用“我是谁？”操作，包括作为多阶段操作一部分的两个绑定请求之间的绑定
Bind operation. Where a whoami Request is received in violation of this absolute prohibition, the server should return a whoami Response with an operationsError resultCode.
绑定操作。如果收到的whoami请求违反了此绝对禁止，则服务器应返回带有operationsError resultCode的whoami响应。
Future specifications may extend the "Who am I?" operation using the control mechanism [RFC4511]. When extended by controls, the "Who am I?" operation requests and returns the authorization identity the server associates with the client in a particular context indicated by the controls.
未来的规范可能会使用控制机制扩展“我是谁？”操作[RFC4511]。当通过控件扩展时，“我是谁？”操作请求并返回服务器在控件指示的特定上下文中与客户端关联的授权标识。
The Proxied Authorization Control [RFC4370] is used by clients to request that the operation it is attached to operate under the authorization of an assumed identity. The client provides the identity to assume in the Proxied Authorization request control. If the client is authorized to assume the requested identity, the server executes the operation as if the requested identity had issued the operation.
客户端使用代理授权控制[RFC4370]来请求其附加的操作在假定身份的授权下运行。客户端提供要在代理授权请求控件中采用的标识。如果客户机被授权使用请求的标识，则服务器将执行该操作，就像请求的标识发出了该操作一样。
As servers often map the asserted authzId to another identity [RFC4513], it is desirable to request that the server provide the authzId it associates with the assumed identity.
由于服务器经常将断言的authzId映射到另一个标识[RFC4513]，因此需要请求服务器提供与假定标识关联的authzId。
When a Proxied Authorization Control is be attached to the "Who am I?" operation, the operation requests the return of the authzId the server associates with the identity asserted in the Proxied Authorization Control. The authorizationDenied (123) result code is used to indicate that the server does not allow the client to assume the asserted identity.
当代理授权控件附加到“我是谁？”操作时，该操作请求返回服务器与代理授权控件中断言的标识关联的authzId。authorizationDenied（123）结果代码用于指示服务器不允许客户端采用断言的身份。
Identities associated with users may be sensitive information. When they are, security layers [RFC4511][RFC4513] should be established to protect this information. This mechanism is specifically designed to allow security layers established by a Bind operation to protect the integrity and/or confidentiality of the authorization identity.
与用户关联的身份可能是敏感信息。如果需要，则应建立安全层[RFC4511][RFC4513]以保护此信息。此机制专门设计用于允许绑定操作建立的安全层保护授权标识的完整性和/或机密性。
Servers may place access control or other restrictions upon the use of this operation. As stated in Section 3, the server SHOULD advertise this extension when it is willing and able to perform the operation.
服务器可能会对此操作的使用设置访问控制或其他限制。如第3节所述，当服务器愿意并且能够执行该操作时，它应该公布该扩展。
As with any other extended operations, general LDAP security considerations [RFC4510] apply.
与任何其他扩展操作一样，一般LDAP安全注意事项[RFC4510]适用。
The OID 1.3.6.1.4.1.4203.1.11.3 is used to identify the LDAP "Who am I?" extended operation. This OID was assigned [ASSIGN] by the OpenLDAP Foundation, under its IANA-assigned private enterprise allocation [PRIVATE], for use in this specification.
OID 1.3.6.1.4.1.4203.1.11.3用于标识LDAP“我是谁？”扩展操作。这个OID由OpenLDAP基金会指派（赋值），在其IANA分配的私有企业分配（私有）下，用于本规范中。
Registration of this protocol mechanism [RFC4520] has been completed by the IANA.
IANA已完成该协议机制[RFC4520]的注册。
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: 1.3.6.1.4.1.4203.1.11.3
Description: Who am I?
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Extended Operation
Specification: RFC 4532
Author/Change Controller: IESG
Comments: none
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: 1.3.6.1.4.1.4203.1.11.3
Description: Who am I?
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Extended Operation
Specification: RFC 4532
Author/Change Controller: IESG
Comments: none
This document borrows from prior work in this area, including "Authentication Response Control" [RFC3829] by Rob Weltman, Mark Smith, and Mark Wahl.
本文件借鉴了该领域的前期工作，包括Rob Weltman、Mark Smith和Mark Wahl的“认证响应控制”[RFC3829]。
The LDAP "Who am I?" operation takes it's name from the UNIX whoami(1) command. The whoami(1) command displays the effective user ID.
LDAP“我是谁？”操作的名称来自UNIX whoami（1）命令。whoami（1）命令显示有效的用户ID。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4370] Weltman, R., "Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control", RFC 4370, February 2006.
[RFC4370]Weltman，R.，“轻量级目录访问协议（LDAP）代理授权控制”，RFC 43702006年2月。
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510]Zeilenga，K.，Ed.“轻量级目录访问协议（LDAP）：技术规范路线图”，RFC45102006年6月。
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511]Sermersheim，J.，Ed.，“轻量级目录访问协议（LDAP）：协议”，RFC4511，2006年6月。
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[RFC4513]Harrison，R.，Ed.“轻量级目录访问协议（LDAP）：身份验证方法和安全机制”，RFC4513，2006年6月。
[RFC3829] Weltman, R., Smith, M., and M. Wahl, "Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls", RFC 3829, July 2004.
[RFC3829]Weltman，R.，Smith，M.和M.Wahl，“轻型目录访问协议（LDAP）授权身份请求和响应控制”，RFC 38292004年7月。
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[RFC4520]Zeilenga，K.，“轻量级目录访问协议（LDAP）的互联网分配号码管理局（IANA）注意事项”，BCP 64，RFC 4520，2006年6月。
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", http://www.openldap.org/foundation/oid-delegate.txt.
[分配] OpenLDAP基金会，“OpenLDAP类委托”，http://www.openldap.org/foundation/oid-delegate.txt.
[PRIVATE] IANA, "Private Enterprise Numbers", http://www.iana.org/assignments/enterprise-numbers.
[私人]IANA，“私人企业编号”，http://www.iana.org/assignments/enterprise-numbers.
Author's Address
作者地址
Kurt D. Zeilenga OpenLDAP Foundation
库尔特D.Zeeliga OpenLDAP基金会
EMail: Kurt@OpenLDAP.org
EMail: Kurt@OpenLDAP.org
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）提供。