1. Oracle Unified Directoryの管理
  2. Oracle Unified Directoryの概念およびアーキテクチャ
  3. Oracle Unified Directoryスキーマ・モデルの理解

10 Oracle Unified Directoryスキーマ・モデルの理解

次の各トピックでは、一般的なスキーマ要素を説明し、これらのスキーマ要素がOracle Unified Directoryで使用される方法を示します。

ldapsearchコマンドを使用してスキーマを表示する説明については、「属性タイプの管理」および「オブジェクト・クラスの管理」を参照してください。

10.1 一致ルールの概要

一致ルールによって、同じ属性の値を比較できます。次の各項では、使用可能な様々な一致ルール、その説明形式および一般的に使用される一致ルールを理解します。

10.1.1 一致ルールの理解

一致ルールは、同じ属性の2つの値を比較し、それらで一致操作を実行するためにOracle Unified Directoryで使用されます。

一致ルールには、次に示すようないくつかの異なるタイプがあります

  • 等価一致ルール

    この種の一致ルールは、2つの値が論理的に等価かどうかを決定するために使用されます。等価一致ルールの実装ごとに、この決定に使用される基準は異なることがあります(たとえば、大文字/小文字の相違を無視するかどうか、どのスペースが重要かの決定など)。

  • 順序付け一致ルール

    この種の一致ルールは、2つの値の相対順序を決定するために(たとえば、次以上または次以下の検索の評価時や、結果をソートする必要があるときなど)使用されます。

  • 部分文字列一致ルール

    この種の一致ルールは、所定の部分文字列アサーションが特定の値に一致するかどうかを決定するために使用されます。部分文字列アサーションは、最大で1つのsubInitial要素、ゼロ個以上のsubAny要素、および最大で1つのsubFinal要素というセットの少なくとも1つの要素で構成されています。

  • 近似一致ルール

    この種の一致ルールは、2つの値がおおよそ等価かどうかを決定するために使用されます。これは、多くの場合、「類似しているものを検索する」などの種類のファジー・アルゴリズムに基づきます。近似一致ルールは正式なLDAP仕様の一部とはなっていませんが、Oracle Unified Directoryでは柔軟性を高めるために採用しています。

10.1.2 一致ルールの説明形式の理解

RFC 4512形式を使用して、スキーマ・サブエントリのmatchingRules属性で一致ルールを表示し、一致ルールと関連付けることのできるプロパティを示します。

RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt)の第4.1.3項に、Augmented Backus-Naur Form (ABNF)に従った一致ルールの説明形式について記載されています。ABNFに関する詳細は、RFC 4234 (http://www.ietf.org/rfc/rfc4234.txt)およびRFC 5234 (http://www.ietf.org/rfc/rfc5234.txt)を参照してください。

次の例は、一致ルールの説明形式の定義を示します:

MatchingRuleDescription = LPAREN WSP
numericoid                 ; object identifier
[ SP "NAME" SP qdescrs ]   ; short names (descriptors)
[ SP "DESC" SP qdstring ]  ; description
[ SP "OBSOLETE" ]          ; not active
SP "SYNTAX" SP numericoid  ; assertion syntax
extensions WSP RPAREN      ; extensions

一致ルールの説明は、次の要素を含みます:

  • numericoid

    数値OIDは、Oracle Unified Directoryで一致ルールを一意に識別する場合に使用されます。すべての一致ルールは、一意のOIDを持っている必要があります。

  • NAME

    名前要素は、OIDのかわりに、それを参照するために使用することができる一致ルールに割り当てられた判読可能な名前です。一致ルールは、判読可能な名前を持つ必要はありません。単一の名前を持つ場合は、それを一重引用符で囲みます。一致ルールに複数の名前がある場合は、それぞれを一重引用符で囲み、名前の間には空白を入れ、名前のセット全体をカッコで囲みます。

  • DESC

    説明要素は、一致ルールの判読可能な説明です。最大で1つの説明があり、それが存在する場合は、一重引用符で囲む必要があります。

  • OBSOLETE

    OBSOLETEフラグは、この一致ルールが使用可能であると見なすかどうかを示します。一致ルールがOBSOLETEにマークされた場合、この一致ルールを参照する、新しい属性タイプまたは一致ルールの使用方法を作成することはできません。

  • SYNTAX

    構文要素は、一致ルールが関連付けられている属性構文を識別します。この要素は、一致ルールが操作する値に対して許容可能な形式を示します。属性構文の詳細は、「属性構文の概要」を参照してください。構文OIDは、すべての一致ルールの説明に含まれている必要があります。

  • extensions

    一致ルールの拡張は、標準の定義に含まれない可能性があるその一致ルールの他のプロパティを識別するために使用することができます。Oracle Unified Directoryは現在、一致ルールで使用するためのいずれの拡張もサポートしていません。

たとえば、次の例は標準のcaseIgnoreMatch一致ルールの説明です: 

( 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

この場合、OIDは2.5.13.2です。caseIgnoreMatchという名前が1つあります。説明はありません。関連する構文のOIDは、1.3.6.1.4.1.1466.115.121.1.15(ディレクトリ文字列構文)です。拡張はありません。

10.1.3 一般的に使用される一致ルールの理解

コア・プロトコル仕様と同様に他の関連するRFCおよびインターネット・ドラフトの両方にLDAPで定義されている一致ルールがあります。これらの一致ルールの多くは、RFC 4517で定義されています。

RFC 4517で定義されている様々な一致ルールの詳細は、第4.2項(http://www.ietf.org/rfc/rfc4517.txt) (LDAP構文および一致ルール)を参照してください。最も一般的に使用される一致ルールを次に示します。

  • caseIgnoreMatch、caseIgnoreOrderingMatch、caseIgnoreSubstringsMatch

    これらのルールはそれぞれ、等価、順序付け、部分文字列一致ルールで、大/小文字の違いを無視し、複数の連続した空白を単一の空白として扱います。

  • caseExactMatch、caseExactOrderingMatch、caseExactSubstringsMatch

    これらのルールはそれぞれ、等価、順序付け、部分文字列の一致ルールで、大/小文字を区別する方法で値を扱いますが、複数の連続した空白は、単一の空白として扱います。

  • octetStringMatch、octetStringOrderingMatch、octetStringSubstringsMatch

    これらのルールはそれぞれ、等価、順序付け、部分文字列の一致ルールで、バイト単位で値の比較を実行します(それらを文字列ではなくバイナリ・データとして扱います)。

  • numericStringMatch、numericStringOrderingMatch、numericStringSubstringsMatch

    これらのルールはそれぞれ、等価、順序付けおよび部分文字列の一致ルールで、数値の桁で始まり、数値の桁および空白のみを含む値に対して操作が行われます。これらの一致ルールでマッチングを実行するときは、空白は無視されます。

  • distinguishedNameMatch

    このルールは、等価一致ルールで、識別名(DN)値に対して操作が行われます。DNコンポーネントを区切るカンマやセミコロンの前後の空白、RDNコンポーネントを区切る正符号の前後の空白、およびRDN属性タイプ名をそれらの対応する値から区切る等号の前後の空白を無視します。大/小文字の違いは、属性タイプ名では無視されます。属性値の等価一致は、対応する属性タイプ用の等価一致ルールを使用して実行されます。

  • doubleMetaphoneApproximateMatch

    このルールは近似一致ルールで、ダブル・メタフォン・アルゴリズムを使用して音声の比較を実行します。

    ノート:

    この一致ルールは公式のLDAP仕様の一部ではなく、柔軟性の向上のためにOracle Unified Directoryに含まれています

10.1.4 相対時間の一致ルールの理解

Oracle Unified Directoryは、一般化時間属性(relativeTimeLTOrderingMatchおよびrelativeTimeGTOrderingMatch)の相対日付で一致を実行するための2つの一致ルールを提供します。

一般化時間属性で一致を実行する2つの一致ルールは、次のように定義されます。 

( 1.3.6.1.4.1.26027.1.4.6
NAME ( 'relativeTimeLTOrderingMatch''relativeTimeOrderingMatch.lt' )
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

( 1.3.6.1.4.1.26027.1.4.5
NAME ( 'relativeTimeGTOrderingMatch' 'relativeTimeOrderingMatch.gt' )
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

構文は、GeneralizedTime構文を持つ属性に適用されますが、一般化時間の文字列を取ることはありません。かわりに、[+|-]数値[単位]の形式でオフセットをとります:

  • +|-

    過去または将来の時間を指定します。正のオフセット(+)は、現在の時間と比較して将来の時間を計算し、負のオフセット(-)は現在の時間と比較して過去の時間を計算します。デフォルトの値は正(+)です。

  • number

    正の整数として、時間単位の数値を指定します。

  • unit

    単一の文字で時間の単位を指定します(秒、分、時間、日または週はそれぞれ、s、m、h、dまたはwとなります)。

フィルタを処理するときに、サーバーは、現在のGMT時間を算出し、オフセットを追加し、属性値を新しく算出された値と比較します。

次の例は、pwdExpirationTime >= (Now + 5 days)を表しています。 

(pwdExpirationTime:1.3.6.1.4.1.26027.1.4.5:=5d)

同様に、次の例はpwdExpirationTime <= (Now + 5 days)を表しています。 

(pwdExpirationTime:1.3.6.1.4.1.26027.1.4.6:=5d)

10.1.5 部分的な日付や時間の一致ルールの理解

Oracle Unified Directoryは、一般化時間属性の日付で部分文字列一致を実行するためにpartialDateAndTimeMatchingRule一致ルールを提供します。

partialDateAndTimeMatchingRule一致ルールは、次のように定義されます。 

( 1.3.6.1.4.1.26027.1.4.7
NAME 'partialDateAndTimeMatchingRule'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

この一致ルールは、GeneralizedTime構文を持つ属性に適用されますが、値は汎用時間ではありません。かわりに、タグの前の1つ以上の整数のシーケンスで構成される日付のパターンを指定します。現在サポートされているタグは、Y、M、D、h、mおよびsです。

次の例では、次の定義の属性birthDate (http://tools.ietf.org/html/draft-gryphon-ldap-schema-vcard4-00で説明しています)を使用しています。 

attributeTypes: ( 1.3.6.1.4.1.33592.1.3.2 NAME 'birthDate' 
DESC 'birthday' 
EQUALITY generalizedTimeMatch 
ORDERING generalizedTimeOrderingMatch
SYNTAX .3.6.1.4.1.1466.115.121.1.24 
USAGE userApplications SINGLE-VALUE )

たとえば、次のフィルタは9月21日に生まれたすべてのユーザーに一致します。

(birthDate:1.3.6.1.4.1.26027.1.4.7:=09M21D)

別の例では、次のフィルタは1965年に生まれたすべてのユーザーに一致します:

(birthDate:1.3.6.1.4.1.26027.1.4.7:=1965Y)

次の検索操作は、任意の月の14日が誕生日であるすべてのエントリを返します:

$ ./ldapsearch -p 1389 -h localhost -D "cn=Directory Manager" -j pwd-file \
  -b "dc=example,dc=com" \
  "(birthDate:1.3.6.1.4.1.26027.1.4.7:=14D)" birthDate

10.1.6 値の正規化の理解

ほとんどの一致ルールが実行する必要のあるタスクの1つが値の正規化です。これは、指定された値を、効率的に値と比較するために使用できる形式に変換するプロセスです。

ほとんどの場合、正規化プロセスでは、すべての論理的に同等の値を同じ文字列に短縮する必要があります。それによって、非常に単純な文字列の比較を実行して、文字列が等しいかどうかを決定することができます。たとえば、caseIgnoreMatch一致ルールは、通常、すべての文字を小文字に変換し、複数の連続した空白を単一の空白に置換することで値を正規化します。より複雑な例は、distinguishedNameMatch一致ルールで、すべての不要な空白(たとえば、カンマ、等号および正符号の前後)を削除して、すべての属性タイプを小文字に変換し、適切な一致ルールを使用して各RDNコンポーネントの属性値を正規化します。

2つの値が論理的に等しいかどうかを決定するためには正規化のみでは不十分な場合があります。特に、値が変換され、同じ値に対して複数の異なる変換が存在する可能性がある場合です。

10.2 属性構文の概要

属性構文は、基本的にデータ型の定義です。属性タイプの構文は、対応する値によって保持されるデータ型を示します。これは、指定された属性で特定の値が受け入れられるかどうかを決定するのに使用されるだけではなく、Oracle Unified Directoryが既存の値とどのように相互作用するかに関する情報を提供するのにも使用されます。

Oracle Unified Directoryでは、関連付けられた属性構文に違反する値を拒否する機能をサポートしています。これは標準への準拠を目的とするデフォルトの動作です。必要であれば、この属性構文の検査を完全に無効にすることができますが、関連付けられた構文に違反する値を受け入れることも可能です。ただし、毎回これが発生するたびにOracle Unified Directoryのエラー・ログに警告メッセージが記録されます。ただし、属性がそれらの関連付けられた構文に違反する値を持つことを許可されている場合は、一致操作はそのような値では期待どおりに動作しない可能性があります。スキーマ・チェックの無効化の詳細は、「スキーマ・チェックの構成」を参照してください。

次の項では、属性構文について説明します:

10.2.1 属性構文の説明形式の理解

RFC 4512では、numericoid、DESC、extensionsなどの要素を含む属性構文の説明形式について説明しています。

RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt)の第4.1.5項に、次の例に示す属性構文の説明形式について記載されています。 

SyntaxDescription = LPAREN WSP
numericoid                 ; object identifier
[ SP "DESC" SP qdstring ]  ; description
extensions WSP RPAREN      ; extensions

属性構文の説明は、次の要素を含みます:

  • numericoid

    数値OIDは、Oracle Unified Directoryで属性構文を一意に識別する場合に使用されます。

  • DESC

    構文のオプションの説明です。指定する場合は、一重引用符で囲む必要があります。

  • extensions

    属性構文の拡張のオプション・セットです。次の拡張がサポートされています。

次の例では、標準のディレクトリ文字列構文の属性構文の説明を示します:

( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )

この場合、OIDは1.3.6.1.4.1.1466.115.121.1.15で、説明はDirectory Stringです。この例では、拡張を指定していません。

10.2.2 一般的に使用される属性構文について

LDAPで定義されている属性構文は多数あります。それらは、コア・プロトコル仕様と他の関連するRFCおよびインターネット・ドラフトの両方で定義されています。このトピックでは、RFC 4517で定義されている様々な属性構文について説明しています。

この属性構文の多くは、RFC 4517 (http://www.ietf.org/rfc/rfc4517.txt)「LDAP構文と一致ルール」の第3.3項で定義されています。最も一般的に使用される属性構文を次に示します。

  • Directory String

    Directory String構文は、1つ以上のUTF-8文字を含む汎用の文字列値を保持するために使用されます。技術的には、空の値(つまり、文字なし)は許可されていません。Oracle Directory Server Enterprise Editionは従来、空の値を許可しているため、標準コンプライアンスに対してデフォルトでは無効になっていますが、Oracle Unified Directoryは、それを許可するために使用できる構成オプションを提供しています。

  • IA5 String

    IA5 String構文は、ASCII文字セットとしても知られているIA5文字セットに基づいた文字列値を保持するために使用されます。

  • Printable String

    Printable String構文は、大文字と小文字、数値の桁、一重引用符、左右のカッコ、正符号、カンマ、ハイフン、ピリオドおよび等号のセットから1つ以上の文字を含む文字列値を保持するために使用されます。

  • Boolean

    Boolean構文は、TRUEまたはFALSEの値を保持するのに使用されます。この構文を持つ属性には、その他の値は許可されていません。

  • Integer

    Integer構文は、少なくとも1つの数字を含む必要がある整数値を保持するために使用されます。負の値を示すためにハイフンで始めることができます。値がゼロの場合にのみ、最初の桁にゼロを使用することができます。

  • Octet String

    Octet String構文は、ゼロ以上のバイトのセットを保持するために使用されます。以前のBinary構文のかわりに使用されています。

  • DN

    DN構文は、ゼロ以上のRDNコンポーネントで構成される識別名の値を保持するのに使用されます。値は、RFC 4514 (http://www.ietf.org/rfc/rfc4514.txt)「識別名のLDAP文字列表現」で指定されている形式である必要があります。

10.2.3 パターン一致構文の拡張について

X-PATTERN属性構文の拡張は、1つ以上の正規表現によって制限された値を使用して新しい文字列構文を定義するのに使用されます。

次の例では、X-PATTERN属性構文をスキーマに追加します。 

$ ldapmodify -p 1389 -h localhost -D "cn=Directory Manager" -j pwd-file
dn: cn=schema
changetype: modify
add: ldapsyntaxes
ldapSyntaxes: ( 1.3.6.1.4.1.32473.1 DESC 'Host and Port in the format of HOST:PORT'
  X-PATTERN '^[a-zA-Z][a-zA-Z0-9-]+:[0-9]+$' )

この新しい構文は、属性およびオブジェクト・クラスを定義するのに使用されます。次に例を示します。

$ ldapmodify -p 1389 -h localhost -D "cn=Directory Manager" -j pwd-file
dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.32473.2 NAME 'example-attr-regex' SYNTAX
1.3.6.1.4.1.32473.1 )
-
add: objectclasses
objectclasses: ( 1.3.6.1.4.1.32473.3 NAME 'exampleOCregex' SUP top AUXILIARY MUST
example-attr-regex)
-

example-attr-regex属性の値は、定義されたパターンに一致する必要があります。そうでなければ、サーバーがそれらを拒否します。次の属性は、例の構文で定義されたパターンに一致するので、サーバーはそれを受け入れます: 

example-attr-regex: localhost:389

次の属性は、必要なコロンおよび数値文字列を含んでいないため、拒否されます:

localhost

次の属性は、HOSTコンポーネントの一部として指定されないピリオド(.)を含むため、拒否されます: 

host.example.com:389

10.2.4 列挙構文の拡張について

X-ENUM属性構文の拡張は、順序付けられた定義済の値のセットに制限された値を用いて新しい文字列構文を定義するために使用されます。

次の例では、X-ENUM属性をスキーマに定義します。 

$ ldapmodify -p 1389 -h localhost -D "cn=Directory Manager" -j pwd-file
dn: cn=schema
changetype: modify
add: ldapsyntaxes
ldapSyntaxes: ( 1.3.6.1.4.1.32473.4 DESC 'Day Of The Week'
  X-ENUM ( 'monday' 'tuesday' 'wednesday' 'thursday'
  'friday' 'saturday' 'sunday' ) )

この新しい構文は、属性およびオブジェクト・クラスを定義するのに使用されます。次に例を示します。

$ ldapmodify -p 1389 -h localhost -D "cn=Directory Manager" -j pwd-file
dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.32473.5 NAME 'example-attr-enum' SYNTAX
1.3.6.1.4.1.32473.4 )
-
add: objectclasses
objectclasses: ( 1.3.6.1.4.1.32473.6 NAME 'exampleOCenum' SUP top AUXILIARY
MUST example-attr-enum)

example-attr-enum属性の値は、定義されたパターンに一致する必要があります。そうでなければ、サーバーがそれらを拒否します。

列挙された値は、大/小文字が区別されないので、次の例の両方が受け入れられます:

example-attr-enum: thursday
example-attr-enum: Thursday

列挙された属性値はリテラルである(国際化されていない)ので、次の例では、任意のセマンティック等価にかかわらず、パターンと一致せずに拒否されます:

example-attr-enum: jeudi

定義された値は順序を指定するので、列挙された属性は、相対的な比較フィルタで使用することができます。次に例を示します:

(example-attr-enum>=wednesday)

前述の比較フィルタは、たとえば、thursdayの値に一致します。比較は、列挙された値の順序に基づき、この場合は、ASCII値は適用されません。

10.2.5 置換構文の拡張について

X-SUBST属性構文の拡張を使用して、既存の構文を用いた値で新しい文字列構文を定義できます。Oracle Unified Directoryでサポートされていない構文を使用する非標準スキーマ(または外部スキーマ)で、ネイティブ・ディレクトリ・サーバーのスキーマを拡張するときに使用するために提供されています。インポートされたスキーマを変更するかわりに、X-SUBST拡張を使用してそれを拡張し、サポートされている構文を使用して値を処理するようにOracle Unified Directoryに指示します。

次の例では、新しい構文(AttCertPath)を既存の構文(1.3.6.1.4.1.1466.115.121.1.15ディレクトリ文字列)を用いて定義します。この変更は、cn=schemaの下で行う必要があります。 

$ ldapmodify -p 1389 -h localhost -D "cn=Directory Manager" -j pwd-file
dn: cn=schema
objectClass: top
objectClass: ldapSubentry
objectClass: subschema
ldapSyntaxes: ( 1.3.6.1.4.1.4203.666.11.10.2.4
  DESC 'AttCertPath'
  X-SUBST '1.3.6.1.4.1.1466.115.121.1.15' )

この機能は、移行時に便利であり、スキーマへの影響を軽減することができます。たとえば、Oracle Unified Directoryへの移行時には、受信スキーマは、定義されていない構文を使用する属性定義を含むことができます。X-SUBST属性構文の拡張は、他の、より一般的な構文を用いてそれらの不足している構文を定義する方法を提供します。スキーマおよびデータは、この機能により、スキーマまたはデータを変更したり、新たな構文を実装したりする必要なしに移行することができます。

10.3 属性タイプの理解

属性タイプは、Oracle Unified Directoryで使用できる属性のセット、およびこれらの属性に関する操作の実行方法を定義します。特に、属性構文および一致ルールのセットを一意のOIDおよび判読可能な名前を結び付けます。

次の項で、属性タイプについて説明します:

10.3.1 属性タイプの説明形式の理解

属性タイプの説明およびこれに含まれている様々な要素について学習します。

RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt)の第4.1.2項に、次の例に示す属性タイプの説明形式について記載されています。 

AttributeTypeDescription = LPAREN WSP
    numericoid                    ; object identifier
    [ SP "NAME" SP qdescrs ]      ; short names (descriptors)
    [ SP "DESC" SP qdstring ]     ; description
    [ SP "OBSOLETE" ]             ; not active
    [ SP "SUP" SP oid ]           ; supertype
    [ SP "EQUALITY" SP oid ]      ; equality matching rule
    [ SP "ORDERING" SP oid ]      ; ordering matching rule
    [ SP "SUBSTR" SP oid ]        ; substrings matching rule
    [ SP "SYNTAX" SP noidlen ]    ; value syntax
    [ SP "SINGLE-VALUE" ]         ; single-value
    [ SP "COLLECTIVE" ]           ; collective
    [ SP "NO-USER-MODIFICATION" ] ; not user modifiable
    [ SP "USAGE" SP usage ]       ; usage
    extensions WSP RPAREN         ; extensions

usage = "userApplications"     /  ; user
        "directoryOperation"   /  ; directory operational
        "distributedOperation" /  ; DSA-shared operational
        "dSAOperation"            ; DSA-specific operational

属性タイプの説明は、次の要素を含みます:

  • numericoid

    数値OIDは、Oracle Unified Directoryで属性タイプを一意に識別する場合に使用されます。仕様では数値OIDが必要ですが、Oracle Unified Directoryはまた、利便性とOracle Unified Directoryとの互換性を高めることを目的として、非数値OIDを許可しています。この場合、非数値OIDは、文字列-oidが続く属性タイプの名前と同じである必要があります。

  • NAME

    判読可能な名前のオプションのセットは、属性タイプを参照するのに使用されます。単一の名前がある場合は、それを一重引用符で囲む必要があります。複数の名前がある場合は、それぞれを空白で区切られた一重引用符で囲み、名前のセット全体をカッコで囲む必要があります。

  • DESC

    オプションの判読可能な説明です。説明がある場合は、一重引用符でそれを囲みます。

  • OBSOLETE

    オプションのOBSOLETEフラグは、属性タイプがアクティブかどうかを示すのに使用されます。属性タイプがOBSOLETEとしてマークされている場合、それは、Oracle Unified Directoryで作成された任意の新しい要素によって参照されるべきではないことを意味します。

  • SUP

    上位の属性タイプへのオプション参照です。上位のタイプがある場合、そのOIDまたは任意の判読可能な名前によって参照することができます。

  • EQUALITY

    オプションの等価一致ルールの定義です。特定の等価一致ルールが指定された場合は、そのOIDまたは任意の判読可能な名前によって参照することができます。等価一致ルールが指定されない場合は、属性タイプは、関連付けられた属性構文にデフォルトの等価一致ルールを使用します。属性構文がデフォルトの等価一致ルールを持たない場合は、等価一致操作はそのタイプの属性では許可されません。

  • ORDERING

    オプションの順序付け一致ルールの定義です。特定の順序付け一致ルールが指定された場合は、そのOIDまたは任意の判読可能な名前によって参照することができます。順序付け一致ルールが指定されない場合は、属性タイプは、関連付けられた属性構文にデフォルトの順序付け一致ルールを使用します。属性構文がデフォルトの順序付け一致ルールを持たない場合は、順序付け一致操作はそのタイプの属性では許可されません。

  • SUBSTR

    オプションの部分文字列一致ルールの定義です。特定の部分文字列一致ルールが指定された場合は、そのOIDまたは任意の判読可能な名前によって参照することができます。部分文字列一致ルールが指定されない場合は、属性タイプは、関連付けられた属性構文にデフォルトの部分文字列一致ルールを使用します。属性構文がデフォルトの部分文字列一致ルールを持たない場合は、部分文字列一致操作はそのタイプの属性では許可されません。

  • SYNTAX

    属性タイプで使用するためのオプションの属性構文です。指定する場合は、数値のOIDにする必要があります。構文識別子はまた、オプションで、OIDの直後に中カッコで囲まれた整数値(OIDの最後の桁と左中カッコの間に空白なし)を含むことができます。これは、そのタイプの属性の値の長さの最低限の上限を示唆するために使用されます。Oracle Unified Directoryでは、属性値に対して最大長の制限が適用されないため、長さが指定された場合、それは無視されます。

  • SINGLE-VALUE

    オプションのSINGLE-VALUEフラグは、そのタイプの属性が、それらが使用されているいずれのエントリでも、単一の値のみを持つことを許可されていることを示します。属性タイプの説明にこのフラグが存在しない場合は、そのタイプの属性は同じエントリで複数の異なる値を持つことを許可されています。

  • COLLECTIVE

    オプションのCOLLECTIVEフラグは、そのタイプの属性に、コレクションにおけるメンバーシップに基づいて値が割り当てられることを示します。集合属性は、RFC 3671 (http://www.ietf.org/rfc/rfc3671.txt) (LDAPの集合属性)で説明されており、Oracle Unified Directoryでサポートされている仮想属性のタイプの1つです。

  • NO-USER-MODIFICATION

    オプションのNO-USER-MODIFICATIONフラグは、そのタイプの属性の値が外部クライアントによって変更されない(つまり、値はOracle Unified Directory内の内部処理によってのみ変更できる)ことを示します。

  • USAGE

    属性タイプが使用される方法を示すオプションの使用方法の仕様です。次の属性使用方法が許可されています:

    • userApplications — ユーザー・データを格納するために使用されます。

    • directoryOperation — Oracle Unified Directory内の内部処理に必要なデータを格納するために使用されます。

    • distributedOperation — トポロジ内のサーバー間で同期させる必要がある操作データを格納するために使用されます。

    • dSAOperation — 特定のディレクトリ·サーバーに固有のものであり、トポロジ間で同期されるべきではない操作データを格納するために使用されます。

  • extensions

    属性タイプの拡張のオプション・セット。Oracle Unified Directoryは現在、属性タイプに次の拡張を使用しています。

    • X-ORIGIN — 属性タイプが定義されている場所の情報を提供します(たとえば、特定のRFCまたはインターネット・ドラフトで定義されているか、またはプロジェクト内で定義されているか)。

    • X-SCHEMA-FILE — 属性タイプの定義が含まれるスキーマ・ファイルを示します。

    • X-APPROX — その属性タイプでどの近似一致ルールを使用するかを示します。これが指定されている場合は、その値は登録されている一致ルールの名前またはOIDになります。

たとえば、次の例では、標準のuid属性タイプの説明を示します: 

( 0.9.2342.19200300.100.1.1 NAME 'uid' EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256}
X-ORIGIN 'RFC 4519' )

この場合、OIDは0.9.2342.19200300.100.1.1です。uidの単一の判読可能な名前があります。等価一致ではcaseIgnoreMatchルールを、部分文字列一致ではcaseIgnoreSubstringsMatchルールを使用する必要があります。属性タイプは、256文字の推奨上限値でディレクトリ文字列構文を使用しており、属性タイプの定義は、RFC 4519 (http://www.ietf.org/rfc/rfc4519.txt)から取得されています。説明または上位タイプは指定されていません。属性タイプは、OBSOLETE、SINGLE-VALUE、COLLECTIVEまたはNO-USER-MODIFICATIONにマークされていません。指定された順序付け一致ルールはありません。つまり、Oracle Unified Directoryは、ディレクトリ文字列構文で使用されているデフォルトの順序付けルールを使用します。近似一致ルールを指定するためのX-APPROX拡張はないので、ディレクトリ文字列構文のデフォルトの近似ルールがここでも使用されます。

10.3.2 属性タイプの継承の理解

属性タイプはその上位タイプとしての属性タイプを参照できます。これにより、その上位タイプから一致ルールおよび属性構文を継承できます

これには、2つの主な効果があります:

  • 下位の属性タイプが上位の属性タイプの定義をオーバーライドしない場合、上位の属性タイプの一致ルールと属性構文の仕様は、下位タイプで継承できます。たとえば、上位の属性タイプがIA5 String構文を使用する場合、その定義が代替構文を指定することによってそれをオーバーライドしないかぎり、下位の属性タイプもまたIA5 String構文を使用します。RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt)の第2.5.1項によると、下位タイプの構文が上位の属性タイプの改良版である場合(つまり、上位の属性タイプの構文の値のサブセットを許可する)にのみ、属性タイプはその上位のタイプとは異なる構文を持つことができます。

  • OID、上位の属性タイプに関連した任意の判読可能な名前、あるいは両方を、下位のタイプのすべてを一元的に参照するために使用することができます。たとえば、名前属性タイプは、cn、sn、c、l、st、o、ou、title、givenName、initials、generationQualifierおよびdmdName属性タイプの上位タイプとして参照されます。したがって、これらのタイプのいずれかを持つ任意の属性がtestの値を持つ場合、(name=test)のフィルタは、エントリに一致する必要があります。

下位の属性タイプは、その上位のタイプと異なる用法を持つことはできません。つまり、上位タイプがuserApplicationsの場合、下位タイプもまた、userApplicationsである必要があります。同様に、上位タイプがCOLLECTIVEを宣言している場合、サブタイプもCOLLECTIVEである必要がありますが、上位タイプがCOLLECTIVEでない場合は、下位タイプもCOLLECTIVEである必要はありません。

10.3.3 属性タイプの実装について

属性タイプの処理に使用されるメカニズムは、LDAPv3の仕様とは異なります。

メカニズムは、次のように異なります。

  • LDAPv3仕様では、下位の属性タイプは上位タイプと同じ構文またはその構文の改良版を持つ必要があると規定されています。属性構文がスーパータイプの構文の改良版であるかどうかを判断する方法がないため、Oracle Unified Directoryは、この制約を実行しません。

  • 同期サブシステムは、(たとえば、dSAOperationの使用方法を持つ属性タイプが同期されないように)属性使用方法を考慮に入れません。

10.4 オブジェクト・クラスの理解

オブジェクト・クラスは、エントリに格納できるデータ型を制御するために使用できる属性タイプの基本的な名前付きセットです。

ノート:

「オブジェクト・クラス」と「オブジェクトクラス」(単語の間の中黒の有無)は、一般的に区別しないで使用されます。

次の項では、オブジェクト・クラスについて説明します:

10.4.1 オブジェクト・クラスの説明形式の理解

オブジェクト・クラスの説明形式およびこれに含まれている様々な要素について学習します。

RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt)の第4.1.1項に、次の例に示すオブジェクト・クラスの説明形式について記載されています。 

ObjectClassDescription = LPAREN WSP
numericoid                 ; object identifier
[ SP "NAME" SP qdescrs ]   ; short names (descriptors)
[ SP "DESC" SP qdstring ]  ; description
[ SP "OBSOLETE" ]          ; not active
[ SP "SUP" SP oids ]       ; superior object classes
[ SP kind ]                ; kind of class
[ SP "MUST" SP oids ]      ; attribute types
[ SP "MAY" SP oids ]       ; attribute types
extensions WSP RPAREN
kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"

オブジェクト・クラスの説明は、次の要素を含みます:

  • numericoid

    数値OIDは、Oracle Unified Directoryでオブジェクト・クラスを一意に識別する場合に使用されます。仕様では数値OIDが必要ですが、Oracle Unified Directoryはまた、利便性とOracle Unified Directoryとの互換性を高めることを目的として、非数値OIDを許可しています。この場合、非数値OIDは、文字列-oidが続くオブジェクト・クラスの名前と同じである必要があります。

  • NAME

    オブジェクト・クラスを参照するのに使用される判読可能な名前のオプションのセットです。単一の名前がある場合は、それを一重引用符で囲む必要があります。複数の名前がある場合は、それぞれを空白で区切られた一重引用符で囲み、名前のセット全体をカッコで囲む必要があります。

  • DESC

    オプションの判読可能な説明です。説明がある場合は、一重引用符でそれを囲みます。

  • OBSOLETE

    オプションのOBSOLETEフラグは、オブジェクト・クラスがアクティブかどうかを示すのに使用されます。オブジェクト・クラスがOBSOLETEとしてマークされている場合、それは、Oracle Unified Directoryで作成されたいずれの新しい要素によっても参照されるべきではないことを意味します。

  • SUP

    オブジェクト・クラスに対して1つ以上の上位クラスのオプションのセットです。

    ノート:

    技術的な仕様では、オブジェクト·クラスは、複数の上位クラスを持つことができますが、Oracle Unified Directoryは現在のところ、単一の上位クラスのみをサポートしています。

    この場合、SUPキーワードの後には、空白および上位クラスの名前またはOIDが続きます。複数の上位クラスがある場合は、それらをドル記号で区切り、上位クラスのセット全体をカッコで囲む必要があります。

  • kind

    定義されているオブジェクト・クラスの種類を指定するオプションのキーワードです。これが指定されている場合は、ABSTRACT、STRUCTURALまたはAUXILIARYのいずれかである必要があります。値が指定されていない場合は、オブジェクト・クラスはSTRUCTURALと見なされます。

  • MUST

    そのオブジェクト・クラスを持つエントリで存在することが要求されている(すなわち、少なくとも1つの値を持つ)属性の属性タイプのオプションのセットです。単一の必須の属性のみの場合、MUST キーワードの後に属性タイプの名前またはOIDが続く必要があります。複数の必須属性タイプがある場合は、それらをドル記号で区切り、必須属性タイプのセット全体をカッコで囲む必要があります。

  • MAY

    そのオブジェクト・クラスを持つエントリに存在することが許可されている(必須ではない)属性のオプションの属性タイプのオプションのセットです。単一のオプションの属性のみの場合、MAY キーワードの後に属性タイプの名前またはOIDが続く必要があります。複数のオプションの属性タイプがある場合は、それらをドル記号で区切り、オプションの属性タイプのセット全体をカッコで囲む必要があります。

  • extensions

    オブジェクト・クラスの拡張のオプション・セット。Oracle Unified Directoryは現在、オブジェクト・クラスに次の拡張を使用しています。

    • X-ORIGIN — オブジェクト・クラスが定義されている場所の情報を提供します(たとえば、特定のRFCまたはインターネット・ドラフト由来かどうか、またはプロジェクト内で定義されているかどうか)。

    • X-SCHEMA-FILE — オブジェクト・クラスの定義が含まれるスキーマ・ファイルを示します(この拡張は、一般に内部目的でのみ使用され、クライアントに公開されています)。

たとえば、次の例では、標準のpersonオブジェクト・クラスのオブジェクト・クラスの説明を示します: 

( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description )
X-ORIGIN 'RFC 4519' )

この場合、OIDは2.5.6.6です。personの単一の判読可能な名前があります。上位クラスはtopです。種類はSTRUCTURALです。personオブジェクト・クラスを含むすべてのエントリは、snおよびcn属性を含むことが必須で、userPassword、telephoneNumber、seeAlsoおよびdescription属性を含むことが可能です。オブジェクト・クラスの定義は、RFC 4519 (http://www.ietf.org/rfc/rfc4519.txt)から取得されています。説明はなく、オブジェクト・クラスはOBSOLETEと見なされません。

10.4.2 オブジェクト・クラスの種類について

オブジェクト・クラスの様々な種類およびJavaプログラミング言語で使用されるモデルとの類似点について学習します。

「オブジェクト・クラスの説明形式の理解」で説明されているように、すべてのオブジェクト・クラスは、ABSTRACT、STRUCTURALまたはAUXILIARYのいずれかの種類である必要があります。

  • ABSTRACTオブジェクト・クラスは、他のオブジェクト・クラスによって拡張されることのみが意図されています。エントリに、その抽象クラスから導出される構造または補助クラスが含まれていないかぎり、エントリはいずれの抽象クラスも含むことができません(つまり、その継承連鎖で抽象クラスを持つ非抽象オブジェクト・クラスを含みます)。すべてのエントリは、構造化クラスの継承連鎖に少なくともtop抽象オブジェクト・クラスを含む必要があります。それらは、それらの構造化クラスまたはいずれかの補助クラスの継承連鎖に、別の抽象クラスを含む可能性もあるし、含まない可能性もあります。

  • STRUCTURALオブジェクト・クラスは、エントリで表されるものの中核を定義することが意図されています。すべてのエントリには、ただ1つの構造化オブジェクト・クラス連鎖が含まれている必要があり、その連鎖のルートは、最終的にはtop抽象オブジェクト・クラスである必要があります。エントリの構造化オブジェクト・クラスを変更することはできません。

  • AUXILIARYオブジェクト・クラスは、エントリの追加クオリティを定義することを意図しています。エントリには、ゼロ個以上の補助クラスを含めることができ、エントリに関連付けられた補助クラスのセットは時間の経過とともに変化します。

オブジェクト・クラスの種類によって表されるモデルは、Javaプログラミング言語で使用されるモデルに整然と変換されます。抽象LDAPオブジェクト·クラスはJavaの抽象クラスに直接マッピングし、補助LDAPオブジェクト·クラスは、Javaのインタフェースに直接マッピングし、構造化LDAPオブジェクト·クラスは、Javaの具象(非抽象)クラスに直接マッピングします。Javaクラスでは、ただ1つのスーパークラスを拡張する必要がありますが、任意の数のインタフェースを実装することができます。同様に、LDAPエントリでは、ただ1つの構造化クラス連鎖が含まれている必要がありますが、任意の数の補助クラス連鎖を含めることができます。また、Java抽象クラスを直接インスタンス化することは不可能であるように、抽象オブジェクト・クラスのみを含むLDAPエントリを作成することもできません。

Oracle Directory Server Enterprise Editionは、オブジェクト・クラスの種類に対してここで示されている制限の多くを適用しません。特に、任意の構造化オブジェクト·クラスのチェーンを含んでいないエントリの作成を許可し、また、複数の構造化オブジェクト・クラスのチェーンを含むエントリの作成も許可します。つまり、Oracle Directory Server Enterprise Editionを使用するデプロイメントには、この制約に違反するエントリを含めることができます。Oracle Unified Directoryでは、デフォルトではこの動作を許可していませんが、既存のOracle Unified Directoryのデプロイメントとの互換性のため、この制約に違反するエントリが許可されるようにOracle Unified Directoryを構成し、オプションでこの状況が検出されるたびにOracle Unified Directoryのエラー・ログにメッセージを書き込むようにすることができます。しかし、正確に1つの構造化オブジェクト·クラスが含まれていないエントリがある場合、この制約に依存するDITコンテンツ・ルールのようないくつかのスキーマ要素は、すべてのケースで期待どおりに動作するとはかぎりません。このようなスキーマ違反を受け入れるようにOracle Unified Directoryを構成するには、グローバル構成のsingle-structural-objectclass-behaviorプロパティを設定します。詳細は、『Oracle Unified Directory構成リファレンス』のグローバル構成に関する項を参照してください。

10.4.3 オブジェクト・クラスの継承について

オブジェクト・クラスでの継承およびオブジェクト・クラスの継承の様々な種類に関して存在する制限事項について学習します。

「オブジェクト・クラスの説明形式の理解」で説明されているように、オブジェクト・クラスは、ゼロ個以上の上位クラス(現在は、Oracle Unified Directoryは最大で1つの上位クラスをサポートしています)を持つことができます。オブジェクト・クラスが上位クラスを参照する場合、その上位クラスに関連付けられた必須およびオプションの属性のすべては、下位クラスにも関連付けられます。

オブジェクト・クラスの継承には次の制約があります:

  • ABSTRACTオブジェクト・クラスは、別の属性クラスからのみ継承することができます。それらは、構造化または補助クラスの下位であることはできません。

  • STRUCTURALオブジェクト・クラスは、抽象クラスまたは別の構造化クラスからのみ継承することができます。それらは、補助オブジェクト・クラスの下位であることはできません。

  • AUXILIARYオブジェクト・クラスは、抽象または別の補助クラスからのみ継承することができます。それらは、構造化オブジェクト・クラスの下位であることはできません。

  • すべてのSTRUCTURALオブジェクト・クラスは、最終的にトップの抽象オブジェクト・クラスから継承する必要があります。これによる実際の影響は、Oracle Unified Directoryのすべてのエントリがtopオブジェクト・クラスを含む必要があり、また、topオブジェクト・クラスに要求されるobjectClass属性タイプを含む必要があるということです。

10.4.4 Directory Serverのオブジェクト・クラスの実装について

オブジェクト・クラスの処理に使用されるメカニズムは、LDAPv3の仕様とは異なります。

このようなメカニズムでは、オブジェクト・クラスで最大1つの上位クラスを持つことが許可される一方で、この仕様により、複数の上位クラスが許可される場合もあります。

10.5 名前書式の理解

名前書式は、Oracle Unified Directoryでエントリに名前を付けるためのメカニズムを定義するために使用できます。特に、名前書式は、特定の構造化オブジェクト・クラスを持つエントリのRDNに存在している必要のある1つ以上の属性タイプを指定します。名前書式では、RDNにオプションで存在可能なゼロ個以上の属性タイプを指定することもできます。

Oracle Unified Directoryのスキーマで定義された各構造化オブジェクト·クラスは、1つ以上の名前書式に関連付けることができます。名前書式が、特定の構造化オブジェクト・クラスに定義されている場合、関連付けられている名前書式は、そのオブジェクト・クラスを含むエントリに対するDNの追加または変更操作で適用されます。構造化オブジェクト·クラスが、名前書式に関連付けられていない場合は、ターゲット・エントリに存在することが許可されている任意の属性タイプはネーミング属性タイプとして使用することができます。

RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt)の第4.1.7.2項に、次の例に示す名前書式の説明形式について記載されています。 

NameFormDescription = LPAREN WSP
numericoid                 ; object identifier
[ SP "NAME" SP qdescrs ]   ; short names (descriptors)
[ SP "DESC" SP qdstring ]  ; description
[ SP "OBSOLETE" ]          ; not active
SP "OC" SP oids             ; structural object classes
SP "MUST" SP oids          ; attribute types
[ SP "MAY" SP oids ]       ; attribute types
extensions WSP RPAREN      ; extensions

名前書式の説明は、次の要素を含みます:

  • numericoid

    数値OIDは、Oracle Unified Directoryで名前書式を一意に識別する場合に使用されます。仕様では数値OIDが必要ですが、Oracle Unified Directoryはまた、利便性を高めること目的として、非数値OIDを許可します。この場合、非数値OIDは、文字列-oidが続く名前書式の名前と同じである必要があります。

  • NAME

    名前書式を参照するのに使用される判読可能な名前のオプションのセットです。単一の名前がある場合は、それを一重引用符で囲む必要があります。複数の名前がある場合は、それぞれを空白で区切られた一重引用符で囲み、名前のセット全体をカッコで囲む必要があります。

  • DESC

    オプションの判読可能な説明です。説明がある場合は、一重引用符でそれを囲みます。

  • OBSOLETE

    オプションのOBSOLETEフラグは、名前書式がアクティブかどうかを示すのに使用されます。名前書式がOBSOLETEとしてマークされている場合、Oracle Unified Directory内で有効にしてはならず、またそれに依存する他の要素を作成することが可能であってはいけません。

  • OC

    名前書式が関連付けられている構造化オブジェクト・クラスの名前またはOIDです。

  • MUST

    指定された構造化クラスを持つエントリのRDNに存在する必要がある1つ以上の属性タイプの名前またはOIDです。単一の必須属性タイプのみの場合は、その名前またはOIDのみを指定する必要があります。複数の必須属性タイプがある場合は、それらを空白とドル記号で区切り、必須属性タイプのセット全体をカッコで囲む必要があります。

  • MAY

    指定された構造化クラスを持つエントリのRDNにオプションで存在可能なゼロ個以上の属性タイプの名前またはOIDです。単一のオプションの属性タイプのみがある場合は、その名前またはOIDのみを指定する必要があります。複数のオプションの属性タイプがある場合は、それらを空白およびドル記号で区切り、オプションの属性タイプのセット全体をカッコで囲む必要があります。

  • extensions

    名前書式の拡張のオプション・セット。Oracle Unified Directoryは現在、名前書式に次の拡張を使用しています。

    • X-ORIGIN — 名前書式が定義されている場所の情報を提供します(たとえば、特定のRFCまたはインターネット・ドラフト由来かどうか、またはプロジェクト内で定義されているかどうか)。

    • X-SCHEMA-FILE — 名前書式の定義が含まれるスキーマ・ファイルを示します(この拡張は、一般に内部目的でのみ使用され、クライアントに公開されています)。

たとえば、次に、RFC 4403 (http://www.ietf.org/rfc/rfc4403.txt)で定義されているuddiBusinessEntityNameForm名前書式の名前書式の説明を示します。 

( 1.3.6.1.1.10.15.1 NAME 'uddiBusinessEntityNameForm'
OC uddiBusinessEntity MUST ( uddiBusinessKey ) X-ORIGIN 'RFC 4403' )

この場合、数値OIDは1.3.6.1.1.10.15.1で、判読可能な名前はuddiBusinessEntityNameFormです。uddiBusinessEntity構造化オブジェクト・クラスを持つエントリは、唯一のRDN属性タイプとしてuddiBusinessKeyを使用することが必要です。説明はなく、関連付けられたエントリにオプションで含まれるその他の属性タイプもありません。名前書式はOBSOLETEにマークされません。

10.6 DITコンテンツ・ルールの概要

DITコンテンツ・ルールは、エントリに表示できるコンテンツを定義するメカニズムを提供します。その構造化オブジェクト・クラスに基づいて、最大で1つのDITコンテンツ・ルールをエントリに関連付けることができます。エントリにそのようなルールが存在する場合、エントリに存在する必要がある(存在する可能性がある、または存在していはいけない)属性タイプと同様に、含む可能性のある補助クラスを定義するために、そのエントリに含まれるオブジェクト・クラスとともに動作します。

次の項では、DITコンテンツ・ルールを説明します:

10.6.1 DITコンテンツ・ルールの説明形式の理解

DITコンテンツ・ルールの説明形式およびこれに含まれている様々な要素について学習します。

RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt)の第4.1.6項に、DITコンテンツ・ルールの説明形式について記載されています。 

DITContentRuleDescription = LPAREN WSP
numericoid                 ; object identifier
[ SP "NAME" SP qdescrs ]   ; short names (descriptors)
[ SP "DESC" SP qdstring ]  ; description
[ SP "OBSOLETE" ]          ; not active
[ SP "AUX" SP oids ]       ; auxiliary object classes
[ SP "MUST" SP oids ]      ; attribute types
[ SP "MAY" SP oids ]       ; attribute types
[ SP "NOT" SP oids ]       ; attribute types
extensions WSP RPAREN      ; extensions

DITコンテンツ・ルールの説明は、次の要素を含みます:

  • numericoid

    DITコンテンツ・ルールに関連付けられている構造化オブジェクト・クラスの数値OIDです。仕様では、数値OIDを必要としますが、このnumericoidは関連付けられているオブジェクト・クラスに指定されているOIDと一致する必要があるので、オブジェクト・クラスのOIDが非数値の場合は、OIDも同様である必要があります。

  • NAME

    DITコンテンツ・ルールを参照するために使用される判読可能な名前のオプションのセットです。単一の名前がある場合は、それを一重引用符で囲む必要があります。複数の名前がある場合は、それぞれを空白で区切られた一重引用符で囲み、名前のセット全体をカッコで囲む必要があります。

  • DESC

    オプションの判読可能な説明です。説明を指定する場合は、一重引用符で囲んでください。

  • OBSOLETE

    オプションのOBSOLETEフラグは、DITコンテンツ・ルールがアクティブかどうかを示すのに使用されます。DITコンテンツ・ルールがOBSOLETEとしてマークされている場合は、Oracle Unified Directory内で有効化しないでください。

  • AUX

    関連付けられた構造化クラスを持つエントリに存在することができる補助オブジェクト・クラスのオプションのリストです。値が指定されていない場合、そのようなエントリは、いずれの補助オブジェクト・クラスも持つことを許可されていません。値は、1つ以上の許可されている補助クラスの名前またはOIDとして指定される必要があります。複数の補助クラスが許可されている場合は、それらを空白およびドル記号で区切り、名前のセット全体をカッコで囲みます。

  • MUST

    関連付けられた構造化クラスを持つエントリに存在することが必要な属性タイプのオプションのリストです。これは、オブジェクト・クラスによって要求される属性タイプに加えてエントリに追加されます、これらの追加属性タイプは、それらのオブジェクト・クラスによって許可される必要はありません。値は、必須属性タイプの1つ以上の名前またはOIDとして指定される必要があります。複数の補助クラスが要求されている場合は、それらを空白およびドル記号で区切り、必須属性タイプのセット全体をカッコで囲みます。

  • MAY

    関連付けられた構造化クラスを持つエントリにオプションで存在することができる属性タイプのオプションのリストです。これは、オブジェクト・クラスによって許可された属性タイプに加えてエントリに追加されます。値は、オプションの属性タイプの1つ以上の名前またはOIDとして指定される必要があります。複数のオプションの補助クラスがある場合は、それらを空白およびドル記号で区切り、オプションの属性タイプのセット全体をカッコで囲みます。

  • NOT

    関連付けられた構造化クラスを持つエントリに存在することが禁止されている属性タイプのオプションのリストです。このリストは、構造化クラスまたは許可されている補助クラスで要求されているいずれの属性タイプも含むことはできませんが、それらのいずれかのオブジェクト・クラスによって許可される属性タイプの混入を防ぐために使用することができます。値は、禁止属性タイプの1つ以上の名前またはOIDとして指定される必要があります。複数のタイプが禁止されている場合は、それらを空白およびドル記号で区切り、禁止属性タイプのセット全体をカッコで囲みます。

  • extensions

    DITコンテンツ・ルールの拡張のオプション・セット。Oracle Unified Directoryは現在、DITコンテンツ・ルールに次の拡張を使用しています。

    • X-ORIGIN — DITコンテンツ・ルールが定義されている場所の情報を提供します(たとえば、特定のRFCまたはインターネット・ドラフト由来かどうか、またはプロジェクト内で定義されているかどうか)。

    • X-SCHEMA-FILE — DITコンテンツ・ルールの定義が含まれるスキーマ・ファイルを示します(この拡張は、一般に内部目的でのみ使用され、クライアントに公開されています)。

次の例では、DITコンテンツ・ルールの説明を示しています:

( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPersonContentRule'
AUX ( posixAccount $ shadowAccount $ authPasswordObject )
MUST uid )

この場合、数値OIDは2.16.840.1.113730.3.2.2で、inetOrgPerson構造化オブジェクト・クラスのOIDです。inetOrgPersonContentRuleの判読可能な名前を持ち、説明はありません。inetOrgPersonオブジェクト・クラスを含むエントリは、posixAccount、shadowAccountおよびauthPasswordObject補助クラスを含むことができ、それらのエントリはuid属性タイプを含む必要があります。この例では、OBSOLETEにマークされず、追加のオプションの属性タイプまたは禁止属性タイプは定義されず、拡張も含まれません。

10.6.2 DITコンテンツ・ルールの実装について

DITコンテンツ・ルールを処理するために使用されるメカニズムは、LDAPv3の仕様とは異なります。DITコンテンツ・ルールの実装の重要性について学習します。

LDAPv3の仕様では、エントリで使用されている構造化オブジェクト・クラスが、対応するDITコンテンツ・ルールを持たない場合、そのエントリはいずれの補助オブジェクト・クラスも含むことはできないと規定されています。Oracle Directory Server Enterprise EditionはDITコンテンツ・ルールをサポートしないため、Oracle Unified Directoryは対応するDITコンテンツ・ルールがないエントリで補助オブジェクト・クラスの使用を妨げません。特定のエントリのタイプに補助クラスが含まれないようにすることが望ましい場合、DITコンテンツ・ルールは、補助クラスを許可しないDITコンテンツ・ルールを作成して、適切な構造化オブジェクト·クラスを持つエントリを処理する必要があります。

10.7 DIT構造ルールの理解

DIT構造ルールは、ディレクトリ・データの許可された階層構造を定義するために使用されます。特に、それらは指定された構造化オブジェクト・クラスを持つエントリの直接の子として存在することができるエントリのタイプを指定することを可能にします。たとえば、inetOrgPerson構造化クラスを持つエントリのみがorganizationalUnit構造化オブジェクト・クラスを持つエントリの直接の子になることができます。

DIT構造ルールは、それら自身で階層になっています。各DIT構造ルールは、整数値であるルールIDが割り当てられ、また、名前書式(1つ以上の構造化オブジェクト・クラスにリンクします)に関連付けられています。DIT構造ルールは、1つ以上上位のDIT構造ルールを参照することができ、これは、データの階層を制御するためのメカニズムを提供します。DIT構造ルールがいずれの上位ルールも指定しない場合は、その関連付けられた構造化オブジェクト・クラスを含むエントリは、関連付けられたスキーマのルートに存在することが許可されています。DIT構造が1つ以上の上位ルールを指定する場合は、関連付けられた構造化オブジェクト・クラスを持つエントリは、それらの上位ルールのいずれかの構造化オブジェクト・クラスを含むエントリの下にのみに存在することが許可されています。

次の項では、DIT構造ルールを説明します:

10.7.1 DIT構造ルールの説明形式の理解

DIT構造ルールの説明形式およびこれに含まれている様々な要素について学習します。

RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt)の第4.1.7.1項に、次に示すDIT構造ルールの説明形式について記載されています。 

DITStructureRuleDescription = LPAREN WSP
ruleid                     ; rule identifier
[ SP "NAME" SP qdescrs ]   ; short names (descriptors)
[ SP "DESC" SP qdstring ]  ; description
[ SP "OBSOLETE" ]          ; not active
SP "FORM" SP oid           ; NameForm
[ SP "SUP" ruleids ]       ; superior rules
extensions WSP RPAREN      ; extensions
ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
ruleidlist = ruleid *( SP ruleid )
ruleid = number

DIT構造ルールの説明は、次の要素を含みます:

  • ruleid

    DIT構造ルールに割り当てられた整数のルールIDです。これは、スキーマ内のすべての他のDIT構造ルールの中で一意である必要があります。

  • NAME

    DIT構造ルールを参照するのに使用される判読可能な名前のオプションのセットです。単一の名前がある場合は、それを一重引用符で囲む必要があります。複数の名前がある場合は、それぞれを空白で区切られた一重引用符で囲み、名前のセット全体をカッコで囲む必要があります。

  • DESC

    オプションの判読可能な説明です。説明を指定する場合は、一重引用符で囲んでください。

  • OBSOLETE

    オプションのOBSOLETEフラグは、DIT構造ルールがアクティブかどうかを示すのに使用されます。OBSOLETEにマークされている場合、エントリの作成時または移動時に、このルールは考慮されません。

  • FORM

    DIT構造ルールが関連付けられている名前書式の名前またはOIDです。「DIT構造ルールの理解」で述べられているように、名前書式はDIT構造ルールと構造化オブジェクト・クラスを関連付けます。

  • SUP

    DIT構造ルールの上位のルールIDのオプションのセットです。複数の上位のルールIDがある場合は、空白でそれらを区切り、上位のルールIDのセット全体をカッコで囲みます。複数のDIT構造ルールは、上位のルールIDの重複セットを使用することが許容されます。

  • extensions

    DIT構造ルールの拡張のオプション・セット。Oracle Unified Directoryは現在、DIT構造ルールに次の拡張を使用しています。

    • X-ORIGIN — DIT構造ルールが定義されている場所の情報を提供します(たとえば、特定のRFCまたはインターネット・ドラフト由来かどうか、またはプロジェクト内で定義されているかどうか)。

    • X-SCHEMA-FILE — DIT構造ルールの定義が含まれるスキーマ・ファイルを示します(この拡張は、一般に内部目的でのみ使用され、クライアントに公開されています)。

次の例は、uddiContactStructureRule DIT構造ルールのDIT構造ルールの定義を示します: 

dITStructureRule:
( 2 NAME 'uddiContactStructureRule' FORM uddiContactNameForm SUP ( 1 )
X-ORIGIN 'RFC 4403' )

この場合、ルールIDは2で、判読可能な名前はuddiContactStructureRuleです。uddiContactNameForm名前書式に関連付けられ(uddiContactオブジェクト・クラスにリンクします)、1の上位のルールIDを持ちます。RFC 4403 (http://www.ietf.org/rfc/rfc4403.txt)で定義されました。説明はありませんし、OBSOLETEにマークされてもいません。

10.7.2 DIT構造ルールと複数のスキーマの理解

DIT構造ルールは、Oracle Unified Directory階層に制約を配置するためのメカニズムを提供することができますが、それらの効用を最大化するためには、複数のスキーマのサポートとともにそれらを使用する必要があります。

たとえば、2つの分岐(ou=People,dc=example,dc=comおよびou=Groups,dc=example,dc=com)が下にあるdc=example,dc=comのネーミング・コンテキストを持つディレクトリについて考えてみます。ou=People分岐の下のinetOrgPersonエントリのみ、およびou=Groups分岐の下のgroupOfNamesエントリのみを許可したい場合は、ou=People分岐およびou=Groups分岐を管理する異なるスキーマがある場合にかぎり、完全にそれを達成することができます。

ディレクトリ・サーバー全体を管理する単一のスキーマがあった場合は、4つのDIT構造ルールがあるだろうことが想像できます:

  • dITStructureRule: (11 NAME 'domainStructureRule' FORM domainNameForm)

  • dITStructureRule: (12 NAME 'organizationalUnitStructureRule' FORM organizationalUnitNameForm SUP 11)

  • dITStructureRule: (13 NAME 'inetOrgPersonStructureRule' FORM inetOrgPersonNameForm SUP 12)

  • dITStructureRule: (14 NAME 'groupOfNamesStructureRule' FORM groupOfNamesNameForm SUP 12)

DIT構造ルールのこのセットは、前述の構造を許可しますが、ou=People分岐の下のグループ・エントリの作成、およびou=Groups分岐の下のユーザー・エントリの作成も許可します。DIT構造ルールを使用してそれを防ぐ唯一の方法は、ou=People分岐およびou=Groups分岐に別々のスキーマを定義し、ou=People分岐のスキーマにはinetOrgPersonStructureRuleルールのみを定義し、ou=Groups分岐のスキーマにはgroupOfNamesStructureRuleのみを定義します。

10.8 一致ルールの使用の理解

一致ルールの使用は、拡張一致フィルタ・コンポーネントで検索リクエストを処理する際に、特定の一致ルールとともに使用できる属性タイプを指定するために使用することができます。その拡張一致コンポーネントが、属性タイプおよび一致ルールIDの両方を含む場合は、Oracle Unified Directoryは関連付けられている一致ルールに対する一致ルールの使用があるかを確認し、ある場合は、指定された属性タイプがその一致ルールで使用することができることを確認します。

RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt)の第4.1.4項に、次に例を示す一致ルールの使用の説明形式について記載されています。 

MatchingRuleUseDescription = LPAREN WSP
numericoid                 ; object identifier
[ SP "NAME" SP qdescrs ]   ; short names (descriptors)
[ SP "DESC" SP qdstring ]  ; description
[ SP "OBSOLETE" ]          ; not active
SP "APPLIES" SP oids       ; attribute types
extensions WSP RPAREN      ; extensions

一致ルールの使用の説明は、次の要素を含みます:

  • numericoid

    一致ルールの使用が関連付けられている一致ルールの数値OIDです。特定の一致ルールに関連付けられた一致ルールの使用は1つのみです。

  • NAME

    一致ルールの使用を参照するのに使用できる判読可能な名前のオプションのセットです。単一の名前がある場合は、それを一重引用符で囲む必要があります。複数の名前がある場合は、それぞれを一重引用符で囲み、空白で区切り、名前のセット全体をカッコで囲む必要があります。

  • DESC

    オプションの判読可能な説明です。説明がある場合は、それを一重引用符で囲む必要があります。

  • OBSOLETE

    オプションのOBSOLETEフラグは、一致ルールの使用がアクティブかどうかを示すのに使用されます。OBSOLETEにマークされている場合、拡張一致フィルタを許可するかどうかを判断する際に、このルールは考慮されません。

  • APPLIES

    関連付けられた一致ルールとともに使用される1つ以上の属性タイプのセットです。関連付けられた属性タイプがある場合は、その名前またはOIDが使用されます。複数の属性タイプがある場合は、それらを空白およびドル記号で区切り、関連付けられた属性タイプのセット全体をカッコで囲みます。

  • extensions

    一致ルールの使用の拡張のオプション・セット。Oracle Unified Directoryは現在、一致ルールの使用に次の拡張を使用しています。

    • X-ORIGIN — 一致ルールが定義されている場所の情報を提供します(たとえば、特定のRFCまたはインターネット・ドラフト由来かどうか、またはプロジェクト内で定義されているかどうか)。

    • X-SCHEMA-FILE — 一致ルールの定義が含まれるスキーマ・ファイルを示します(この拡張は、一般に内部目的でのみ使用され、クライアントに公開されています)。

次の例は、一致ルールの使用の説明を示しています:

( 1.3.6.1.4.1.26027.1.999.10 NAME 'testAddMRUSuccessful' APPLIES cn )

この場合、数値OIDは1.3.6.1.4.1.26027.1.999.10、単一の判読可能な名前はtestAddMRUSuccessfulであり、cn属性とともに使用できます。説明はなく、OBSOLETEにマークされておらず、そしていずれの拡張もありません。