test

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

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

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

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

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

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

LDIF データビューは、LDIF ファイルを LDAP データソースのように見せかける、単純な仮想データビューです。LDAP データビューとは異なり、LDIF データビューを設定する場合にデータソースやデータソースプールは作成しません。代わりに、データビューを作成する場合に LDIF ファイルを指定します。デフォルトで、LDIF データビューに書き込むことはできません。詳細については、「仮想データビューでのアクセス制御の定義」を参照してください。

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

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

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

  1. LDIF データビューを作成します。


    $ dpconf create-ldif-data-view -h host -p port view-name path-to-ldif-file suffix-dn

  2. (省略可能) LDIF データビューの一覧を表示します。


    $ dpconf list-ldif-data-views -h host -p port

    デフォルトで設定されている LDIF データビューは、virtual access controls データビューのみです。このデータビューは、サーバーによって生成され、要求を仮想アクセス制御命令 (ACI) に経路指定できるようにします。

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

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

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

  2. 手順 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

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

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

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

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

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

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

  1. 仮想 ACI が保存されるリポジトリのデータビューを作成します。

  2. 前の手順で作成したデータビューに ACI データビューとして名前を指定します。

    $ dpconf set-virtual-aci-prop -h host -p port aci-data-view:data-view-name

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

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

使用する ACI リポジトリに関係なく、仮想アクセス制御を設定する必要があります。

注 –

ACI のプールを作成し、ACI データビューによって直接 ACI を管理できるのはプロキシマネージャーだけです。ACI リポジトリが LDAP ディレクトリの場合、aciSource オブジェクトクラスと dpsaci 属性が含まれるようにそのディレクトリのスキーマを変更します。スキーマのカスタマイズの詳細については、「Directory Server スキーマの拡張」を参照してください。

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

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

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


    % 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: data-source-name

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


    % dpconf set-connection-handler-prop -h host -p port connection-handler \
aci-source:aci-source-name

  3. 必要な 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 プロパティーを次のように設定します。

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

  1. サーバーインスタンスが外部スキーマを使用するように設定します。


    $ dpconf set-server-prop -h host -p port use-external-schema:true

  2. 接続ハンドラでスキーマチェックを有効にします。


    $ dpconf set-connection-handler-prop -h host -p port connection-handler \
 schema-check-enabled:true

  3. cn=schema を公開するデータビューを作成します。

    外部スキーマが LDAP ディレクトリで定義される場合、第 19 章「LDAP データビュー」での説明に従って、ビューベースを cn=schema にして LDAP データビューを作成します。

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

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

    デフォルトで、データビューはすべて接続ハンドラによって公開されます。接続ハンドラによって公開されたデータビューのカスタムリストを定義している場合、このデータビューをリストに追加します。


    $ dpconf set-connection-handler-prop -h host -p port connection-handler \
 data-view-routing-custom-list+:data-view-name

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

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

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

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

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

  1. 結合ビューを形成するためにまとめる一次データビューと二次データビューを特定します。

    結合ビューを作成する前に、一次データビューと二次データビューを準備しておきます。一次ビューと二次ビューは、LDAP データビュー、LDIF データビュー、JDBC データビュー、またはその他の結合データビューを含むどんな種類のデータビューでも構いません。特定のプロパティーを二次ビュー上で設定し、結合ビューのソースとして機能できるようにします。詳細については、「結合ビューの二次ビューを設定する」を参照してください。

  2. 結合データビューを作成します。


    $ dpconf create-join-data-view -h host -p port view-name primary-view secondary-view \
 suffix-dn

  3. (省略可能) データビューが正常に作成されたことを確認するために、結合ビューの一覧を表示します。


    $ dpconf list-join-data-views -h host -p port

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

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

  1. 結合データビューのプロパティーを表示します。


    $ 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

  2. 手順 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

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

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

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

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

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

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

  1. 結合データビューで join-rule-control-enabled を true に設定します。


    $ dpconf set-join-data-view-prop view-name join-rule-control-enabled:true

    join-rule-control-enabled を true に設定すると、その結合データビューに格納された結合ルール設定情報がサーバーで使用されます。ある結合データビューに対して、結合ルール設定情報が二次データビューに格納されている場合、この情報はサーバーで使用されません。この情報をサーバーに使用させるには、結合データビューレベルで設定情報を手動で追加してください。

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

    次のどちらかの結合ルールを使用できます。

    • 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 の場合、エスケープは必要ありません。

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

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

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

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

    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 に設定されていると、二次ビューで設定された情報は無視されます。

  2. 結合データビューでフィルタ結合ルールが設定されている場合は、二次データビューで仮想変換ルールを設定して、その結合データビューでエントリを追加できるようにする必要があります。


    dpconf add-virtual-transformation secondary-view-name \
write add-attr-value dn uid=\${uid}
    注 –

    このルールを設定しなければ、結合データビューにエントリを追加できません。

  3. (省略可能) 二次ビューでバインドを許可するかどうかを指定します。

    デフォルトでは、すべてのデータビューでバインドが可能です。二次データビューのバインドを禁止する場合は、次のコマンドを実行します。


    $ dpconf set-ldap-data-view-prop -h host -p port secondary-view-name process-bind:false

    このプロパティーの詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Handling of Binds」を参照してください。

  4. (省略可能) 二次データビューに共有エントリが含まれるかどうかを指定します。


    $ 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.3 Reference』の「Handling of Shared Entries」を参照してください。

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

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

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

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

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

  1. リレーショナルデータベース用の 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 ソースに接続できます。

  2. JDBC データソースプールを作成します。


    $ dpconf create-jdbc-data-source-pool -h host -p port pool-name

  3. JDBC データソースを JDBC データソースプールに接続します。


    $ dpconf attach-jdbc-data-source -h host -p port pool-name source-name

  4. JDBC データビューを作成します。


    $ dpconf create-jdbc-data-view -h host -p port view-name pool-name suffix-DN

  5. (省略可能) データビューが正常に作成されたことを確認するために、JDBC データビューの一覧を表示します。


    $ dpconf list-jdbc-data-views -h host -p port

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

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

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

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


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

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

JDBC データビューを設定する場合、次のオブジェクトも設定する必要があります。

  1. リレーショナルデータベースの各テーブルの JDBC テーブルを作成します。


    % dpconf create-jdbc-table jdbc-table-name db-table

    db-table の名前は大文字と小文字を区別します。リレーショナルデータベースで使用したのと同じ文字 (大文字または小文字) を使用してください。異なる文字を使用すると、そのテーブルをターゲットとする操作は失敗する場合があります。

  2. 各リレーショナルデータベーステーブル内で各列の JDBC 属性を作成します。


    % dpconf add-jdbc-attr table-name attr-name sql-column

    JDBC 属性を作成すると、テーブル列が LDAP 属性にマップされます。

  3. (省略可能) リレーショナルデータベース内の列が大文字と小文字を区別する場合、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 は、大文字と小文字を区別しないデータベースではサポートされません。

  4. 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 となります。

    JDBC オブジェクトクラスの DN パターンに定義されたサブツリーコンポーネントにはすべて、それらのサブツリーコンポーネント用に定義された JDBC オブジェクトクラスを設定するようにしてください。たとえば、JDBC オブジェクトクラスに uid,ou という DN パターンがある場合、JDBC オブジェクトクラス定義に DN パターン ou を設定するようにしてください。これは、Directory Proxy Server で正しい構造の DIT を構築するために必要です。この設定を行わないと、ou=xxx,base-DN のような値を持つサブツリーが検索結果で返されません。

  5. 二次テーブルが存在する場合、一次テーブルと二次テーブル間の結合ルールを定義します。


    % dpconf set-jdbc-table-prop secondary-table-name filter-join-rule:join-rule

    結合ルールは二次テーブルで定義され、そのテーブルからのデータが一次テーブルのデータにリンクされる方法を決定します。オブジェクトクラスの一次テーブルと二次テーブル間の関係の定義方法は重要です。詳細については、「JDBC テーブル間の関係の定義」を参照してください。

  6. JDBC オブジェクトクラスのスーパークラスを指定します。


    % dpconf set-jdbc-object-class-prop view-name objectclass super-class:value

    スーパークラスは、JDBC オブジェクトクラスが継承した LDAP オブジェクトクラスを示します。

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

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

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

次の例は、最初の 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}"

複数の二次テーブルの場合は、二次テーブルごとに filter-join-rule を設定する必要があります。複数の二次テーブルで filter-join-rule を設定する方法の詳細については、手順 11 を参照してください。

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

例 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 でサポートされていません。

仮想設定の例

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

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

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

図 23–1 仮想設定の例

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

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

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

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

DIR_PROXY_PORT

1389

LDAP_ADMIN_PWF

pwd.txt、管理者パスワードを含むファイル

DIRSERV_PORT

4389

LDAP_ADMIN_USER

cn=Directory Manager

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

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

始める前に

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

  1. Directory Server インスタンスに対して、myds1 という名前の LDAP データソースを作成します。


    % dpconf create-ldap-data-source myds1 host1:4389

  2. データソースを有効にして、データソースへの書き込み操作を許可します。


    % dpconf set-ldap-data-source-prop myds1 is-enabled:true is-read-only:false

  3. myds1-pool という名前の LDAP データソースプールを作成します。


    % dpconf create-ldap-data-source-pool myds1-pool

  4. LDAP データソースを LDAP データソースプールに接続します。


    % dpconf attach-ldap-data-source myds1-pool myds1

  5. データソースがそのデータソースプールからのバインド、追加、検索、および変更操作の 100% を受け取るように指定します。


    % dpconf set-attached-ldap-data-source-prop myds1-pool myds1 add-weight:100 \
 bind-weight:100 modify-weight:100 search-weight:100

  6. ベース DN が dc=example,dc=com で myds1–view という名前のデータソースプールの LDAP データビューを作成します。


    % dpconf create-ldap-data-view myds1-view myds1-pool dc=example,dc=com

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

  1. 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 を処理するようにデータビューを定義する必要があります。

  2. 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 データベースが次のように設定されていることが前提となっています。

次の表は、データベース内のテーブルと複合フィールドを説明しています。JDBC データビューを設定するためにこの情報が必要です。

mySQL テーブル 

フィールド 

EMPLOYEE

ID、SURNAME、PASSWORD、 ROOM、COUNTRY_ID

COUNTRY

ID、NAME

PHONE

USER_ID、NUMBER

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

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

  2. SQL データベースのユーザー名とパスワードファイルを指定します。


    % dpconf set-jdbc-data-source-prop mysql1 db-pwd-file:sqlpwd.txt db-user:root

  3. プロキシサーバーを再起動します。


    % dpadm restart /local/dps

  4. データソースを有効にして、データソースへの書き込み操作を許可します。


    % dpconf set-jdbc-data-source-prop mysql1 is-enabled:true is-read-only:false

  5. mysql1–pool という名前の JDBC データソースプールを作成します。


    % dpconf create-jdbc-data-source-pool mysql1-pool

  6. JDBC データソースをデータソースプールに接続します。


    % dpconf attach-jdbc-data-source mysql1-pool mysql1

  7. ベース DN が o=sql で myjdbc1–view という名前のデータソースプールの JDBC データビューを作成します。


    % dpconf create-jdbc-data-view mysql1-view mysql1-pool o=sql

  8. MySQL データベースの各テーブルの JDBC テーブルを作成します。


    % dpconf create-jdbc-table employee1 EMPLOYEE
% dpconf create-jdbc-table country1 COUNTRY
% dpconf create-jdbc-table phone1 PHONE

    SQL データベースのテーブル名は大文字と小文字を区別します。SQL データベースの場合と同じ文字 (大文字または小文字) を使用していることを確認してください。

  9. 各テーブルの各列の 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 列には、LDAP 属性 uid がすでに作成されている EMPLOYEE.ID に存在する値だけが含まれるため、これらの列の JDBC 属性を必ずしも作成する必要はありません。

  10. LDAP person オブジェクトクラスに対して JDBC オブジェクトクラスを作成します。

    ここでは、employee1 テーブルを一次テーブル、country1 テーブルと phone1 テーブルを二次テーブルとします。JDBC オブジェクトクラスの作成にも DN が必要です。この例では、DN は uid 属性とデータビューのベース DN から構築されます。


    % dpconf create-jdbc-object-class mysql1-view person employee1 country1 phone1 uid

  11. 一次テーブルと二次テーブル間の結合ルールを定義します。

    結合ルールは二次テーブルで定義され、そのテーブルからのデータが一次テーブルのデータにリンクされる方法を決定します。


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

  12. JDBC オブジェクトクラスのスーパークラスを指定します。

    スーパークラスは、JDBC オブジェクトクラスが属性を継承した LDAP オブジェクトクラスを示します。


    % dpconf set-jdbc-object-class-prop mysql1-view person super-class:top

Procedure必要な ACI を作成する

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

  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

  2. o=sql ドメインへの接続を処理するために接続ハンドラを作成します。


    % dpconf create-connection-handler mysql1-handler

  3. 接続ハンドラを有効にして、o=sql ドメイン内のユーザーからのバインドをすべて処理するように設定します。


    % dpconf set-connection-handler-prop mysql1-handler is-enabled:true \
 bind-dn-filters:"uid=.*,o=sql"

  4. 前の手順で追加した ACI のプールを使用するように接続ハンドラを設定します。


    % dpconf set-connection-handler-prop mysql1-handler aci-source:mysql1

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

  1. o=sql のユーザーとして JDBC データソースを検索し、データビューから読み取りができることを確認します。 


    % ldapsearch -p 1389 -D "uid=kvaughan,o=sql" -w mypwd -b o=sql "objectclass=*"
    注 –

    o=sql のユーザーの資格を使用する必要があります。

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


    % ldapmodify -p 1389 -D "uid=kvaughan,o=sql" -w mypwd
dn: uid=kvaughan,o=sql
changetype: modify
replace: userPassword
userPassword: myNewpwd

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

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

  1. myjoin1–view という名前の結合データビューを作成します。

    LDAP データビューを一次データビュー、JDBC データビューを二次データビューに指定します。


    % dpconf create-join-data-view myjoin1-view myds1-view mysql1-view o=join

  2. 二次データビューで結合ルールを定義します。

    次の結合ルールは、二次データビューのエントリの uid 属性が一次データビューのエントリの uid 属性に一致することを指定します。


    % dpconf set-jdbc-data-view-prop mysql1-view filter-join-rule:uid=\${myds1-view.uid}

  3. 結合データビューでフィルタ結合ルールが設定されている場合は、二次データビューで仮想変換ルールを設定して、その結合データビューでエントリを追加できるようにする必要があります。


    dpconf add-virtual-transformation secondary-view-name \
write add-attr-value dn uid=\${uid}
    注 –

    このルールを設定しなければ、結合データビューにエントリを追加できません。

  4. 結合データビューを使用して、一次データビューに対して読み書きができる属性のセットを定義します。


    % 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 データビューに直接アクセスした場合、デフォルトでは、すべての属性が読み書きできます。

  5. 結合データビューを使用して、二次データビューに対して読み書きができる属性のセットを定義します。


    % 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 データビューに直接アクセスした場合、デフォルトでは、すべての属性が読み書きできます。

Procedure必要な ACI を作成する

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

  2. 前の手順で追加した ACI のプールを使用するように接続ハンドラを設定します。


    % dpconf set-connection-handler-prop default-connection-handler aci-source:myjoin1

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

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

    ここでは、Kirsten Vaughan のエントリを検索し、両方の結合ビューからのデータが取得されるかどうかを確認します。


    % ldapsearch -p 1389 -b o=join "uid=kvaughan"

    返されるエントリには、LDAP データビューと JDBC データビューの両方からの属性が含まれていることに注意してください。

  2. 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 部門は 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.3 Reference』の第 17 章「Directory Proxy Server Distribution」および『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 18 章「Directory Proxy Server Virtualization」を参照してください。

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

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

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

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

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

図は、LDAP ディレクトリと LDIF ファイルの結合ビューを示しています。

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

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

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

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

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

  1. 給与ディレクトリの LDAP データソースを作成します。

    $ dpconf create-ldap-data-source payroll-directory payrollHost:2389

  2. 給与ディレクトリの LDAP データソースプールを作成します。

    $ dpconf create-ldap-data-source-pool payroll-pool

  3. 給与データソースをデータソースプールに接続します。

    $ dpconf attach-ldap-data-source payroll-pool payroll-directory

  4. 接続済みデータソースのウェイトを設定します。

    $ 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

  5. 給与ディレクトリの LDAP データビューを作成します。

    $ dpconf create-ldap-data-view payroll-view payroll-pool o=example.com

  6. クライアント要求がこのデータビューに経路指定できるように LDAP データビューを有効にします。

    $ dpconf set-ldap-data-view-prop payroll-view is-enabled:true

  7. 変更を有効にするために、Directory Proxy Server を再起動します。

    $ dpadm restart /local/myDPS

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

  1. 管理データの LDIF データビューを作成します。

    $ dpconf create-ldif-data-view admin-view example.ldif dc=example,dc=com

  2. 管理データの LDIF データビューを有効にします。

    $ dpconf set-ldif-data-view-prop admin-view is-enabled:true

  3. 管理ビューに給与ビューの複数のエントリで使用されるエントリが含まれるように指定します。

    $ dpconf set-ldif-data-view-prop admin-view contains-shared-entries:true

    このプロパティーが TRUE に設定されている場合、給与データビューのエントリを削除しても、管理データビューの共有エントリは削除されません。給与データビューにエントリを追加すると、それがすでに存在していなければ、二次データビューのエントリのみが追加されます。

  4. 変更を有効にするために、Directory Proxy Server を再起動します。

    $ dpadm restart /local/myDPS

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

  1. データの集約方法を指定するフィルタ結合ルールを管理データビューで作成します。

    次の結合ルールは、ユーザーエントリの employeeNumber 属性に基づいてデータが結合されるよう指定します。

    $ dpconf set-ldif-data-view-prop admin-view \
filter-join-rule:employeeNumber=\${payroll-view.employeeNumber}

  2. 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 の名前の変更

図は、データを DIT に追加するための DN の名前の変更を示しています。

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

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

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

  1. Company 22 のディレクトリの LDAP データソースを作成します。

    $ dpconf create-ldap-data-source company22-directory company22Host:2389

  2. Company 22 のディレクトリの LDAP データソースプールを作成します。

    $ dpconf create-ldap-data-source-pool company22-pool

  3. Company 22 のデータソースをデータソースプールに接続します。

    $ dpconf attach-ldap-data-source company22-pool company22-directory

  4. 接続済みデータソースのウェイトを設定します。

    $ 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

  5. 仮想 DN の dc=example,dc=com で Company 22 のディレクトリの LDAP データビューを作成します。

    $ dpconf create-ldap-data-view company22-view company22-pool dc=example,dc=com

  6. この仮想 DN を Company 22 のディレクトリの実際の DN にマップするよう Directory Proxy Server に命令します。

    $ dpconf set-ldap-data-view-prop company22-view \
dn-mapping-source-base-dn:dc=company22,dc=com

  7. クライアント要求がこのデータビューに経路指定できるように、Company 22 のディレクトリの LDAP データビューを有効にします。

    $ dpconf set-ldap-data-view-prop company22-view is-enabled:true

  8. 変更を有効にするために、Directory Proxy Server を再起動します。

    $ dpadm restart /local/myDPS

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

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

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

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

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

  1. データの集約方法を指定するフィルタ結合ルールを Company 22 データビューで作成します。

    次の結合ルールは、ユーザーエントリの employeeNumber 属性に基づいてデータが結合されるよう指定します。

    $ dpconf set-ldif-data-view-prop company22-view \
filter-join-rule:employeeNumber=\${example-join-view.employeeNumber}

  2. 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 データビューが作成されます。

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

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

  1. 給与データベース用の JDBC データソースを作成します。

    $ dpconf create-jdbc-data-source -b payrollsqldb \
  -B jdbc:payrollsqldb:payrollsql://localhost/ \
  -J file://payrollsqldb.jar \
  -S org.payrollsqldb.jdbcDriver payroll-src

  2. SQL データベースのプロパティーで JDBC データソースを設定します。

    $ dpconf set-jdbc-data-source-prop payroll-src \
  db-user:proxy db-pwd-file:password-file-location/myPasswordFile

  3. JDBC データソースを有効にします。

    $ dpconf set-jdbc-data-source-prop payroll-src is-enabled:true

  4. 給与データベース用の JDBC データソースプールを作成します。

    $ dpconf create-jdbc-data-source-pool payroll-pool

  5. 給与データソースをデータソースプールに接続します。

    $ dpconf attach-jdbc-data-source payroll-pool payroll-src

  6. 仮想 DN の o=payroll で給与データベースの JDBC データビューを作成します。

    $ dpconf create-jdbc-data-view payroll-view payroll-pool o=payroll

  7. SQL データベースの各テーブルの JDBC テーブルを作成します。

    $ dpconf create-jdbc-table jdbc-employee employee
$ dpconf create-jdbc-table jdbc-salary salary

  8. 各 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

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

  10. LDAP オブジェクトクラスにマップされる JDBC オブジェクトクラスを作成します。

    次のコマンドは、LDAP person オブジェクトクラスにマップされるオブジェクトクラスを作成します。オブジェクトクラスは、従業員テーブルは一次テーブルとして使用され、給与テーブルが二次テーブルとして使用されるよう指定します。eid 属性は、DN を構築するために使用されます。

    $ dpconf create-jdbc-object-class payroll-view \
 person jdbc-employee jdbc-salary eid

  11. 二次テーブルからのデータが一次テーブルからのデータにリンクされる方法を指定したフィルタ結合ルールを二次テーブル上で作成します。

    次の結合ルールは、employee_id 属性に基づいてデータが結合されるよう指定します。

    $ dpconf set-jdbc-table-prop jdbc-salary \
filter-join-rule:employee_id=\${employee.employee_id}

  12. JDBC オブジェクトクラス上のスーパークラスを作成します。

    $ dpconf set-jdbc-object-class-prop payroll-view person super-class:extensibleObject

仮想アクセス制御の追加

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

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

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

  1. 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");)

  2. 接続ハンドラで仮想 ACI をポイントします。

    $ dpconf set-connection-handler-prop anonymous aci-source:ldifonly-acis

  3. 接続ハンドラを有効にします。

    $ dpconf set-connection-handler-prop anonymous is-enabled:true