RFC4370 日本語訳
4370 Lightweight Directory Access Protocol (LDAP) ProxiedAuthorization Control. R. Weltman. February 2006. (Format: TXT=10624 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Weltman Request for Comments: 4370 Yahoo!, Inc. Category: Standards Track February 2006
Weltmanがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4370年のYahoo!Inc.カテゴリ: 標準化過程2006年2月
Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control
ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)Proxied承認コントロール
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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)プロキシAuthorization Controlを定義します。 Proxy Authorization Controlは接続に関連している現在の承認のアイデンティティの代わりに操作が提供された承認のアイデンティティの下で処理されるようクライアントを要求させます。
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.
プロキシ承認で、クライアントは、接続に関連している現在の承認のアイデンティティの代わりに操作が提供された承認のアイデンティティの下で処理されるよう要求できます。 このドキュメントは、Controlメカニズム[RFC2251]を使用することでプロキシ承認のサポートを定義します。 ライトウェイト・ディレクトリ・アクセス・プロトコル[LDAPV3]はSimple Authenticationの使用と認証と認証のアイデンティティと異なった承認のアイデンティティを供給するためのSecurity Layer[SASL]をサポートします。そこでは、承認のアイデンティティが全体のLDAPセッションに適用されます。 Proxy Authorization Controlは1操作あたり1個のベースで承認のアイデンティティを指定するのにメカニズムを提供します、効率的に複数のユーザを代表して操作を実行する必要があるクライアントのためになって。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" used in this document are to be interpreted as described in [KEYWORDS].
キーワード“MUST"、「必須NOT」“SHOULD"、「」 本書では使用される「5月」は中[キーワード]で説明されるように解釈されることになっているべきです。
Weltman Standards Track [Page 1] RFC 4370 LDAP Proxied Authorization Control February 2006
Weltman規格はLDAP Proxied承認コントロール2006年2月にRFC4370を追跡します[1ページ]。
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).
Proxy Authorization ControlのサポートがObject Identifier(OID)の存在によって示される、「2.16、.840、.1、.113730、.3、.4、サーバの根のDSA特有のエントリー(DSE)のsupportedControl属性[RFC2252]における0.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].
Proxy Authorization Controlがそうするシングルがどんな検索にも含まれていて、Distinguished Name(DN)か拡大手術要求メッセージを比較するか、変更するか、加えるか、削除するか、または変更してください。 例外は認証における変化、承認、またはデータの機密性[RFC2829]を引き起こすあらゆる拡大です、LDAPMessageのコントロール分野の一部としてのStart TLS[LDAPTLS]などのように、[RFC2251]で定義されるように。
The controlType of the proxy authorization control is "2.16.840.1.113730.3.4.18".
プロキシ承認コントロールのcontrolTypeがそうである、「2.16 .840 .1 .113730 .3 .4 0.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.
臨界は、存在していなければならなくて、TRUEであるに違いありません。 この要件は故意でない承認のアイデンティティで実行される要求を提出するのからクライアントを保護します。
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に設定された旗でProxy Authorization Controlを含むどんな要求も拒絶しなければなりません。 これらの要件は故意でない承認のアイデンティティで実行される要求を提出するのからクライアントを保護します。
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 SHALL、存在してください、そして、SHALLが要求のために承認のアイデンティティを表しながら、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.
要求された承認のアイデンティティがサーバによって認められて、クライアントが要求された承認のアイデンティティを採用するのに権限を与えられると、要求はまるでプロキシ承認のアイデンティティで提出するかのように実行されるでしょう。 さもなければ、結果コード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
プロキシ承認と通常のアクセスコントロールの1回の可能な相互作用がここで例証されます。 検索要求の評価の間、検索(プロキシ承認のアイデンティティで直接提出するなら)のために返されたエントリーは返されないかもしれません。
Weltman Standards Track [Page 2] RFC 4370 LDAP Proxied Authorization Control February 2006
Weltman規格はLDAP Proxied承認コントロール2006年2月にRFC4370を追跡します[2ページ]。
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.
Proxy Authorization Controlメソッドは一般的な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.
コントロールは、追加承認のアイデンティティが通過されるのを許容します。 いくつかの展開では、これらのアイデンティティはプライバシー保護を必要とする秘密情報を含むかもしれません。
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.
プロキシ承認要求が光栄に思うかどうかことであることを決定するのにサーバが原因となることに注意してください。 「匿名」のユーザSHOULD NOT、他のもののアイデンティティは仮定させられてください。
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、0.18インチがプロキシ承認コントロールのために予約される、」 LDAPプロトコルMechanism[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)はサーバがプロキシ承認のアイデンティティを使用することで要求を実行しないケースのために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.
マーク・ウォール、以前ネットスケープ・コミュニケーションズについてスミスをマークしてください、そして、以前、サン・マイクロシステムズ・インクでは、OpenLDAP財団のカートZeilenga、ノベルのジムSermersheim、およびAdacelのスティーブンLeggはこのドキュメントのレビューで貢献しました。
Weltman Standards Track [Page 3] RFC 4370 LDAP Proxied Authorization Control February 2006
Weltman規格はLDAP Proxied承認コントロール2006年2月にRFC4370を追跡します[3ページ]。
8. Normative References
8. 引用規格
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[LDAPV3] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[LDAPV3] ホッジズ、J.、およびR.モーガン、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「技術的な仕様」、RFC3377、2002年9月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL] マイアーズ、J.、「簡易認証とセキュリティは(SASL)を層にする」RFC2222、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のための認証方法」RFC2829)は2000がそうするかもしれません。
[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)について議定書の中で述べます」。 「トランスポート層セキュリティのための拡大」(RFC2830)は2000がそうするかもしれません。
[RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251]ウォール、M.、ハウズ、T.、およびS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 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)について議定書の中で述べます」。 「属性構文定義」、RFC2252、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のための認証方法」RFC2829)は2000がそうするかもしれません。
[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.、「インターネットはライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)のために数の権威(IANA)に問題を割り当てました」、BCP64、RFC3383、2002年9月。
Author's Address
作者のアドレス
Rob Weltman Yahoo!, Inc. 701 First Avenue Sunnyvale, CA 94089 USA
ロブWeltman Yahoo!Inc.701First Avenueカリフォルニア94089サニーベル(米国)
Phone: +1 408 349-5504 EMail: robw@worldspot.com
以下に電話をしてください。 +1 408 349-5504 メールしてください: robw@worldspot.com
Weltman Standards Track [Page 4] RFC 4370 LDAP Proxied Authorization Control February 2006
Weltman規格はLDAP Proxied承認コントロール2006年2月にRFC4370を追跡します[4ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Weltman Standards Track [Page 5]
Weltman標準化過程[5ページ]
一覧
スポンサーリンク