| Oracle® Fusion Middleware Oracle Unified Directory管理者ガイド 11g リリース2 (11.1.2) B72794-02 |
|
 前 |
 次 |
この章では、一般的なスキーマ要素を説明し、これらのスキーマ要素がOracle Unified Directoryで使用される方法を示します。
この章の内容は次のとおりです:
ldapsearchコマンドを使用してスキーマを表示する説明については、第27.4.1項「属性タイプの管理」および第27.4.2項「オブジェクト・クラスの管理」を参照してください。
一致ルールは、同じ属性の2つの値を比較するため、すなわち、それらで一致操作を実行するためにOracle Unified Directoryで使用されます。一致ルールには、次に示すようないくつかの異なるタイプがあります
この種の一致ルールは、2つの値が論理的に等価かどうかを決定するために使用されます。等価一致ルールの実装ごとに、この決定に使用される基準は異なることがあります(たとえば、大文字/小文字の相違を無視するかどうか、どのスペースが重要かの決定など)。
この種の一致ルールは、2つの値の相対順序を決定するために(たとえば、次以上または次以下の検索の評価時や、結果をソートする必要があるときなど)使用されます。
この種の一致ルールは、所定の部分文字列アサーションが特定の値に一致するかどうかを決定するために使用されます。部分文字列アサーションは、最大で1つのsubInitial要素、ゼロ個以上のsubAny要素、および最大で1つのsubFinal要素というセットの少なくとも1つの要素で構成されています。
この種の一致ルールは、2つの値がおおよそ等価かどうかを決定するために使用されます。これは、多くの場合、「類似しているものを検索する」などの種類のファジー・アルゴリズムに基づきます。近似一致ルールは正式なLDAP仕様の一部とはなっていませんが、Oracle Unified Directoryでは柔軟性を高めるために採用しています。
次の項では、一致ルールを説明します:
一致ルールの説明形式は、Augmented Backus-Naur Form (ABNF)で、RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt)の第4.1.3項で説明されています。ABNFに関する詳細は、RFC 4234 (http://www.ietf.org/rfc/rfc4234.txt)およびRFC 5234 (http://www.ietf.org/rfc/rfc5234.txt)を参照してください。これは、スキーマ・サブエントリのmatchingRules属性で一致ルールを表示するのに使用される形式で、一致ルールと関連付けることのできるプロパティを示します。次の例は、一致ルールの説明形式の定義を示します:
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つの説明があり、それが存在する場合は、一重引用符で囲む必要があります。
OBSOLETEOBSOLETEフラグは、この一致ルールが使用可能であると見なすかどうかを示します。一致ルールがOBSOLETEにマークされた場合、この一致ルールを参照する、新しい属性タイプまたは一致ルールの使用方法を作成することはできません。
SYNTAX構文要素は、一致ルールが関連付けられている属性構文を識別します。これは、一致ルールが操作する値に対して許容可能な形式を示すために使用されます。属性構文に関する詳細は、第9.2項「属性構文の理解」を参照してください。構文OIDは、すべての一致ルールの説明に含まれている必要があります。
一致ルールの拡張は、標準の定義に含まれない可能性があるその一致ルールの他のプロパティを識別するために使用することができます。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(ディレクトリ文字列構文)です。拡張はありません。
LDAPで定義されている一致ルールは多数あります。それらは、コア・プロトコル仕様と同様に他の関連するRFCおよびインターネット・ドラフトの両方で定義されています。この一致ルールの多くは、RFC 4517 (http://www.ietf.org/rfc/rfc4517.txt)「LDAP構文と一致ルール」の第4.2項で定義されています。もっとも一般的に使用される一致ルールのいくつかを次に示します:
caseIgnoreMatch、caseIgnoreOrderingMatch、caseIgnoreSubstringsMatchこれらはそれぞれ、等価、順序付け、部分文字列一致ルールで、大/小文字の違いを無視し、複数の連続した空白を単一の空白として扱います。
caseExactMatch、caseExactOrderingMatch、caseExactSubstringsMatchこれらはそれぞれ、等価、順序付け、部分文字列の一致ルールで、大/小文字を区別をする方法で値を扱いますが、複数の連続した空白は、単一の空白として扱います。
octetStringMatch、octetStringOrderingMatch、octetStringSubstringsMatchこれらはそれぞれ、等価、順序付け、部分文字列の一致ルールで、バイト単位で値の比較を実行します(それらを文字列ではなくバイナリ・データとして扱います)。
numericStringMatch、numericStringOrderingMatch、numericStringSubstringsMatchこれらはそれぞれ、等価、順序付けおよび部分文字列の一致ルールで、数値の桁で始まり、数値の桁および空白のみを含む値に対して操作が行われます。これらの一致ルールでマッチングを実行するときは、空白は無視されます。
distinguishedNameMatchこれは、等価一致ルールで、識別名(DN)値に対して操作が行われます。DNコンポーネントを区切るカンマやセミコロンの前後の空白、RDNコンポーネントを区切る正符号の前後の空白、およびRDN属性タイプ名をそれらの対応する値から区切る等号の前後の空白を無視します。大/小文字の違いは、属性タイプ名では無視されます。属性値の等価一致は、対応する属性タイプ用の等価一致ルールを使用して実行されます。
doubleMetaphoneApproximateMatchこれは近似一致ルールで、比較「のような」ことを実行するためにdouble metaphoneアルゴリズムを使用します。この一致ルールは公式のLDAP仕様の一部ではなく、柔軟性の向上のためにOracle Unified Directoryに含まれていることに注意してください。
Oracle Unified Directoryは、ここで定義されているように、「一般化時間」(付録D)属性(relativeTimeLTOrderingMatchおよびrelativeTimeGTOrderingMatch)の相対日付で一致を実行するための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構文を持つ属性に適用されますが、一般化時間の文字列を取ることはありません。かわりに、[+|-]数値[単位]の形式でオフセットをとります:
+|-過去または将来の時間を指定します。正のオフセット(+)は、現在の時間と比較して将来の時間を計算し、負のオフセット(-)は現在の時間と比較して過去の時間を計算します。デフォルトの値は正(+)です。
正の整数として、時間単位の数値を指定します。
単一の文字で時間の単位を指定します(秒、分、時間、日または週はそれぞれ、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)
Oracle Unified Directoryは、「一般化時間」(付録D)属性の日付で部分文字列一致を実行するために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
ほとんどの一致ルールが実行する必要のあるタスクの1つが値の正規化です。これは、指定された値を、効率的に値と比較するために使用できる形式に変換するプロセスです。ほとんどの場合、正規化プロセスでは、すべての論理的に同等の値を同じ文字列に短縮する必要があります。それによって、非常に単純な文字列の比較を実行して、文字列が等しいかどうかを決定することができます。たとえば、caseIgnoreMatch一致ルールは、通常、すべての文字を小文字に変換し、複数の連続した空白を単一の空白に置換することで値を正規化します。より複雑な例は、distinguishedNameMatch一致ルールで、すべての不要な空白(たとえば、カンマ、等号および正符号の前後)を削除して、すべての属性タイプを小文字に変換し、適切な一致ルールを使用して各RDNコンポーネントの属性値を正規化します。
場合によっては、正規化単独では、2つの値が論理的に同等であるかを判断するには不十分であることに注意してください。これは、値が変換され、同じ値に対して複数の異なる変換が存在する可能性がある場合に、特に当てはまります。
属性構文は、基本的にデータ型の定義です。属性タイプの構文は、対応する値によって保持されるデータ型を示します。これは、指定された属性で特定の値が受け入れられるかどうかを決定するのに使用されるだけではなく、Oracle Unified Directoryが既存の値とどのように相互作用するかに関する情報を提供するのにも使用されます。
Oracle Unified Directoryでは、関連付けられた属性構文に違反する値を拒否する機能をサポートしています。これは標準への準拠を目的とするデフォルトの動作です。必要であれば、この属性構文の検査を完全に無効にすることができますが、関連付けられた構文に違反する値を受け入れることも可能です。ただし、毎回これが発生するたびにOracle Unified Directoryのエラー・ログに警告メッセージが記録されます。ただし、属性がそれらの関連付けられた構文に違反する値を持つことを許可されている場合は、一致操作はそのような値では期待どおりに動作しない可能性があります。スキーマ・チェックの無効化の詳細は、第27.2項「スキーマ・チェックの構成」を参照してください。
次の項では、属性構文について説明します:
属性構文の説明形式は、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構文のオプションの説明です。指定する場合は、一重引用符で囲む必要があります。
属性構文の拡張のオプションのセットです。Oracle Unified Directoryでは、次の拡張がサポートされています:
X_PATTERN: 属性が正規表現構文を使用することを指定します。詳細は、第9.2.3項「パターン一致構文の拡張」を参照してください。
X-ENUM: 属性が列挙構文を使用することを指定します。詳細は、第9.2.4項「列挙構文の拡張」を参照してください。
X-SUBST: 属性が置換構文を使用することを指定します。詳細は、第9.2.5項「置換構文の拡張」を参照してください。
次の例では、標準のディレクトリ文字列構文の属性構文の説明を示します:
( 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です。この例では、拡張を指定していません。
LDAPで定義されている属性構文は多数あります。それらは、コア・プロトコル仕様と他の関連するRFCおよびインターネット・ドラフトの両方で定義されています。この属性構文の多くは、RFC 4517 (http://www.ietf.org/rfc/rfc4517.txt)「LDAP構文と一致ルール」の第3.3項で定義されています。もっとも一般的に使用される属性構文のいくつかを次に示します:
Directory String構文は、1つ以上のUTF-8文字を含む汎用の文字列値を保持するために使用されます。技術的には、空の値(つまり、文字なし)は許可されていません。Oracle Directory Server Enterprise Editionは従来、空の値を許可しているため、標準コンプライアンスに対してデフォルトでは無効になっていますが、Oracle Unified Directoryは、それを許可するために使用できる構成オプションを提供しています。
IA5 String構文は、ASCII文字セットとしても知られているIA5文字セットに基づいた文字列値を保持するために使用されます。
Printable String構文は、大文字と小文字、数値の桁、一重引用符、左右のカッコ、正符号、カンマ、ハイフン、ピリオドおよび等号のセットから1つ以上の文字を含む文字列値を保持するために使用されます。
Boolean構文は、TRUEまたはFALSEの値を保持するのに使用されます。この構文を持つ属性には、その他の値は許可されていません。
Integer構文は、少なくとも1つの数字を含む必要がある整数値を保持するために使用されます。負の値を示すためにハイフンで始めることができます。値がゼロの場合にのみ、最初の桁にゼロを使用することができます。
Octet String構文は、ゼロ以上のバイトのセットを保持するために使用されます。以前のBinary構文のかわりに使用されています。
DN構文は、ゼロ以上のRDNコンポーネントで構成される識別名の値を保持するのに使用されます。値は、RFC 4514 (http://www.ietf.org/rfc/rfc4514.txt)「識別名のLDAP文字列表現」で指定されている形式である必要があります。
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.domain.com:389
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値は適用されません。
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属性構文の拡張は、他の、より一般的な構文を用いてそれらの不足している構文を定義する方法を提供します。スキーマおよびデータは、この機能により、スキーマまたはデータを変更したり、新たな構文を実装したりする必要なしに移行することができます。
属性タイプは、Oracle Unified Directoryで使用できる属性のセット、およびこれらの属性に関する操作の実行方法を定義します。特に、属性構文および一致ルールのセットを一意のOIDおよび判読可能な名前を結び付けます。
次の項で、属性タイプについて説明します:
属性タイプの説明形式は、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 Directory Server Enterprise Editionとの互換性を高めることを目的として、非数値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 — 特定のディレクトリ·サーバーに固有のものであり、トポロジ間で同期されるべきではない操作データを格納するために使用されます。
属性タイプの拡張のオプションのセットです。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拡張はないので、ディレクトリ文字列構文のデフォルトの近似ルールがここでも使用されます。
属性タイプはその上位タイプとしての属性タイプを参照できます。これには、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である必要はありません。
現時点では、属性タイプを処理するために使用されるメカニズムは、次の点でLDAPv3の仕様とは異なります:
LDAPv3仕様では、下位の属性タイプは上位タイプと同じ構文またはその構文の改良版を持つ必要があると規定されています。属性構文がスーパータイプの構文の改良版であるかどうかを判断する方法がないため、Oracle Unified Directoryは、この制約を実行しません。
同期サブシステムは、(たとえば、dSAOperationの使用方法を持つ属性タイプが同期されないように)属性使用方法を考慮に入れません。
オブジェクト・クラスは、エントリに格納できるデータ型を制御するために使用できる属性タイプの基本的な名前付きセットです。「オブジェクト・クラス」と「オブジェクトクラス」(単語の間の中黒の有無)は、一般的に区別しないで使用されることに注意してください。
次の項では、オブジェクト・クラスについて説明します:
オブジェクト・クラスの説明形式は、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 Directory Server Enterprise Editionとの互換性を高めることを目的として、非数値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が続く必要があります。複数のオプションの属性タイプがある場合は、それらをドル記号で区切り、オプションの属性タイプのセット全体をカッコで囲む必要があります。
オブジェクト・クラスの拡張のオプションのセットです。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と見なされません。
第9.4.1項「オブジェクト・クラスの説明形式」で説明されているように、すべてのオブジェクト・クラスは、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 Directory Server Enterprise Editionのデプロイメントとの互換性のため、この制約に違反するエントリが許可されるようにOracle Unified Directoryを構成し、オプションでこの状況が検出されるたびにOracle Unified Directoryのエラー・ログにメッセージを書き込むようにすることができます。しかし、正確に1つの構造化オブジェクト·クラスが含まれていないエントリがある場合、この制約に依存するDITコンテンツ・ルールのようないくつかのスキーマ要素は、すべてのケースで期待どおりに動作するとはかぎりません。このようなスキーマ違反を受け入れるようにOracle Unified Directoryを構成するには、グローバル構成のsingle-structural-objectclass-behaviorプロパティを設定します。詳細については、Oracle Unified Directory構成リファレンスのグローバル構成に関する項を参照してください。
第9.4.1項「オブジェクト・クラスの説明形式」で説明されているように、オブジェクト・クラスは、ゼロ個以上の上位クラス(現時点では、Oracle Unified Directoryは最大で1つの上位クラスをサポートしています)を持つことができます。オブジェクト・クラスが上位クラスを参照する場合、その上位クラスに関連付けられた必須およびオプションの属性のすべては、下位クラスにも関連付けられます。
オブジェクト・クラスの継承には次の制約があります:
ABSTRACTオブジェクト・クラスは、別の属性クラスからのみ継承することができます。それらは、構造化または補助クラスの下位であることはできません。
STRUCTURALオブジェクト・クラスは、抽象クラスまたは別の構造化クラスからのみ継承することができます。それらは、補助オブジェクト・クラスの下位であることはできません。
AUXILIARYオブジェクト・クラスは、抽象または別の補助クラスからのみ継承することができます。それらは、構造化オブジェクト・クラスの下位であることはできません。
すべてのSTRUCTURALオブジェクト・クラスは、最終的にトップの抽象オブジェクト・クラスから継承する必要があります。これによる実際の影響は、Oracle Unified Directoryのすべてのエントリがtopオブジェクト・クラスを含む必要があり、また、topオブジェクト・クラスに要求されるobjectClass属性タイプを含む必要があるということです。
オブジェクト・クラスを処理するために使用されるメカニズムは、オブジェクト・クラスで最大1つの上位クラスを持つことが許可されている点で、LDAPv3仕様と異なります。LDAPv3仕様では、場合によっては複数の上位クラスが許可されます。
名前書式は、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のみを指定する必要があります。複数のオプションの属性タイプがある場合は、それらを空白およびドル記号で区切り、オプションの属性タイプのセット全体をカッコで囲む必要があります。
名前書式の拡張のオプションのセットです。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にマークされません。
DITコンテンツ・ルールは、エントリに表示できるコンテンツを定義するメカニズムを提供します。その構造化オブジェクト・クラスに基づいて、最大で1つのDITコンテンツ・ルールをエントリに関連付けることができます。エントリにそのようなルールが存在する場合、エントリに存在する必要がある(存在する可能性がある、または存在していはいけない)属性タイプと同様に、含む可能性のある補助クラスを定義するために、そのエントリに含まれるオブジェクト・クラスとともに動作します。
次の項では、DITコンテンツ・ルールを説明します:
DITコンテンツ・ルールの説明形式は、RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt)の第4.1.6項で説明されています。次に例を示します:
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コンテンツ・ルールの説明は、次の要素を含みます:
numericoidDITコンテンツ・ルールに関連付けられている構造化オブジェクト・クラスの数値OIDです。仕様では、数値OIDを必要としますが、このnumericoidは関連付けられているオブジェクト・クラスに指定されているOIDと一致する必要があるので、オブジェクト・クラスのOIDが非数値の場合は、OIDも同様である必要があります。
NAMEDITコンテンツ・ルールを参照するために使用される判読可能な名前のオプションのセットです。単一の名前がある場合は、それを一重引用符で囲む必要があります。複数の名前がある場合は、それぞれを空白で区切られた一重引用符で囲み、名前のセット全体をカッコで囲む必要があります。
DESCオプションの判読可能な説明です。説明を指定する場合は、一重引用符で囲んでください。
OBSOLETEオプションのOBSOLETEフラグは、DITコンテンツ・ルールがアクティブかどうかを示すのに使用されます。DITコンテンツ・ルールがOBSOLETEとしてマークされている場合は、Oracle Unified Directory内で有効してはいけません。
AUX関連付けられた構造化クラスを持つエントリに存在することができる補助オブジェクト・クラスのオプションのリストです。値が指定されていない場合、そのようなエントリは、いずれの補助オブジェクト・クラスも持つことを許可されていません。値は、1つ以上の許可されている補助クラスの名前またはOIDとして指定される必要があります。複数の補助クラスが許可されている場合は、それらを空白およびドル記号で区切り、名前のセット全体をカッコで囲みます。
MUST関連付けられた構造化クラスを持つエントリに存在することが必要な属性タイプのオプションのリストです。これは、オブジェクト・クラスによって要求される属性タイプに加えてエントリに追加されます、これらの追加属性タイプは、それらのオブジェクト・クラスによって許可される必要はありません。値は、必須属性タイプの1つ以上の名前またはOIDとして指定される必要があります。複数の補助クラスが要求されている場合は、それらを空白およびドル記号で区切り、必須属性タイプのセット全体をカッコで囲みます。
MAY関連付けられた構造化クラスを持つエントリにオプションで存在することができる属性タイプのオプションのリストです。これは、オブジェクト・クラスによって許可された属性タイプに加えてエントリに追加されます。値は、オプションの属性タイプの1つ以上の名前またはOIDとして指定される必要があります。複数のオプションの補助クラスがある場合は、それらを空白およびドル記号で区切り、オプションの属性タイプのセット全体をカッコで囲みます。
NOT関連付けられた構造化クラスを持つエントリに存在することが禁止されている属性タイプのオプションのリストです。このリストは、構造化クラスまたは許可されている補助クラスで要求されているいずれの属性タイプも含むことはできませんが、それらのいずれかのオブジェクト・クラスによって許可される属性タイプの混入を防ぐために使用することができます。値は、禁止属性タイプの1つ以上の名前またはOIDとして指定される必要があります。複数のタイプが禁止されている場合は、それらを空白およびドル記号で区切り、禁止属性タイプのセット全体をカッコで囲みます。
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にマークされず、追加のオプションの属性タイプまたは禁止属性タイプは定義されず、拡張も含まれません。
現時点では、DITコンテンツ・ルールを処理するために使用されるメカニズムは、LDAPv3の仕様とは異なります。LDAPv3の仕様では、エントリで使用されている構造化オブジェクト・クラスが、対応するDITコンテンツ・ルールを持たない場合、そのエントリはいずれの補助オブジェクト・クラスも含むことはできないと規定されています。Oracle Directory Server Enterprise EditionはDITコンテンツ・ルールをサポートしないため、Oracle Unified Directoryは対応するDITコンテンツ・ルールがないエントリで補助オブジェクト・クラスの使用を妨げません。特定のエントリのタイプに補助クラスが含まれないようにすることが望ましい場合、DITコンテンツ・ルールは、補助クラスを許可しないDITコンテンツ・ルールを作成して、適切な構造化オブジェクト·クラスを持つエントリを処理する必要があります。
DIT構造ルールは、ディレクトリ・データの許可された階層構造を定義するために使用されます。特に、それらは指定された構造化オブジェクト・クラスを持つエントリの直接の子として存在することができるエントリのタイプを指定することを可能にします。たとえば、inetOrgPerson構造化クラスを持つエントリのみがorganizationalUnit構造化オブジェクト・クラスを持つエントリの直接の子になることができます。
DIT構造ルールは、それら自身で階層になっています。各DIT構造ルールは、整数値であるルールIDが割り当てられ、また、名前書式(1つ以上の構造化オブジェクト・クラスにリンクします)に関連付けられています。DIT構造ルールは、1つ以上上位のDIT構造ルールを参照することができ、これは、データの階層を制御するためのメカニズムを提供します。DIT構造ルールがいずれの上位ルールも指定しない場合は、その関連付けられた構造化オブジェクト・クラスを含むエントリは、関連付けられたスキーマのルートに存在することが許可されています。DIT構造が1つ以上の上位ルールを指定する場合は、関連付けられた構造化オブジェクト・クラスを持つエントリは、それらの上位ルールのいずれかの構造化オブジェクト・クラスを含むエントリの下にのみに存在することが許可されています。
次の項では、DIT構造ルールを説明します:
DIT構造ルールの説明形式は、RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt)の第4.1.7.1項で説明されています。次に例を示します:
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構造ルールの説明は、次の要素を含みます:
DIT構造ルールに割り当てられた整数のルールIDです。これは、スキーマ内のすべての他のDIT構造ルールの中で一意である必要があります。
NAMEDIT構造ルールを参照するのに使用される判読可能な名前のオプションのセットです。単一の名前がある場合は、それを一重引用符で囲む必要があります。複数の名前がある場合は、それぞれを空白で区切られた一重引用符で囲み、名前のセット全体をカッコで囲む必要があります。
DESCオプションの判読可能な説明です。説明を指定する場合は、一重引用符で囲んでください。
OBSOLETEオプションのOBSOLETEフラグは、DIT構造ルールがアクティブかどうかを示すのに使用されます。OBSOLETEにマークされている場合、エントリの作成時または移動時に、このルールは考慮されません。
FORMDIT構造ルールが関連付けられている名前書式の名前またはOIDです。第9.7項「DIT構造ルールの理解」で述べられているように、名前書式はDIT構造ルールと構造化オブジェクト・クラスを関連付けます。
SUPDIT構造ルールの上位のルールIDのオプションのセットです。複数の上位のルールIDがある場合は、空白でそれらを区切り、上位のルールIDのセット全体をカッコで囲みます。複数のDIT構造ルールは、上位のルールIDの重複セットを使用することが許容されます。
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にマークされてもいません。
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のみを定義します。
一致ルールの使用は、拡張一致フィルタ・コンポーネントで検索リクエストを処理する際に、特定の一致ルールとともに使用できる属性タイプを指定するために使用することができます。その拡張一致コンポーネントが、属性タイプおよび一致ルール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
一致ルールの使用の説明は、次の要素を含みます:
一致ルールの使用が関連付けられている一致ルールの数値OIDです。特定の一致ルールに関連付けられた一致ルールの使用は1つのみです。
NAME一致ルールの使用を参照するのに使用できる判読可能な名前のオプションのセットです。単一の名前がある場合は、それを一重引用符で囲む必要があります。複数の名前がある場合は、それぞれを一重引用符で囲み、空白で区切り、名前のセット全体をカッコで囲む必要があります。
DESCオプションの判読可能な説明です。説明がある場合は、それを一重引用符で囲む必要があります。
OBSOLETEオプションのOBSOLETEフラグは、一致ルールの使用がアクティブかどうかを示すのに使用されます。OBSOLETEにマークされている場合、拡張一致フィルタを許可するかどうかを判断する際に、このルールは考慮されません。
APPLIES関連付けられた一致ルールとともに使用される1つ以上の属性タイプのセットです。関連付けられた属性タイプがある場合は、その名前またはOIDが使用されます。複数の属性タイプがある場合は、それらを空白およびドル記号で区切り、関連付けられた属性タイプのセット全体をカッコで囲みます。
一致ルールの使用の拡張のオプションのセットです。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にマークされておらず、そしていずれの拡張もありません。
