| Oracle® Fusion Middleware Oracle Directory Server Enterprise Edition管理者ガイド 11g リリース1 (11.1.1.7.0) B72439-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Edition管理者ガイド 11g リリース1 (11.1.1.7.0) B72439-01 |
|
前 |
次 |
この章では、仮想データ・ビューの作成方法について説明します。仮想データ・ビューは、ソース・データを変換し、クライアント・アプリケーションにそのデータの異なるビューを表示します。仮想データ・ビューは、変換されたLDAPデータ・ビュー、LDIFデータ・ビュー、結合データ・ビュー、JDBCデータ・ビューなどです。仮想データ・ビューの機能の概要および使用例の説明は、Oracle Directory Server Enterprise Editionリファレンスの第18章のDirectory Proxy Serverの仮想化に関する説明を参照してください。
Directory Service Control Center(DSCC)を使用して、この章の手順を実行することはできません。コマンドラインを使用する必要があります。
この章の内容は、次のとおりです。
LDIFデータ・ビューは、LDIFファイルがLDAPデータソースのように見える単純な仮想データ・ビューです。LDAPデータ・ビューとは異なり、LDIFデータ・ビューを設定するときに、データソースまたはデータソース・プールを作成しません。かわりに、データ・ビューを作成するときに、LDIFファイルを指定します。デフォルトでは、LDIFデータ・ビューに書き込むことはできません。詳細は、「仮想データ・ビューのアクセスする制御の定義」を参照してください。
LDIFデータ・ビューの作成および構成の詳細は、次の手順を参照してください。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
LDIFデータ・ビューを作成します。
$ dpconf create-ldif-data-view -h host -p port view-name path-to-ldif-file suffix-dn
LDIFデータ・ビューのリストを表示します。
$ dpconf list-ldif-data-views -h host -p port
virtual access controlsデータ・ビューは、唯一のデフォルトのLDIFデータ・ビューです。このデータ・ビューは、サーバーによって生成され、リクエストを仮想アクセス制御命令(ACI)にルーティングできるようにします。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
LDIFデータ・ビューのプロパティを表示します。
$ dpconf get-ldif-data-view-prop -h host -p port view-name
LDIFデータ・ビューには、次のデフォルトのプロパティがあります。
alternate-search-base-dn : - attr-name-mappings : none base-dn : suffixDN bind-pwd-attr : userPassword contains-shared-entries : false custom-distribution-algorithm : none db-pwd-encryption : clear-text description : - distribution-algorithm : none dn-join-rule : none dn-mapping-attrs : none dn-mapping-source-base-dn : none excluded-subtrees : - filter-join-rule : none is-enabled : true is-read-only : false is-routable : true ldif-data-source : /path/to/filename.ldif lexicographic-attrs : all lexicographic-lower-bound : none lexicographic-upper-bound : none non-viewable-attr : none non-writable-attr : none numeric-attrs : all numeric-default-data-view : false numeric-lower-bound : none numeric-upper-bound : none pattern-matching-base-object-search-filter : all pattern-matching-dn-regular-expression : all pattern-matching-one-level-search-filter : all pattern-matching-subtree-search-filter : all process-bind : - replication-role : master viewable-attr : all except non-viewable-attr writable-attr : all except non-writable-attr
「LDIFデータ・ビューのプロパティを表示します。」でリストされたプロパティを1つ以上変更します。
$ dpconf set-ldif-data-view-prop -h host -p port view-name property:value \ [property:value ... ]
たとえば、データ・ビューのソースLDIFファイルを変更するには、ldif-data-sourceプロパティを設定します。
$ dpconf set-ldif-data-view-prop -h host1 -p 1389 -D cn="Proxy Manager" \ myLDIFDataView ldif-data-source:/local/files/example.ldif
仮想データ・ビュー上のACIは、LDAPディレクトリまたはLDIFファイルに格納できます。仮想ACIがどのように機能するかについては、Oracle Directory Server Enterprise Editionリファレンスの仮想データ・ビューのアクセス制御に関する項を参照してください。
Directory Proxy Serverのインスタンスを作成するとき、仮想アクセス制御の次のデフォルト構成が定義されます。
デフォルトでACIが格納されるLDIFファイル(instance-path/config/access_controls.ldif)
virtual access controlsというLDIFデータ・ビュー
このデータ・ビューでは、Directory Proxy ServerからLDIFファイルに格納されているACIにアクセスできます。
前に説明したデフォルトのACI構成を使用しない場合、異なるストレージ・リポジトリを定義できます。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
仮想ACIが格納されるリポジトリのデータ・ビューを作成します。
ACIがLDAPディレクトリに格納される場合、第17章「LDAPデータ・ビュー」の説明に従って、LDAPデータソース、LDAPデータソース・プールおよびLDAPデータ・ビューを作成します。
ACIがLDIFファイルに格納される場合、「LDIFデータ・ビューの作成および構成」の説明に従って、LDIFデータ・ビューを作成します。
前の手順で作成したデータ・ビューの名前をACIデータ・ビューとして指定します。
$ dpconf set-virtual-aci-prop -h host -p port aci-data-view:data-view-name
ACIリポジトリがLDAPディレクトリの場合、ACIデータ・ビューへのアクセスに必要な資格証明を定義します。
$ dpconf set-virtual-aci-prop -h host -p port aci-manager-bind-dn:bind-dn $ dpconf set-virtual-aci-prop -h host -p port aci-manager-bind-pwd-file:filename
使用するACIリポジトリに関係なく、仮想アクセス制御を構成する必要があります。
|
注意: プロキシ・マネージャのみがACIのプールを作成し、ACIデータ・ビューを介して直接ACIを管理できます。ACIリポジトリがLDAPディレクトリの場合、 |
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
ACIリポジトリにACIのプールを作成し、グローバルACIを設定します。
グローバルACIの詳細は、Oracle Directory Server Enterprise EditionリファレンスのグローバルACIに関する項を参照してください。グローバルACIを設定するには、aciSourceエントリをACIデータ・ビューのビュー・ベースの下に追加します。次に例を示します。
% ldapmodify -p port -D "cn=proxy manager" -w - dn: cn=aci-source-name,cn=virtual access controls changetype: add objectclass: aciSource dpsaci: (targetattr="*") (target="ldap:///ou=people,o=virtual") (version 3.0; acl "perm1"; allow(all) groupdn="ldap:///cn=virtualGroup1,o=groups,o=virtual";) cn: aci-source-name
このACIのプールを使用するように1つ以上の接続ハンドラを構成します。
% dpconf set-connection-handler-prop -h host -p port connection-handler \ aci-source:aci-source-name
必要なACIをデータに追加します。
このためには、ACIを含む仮想エントリを作成します。次に例を示します。
% ldapmodify -p port -D "cn=virtual application,ou=application users,dc=com" -w -
dn: ou=people,o=virtual
changetype: modify
add: dpsaci
dpsaci: (targetattr="*")(version 3.0; acl "perm1"; allow(all) userdn="ldap:///self";)
dpsaci: (targetattr="*")(version 3.0; acl "perm1"; allow(search, read, compare)
userdn ="ldap:///anyone";)
|
注意: 適切なアクセス権を持つ任意のユーザーは、データ・ビューを介して仮想ACIの追加および取得を実行できます。 |
一般的に、LDAPデータ・ビューでは、スキーマ・チェックは、バックエンド・ディレクトリのスキーマを使用して、バックエンド・ディレクトリによって実行されます。Directory Proxy Serverによってスキーマ・チェックを実行する場合、次の手順を使用します。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
リクエスト(特にDN)を正規化するには、サーバーのuse-external-schemaプロパティを次のように設定します。
サーバーのインスタンスが外部スキーマを使用する必要があることを示します。
$ dpconf set-server-prop -h host -p port use-external-schema:true
接続ハンドラに対するスキーマ・チェックを有効にします。
$ dpconf set-connection-handler-prop -h host -p port connection-handler \ schema-check-enabled:true
cn=schemaを公開するデータ・ビューを作成します。
外部スキーマがLDAPディレクトリで定義されている場合、第17章「LDAPデータ・ビュー」の説明に従って、LDAPデータ・ビューを作成し、ビュー・ベースをcn=schemaにします。
外部スキーマがLDIFファイルで定義されている場合、「LDIFデータ・ビューの作成および構成」の説明に従って、LDIFデータ・ビューを作成し、ビュー・ベースをcn=schemaにします。
このデータ・ビューを接続ハンドラによって公開されるデータ・ビューのリストに追加します。
デフォルトでは、すべてのデータ・ビューが接続ハンドラによって公開されます。接続ハンドラによって公開されるデータ・ビューのカスタム・リストを定義済の場合、このデータ・ビューをそのリストに追加します。
$ dpconf set-connection-handler-prop -h host -p port connection-handler \ data-view-routing-custom-list+:data-view-name
結合データ・ビューは、複数のデータ・ビューの集約です。結合データ・ビューがどのように機能するかについては、Oracle Directory Server Enterprise Editionのリファレンスの結合データ・ビューに関する項を参照してください。
結合データ・ビューを作成して構成する方法の詳細は、次の手順を参照してください。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
結合ビューを形成するために集約されるプライマリ・データ・ビューとセカンダリ・データ・ビューを特定します。
結合ビューを作成するには、その前にプライマリ・データ・ビューとセカンダリ・データ・ビューが存在する必要があります。プライマリ・ビューとセカンダリ・ビューは、LDAPデータ・ビュー、LDIFデータ・ビュー、JDBCデータ・ビュー、その他の結合データ・ビューなど任意のタイプのデータ・ビューにできます。セカンダリ・ビューが結合ビューのソースとして機能できるように、セカンダリ・ビューに関して特定のプロパティを構成する必要があります。詳細は、「結合ビューのセカンダリ・ビューを構成するには:」を参照してください。
結合データ・ビューを作成します。
$ dpconf create-join-data-view -h host -p port view-name primary-view secondary-view \ suffix-dn
結合ビューのリストを表示し、データ・ビューが正しく作成されたことを確認します。
$ dpconf list-join-data-views -h host -p port
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
結合データ・ビューのプロパティを表示します。
$ dpconf get-join-data-view-prop -h host -p port view-name
結合データ・ビューのデフォルトのプロパティは、次のとおりです。
allow-heuristic-search : true allow-partial-search : false alternate-search-base-dn : - attr-name-mappings : none base-dn : suffixDN contains-shared-entries : false custom-distribution-algorithm : none description : - distribution-algorithm : none dn-join-rule : none dn-mapping-attrs : none dn-mapping-source-base-dn : none excluded-subtrees : - filter-join-rule : none is-enabled : true is-read-only : false is-routable : true join-rule-control-enabled : false lexicographic-attrs : all lexicographic-lower-bound : none lexicographic-upper-bound : none non-viewable-attr : none non-writable-attr : none numeric-attrs : all numeric-default-data-view : false numeric-lower-bound : none numeric-upper-bound : none pattern-matching-base-dn-regular-expression : all pattern-matching-base-object-search-filter : all pattern-matching-dn-regular-expression : all pattern-matching-one-level-search-filter : all pattern-matching-subtree-search-filter : all primary-view : primary-view process-bind : - replication-role : master request-grouping-size : 5 secondary-view : secondary-view viewable-attr : all except non-viewable-attr vlv-control-enabled : false vlv-control-page-size : 1k vlv-control-sorting-attr : objectclass writable-attr : all except non-writable-attr
「結合データ・ビューのプロパティを表示します。」でリストされたプロパティを1つ以上変更します。
$ dpconf set-join-data-view-prop -h host -p port view-name property:value \ [property:value ... ]
たとえば、データソースのプライマリ・データ・ビューをmyLDAPDataViewに変更するには、次のコマンドを使用します。
$ dpconf set-join-data-view-prop -h host1 -p 1389 -D cn="Proxy Manager" \ myJoinDataView primary-view:myLDAPDataView
vlv-control-enabledがtrueに設定されている場合、Directory Proxy Serverは、プライマリ・データ・ビューに接続するときに、検索リクエストでVLV制御を使用します。
結合データ・ビューを構成するとき、プライマリ・データ・ビューとセカンダリ・データ・ビューでviewable-attrプロパティとwritable-attrプロパティを設定します。
これらのプロパティを設定すると、検索フィルタをプライマリ・データ・ビューとセカンダリ・データ・ビューに適切に分割する際に役立ちます。これを行わないと、検索フィルタにセカンダリ・データ・ビューの属性が含まれる場合に、検索結果の不一致が発生する可能性があります。
必要な場合は、Directory Proxy Serverのインスタンスを再起動して、変更を有効にします。
Directory Proxy Serverの再起動については、「Directory Proxy Serverを再起動するには:」を参照してください。
結合データ・ビューで結合ルール構成情報を設定すると、複数の結合データ・ビューでデータ・ビューを参照できるようになります。このようにするには、次の手順を実行します。
結合データ・ビューで、join-rule-control-enabledをtrueに設定します。
$ dpconf set-join-data-view-prop view-name join-rule-control-enabled:true
join-rule-control-enabledをtrueに設定した後、結合データ・ビューに格納されている結合ルール構成情報がサーバーによって使用されます。結合ルール構成情報がセカンダリ・データ・ビューに格納されている結合データ・ビューの場合、この情報はサーバーによって使用されません。この情報をサーバーで使用させるには、結合データ・ビュー・レベルで手動で構成情報を追加する必要があります。
セカンダリ・ビューがプライマリ・ビューとどのように関連付けられるかを決定する結合ルールを定義します。
結合ルールは、次のいずれかです。
DN結合ルール
$ dpconf set-join-data-view-prop view-name \ dn-join-rule:uid=\${primary-view-name.uid},ou=People,dc=example
フィルタ結合ルール
$ dpconf set-join-data-view-prop view-name \ filter-join-rule:uid=\${primary-view-name.uid}
前述のコマンドで、属性名は、変数として処理される場合、${}で囲まれています。属性名を${}で囲まない場合、その属性名は、定数として処理されます。
UNIXでbashまたはkshを使用する場合、$文字は、\${primary-view-name.uid}のような構成内では\によってエスケープする必要があります(Windowsでは、エスケープは必要ありません)。
セカンダリ・データ・ビューが結合ビューのソースとして機能できるように、セカンダリ・データ・ビューに関して特定のプロパティを構成する必要があります。セカンダリ・ビューは任意のタイプのデータ・ビューにできるため、使用するコマンドは、データ・ビューのタイプによって異なります。次のコマンド例は、セカンダリ・ビューがLDAPデータ・ビューであることを前提にしています。ここに記述されているプロパティの詳細は、Oracle Directory Server Enterprise Editionのリファレンスの追加のセカンダリ・データ・ビューのプロパティに関する項を参照してください。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
セカンダリ・ビューがプライマリ・ビューとどのように関連付けられるかを決定する結合ルールを定義します。
結合ビューのプライマリ・データ・ビューでfilter-join-ruleとdn-join-ruleは設定しないでください。
結合ルールは、次のいずれかです。
DN結合ルール
$ dpconf set-ldap-data-view-prop -h host -p port secondary-view-name \ dn-join-rule:uid=\${primary-view-name.uid},ou=People,dc=example
フィルタ結合ルール
$ dpconf set-ldap-data-view-prop -h host -p port secondary-view-name \ filter-join-rule:uid=\${primary-view-name.uid}
dn-join-ruleプロパティとfilter-join-ruleプロパティの構成は、結合データ・ビューのjoin-rule-control-enabledプロパティがfalseに設定されている場合のみサーバーによって使用されます。それ以外の場合、結合データ・ビューでjoin-rule-control-enabledプロパティがtrueに設定されていると、セカンダリ・ビューに設定されている情報は無視されます。
フィルタ結合ルールが結合データ・ビューで設定されている場合、セカンダリ・データ・ビューの仮想変換ルールを設定し、結合データ・ビューのエントリを追加できるようにする必要があります。
dpconf add-virtual-transformation secondary-view-name \
write add-attr-value dn uid=\${uid}
|
注意: このルールを設定しないと、エントリを結合データ・ビューに追加できません。 |
セカンダリ・ビューでバインドを許可するかどうか指定します。
デフォルトでは、バインドは、すべてのデータ・ビューで許可されています。セカンダリ・データ・ビューへのバインドを禁止するには、次のコマンドを実行します。
$ dpconf set-ldap-data-view-prop -h host -p port secondary-view-name process-bind:false
このプロパティの詳細は、Oracle Directory Server Enterprise Editionのリファレンスのバインドの処理に関する項を参照してください。
セカンダリ・ビューに共有エントリを含めるかどうか指定します。
$ dpconf set-ldap-data-view-prop -h host -p port secondary-view-name \ contains-shared-entries:true
このプロパティの詳細は、Oracle Directory Server Enterprise Editionのリファレンスの共有エントリの処理に関する項を参照してください。
コーディネータ・データ・ビューには、コーディネートするデータ・ビューの順序付けされたリストがあります。コーディネータ・データ・ビューは、リクエストを受信すると、それをコーディネートされたデータ・ビューに正しい順序で送信します。この順序は、コーディネートされたデータ・ビューを指定するためにCLIで使用される順序によって定義されます。コーディネータ・データ・ビューは、ルーティング・ポリシーで定義されているようにリクエストをコーディネートされたデータ・ビューに送信し、最後に結果をクライアントに返します。詳細は、Oracle Directory Server Enterprise Editionのリファレンスのコーディネータ・データ・ビューに関する項を参照してください。
コーディネータ・データ・ビューは、次のルーティング・ポリシーをサポートします。
first-match: 最初の一致でリクエストの送信を停止します。
all-candidates: すべてのコーディネートされたデータ・ビューにリクエストを送信します。
mirror: 最初のコーディネートされたデータ・ビューにすべてのリクエストを送信しますが、書込みリクエストはすべてのコーディネートされたデータ・ビューに送信されます。
|
注意: コーディネータ・データ・ビューによってコーディネートされたすべてのデータ・ビューは、コーディネータ・データ・ビューのビュー・ベースと同じビュー・ベースを持っている必要があります。 |
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
コーディネータ・データ・ビューを形成するために集約されるデータ・ビューを特定します。
データ・ビューは、コーディネータ・データ・ビューを作成する前に存在している必要があります。データ・ビューは、LDAPデータ・ビュー、LDIFデータ・ビュー、JDBCデータ・ビュー、その他の結合データ・ビューなど任意のタイプのデータ・ビューにできます。
コーディネータ・データ・ビューを作成します。
$ dpconf create-coordinator-data-view -h host -p port VIEW_NAME \ COORDINATED_VIEW [COORDINATED_VIEW...] SUFFIX_DN
次のコマンドでは、2つのデータ・ビューを使用して、コーディネータ・データ・ビューview_comが作成されます。
$ dpconf create-coordinator-data-view -h host -p port view_com \ first_view second_view dc=com
コーディネータ・データ・ビューのリストを表示し、データ・ビューが正しく作成されたことを確認します。
$ dpconf list-coordinator-data-views -h host -p port
この場合、前述のコマンドによって、view_comが表示されます。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
コーディネータ・データ・ビューのプロパティを表示します。
$ dpconf get-coordinator-data-view-prop -h host -p port VIEW_NAME
結合データ・ビューのデフォルトのプロパティは、次のとおりです。
alternate-search-base-dn : "" attr-name-mappings : none base-dn : "" contains-shared-entries : - coordinated-data-view : first_view coordinated-data-view : second_view custom-distribution-algorithm : none description : - distribution-algorithm : none dn-join-rule : none dn-mapping-attrs : none dn-mapping-source-base-dn : none excluded-subtrees : "" filter-join-rule : none is-enabled : true is-read-only : false is-routable : true lexicographic-attrs : all lexicographic-lower-bound : none lexicographic-upper-bound : none non-viewable-attr : none non-writable-attr : none numeric-attrs : all numeric-default-data-view : false numeric-lower-bound : none numeric-upper-bound : none pattern-matching-base-object-search-filter : all pattern-matching-dn-regular-expression : all pattern-matching-one-level-search-filter : all pattern-matching-subtree-search-filter : all process-bind : - replication-role : master routing-policy : all-candidates viewable-attr : all except non-viewable-attr writable-attr : all except non-writable-attr
たとえば、次のコマンドによって、指定されたコーディネータ・データ・ビューのcoordinated-data-viewsプロパティがリストされます。
$ dpconf get-coordinator-data-view-prop VIEW_NAME coordinated-data-view
coordinated-data-view : first_view
coordinated-data-view : second_view
「結合データ・ビューのプロパティを表示します。」でリストされたプロパティを1つ以上変更します。
$ dpconf set-coordinator-data-view-prop -h host -p port VIEW_NAME PROP:VAL \ [PROP:VAL...]
たとえば、次のコマンドを使用して、コーディネータ・データ・ビューにコーディネートされたデータ・ビューを追加します。
$ dpconf set-coordinator-data-view-prop -h host -p port view_com \ coordinated-data-view+:third_view coordinated-data-view+:fouth_view
前述のコマンドで指定されたコーディネートされたデータ・ビューの順序のとおり、コーディネートされたデータ・ビューが次の順序で送信されます。
$ dpconf get-coordinator-data-view-prop VIEW_NAME coordinated-data-view
coordinated-data-view : first_view
coordinated-data-view : second_view
coordinated-data-view : third_view
coordinated-data-view : fourth_view
コーディネータ・データ・ビューがリクエストをコーディネートされたデータ・ビューに送信する方法を記述した、routing-policyモードを変更します。
$ dpconf set-coordinator-data-view-prop -h host -p port view_com \ routing-policy:first-match
詳細は、routing-policyに関する説明を参照してください。
必要な場合は、Directory Proxy Serverのインスタンスを再起動して、変更を有効にします。
Directory Proxy Serverの再起動については、「Directory Proxy Serverを再起動するには:」を参照してください。
JDBCデータ・ビューを使用すると、リレーショナル・データベースからLDAPクライアント・アプリケーションにアクセスできます。JDBCデータ・ビューがどのように機能するかについては、Oracle Directory Server Enterprise EditionのリファレンスのJDBCデータ・ビューに関する項を参照してください。
JDBCデータ・ビューを作成して構成する方法の詳細は、次の手順を参照してください。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
リレーショナル・データベースのJDBCデータソースを作成します。
$ dpconf create-jdbc-data-source -h host -p port -b db-name -B db-url -J driver-url \ [-J driver-url]... -S driver-class source-name
現在、1つのJDBCデータソースのみが各JDBCデータ・ビューに対してサポートされています。つまり、JDBCデータソース間でロード・バランシングできません。複数のJDBCデータソースにアクセスするために、各データソースにデータ・ビューを作成し、これらを結合データ・ビューと結合できます。
JDBCデータソースを作成するとき、次のプロパティを設定する必要があります。
db-nameリレーショナル・データベースの名前(たとえば、payrolldb)。
db-urlデータベースへのURLで、形式は、jdbc:vendor:driver://dbhost:dbportです。
db-urlは、データベース名を含んでいないため、完全なJDBCデータベースURLではありません。(データベース名は、db-nameプロパティによって指定されます。)
MySQL、DB2およびDerbyの各データベースに対しては、最後にdb-urlに/を付け、Oracle Databaseに対しては、:を付ける必要があります。
driver-classJDBCドライバ・クラス(たとえば、org.hsqldb.jdbcDriver)。
driver-urlJDBCドライバへのパス(たとえば、file:///path/to/hsqldb/lib/hsqldb.jar)。
driver-urlプロパティは複数値です。したがって、driver-urlは、JDBCドライバに対して複数のJARファイルをサポートし、異なるプラットフォーム上でJDBCソースに接続できるようにします。
DBベンダーが提供するJDBCドライバ以外のサード・パーティJDBCドライバを使用してRDBMSバックエンドに接続する場合、db-vendorプロパティを設定します。db-vendorプロパティの詳細は、db-vendorを参照してください。
JDBCデータソース・プールを作成します。
$ dpconf create-jdbc-data-source-pool -h host -p port pool-name
JDBCデータソースをJDBCデータソース・プールにアタッチします。
$ dpconf attach-jdbc-data-source -h host -p port pool-name source-name
JDBCデータ・ビューを作成します。
$ dpconf create-jdbc-data-view -h host -p port view-name pool-name suffix-DN
JDBCデータ・ビューのリストを表示し、ご使用のデータ・ビューが正しく作成されたことを確認します。
$ dpconf list-jdbc-data-views -h host -p port
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
JDBCデータ・ビューのプロパティを表示します。
$ dpconf get-jdbc-data-view-prop -h host -p port view-name
JDBCデータ・ビューのデフォルトのプロパティは、次のとおりです。
alternate-search-base-dn : -
attr-name-mappings : none
base-dn : o=sql1
contains-shared-entries : -
description : -
distribution-algorithm : -
dn-join-rule : -
dn-mapping-attrs : none
dn-mapping-source-base-dn : none
excluded-subtrees : -
filter-join-rule : -
is-enabled : true
is-read-only : false
is-routable : true
jdbc-attr-date-format : yyyy-MM-dd
jdbc-attr-time-format : hh:mm:ss
jdbc-attr-timestamp-format : yyyy-MM-dd hh:mm:ss
jdbc-data-source-pool : pool-name
lexicographic-attrs : all
lexicographic-lower-bound : none
lexicographic-upper-bound : none
non-viewable-attr : -
non-writable-attr : -
numeric-attrs : all
numeric-default-data-view : false
numeric-lower-bound : none
numeric-upper-bound : none
pattern-matching-base-object-search-filter : all
pattern-matching-dn-regular-expression : all
pattern-matching-one-level-search-filter : all
pattern-matching-subtree-search-filter : all
process-bind : -
replication-role : master
viewable-attr : all except non-viewable-attr
writable-attr : all except non-writable-attr
「JDBCデータ・ビューのプロパティを表示します。」でリストされたプロパティを1つ以上変更します。
$ dpconf set-jdbc-data-view-prop -h host -p port view-name property:value \ [property:value ... ]
ISO形式の他に、次のすべての形式で日付、時刻およびタイムスタンプの属性タイプのJDBC属性を設定できます。
日付と時刻を構成するコンポーネントを次にリストします。
Letter Date or Time Component Examples G Era designator AD y Year 1996; 96 M Month in year July; Jul; 07 w Week in year 27 W Week in month 2 D Day in year 189 d Day in month 10 F Day of week in month 2 E Day in week Tuesday; Tue a Am/pm marker PM H Hour in day (0-23) 0 k Hour in day (1-24) 24 K Hour in am/pm (0-11) 0 h Hour in am/pm (1-12) 12 m Minute in hour 30 s Second in minute 55 S Millisecond 978 z Time zone Pacific Standard Time; PST; GMT-08:00 Z Time zone -0800
次の例は、日時パターンが米国のロケールでどのように解釈されるかを示しています。指定された日時は、米国太平洋標準時タイムゾーンの2001-07-04 12:08:56ローカル時間です。
Date and Time Pattern Result "yyyy.MM.dd G 'at' HH:mm:ss z" 2001.07.04 AD at 12:08:56 PDT "EEE, MMM d, ''yy" Wed, Jul 4, '01 "h:mm a" 12:08 PM "hh 'o''clock' a, zzzz" 12 o'clock PM, Pacific Daylight Time "K:mm a, z" 0:08 PM, PDT "yyyyy.MMMMM.dd GGG hh:mm aaa" 02001.July.04 AD 12:08 PM "EEE, d MMM yyyy HH:mm:ss Z" Wed, 4 Jul 2001 12:08:56 -0700 "yyMMddHHmmssZ" 010704120856-0700 "yyyy-MM-dd'T'HH:mm:ss.SSSZ" 2001-07-04T12:08:56.235-0700
JDBCデータ・ビューを構成するとき、次のオブジェクトも構成する必要があります。
JDBCオブジェクト・クラス。1つ以上のJDBC表をLDAPオブジェクト・クラスにマップします。
JDBC表。各リレーショナル・データベース表に対して定義されます。
JDBC属性。JDBC表の指定された列からLDAP属性を定義します。
リレーショナル・データベース内の各表に対してJDBC表を作成します。
% dpconf create-jdbc-table jdbc-table-name db-table
db-tableの名前は、大文字と小文字を区別します。大文字/小文字は、リレーショナル・データベースで使用されているものと同じにしてください。そうしないと、その表をターゲットとする操作が失敗する場合があります。
各リレーショナル・データベース表の各列にJDBC属性を作成します。
% dpconf add-jdbc-attr table-name attr-name sql-column
JDBC属性を作成すると、表の列がLDAP属性にマップされます。
リレーショナル・データベースの列が大文字と小文字を区別する場合、JDBC属性のLDAP構文を変更します。
% dpconf set-jdbc-attr-prop table-name attr-name ldap-syntax:ces
ldap-syntaxの値は、デフォルトではcisです。これは、jdbc-attrが大文字と小文字を区別しないことを示しています。リレーショナル・データベースが大文字と小文字を区別する場合、この値をcesに変更します。
OracleやDB2などの特定のリレーショナル・データベースは、デフォルトで大文字と小文字を区別します。LDAPは、デフォルトでは大文字と小文字を区別しません。リレーショナル・データベース表の列が大文字と小文字を区別することをDirectory Proxy Serverが検出すると、フィルタに対応する属性が含まれているldapsearch問合せは、関数UPPERを使用してSQL問合せに変換されます。
たとえば、問合せldapsearch -b "dc=mysuffix" "(attr=abc)"は、次のSQL問合せに変換されます。
SELECT * FROM mytable WHERE (UPPER(attr)='ABC')
デフォルトでは、このタイプの問合せは、索引付けされません。したがって、この種類の問合せは、パフォーマンスに多大な影響を与えます。
次の2つの方法でパフォーマンスへの影響を軽減できます。
jdbc-attrのldap-syntaxプロパティをcesに設定します。
LDAPフィルタに使用されている可能性がある各jdbc-attrに対して関数UPPERで索引を作成します。
|
注意: リレーショナル・データベースが大文字と小文字を区別しない場合、 |
LDAPリレーショナル・データベース表のJDBCオブジェクト・クラスを作成します。
% dpconf create-jdbc-object-class view-name objectclass primary-table \ [secondary-table... ] DN-pattern
JDBCオブジェクト・クラスを作成すると、これらの表が関連付けられるLDAPオブジェクトが指定されます。JDBCオブジェクト・クラスは、プライマリ表とセカンダリ表も指定します(これらが存在する場合)。
JDBCオブジェクト・クラスを作成するとき、DNパターンを指定します。DNパターンは、エントリのDNの構成に使用される属性を記述しています。たとえば、DNパターンをuidと指定すると、エントリのDNは、属性uidおよびデータ・ビューのビュー・ベースを使用して構成されます。たとえば、uid=bjensen,ou=people,dc=example,dc=comとなります。DNパターンは、複数の属性を構成できます。この場合、属性を,(カンマ)で区切る必要があります。たとえば、DNパターンをuid,countryと指定すると、データ・ビューによって返されるエントリのDNは、uid=bjensen,country=America,ou=people,dc=example,dc=comになります。
データソースに重複エントリがあり、重複エントリが不要な場合、次のコマンドを使用して、perform-distinct-selectをtrueに設定します。
% dpconf set-jdbc-object-class-prop view-name objectclass perform-distinct-select:true
JDBCオブジェクト・クラスのDNパターンで定義されるすべてのサブツリー・コンポーネントでは、JDBCオブジェクト・クラスをコンポーネントに対して定義する必要があります。たとえば、JDBCオブジェクト・クラスにDNパターンuid,ouがある場合、DNパターンouを含むJDBCオブジェクト・クラス定義が必要です。これは、Directory Proxy Serverで正しい構造のDITを構成するために必要です。そうでない場合、ou=xxx,base-DNなどの値を持つサブツリーは、検索結果に返されません。
セカンダリ表が存在する場合、プライマリ表とセカンダリ表の間の結合ルールを定義します。
% dpconf set-jdbc-table-prop secondary-table-name filter-join-rule:join-rule
結合ルールは、セカンダリ表で定義され、その表からのデータをプライマリ表からのデータとどのようにリンクするかが決定されます。オブジェクト・クラスのプライマリ表とセカンダリ表の間の関係をどのように定義するかは重要です。詳細は、「JDBC表の関係の定義」を参照してください。
JDBCオブジェクト・クラスのスーパー・クラスを指定します。
% dpconf set-jdbc-object-class-prop view-name objectclass super-class:value
スーパー・クラスは、JDBCオブジェクト・クラスの継承元のLDAPオブジェクト・クラスを示しています。
最も単純な例では、JDBCオブジェクト・クラスには、1つ(プライマリ)の表のみが含まれています。セカンダリ表はなく、したがって、表間の関係を定義する必要はありません。
オブジェクト・クラスに複数の表が含まれている場合、これらの表の間の関係を明確に定義する必要があります。表間の関係は、常にセカンダリ表で定義します。セカンダリ表の次のプロパティを使用すると、これらの関係を定義できます。
is-single-row-tableは、LDAPエントリが表に一致する行を1つしか持たないことを指定します。
contains-shared-entriesは、セカンダリ表の行がプライマリ表の複数の行によって使用されることを指定します。
filter-join-ruleは、プライマリ表のなんらかの値に基づいてエントリがセカンダリ表からどのように取得されるかを示します。
次の例は、最初の2つのプロパティの値に基づいて、どのようにフィルタ結合ルールが定義されるかを示しています。これらの例は、オブジェクト・クラスが1つのプライマリ表と1つのセカンダリ表を持っていることを前提にしています。
例22-1 is-single-row-table:trueとcontains-shared-entries:true
これらは、プロパティのデフォルト値です。この場合、プライマリ表とセカンダリ表の関係は、n->1です。つまり、プライマリ表のn個の行がセカンダリ表の1つの共有行を参照します。
リレーショナル・データベースで、外部キー(FK)は、プライマリ表で定義され、セカンダリ表の列を指します。
たとえば、数人の従業員が同じ管理者を共有する組織について考えてみます。2つのリレーショナル・データベース表が次の構造で定義されます。
primary table : EMPLOYEE [ID, NAME, FK_MANAGER_ID] secondary table : MANAGER [ID, NAME]
次のオブジェクト・クラスおよび属性が定義されます。
object-class : employee attr : name (from primary EMPLOYEE.NAME) attr : manager (from secondary MANAGER.NAME)
次のフィルタ結合ルールがセカンダリ表で定義されます。
ID=\${EMPLOYEE.FK_MANAGER_ID}"
複数のセカンダリ表の場合、それぞれのセカンダリ表に対してfilter-join-ruleを構成する必要があります。複数のセカンダリ表に対するfilter-join-ruleの構成方法の詳細は、「プライマリ表とセカンダリ表の間の結合ルールを定義します。」を参照してください。
この構成では、LDAP操作で次の動作が発生します。
従業員のエントリの追加。従業員エントリの管理者が表に存在しない場合は、新しい行が作成されます。管理者が存在する場合は、既存の行が使用されます。
エントリにおける管理者の属性の値を置換。行MANAGER.NAMEの値が変更されます。
従業員のエントリの削除。管理者エントリが共有されているため、セカンダリ表の行は削除されません。
管理者の属性をエントリから削除。セカンダリ表の行が削除され、外部キー(EMPLOYEE.FK_MANAGER_ID)がNULLに設定されます。
属性が削除されると、属性の値はNULLに設定されます。ただし、属性が表定義でNOT NULL属性に定義されている場合、削除できません。
例22-2 is-single-row-table:trueとcontains-shared-entries:false
この場合、プライマリ表とセカンダリ表の関係は、1->1または1<-1です。つまり、プライマリ表の1つの行がセカンダリ表の1つの行に参照されます。
リレーショナル・データベースで、外部キー(FK)は、プライマリ表またはセカンダリ表で定義されます。
たとえば、従業員のUIDがある表に格納されていて、従業員の名字が2番目の表に格納されている組織について考えてみます。2つのリレーショナル・データベース表が次の構造で定義されます。
primary table : UID [ID, VALUE, FK_SN_ID] secondary table : SN [ID, VALUE]
次のオブジェクト・クラスおよび属性が定義されます。
object-class : employee attr : uid (from primary UID.VALUE) attr : sn (from secondary ID.VALUE)
次のフィルタ結合ルールがセカンダリ表で定義されます。
ID=\${UID.FK_SN_ID}
これは、dpconfコマンドを使用して、次のように使用できます。
dpconf set-jdbc-table-prop SN filter-join-rule:ID=\${UID.FK_SN_ID}
この構成は逆に、外部キーFK_UID_IDがセカンダリ表に格納され、UID.IDを指すようにすることもできます。
例22-3 is-single-row-table:falseとcontains-shared-entries:false
この場合、プライマリ表とセカンダリ表の関係は、1->nです。つまり、プライマリ表の1つの行がセカンダリ表のn個の行に参照されます。この例は、複数値属性の場合を示しています。複数値属性は、属性値ごとに1つの行を持つセカンダリ表の一連の行として表されます。
リレーショナル・データベースで、外部キーは、セカンダリ表で定義され、プライマリ表の列を指します。
たとえば、従業員がいくつかの電話番号を持つことができる組織について考えてみます。2つのリレーショナル・データベース表が次の構造で定義されます。
primary table : EMPLOYEE [ID, NAME] secondary table : PHONE [ID, VALUE, USER_ID]
次のオブジェクト・クラスおよび属性が定義されます。
object-class : employee attr : cn (from primary EMPLOYEE.NAME) attr : telephoneNumber (from secondary PHONE.VALUE)
次のフィルタ結合ルールがセカンダリ表で定義されます。
USER_ID=\${EMPLOYEE.ID}
次の項では、2つの構成例を示します。これらの構成では、仮想ディレクトリの主な機能およびこれらの機能の構成方法を示します。
この項の手順では、LDAPディレクトリとMySQLデータベースを結合する仮想構成の例について説明します。LDAPディレクトリは、ほとんどのユーザー情報を含むプライマリ・データソースです。MySQLデータベースには、ユーザーに関する追加の情報が含まれています。構成例を次の図に示します。
install-path/resources/ldif/Example.ldifで提供されているサンプル・データを使用して、この例を複製するか、サンプル・データを独自のデータに置き換えることができます。
この構成は、3つのセクションに分解できます。
LDAPデータ・ビューの構成およびテスト
JDBCデータ・ビューの構成およびテスト
結合データ・ビューの構成およびテスト
簡潔にするために、この項のすべてのコマンドは、Directory Proxy Serverが/local/dpsのローカル・ホストで実行されていることを前提とします。コマンドは、次の環境変数が設定済であることも前提とします。
DIR_PROXY_PORT1389
LDAP_ADMIN_PWFpwd.txt。管理者のパスワードを含むファイル。
DIRSERV_PORT4389
LDAP_ADMIN_USERcn=Directory Manager
開始する前に
この項のタスクは、次の情報を前提としています。
Directory Serverのインスタンスは、host1のポート4389で実行されています。
Directory Serverのデータは、接尾辞dc=example,dc=comの下に格納されています。この例を複製するには、Directory Serverのインスタンスを作成し、接尾辞dc=example,dc=comを作成し、install-path/resources/ldif/Example.ldifのサンプル・データをインポートします。
Directory Serverのインスタンスのmyds1というLDAPデータソースを作成します。
% dpconf create-ldap-data-source myds1 host1:4389
このデータソースを有効にし、データソースへの書込み操作を許可します。
% dpconf set-ldap-data-source-prop myds1 is-enabled:true is-read-only:false
myds1-poolというLDAPデータソース・プールを作成します。
% dpconf create-ldap-data-source-pool myds1-pool
LDAPデータソースをLDAPデータソース・プールにアタッチします。
% dpconf attach-ldap-data-source myds1-pool myds1
データソースがそのデータソース・プールからのバインド、追加、検索および変更の各操作を100%受信するように指定します。
% dpconf set-attached-ldap-data-source-prop myds1-pool myds1 add-weight:100 \ bind-weight:100 modify-weight:100 search-weight:100
データソース・プール用にmyds1-viewというLDAPデータ・ビューを作成し、ベースDNをdc=example,dc=comにします。
% dpconf create-ldap-data-view myds1-view myds1-pool dc=example,dc=com
dc=example,dc=comの下のユーザーとして、LDAPデータソースのすべてのエントリを検索し、データ・ビューから読み取ることができることを確認します。
% ldapsearch -p 1389 -D "uid=kvaughan,ou=people,dc=example,dc=com" -w bribery \ -b dc=example,dc=com "objectclass=*"
|
注意:
|
dc=example,dc=comの下のユーザーとして、userPassword属性を変更し、データ・ビューに書き込むことができることを確認します。
% ldapmodify -p 1389 -D "uid=kvaughan,ou=people,dc=example,dc=com" -w bribery dn: uid=kvaughan,ou=people,dc=example,dc=com changetype: modify replace: userPassword userPassword: myNewPassword
|
注意: Directory ServerのデフォルトのACIを使用すると、ユーザーは独自のパスワードを変更できます。 |
次のタスクは、MySQLデータベースがインストールされていて、実行中かつデータが移入されていて、MySQLデータベースに次の特性が備わっていることを前提にしています。
データベース名: sample_sql
データベースのURL: host2.example.com:3306/
JDBCドライバのURL: file:/net/host2.example/local/mysql/lib/jdbc.jar
ドライバ・クラス: com.mysql.jdbc.Driver
データベース・ユーザー: root
データベース・パスワード・ファイル: mysqlpwd.txt
次の表では、データベース内の表およびそのコンポジット・フィールドを説明します。JDBCデータ・ビューを設定するには、この情報が必要です。
| MySQL表 | フィールド |
|---|---|
|
|
|
|
|
|
|
|
|
SQLデータベース用にmysql1というJDBCデータソースを作成します。
% dpconf create-jdbc-data-source -b sample_sql \ -B jdbc:mysql://host2.example.com:3306/ \ -J file:/net/host2.example/local/mysql/lib/jdbc.jar \ -S com.mysql.jdbc.Driver mysql1
|
注意: num-connection-incr、num-connection-initおよびnum-connection-limitのJDBCデータソースのプロパティを使用して、JDBCデータソースの接続数を設定できます。 |
SQLデータベースのユーザー名およびパスワード・ファイルを指定します。
% dpconf set-jdbc-data-source-prop mysql1 db-pwd:sqlpwd db-user:rootUser
sqlpwdおよびrootUserは、認証ユーザーのパスワードおよびユーザー名で、これらの資格証明はデータベースに格納されています。JDBCデータソースを構成するとき、ユーザー名とパスワードを使用してプロキシ・サーバーを構成する必要があります。
DBベンダーによって提供されたドライバ以外のサード・パーティJDBCドライバを使用してRDBMSバックエンドに接続する場合、JDBCデータソースのdb-vendorプロパティは、set-jdbc-data-source-propを使用して設定する必要があります。このデータは、可能な場合には必ずベンダー固有のSQL文を構成するために使用され、パフォーマンスを向上させます。詳細は、db-vendorに関する説明を参照してください。
プロキシ・サーバーを再起動します。
% dpadm restart /local/dps
このデータソースを有効にし、データソースへの書込み操作を許可します。
% dpconf set-jdbc-data-source-prop mysql1 is-enabled:true is-read-only:false
開いている接続およびデータソースの監視を向上させるために、monitoring-inactivity-timeout、monitoring-intervalおよびmonitoring-modeを設定します。
詳細は、monitoring-inactivity-timeoutについての説明、monitoring-intervalについての説明およびmonitoring-modeについての説明を参照してください。
mysql1-poolというJDBCデータソース・プールを作成します。
% dpconf create-jdbc-data-source-pool mysql1-pool
JDBCデータソースをデータソース・プールにアタッチします。
% dpconf attach-jdbc-data-source mysql1-pool mysql1
データソース・プール用にmyjdbc1-viewというJDBCデータ・ビューを作成し、ベースDNをo=sqlにします。
% dpconf create-jdbc-data-view mysql1-view mysql1-pool o=sql
MySQLデータベース内の各表に対してJDBC表を作成します。
% dpconf create-jdbc-table employee1 EMPLOYEE % dpconf create-jdbc-table country1 COUNTRY % dpconf create-jdbc-table phone1 PHONE
SQLデータベース内の表の名前では、大文字と小文字が区別されます。大文字/小文字は、SQLデータベースで使用されているものと同じにしてください。
各表の各列にJDBC属性を作成します。
JDBC属性を作成すると、MySQL列がLDAP属性にマップされます。
% dpconf add-jdbc-attr employee1 uid ID % dpconf add-jdbc-attr employee1 sn SURNAME % dpconf add-jdbc-attr employee1 userPassword PASSWORD % dpconf add-jdbc-attr employee1 roomNumber ROOM % dpconf add-jdbc-attr phone1 telephoneNumber NUMBER % dpconf add-jdbc-attr country1 countryName NAME
phone1 user_id列とcountry1 id列にJDBC属性を作成する必要はありません。これは、これらの列には、EMPLOYEE.IDにある値のみが含まれており、このLDAP属性uidはすでに作成済であるためです。
LDAPpersonオブジェクト・クラスのJDBCオブジェクト・クラスを作成します。
この手順では、employee1表がプライマリ表として識別され、country1表とphone1表がセカンダリ表として識別されます。JDBCオブジェクト・クラスの作成には、DNも必要です。この例では、DNは、uid属性およびデータ・ビューのベースDNから構成されます。
% dpconf create-jdbc-object-class mysql1-view person employee1 country1 phone1 uid
プライマリ表とセカンダリ表の間の結合ルールを定義します。
結合ルールは、セカンダリ表で定義され、その表からのデータをプライマリ表からのデータとどのようにリンクするかが決定されます。
% dpconf set-jdbc-table-prop country1 filter-join-rule:ID=\${EMPLOYEE.COUNTRY_ID}
% dpconf set-jdbc-table-prop phone1 filter-join-rule:USER_ID=\${EMPLOYEE.ID}
JDBCオブジェクト・クラスのスーパー・クラスを指定します。
スーパー・クラスは、JDBCオブジェクト・クラスの属性の継承元のLDAPオブジェクト・クラスを示しています。
% dpconf set-jdbc-object-class-prop mysql1-view person super-class:top
JDBCデータ・ビューをテストするには、その前に、ACIを構成してデータ・ビューへの書込みアクセスを有効にする必要があります。デフォルトでは、非LDAPデータ・ビューへの書込みアクセスは拒否されます。この例の目的のためには、独自のパスワードの変更をユーザーに許可する1つのグローバルACIを追加するのみで十分です。
プロキシ・マネージャとして、ACIのプールをJDBCデータソースに追加し、独自のエントリの変更をユーザーに許可するグローバルACIを追加します。
% ldapmodify -p 1389 -D "cn=proxy manager" -w password dn: cn=mysql1,cn=virtual access controls changetype: add objectclass: acisource dpsaci: (targetattr="*") (target = "ldap:///o=sql") (version 3.0; acl "enable all access for all users "; allow(all) userdn="ldap:///uid=kvaughan,o=sql";) cn: mysql1
o=sqlドメインへの接続を処理する接続ハンドラを作成します。
% dpconf create-connection-handler mysql1-handler
接続ハンドラを有効にし、o=sqlドメインのユーザーからのすべてのバインドを処理するように構成します。
% dpconf set-connection-handler-prop mysql1-handler is-enabled:true \ bind-dn-filters:"uid=.*,o=sql"
前に追加したACIのプールを使用するように、接続ハンドラを構成します。
% dpconf set-connection-handler-prop mysql1-handler aci-source:mysql1
o=sqlの下のユーザーとして、JDBCデータソースを検索し、データ・ビューから読み取ることができることを確認します。
% ldapsearch -p 1389 -D "uid=kvaughan,o=sql" -w mypwd -b o=sql "objectclass=*"
|
注意:
|
o=sqlの下のユーザーとして、userPassword属性を変更し、データ・ビューに書き込むことができることを確認します。
% ldapmodify -p 1389 -D "uid=kvaughan,o=sql" -w mypwd dn: uid=kvaughan,o=sql changetype: modify replace: userPassword userPassword: myNewpwd
myjoin1-viewという結合データ・ビューを作成します。
LDAPデータ・ビューをプライマリ・データ・ビューに、JDBCデータ・ビューをセカンダリ・データ・ビューに指定します。
% dpconf create-join-data-view myjoin1-view myds1-view mysql1-view o=join
セカンダリ・データ・ビューの結合ルールを定義します。
次の結合ルールは、セカンダリ・データ・ビューのエントリのuid属性がプライマリ・データ・ビューのエントリのuid属性と一致する必要があることを指定します。
% dpconf set-jdbc-data-view-prop mysql1-view filter-join-rule:uid=\${myds1-view.uid}
フィルタ結合ルールが結合データ・ビューで設定されている場合、セカンダリ・データ・ビューの仮想変換ルールを設定し、結合データ・ビューのエントリを追加できるようにする必要があります。
dpconf add-virtual-transformation secondary-view-name \
write add-attr-value dn uid=\${uid}
|
注意: このルールを設定しないと、エントリを結合データ・ビューに追加できません。 |
結合データ・ビューを介してプライマリ・データ・ビューからの読取りおよびプライマリ・データ・ビューへの書込みが可能な属性のセットを定義します。
% dpconf set-ldap-data-view-prop myds1-view viewable-attr:dn \ viewable-attr:cn viewable-attr:sn viewable-attr:givenName \ viewable-attr:objectClass viewable-attr:ou viewable-attr:l \ viewable-attr:uid viewable-attr:mail viewable-attr:telephoneNumber \ viewable-attr:facsimileTelephoneNumber viewable-attr:roomNumber \ viewable-attr:userPassword % dpconf set-ldap-data-view-prop myds1-view writable-attr:dn \ writable-attr:cn writable-attr:sn writable-attr:givenName \ writable-attr:objectClass writable-attr:ou writable-attr:l \ writable-attr:uid writable-attr:mail writable-attr:telephoneNumber \ writable-attr:facsimileTelephoneNumber writable-attr:roomNumber \ writable-attr:userPassword
これらの定義は、結合ビューのコンテキストでのみ適用されます。デフォルトでは、すべての属性は、LDAPデータ・ビューに直接アクセスする場合には、読取りおよび書込みが可能です。
結合データ・ビューを介してセカンダリ・データ・ビューからの読取りおよびセカンダリ・データ・ビューへの書込みが可能な属性のセットを定義します。
% dpconf set-jdbc-data-view-prop mysql1-view viewable-attr:dn \ viewable-attr:objectclass viewable-attr:sn viewable-attr:roomNumber \ viewable-attr:userpassword viewable-attr:jobtitle viewable-attr:countryName \ viewable-attr:telephoneNumber % dpconf set-jdbc-data-view-prop mysql1-view writable-attr:dn \ writable-attr:objectclass writable-attr:sn writable-attr:roomNumber \ writable-attr:userpassword writable-attr:jobtitle \ writable-attr:countryName writable-attr:telephoneNumber
これらの定義は、結合ビューのコンテキストでのみ適用されます。デフォルトでは、すべての属性は、JDBCデータ・ビューに直接アクセスする場合には、読取りおよび書込みが可能です。
プロキシ・マネージャとして、結合データ・ビューへの匿名アクセスを許可するグローバルACIを追加します。
% ldapmodify -p 1389 -D "cn=proxy manager" -w password dn: cn=myjoin1,cn=virtual access controls changetype: add objectclass: acisource dpsaci: (targetattr="*") (target = "ldap:///o=join") (version 3.0; acl "anonymous_access"; allow(all) userdn="ldap:///anyone";) cn: myjoin1
前に追加したACIのプールを使用するように、接続ハンドラを構成します。
% dpconf set-connection-handler-prop default-connection-handler aci-source:myjoin1
この手順では、Kirsten Vaughanのエントリを検索し、両方の結合ビューからデータを取得できるかどうかを確認します。
% ldapsearch -p 1389 -b o=join "uid=kvaughan"
返されるエントリには、LDAPデータ・ビューとJDBCデータ・ビューの両方の属性が含まれていることに注意してください。
o=joinの下のユーザーとして、userPassword属性を変更し、結合データ・ビューに書き込むことができることを確認します。
% ldapmodify -p 1389 dn: uid=kvaughan,ou=people,o=join changetype: modify replace: userPassword userPassword: myPassword
この構成では、特定のディレクトリ・サービス要件が仮想ディレクトリの一部の機能によって満たされている組織Example.comについて説明します。
Example.comは、組織データを複数の異なるデータソースに格納します。旧来の理由によって、ユーザー・データは、LDAPディレクトリ、フラットLDIFファイルおよびSQLデータベースに拡散されます。HR部門は、ユーザー・データをLDAPディレクトリに格納し、ベースDNをo=example.comに設定します。給与部門は、データをSQLデータベースに格納します。部門やビルディング番号のような管理データは、管理部門によってLDIFファイルに格納されベースDNがdc=example,dc=comに設定されます。
また、Example.comは、Company22という会社を取得済です。Company 22も、そのユーザー・データをLDAPディレクトリに格納し、ベースDNをdc=company22,dc=comに設定します。
次の図は、Example.comのユーザー・データが格納される方法の概要レベルのビューを示しています。
Example.comには、異なるデータソースに格納されているデータにアクセスする必要がある、いくつかのLDAPクライアント・アプリケーションがあります。クライアント・アプリケーションの要件は、すべてが同じというわけではありません。データの異なるビューが必要です。クライアントは、データを集約する必要がある場合があります。また、一部のクライアント・アプリケーションは、Example.comのこれらの新しい従業員を古い従業員とともに管理できるように、Company22のユーザー・データにアクセスする必要があります。
次の図は、Example.comのクライアント・アプリケーションの要件の概要レベルのビューを示しています。
次の各項は、このサンプル・シナリオで説明したクライアント・アプリケーションの要件を満たすために十分なDirectory Proxy Serverのデータ・ビューの構成について説明します。データ・ビューの動作の詳細は、Oracle Directory Server Enterprise Editionリファレンス、第17章のDirectory Proxy Serverの配布に関する説明およびOracle Directory Server Enterprise Editionリファレンス、第18章のDirectory Proxy Serverの仮想化に関する説明を参照してください。
サンプル・シナリオの構成は、次の各項に分解されます。
HR部門は、従業員名、ジョブ開始データ、ジョブ・レベルなどの情報を格納します。管理部門は、ビルディング・コードやオフィス番号などの追加データを格納します。HRデータを処理するクライアント・アプリケーションは、両方のソースからの結合データにアクセスする必要があります。両方のデータソースには、各エントリに存在している共通の属性employeeNumberがあります。
次の図は、クライアント・アプリケーションの要件を示しています。
このアプリケーションの要件を満たすために、データ・ビューは、給与ディレクトリおよび管理LDIFファイルに対して作成されます。これら2つのデータ・ビューは結合され、集約データへのアクセスを提供します。この共通の属性を使用すると、Directory Proxy Serverで各ユーザーのデータを集約できます。
簡潔にするために、この項で使用されるコマンドは、次の情報を前提とします。
Directory Proxy Serverのインスタンスは、ローカル・ホスト上のデフォルトのLDAPポート(389)で実行されます。
Directory Proxy Serverのインスタンスは、/local/myDPSにあります。
プロキシ・マネージャのパスワードを含むファイルへのパスは、変数LDAP_ADMIN_PWFとして設定済です。
給与LDAPディレクトリは、payrollHostというホストのポート2389で実行されます。
管理データを格納するために使用されるLDIFファイルの名前はexample.ldifです。
各コマンドの完全な構文を取得するには、オプションを指定せずにコマンドを実行します。次に例を示します。
$ dpconf create-ldap-data-view Operands are missing Usage: dpconf create-ldap-data-view VIEW_NAME POOL_NAME SUFFIX_DN
給与ディレクトリに対してLDAPデータソースを作成します。
$ dpconf create-ldap-data-source payroll-directory payrollHost:2389
給与ディレクトリに対してLDAPデータソース・プールを作成します。
$ dpconf create-ldap-data-source-pool payroll-pool
給与データソースをデータソース・プールにアタッチします。
$ dpconf attach-ldap-data-source payroll-pool payroll-directory
アタッチされたデータソースの重みを構成します。
$ dpconf set-attached-ldap-data-source-prop -h payrollHost -p 2389 \ payroll-pool payroll-directory add-weight:2 \ bind-weight:2 compare-weight:2 delete-weight:2 \ modify-dn-weight:2 modify-weight:2 search-weight:2
給与ディレクトリに対してLDAPデータ・ビューを作成します。
$ dpconf create-ldap-data-view payroll-view payroll-pool o=example.com
クライアント・リクエストをこのデータ・ビューにルーティングできるように、LDAPデータ・ビューを有効にします。
$ dpconf set-ldap-data-view-prop payroll-view is-enabled:true
Directory Proxy Serverを再起動して、変更を有効にします。
$ dpadm restart /local/myDPS
管理データに対してLDIFデータ・ビューを作成します。
$ dpconf create-ldif-data-view admin-view example.ldif dc=example,dc=com
管理データに対してLDIFデータ・ビューを有効にします。
$ dpconf set-ldif-data-view-prop admin-view is-enabled:true
給与ビューの複数のエントリに使用されるエントリが管理ビューに含まれていることを指定します。
$ dpconf set-ldif-data-view-prop admin-view contains-shared-entries:true
このプロパティがTRUEに設定されている場合、給与データ・ビューのエントリを削除しても管理者データ・ビューの共有エントリは削除されません。給与データ・ビューにエントリを追加しても、エントリはセカンダリ・データ・ビューに追加されるのみです(これがまだ存在していない場合)。
Directory Proxy Serverを再起動して、変更を有効にします。
$ dpadm restart /local/myDPS
データの集約方法を指定する管理者データ・ビューのフィルタ結合ルールを作成します。
次の結合ルールは、ユーザー・エントリのemployeeNumber属性に基づいてデータを結合することを指定します。
$ dpconf set-ldif-data-view-prop admin-view \
filter-join-rule:employeeNumber=\${payroll-view.employeeNumber}
2つのデータ・ビューを集約する結合データ・ビューを作成します。
結合データ・ビューに対して、組織は、接尾辞DN dc=example,dc=comを使用します。
$ dpconf create-join-data-view example-join-view payroll-view admin-view \ dc=example,dc=com
Company 22のユーザー・データは、DN dc=company22,dc=comの下に格納されます。Example.comは、ほとんどの場合、このユーザー・データを別個に保持しますが、あるクライアント・アプリケーションでは、Company 22の従業員および残りのExample.comの従業員を管理する必要があります。このクライアント・アプリケーションでは、Company 22のユーザー・データがExample.comのデータのように見える必要があります。
次の図は、クライアント・アプリケーションの要件を示しています。
このアプリケーションの要件を満たすために、仮想DNがdc=example,dc=comであるデータ・ビューがCompany 22のディレクトリ用に作成されます。
簡潔にするために、この項で使用されるコマンドは、次の情報を前提とします。
Directory Proxy Serverのインスタンスは、ローカル・ホスト上のデフォルトのLDAPポート(389)で実行されます。
Directory Proxy Serverのインスタンスは、/local/myDPSにあります。
プロキシ・マネージャのパスワードを含むファイルへのパスは、変数LDAP_ADMIN_PWFとして設定済です。
Company 22LDAPディレクトリは、company22Hostというホストのポート2389で実行されます。
Company 22のディレクトリに対してLDAPデータソースを作成します。
$ dpconf create-ldap-data-source company22-directory company22Host:2389
Company 22のディレクトリに対してLDAPデータソース・プールを作成します。
$ dpconf create-ldap-data-source-pool company22-pool
Company 22のデータソースをデータソース・プールにアタッチします。
$ dpconf attach-ldap-data-source company22-pool company22-directory
アタッチされたデータソースの重みを構成します。
$ dpconf set-attached-ldap-data-source-prop -p 2389 \ company22-pool company22-directory add-weight:2 \ bind-weight:2 compare-weight:2 delete-weight:2 \ modify-dn-weight:2 modify-weight:2 search-weight:2
Company 22のディレクトリ用にLDAPデータ・ビューを作成し、仮想DNをdc=example,dc=comにします。
$ dpconf create-ldap-data-view company22-view company22-pool dc=example,dc=com
この仮想DNをCompany 22のディレクトリにある実際のDNにマップするようにDirectory Proxy Serverに指示します。
$ dpconf set-ldap-data-view-prop company22-view \ dn-mapping-source-base-dn:dc=company22,dc=com
クライアント・リクエストをこのデータ・ビューにルーティングできるように、Company 22のディレクトリに対してLDAPデータ・ビューを有効にします。
$ dpconf set-ldap-data-view-prop company22-view is-enabled:true
Directory Proxy Serverを再起動して、変更を有効にします。
$ dpadm restart /local/myDPS
HR部門には、Example.comのHRデータと新しく取得したCompany 22のHRデータの集約ビューが必要です。次の図は、グローバルHRアプリケーションの要件を示しています。
データの集約方法を指定するCompany 22データ・ビューのフィルタ結合ルールを作成します。
次の結合ルールは、ユーザー・エントリのemployeeNumber属性に基づいてデータを結合することを指定します。
$ dpconf set-ldif-data-view-prop company22-view \
filter-join-rule:employeeNumber=\${example-join-view.employeeNumber}
Company 22のデータ・ビューとExample.comの結合データ・ビューを集約する結合データ・ビューを作成します。
$ dpconf create-join-data-view global-join-view example-join-view \ company22-view dc=example,dc=com
Example.comの給与部門は、給与データをSQLデータベースに格納します。データベースには、employee表とsalary表の2つの表があります。Example.comには、そのデータにアクセスする必要があるLDAPクライアント・アプリケーションがあります。クライアント・アプリケーションでは、SQLデータがLDAPデータのように見える必要があります。
次の図は、クライアント・アプリケーションの要件を示しています。
このアプリケーションの要件を満たすために、SQL表の列をLDAP属性にマップするJDBCデータ・ビューが作成されます。
簡潔にするために、この項で使用されるコマンドは、次の情報を前提とします。
Directory Proxy Serverのインスタンスは、ローカル・ホスト上のデフォルトのLDAPポート(389)で実行されます。
Directory Proxy Serverのインスタンスは、/local/myDPSにあります。
プロキシ・マネージャのパスワードを含むファイルへのパスは、変数LDAP_ADMIN_PWFとして設定済です。
SQLデータベースが稼働中であること。
JAVA_HOME変数が正しいJavaパスに設定済であること。
SQLデータベースのパスワードがmyPasswordで、myPasswordFileファイルに格納されていること。
給与データベースのJDBCデータソースを作成します。
$ dpconf create-jdbc-data-source -b payrollsqldb \ -B jdbc:payrollsqldb:payrollsql://localhost/ \ -J file://payrollsqldb.jar \ -S org.payrollsqldb.jdbcDriver payroll-src
SQLデータベースのプロパティを使用してJDBCデータソースを構成します。
$ dpconf set-jdbc-data-source-prop payroll-src \
db-user:proxy db-pwd-file:password-file-location/myPasswordFile
JDBCデータソースを有効にします。
$ dpconf set-jdbc-data-source-prop payroll-src is-enabled:true
給与データベースのJDBCデータソース・プールを作成します。
$ dpconf create-jdbc-data-source-pool payroll-pool
給与データソースをデータソース・プールにアタッチします。
$ dpconf attach-jdbc-data-source payroll-pool payroll-src
給与データベース用にJDBCデータ・ビューを作成し、仮想DNをo=payrollにします。
$ dpconf create-jdbc-data-view payroll-view payroll-pool o=payroll
SQLデータベース内の各表に対してJDBC表を作成します。
$ dpconf create-jdbc-table jdbc-employee employee $ dpconf create-jdbc-table jdbc-salary salary
SQL表の各列にJDBC属性を追加します。
$ dpconf add-jdbc-attr jdbc-employee eid employee_id $ dpconf add-jdbc-attr jdbc-employee first firstname $ dpconf add-jdbc-attr jdbc-employee last lastname $ dpconf add-jdbc-attr jdbc-employee description description $ dpconf add-jdbc-attr jdbc-employee spouse spousename $ dpconf add-jdbc-attr jdbc-salary salary salary $ dpconf add-jdbc-attr jdbc-salary social ssn
JDBCデータ・ビューを使用して、表示できる属性および書込みが可能な属性を指定します。
$ dpconf set-jdbc-data-view-prop payroll-view \ viewable-attr:eid \ viewable-attr:first \ viewable-attr:last \ viewable-attr:desc \ viewable-attr:spouse \ viewable-attr:salary \ viewable-attr:social $ dpconf set-jdbc-data-view-prop payroll-view \ writable-attr:eid \ writable-attr:first \ writable-attr:last \ writable-attr:description \ writable-attr:spouse \ writable-attr:salary \ writable-attr:social
LDAPオブジェクト・クラスにマップするJDBCオブジェクト・クラスを作成します。
次のコマンドでは、LDAP personオブジェクト・クラスにマップするオブジェクト・クラスが作成されます。オブジェクト・クラスは、従業員表をプライマリ表として使用し、給与表をセカンダリ表として使用することを指定します。eid属性は、DNを構成するために使用する必要があります。
$ dpconf create-jdbc-object-class payroll-view \ person jdbc-employee jdbc-salary eid
セカンダリ表からのデータをプライマリ表からのデータとどのようにリンクするかを指定するセカンダリ表のフィルタ結合ルールを作成します。
次の結合ルールは、employee_id属性に基づいてデータを結合することを指定します。
$ dpconf set-jdbc-table-prop jdbc-salary \
filter-join-rule:employee_id=\${employee.employee_id}
JDBCオブジェクト・クラスのスーパー・クラスを作成します。
$ dpconf set-jdbc-object-class-prop payroll-view person super-class:extensibleObject
LDAPディレクトリのアクセス制御は、ディレクトリ自体にACIを定義することによって処理されます。データソースが仮想データ・ビューを介してアクセスされる場合、これらのデータ・ビューを介して表示されるデータに対してのみ適用されるACIを定義する必要があります。
Directory Proxy Serverを介する任意のアクセスは、接続ハンドラによって制御されます。接続ハンドラの詳細は、第25章「クライアントとDirectory Proxy Server間の接続」を参照してください。
ACIを追加します。
$ ldapadd -v -D "cn=proxy manager" -w password -p 389 dn: cn=ldifonly-acis,cn=virtual access controls objectclass: top objectclass: aciSource cn: ldifonly-acis dpsaci: (targetattr="*")(version 3.0; acl "anonymous_access"; allow(all) \ (userdn="ldap:///anyone");)
接続ハンドラが仮想ACIを指すようにします。
$ dpconf set-connection-handler-prop anonymous aci-source:ldifonly-acis
接続ハンドラを有効にします。
$ dpconf set-connection-handler-prop anonymous is-enabled:true
