メインコンテンツまでスキップ

RFC 4516 - Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator

  • ステータス: Proposed Standard
  • 発行日: June 2006
  • ストリーム: IETF
  • 廃止: RFC2255
  • エラッタ: エラッタなし

概要​

本文書は、Lightweight Directory Access Protocol (LDAP) Uniform Resource Locator (URL) のフォーマットについて記述しています。LDAP URL は、LDAP ディレクトリから情報を取得するために使用される LDAP 検索操作を記述します。あるいは、LDAP 参照またはリファレンスのコンテキストでは、LDAP URL は LDAP 操作が進行される可能性のあるサービスを記述します。

目次​

  1. はじめに
  2. URL 定義 2.1. パーセントエンコーディング
  3. LDAP URL フィールドのデフォルト
  4. 例
  5. セキュリティに関する考慮事項
  6. 引用規格
  7. 参考文献
  8. 謝辞 Appendix A: RFC 2255 からの変更点

1. はじめに​

LDAP は Lightweight Directory Access Protocol [RFC4510] です。本文書は、LDAP バージョン 3 の LDAP URL フォーマットを指定し、LDAP URL がどのように解決されるかを明確にします。本文書はまた、LDAP URL の拡張メカニズムを定義します。このメカニズムを使用して、新しい LDAP 拡張へのアクセスを提供できます。

[RFC4511] で記述されている LDAP 検索操作のすべてのパラメータが、本文書で定義されているフォーマットを使用して表現できるわけではないことに注意してください。また、URL は、非検索操作のものを含む参照知識を表すために使用される場合があることにも注意してください。

本文書は、LDAP 技術仕様 [RFC4510] の不可欠な部分であり、以前に定義された LDAP 技術仕様である RFC 3377 を全体として廃止します。

本文書は RFC 2255 を置き換えます。RFC 2255 に対する変更点のリストについては、付録 A を参照してください。

2. URL 定義​

LDAP URL はプロトコルプレフィックス "ldap" で始まり、[RFC4234] で定義されている ABNF 表記に従って、以下の文法で定義されます。

      ldapurl     = scheme COLON SLASH SLASH [host [COLON port]]
                       [SLASH dn [QUESTION [attributes]
                       [QUESTION [scope] [QUESTION [filter]
                       [QUESTION extensions]]]]]
                                      ; <host> and <port> are defined
                                      ;   in Sections 3.2.2 and 3.2.3
                                      ;   of [RFC3986].
                                      ; <filter> is from Section 3 of
                                      ;   [RFC4515], subject to the
                                      ;   provisions of the
                                      ;   "Percent-Encoding" section
                                      ;   below.

      scheme      = "ldap"

      dn          = distinguishedName ; From Section 3 of [RFC4514],
                                      ; subject to the provisions of
                                      ; the "Percent-Encoding"
                                      ; section below.

      attributes  = attrdesc *(COMMA attrdesc)
      attrdesc    = selector *(COMMA selector)
      selector    = attributeSelector ; From Section 4.5.1 of
                                      ; [RFC4511], subject to the
                                      ; provisions of the
                                      ; "Percent-Encoding" section
                                      ; below.

      scope       = "base" / "one" / "sub"
      extensions  = extension *(COMMA extension)
      extension   = [EXCLAMATION] extype [EQUALS exvalue]
      extype      = oid               ; From section 1.4 of [RFC4512].

      exvalue     = LDAPString        ; From section 4.1.2 of
                                      ; [RFC4511], subject to the
                                      ; provisions of the
                                      ; "Percent-Encoding" section
                                      ; below.

      EXCLAMATION = %x21              ; exclamation mark ("!")
      SLASH       = %x2F              ; forward slash ("/")
      COLON       = %x3A              ; colon (":")
      QUESTION    = %x3F              ; question mark ("?")

"ldap" プレフィックスは、指定されたホスト名およびポート番号で実行されている LDAP サーバーからアクセス可能なエントリを示します。<host> には、[RFC3986] のセクション 3.2.2 で指定されているリテラル IPv6 アドレスが含まれる場合があることに注意してください。

<dn> は、[RFC4514] で記述されている文字列表現を使用した LDAP 識別名です。これは、LDAP 検索のベースオブジェクトまたは非検索操作のターゲットを識別します。

<attributes> 構造は、エントリから返される属性を示すために使用されます。

<scope> 構造は、指定された LDAP サーバーで実行する検索のスコープを指定するために使用されます。許可されるスコープは、ベースオブジェクト検索の場合は "base"、1 レベル検索の場合は "one"、サブツリー検索の場合は "sub" です。

<filter> は、検索中に指定されたスコープ内のエントリに適用する検索フィルタを指定するために使用されます。これには、[RFC4515] で指定されたフォーマットがあります。

<extensions> 構造は、LDAP URL に拡張性メカニズムを提供し、URL の機能を将来拡張できるようにします。拡張は、type=value ペアの単純なカンマ区切りリストであり、それを必要としないオプションの場合は =value 部分を省略できます (MAY)。各 type=value ペアは個別の拡張です。これらの LDAP URL 拡張は、必ずしも LDAP 拡張メカニズムに関連しているわけではありません。拡張は、URL を解決するクライアントによってサポートされている場合もあれば、サポートされていない場合もあります。'!' 文字 (ASCII 0x21) で始まる拡張は重要 (critical) です。'!' 文字で始まらない拡張は重要ではありません (non-critical)。

LDAP URL 拡張が実装されている場合 (つまり、実装がそれを理解し、使用できる場合)、実装はそれを使用しなければなりません (MUST)。拡張が実装されておらず、重要としてマークされている場合、実装はその URL を処理してはなりません (MUST NOT)。拡張が実装されておらず、重要としてマークされていない場合、実装はその拡張を無視しなければなりません (MUST)。

拡張タイプ (<extype>) は、数値 OID <numericoid> 形式 (例: 1.2.3.4) または記述子 <descr> 形式 (例: myLDAPURLExtension) を使用して指定できます (MAY)。<descr> 形式の使用は、登録されたオブジェクト識別子の記述名に制限されるべきです (SHOULD)。記述名の登録の詳細と使用ガイドラインについては、[RFC4520] を参照してください。

本文書では LDAP URL 拡張は定義されていません。他の文書または本文書の将来のバージョンで、1 つ以上の拡張が定義される場合があります (MAY)。

2.1. パーセントエンコーディング​

生成された LDAP URL は、[RFC3986] で定義されている以下の 3 つの生成規則のいずれかに含まれる制限された文字セットのみで構成されなければなりません (MUST)。

      <reserved>
      <unreserved>
      <pct-encoded>

実装は、入力として他の有効な UTF-8 文字列 [RFC3629] を受け入れるべきです (SHOULD)。以下のいずれかの状況では、[RFC3986] のセクション 2.1 で記述されているパーセントエンコーディングメカニズムを使用してオクテットをエンコードしなければなりません (MUST)。

  • オクテットが、[RFC3986] のセクション 2.2 で定義されている予約セット、または [RFC3986] のセクション 2.3 で定義されている非予約セットに含まれていない。
  • 単一の予約文字 '?' であり、<dn>、<filter>、または LDAP URL のその他の要素内に存在する。
  • <exvalue> 内に存在するカンマ文字 ',' である。

パーセントエンコーディングメカニズムが適用される前に、LDAP URL の拡張コンポーネントには 1 つ以上の null (ゼロ) バイトが含まれる場合があることに注意してください。他のコンポーネントには含まれません。

3. LDAP URL フィールドのデフォルト​

上記のように、LDAP URL の一部のフィールドはオプションです。他の指定がない場合、フィールドが存在しないときは以下の一般的なデフォルトを使用すべきです (SHOULD)。他の文書で異なるデフォルトルールが指定される場合があることに注意してください (MAY)。たとえば、[RFC4511] のセクション 4.1.10 では、参照として返される LDAP URL に DN がない場合に使用する正しい DN を決定するための異なるルールが指定されています。

<host> <host> が指定されていない場合、クライアントは連絡すべき適切な LDAP サーバーに関する事前の知識を持っている必要があります。

<port> デフォルトの LDAP ポートは TCP ポート 389 です。

<dn> <dn> が指定されていない場合、デフォルトは長さゼロの DN "" です。

<attributes> <attributes> 部分が省略された場合、エントリのすべてのユーザー属性が要求されるべきです (たとえば、LDAP 検索要求の属性フィールド AttributeDescriptionList を NULL リストに設定するか、特別な <alluserattrs> セレクタ "*" を使用することによって)。

<scope> <scope> が省略された場合、"base" の <scope> が想定されます。

<filter> <filter> が省略された場合、"(objectClass=*)" のフィルタが想定されます。

<extensions> <extensions> が省略された場合、拡張なしが想定されます。

4. 例​

以下は、上記で定義されたフォーマットを使用したいくつかの LDAP URL の例です。最初の例は、ミシガン大学のエントリを参照する LDAP URL であり、クライアントが選択した LDAP サーバーから利用可能です。

ldap:///o=University%20of%20Michigan,c=US

次の例は、特定の ldap サーバー内のミシガン大学のエントリを参照する LDAP URL です。

ldap://ldap1.example.net/o=University%20of%20Michigan,c=US

これらの URL は両方とも、フィルタ "(objectclass=*)" を使用してすべての属性を要求する、"o=University of Michigan,c=US" エントリのベースオブジェクト検索に対応しています。

次の例は、ミシガン大学のエントリの postalAddress 属性のみを参照する LDAP URL です。

ldap://ldap1.example.net/o=University%20of%20Michigan,
       c=US?postalAddress

対応する LDAP 検索操作は前の例と同じですが、postalAddress 属性のみが要求されます。

次の例は、ポート 6666 上の指定された LDAP サーバーにクエリを実行し、"Babs Jensen" という共通名を持つエントリについてミシガン大学のサブツリー検索を実行して見つかったエントリのセットを参照し、すべての属性を取得する LDAP URL です。

ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
       c=US??sub?(cn=Babs%20Jensen)

次の例は、c=GB エントリのすべての子を参照する LDAP URL です。

LDAP://ldap1.example.com/c=GB?objectClass?ONE

objectClass 属性がエントリとともに返されるように要求され、デフォルトのフィルタ "(objectclass=*)" が使用されます。

次の例は、"o=Question?,c=US" という名前の LDAP エントリの mail 属性を取得するための LDAP URL であり、予約文字 '?' でのパーセントエンコーディングメカニズムの使用を示しています。

ldap://ldap2.example.com/o=Question%3f,c=US?mail

次の例 (読みやすくするために 2 行に分かれています) は、フィルタ引用メカニズムの LDAP 文字列表現と URL 引用メカニズムの間の相互作用を示しています。

ldap://ldap3.example.com/o=Babsco,c=US
        ???(four-octet=%5c00%5c00%5c00%5c04)

この例のフィルタは、LDAP エスケープメカニズム \ を使用して、値内の 3 つのゼロまたは null バイトをエンコードします。LDAP では、フィルタは (four-octet=\00\00\00\04) と記述されます。URL では \ 文字をエスケープする必要があるため、URL エンコーディングでは \ が %5c (または %5C) としてパーセントエンコードされます。

次の例は、DN 引用メカニズムの LDAP 文字列表現と URL 引用メカニズムの間の相互作用を示しています。

ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US

上記の URL でエンコードされた DN は次のとおりです。

o=An Example\2C Inc.,c=US

つまり、左端の RDN 値は次のとおりです。

An Example, Inc.

本文書の第 3 節で指定されているデフォルトルールが使用されていると仮定すると、以下の 3 つの URL は同等です。

ldap://ldap.example.net
ldap://ldap.example.net/
ldap://ldap.example.net/?

これら 3 つの URL は、ldap.example.net サーバー上のルート DSE を指します。

最後の 2 つの例は、架空の実験的なバインド名拡張の使用を示しています (拡張に関連付けられた値は LDAP DN です)。

ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com

2 つの URL は同じですが、2 つ目の URL は e-bindname 拡張を重要 (critical) としてマークしています。e-bindname 拡張の識別名値内のカンマをエンコードするためにパーセントエンコーディングメカニズムが使用されていることに注意してください。

5. セキュリティに関する考慮事項​

[RFC3986] で議論されている一般的な URL セキュリティに関する考慮事項は、LDAP URL に関連しています。

LDAP URL を処理する際にセキュリティメカニズムを使用するには、特別な注意が必要です。これは、クライアントが URL を介して多くの異なるサーバーに遭遇する可能性があり、URL がユーザーの介入なしに自動的に処理される可能性が高いためです。クライアントは、クライアントがどのサーバーと LDAP セッションを確立し、どのセキュリティメカニズムを使用するかを制御するユーザー構成可能なポリシーを持つべきであり (SHOULD)、このポリシーと矛盾する LDAP セッションを確立すべきではありません (SHOULD NOT)。クライアントが 1 つ以上の LDAP URL を解決するときに既存の LDAP セッションを再利用することを選択した場合、セッションが URL と互換性があり、セキュリティポリシーに違反していないことを確認しなければなりません (MUST)。

メカニズムに関係なく、認証情報を送信すると、ユーザーのプライバシー要件に違反する可能性があります。認証情報をサーバーに送信することを許可する特定のポリシーがない場合、クライアントは匿名 LDAP セッションを使用する必要があります。(すべての LDAP セッションが匿名で保護されていない以前の LDAP URL 仕様に準拠しているクライアントは、本仕様と整合性があることに注意してください。それらは単にデフォルトのセキュリティポリシーを持っているだけです。) 別のサーバーへのトランスポート接続を開くだけでも、一部のユーザーのプライバシー要件に違反する可能性があるため、クライアントはユーザーに URL 処理を制御する方法を提供する必要があります。

一部の認証方法、特にサーバーに送信される再利用可能なパスワードは、リモートサーバーまたは転送中の盗聴者に悪用されやすい情報を漏らす可能性があり、ポリシーによって明示的に許可されていない限り、URL 処理で使用すべきではありません。多くの状況では、認証情報の使用を人間のユーザーが確認することが適切です。機密情報を漏らさない強力な認証方法の使用が強く推奨されます。URL が更新操作の参照を表す場合は、強力な認証方法を使用すべきです (SHOULD)。詳細については、[RFC4513] のセキュリティに関する考慮事項のセクションを参照してください。

LDAP URL フォーマットでは、LDAP URL の評価時に実行される任意の LDAP 検索操作を指定できます。LDAP URL に従うと、大量のデータの取得や長時間実行される検索の開始など、予期しない結果が生じる可能性があります。LDAP URL を解決することによるセキュリティへの影響は、LDAP 検索クエリを解決することによる影響と同じです。

6. 引用規格​

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
  • [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
  • [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
  • [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
  • [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
  • [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
  • [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
  • [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
  • [RFC4515] Smith, M. Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters", RFC 4515, June 2006.

7. 参考文献​

  • [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
  • [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.

8. 謝辞​

LDAP URL フォーマットは、もともとミシガン大学で定義されました。この資料は、Grant No. NCR-9416667 に基づき米国国立科学財団の支援を受けた研究に基づいています。ミシガン大学と米国国立科学財団の両方の支援に感謝します。

本文書は、Tim Howes と Mark Smith による RFC 2255 を廃止します。この改訂された仕様に含まれる変更は、著者間の議論、LDAP (v3) 改訂ワーキンググループ (ldapbis) 内での議論、および他の IETF ワーキンググループ内での議論に基づいています。これらのワーキンググループの個人の貢献に感謝します。特に、RL "Bob" Morgan、Mark Wahl、Kurt Zeilenga、Jim Sermersheim、Hallvard Furuseth の各氏には、本文書に対する貴重なコメントをいただき、感謝の意を表します。

に最終更新