RFC 4532 - Lightweight Directory Access Protocol (LDAP) "Who am I?" Operation 日本語訳

URL : https://tools.ietf.org/html/rfc4532
タイトル : RFC 4532 - LDAP（Lightweight Directory Access Protocol）の "私は？"操作
翻訳編集 : 自動生成

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

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）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（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.

この仕様は、サーバーがユーザーまたはアプリケーションのエンティティに関連付けられた認可IDを取得するためのLDAP（Lightweight Directory Access Protocol）クライアントのためのメカニズムを提供します。 LDAP拡張操作がLDAPと呼ばれるように、このメカニズムは、指定された「Iです？」操作。

1. Background and Intent of Use

1.背景と利用意向

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.

この仕様は、Lightweight Directory Access Protocol（LDAP）[RFC4510]クライアントは、サーバーがユーザーやアプリケーションのエンティティに関連付けられていることを、その主要な形で、次許可IDを取得するために使用できる操作について説明しています。操作は、「私は誰だ？」と呼ばれています操作。

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.

この仕様は、リクエストにバインド要求および応答コントロールを使用し、認可IDを返し、既存の認証アイデンティティコントロール[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.

バインド操作とは別に、サーバーがクライアントに関連付けられていることを認可IDを要求することが望ましい他の例があります。例えば、「私は誰です？」操作は、アイデンティティを持つサーバーの仲間は、プロキシさ認可のコントロールでアサート認証アイデンティティを決定するためにプロキシを使用する認証コントロール[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.

サーバは、多くの場合、クライアントで複数の認証IDを関連付け、各認可IDは、複数のauthzidは[RFC4513]の文字列で表すことができます。この操作を要求し、サーバがプライマリと考えることauthzidはを返します。明細書において、用語「認可同一性」および「authzidは」は、それぞれ、「一次許可同一性」および「一次authzidは」として読まれることが一般的です。

1.1. Conventions Used in This Document

1.1. このドキュメントの表記規則

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].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14 [RFC2119]に記載されているように解釈されます。

2. The "Who am I?" Operation

2.「私を誰です？」操作

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"

2.1. The whoami Request

2.1. whoamiをリクエスト

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要求はwhoamiOID OIDと不在requestValueフィールドを含むrequestNameフィールドとのExtendedRequestあります。例えば、WHOAMI要求（16進数）オクテットのシーケンスとして符号化することができます。

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 2E 33

2.2. The whoami Response

2.2. whoamiはレスポンス

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フィールドが存在しないとの応答フィールドでExtendedResponseあり、存在する場合、空またはauthzidは[RFC4513]です。例えば、authzidは「U：xxyyz@EXAMPLE.NET」を返すWHOAMI応答（例えば、要求に応じて）が（16進数）オクテットのシーケンスとして符号化されるであろう。

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 1 0A 01 00 04 00 04 00 13 75 8B shtya shtya ZA 78 78から40 45 58 41 50 CHDのchts 45 2E 4E 45 54

3. Operational Semantics

3.操作的意味論

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.

「私は誰です？」クライアントはサーバが現在クライアントと関連付け認可IDを返すことを要求するための操作は、メカニズム、に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の「supportedExtension」属性タイプの値としてwhoamiOIDオブジェクト識別子を提供することによって、この拡張操作のための彼らのサポートを示します。クライアントは喜んで、この操作を実行することが可能である場合にのみ、サーバはこの拡張機能を宣伝すべきです。

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.

サーバは喜んで、それはクライアントと関連付け認可IDを提供することができる場合は、サーバは成功のresultCodeとWHOAMIレスポンスを返します。サーバが匿名のエンティティとしてクライアントを処理している場合、応答フィールドは存在するが空です。そうしないと、サーバーは、現在の応答フィールドにクライアントと関連付け認可IDを表す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.

サーバがクライアントと関連付け認可IDを提供したくないか、できない場合は、サーバーは、operationsError、はProtocolError、confidentialityRequired、insufficientAccessRights、忙しい、使用できない、unwillingToPerformとして、または適切な非成功のresultCode（と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セッションは、「匿名」の関連を持っています。クライアントは、「私は誰だ？」呼び出してはなりません操作任意のバインド操作は、多段の一部として作られた2つのバインド要求との間など、進行中

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はレスポンスを返す必要があります。

4. Extending the "Who am I?" Operation with Controls

4.「私は誰だ？」の拡張コントロールによる操作

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]を使用して操作。コントロールによって拡張すると、「私を誰です？」動作要求とコントロールで示される特定のコンテキストで認可IDにクライアントとサーバーの仲間を返します。

4.1. Proxied Authorization Control

4.1. プロキシさ認可のコントロール

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]は、操作は、想定同一の権限の下で動作するように接続されていることを要求するためにクライアントによって使用されます。クライアントは、プロキシさAuthorizationリクエスト制御で仮定するアイデンティティーを提供します。クライアントが要求されたアイデンティティを仮定することを許可された場合、サーバは要求されたアイデンティティが操作を発行したかのように動作を実行します。

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.

サーバは、多くの場合、別のアイデンティティ[RFC4513]にアサートauthzidはをマップとして、サーバが想定さアイデンティティと関連付け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.

プロキシさ認可のコントロールが接続されている場合は、「Iを誰です？」操作は、操作がアイデンティティを持つサーバーの仲間は、プロキシさ認可のコントロールで主張authzidはのリターンを要求します。 authorizationDenied（123）結果コードは、サーバは、クライアントがアサートアイデンティティを仮定することはできませんことを示すために使用されます。

5. Security Considerations

5.セキュリティについての考慮事項

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]は、この情報を保護するために確立されるべきです。このメカニズムは、具体的完全性および/または認可IDの機密性を保護するためにバインド操作によって確立されたセキュリティレイヤーを許可するように設計されています。

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]適用されます。

6. IANA Considerations

6. IANAの考慮事項

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識別するために使用された「I午前？」拡張操作。このOIDは、この仕様で使用するために、そのIANAによって割り当てられた民間企業の割り当て[PRIVATE]の下で、OpenLDAPの財団[ASSIGN]を割り当てました。

Registration of this protocol mechanism [RFC4520] has been completed by the IANA.

このプロトコルメカニズム[RFC4520]の登録はIANAによって完成されました。

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

件名：LDAPプロトコルメカニズム登録オブジェクト識別子の要求：1.3.6.1.4.1.4203.1.11.3説明：私は？人と詳細のために連絡する電子メールアドレス：クルトZeilenga <kurt@openldap.org>使用法：拡張動作仕様：RFC 4532著者/変更コントローラ：IESGコメント：なし

7. Acknowledgement

7.謝辞

This document borrows from prior work in this area, including "Authentication Response Control" [RFC3829] by Rob Weltman, Mark Smith, and Mark Wahl.

この文書では、ロブ・Weltman、マーク・スミス、そしてマーク・ワールで「認証応答制御」[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を表示します。

8. References

8.参照文献

8.1. Normative References

8.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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（Lightweight Directory Access Protocol）のプロキシを使用する認証コントロール"、RFC 4370、2006年2月。

[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.

[RFC4510] Zeilenga、K.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：技術仕様ロードマップ"。、RFC 4510、2006年6月。

[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.

[RFC4511] Sermersheim、J.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：プロトコル"、RFC 4511、2006年6月。

[RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.

[RFC4513]ハリソン、R.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：認証方法とセキュリティメカニズム"。、RFC 4513、2006年6月。

8.2. Informative References

8.2. 参考文献

[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.、スミス、M.、およびM.ワール、 "LDAP（Lightweight Directory Access Protocol）の認証アイデンティティ要求と応答コントロール"、RFC 3829、2004年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.、 "IANA（Internet Assigned Numbers Authority）のライトウェイトディレクトリアクセスプロトコル（LDAP）に関する考慮事項"、BCP 64、RFC 4520、2006年6月。

[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", http://www.openldap.org/foundation/oid-delegate.txt.

[ASSIGN]のOpenLDAP財団、 "OpenLDAPのOIDの代表団"、http://www.openldap.org/foundation/oid-delegate.txt。

[PRIVATE] IANA, "Private Enterprise Numbers", http://www.iana.org/assignments/enterprise-numbers.

[PRIVATE] IANA、 "民間企業番号"、http://www.iana.org/assignments/enterprise-numbers。

Author's Address

著者のアドレス

Kurt D. Zeilenga OpenLDAP Foundation

クルトD. ZeilengaのOpenLDAP財団

EMail: Kurt@OpenLDAP.org

メールアドレス：Kurt@OpenLDAP.org

Full Copyright Statement

完全な著作権声明

著作権（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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

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.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).

RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。