| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionリファレンス 11g リリース1 (11.1.1.7.0) B72441-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionリファレンス 11g リリース1 (11.1.1.7.0) B72441-01 |
|
前 |
次 |
Directory Proxy Serverでは仮想データ・ビューの定義によって仮想化を実現しています。仮想データ・ビューではユーザーが物理データを違った方法で表示することができます。この章では仮想データ・ビューの作成方法と、Directory Proxy Serverで使用可能な仮想データ・ビューの種類について説明します。
この章の内容は次のとおりです。
仮想データ・ビューは基本的には、特定の変換アクションが定義された物理データ・ビューです。変換アクションはリアルタイムで行われ、仮想データ・ビューが作成されます。次の図は、仮想データ・ビューを作成するために、物理データ・ビューで変換アクションが定義される方法を示しています。
変換アクションに加えて、特定のプロパティをデータ・ビューで定義でき、これにより、そのデータ・ビューでデータが管理される方法を制限します。仮想データ・ビューの追加プロパティについては、「仮想データ・ビューの追加プロパティ」で説明します。
|
注意: 仮想データ・ビューはパフォーマンスへの影響を暗黙的に意味します。パフォーマンスへの影響の大きさは、物理データ・ソースのサイズ、変換アクションの複雑さおよび使用する仮想ACIの複雑さなど、複数の要因に応じて異なります。 |
仮想データ変換により、物理データ・ビューから仮想データ・ビューが作成されます。実質的には、ユーザーが仮想データ・ビューを定義することはありません。かわりに、必要な変換を指定し、これらを既存の物理データ・ビューで定義します。変換により、特定のアクションが特定の方向で実行されます。変換の方向により、変換モデルが決定されます。仮想データ変換を定義する場合、仮想データ・ビューのコンテキストでのみに存在する仮想属性を作成します。
次のようにdpconfコマンドを使用して、変換がデータ・ビューで定義されます。
$ dpconf add-virtual-transformation -h host -p port -D bindDN / view-name model action attr-name [parameters...]
view-nameは、変換が定義されるデータ・ビューのことです。attr-nameは作成される仮想属性のことです。モデル、アクションおよび追加パラメータについては以降の各項で説明します。
仮想変換の名前は次のコマンドを使用して設定できます。
$ dpconf set-virtual-transformation-prop -h host -p port -D bindDN / view-name transformation-name property:value [property:value]
変換モデルは変換の方向、つまり、変換がリクエスト時に適用されるか、レスポンス時に適用されるか、または両方で適用されるかにより決まります。
この意味で、変換は次のタイプに分類できます。
マッピング変換(双方向変換)
書込み変換(インバウンド変換)
読取り変換(アウトバウンド変換)
最も一般的な変換は双方向(マッピング)変換です。マッピング変換はリクエスト時に適用され、その逆はレスポンス時に適用されます。これらの変換は、実際には物理データ・ビューの属性やエントリが仮想データ・ビューの属性やエントリにマップされるため、マッピングと呼ばれます。マッピング変換では、既存の値をDNコンポーネント、属性タイプまたは値、あるいはオブジェクト・クラスに割り当てる前に、それらの値を処理することができます。
次の図は、マッピング変換のプリンシパルを表しています。
マッピング変換は、次のようにdpconfコマンドを実行することにより、データ・ビューで定義されます。
$ dpconf add-virtual-transformation -h host -p port -D bindDN / view-name mapping action attr-name [parameters]
次の検索フィルタ・コンポーネントがサポートされています。
単一の属性とともに仮想属性composeが含まれている、すべてのsubstringまたはpresence検索フィルタ。
1つ以上の属性とともに仮想属性composeが含まれている、すべてのequality検索フィルタ。
注意: マッピング変換を作成するときには、次の制限が適用されます。
constantまたはmacro(split、substring、increment、decrement)パラメータ値を持つ仮想属性が含まれている検索フィルタは、サポートされていません。
複数の仮想属性が含まれているsubstringまたはpresence検索フィルタ・コンポーネントはサポートされていません。
例18-1 マッピング変換を使用する場合
たとえば、属性surnameおよびgivenameを持つエントリが含まれている物理データ・ソースをある組織が持っているとします。この組織には、形式givenname surnameのcn (共通名)属性を持つエントリを必要とするクライアント・アプリケーションがあります。
クライアント・アプリケーションは形式cn=Carlos Fuentesのエントリーを求める検索リクエストを送信します。このリクエスト時に氏名を抽出し、リクエストをsurname=Fuentes, givenname=Carlos形式の1つに変換する変換が定義されます。対応するエントリはデータ・ソースにあります。このエントリをクライアント・アプリケーションに戻す前に、逆の変換が実行されます。クライアント・アプリケーションは、理解できる形式であるcn=Carlos Fuentesでエントリを受信します。
このリクエストは形式surname=Fuentes, givenname=Carlosに変換されます。同様に、クライアント・アプリケーションはエントリのcn属性をLisa Davisに変更する変更リクエストを送信します。このリクエストは、物理エントリのgivenname属性がLisaに変更され、surname属性がDavisに変更されるように、変換されます。
書込み変換はリクエスト時に適用されますが、レスポンス時には適用されません。書込み変換はストレージ内の物理データを変更します。
次の図は書込み変換のプリンシパルを表しています。
次のようにdpconfコマンドを使用して、書込み変換がデータ・ビューで定義されます。
$ dpconf add-virtual-transformation -h host -p port -D bindDN / view-name write action attr-name [parameters]
読取り変換は、リクエストに対するレスポンス時にのみ適用されます。リクエスト時には変換は適用されず、物理データは変更されません。
次の図は、読取り変換のプリンシパルを表しています。
次のようにdpconfコマンドを使用して、読取り変換がデータ・ビューで定義されます。
$ dpconf add-virtual-transformation -h host -p port -D bindDN / view-name read action attr-name parameters
例18-3 読取り変換を使用する場合
ある組織に、個人エントリを表示する機能を持つレガシー・アプリケーションがあるとします。このアプリケーションは、mail属性を含んでいないエントリをサポートしていません。物理データ・ソースは更新されており、email属性はもう個人エントリに存在していません(電子メール・アドレスは、他の属性を使用して構成されます)。
ここで必要な変換は、検索レスポンス時にmail属性を追加することです。この変換はデータベースから読み取られたエントリを変更し、mail属性(値は、givenname.surname@example.com)を追加します。逆の変換は必要なく、物理データは変更されません。
上記の変換の場合、mail属性は検索リクエスト・フィルタで意味がないことに気を付けてください。検索リクエスト・フィルタには物理的な属性が含まれている必要があります。
変換アクションは、ターゲット・エントリに対して変換が何を行うかを記述します。次の変換アクションが考えられます。
属性の構成。このアクションにより、ユーザーは物理データ・ソースには実際に存在していないが、クライアント・アプリケーションに必要な仮想属性を構成できます。このアクションを使用して、物理データ・ソースに必要な属性を構成するための追加または修正リクエストを変更することもできます。
属性を構成するには、add-attr変換アクションを使用します。
属性の削除。このアクションにより、ある属性が物理データ・ソースでスキーマにより許可されていない場合に、ユーザーがその属性をクライアント・リクエストから削除できます。クライアント・アプリケーションがその属性を必要としない場合は、クライアント・アプリケーションに送信されたレスポンスから、このアクションを使用して属性を削除することもできます。
属性を削除するには、remove-attr変換アクションを使用します。
属性値の構成。このアクションにより、ユーザーは他の属性値からある属性値を作成できます。
属性値を作成するには、add-attr-value変換アクションを使用します。
属性値の削除。このアクションにより、ユーザーは属性から値を削除できます。これは通常、クライアント・アプリケーションまたはデータ・ソース・スキーマが複数値属性を許可していない場合に、複数値属性から1つ以上の値を削除するために使用されます。
属性値を削除するには、remove-attr-value変換アクションを使用します。
属性にデフォルト値を追加する。このアクションでは、属性に値が存在していない場合、デフォルト値を追加できます。
デフォルト値を属性に追加するには、def-value変換アクションを使用します。
1つの属性値を別の属性値にマップする。このアクションでは、属性がデータ・ソースに書き込まれるか、クライアント・アプリケーションに返されるかに応じて、ある属性に対して2つの異なる値を持つことができます。
属性値をマップするには、attr-value-mapping変換アクションをinternal-valueパラメータおよびview-valueパラメータとともに使用します。
|
注意: Directory Proxy Serverでは、単純な属性マッピングと仮想変換によるマッピングという、属性値をマッピングする2つの方法がサポートされています。一般に、属性マッピングは構成がより簡単で、パフォーマンスの点でも若干の利得があります。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の属性とDNの名前変更に関する説明を参照してください。 |
変換アクションの結果は変換モデルに応じて異なります。
変換パラメータは仮想属性の値を提供します。この値はデフォルト値か、または他の属性値から値を作成するルールであることが可能です。
次の変換パラメータが受け入れられます。
value。このパラメータは、attr-value-mappingアクション以外の、属性値を追加するすべての変換アクションに適用されます。
internal-value:value。このパラメータは、attr-value-mappingアクションとremove-attr-valueアクション(mappingモデルで使用される場合)にのみ適用されます。これは、物理データ・ソースに書き込まれる、または物理データ・ソースから読み取られる属性の値を説明します。
view-value:value。このパラメータは、attr-value-mappingアクションとremove-attr-valueアクション(mappingモデルで使用される場合)にのみ適用されます。これは、クライアント・アプリケーションに返されるまたは、クライアント・アプリケーションにより送信される属性の値を説明します。
変換パラメータは次の構文をとります。
定数。静的なデフォルト値を持つ属性の生成に使用されます。
たとえば、デフォルトの電話番号を指定するにはパラメータ0800-5994654が使用される場合があります。
このパラメータはマッピング変換についてはサポートされていません。
属性値。処理されるエントリの既存の属性から新しい属性を作成するために使用されます。
たとえば、パラメータ\${cn}は、新しい属性の値をcn属性の値からとる必要があることを指定します。$の前にはエスケープ文字が必要です。
定数および属性値。既存の属性と静的な値を組み合せることにより、新しい属性を作成するために使用されます。
たとえば、パラメータ\${cn}@example.comは、新しい属性の値をcn属性の値および静的なドメイン名からとる必要があることを指定します。
マクロ。既存の属性の値を操作することにより、属性を作成するために使用されます。
このパラメータはマッピング変換についてはサポートされていません。
マクロはJava正規表現です。Java正規表現の詳細は、http://download.oracle.com/docs/cd/E17476_01/javase/1.4.2/docs/api/java/util/regex/Pattern.htmlを参照してください。
次のマクロがサポートされています。
属性値の一定量の増加:
increment(source-attribute-value,increment)
たとえば、マクロincrement(\$(uid),10)は、エントリに存在するuid属性の値に10を加えることにより、新しい属性の値を取得することを指定します。
属性値の一定量の減少:
decrement(source-attribute-value,decrement)
たとえば、マクロdecrement($(uid),10)は、エントリに存在するuid属性の値から10を引くことにより、新しい属性の値を取得することを指定します。
既存の属性値の一部を使用:
substring(source-attribute-value,begin-index[,end-index])
begin-indexではその値も含まれ、end-indexではその値が除外されます。つまり、サブストリングはbegin-indexで指定された文字で始まり、end-indexの直前の文字で終了します。
たとえば、値がcn属性の値から始めの2つの文字を引いたものである新しい属性を作成するには、次のマクロを定義します。
substring(\${cn},2)
値が、cn属性の値の初めの2文字のみを含む新しい属性を作成するには、次のマクロを定義します。
substring(\${cn},0,2)
値を特定の場所で分割して、既存の属性値の一部を使用:
split(source-attribute-value,token-index,regular-expression)
たとえば、マクロsplit\(\${mail},1,"@"\)はドメインを返します。
次の各項では、仮想データ・ビューが必要なユースケース、およびこのユースケースを実装するために必要な変換モデルとアクションの組合せについて説明します。
例18-4 ADAMオブジェクト・クラスのLDAP準拠への適合
会社Example Aは、ユーザーをLDAPディレクトリに格納しています。Example Aは別の会社、Example Bを買収しますが、この会社はユーザーをADAMディレクトリに格納しています。
Example AのLDAPディレクトリで、ユーザーはinetOrgPersonとして保管されます。Example Bのディレクトリでは、ユーザーはuserとして保管されます。このため、ADAMのuserオブジェクト・クラスをLDAPのinetOrgPersonオブジェクト・クラスにマップする変換が必要です。
次の変換がExample Aのディレクトリの物理データ・ビューで定義されます。
$ dpconf add-virtual-transformation -h myHost -p 2389 -D "cn=Proxy Manager" \ exampleB-view-name mapping attr-value-mapping objectclass internal-value:user \ view-value:inetOrgPerson
例18-5 書込み変換による属性の構成
Example Aはユーザー・エントリをそのディレクトリに保管します。すべてのユーザー・エントリにはmail属性が必要です。mail属性のないユーザー・エントリが追加されると、スキーマ違反エラーが返されます。Example Aには、ユーザー・エントリをディレクトリに追加するクライアント・アプリケーションがあります。一部のユーザー・エントリにはmail属性が含まれておらず、クライアント・アプリケーションはその属性を生成できません。ユーザー・エントリ追加時のスキーマ違反を回避するには、追加リクエストにmail属性を追加する変換を定義します。mail属性の値はクライアントの追加リクエストで指定されるuidから取得し、これに@example.comを付加します。
次の図は、追加リクエストで発生する変換を示しています。
この変換は、次のdpconfコマンドを使用することにより、物理データ・ビューで定義されます。
$ dpconf add-virtual-transformation -h myHost -p 2389 -d "cn=Proxy Manager" \
exampleA-view-name write add-attr mail \${uid}@example.com
このコマンドで、\${uid}は、そのエントリのuid属性の値を意味します。
例18-6 読取り変換による属性の構成
Example Aは、ディレクトリにユーザーのメール・アドレスを保管していません。しかし、新しいクライアント・アプリケーションでは、ユーザー・エントリーとともにユーザーのメール・アドレスを返すことが必要です。
会社内のすべてのメール・アドレスは、firstname.lastname@example.comという書式をとります。この組織は、mail属性を各ユーザー・エントリに読取り専用で追加する、仮想ビューを定義します。mail属性の値は、ユーザー・エントリにすでに存在しているgivenName属性およびsn属性の値から生成されます。
次の図は、検索でユーザーのエントリが返されるときにユーザーのエントリで発生する変換を示しています。
この変換は、次のdpconfコマンドを使用することにより、物理データ・ビューで定義されます。
$ dpconf add-virtual-transformation -h myHost -p 2389 -d "cn=Proxy Manager" \
exampleA-view-name read add-attr mail \${givenname}.\${sn}@example.com
例18-7 デフォルト属性値の追加
Example Aは、そのディレクトリに多くの製品を保管しています。過去には、それぞれの製品が1人のサポート・スタッフ(その製品についてのすべてのサポート・コールを処理する社員)と関連付けられていました。したがって、物理データ・ストアでは各製品がsupportPerson属性と関連付けられており、その値はその会社の社員のDNです。
同社ではサポート照会のビジネス・プロセスを変更し、すべての製品に関する問合せを中央のホットラインに送ることになりました。物理データを変更せずにこの変更を処理するために、会社ではすべての製品エントリがsupportPerson属性を持たないが、かわりにhotline属性を持つ仮想データ・ビューを定義します。hotline属性の値は、すべての製品について同じ数字である0800です。
次の図は、検索で返されるときに製品エントリで発生する変換を示しています。
この変換は、次のdpconfコマンドを使用して物理データ・ビューで定義されます。
$ dpconf add-virtual-transformation -h myHost -p 2389 -d "cn=Proxy Manager" \ exampleA-view-name read remove-attr supportPerson $ dpconf add-virtual-transformation -h myHost -p 2389 -d "cn=Proxy Manager" \ exampleA-view-name read add-attr hotline "0800755 8625"
例18-8 仮想変換を使用したDNの名前変更
Example Aには、オブジェクト・クラスに従ってエントリをソートする必要があるクライアント・アプリケーションがあります。
これを実行するために、Example Aでは、エントリがその特定のクライアント・アプリケーションに返されるときには常にそのエントリのRDNを書き変え、cnとともにエントリのオブジェクト・クラスを含めるという仮想変換を定義します。
次の変換がExample Aのディレクトリの物理データ・ビューで定義されます。
$ dpconf add-virtual-transformation -h myHost -p 2389 -d "cn=Proxy Manager" \
exampleB-view-name mapping attr-value-mapping dn internal-value:cn=\${cn} \
view-value:cn=\${cn},objectclass=\${objectclass}
前述の変換アクションに加えて、特定のプロパティをデータ・ビューで定義でき、これにより、そのデータ・ビューでデータが管理される方法を制限します。これらのプロパティは基本的に、仮想データ・ビューを介して読取りまたは変更できる属性のリストを提供します。
制限された仮想データ・ビューを表示するために、次の追加プロパティをデータ・ビューで定義できます。
表示できない属性。このデータ・ビューを介して読み取ることができない属性のリストです。このリストは、複数値プロパティnon-viewable-attrをデータ・ビューに追加することにより、指定されます。このプロパティは、読み取ることができない属性の数が少ない場合に使用する必要があります。
書込みできない属性。このデータ・ビューを介して追加または変更することができない属性のリストです。このリストは、複数値プロパティnon-writable-attrをデータ・ビューに追加することにより、指定されます。このプロパティは、追加または変更できない属性の数が少ない場合に使用する必要があります。
表示可能な属性。このデータ・ビューを介して読み取ることができる属性のリストです。このリストは、複数値プロパティviewable-attrをデータ・ビューに追加することにより、指定されます。このプロパティは、読み取ることができる属性の数が少ない場合に使用する必要があります。
書込み可能な属性。このデータ・ビューを介して追加または変更できる属性のリストです。このリストは、複数値プロパティwritable-attrをデータ・ビューに追加することにより、指定されます。このプロパティは、追加または変更できる属性の数が少ない場合に使用する必要があります。
表示できない属性と表示できる属性は相互に排他的です。同様に、書込みできない属性と書込みできる属性も相互に排他的です。
結合データ・ビューは複数のデータ・ビューを集約したものです。Directory Proxy Serverの現在のリリースでは、2つのデータ・ビューの1つの結合データ・ビューへの集約がサポートされています。
結合データ・ビューは、結合データ・ビューの名前と、集約される2つの既存のデータ・ビューを指定することにより作成されます。これら既存のデータ・ビューの1つはプライマリ・データ・ビューとみなされ、もう一方のデータ・ビューはセカンダリ・データ・ビューとみなされます。結合データ・ビューを作成する前に、データが集約される方法を決定するルールをセカンダリ・データ・ビューに対して構成する必要があります。
次の図は、プライマリ・データ・ビューとセカンダリ・データ・ビューを集約して1つの結合データ・ビューを形成する様子を示しています。
結合データ・ビューのソースを階層的に編成することにより、Directory Proxy Serverではプライマリ・データ・ビューおよびセカンダリ・データ・ビューのデータが一致しない場合のデフォルトの決定を行うことができます。
プライマリ・データ・ビューは結合データ・ビューの存在を制御します。セカンダリ・データ・ビューはこのエントリ・リストの補助データを提供します。言い換えれば、あるエントリがセカンダリ・データ・ビューには存在するがプライマリ・データ・ビューには存在しない場合、そのエントリは結合データ・ビューに表示されません。
デフォルトでは、プライマリ・データ・ビューが権限を持つソースです。ある属性が両方のソース・データ・ビューにあるが、それぞれが違う値の場合、複数値属性が返されます。ただし、この動作は構成可能です。たとえば、プライマリ・データ・ビューの値のみを受け入れる、またはセカンダリ・データ・ビューの値のみを受け入れるように選択できます。
「仮想データ・ビューの追加プロパティ」で説明した仮想データ・ビューのプロパティに加えて、セカンダリ・データ・ビューのみに特定のプロパティを定義できます。これらのプロパティは、2つのビューのデータが集約される方法およびデータ・ビューへのリクエストが処理される方法を決定します。次の各項ではこれらの追加プロパティについて説明します。
結合ルールは、セカンダリ・データ・ビューのエントリがプライマリ・データ・ビューのエントリに関連する方法を決定します。結合ルールはセカンダリ・データ・ビューでは必須ではありません。ただし、結合ルールが定義されていないと、LDAP操作時にセカンダリ・データ・ビューへの問合せは行われません。Directory Proxy Serverには、DN結合ルールおよびフィルタ結合ルールの、2つのタイプの結合ルールが用意されています。
DN結合ルールはセカンダリ・データ・ビューでのエントリのDNを決定します。DN結合ルールは、dn-join-ruleプロパティを使用してセカンダリ・データ・ビューで構成されます。セカンダリ・データ・ビューに構成できるDN結合ルールは1つだけです。DN結合ルールをデータ・ビューに構成した場合、そのデータ・ビューにはフィルタ結合ルールを構成できません。
DN結合ルールにはDN構文があり、次の形式のいずれかをとることができます。
セカンダリ・エントリのDNは、プライマリ・エントリの属性から構成されます。
たとえば、次のDN結合ルールは、セカンダリ・データ・ビューのエントリのDNにプライマリ・データ・ビューのcnが含まれ、これにou=peopleのサフィックスが付いている必要があることを規定しています。
cn=\${primary-data-view.cn},ou=people
DNにはセカンダリ・データ・ビューのベースDNが含まれていてはいけません。その意味で、これは相対DNです。
セカンダリ・エントリのDNはプライマリ・エントリのDNと同じです。
このような結合ルールの構文は次のとおりです。
\${primary-data-view.dn}
この場合、ベースDN下のプライマリおよびセカンダリDNの部分は、完全DNが異なっている場合でも同一です。たとえば、プライマリ・データ・ビューのベースDNがo=primaryで、セカンダリ・データ・ビューのベースDNがo=secondaryである場合を想定します。結合ルール\${primary-data-view.dn}は、ベースDN下のDITが同一であることを意味します。このため、エントリuid=1,o=secondaryはuid=1,o=primaryと関連付けられます。
フィルタ結合ルールは、プライマリ・データ・ビューとセカンダリ・データ・ビュー間の関係を定義します。フィルタ結合ルールは、filter-join-ruleプロパティを使用してセカンダリ・データ・ビューで構成されます。このルールは、プライマリ・データ・ビューの何かに基づいてセカンダリ・データ・ビューからエントリが取得される方法を示します。
セカンダリ・データ・ビューに構成できるフィルタ結合ルールは1つだけです。フィルタ結合ルールをデータ・ビューに構成した場合、そのデータ・ビューにはDN結合ルールを構成できません。フィルタ結合ルールは、プライマリ・データ・ビューの1つ以上の属性からある属性を構成するために使用するフィルタの形をとります。
たとえば次のフィルタ結合ルールは、プライマリ・データ・ビューのエントリuidがセカンダリ・データ・ビューのエントリuidに一致した場合に、エントリが取得されることを規定しています。
uid=\${primary.uid}
contains-shared-entriesプロパティは、セカンダリ・データ・ビューのエントリがプライマリ・データ・ビィーの複数のエントリにより使用されている場合に、何が実行されるかを決定します。
たとえば、プライマリ・データ・ビューにユーザー・エントリのリストが含まれており、セカンダリ・データ・ビューに部門番号のリストが含まれている場合を想定します。セカンダリ・データ・ビューの1つの部門番号は、プライマリ・データ・ビューの複数のユーザーに適用される可能性があります。プライマリ・データ・ビューからあるユーザーが削除された場合、セカンダリ・データ・ビューからそのユーザーの部門番号を必ずしも削除する必要がないことがあります。
contains-shared-entriesプロパティはセカンダリ・データ・ビューに設定されます。このプロパティはデフォルトでTRUEに設定されています。これは、プライマリ・データ・ビューのエントリを削除することで、セカンダリ・データ・ビューの共有エントリが削除されることはないことを意味します。プライマリ・データへエントリを追加すると、セカンダリ・データ・ビューにまだそのエントリが存在していない場合にのみセカンダリ・データ・ビューにそのエントリが追加されます。
属性がプライマリ・データ・ビューとセカンダリ・データ・ビューの両方に存在している場合、その属性の値は結合データ・ビューによってマージされます。読取り操作の場合、これは、両方のデータ・ビューからの値を持つ複数値属性が返されるっことを意味します。書込み操作の場合、プロキシが両方のデータ・ビューに問合せを行い、書込み操作の内容に基づいて値を書き込む場所を決定します。
追加操作時にあるバックエンド・データ・ソースに障害が発生した場合、Directory Proxy Serverは自動ロールバックを実行します。ロールバックは、障害が発生しなかったデータ・ソースでの削除操作の形式をとります。これにより、2つのデータ・ソース間のデータの一貫性が確保されます。ロールバックを実行できない場合はエラーが記録され、オプションで管理アラートが発行されます。自動ロールバックはデフォルトで有効になっています。自動ロールバックは、revertAddOnFailure属性をoff (直接cn=configで)に設定することにより構成できます。
削除操作時にあるバックエンド・データ・ソースに障害が発生した場合、ロールバックは実行されません。エラーが記録され、オプションで管理アラートが発行されます。
各種の仮想データ変換は「仮想データの変換」で説明されています。変換パラメータの構文は、データ変換が結合データ・ビューで定義されている場合は少し異なります。属性が複数のデータ・ビューから取得されるため、属性の内容を定義する変数は完全修飾パスである必要があります。つまり、ソースの属性値には、その属性の取得元であるデータ・ビューの名前が含まれている必要があります。
たとえば、次のパラメータはプライマリ・データ・ビューとセカンダリ・データ・ビューの両方の既存の属性から属性を作成します。
\${primaryDataView.firstName}.\${secondaryDataView.lastName}@\${primaryDataView.domainName}
firstNameおよびdomainName属性はプライマリ・データ・ビューから取得され、lastName属性はセカンダリ・データ・ビューから取得されます。
コーディネータ・データ・ビューは、一連のデータ・ビューを単一のデータ・ビューのように表示できるようにグループ化します。このグループ化によって、ユーザーはそれぞれのエントリがどこに格納されているかを知らなくても、1つの操作で別々のデータ・ビューに格納されているエントリにアクセスできます。このデータ・ビューは、各エントリがどこに格納されているかを自動的に検出し、それらに対する操作を実行します。
2つの異なるソースのエンティティが1つのネームスペースに統合される場合、別々のデータ・ソースにまだ格納されているエントリの場所指定するために分散アルゴリズムが使用されることはありません。
名前付きサービスがディレクトリ・サーバーの階層によってデプロイされるとき、問合せではまずローカル・サーバーがヒットします。一致するエントリが見つからない場合、クエリはよりグローバルなサーバーにアクセスします。
データが複数のデータ・ビューに分散されている場合、コーディネータ・データ・ビューは分散されたデータ・ビューをグループ化してそれが単一のデータ・ビューとして表示されるようにし、そのビューはさらに結合データ・ビューのプライマリ・データ・ビューまたはセカンダリ・データ・ビューとして使用できます。このように、コーディネータ・データ・ビューではエントリの集約と分散が可能です。
問合せで分散キーが使用できない場合、コーディネータ・データ・ビューはリクエストを分散データ・ビューにルーティングし、その分散データ・ビューはさらに分散データ・ビュー間のルーティングを繰り返してエントリを探します。
すべての構成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のコーディネータ・データ・ビューの作成および構成に関する説明を参照してください。
LDIFデータ・ビューは、LDIFファイルがLDAPデータ・ソースのように見える単純な仮想データ・ビューです。LDIFデータ・ビューは、次のようにdpconfコマンドを使用して定義されます。
dpconf create-ldif-data-view VIEW_NAME LDIF_FILE_NAME SUFFIX_DN
追加の変換は必要ありません。Directory Proxy Serverは、クライアント・アプリケーションに対してLDIFデータがLDAPデータのように見えるようにするために必要な変換を自動的に実行します。
LDIFデータ・ビューの作成および構の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のLDIFデータ・ビューの作成および構成に関する説明を参照してください。
JDBCデータ・ビューを使用すると、リレーショナル・データベースからLDAPクライアント・アプリケーションにアクセスできます。JDBCデータ・ビューをセットアップするには、次の構成オブジェクトが必要です。
JDBCデータ・ソース。各リレーショナル・データベースに対して定義されます。現在、1つのJDBCデータ・ビューについてサポートされているJDBCデータ・ソースは1つだけです。
JDBCデータ・ソース・プール。各JDBCデータ・ソースに対して定義されます。
JDBCデータ・ビュー。複数のJDBCオブジェクト・クラスを、LDAPクライアント・アプリケーションがアクセスできる単一のデータ・ビューに集約します。
JDBCオブジェクト・クラス。1つ以上のJDBC表をLDAPオブジェクト・クラスにマップします。
JDBC表。各リレーショナル・データベース表に対して定義されます。
JDBC属性。JDBC表の指定された列からLDAP属性を定義します。
次の図は、前述のJDBCオブジェクトの構成により、LDAPクライアント・アプリケーションがLDAP DIT形式でOracleデータベースを表示する方法を示しています。各オブジェクトについては、この後の項で詳しく説明します。
LDAPクライアント・アプリケーションはJDBCデータ・ビューに、またはJDBCデータ・ビューが含まれている結合データ・ビューにバインドすることもできます。その場合、Directory Proxy ServerはJDBCデータベースからパスワードを取得してパスワード・チェックを実行します。パスワードはクリア・テキスト、SHAまたはSSHAで取得できます。
JDBCデータ・ソースは各リレーショナル・データベースに対して定義されます。JDBCデータ・ソースのプロパティにはリレーショナル・データベースの名前と場所、およびデータベースへのアクセスに必要なユーザー名とパスワードが含まれています。JDBCデータ・ソースに設定できるプロパティの完全なリストについては、次のコマンドを実行します。
$ dpconf get-jdbc-data-source-prop -h myHost -p 2389 -d "cn=Proxy Manager"\
jdbc-data-source-name
現在、1つのJDBCデータ・ソースのみが各JDBCデータ・ビューに対してサポートされています。つまり、JDBCデータ・ソース間ではロード・バランシングできません。
LDAPデータ・ソース同様、JDBCデータ・ソースは複数のデータ・ソース・プールで編成されます。JDBCデータ・ソース・プールのプロパティは、LDAPデータ・ソース・プールのプロパティに似ています。LDAPデータ・ソース・プールの詳細は、「LDAPデータ・ソース・プール」を参照してください。
|
注意: Directory Proxy Serverはリレーショナル・データベースから取得されるメタデータに依存します。このメタデータはDirectory Proxy Serverの起動時、または新しいJDBCデータ・ビューが追加されるときに読み取られます。メタデータはDirectory Proxy Serverがリクエストを処理するたびに再度読み取られます。リレーショナル・データベースでメタデータを変更した場合、変更を考慮に入れるためにはDirectory Proxy Serverを再起動する必要があります。 メタデータは次のいずれかの変更が行われた場合に変更されます。
|
JDBCオブジェクト・クラスはLDAPオブジェクト・クラスを1つ以上のリレーショナル・データベース表にマップします。JDBCオブジェクト・クラスは結合データ・ビューと同じ方法で機能します(「結合データ・ビュー」を参照)。結合データ・ビューがプライマリおよびセカンダリ・ソースデータ・ビューを持つのとちょうど同じように、JDBCオブジェクト・クラスは情報を複数の表から取得できます。1つの表をプライマリ表として定義する必要があり、それ以外の表がある場合は、それらをセカンダリ表として定義します。プライマリ表はエントリのリストを制御し、これらのエントリに関する追加情報はセカンダリ表から抽出されます。
JDBCオブジェクト・クラスを定義するときには、次のオペランドを指定する必要があります。
このオブジェクト・クラスがアタッチされるJDBCデータ・ビューの名前。
JDBCオブジェクト・クラスの名前。
オブジェクト・クラスがエントリのリストを取得するプライマリJDBC表。
データ・ビューでDNが構成される方法を制御するDNパターン。
1つ以上のセカンダリJDBC表(オプション)。
JDBC表は、JDBCデータ・ビューで使用される各リレーショナル・データベースに対して作成する必要があります。JDBC表を作成するときには、リレーショナル・データベースで表の名前を指定し、次にJDBCデータ・ビューでこの表に割り当てる名前を指定します。
JDBC表には次のプロパティが適用されます。
SQL表。 (sql-table) リレーショナル・データベース表の名前を指定します。
この値は、JDBC表を作成するときに指定する必要がありますが、SQL表の名前に変更があった場合は変更できます。
1行表。 (is-single-row-table) あるLDAPエントリがリレーショナル・データベース表で一致する行を1つだけ持つことを指定します。
このプロパティをtrueに設定した場合、SQLリクエストに順番がないため、一般にパフォーマンスが向上します。
共有エントリ。 (contains-shared-entries) このプロパティは、セカンダリ表のある行がプライマリ表の複数のエントリによって使用されている場合にどのように処理するかを決定します。
たとえば、プライマリ表にユーザー詳細のリストがあり、セカンダリ表に部門番号が含まれている場合を想定します。セカンダリ表の1つの部門番号は、プライマリ表の複数のユーザーに適用される可能性があります。あるユーザーが削除された場合、セカンダリ表からそのユーザーの部門番号を必ずしも削除する必要がないことがあります。
contains-shared-entriesプロパティはセカンダリ表にのみ設定されます。このプロパティがTRUEに設定された場合、LDAPエントリを削除するとプライマリ表のユーザーは削除されますが、セカンダリ表の対応する行は削除されません。
フィルタ結合ルール。 (filter-join-rule) フィルタ結合ルールはプライマリ表とセカンダリ表の間の関係を定義します。
フィルタ結合ルールはセカンダリ表では必須で、プライマリ表のなんらかの値に基づいてエントリがセカンダリ表からどのように取得されるかを示します。
各セカンダリ表に構成できるフィルタ結合ルールは1つだけです。フィルタ結合ルールは、LDAP属性を構成するために使用されるフィルタの形をとります。
たとえば、次のコマンドはセカンダリphone表にフィルタ結合を作成します。このルールは、phone表のuser_idフィールドがemployee表のidフィールドに一致する場合に、エントリをphone表から取得することを規定しています。
$ dpconf set-jdbc-table-prop -h myHost -p 2389 -d "cn=Proxy Manager" \
phone filter-join-rule:user_id=\${employee.id}
JDBC属性はリレーショナル・データベース表のエントリにLDAP属性をマップします。JDBC属性の定義にはLDAP属性の名前と、該当する情報がある表および列が含まれています。
たとえば、次のコマンドはemployeeNumber属性をEMPLOYEE表のIDフィールドにマップします。
$ dpconf add-jdbc-attr -h myHost -p 2389 -d "cn=Proxy Manager" \ EMPLOYEE employeeNumber ID
JDBC属性には次のプロパティがあります。
LDAP構文。 (ldap-syntax) このプロパティは、リレーショナル・データベース表のエントリからLDAP表を構成するために使用される構文を定義します。
JDBC属性の構文に対する変更が考慮されるためにはサーバーの再起動が必要です。
SQL列。 (sql-column) LDAP属性の取得元のリレーショナル・データベース表の列。
SQL構文。 (sql-syntax) このプロパティはLDAPエントリからリレーショナル・データベース表のエントリを構成するために使用される構文を定義します。
場合によっては、LDAP属性に大文字小文字の区別がなく、リレーショナル・データベースの対応する列に大文字小文字の区別があることがあります。Directory Proxy Serverは、UPPERキーワードを同等索引付けおよび部分文字列索引付けに追加することにより、この状態を処理します。これはパフォーマンスに重大な影響を与える場合があります。したがって、リレーショナル・データベースで大文字小文字の区別が必要な場合は、大文字の値に対して特定の索引を作成する必要があります。
仮想データ・ビューではDirectory Proxy Serverは仮想データを表示します。したがって、Directory Proxy Serverはそのデータに誰がアクセスできるか、およびそのデータのどの部分をアクセス可能にするかの制御を担当します。仮想データへのアクセスを制御するために、仮想ACIを定義できます。Directory Proxy Serverが仮想データ・ビューに対するリクエストを受信すると、仮想ACIおよび、ユーザーにより提供された認証情報を使用して、リクエストされた情報へのアクセスを許可または拒否します。
この項では仮想ACIの構文およびアーキテクチャについて説明します。仮想ACIの構成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の仮想データ・ビューのアクセス制御の定義に関する説明を参照してください。
仮想ACIはdpsaci操作属性を使用して定義されます。dpsaci属性は複数値です。これは、ディレクトリの同じ部分に対して複数のACIを定義できることを意味します。
Directory Proxy Serverはdpsaci属性の管理を担当します。この属性は物理データとともに構成できますが、データと一緒には保管されません。dpsaci属性がリクエストに含まれている場合、Directory Proxy Serverはリクエストからそれを抽出し、独自のACIデータ・ビューを介してそれを専用のACIリポジトリで管理します。
仮想データ・ビューを対象とし、dpsaci属性を含む変更リクエストは、Directory Proxy Serverにより2つのリクエストに効率的に分割されます。最初のリクエストは仮想データのみを処理し、2番目のリクエストは仮想ACIを処理します。
|
注意: デフォルトで、書込み操作はLDAPデータ・ビュー以外のビューでは許可されていません。 |
グローバルACIは、エントリcn=data-source-name,cn=virtual access controlsで定義されます。これらのACIはACIエンジンにより評価され、そのACIプールを使用する接続ハンドラからのリクエストを拒否するか、または許可します。グローバルACIは、アプリケーション管理者による特定データへのアクセスを許可または拒否するために必要です。その後、これらのアプリケーション管理者は、データに直接ACIを配置することにより、よりきめ細かなアクセス制御を提供できます。
プロキシ・マネージャのみがACIのプールを作成し、ACIデータ・ビューを介して直接ACIを管理できます。アプリケーション管理者は、たとえエントリを追加する権限を持っても、ACIデータ・ビューを介してACIを管理することはできません。アプリケーション・マネージャはデータを介してACIを管理できるだけです。
データそのものに定義されているACIは、Directory Proxy Serverにより評価されます。これらのACIは、プロキシ・マネージャにより定義されたACIのプールにあるエントリ、つまり、エントリcn=data-source-name,cn=virtual access controlsの子エントリです。
ACIはパフォーマンスに影響を及ぼします。したがって、データそのものでACIを使用する場合、サブツリーがアクセスされるたびにグローバルACIが評価されるため、グローバルACIのルール数を最小限にしてください。
dpsaci属性は、構文と振舞いにおいてDirectory Serverのaci属性に似ています。Directory ServerのACI構文の説明は、「Directory Serverのアクセス制御の提供方法」を参照してください。
次のリストでは、仮想ACIとDirectory Server ACIの間の違いを説明します。
ターゲット・キーワード。target、targetAttrおよびtargetscopeの各キーワードのみがサポートされています。
許可キーワード。All 書込み権限はselfwrite操作を許可しません。
バインド・ルール・サブジェクト。パフォーマンス上の理由から、仮想ACIはldap:///suffix??sub?(filter)をuserdnキーワードの値としてサポートしていません。
バインド・ルール・コンテキスト。仮想ACIはSASL認証をサポートしていません。さらに、ipキーワードはサブネット・マスクをサポートしていません。
仮想ACIはLDIFファイルまたはLDAPディレクトリに、一元的に格納されます。Directory Proxy Serverインスタンスを作成するときに、仮想ACIはデフォルトでLDIFファイルinstance-path /config/access_controls.ldifに格納されます。特に複数のプロキシ・サーバー間でACIを共有する場合など、仮想ACIの場所を変更できます。仮想ACIの場所を変更する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の新しいACIストレージ・リポジトリの定義に関する説明を参照してください。
ACIリポジトリは、リポジトリのタイプに応じてLDAPまたはLDIFデータ・ビューを介してアクセスされます。デフォルトで、アクセス制御データ・ビューはvirtual access controlsという名前のLDIFデータ・ビューです。アクセス制御データ・ビューにより表示されるビュー・ベースはACIリポジトリ内に存在する必要があります。
ACIリポジトリには1つ以上のACIのプールが含まれています。ACIプールは、データ・ビューのビュー・ベースの直下にある、タイプがaciSourceのLDAPエントリにより定義されます。ACIプールはエントリのサブツリーです。これはアクセス制御を含めることができ、ACIが含まれている他のエントリの親エントリとなることができます。
Directory Proxy Serverでは、物理データ・ソースのスキーマとは異なる独自のスキーマがあります。Directory Proxy ServerのスキーマはローカルのLDIFファイルに保管されるか、またはリモートのDirectory Serverに保管されます。dpconfコマンドを使用して、スキーマを保管する場所を構成できます。接続ハンドラごとに1つのスキーマが定義されます。特定の接続ハンドラのスキーマは、ldapsearchまたはldapmodifyを使用して取得または更新できます。スキーマが更新された場合、変更が有効になるためにはDirectory Proxy Serverを再起動する必要があります。
一般的に、スキーマ・チェックは、そのスキーマを表示するサーバーにより実行されます。Directory Proxy Serverが1つ以上のDirectory Serverのプロキシとして動作するシナリオでは、それらのDirectory Serverにより、追加リクエストおよび変更リクエストがそれらのLDAPスキーマに準拠しているかが確認されます。Directory Proxy Serverが独自のスキーマを表示する場合、Directory Proxy Serverは追加リクエストおよび変更リクエストがこれらのスキーマに準拠していることを確認する必要があります。
スキーマは特定の接続ハンドラに対して定義されるため、スキーマ・チェックは接続ハンドラごとに有効化されます。スキーマ・チェックは、接続ハンドラのschemaCheck属性をtrueに設定することにより、有効化されます。
仮想データ・ビューを使用して、ローカルの仮想グループを定義し、ACIを介してそれらを使用できます。バックエンド・サーバーに定義された既存のグループにも依存できます。DNマッピングを使用することにより、LDAPディレクトリのグループを仮想ネームスペースで表示されるように変換できます。属性値の名前変更を使用して、すべてのメンバーのDNを変換することもできます。
結合データ・ビューでは、メンバーの名前の競合がないかぎり、2つの異なるLDAPバックエンドからの2つの静的グループを結合できます。ACIを使用して、たとえばuniquemember属性に読取り専用の仮想グループを作成することもできます。
Directory Proxy ServerサーバーはACIの領域でのみグループを使用します。ACIエンジンはgroupdnキーワードを使用することにより、静的グループと動的グループの両方を参照できます。
仮想ACIは静的グループと動的グループの両方をサポートします。ただし、isMemberOf機能はサポートされていません。パフォーマンスに重大な影響を及ぼすため、ネストされたグループもサポートされません。
動的グループの場合、属性値の名前変更はその値がLDAP URLであり、したがってDN構文ではないため、動的グループの値には適用されません。言い換えれば、動的グループの値にDNが含まれている場合、そのDNの部分は名前変更されません。
