Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド

第 23 章 Directory Proxy Server による仮想化

この章では、仮想データビューの作成方法を説明します。仮想データビューは、ソースデータを変換し、そのデータをクライアントアプリケーションに異なるビューで表示します。仮想データビューには、変換された LDAP データビュー、LDIF データビュー、結合データビュー、および JDBC ^TMデータビューが含まれます。仮想データビューの機能の概要とユースケースの例の説明については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の第 18 章「Directory Proxy Server Virtualization」を参照してください。

Directory Service Control Center (DSCC) を使用してこの章の手順を実行することはできません。コマンド行を使用する必要があります。

この章の内容は次のとおりです。

LDIF データビューの作成と設定

LDIF データビューは、LDIF ファイルを LDAP データソースのように見せかける、単純な仮想データビューです。LDAP データビューとは異なり、LDIF データビューを設定する場合にデータソースやデータソースプールは作成しません。代わりに、データビューを作成する場合に 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
デフォルトで設定されている LDIF データビューは、virtual access controls データビューのみです。このデータビューは、サーバーによって生成され、要求を仮想アクセス制御命令 (ACI) に経路指定できるようにします。

LDIF データビューを設定する

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

LDIF データビューのプロパティーを表示します。

$ dpconf get-ldif-data-view-prop -h host -p port view-name

LDIF データビューには、次のデフォルトプロパティーがあります。

alternate-search-base-dn                    :  ""
alternate-search-base-dn                    :  dc=com
attr-name-mappings                          :  none
base-dn                                     :  suffixDN
bind-pwd-attr                               :  userPassword
contains-shared-entries                     :  -
db-pwd-encryption                           :  clear-text
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
ldif-data-source                            :  /path/to/filename.ldif
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

手順 1で一覧表示されるプロパティーの 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

仮想データ変換の設定

仮想データ変換は、既存のデータビュー上で定義され、物理データビューから仮想データビューを作成します。機能方法については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の「Virtual Data Transformations」を参照してください。

仮想データ変換は次のどの種類のデータビューにも追加できます。LDAP データビュー、LDIF データビュー、結合データビュー、または JDBC データビュー。

仮想変換を追加する

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

変換をデータビューに追加します。
$ dpconf add-virtual-transformation -h host -p port view-name \ transformation-model transformation-action attribute-name [parameters...]
transformation-model と transformation-action によっては、parameters は必須である場合があります。変換のモデル、変換アクション、変換パラメータについては、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の「Virtual Data Transformations」を参照してください。

(省略可能) データビューで定義された仮想変換の一覧を表示します。
```
$ dpconf list-virtual-transformations -h host -p port view-name
```

結合データビューの作成と設定

結合データビューは複数のデータビューを 1 つにまとめたものです。結合データビューの機能方法については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の「Join Data Views」を参照してください。

結合データビューの作成と設定の方法については、次の手順を参照してください。

結合データビューを作成する

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

結合データビューのデフォルトプロパティーは次のとおりです。

alternate-search-base-dn                    :  ""
alternate-search-base-dn                    :  dc=com
attr-name-mappings                          :  none
base-dn                                     :  suffixDN
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
join-rule-control-enabled                   :  false
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
primary-view                                :  primary-view
process-bind                                :  -
replication-role                            :  master
secondary-view                              :  secondary-view
viewable-attr                               :  all except non-viewable-attr
writable-attr                               :  all except non-writable-attr

手順 1で一覧表示されるプロパティーの 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

結合データビューを設定する場合は、一次データビューと二次データビューで viewable-attr および writable-attr プロパティーを設定します。

これらのプロパティーを設定すると、一次データビューと二次データビューで検索フィルタを適切に分割できます。これらのプロパティーを設定しなければ、二次データビューからの属性が検索フィルタに含まれている場合、検索結果に矛盾が生じる可能性があります。

必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。

Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。

複数の結合データビューが 1 つのデータビューを参照できるよう結合データビューを設定する

結合データビューで結合ルール設定情報を設定することにより、そのデータビューが複数の結合データビューから参照されるようにします。これを行うには、次の手順を実行します。

結合データビューで 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}

結合ビューの二次ビューを設定する

特定のプロパティーを二次データビュー上で設定し、結合ビューのソースとして機能できるようにします。二次ビューはどんな種類のデータビューでも構わないため、使用するコマンドは、データビューの種類によって異なります。次のサンプルコマンドは、二次ビューが LDAP データビューであることを前提としています。ここで説明するプロパティーの詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の「Additional Secondary Data View Properties」を参照してください。

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

二次ビューが一次ビューに関連付けられる方法を決定する結合ルールを定義します。

次のどちらかの結合ルールを使用できます。
- 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
このプロパティーの詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の「Handling of Binds」を参照してください。

(省略可能) 二次データビューに共有エントリが含まれるかどうかを指定します。
$ dpconf set-ldap-data-view-prop -h host -p port secondary-view-name \ contains-shared-entries:true
このプロパティーの詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の「Handling of Shared Entries」を参照してください。

JDBC データビューの作成と設定

JDBC データビューを使用すると、LDAP クライアントアプリケーションがリレーショナルデータベースにアクセスできるようになります。JDBC データビューの機能方法については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の「JDBC Data Views」を参照してください。

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
現在、各 JDBC データビューでサポートされる JDBC データソースは 1 つだけです。つまり、JDBC データソースで負荷分散することはできません。複数の JDBC データソースにアクセスするには、各データソース用にデータビューを作成し、それらをすべて結合データビューに結合します。

JDBC データソースを作成する場合は、次のプロパティーを設定します。

db-name

リレーショナルデータベースの名前。たとえば、payrolldb などです。

db-url

データベースへの URL。形式は、jdbc: vendor:driver://dbhost: dbport です。

db-url には、データベース名が含まれていないため、JDBC データベース URL としては完全ではありません。(データベース名は、db-name プロパティーで指定されます。)

db-url の末尾には、MySQL、DB2、および Derby データベースの場合は /、Oracle データベースの場合は : を付けてください。

driver-class

JDBC ドライバクラス。たとえば、org.hsqldb.jdbcDriver などです。

driver-url

JDBC ドライバへのパス。たとえば、file:/// path/to/hsqldb/lib/hsqldb.jar などです。

driver-url プロパティーは複数値プロパティーです。そのため、driver-url で JDBC ドライバ用の複数の JAR ファイルを設定することにより、各種のプラットフォームで JDBC ソースに接続できます。

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

JDBC データビューを設定する

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-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

手順 1で一覧表示されるプロパティーの 1 つまたは複数を変更します。

$ dpconf set-jdbc-data-view-prop -h host -p port view-name property:value \
 [property:value ... ]

JDBC テーブル、属性、オブジェクトクラスを設定する

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-syntax をデフォルト値の cis に設定します。ldap-syntax:ces は、大文字と小文字を区別しないデータベースではサポートされません。

LDAP リレーショナルデータベーステーブルの JDBC オブジェクトクラスを作成します。
% dpconf create-jdbc-object-class view-name objectclass primary-table \ [secondary-table... ] DN-pattern
JDBC オブジェクトクラスを作成すると、原則的にこれらのテーブルが関連付けられる LDAP オブジェクトクラスが指定されます。JDBC オブジェクトクラスは、一次テーブルと二次テーブルが存在する場合、これらも指定します。

JDBC オブジェクトクラスを作成する場合、DN パターンを指定します。DN パターンは、エントリの 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 テーブル間の関係の定義

もっとも単純な場合、JDBC オブジェクトクラスにはテーブルが 1 つ (一次) しか含まれません。二次テーブルはなく、このため、テーブル間の関係を定義する必要はありません。

オブジェクトクラスに複数のテーブルが含まれる場合、これらのテーブル間の関係を明確に定義します。テーブル間の関係は、常に二次テーブル上で定義されます。二次テーブルの次のプロパティーによって、これらの関係を定義できます。

is-single-row-table は、テーブルで LDAP エントリに一致する行が 1 つだけであると指定します。
contains-shared-entries は、二次テーブルの行が一次テーブルの複数の行に使用されることを指定します。
filter-join-rule は、エントリが一次テーブルに基づいて二次テーブルから取得される方法を示します。

次の例は、最初の 2 つのプロパティーの値に基づいて、フィルタ結合ルールがどのように定義されるかを示しています。以降の例では、オブジェクトクラスに一次テーブルと二次テーブルが 1 つずつあることを前提としています。

例 23–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}"

この設定の場合、LDAP 操作で次の動作が行われます。

従業員エントリの追加。従業員エントリのマネージャーがテーブルに存在しない場合、新しい行が作成されます。マネージャーが存在する場合は、既存の行が使用されます。
エントリ内の「manager」属性の値の置き換え。MANAGER.NAME 行の値が変更されます。
従業員エントリの削除。マネージャーエントリが共有されているため、二次テーブルの行は削除されません。
エントリから「manager」属性の削除。二次テーブルの行が削除され、外部キー (EMPLOYEE.FK_MANAGER_ID) が NULL に設定されます。

例 23–2 `is-single-row-table:true` と `contains-shared-entries:false`

この場合、一次テーブルと二次テーブルの関係は、1->1 または 1<-1 です。つまり、一次テーブルの 1 行が二次テーブルの 1 行で参照されます。

リレーショナルデータベースで、外部キー (FK) が一次テーブルまたは二次テーブルで定義されることがあります。

たとえば、従業員の UID が 1 つのテーブルに保存され、従業員の姓が二次テーブルに保存されている組織の場合を考えてみます。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}"

別の方法として、二次テーブルに保存されている外部キー FK_UID_ID を UID.ID にポイントさせることでも同等の設定が可能です。

例 23–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}"

例 23–4 `is-single-row-table:false` と `contains-shared-entries:true`

これは、現在 Directory Proxy Server でサポートされていません。

仮想データビューでのアクセス制御の定義

仮想データビューの ACI は、LDAP ディレクトリまたは LDIF ファイルに保存できます。仮想 ACI の機能方法については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の「Access Control On Virtual Data Views」を参照してください。

Directory Proxy Server インスタンスを作成すると、仮想アクセス制御の次のデフォルト設定が定義されます。

ACI がデフォルトで保存される LDIF ファイル ( instance-path/config/access_controls.ldif)
virtual access controls という名前の LDIF データビュー

このデータビューは、Directory Proxy Server が LDIF ファイルに保存された ACI にアクセスできるようにします。

新しい ACI ストレージリポジトリを定義する

前述のデフォルト ACI 設定を使用しない場合は、別のストレージリポジトリを定義できます。

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

仮想 ACI が保存されるリポジトリのデータビューを作成します。
- ACI が 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 ディレクトリの場合、aciSource オブジェクトクラスと dpsaci 属性が含まれるようにそのディレクトリのスキーマを変更します。スキーマのカスタマイズの詳細については、「Directory Server スキーマの拡張」を参照してください。

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

ACI リポジトリに ACI のプールを作成し、グローバル ACI を設定します。

グローバル ACI の詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の「Global ACIs」を参照してください。グローバル ACI を設定するには、ACI データビューのビューベースの下に aciSource エントリを追加します。次に例を示します。

% ldapmodify -p port -D "cn=proxy manager" -w -
dn: cn=data-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: data-source-name

この ACI のプールを使用するよう 1 つまたは複数の接続ハンドラを設定します。

% dpconf set-connection-handler-prop -h host -p port connection-handler \
aci-source:data-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 ディレクトリで定義される場合、「LDAP データビューの作成と設定」での説明に従って、ビューベースを cn=schema にして LDAP データビューを作成します。

外部スキーマが LDIF ファイルで定義される場合、「LDIF データビューの作成と設定」での説明に従って、ビューベースを cn=schema にして LDIF データビューを作成します。

接続ハンドラによって公開されるデータビューの一覧にこのデータビューを追加します。

デフォルトで、データビューはすべて接続ハンドラによって公開されます。接続ハンドラによって公開されたデータビューのカスタムリストを定義している場合、このデータビューをリストに追加します。
$ dpconf set-connection-handler-prop -h host -p port connection-handler \ data-view-routing-custom-list+:data-view-name

仮想設定の例

次の節では、2 つの設定例について説明します。これらの設定は、仮想ディレクトリの主な機能と、これらの機能の設定方法を示しています。

LDAP ディレクトリと MySQL データベースの結合

ここでの手順は、LDAP ディレクトリと MySQL データベースを結合する仮想設定の例について説明しています。LDAP ディレクトリは、一次データソースとして、ユーザー情報のほとんどが含まれています。mySQL データベースには、ユーザーについての追加情報が含まれています。結果として得られる設定を次の図に示します。

図 23–1 仮想設定の例

図は、LDAP データビューおよび JDBC データビューから成る結合データビューを示しています。

install-path /ds6/ldif/Example.ldif のサンプルデータを使用して、この例を複製したり、サンプルデータを独自のデータに置き換えられます。

この設定は、3 つの部分に分割できます。

LDAP データビューの設定とテスト
JDBC データビューの設定とテスト
結合データビューの設定とテスト

わかりやすいように、ここでのコマンドはすべて Directory Proxy Server が /local/dps のローカルホストで実行されていることを前提としています。コマンドは、次の環境変数が設定されていることも前提としています。

DIR_PROXY_PORT: 1389
LDAP_ADMIN_PWF: pwd.txt、管理者パスワードを含むファイル
DIRSERV_PORT: 4389
LDAP_ADMIN_USER: cn=Directory Manager

LDAP データビューの設定とテスト

LDAP データビューを設定する

始める前に

ここでの作業は次の情報を前提としています。

Directory Server インスタンスが host1 上のポート 4389 で実行されている。
Directory Server のデータがサフィックス dc=example,dc=com の下に保存されている。この例と同じ環境を構築するには、Directory Server インスタンスとサフィックス dc=example,dc=com を作成し、install-path/ds6/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

ベース DN が dc=example,dc=com で myds1–view という名前のデータソースプールの LDAP データビューを作成します。
% dpconf create-ldap-data-view myds1-view myds1-pool dc=example,dc=com

LDAP データビューをテストする

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 のユーザーの資格を使用します。cn=Directory Manager を使用する場合は、この DN を処理するようにデータビューを定義する必要があります。

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 はユーザーが自分自身のパスワードを変更することを許可しています。

JDBC データビューの設定とテスト

次の作業は、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 テーブル	フィールド
`EMPLOYEE`	`ID`、`SURNAME`、`PASSWORD`、 `TITLE`、`COUNTRY_ID`
`COUNTRY`	`ID`、`NAME`
`PHONE`	`USER_ID`、`NUMBER`

JDBC データビューを設定する

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

SQL データベースのユーザー名とパスワードファイルを指定します。
% dpconf set-jdbc-data-source-prop mysql1 db-pwd-file:sqlpwd.txt db-user:root

プロキシサーバーを再起動します。
% dpadm restart /local/dps

データソースを有効にして、データソースへの書き込み操作を許可します。
% dpconf set-jdbc-data-source-prop mysql1 is-enabled:true is-read-only:false

mysql1–pool という名前の JDBC データソースプールを作成します。
% dpconf create-jdbc-data-source-pool mysql1-pool

JDBC データソースをデータソースプールに接続します。
% dpconf attach-jdbc-data-source mysql1-pool mysql1

ベース DN が o=sql で myjdbc1–view という名前のデータソースプールの JDBC データビューを作成します。
% 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 room ROOM
% dpconf add-jdbc-attr phone1 tel NUMBER
% dpconf add-jdbc-attr country1 country NAME

phone1 user_id 列と country1 id 列は MySQL データベースのコンテキストでのみ使用されるため、これらの列の JDBC 属性を必ずしも作成する必要はありません。これらには、対応する LDAP 属性がありません。

LDAP person オブジェクトクラスに対して 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

必要な ACI を作成する

JDBC データビューをテストする前に、ACI を設定してデータビューへの書き込みアクセスを有効にします。デフォルトで、LDAP データビュー以外への書き込みアクセスは拒否されます。この例では、ユーザーに自分のパスワードの変更を許可するグローバル ACI を 1 つ追加するだけで十分です。

プロキシマネージャーとして、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

JDBC データビューをテストする

o=sql のユーザーとして JDBC データソースを検索し、データビューから読み取りができることを確認します。
% ldapsearch -p 1389 -D "uid=kvaughan,o=sql" -w mypwd -b o=sql "objectclass=*"
注 –
o=sql のユーザーまたは匿名バインドの資格を使用します。

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:room viewable-attr:userpassword viewable-attr:jobtitle \
 viewable-attr:country viewable-attr:tel
% dpconf set-jdbc-data-view-prop mysql1-view writable-attr:dn writable-attr:objectclass \
 writable-attr:sn writable-attr:room writable-attr:userpassword writable-attr:jobtitle \
 writable-attr:country writable-attr:tel

これらの定義は、結合ビューのコンテキストにのみ適用されます。JDBC データビューに直接アクセスした場合、デフォルトでは、すべての属性が読み書きできます。

必要な ACI を作成する

プロキシマネージャーとして、結合データビューへの匿名アクセスを許可するグローバル 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

o=join ドメインへの接続を処理するために接続ハンドラを作成します。
% dpconf create-connection-handler myjoin1-handler

接続ハンドラを有効にして、o=join のユーザーからのバインドをすべて処理するように設定します。
% dpconf set-connection-handler-prop myjoin1-handler is-enabled:true \ bind-dn-filters:"uid=.*,ou=people,o=join"

前の手順で追加した ACI のプールを使用するように接続ハンドラを設定します。
% dpconf set-connection-handler-prop myjoin1-handler aci-source:myjoin1

結合データビューをテストする

匿名ユーザーとして、結合データビューを検索します。

ここでは、Kirsten Vaughan のエントリを検索し、両方の結合ビューからのデータが取得されるかどうかを確認します。
% ldapsearch -p 1389 -b o=join "uid=kvaughan"
返されるエントリには、LDAP データビューと JDBC データビューの両方からの属性が含まれていることに注意してください。

o=join のユーザーとして、userPassword 属性を変更して、結合データビューに書き込みができることを確認します。

% ldapmodify -p 1389 -D "uid=kvaughan,ou=people,o=join" -w myNewPassword
dn: uid=kvaughan,ou=people,o=join
changetype: modify
replace: userPassword
userPassword: myPassword

複数の異種データソースの結合

この設定は、仮想ディレクトリの機能のいくつかが特定のディレクトリサービス要件を満たしている Example.com という組織で説明します。

データストレージシナリオ

Example.com は複数の異種データソースに組織データを保存しています。過去の経緯により、ユーザーデータは LDAP ディレクトリ、フラット LDIF ファイル、SQL データベースに分散されています。HR 部門は o=example.com のベース DN でユーザーデータを LDAP ディレクトリに保存しています。給与部門はデータを SQL データベースに保存しています。部門やビルの番号などの管理データはdc=example,dc=com のベース DN で管理部門の LDIF ファイルに保存されています。

さらに、Example.com は Company22 という名前の企業を買収しました。Company 22 もユーザーデータを dc=company22,dc=com のベース DN で LDAP ディレクトリに保存しています。

次の図は、Example.com のユーザーデータがどのように保存されているかをまとめたものです。

図 23–2 異種ソースのデータストレージ

図は、Example.com のユーザーデータがどのように異種のデータソースに保存されているかを示しています。

クライアントアプリケーション要件

Example.com には、異種データソースに保存されたデータにアクセスする必要のある LDAP クライアントアプリケーションがいくつかあります。クライアントアプリケーションの要件はすべて同じではありません。異なるデータビューは必要です。場合によっては、クライアントはデータを集約する必要があります。さらに、Example.com の新しい従業員を以前からの従業員とともに管理できるように、一部のクライアントアプリケーションは Company22 のユーザーデータにアクセスする必要があります。

次の図は、Example.com のクライアントアプリケーション要件をまとめたものです。

図 23–3 クライアントアプリケーション要件

図は、Example.com の LDAP アプリケーションの要件を示しています。

次の節では、Directory Proxy Server データビューがこのサンプルシナリオで説明したクライアントアプリケーション要件を十分満たすことができる設定について見ていきます。データビューの機能方法については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の第 17 章「Directory Proxy Server Distribution」および『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の第 18 章「Directory Proxy Server Virtualization」を参照してください。

サンプルシナリオの設定は次のセクションで構成されています。

HR LDAP ディレクトリと管理 LDIF ファイルのデータの集約

HR 部門は従業員名、職務開始データ、職務レベルなどの情報を保存しています。管理部門は、建築基準法や会社の電話番号などの追加データを保存しています。HR データを処理するクライアントアプリケーションは、両方のソースからの複合データにアクセスする必要があります。各エントリ内の属性 employeeNumber は両方のデータソースに共通です。

次の図は、クライアントアプリケーションの要件を示しています。

図 23–4 LDAP ディレクトリと LDIF ファイルのデータの集約

このアプリケーション要件を満たすために、給与ディレクトリと管理 LDIF ファイル用にデータビューが作成されます。これらの 2 つのデータビューは、その後、集約されたデータにアクセスできるよう結合されます。この共通属性によって、Directory Proxy Server は各ユーザーのデータを集約できます。

わかりやすいように、ここで使用するコマンドは次の情報を前提としています。

Directory Proxy Server インスタンスはローカルホスト上のデフォルト LDAP ポート (389) で実行されている。
Directory Proxy Server インスタンスは、/local/myDPS にある。
プロキシマネージャーのパスワードを含むファイルへのパスは、変数 LDAP_ADMIN_PWF として設定されている。Directory Proxy Server 環境変数の設定の詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 Installation Guide』の「Environment Variables」を参照してください。
給与 LDAP ディレクトリは payrollHost という名前のホストのポート 2389 で実行されている。
管理データを保存している LDIF ファイルの名前は、 example.ldif である。

各コマンドの完全な構文を取得するために、オプションを使用せずにコマンドを実行します。次に例を示します。

$ dpconf create-ldap-data-view
Operands are missing
Usage: dpcfg create-ldap-data-view VIEW_NAME POOL_NAME SUFFIX_DN

給与ディレクトリの LDAP データビューの作成と有効化

給与ディレクトリの 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 データビューの作成と有効化

管理データの 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
```

DN の名前を変更して Company 22 からのデータを Example.Com の DIT に追加

Company 22 のユーザーデータは、DN dc=company22,dc=com で保存されています。Example.com はこのユーザーデータをほとんどの場合に区別しておきたいと考えていますが、あるクライアントアプリケーションは Company 22 の従業員を Example.com の残りの従業員とともに管理する必要があります。このクライアントアプリケーションは Company 22 のユーザーデータが Example.com のデータのように見えることを必要としています。

次の図は、クライアントアプリケーションの要件を示しています。

図 23–5 DN の名前の変更

このアプリケーション要件を満たすために、仮想 DN の dc=example,dc=com のデータビューが Company 22 ディレクトリに対して作成されます。

わかりやすいように、ここで使用するコマンドは次の情報を前提としています。

Directory Proxy Server インスタンスはローカルホスト上のデフォルト LDAP ポート (389) で実行されている。
Directory Proxy Server インスタンスは、/local/myDPS にある。
プロキシマネージャーのパスワードを含むファイルへのパスは、変数 LDAP_ADMIN_PWF として設定されている。Directory Proxy Server 環境変数の設定の詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 Installation Guide』の「Environment Variables」を参照してください。
Company 22 LDAP ディレクトリは company22Host という名前のホストのポート 2389 で実行されている。

仮想 DN を持つ Company 22 のディレクトリに対するデータビューの作成

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 -h company22Host -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

仮想 DN の dc=example,dc=com で Company 22 のディレクトリの LDAP データビューを作成します。
```
$ 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
```

Company 22 のデータの HR データへの追加

HR 部門は Example.com と新しく買収した Company 22 の HR データの集約されたビューを必要としています。次の図は、グローバル HR アプリケーションの要件を示しています。

図 23–6 結合データビューと LDAP データビューからのデータの集結

図は、LDAP ディレクトリとほかの結合ビューの複合的な結合ビューを示しています。

結合データビューの例と Company 22 データビューの結合

データの集約方法を指定するフィルタ結合ルールを 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
```

LDAP クライアントによる SQL データベース内の給与データへのアクセスの有効化

Example.com の給与部門は給与データを SQL データベースに保存しています。データベースには、employee テーブルと salary テーブルの 2 つのテーブルがあります。Example.com には、このデータへのアクセスを必要とする LDAP クライアントアプリケーションがあります。クライアントアプリケーションは SQL データが LDAP データのように見えることを必要としています。

次の図は、クライアントアプリケーションの要件を示しています。

図 23–7 SQL データベースへのアクセスを提供する JDBC データビュー

図は、SQL データベースへのアクセスを提供する JDBC データビューを示しています。

このアプリケーション要件を満たすために、SQL テーブル内の列を LDAP 属性にマップする JDBC データビューが作成されます。

わかりやすいように、ここで使用するコマンドは次の情報を前提としています。

Directory Proxy Server インスタンスはローカルホスト上のデフォルト LDAP ポート (389) で実行されている。
Directory Proxy Server インスタンスは、/local/myDPS にある。
プロキシマネージャーのパスワードを含むファイルへのパスは、変数 LDAP_ADMIN_PWF として設定されている。Directory Proxy Server 環境変数の設定の詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 Installation Guide』の「Environment Variables」を参照してください。
SQL データベースが起動して実行中である。
JAVA_HOME 変数が正しい Java パスに設定されている。
SQL データベースへのパスワードは、myPasswordFile ファイルに格納された myPassword である。

Example.com の給与データベースに対する JDBC データビューの作成

給与データベース用の 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
```

仮想 DN の o=payroll で給与データベースの JDBC データビューを作成します。
```
$ 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 を構築するために使用されます。
```
$ dpcfg 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 オブジェクトクラス上のスーパークラスを作成します。
```
$ set-jdbc-object-class-prop payroll-view person super-class:extensibleObject
```

仮想アクセス制御の追加

LDAP ディレクトリ上のアクセス制御は、ディレクトリ自体で ACI を定義することで処理されます。仮想データビューによってデータソースにアクセスされる場合、これらのデータビューで表示されるデータのみに適用される ACI を定義する必要があります。

Directory Proxy Server を経由するアクセスはすべて、接続ハンドラによって制御されます。接続ハンドラについては、第 25 章「クライアントと Directory Proxy Server の接続」を参照してください。

匿名アクセスを許可する ACI の追加

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

第 23 章 Directory Proxy Server による仮想化

LDIF データビューの作成と設定

LDIF データビューを作成する

LDIF データビューを設定する

仮想データ変換の設定

仮想変換を追加する

結合データビューの作成と設定

結合データビューを作成する

結合データビューを設定する

複数の結合データビューが 1 つのデータビューを参照できるよう結合データビューを設定する

結合ビューの二次ビューを設定する

JDBC データビューの作成と設定

JDBC データビューを作成する

JDBC データビューを設定する

JDBC テーブル、属性、オブジェクトクラスを設定する

JDBC テーブル間の関係の定義

例 23–1 is-single-row-table:true と contains-shared-entries:true

例 23–2 is-single-row-table:true と contains-shared-entries:false

例 23–3 is-single-row-table:false と contains-shared-entries:false

例 23–4 is-single-row-table:false と contains-shared-entries:true

仮想データビューでのアクセス制御の定義

新しい ACI ストレージリポジトリを定義する

仮想アクセス制御を設定する

仮想データビューでのスキーマチェックの定義

スキーマチェックを定義する

仮想設定の例

LDAP ディレクトリと MySQL データベースの結合

図 23–1 仮想設定の例

LDAP データビューの設定とテスト

LDAP データビューを設定する

始める前に

LDAP データビューをテストする

JDBC データビューの設定とテスト

JDBC データビューを設定する

必要な ACI を作成する

JDBC データビューをテストする

結合データビューの作成とテスト

結合データビューを作成する

必要な ACI を作成する

結合データビューをテストする

複数の異種データソースの結合

データストレージシナリオ

図 23–2 異種ソースのデータストレージ

クライアントアプリケーション要件

図 23–3 クライアントアプリケーション要件

HR LDAP ディレクトリと管理 LDIF ファイルのデータの集約

図 23–4 LDAP ディレクトリと LDIF ファイルのデータの集約

給与ディレクトリの LDAP データビューの作成と有効化

管理データの LDIF データビューの作成と有効化

給与データビューと管理データビューの結合

DN の名前を変更して Company 22 からのデータを Example.Com の DIT に追加

図 23–5 DN の名前の変更

仮想 DN を持つ Company 22 のディレクトリに対するデータビューの作成

Company 22 のデータの HR データへの追加

図 23–6 結合データビューと LDAP データビューからのデータの集結

結合データビューの例と Company 22 データビューの結合

LDAP クライアントによる SQL データベース内の給与データへのアクセスの有効化

図 23–7 SQL データベースへのアクセスを提供する JDBC データビュー

Example.com の給与データベースに対する JDBC データビューの作成

仮想アクセス制御の追加

匿名アクセスを許可する ACI の追加

例 23–1 `is-single-row-table:true` と `contains-shared-entries:true`

例 23–2 `is-single-row-table:true` と `contains-shared-entries:false`

例 23–3 `is-single-row-table:false` と `contains-shared-entries:false`

例 23–4 `is-single-row-table:false` と `contains-shared-entries:true`