RFC 4370 - Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control 日本語訳

URL : https://tools.ietf.org/html/rfc4370
タイトル : RFC 4370 - LDAP（Lightweight Directory Access Protocol）のプロキシを使用する認証コントロール
翻訳編集 : 自動生成

Network Working Group                                         R. Weltman
Request for Comments: 4370                                  Yahoo!, Inc.
Category: Standards Track                                  February 2006

             Lightweight Directory Access Protocol (LDAP)
                     Proxied Authorization Control

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 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（Lightweight Directory Access Protocol）のプロキシ認証の制御を定義しています。プロキシ認証コントロールは、クライアントが操作を提供する認可IDの下ではなく、接続に関連付けられている現在の認可IDの下で処理することを要求することができます。

1. Introduction

1. はじめに

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.

プロキシ認証は、クライアントが操作を提供する認証アイデンティティの下ではなく、接続に関連付けられている現在の認可IDの下で処理することを要求することができます。この文書では、制御機構[RFC2251]を使用したプロキシ認証のサポートを定義します。ライトウェイトディレクトリアクセスプロトコル[LDAPV3]は、認証用と承認のアイデンティティが全体のLDAPセッションに適用される認証アイデンティティとは異なる認証アイデンティティを供給するための簡易認証セキュリティー層[SASL]の使用をサポートしています。プロキシ認証の制御は、複数のユーザーに代わって効率的に操作を実行する必要があるクライアントに利益をもたらす、あたりの操作に基づき認可IDを指定するためのメカニズムを提供します。

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" used in this document are to be interpreted as described in [KEYWORDS].

キーワード「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、および本書で使用される[KEYWORDS]で説明されるように解釈される「場合があります」。

2. Publishing Support for the Proxy Authorization Control

プロキシ認証制御の2出版サポート

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」の存在によって示されます。

3. Proxy Authorization Control

3.プロキシ認証コントロール

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）または拡張操作要求メッセージを修正することができます。 [RFC2251]で定義されるように例外は、たLDAPMessageの制御フィールドの一部としてこのようなスタートTLSなどの認証、認可、またはデータの機密性の変化を引き起こす任意の拡張子[RFC2829]、[LDAPTLS]です。

The controlType of the proxy authorization control is "2.16.840.1.113730.3.4.18".

プロキシ認証制御のcontrolTypeは「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に設定しなければなりません。サーバーは、臨界フラグなしではProtocolErrorエラーでFALSEに設定されたフラグとプロキシ許可制御を含む任意の要求を拒否しなければなりません。これらの要件は、意図しない認証アイデンティティで実行された要求を提出からクライアントを保護します。

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.

要求された認可IDがサーバーによって認識され、そしてクライアントが要求認可IDを採用することを許可されている場合は、プロキシ認証アイデンティティが提出したかのように、要求が実行されます。そうでない場合は、結果コード123が返されます。

4. Implementation Considerations

4.実装に関する考慮事項

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下の検索要求の範囲内であっても。これは、プロキシ認証のアイデンティティが直接要求を発行した場合の場合よりも少ない結果、または全く結果が、返され得ることを意味します。そのような場合の例は、プロキシ権利要求者がツリー内のポイントまたはポイントで以下に探索木の上部に代理権限を有するがないファイングレイン・アクセス・コントロールを備えたシステムであってもよいです。

5. Security Considerations

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

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.

プロキシ認証制御方法は、[RFC2251] [AUTH] [LDAPTLS]一般的なLDAPセキュリティの考慮の対象となります。制御は、安全なチャネルを介して、並びに安全でないチャネルを介して送られてもよいです。

The control allows for an additional authorization identity to be passed. In some deployments, these identities may contain confidential information that requires privacy protection.

制御が渡される追加の許可のアイデンティティが可能になります。いくつかの展開では、これらのIDは、プライバシー保護を必要とする機密情報が含まれていてもよいです。

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.

サーバがプロキシ認証要求を光栄するかどうかを判断する責任があることに注意してください。「匿名」のユーザーは、他人のIDを仮定することは許されません。

6. IANA Considerations

6. IANAの考慮事項

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.

結果コード（123）は、サーバがプロキシ認証IDを使用して要求を実行しない場合のためにIANAによって割り当てられています。

7. Acknowledgements

7.謝辞

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.

以前はSun Microsystems、Inc.の、OpenLDAPの財団のクルトZeilengaの旧ネットスケープ・コミュニケーションズ社のマーク・スミス、マーク・ワール、ノベルのジム・Sermersheim、およびAdacelのスティーブン・レッグは、この文書のレビューに貢献してきました。

8. Normative References

8.引用規格

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

[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[LDAPV3] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.

[LDAPV3]ホッジス、J.とR.モルガン、 "ライトウェイトディレクトリアクセスプロトコル（v3の）：技術仕様"、RFC 3377、2002年9月。

[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.

[SASL]マイヤーズ、J.、 "簡易認証セキュリティー層（SASL）"、RFC 2222、1997年10月。

[AUTH] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan, "Authentication Methods for LDAP", RFC 2829, May 2000.

[AUTH]ワール、M.、Alvestrand、H.、ホッジス、J.、およびR.モルガン、 "LDAPのための認証方法"、RFC 2829、2000年5月。

[LDAPTLS] Hodges, J., Morgan, R., and M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000.

[LDAPTLS]ホッジス、J.、モルガン、R.、およびM.ワール、 "ライトウェイトディレクトリアクセスプロトコル（v3の）：トランスポート層セキュリティのための拡張"、RFC 2830、2000年5月。

[RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.

[RFC2251]ワール、M.、ハウズ、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]ワール、M.、Coulbeck、A.、ハウズ、T.、およびS. Kille、 "軽量のディレクトリアクセスプロトコル（V3）：属性の構文定義"、RFC 2252、1997年12月。

[RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan, "Authentication Methods for LDAP", RFC 2829, May 2000.

[RFC2829]ワール、M.、Alvestrand、H.、ホッジス、J.、およびR.モルガン、 "LDAPのための認証方法"、RFC 2829、2000年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.、 "IANA（Internet Assigned Numbers Authority）のライトウェイトディレクトリアクセスプロトコル（LDAP）に関する考慮事項"、BCP 64、RFC 3383、2002年9月。

Author's Address

著者のアドレス

Rob Weltman Yahoo!, Inc. 701 First Avenue Sunnyvale, CA 94089 USA

ロブWeltmanヤフー株式会社701まずアベニューサニーベール、CA 94089 USA

Phone: +1 408 349-5504 EMail: robw@worldspot.com

電話：+1 408 349-5504 Eメール：robw@worldspot.com

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）によって提供されます。