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

原文URL : https://datatracker.ietf.org/doc/html/rfc4370
タイトル : RFC 4370 - LightWeight Directory Access Protocol（LDAP）承認制御を促進する
翻訳編集 : 自動生成

[要約] RFC 4370は、LDAPプロキシ認証制御に関する規格であり、クライアントが他のユーザーの認証情報を使用して操作を実行できるようにすることを目的としています。

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

Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control

LightWeight Directory Access Protocol（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）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

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.

このドキュメントでは、Lightweight Directory Access Protocol（LDAP）プロキシ認証制御を定義します。プロキシ認証制御により、クライアントは、接続に関連付けられた現在の認証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の下ではなく、提供された承認IDの下で操作を処理することを要求できます。このドキュメントでは、制御メカニズム[RFC2251]を使用したプロキシ認証のサポートを定義しています。Lightweight Directory Access Protocol [LDAPV3]は、認証と認証IDとは異なる認証IDを提供するために、Simple Authentication and Security Layer [SASL]の使用をサポートします。プロキシ認証コントロールは、複数のユーザーに代わって効率的に操作を実行する必要があるクライアントに利益をもたらすためのメカニズムを提供します。

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" used in this document are to be interpreted as described in [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）のサポートコントロール属性[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のコントロールフィールドの一部としてStart TLS [LDAPTLS]など、認証、承認、またはデータの機密性の変更を引き起こす任意の拡張です[RFC2829]。

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.

臨界性は存在しなければならず、真実でなければなりません。この要件により、クライアントは、意図しない認可IDで実行されるリクエストを送信することを保護します。

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.

クライアントは批判的なフラグを含める必要があり、それを真に設定する必要があります。サーバーは、批判的なフラグなしで、またはプロトコレロエラーでFalseに設定されたフラグを使用して、プロキシ認証制御を含むリクエストを拒否する必要があります。これらの要件は、クライアントが意図しない認可IDで実行されるリクエストを送信することを保護します。

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は存在し、要求の認可IDを表す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を採用する権限を与えられている場合、リクエストはプロキシ認証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.

プロキシ認証と通常のアクセス制御の1つの可能な相互作用をここに示します。検索要求の評価中に、検索のために返されるエントリ（プロキシ認証IDから直接送信された場合）が返されない場合があります。エントリは、そのような権利を暗示する基本DNの下で、エントリが検索要求の範囲内であっても。これは、プロキシ認証IDがリクエストを直接発行した場合よりも、結果が少ない、または結果が返されないことを意味します。そのような場合の例は、密集したアクセス制御を備えたシステムである可能性があります。ここでは、プロキシ右リクエスト担当者は検索ツリーの上部にプロキシ権利を持っていますが、ツリー内のポイントまたはポイント以下ではありません。

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.

プロキシ認証制御方法は、一般的な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.

コントロールにより、追加の承認IDを渡すことができます。一部の展開では、これらの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.

サーバーは、プロキシ承認要求を尊重するかどうかを判断する責任があることに注意してください。「匿名」ユーザーは、他人の身元を引き受けることを許可されるべきではありません。

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.

以前はNetscape Communications Corp.のMark WahlのMark Smith、以前はSun Microsystems、Inc.、Openldap FoundationのKurt Zeilenga、NovellのJim Sermersheim、AdacelのSteven Leggがこの文書のレビューに貢献しています。

8. Normative References

8. 引用文献

[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、「Lightweight Directory Access Protocol（V3）：技術仕様」、RFC 3377、2002年9月。

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

[SASL] Myers、J。、「Simple Authentication and Security Layer（SASL）」、RFC 2222、1997年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 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] Hodges、J.、Morgan、R。、およびM. Wahl、「Lightweight Directory Access Protocol（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、「Lightweight Directory Access Protocol（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、「Lightweight Directory Access Protocol（V3）：属性構文定義」、RFC 2252、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 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）のLightweight Directory Access Protocol（LDAP）の考慮事項」、BCP 64、RFC 3383、2002年9月。

Author's Address

著者の連絡先

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

Rob Weltman Yahoo！、Inc。701 First Avenue Sunnyvale、CA 94089 USA

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

Full Copyright Statement

完全な著作権声明

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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。