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

RFC 4515 - Lightweight Directory Access Protocol (LDAP)：検索フィルタの文字列表現

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

概要​

Lightweight Directory Access Protocol (LDAP) 検索フィルタは、ネットワーク上での使用に適したバイナリ表現を使用して LDAP プロトコルで送信されます。本文書は、LDAP URL (RFC 4516) やその他のアプリケーションでの使用に適した、LDAP 検索フィルタの人間が読める文字列表現を定義します。

目次​

  1. はじめに
  2. LDAP 検索フィルタの定義
  3. 文字列検索フィルタの定義
  4. 例
  5. セキュリティに関する考慮事項
  6. 引用規格
  7. 参考文献
  8. 謝辞 Appendix A: RFC 2254 からの変更点

1. はじめに​

Lightweight Directory Access Protocol (LDAP) [RFC4510] は、LDAP サーバーに送信される検索フィルタのネットワーク表現を定義しています。アプリケーションによっては、これらの検索フィルタを人間が読める形式で表現する一般的な方法があると便利な場合があります。LDAP URL [RFC4516] はそのようなアプリケーションの一例です。本文書は、拡張マッチフィルタを含む、可能なすべての LDAP バージョン 3 検索フィルタを表現するための人間が読める文字列形式を定義します。

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

本文書は RFC 2254 を置き換えます。RFC 2254 への変更点は付録 A に要約されています。

2. LDAP 検索フィルタの定義​

LDAP 検索フィルタは、[RFC4511] のセクション 4.5.1 で次のように定義されています。

        Filter ::= CHOICE {
            and                [0] SET SIZE (1..MAX) OF filter Filter,
            or                 [1] SET SIZE (1..MAX) OF filter Filter,
            not                [2] Filter,
            equalityMatch      [3] AttributeValueAssertion,
            substrings         [4] SubstringFilter,
            greaterOrEqual     [5] AttributeValueAssertion,
            lessOrEqual        [6] AttributeValueAssertion,
            present            [7] AttributeDescription,
            approxMatch        [8] AttributeValueAssertion,
            extensibleMatch    [9] MatchingRuleAssertion }

        SubstringFilter ::= SEQUENCE {
            type    AttributeDescription,
            -- initial and final can occur at most once
            substrings    SEQUENCE SIZE (1..MAX) OF substring CHOICE {
             initial        [0] AssertionValue,
             any            [1] AssertionValue,
             final          [2] AssertionValue } }

        AttributeValueAssertion ::= SEQUENCE {
            attributeDesc   AttributeDescription,
            assertionValue  AssertionValue }

        MatchingRuleAssertion ::= SEQUENCE {
            matchingRule    [1] MatchingRuleId OPTIONAL,
            type            [2] AttributeDescription OPTIONAL,
            matchValue      [3] AssertionValue,
            dnAttributes    [4] BOOLEAN DEFAULT FALSE }

        AttributeDescription ::= LDAPString
                        -- Constrained to <attributedescription>
                        -- [RFC4512]

        AttributeValue ::= OCTET STRING

        MatchingRuleId ::= LDAPString

        AssertionValue ::= OCTET STRING

        LDAPString ::= OCTET STRING -- UTF-8 encoded,
                                    -- [Unicode] characters

AttributeDescription は、[RFC4511] で定義されているように、[RFC4512] で説明されている属性記述の文字列表現です。AttributeValue および AssertionValue OCTET STRING は、[RFC4517] で定義されている形式を持ちます。フィルタは、[RFC4511] で説明されている簡略化を加えた [X.690] で定義されている Basic Encoding Rules (BER) を使用して、ネットワーク経由で送信するためにエンコードされます。

3. 文字列検索フィルタの定義​

LDAP 検索フィルタの文字列表現は、以下の文法によって定義される UTF-8 [RFC3629] エンコードされた Unicode 文字 [Unicode] の文字列であり、[RFC4234] で定義されている ABNF 表記に従います。ここで定義されていない生成規則は、特に明記されていない限り、[RFC4512] のセクション 1.4 (共通 ABNF 生成規則) で定義されています。フィルタ形式はプレフィックス表記を使用します。

      filter         = LPAREN filtercomp RPAREN
      filtercomp     = and / or / not / item
      and            = AMPERSAND filterlist
      or             = VERTBAR filterlist
      not            = EXCLAMATION filter
      filterlist     = 1*filter
      item           = simple / present / substring / extensible
      simple         = attr filtertype assertionvalue
      filtertype     = equal / approx / greaterorequal / lessorequal
      equal          = EQUALS
      approx         = TILDE EQUALS
      greaterorequal = RANGLE EQUALS
      lessorequal    = LANGLE EQUALS
      extensible     = ( attr [dnattrs]
                           [matchingrule] COLON EQUALS assertionvalue )
                       / ( [dnattrs]
                            matchingrule COLON EQUALS assertionvalue )
      present        = attr EQUALS ASTERISK
      substring      = attr EQUALS [initial] any [final]
      initial        = assertionvalue
      any            = ASTERISK *(assertionvalue ASTERISK)
      final          = assertionvalue
      attr           = attributedescription
                         ; The attributedescription rule is defined in
                         ; Section 2.5 of [RFC4512].
      dnattrs        = COLON "dn"
      matchingrule   = COLON oid
      assertionvalue = valueencoding
      ; The <valueencoding> rule is used to encode an <AssertionValue>
      ; from Section 4.1.6 of [RFC4511].
      valueencoding  = 0*(normal / escaped)
      normal         = UTF1SUBSET / UTFMB
      escaped        = ESC HEX HEX
      UTF1SUBSET     = %x01-27 / %x2B-5B / %x5D-7F
                          ; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
                          ; RPAREN, ASTERISK, and ESC.
      EXCLAMATION    = %x21 ; exclamation mark ("!")
      AMPERSAND      = %x26 ; ampersand (or AND symbol) ("&")
      ASTERISK       = %x2A ; asterisk ("*")
      COLON          = %x3A ; colon (":")
      VERTBAR        = %x7C ; vertical bar (or pipe) ("|")
      TILDE          = %x7E ; tilde ("~")

上記の文法では <substring> と <present> の両方の生成規則が "attr=*" 構造を生成できますが、この構造は存在フィルタを示すためにのみ使用されることに注意してください。

<valueencoding> 規則は、フィルタ文字列全体が有効な UTF-8 文字列であることを保証し、ASCII 文字 "*" (ASCII 0x2a)、"(" (ASCII 0x28)、")" (ASCII 0x29)、"" (ASCII 0x5c)、および NUL (ASCII 0x00) を表すオクテットが、バックスラッシュ "" (ASCII 0x5c) とそれに続くエンコードされたオクテットの値を表す 2 つの 16 進数字として表現されることを規定します。

この単純なエスケープメカニズムにより、フィルタ解析の曖昧さが排除され、LDAP で表現できる任意のフィルタを NUL 終端文字列として表現できるようになります。<normal> セットの一部である他のオクテットも、このメカニズムを使用してエスケープできます (例: 非表示 ASCII 文字)。

UTF-8 文字データを含む AssertionValues の場合、エスケープされる文字の各オクテットは、バックスラッシュと 2 つの 16 進数字に置き換えられます。これらは、文字のコード内の単一のオクテットを形成します。たとえば、"cn" 属性に文字 "" を含む値が含まれているかどうかを確認するフィルタは、"(cn=\2a*)" と表現されます。

<valueencoding> 規則で示されているように、実装は、検索フィルタの文字列表現を生成するときに、有効な UTF-8 エンコードシーケンスの一部ではない 0x7F より大きいすべてのオクテットをエスケープしなければなりません (MUST)。実装は、有効な UTF-8 文字列ではない入力文字列を受け入れるべきです (SHOULD)。これは、RFC 2254 が「文字列表現」という用語を明確に定義していなかったためです (特に、LDAP 検索フィルタの文字列表現が UTF-8 エンコードされた Unicode 文字の文字列であることについて言及していませんでした)。

4. 例​

このセクションでは、この表記法を使用して記述された検索フィルタのいくつかの例を示します。

(cn=Babs Jensen)
(!(cn=Tim Howes))
(&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
(o=univ*of*mich*)
(seeAlso=)

以下の例は、拡張マッチングの使用法を示しています。

(cn:caseExactMatch:=Fred Flintstone)
(cn:=Betty Rubble)
(sn:dn:2.4.6.8.10:=Barney Rubble)
(o:dn:=Ace Industry)
(:1.2.3:=Wilma Flintstone)
(:DN:2.4.6.8.10:=Dino)

最初の例は、マッチング規則 "caseExactMatch" の使用法を示しています。

2 番目の例は、matchingRule なしの MatchingRuleAssertion 形式の使用法を示しています。

3 番目の例は、":oid" 表記の使用法を示しています。これは、比較を行う際に OID "2.4.6.8.10" で識別されるマッチング規則を使用する必要があること、およびマッチングを評価する際にエントリの識別名 (DN) の属性をエントリの一部と見なす必要があること (":dn" の使用で示される) を示しています。

4 番目の例は、DN コンポーネントがマッチングを行う際にエントリの一部と見なされる必要があることを除いて、等価マッチを示しています。

5 番目の例は、指定されたマッチング規則をサポートする任意の属性に適用する必要があるフィルタです (<attr> が省略されているため)。

6 番目の最後の例も、指定されたマッチング規則をサポートする任意の属性に適用する必要があるフィルタです。DN に含まれるマッチング規則をサポートする属性も考慮する必要があります。

以下の例は、エスケープメカニズムの使用法を示しています。

(o=Parens R Us \28for all your parenthetical needs\29)
(cn=*\2A*)
(filename=C:\5cMyFile)
(bin=\00\00\00\04)
(sn=Lu\c4\8di\c4\87)
(1.3.6.1.4.1.1466.0=\04\02\48\69)

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

本文書は、LDAP 検索フィルタの文字列表現について説明しています。表現自体には既知のセキュリティ上の意味はありませんが、LDAP 検索フィルタにはあります。それらは LDAP サーバーによって解釈され、データが取得されるエントリを選択します。LDAP サーバーは、維持しているデータを不正アクセスから保護するように注意する必要があります。

詳細については、[RFC4511] および [RFC4513] のセキュリティに関する考慮事項のセクションを参照してください。

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.
  • [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.
  • [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
  • [Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2."

7. 参考文献​

  • [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 2006.
  • [X.690] Specification of ASN.1 encoding rules: Basic, Canonical, and Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994.

8. 謝辞​

本文書は、Tim Howes による RFC 2254 を置き換えます。RFC 2254 は、IETF ASID ワーキンググループの成果物でした。

に最終更新