| Oracle® Fusion Middleware Oracle Virtual Directory管理者ガイド 11gリリース1(11.1.1) B55922-05 |
|
 前へ |
 次へ |
この章では、Oracle Virtual Directoryのアダプタについて説明します。この章の内容は次のとおりです。
複数かつ様々なデータ・リポジトリにあるデータの単一の仮想ディレクトリ・ビューを表示するには、Oracle Virtual Directoryをこれらのリポジトリに接続して、データの仮想化とリポジトリ間でのデータのルーティングを可能にする必要があります。Oracle Virtual Directoryは、アダプタを使用して基礎となるデータ・リポジトリに接続します。各アダプタは、特定の親識別名(DN)で識別されるディレクトリのネームスペースを管理します。構成できるアダプタ数に制限はありません。また、アダプタを組み合せてオーバーラップさせることにより、カスタマイズ・ディレクトリ・ツリーを作成できます。
この章の項では、Oracle Virtual Directoryの各アダプタについて説明します。次に、Oracle Virtual Directoryが提供するアダプタのリストを示します。
LDAPアダプタ
データベース・アダプタ
ローカル・ストア・アダプタ
結合ビュー・アダプタ
カスタム・アダプタ
LDAPアダプタは、Oracle Virtual DirectoryをLDAPv2とLDAPv3のディレクトリ、およびMicrosoft Active Directoryに接続します。LDAPアダプタでは、ディレクトリ構造とスキーマの変換がリアルタイムで自動的に行われるため、Oracle Virtual DirectoryはLDAPv2とLDAPv3およびMicrosoft Active Directoryのデータを、仮想ディレクトリのサブツリーとして表すことができます。ディレクトリの最上部で仮想サブツリーのルートとなるようLDAPアダプタを構成し、アダプタが仮想ディレクトリの情報ツリー(DIT)全体を網羅するようにできます。接続先の各LDAPソースごとに1つのLDAPアダプタが必要です。たとえば、4つのレプリカ・サーバーを持つActive Directoryのドメイン・コントローラがある場合、LDAPアダプタを1つのみデプロイし、レプリカの4つのホスト名およびポートをそれぞれリストするように構成します。
Oracle Virtual Directoryを使用すると、レプリカ全体のリクエストのロード・バランシングや、順番でのフェイルオーバーが可能になります。Oracle Virtual Directoryの管理者は、ロード・バランシングの割合を調整できます。
LDAPアダプタには、追加のフォルト・トレランスやパフォーマンスのソリューションが用意されています。これには、特定の検索基準、または可用性や操作タイプ(変更操作と問合せ操作の比較など)に従ったロード・バランシング要件に基づき、LDAP問合せのトラフィックを複数のLDAPディレクトリ・レプリカに転送する機能などがあります。たとえば、何千ものアクティブ・クライアントがある場合、Oracle Virtual Directoryは、数千の問合せを処理する安定した10または20の接続に負荷を減らします。つまり、特にビジー状態にあるクライアントの場合は、定義されたロード・バランシングの目標値に従って、ワーカー・スレッドのそれぞれに負荷を分散します。
高パフォーマンス・シナリオの場合、LDAPアダプタで、限定された一連の接続全体に複数のクライアントからの負荷を分散することによって、ソース・ディレクトリに対する接続負荷を均等にすることができます。LDAPアダプタは、Oracle Virtual Directory、ソース・ディレクトリおよびそのレプリカ間の接続プールを維持することでこれを実現します。これにより、接続処理の負荷が減少し、最大スレッド負荷を超えないようにOracle Virtual Directoryへのトラフィックが制限されて、ソース・ディレクトリの処理が高速になります。
|
注意: Oracle Virtual Directoryを使用すると、SSLを使用してLDAPアダプタのインタフェースを保護できます。 |
この項のこれ以降では、次に示すLDAPアダプタの追加情報を説明します。
LDAPアダプタは、次に示すものとしてデプロイできます。
単純プロキシ
仮想ディレクトリ・プロキシ
単純プロキシとしてのLDAPアダプタ
LDAPアダプタは、単純プロキシとして、変換を実行しないように構成できます。これにより、Oracle Virtual Directoryは、可用性およびファイアウォールの問題を解決するディレクトリ・ルーターとして機能します。LDAPアダプタを単純プロキシとして構成するには、アダプタ・ルートとアダプタ・リモート・ベースの構成パラメータを同じ値に設定します。
仮想ディレクトリ・プロキシとしてのLDAPアダプタ
それとは対照的に、あるディレクトリ・ツリーのネームスペースを別の名前に変更して単純なネームスペース・マッピングを提供することが必要な場合があります。アダプタ・ルートおよびアダプタ・リモート・ベース構成パラメータに異なる値を設定すると、暗黙的にネームスペース・マッピングが指定されます。たとえば、プロキシ・ディレクトリのベースou=People,o=Airius.comに、peopleエントリがあるとします。ローカル・ディレクトリは、Airiusエントリへのコールがローカルのpeopleフォルダに表示されるように設計されています。
アダプタ構成パラメータに次の設定を行うとします。
アダプタ・ルート: ou=Airius,ou=People,dc=YourCompany,dc=com
リモート・ベース: ou=People,o=Airius.com
この設定でLDAPアダプタを介して問合せを行うと、ou=People,o=Airius.comより下のすべてのエントリのDNが、指定されたDNルートou=Airius,ou=People,dc=YourCompany,dc=comの下にあるように表示されます。
デフォルトで、すべての属性は、Oracle Virtual Directoryを介してプロキシ・ディレクトリからOracle Virtual Directoryクライアントへそのままの状態で受け渡しされます。LDAPアダプタは、DN属性構成パラメータ・リストに指定されたDNを含む属性の基本的なDN変換を実行できます。DN属性パラメータ構成リスト内の属性、およびLDAPアダプタのリモート・ベースDN構成パラメータ値を含むDN値を接尾辞として持つ属性のみが変換されます。たとえば、次の例を検討してみます。
アダプタ・ルートDNはdc=emer,dc=orion,dc=com、リモート・ベースDNはou=emer,o=orion.comです。
dc=emer,dc=orion,dc=comおよびdc=amer,dc=orion,dc=comネームスペース両方にメンバーを持つ(たとえばActive Directory信頼関係のため)dc=emer,dc=orion,dc=comネームスペースのグループ・グループ・オブジェクトは、次のように変換されます。
DN: cn=Group 1, cn=groups,ou=emer,o=orion.com objectclass: top objectclass: group member: cn=Jane Doe,cn=users,ou=emer,o=orion.com member: cn=Ted Davies,cn=users,dc=amer,dc=orion,dc=com
|
注意: LDAPアダプタはネームスペースの外にある値は変換できないため、dc=amer,dc=orion,dc=com値は変更されていません。
通常は、DN属性値がディレクトリ・ネームスペース内に存在するか、ディレクトリに追加される前に値が適切に変換されるため、これは一般的なシナリオではありません。 |
このようなシナリオが発生した場合は、カスタムのマッピング・スクリプトを使用して、アダプタのルート・ネームスペースの外にある値を変換します。また、Oracle Virtual Directoryは、リモート・ディレクトリのデータがマッピングおよびプラグインを使用してOracle Virtual Directoryに渡される際に、その場で属性を変換することもできます。
LDAPアダプタでは、読取り、追加、変更、削除および名前変更の機能が完全にサポートされます。LDAPの名前変更操作のサポートには、アダプタ間の名前変更、つまり移動の機能も含まれます。アダプタ間で行われるLDAP名前変更(すなわちmove)のLDAPv3 moddn機能では、切取りと貼付けが行われます。このトランザクションを安全に行うために、Oracle Virtual Directoryによって移動先ディレクトリへの追加が正常に行われたことが確認されるまで、元のエントリは削除されません。移動先ディレクトリでの追加が失敗した場合、操作は中断され、移動先ディレクトリからエラーが戻されます。
アダプタ間またはプロトコル間でサポートを提供するために、LDAPの比較操作は、自動的にLDAP取得またはLDAPバインド操作に変換されます。
Oracle Virtual Directoryのアクセス制御は、次の2つのレベルで適用されます。
Oracle Virtual Directoryのアクセス制御
リモートLDAPサーバーのアクセス制御
Oracle Virtual Directoryのアクセス制御
Oracle Virtual DirectoryではIETF RFC 2820がサポートされ、IETFの「LDAP Access Control Model for LDAPv3」(2001年3月2日草稿)に基づいてアクセス制御も実行されます。この草案では、RFC 2820をベンダーに中立的に実装する方法が指定されています。Oracle Virtual Directoryでは、これらの標準および草案に準拠したアクセス制御がすべてのアダプタで同様に実行されるため、一貫したセキュリティ実装が実現されます。詳細は、「Oracle Virtual Directoryのアクセス制御の概要」を参照してください。
リモートLDAPサーバーのアクセス制御
Oracle Virtual DirectoryはLDAPクライアントとして機能するため、LDAPディレクトリなどのリモート・アダプタ・ディレクトリでのアクセス制御に従う必要があります。この動作方法は、ベンダーのアクセス制御の実装によって異なります。
Oracle Virtual Directoryは、プロキシ設定されたディレクトリ・サーバーに接続すると、独自の資格証明またはバインドされているエンド・クライアントの資格証明を使用できます。
Oracle Virtual Directoryによってソース・ディレクトリにユーザー資格証明が渡された場合は、エンドツーエンドのユーザー・コンテキスト・アクセス制御が有効になります。これにより、リモート・サーバーで、バインドされたエンド・クライアントの資格証明が認証されます。
Oracle Virtual Directoryによって独自の資格証明が渡される場合、Oracle Virtual Directoryは、プロキシ設定されたディレクトリのサーバー資格証明に対して強制されるアクセス制御の対象となると同時に、独自のユーザー固有アクセス制御を実行する必要があります。
LDAPアダプタの資格証明の引渡し構成パラメータに設定する値に応じ、エントリがLDAPアダプタによって表されるユーザーのパスワードを使用してバインド・リクエストを処理する際に、Oracle Virtual Directoryは次のいずれかの方法で資格証明を検証できます。
資格証明の引渡し構成パラメータが「常時」または「バインドのみ」に設定されている場合は、Oracle Virtual Directoryにより、指定されたユーザーDNおよびパスワードが、プロキシ設定されたLDAPディレクトリに渡されます。プロキシ設定されたディレクトリは、ユーザーが入力したパスワードの妥当性の判別を行います。リモート・パスワード検証の成功または失敗は、透過的にユーザーに戻されます。
資格証明の引渡し構成パラメータが「なし」に設定されている場合、Oracle Virtual Directoryはアダプタで指定されたアカウントを使用してリモート・ディレクトリに接続し、暗号化されたパスワード値を取得します。
|
注意: アダプタ構成で指定されたアカウントは、プロキシ設定されたディレクトリによって暗号化されたパスワード値へのアクセス権が付与されている必要があります。それ以外の場合は、バインドが失敗として処理されます。暗号化された値がOracle Virtual Directoryに戻されると、Oracle Virtual Directoryでは、ユーザーのパスワードが暗号化され、それがプロキシ設定されたサーバーから戻された暗号化済の値と比較されます。一致すると判断された場合は、Oracle Virtual Directoryによって正常なバインドが戻されます。ユーザーが証明書のバインドを実行する場合は、資格証明の引渡し設定の「なし」が暗黙的に指定されます。この場合は、Oracle Virtual Directoryにより、リモートのLDAPプロキシからクライアントの公開鍵を取得してクライアント資格証明が確認されます。 |
データベース・アダプタは、すべての機能が備わったLDAPからJava Database Connectivity(JDBC)へのゲートウェイで、すべてのLDAP操作(追加、バインド、削除、取得、変更、名前の変更)を、プリコンパイルされた同等のSQL文コードに変換できます。データベース・アダプタは、JDBC-ODBCライブラリを介してJDBCまたはOpen Database Connectivity(ODBC)をサポートするほとんどのデータベースに接続できます。データベース・アダプタではJDBCクラス・ライブラリを使用して、LDAP検索を実行するためのデータベースへの接続を形成します。必要なデータベース・ライブラリは、一般的にはデータベース・ディストリビューションとともに提供されるか、データベース・ベンダーを介して入手できます。
データベース・アダプタの機能
次に、データベース・アダプタの機能の一部を示します。
ソース・データベースの変更が不要。
表および列の柔軟なマッピング。LDAPオブジェクト・クラスを表から導出する方法が定義されているマッピングを使用して、ほぼすべてのLDAPオブジェクトをその場で構成できます。
リクエストを簡略化するための接続プール。
Oracle Virtual Directory内、またはRDBMSサーバーのビューを使用して実行される複数表の結合。
プライマリ・キーとグルーピングを使用した複数の値を持つ属性のマッピング
単一のアダプタ接続内に複数のオブジェクト・クラスおよび階層を構成する機能。
データベース・アダプタの考慮事項
データベース・アダプタを使用する際は、次の点に注意してください。
LDAP操作ではトランザクションがサポートされていないため、データベース・アダプタでは、一度に1つの表が変更されます。
LDAPでは複数値の属性がサポートされていますが、データベース表でサポートされているのは各列に1つの値のみです。データベース表に複数値の属性を持つエントリを作成するには、データベース・アダプタで表を非正規化し、エントリの属性の各値に対して行を1行ずつ作成します。
データベース・アダプタは、Oracle Virtual Directoryの資格証明のみを使用してデータベースに接続します。LDAPアダプタのように、クライアント・ユーザーの資格証明を通過させることはできません。
データベース・アダプタでサポートされているのは通常のSQL操作のみで、デプロイ固有のストアド・プロシージャはサポートされていません。データベースのストアド・プロシージャ統合をサポートする場合は、データベース・アダプタとともにプラグインを使用することを検討してください。
ルートのアダプタ・ネームスペースであるDNの一部を除き、エントリのDNを形成するすべてのコンポーネントがデータベース表に含まれている必要があります。
複数の属性が1つのデータベース列にマッピングされている場合、Oracle Virtual Directoryにより戻される属性は1つのみです。この問題は、カスタム・マッピング・スクリプトを作成することで解決できます。
データベース表のフィールドに格納されているパスワードを検証するなど、データベース・アダプタを使用してクライアント・バインドを管理する場合は、データベースのCHAR/VARCHARフィールドにパスワードを格納し、データベース・アダプタにデータベース・パスワードのマップ・マッピングをデプロイする必要があります。
検索フィルターで使用された場合、データベース・アダプタで現在サポートされているのは、電話番号値の完全一致のみです。データベース・アダプタを使用して電話番号の検索をサポートしている場合は、問合せを送信する前に、プラグインを使用して入力値を正規化し、LDAP標準に準拠していないLDAPアダプタが継続して機能するようにできます。
データベース・アダプタでは、複数値のRDNはサポートされていません。
この項のこれ以降では、次に示すデータベース・アダプタの追加情報を説明します。
データベース・アダプタは、Oracle Virtual Directoryの固有のアクセス制御に加えて、リモート・データベースに存在するアクセス制御にも関係します。LDAPアダプタとは異なり、認証されたユーザーの資格証明をOracle Virtual Directoryからリモート・データベースに渡すことはできません。つまり、Oracle Virtual Directoryは、JDBCクライアントとして、JDBC接続情報で指定されるアダプタのデータベース・ユーザー名によって定義される、アダプタのRDBMSサーバーが認証する機能に対して制約を受けます。すべての問合せは、データベース・ユーザー名フィールドに指定されたアカウントを使用して実行されます。
Oracle Virtual Directoryでは、データベースから戻された値をユーザーが指定した値と比較して、パスワード検証が実行されます。ハッシュまたは暗号化された形式でパスワードが格納される場合は、その値の接頭辞として適切なハッシュ修飾子({crypt}、{sha}、{ssha})を使用する必要があります。この接頭辞により、Oracle Virtual Directoryに対して、パスワードの検証時に使用するパスワード・ハッシュの比較アルゴリズムのタイプが指定されます。この接頭辞はLDAPの表記規則であるため、テキスト・ファイルには存在しない可能性があります。接頭辞を割り当てるには、アダプタ・マッピングを使用します。
Oracle Virtual Directoryでは、独自の標準ベースのLDAPセキュリティおよびアクセス制御モデルが、すべてのアダプタおよびアダプタ・タイプに同時に適用されます。
特定のJDBCドライバを使用するには、その前に「Oracle Virtual Directoryサーバーへのライブラリのロード」の説明に従って、そのドライバ・ファイルをOracle Virtual Directoryにロードする必要があります。ドライバ・ファイルは、各製造業者からダウンロードできます。ドライバの検出の詳細は、http://www.oracle.com/technology/index.htmlのOracle Technology Networkを参照してください。
JDBCライブラリがOracle Virtual Directoryにロードされたら、事前定義済のデータベース・タイプを選択するか、製造業者によって定義されたJDBC URLを指定して、新しいデータベース・アダプタ接続を定義できます。
データベース・アダプタでは、次のデータベースの事前定義済JDBC URLがサポートされます。
Hypersonic
IBM DB2
Microsoft SQL*Server
MySQL
OpenBase
Oracle
PostgreSQL
Sybase
Sun ODBC-JDBC Bridge
次に、データベース・アダプタの使用時に、リレーショナル・データ構造を階層ディレクトリにマッピングする際に関連する事項のリストを示します。
エントリ名の一部として使用するすべてのデータベース・フィールド(アダプタのルートであるDNの一部分を除く)は、データベース・アダプタ経由でOracle Virtual Directoryにマッピングおよび戻される表の行に含まれている必要があります。たとえば、ユーザー・オブジェクトのDNに共通名(cn)と組織単位(ou)の両方が含まれる階層(cn=Joe User,ou=Marketingなど)を作成するには、cnとouの両方がエントリの一部であることが必要です。
純粋なLDAPでは、ou属性は親エントリの一部であるため、本来は必要ありません。データベースは階層的ではないため、これによって、階層を定義するために多くの新しいメタデータを作成して管理せずに、複数レベルのDNを生成できます。
データベース・アダプタの使用時のパフォーマンスを向上させるために、マップされるデータベース表に適切な索引を作成することをお薦めします。たとえば、employeeという表にsalaryおよびemployeenameという列があり、cn名がemployeenameにマップされるとします。パフォーマンスを向上させるには、次のようにemployeenameの関数索引を作成します。
create index upper_employee on employee (upper(employeename));
複数表の書込みは、単一のデータベース・アダプタを介して直接行うことはできません。これは、複数表の列を表示しているときには表示の更新を直接実行できないという、データベースで発生する制限と同じです。
Oracle Virtual Directoryでは、Oracle Virtual Directoryの結合ビュー・アダプタを使用することで、この制限を回避できます。複数のデータベース・アダプタを作成し(一般的に表ごとに1つ)、アダプタ間の関係を定義すると、複数の表を介して構成されたエントリへのOracle Virtual Directoryによる書込みが可能になります。
データベースでは、一般的に表の単一の行にある単一フィールドに複数の値を使用できません。配列タイプがサポートされる例外もありますが、これらのデータ・タイプは相対的に制限される傾向にあります。一部では、カンマやパイプ(|)などのデリミタを使用してフィールド内のデータ(アカウントのフラグなど)を区切ることで、複数の値を行に挿入するということが行われています。
従来型のデータベース設計では、複数の値を持つフィールドは、正規化して追加の表にすることが求められます。データ・ウェアハウスの一部であるデータベースでは、すべてのフィールドのすべての順列を非正規化された表に配置するという、異なる方法が採られる場合があります。
Oracle Virtual Directoryでは、通常どちらかのモデルがサポートされます。一般的にOracle Virtual Directoryでは、指定されたRDN属性を使用して複数の行がグループ化されます。Oracle Virtual Directoryのスキーマが複数値をサポートする場合、Oracle Virtual Directoryはこれらの行をグループ化して、結合エントリを形成します。
たとえば、次の例に示すような、グループ・メンバーシップの定義に使用する表があるとします。最初の列にはグループ名が記載されています。メンバーは、次のように2番目の列で定義されています。
| GroupName | Member |
|---|---|
| My First Group | cn=Paul Jacobs,cn=Users,dc=Oracle,dc=com |
| My First Group | cn=Alice Wing,cn=Users,dc=Oracle,dc=com |
| My First Group | cn=Jim Smith,cn=Users,dc=Oracle,dc=com |
| Administrators | cn=Paul Jacobs,cn=Users,dc=Oracle,dc=com |
| Administrators | cn=Jim Smith,cn=Users,dc=Oracle,dc=com |
SQLでは、各グループのメンバーを表示するSQL問合せは次のようになります。
select * from grouptable group by groupName;
データベース・アダプタを介してプロキシ設定された場合、Oracle Virtual Directoryはデータを次のように戻します。
dn: cn=My First Group,ou=Groups,dc=Yourcompany,dc=com objectclass: groupofuniquenames objectclass: top cn: My First Group uniquemember: cn=Paul Jacobs,cn=Users,dc=Oracle,dc=com uniquemember: cn=Alice Wing,cn=Users,dc=Oracle,dc=com uniquemember: cn=Jim Smith,cn=Users,dc=Oracle,dc=com dn: cn=Administrators,ou=Groups,dc=Yourcompany,dc=com objectclass: groupofuniquenames objectclass: top cn: Administrators uniquemember: cn=Paul Jacobs,cn=Users,dc=Oracle,dc=com uniquemember: cn=Jim Smith,cn=Users,dc=Oracle,dc=com
この結果では、グループ名は一意の単一値にまとめられ、グループのメンバーは複数値のuniquemember属性に結合されています。
正規化および非正規化された表に対する検索がサポートされます。必要に応じてデータベース・レベルの結合を構成する以外は、何も行う必要はありません。正規のLDAP条件で期待されるように、属性のすべての値が返されます。たとえば、次のような検索を行うとします。
ldapsearch -b "ou=groups,dc=yourcompany,dc=com" -s sub "uniquemember=Paul Jacobs,cn=Users,dc=Oracle,dc=com"
データベース・アダプタでは次のような結果が戻されます。
cn=Administrators,ou=Groups,dc=Yourcompany,dc=com objectclass=groupofuniquenames objectclass=top cn=Administrators uniquemember=cn=Paul Jacobs,cn=Users,dc=Oracle,dc=com uniquemember=cn=Jim Smith,cn=Users,dc=Oracle,dc=com
一般的なグループ・エントリ検索は、通常ユーザー認証のために行われます。検索では、指定されたユーザーをメンバーに持つグループのリストが取得されます。結果セット内のグループ・エントリの完全なメンバーシップ情報は、通常は必要ありません。パフォーマンスを高めるために、uniquemember属性が不要な場合には、LDAPクライアントが必要な属性を明示的にリクエストし、uniquemember属性以外の属性を指定することをお薦めします。たとえば、前の検索にかわりに、次の検索を実行します。
ldapsearch -b "ou=groups,dc=yourcompany,dc=com" -s sub "uniquemember=Paul Jacobs,cn=Users,dc=Oracle,dc=com" dn cn
データベース・アダプタでは次のような結果が戻されます。
cn=Administrators,ou=Groups,dc=Yourcompany,dc=com cn=Administrators
複数表オブジェクト(正規化された表)への書込みは、データベースの設計に基づいて属性をそれぞれの表に分割する結合ビュー・アダプタ経由で実行する必要があります。これが必要となるのは、データベース設計に一般的なガイドラインがある一方で、それぞれの顧客のデータベースが異なり、結合された表間の関係が大きく変わる可能性があるためです。
既存の重要な表を使用する顧客は、これらの表の更新制御の一部としてストアド・プロシージャも使用します。これらはAPIコールと類似しており、作成および呼び出される方法はそれぞれのデータベースに固有です。APIコール自体は顧客独自のものです。Oracle Virtual Directoryでは、プラグイン・システムを使用することでストアド・プロシージャをサポートします。
Oracle Virtual Directoryでは非正規化された表に直接書き込むことができます。これらの表にはそれぞれのフィールド値が格納され、エントリのRDNとして使用されるフィールドに関連するエントリで使用されます。追加、変更、削除などのすべての操作がサポートされます。
変更操作では、LDAPにおける変更-置換の動作は、既存の属性値を削除してから新しい属性値を追加する方法で行われます。この動作は、SQLの挿入、更新、および削除の複合セットではなく、1つのSQL削除および1つのSQL挿入に変換されます。対応が難しい可能性があるのは、挿入および削除によりデータベース内で他のアクションがトリガーされる正規化された表を含むデータベースです。このような場合は、変更-置換操作を処理するためのプラグインを作成する必要があります。
ほとんどの顧客は、変更に直接SQLアクセスを使用しないか、読取りのみに複数の値を使用する、または変更-追加と変更-削除のみを直接使用するため、このような問題が発生することはありません。たとえば、大規模なグループの問題を解決する顧客が、Oracle Virtual Directoryを使用してデータベースにグループを格納しているとします。グループのほとんどのメンバーシップ変更は、置換ではなく追加と削除です。
「表への書込み」の説明で示した問題で、データベース・アダプタの使用時に最も注意すべき問題は、カスケード削除を使用するデータベースへの直接書込みを行うデータベースの処理が、Oracle Virtual Directoryによっていつ行われるかということです。カスケード削除では、1つの表で削除を行うと、データベースによりストアド・プロシージャがアクティブ化され、それによって他の表でも削除が発生します。カスケード削除を使用した場合、変更-置換によって、データベース・アダプタが直接処理を行う表の外側で削除がトリガーされる可能性があります。これが発生するのは、既存の値を削除するSQL DELETEおよび新規の置換値を追加するSQL INSERTを実行する単一のトランザクションが、データベースによって送信されるためです。
データベースのトリガーが単一の値を持つ表に基づいており、複数の値を持つフィールドが他の表に正規化されている場合は、これは問題になりません。変更対象のエントリに関連付けられている単一の行が表に含まれている場合の置換時に、Oracle Virtual DirectoryによってDELETE-INSERTの組合せではなくUPDATEが実行されます。
|
注意: データベース・アダプタは、LDAP更新時にマップされていないデータベース列値をNULLに設定します。この制限事項は、Oracle Virtual Directoryの将来のバージョンで解消される予定です。この制限事項に対処するには、すべての列をマップする(かつ、ルーティング・ルールを使用して検索結果に表示されないようにする)か、表を更新トリガーが設定されたビューにマップします。 |
アプリケーションが部分文字列検索を使用する場合、データベース・アダプタにマッピングされる属性は、VARCHARデータベース構文としてマッピングされる必要があります。これがSQLが部分文字列検索をサポートするための唯一の方法です。
ローカル・ストア・アダプタを使用すると、可用性を高くする必要のない少量のデータをローカルのフラット・ファイルに格納できます。次に、最も一般的なローカル・ストア・アダプタの使用方法を示します。
クライアント・アプリケーションに表示する必要はあるが、ほとんど変更されず、可用性を高くする必要もない少量のデータを格納する必要がある場合。Oracle Virtual Directoryとエンタープライズ・ユーザー・セキュリティ統合の一部としてOracle Internet Directoryをエミュレートするために、Oracle Virtual Directoryによって使用されるベース・エントリなどです。
開発者は、企業ディレクトリを使用するアプリケーションを作成するが、現在は企業ディレクトリ・サービスへのアクセス権がない場合に、ローカル・ストア・アダプタを使用できます。この場合、開発者はローカル・ストア・アダプタを使用して開発プロセスの一部としてテスト・エントリを格納し、アプリケーションを本番で使用できるようになったら、Oracle Internet Directoryなどの企業ディレクトリ格納システムに後から移行します。
|
注意: Oracle Virtual Directoryの値は仮想化およびプロキシ・サービス用で、ディレクトリ・ストア用ではありません。可用性の高いディレクトリ格納システムが必要な場合には、Oracle Virtual Directoryのローカル・ストア・アダプタではなく、Oracle Internet Directoryを使用することをお薦めします。 |
複数のアダプタがあり、それらがすべてディレクトリ・ツリーのブランチである際に、ディレクトリ・ツリー最上位の単一のエントリを保持する場合。次に例を示します。
次の2つのLDAPアダプタが構成されているとします。
ou=staff,dc=mycompany,dc=com
ou=customers,dc=mycompany,dc=com
ローカル・ストア・アダプタを使用して、その他のアダプタの上にdc=mycompany,dc=comの最上位のエントリを格納できます。Oracle Virtual Directoryにはこの最上位のエントリは必要なく、大部分のLDAPクライアントに透過的ですが、一部のLDAPクライアント・アプリケーション、特にグラフィカル・ユーザー・インタフェース・デスクトップのLDAP管理クライアントでは、サーバーの最上位にエントリが指定されていないと、誤ったエラー・メッセージが戻される場合があります。
Oracle Virtual Directoryの各サーバーに複数のローカル・ストア・アダプタをデプロイできますが、ほとんどのサーバーでデプロイされるのは1つのみです。複数のローカル・ストア・アダプタをデプロイする最も一般的な理由は、バックアップおよびリカバリを考慮して、異なるファイルにディレクトリ・ツリーの異なる部分を格納することです。たとえば、ディレクトリ・ツリーの相対的に静的なブランチは、頻繁にバックアップする必要はありません。
Oracle Internet Directoryのoidcmprecツールを使用して、ローカル・ストア・アダプタから別のリポジトリにLDAPデータを移行できます。
この項では、oidcmprecを使用したローカル・ストア・アダプタからのデータの移行の概要を説明します。
|
関連項目: Oracle Internet Directoryのoidcmprecツールの詳細は、次のドキュメントを参照してください。
|
この項には、次のシナリオでoidcmprecを使用して、ローカル・ストア・アダプタからデータを移行する方法の例が記載されています。
|
注意:
|
2つのローカル・ストア・アダプタ間における最初の一方向データ移行
たとえば、次のユースケースがあるとします。2つの異なるホストmyhost1およびmyhost2で、2つのOracle Virtual Directoryサーバーが稼働しているとします。各ホストにはローカル・ストア・アダプタ(LSA)が、myhost1にはLSA1、myhost2にはLSA2となるように構成されています。LSA1のc=USの下にあるデータを、初めてLSA2に移行する必要があります。この移行を実行するには、次のコマンドを実行します。
oidcmprec operation=reconcile source=myhost1:port destination=myhost2.port base="'c=US'" scope=subtree exclattr=orclguid
|
注意: 一方向のデータ移行には、oidcmprecのreconcile操作を使用することをお薦めします。 |
2つのローカル・ストア・アダプタ間での同期
たとえば、次のユースケースがあるとします。「2つのローカル・ストア・アダプタ間における最初の一方向データ移行」で説明されているように、あるOracle Virtual Directory(myhost1など)のローカル・ストア・アダプタ(LSA1など)から、異なるOracle Virtual Directory(myhost2など)の別のローカル・ストア・アダプタ(LSA2など)に初めてデータを移行しました。後で、2つのローカル・ストア・アダプタ間でc=USの下にあるデータを同期することが必要になるとします。ソースからc=USの下にあるすべてのデータを移行する必要はありません。かわりに、oidcmprecツールのRFC 2254に基づくタイムスタンプ・ベースのフィルタを使用して、最近変更されたデータのみを移行します。タイムスタンプ・フィルタに指定された値よりも後に変更された、ソース内のすべてのデータが宛先に移行されます。
|
注意:
|
このタイプの移行を実行するには、次のコマンドを実行します。
oidcmprec operation=reconcile source=myhost1:port destination=myhost2.port base="'c=US'" scope=subtree filter='("modifytimestamp>=point_in_time")' exclattr=orclguid
ローカル・ストア・アダプタからOracle Internet Directoryへのデータ移行
oidcmprecを使用して、ローカル・ストア・アダプタからOracle Internet Directoryにデータを移行することもできます。次のコマンドは、myhost1で稼働しているOracle Virtual Directoryのローカル・ストア・アダプタのc=USにあるデータを、myhost2で稼働しているOracle Internet Directoryに移行します。
oidcmprec operation=reconcile source=myhost1:OVD_port destination=myhost2.OID_port base="'c=US'" scope=subtree exclattr=orclguid
結合ビュー・アダプタは、リレーショナル・データベースの表結合のように、複数の異なるデータ・ソースを統合された1つのLDAPビューに結合します。結合ビュー・アダプタは、Oracle Virtual Directoryのその他のアダプタのように、基礎となるデータ・リポジトリには接続せず、1つ以上の既存のアダプタ上にデータをアセンブルします。結合ビュー・アダプタは、アダプタ間の結合関係(ジョイナとも呼ばれる)を定義することで、2つ以上のデータ・リポジトリを結合します。
結合ビューは動的で、プロキシ・ソース間の同期は実行しません。結合ビューの目的は、マージしたデータをLDAPクライアントにリアルタイムに提供することです。結合アダプタは、分割プロファイル(1つのエントリのデータが2つ以上のソースに分割されるケース)の問題を解決します。たとえば、結合アダプタを使用して、ユーザーのLDAPエントリと、人事管理データベース内のこのユーザーの役職をリンクさせることができます。結合アダプタは、スタッフのLDAPと顧客のLDAPなどの複数の異なるソースの検索をアプリケーションに許可する問題の解決には使用されません。この問題は、これらのソースを共通ルートの下に仮想ブランチとして見せることによって解決できます。
次に、結合ビュー・アダプタの機能の一部を示します。
複数のアダプタおよびオブジェクト・クラスの属性を1つの新しい仮想エントリにマージできます。
検索時に各アダプタが表示用の特定の属性を選択できます。
変更操作時に各アダプタが属性の変更を適用できます。
ネストした結合ビュー・アダプタがサポートされます。プライマリ・アダプタまたは結合アダプタを、別の結合ビュー・アダプタにすることが可能です。
再帰的結合ビュー・アダプタがサポートされます。自身との結合が行われ、結合エントリがなくなると再帰的な構造も終了します。
各結合アダプタ・エントリが戻されると、結合ビュー・アダプタにより、結合アダプタのどのエントリが統合エントリの形成に使用されたかを示す属性値vdejoindnが追加されます。
次に、結合ビュー・アダプタの重要事項を示します。
各結合ビュー・アダプタでは、プライマリ・アダプタが1つのみ識別される必要があります。プライマリ・アダプタは、ディレクトリ・ツリー・エントリの作成および検索に使用されます。結合ビュー・アダプタは、プライマリ・アダプタで検出された各エントリを取得し、定義された結合関係に従って別のアダプタのエントリと結合することで動作します。エントリが結合ビュー・アダプタに存在するためには、結合ビュー・アダプタのプライマリ・アダプタに存在する必要があります。デフォルトで、プライマリ・アダプタは認証資格証明の処理に使用されます。任意の結合アダプタもバインディングに使用されます。
各結合ビュー・アダプタには、プライマリ・アダプタのエントリと結合アダプタのエントリ間の結合関係を指定するゼロ以上の結合ルールがあります。結合ルールは、結合関係、結合しているアダプタ、およびuserprincipalname=uid検索基準などのSimple結合構成情報で構成されています。結合ルールは、定義された順序で処理され、累積的に実行されます。各結合が処理されると、結果の結合エントリが次の結合関係に使用されます。
詳細は、「結合関係」を参照してください。
結合ビュー・アダプタは、いくつかのルーティング属性(特にルーティング取得可能およびルーティング格納可能)に依存して、各アダプタのどの属性が取得可能かつ編集可能かを判断します。可視性のルーティング属性を使用すると、結合ビュー・アダプタの形成に使用されるプライマリ・アダプタおよび結合アダプタを非表示にできます。
デフォルトでは、結合ビュー・アダプタは、プライマリ・アダプタのみを検索します。ただし、ForkJoinプラグインを使用すると、結合されたソースの属性全体を検索できます。
2つのアダプタ、AとBがあるとします。アダプタAはプライマリ・アダプタであり、uid、sn、およびcnが含まれています。アダプタBには、uid、mail、およびemployeeNumberが含まれています。アダプタAをプライマリ・アダプタとし、アダプタBをセカンダリ・アダプタとして結合ビュー・アダプタCを作成し、uidを検索します。Oracle Virtual DirectoryはアダプタAを検索してそのエントリを見つけ、アダプタBを検索して一致する結合エントリをすべて見つけます。この検索では、uid、sn、cn、mail、およびemployeeNumberを含むエントリが戻されます。
クライアントがすべての属性を戻すようリクエストした場合、つまり検索操作後に属性のリストが残らない場合、Oracle Virtual Directoryは結合アダプタからすべての属性をリクエストします。ただし、クライアントが戻される属性のリストを指定した場合、それらの属性は結合条件の属性を使用して内部的に拡張され、Oracle Virtual Directoryは、結合アダプタの属性のそのリストのみをリクエストします。パフォーマンス上の理由から、結合条件の属性ではなく、クライアントが指定した属性のみが戻されます。Oracle Virtual Directoryであるか、結合ビュー・アダプタを使用しているかにかかわらず、LDAPサーバーから戻される属性の数を制限すると、パフォーマンスが向上します。
複数のデータ・ソースに同じ名前の属性が複数存在し(異なる2つのLDAPアダプタの2つのuidなど)、特定のアダプタからのみ属性値を取得するよう結合ビュー・アダプタを構成している場合、結合ビュー・アダプタにより表示されるのは単一の値のみです。特定のアダプタの属性のみを表示するには、属性を表示しないアダプタの「ルーティング」設定の「取得可能な属性」フィールドに、その属性がリストされていないことを確認してください。オプションで、マッピングまたはプラグインを使用して特定の属性を非表示にできます。
結合ビュー・アダプタは、動的かつリアルタイムにデータの結合ビューを提供します。同期は不要で、特に、次に示すような一般的なID管理タスクの実行に便利です。
Microsoft Active Directoryとのパスワードの統合
主要なユーザーIDリポジトリとしてMicrosoft Active Directoryを使用している場合には、結合ビュー・アダプタを使用することで、面倒なパスワード統合プロセスを行わずにすみます。結合ビュー・アダプタを使用すると、2つを結合して、Active Directoryからその他のアプリケーション・ディレクトリにパスワード情報をエクスポートする必要がなくなります。結合ビュー・アダプタを使用すると、Active Directoryのデータを使用したバインドを除き、クライアントにアプリケーション・ディレクトリ・データのビューが提供されます。
データ統合
結合ビュー・アダプタを使用すると、データベースおよびディレクトリを含む複数のデータ・ソースを結合し、Oracle Virtual Directoryでユーザーの統合ビューを作成できます。
アプリケーションの統合
一部のアプリケーション(特にカスタム・アプリケーション)には独自のデータ要件があり、多くの場合、それらの独自の要件に対応するために企業のディレクトリ・スキーマを変更するのは困難です。結合ビュー・アダプタを使用すると、企業ディレクトリのデータを使用し、かつ別のディレクトリまたはローカル・ストア・アダプタでカスタム・アプリケーションの独自のデータを管理できます。
各結合ビュー・アダプタには、個別のプライマリ・アダプタを必要です。結合ビュー・アダプタとそのプライマリ・アダプタを結合するには、結合関係(ジョイナとも呼ばれる)を作成します。結合関係は、どのように結合を形成するか、およびそれらがクライアントのかわりにすべてのディレクトリ操作にどのように影響を与えるかを定義する一連のルーチンです。Oracle Virtual Directoryは、カスタム・ロジックの作成に使用できる拡張可能なジョイナ・クラスを提供します。ジョイナ・クラスにはAPIが含まれ、これを使用することで、事前処理やDNマッピング・ロジック(preAdd、preModify、preGet、preDelete、preRenameなど)を各LDAP操作に加えることができます。
結合関係を指定せずに結合ビュー・アダプタを使用し、既存のアダプタをディレクトリ・ツリーの新しい場所にコピーすることもできます。これには、複製のアダプタを作成せずに、元のアダプタの接続プールを共有するという利点があります。
Simple結合関係は、remoteattribute=primaryadapterattributeという形式のSimple結合関係を使用してエントリの属性を比較することで、プライマリ・アダプタと結合ビュー・アダプタのエントリの間に1対1関係を定義します。remoteattributeは、ターゲットの結合アダプタの属性で、primaryadapterattrinuteはプライマリ・アダプタの属性です。条件のカンマ区切りのリストを使用して、より複雑な基準にすることができます。これにより、すべての条件をandで結合する複数条件の結合が作成されます。たとえば、uid=uid,sn=sn,mail=mailのようになります。
一致する属性が複数存在する場合、Oracle Virtual Directoryでは最初の一致する属性が使用されます。Oracle Virtual Directoryは、プライマリ・アダプタにのみAdd、Delete、RenameのLDAP操作を適用し、結合ビュー・アダプタではそれらの操作を無視します。
図2-1に、認証に使用されるSimple結合の高度な例を示します。
「Simpleジョイナ」の項で説明されているように、Simpleジョイナは、共有される属性値に基づいて2つのアダプタのエントリを結合します。条件付きのSimple結合関係は、結合が追加の条件によってのみ行われるように、Simpleジョイナの機能を拡張します。条件付きのSimple結合関係では、結合ルールに;文字を使用してSimple結合関係を拡張し、employeenumber>0など、その場合にのみ結合が行われる条件を追加します。
たとえば、Simpleジョイナ条件がemployeenumber=employeenumberであるとします。
次のように、ConditionalSimpleJoinerおよび;文字を使用して、このSimpleジョイナ・ルールを拡張し、条件を追加できます。
employeenumber=employeenumber;(&(employeenumber=101)(sn=Smith))
OneToMany結合関係は、複数のプライマリ・アダプタと結合ビュー・アダプタの間に1対多関係を定義します。Simple結合関係と同様、OneToMany結合関係では、属性を比較することで結合ビュー・アダプタの属性が特定されますが、結合ビュー・アダプタの一致するすべてのエントリがアダプタ間の関係に含まれます。OneToMany結合は、複数のロール・オブジェクトまたはIDを1つの仮想エントリに統合するために役立ちます。これもSimple結合関係と同じですが、Oracle Virtual Directoryは、プライマリ・アダプタにのみAdd、Delete、RenameのLDAP操作を適用し、OneToMany結合関係を使用している場合には、結合ビュー・アダプタではそれらの操作を無視します。
図2-2に、ポリシー・サーバーで個人についてポリシー決定をする必要がある場合の例を示します。統合を目的とする場合、ポリシー・サーバーは、権限属性として公開されているユーザーの権限が含まれる1つのエントリを認識することが望ましいとされます。これにより、ポリシー・サーバーは次の問合せで権限のアサーションをテストできます。
ldapsearch –b "uid=e027451,ou=People,o=LargeCo" –s base "(priv=XYZ Mgr)"
OneToManyジョイナは、メインのou=Peopleエントリのプロファイル属性に基づいて、1つ以上の権限を1ユーザーと一致させるために使用されます。OneToManyジョイナは、エントリと同じプロファイル値のすべての権限を検索して、それらをエントリとマージします。第2段階の結合ではSimpleジョイナが使用され、SunOne Directoryの組み合されたプロファイルが、ユーザーのActive Directory資格証明とともに使用されます。
Shadowジョイナは、スキーマ拡張機能を必要とするLDAPアダプタまたはデータベース・アダプタなどのソースにエントリを格納する必要があるが、スキーマ拡張機能をビジネスまたは技術的な理由で使用できない場合に使用します。Shadowジョイナを使用すると、ローカル・ストア・アダプタなどの別のストアや、Oracle Internet DirectoryまたはOracle Directory Server Enterprise Edition (旧称はSun(tm) Java System Directory Server)などのextensibleobjectオブジェクト・クラスをサポートする別のLDAPディレクトリの拡張属性を使用できます(現在Microsoft Active Directoryでは、extensibleobjectオブジェクト・クラスはサポートされていません)。
Shadow結合関係は、プライマリ・アダプタのエントリと同じ構造を維持しますが、別のアダプタを使用してシャドウ・エントリを作成することで追加の属性を保持します。Shadow結合関係を使用すると、アプリケーションで企業ディレクトリを使用し、アプリケーション固有の属性を結合ビュー・アダプタのデータ・ストアに格納できます。アプリケーションは、すべての属性を格納するディレクトリと通信していると認識しますが、アプリケーション固有のデータは実際には、Oracle Virtual Directoryにより別のShadowディレクトリに格納されています。Shadow属性が表示されるのは、値の指定された属性が、結合されたエントリDNに追加された後のみです。
Shadowジョイナを使用するには、データを格納するディレクトリでExtensibleEntryオブジェクト・クラスがサポートされ、vdeshadowobjectオブジェクト・クラスが定義されている必要があります。extensibleobjectオブジェクト・クラスは、任意の属性を含み、どのLDAPv3サーバー製品でもサポートされていないオブジェクトを定義します(IETF RFC 2251ではオプションのアイテムです)。ローカル・エントリには1つ以上の属性のみが含まれ、有効なオブジェクト・クラスを形成しない可能性があるため、Shadowジョイナでは、extensibleobjectおよびvdeshadowobjectオブジェクト・クラスを使用してローカル・エントリが格納されます。一般的に、ローカル・ストア・アダプタはローカル・エントリの格納に使用されますが、extensibleobjectオブジェクト・クラスをサポートし、vdeshadowobjectオブジェクト・クラスが定義されているLDAPディレクトリを使用することもできます。
|
注意: Oracle Internet Directoryでは、ExtensibleEntryオブジェクト・クラスがサポートされています。 |
Shadowジョイナは、プライマリ・アダプタのすべてのDNをハッシュにエンコードすることで機能します。ハッシュにより、検索を実行せずに、結合アダプタで結合エントリを見つけられるようになります。Shadowジョイナは、対応するレコードを結合ビュー・アダプタで見つけられないと、自動的に新しいレコードを作成し、指定の属性を結合アダプタに格納します。Shadowジョイナはアプリケーションに対してできるかぎり透過的に稼働し、プライマリ・アダプタのエントリと同期してエントリの作成や名前の変更を処理します。
Shadowジョイナでは、すべてのLDAP操作がサポートされています。LDAP変更操作が行われると、Shadowジョイナはアダプタの格納可能属性ルーティング・パラメータによって示されたパラメータを調査し、Shadow結合アダプタに格納する属性の有無を確認します。そのような属性が存在する場合、Shadowジョイナは、プライマリ・エントリのMD5ハッシュを使用して、ローカル・エントリの特定を試行します。特定されると、適切なLDAP変更操作がローカルで実行されます。ローカル・エントリが検出されない場合、Shadowジョイナは、プライマリDNが変更されている場合に備えて2回目の検索を実行し、プライマリ・キーを使用してエントリを特定します。ローカル・エントリが検出されない場合は、新しいエントリが自動的に作成されます。
図2-3は、Oracle Virtual Directoryと接続するように構成されたCheckPointファイアウォールを示しています。Oracle Virtual Directoryは、CheckPointファイアウォール・スキーマを管理するためにOracle Internet Directoryを使用します。これにより、企業ディレクトリ・スキーマをアプリケーション固有データで拡張することなく、企業エンタープライズ・ディレクトリへのCheckPointファイアウォールの統合が可能になります。かわりに、Oracle Internet Directoryにそれを格納することにより、CheckPointファイアウォール管理を担当するチームがアプリケーション固有データを管理できます。
結合ビュー・アダプタでは、様々な複雑な関係を実装できるJavaベース・プラグイン結合関係もサポートされています。たとえば、結合で複数の段階からなる操作を実行する場合、カスタム結合により、実際のシナリオに適した特別なリカバリ・メカニズムを提供できます。Javaベースのプラグインの詳細は、第4章「Oracle Virtual Directoryのプラグインの概要」を参照してください。
Oracle Virtual Directoryではカスタム・アダプタの作成機能もサポートされています。これには、定義済のAPIによってほとんどすべてのデータ・ソースに接続できるプラグインを使用します。カスタム・アダプタのデプロイの詳細は、「カスタム・アダプタの作成および構成」を参照してください。
この項では、アダプタを使用して仮想ディレクトリを作成する方法を説明する次の例を示します。
図2-4に、ベースがo=YourCompany,c=USで、次のようなメイン・ブランチを持つディレクトリの仮想ディレクトリ構造を示します。
ou=Airius: パートナのLDAPディレクトリを指します。
ou=People: 社内のRDBMSを指します。
ou=Groups: ローカルのOracle Virtual Directoryディレクトリ・ストアに格納されるグループとロールの情報です。
図2-4の仮想ディレクトリには次のアダプタが必要です。
LDAPアダプタ
データベース・アダプタ
ローカル・ストア・アダプタ
次のリストは、仮想ディレクトリを作成するために、図2-5でアダプタがどのように構成されているかを説明します。
アダプタ0: ローカル・ストア・アダプタ
このアダプタは、ディレクトリのベースを形成し、プロキシの対象にならないエントリを保持します。この場合、Groupsの下のディレクトリ・エントリはローカル・ディレクトリに格納されます。
アダプタ1: LDAPアダプタ
このアダプタは、リモートLDAPディレクトリと、仮想ディレクトリ・ツリーにマッピングされるリモート・ベースを指定します。この場合、リモート・サーバーのo=Airius.comの下のすべてのエントリは、仮想ディレクトリでou=Airius,o=YourCompany,c=USとして表されます。
アダプタ2: データベース・アダプタ
このデータベース・アダプタは、2つの表を使用してディレクトリのエントリが形成されることを指定するデータベース接続です。この場合、2つの表の結合問合せによるレコードが、仮想ディレクトリのネームスペースou=People,o=YourCompany,c=USのユーザー・オブジェクトを形成するために使用されます。
図2-5に示されているように、Oracle Virtual Directoryおよびそのアダプタでは、ディレクトリ・ツリーの各部分のソースを様々な場所に求めることができます。仮想ディレクトリ情報ツリー構造を計画するときは、2つのアダプタ・ルートが同じルート・ノードを占有しないようにしてください。ただし、アダプタを別のアダプタの子ノードとして表すことは可能です。
第1章「Oracle Virtual Directoryの概要」の図1-2には、ある企業の全従業員が使用するエンタープライズ・アプリケーションの例が示されています。アプリケーションは、3つの異なるソースのディレクトリ情報にアクセスし、各ソースには異なるユーザーのグループがあります。図2-6と図1-2のトポロジは同じですが、図2-6の右側にある3つのすべてのディレクトリ・ソースには同じユーザー・グループが含まれています。
図2-6では、すべてのユーザーの企業ディレクトリ情報の主なソースが含まれるメインの企業ディレクトリを示しています。たとえば、企業ディレクトリの各ユーザーについては、ユーザー認証のためにMicrosoft Active Directoryの対応するアカウントと一致させる必要があるとします。また、企業データベースで職員関連のアプリケーション情報にアクセスするために、企業ディレクトリの各ユーザーを企業データベースの表エントリに関連付ける必要があります。
図2-6の要件に対応するには、次の4つのアダプタを使用してOracle Virtual Directoryを構成します。
アダプタ0は、ローカル・アプリケーション記憶域用で、ツリーのルート位置を保持します。
アダプタ1はActive Directoryのプロキシとして定義されます。
アダプタ2は、企業LDAPディレクトリのプロキシです。
アダプタ3はデータベース・アダプタで、企業RDBMSの該当するユーザー・レコードにマップされます。
アダプタ4は結合ビュー・アダプタです。この場合、企業ディレクトリのアダプタ2がプライマリ・アダプタとして使用されるため、アダプタ4で表示されるすべてのエントリは、アダプタ2のエントリとまったく同一になります。他に何も定義しない場合、結合ビュー・アダプタはアダプタ2のコピーにすぎません。
アダプタを構成したら、結合関係を定義する必要があります。この場合、Active Directoryに対して1つ、企業RDBMSに対して1つ、合せて2つの結合関係を定義します。Active Directoryの結合では、アダプタ2に対するSimple結合をアダプタ4に定義します。プライマリ・アダプタであるアダプタ1と実際に結合していることに注意してください。
結合を完了するために、Active Directoryのエントリをプライマリ・アダプタに結合する一意の基準を指定します。図2-7に示すように、uid=userprincipalnameを使用します。uidはアダプタ1にあり、userprincipalnameはアダプタ2(Active Directory)にあります。2つ目の結合では、Simple結合を使用してアダプタ3と結合し、uid=useridを使用して一意の一致を取得します。
最後に、プライマリ・アダプタ(アダプタ2)ではなくアダプタ1を認証用に使用するため、bindadapter設定は1とします。これにより結合ビュー・アダプタは、プライマリ・アダプタではなく結合アダプタに対して認証をテストするようになります。
|
注意: ユーザーを複数のRDBMSレコード(たとえば権限表)と一致させる場合は、approle=privのようなOneToMany結合を指定できます。このapproleは、企業ディレクトリの属性です。approle属性は、RDBMSの一連の権限と一致します。この例で結合を実行することで、単純なロールが一連の権限に変換されます。 |
アダプタ4を構成したら、これらの各アダプタのルーティング可視性を内部に設定することで、アダプタ1、2および3をエンド・ユーザーに対して非表示にできます。これにより、ディレクトリのブランチが1つ(ou=People,o=AppView)に見えるようになります。ou=Peopleの下のディレクトリを参照するときは、結合ビュー・アダプタであるアダプタ4を問い合せることになります。結合ビュー・アダプタが問合せを受け取ると、問合せを自動的に変換して、表示されていない他の3つのアダプタに渡します。結果として、アプリケーションに対しては、各ユーザーに1つのエントリしかないように見えます。
図2-8に、個別ディレクトリが4つあるソース・ディレクトリ・ツリー構造を示します。目標は4つの個別ディレクトリすべてを1つの新しいディレクトリ・ツリー設計にまとめることです。Oracle Virtual Directoryで実装できる最も基本的なディレクトリ・ツリー設計には変換機能がないため、4つの個別のディレクトリ・ツリーを含むソース・ディレクトリ構造がOracle Virtual Directory内で有効になり、変換機能を使用しない純粋なディレクトリ・プロキシとして機能します。
図2-9に、o=YourCompany, c=USの子として追加された外部の2つの企業を示します。この例では、アダプタ1とアダプタ2はアダプタ0に相対的なサブツリー・エントリの位置を占めています。また、アダプタ3は別のネームスペースを占めており、管理ネットワーク・サービスを提供するが、他の3つの組織のビジネス・アプリケーションには参加しないサード・パーティの会社を表しています。この場合、ISPディレクトリ・エントリを別にしておくことをお薦めします。
図2-10では、すべてのパートナ・ユーザーがou=Peopleブランチの下に配置されるように再設計されたディレクトリ構造を示しています。アプリケーションの制限のためにこのような要件になることがあります(アプリケーションがou=People, o=YourCompany, c=USの1ベースのユーザーしか認証しない場合など)。YourCompanyの人のエントリはou=Peopleの直下にありますが、パートナのディレクトリはou=Peopleの下の組織単位に含まれることに注意してください。組織単位を配置することで、それらのパートナのユーザー固有のアクセス制御グループやロールの作成が容易になり、ネームスペースの競合が回避されます。ツリーのどのノードも1つのアダプタが占有することに注意してください。
図2-11に、アダプタ0に格納されるエントリとアダプタ1と3のルート・エントリとの間の競合のために2つの問題が生じる例を示します。検索操作時に、Oracle Virtual Directoryはオーバーラップするネームスペースを検索し、すべてのアダプタから一致結果を戻します。ただし、変更操作時には、Oracle Virtual Directoryは、そのエントリからツリー内を下から順に進んで最初に一致したアダプタ内のエントリしか処理しません(この例では、アダプタ0はツリー内で上にあるため、アダプタ1と3のみが処理されます)。
従来は、オーバーラップしたディレクトリ構造は受け入れられませんでしたが、Oracle Virtual Directoryでは、オーバーラップ・ネームスペースの操作の処理方法を制御するルーティング・フィルタがサポートされています。
Oracle Virtual Directoryには、アダプタの構成プロセスを簡略化するアダプタ・テンプレートが用意されています。新規アダプタを作成する場合、新規アダプタ画面には、各アダプタで使用可能なテンプレートが表示される「アダプタ・テンプレート」リストがあります。アダプタ・テンプレートを選択すると、Oracle Directory Services Managerによってアダプタ設定の一部のデフォルト値が自動的に移入されます。これらのデフォルト値は、使用する環境に合せて変更する必要があります。
次の項では、アダプタ・テンプレートをリストして説明します。
デフォルト・テンプレートは、すべてのアダプタ・タイプで使用可能な汎用テンプレートで、1つのベンダーのディレクトリに固有ではありません。デフォルト・テンプレートは、他のテンプレートがニーズに一致しない場合に使用します。
|
注意: 一部のアダプタ・テンプレートでは、Pythonマッピング・スクリプトが使用されます。テンプレートにより、アダプタの情報を使用してマッピング・スクリプトが構成されますが、そのマッピング・スクリプトのデプロイは行われません。マッピング・スクリプトを使用するアダプタ・テンプレートを使用する場合は、アダプタの構成後にOracle Virtual Directoryサーバーにマッピング・スクリプトを明示的にデプロイする必要があります。 |
Active_Directoryテンプレートは、Microsoft Active DirectoryまたはActive Directoryアプリケーション・モードのターゲットに接続し、Active DirectoryオブジェクトをInetOrgPersonオブジェクトにマップしない場合に使用します。
|
注意: Microsoft Active DirectoryまたはActive Directoryアプリケーション・モードのターゲットに接続し、Active DirectoryオブジェクトをInetOrgPersonオブジェクトにマップする場合は、Oracle Access Managerと統合しない場合でもマッパーを使用したOAM/ADアダプタ・テンプレートを使用します。 |
ソースLDAPディレクトリのchangelog情報を適切な書式に標準化する必要がある場合は、Changelog_LDAP-TYPEテンプレートを使用します。Oracle Virtual Directoryには、Microsoft Active Directory (Changelog_ActiveDirectory)、Oracle Internet Directory (Changelog_OID)、およびOracle Directory Server Enterprise Edition (Changelog_SunOne)用のアダプタ・テンプレートが組み込まれています。
各Changelog_LDAP-Typeテンプレートによって、Changelogプラグインがデプロイされます。
|
注意: 表2-1は、Oracle Virtual Directoryリリース11.1.1.4.0では推奨されません。この表に記載されているアダプタ・テンプレートは、Oracle Virtual Directoryリリース11.1.1.4.0では機能しません。 |
Active Directoryを使用するOracle Virtual Directoryとエンタープライズ・ユーザー・セキュリティとの統合には、EUS_ActiveDirectoryテンプレートを使用します。EUS_ActiveDirectoryを使用すると、次のプラグインがデプロイされ、統合が簡単になります。
Objectclass Mapper: Active Directoryで管理できるよう、特定のOracle属性およびオブジェクト・クラスをマッピングします。
Active Directory Password: データベースにディレクトリが登録されている場合には、データベース・パスワードをActive Directoryに格納できます。
EUSActiveDirectory: GUIDなど、特定のActive Directoryの属性を、エンタープライズ・ユーザー・セキュリティで使用できる形式に変換します。
Oracle Internet Directoryを使用するOracle Virtual Directoryとエンタープライズ・ユーザー・セキュリティとの統合には、EUS_OIDテンプレートを使用します。EUS_OIDを使用すると、特定の属性をエンタープライズ・ユーザー・セキュリティで使用可能な一貫性のある形式に変換するEUSOIDプラグインがデプロイされるため、統合が簡単になります。
Oracle Directory Server Enterprise Editionを使用するOracle Virtual Directoryとエンタープライズ・ユーザー・セキュリティとの統合には、EUS_Sunテンプレートを使用します。EUS_Sunを使用すると、次のプラグインがデプロイされ、統合が簡単になります。
Objectclass Mapper: Oracle Directory Server Enterprise Editionで管理できるよう、特定のOracle属性およびオブジェクト・クラスをマッピングします。
EUSSun: GUIDなど、特定のOracle Directory Server Enterprise Editionの属性を、エンタープライズ・ユーザー・セキュリティで使用できる形式に変換します。
Novell eDirectoryを使用するOracle Virtual Directoryとエンタープライズ・ユーザー・セキュリティとの統合には、EUS_eDirectoryテンプレートを使用します。EUS_eDirectoryを使用すると、次のプラグインがデプロイされ、統合が簡単になります。
Objectclass Mapper: eDirectoryで管理できるよう、特定のOracle属性およびオブジェクト・クラスをマッピングします。
EUSeDirectory: 特定のeDirectoryの属性を、エンタープライズ・ユーザー・セキュリティで使用できる形式に変換します。
General_LDAP_Directoryテンプレートは、デフォルト・テンプレートと同じです。
このテンプレートを使用することでその他のアプリケーションにも利点がありますが、Microsoft Active Directoryを使用するOracle Virtual DirectoryとOracle Access Managerの統合には、このテンプレートを使用することをお薦めします。マッパーを使用したOAM/ADアダプタ・テンプレートを使用すると、次のプラグインがデプロイされ、LDAPアダプタとActive Directoryの通信が簡単になります。
Active Directory Ranged Attribute: 範囲指定された属性を1つのリクエストに変換します。範囲指定された属性とは複数値の値がいくつかある属性で、Active Directoryにより複数のリクエストに分割され、クライアントの混乱の原因になります。
ObjectClass Mapper: Active Directory User/GroupオブジェクトをInetOrgPerson/GroupOfUniqueNameオブジェクトにマッピングします。
ActiveDirectory Password: 標準のuserPassword属性をMicrosoftのunicodePWD属性に変換します。また、このアダプタを非SSLのポートを介してActive Directoryに接続させるために、このプラグインで、SSLを使用してActive Directoryサーバーに接続する別のアダプタ・インスタンスにパスワードの更新をルーティングできます(Active DirectoryでSSLを使用するにはLDAPを介したパスワードの変更が必要なため)。アダプタがSSLを使用するように設定されている場合は、プラグイン構成からホスト名を削除します。アダプタがSSLを使用しないように設定されている場合は、プラグインのホスト名を、SSLを使用してActive Directoryに接続されているActive Directoryアダプタの名前に設定します。
Dump Before: プラグインにデータを渡す前に、操作の値をvde.logにダンプするDump Transactionプラグインの一種。
Dump After: プラグインにデータを渡した後に、操作の値をvde.logにダンプするDump Transactionプラグインの一種。
|
注意: マッパーを使用したOAM/ADアダプタ・テンプレートは、スクリプトを使用したOAM/ADアダプタ・テンプレートに似ていますが、スクリプトを使用したOAM/ADアダプタ・テンプレートのように、追加のマッピング・スクリプトをデプロイする必要はありません。 |
Oracle Virtual DirectoryとOracle Access Managerの統合においてのみ、パスワード変更操作でSSLを使用してActive Directoryターゲットに接続するようLDAPアダプタを構成します。デフォルトで、アダプタの可視性のルーティング設定が内部に設定されており、アダプタはクライアントに対して非表示になり、Active Directory Passwordプラグインなどのプラグインを介してのみアクセスできるようになります。
属性名の変更にObjectClass MapperではなくOblixADMapping Pythonマッピング・スクリプトを使用することを除き、マッパーを使用したOAM/ADアダプタ・テンプレートに似ています。スクリプトを使用したOAM/ADアダプタ・テンプレートを使用すると、次のプラグインがデプロイされ、LDAPアダプタとActive Directoryの通信が簡単になります。
Active Directory Ranged Attribute: 範囲指定された属性を1つのリクエストに変換します。範囲指定された属性とは複数値の値がいくつかある属性で、Active Directoryにより複数のリクエストに分割され、クライアントの混乱の原因になります。
ActiveDirectory Password: 標準のuserPassword属性をMicrosoftのunicodePWD属性に変換します。また、このアダプタを非SSLのポートを介してActive Directoryに接続させるために、このプラグインで、SSLを使用してActive Directoryサーバーに接続する別のアダプタ・インスタンスにパスワードの更新をルーティングできます(Active DirectoryでSSLを使用するにはLDAPを介したパスワードの変更が必要なため)。アダプタがSSLを使用するように設定されている場合は、プラグイン構成からホスト名を削除します。アダプタがSSLを使用しないように設定されている場合は、プラグインのホスト名を、SSLを使用してActive Directoryに接続されているActive Directoryアダプタの名前に設定します。
Dump Before: プラグインにデータを渡す前に、操作の値をvde.logにダンプするDump Transactionプラグインの一種。
Dump After: プラグインにデータを渡した後に、操作の値をvde.logにダンプするDump Transactionプラグインの一種。
スクリプトを使用したOAM/ADアダプタ・テンプレートでは、アダプタの情報を使用して、OblixADMappingスクリプトも構成されます。OblixADMappingスクリプトは、Active Directory User/GroupオブジェクトをInetOrgPerson/GroupOfUniqueNameオブジェクトにマッピングするObjectClass Mapperに似ています。
|
注意: スクリプトを使用したOAM/ADアダプタ・テンプレートを使用してアダプタを構成したら、OblixADMappingマッパー・スクリプトをOracle Virtual Directoryサーバーに明示的にデプロイする必要があります。同じ結果を得るために、スクリプトを使用したOAM/ADアダプタ・テンプレートまたはマッパーを使用したOAM/ADアダプタ・テンプレートのいずれかを使用できる場合は、マッパーを使用したOAM/ADアダプタ・テンプレートの使用をお薦めします。これは、スクリプトを使用したOAM/ADアダプタ・テンプレートでは、アダプタの構成後に、OblixADMappingマッパー・スクリプトをOracle Virtual Directoryサーバーに明示的にデプロイする必要があり、マッパーを使用したOAM/ADアダプタ・テンプレートではこの必要がないためです。 |
このテンプレートを使用することでその他のアプリケーションにも利点がありますが、Microsoft Active Directoryアプリケーション・モードを使用するOracle Virtual DirectoryとOracle Access Managerの統合には、このテンプレートを使用することをお薦めします。マッパーを使用したOAM/ADAMアダプタ・テンプレートを使用すると、次のプラグインがデプロイされ、LDAPアダプタとActive Directory Application Modeの通信が簡単になります。
Active Directory Ranged Attribute: 範囲指定された属性を1つのリクエストに変換します。範囲指定された属性とは複数値の値がいくつかある属性で、Active Directoryにより複数のリクエストに分割され、クライアントの混乱の原因になります。
ObjectClass Mapper: Active Directory User/GroupオブジェクトをInetOrgPerson/GroupOfUniqueNameオブジェクトにマッピングします。
ActiveDirectory Password: 標準のuserPassword属性をMicrosoftのunicodePWD属性に変換します。また、このアダプタを非SSLのポートを介してActive Directoryに接続させるために、このプラグインで、SSLを使用してActive Directoryサーバーに接続する別のアダプタ・インスタンスにパスワードの更新をルーティングできます(Active DirectoryでSSLを使用するにはLDAPを介したパスワードの変更が必要なため)。アダプタがSSLを使用するように設定されている場合は、プラグイン構成からホスト名を削除します。アダプタがSSLを使用しないように設定されている場合は、プラグインのホスト名を、SSLを使用してActive Directoryに接続されているActive Directoryアダプタの名前に設定します。
Dump Before: プラグインにデータを渡す前に、操作の値をvde.logにダンプするDump Transactionプラグインの一種。
Dump After: プラグインにデータを渡した後に、操作の値をvde.logにダンプするDump Transactionプラグインの一種。
|
注意: マッパーを使用したOAM/ADAMアダプタ・テンプレートは、スクリプトを使用したOAM/ADAMアダプタ・テンプレートに似ていますが、スクリプトを使用したOAM/ADAMアダプタ・テンプレートのように、追加のマッピング・スクリプトをデプロイする必要はありません。 |
Oracle Virtual DirectoryとOracle Access Managerの統合においてのみ、パスワード変更操作でSSLを使用してActive Directory Application Modeターゲットに接続するようLDAPアダプタを構成します。デフォルトで、アダプタの可視性のルーティング設定が内部に設定されており、アダプタはクライアントに対して非表示になり、Active Directory Passwordプラグインなどのプラグインを介してのみアクセスできるようになります。
属性名の変更にObjectClass MapperではなくOblixADMapping Pythonマッピング・スクリプトを使用することを除き、マッパーを使用したOAM/ADAMアダプタ・テンプレートに似ています。スクリプトを使用したOAM/ADAMアダプタ・テンプレートを使用すると、次のプラグインがデプロイされ、LDAPアダプタとActive Directory Application Modeの通信が簡単になります。
Active Directory Ranged Attribute: 範囲指定された属性を1つのリクエストに変換します。範囲指定された属性とは複数値の値がいくつかある属性で、Active Directoryにより複数のリクエストに分割され、クライアントの混乱の原因になります。
ActiveDirectory Password: 標準のuserPassword属性をMicrosoftのunicodePWD属性に変換します。また、このアダプタを非SSLのポートを介してActive Directoryに接続させるために、このプラグインで、SSLを使用してActive Directoryサーバーに接続する別のアダプタ・インスタンスにパスワードの更新をルーティングできます(Active DirectoryでSSLを使用するにはLDAPを介したパスワードの変更が必要なため)。アダプタがSSLを使用するように設定されている場合は、プラグイン構成からホスト名を削除します。アダプタがSSLを使用しないように設定されている場合は、プラグインのホスト名を、SSLを使用してActive Directoryに接続されているActive Directory Application Modeアダプタの名前に設定します。
Dump Before: プラグインにデータを渡す前に、操作の値をvde.logにダンプするDump Transactionプラグインの一種。
Dump After: プラグインにデータを渡した後に、操作の値をvde.logにダンプするDump Transactionプラグインの一種。
スクリプトを使用したOAM/ADAMアダプタ・テンプレートでは、アダプタの情報を使用して、OblixADMappingスクリプトも構成されます。OblixADMappingスクリプトは、Active Directory User/GroupオブジェクトをInetOrgPerson/GroupOfUniqueNameオブジェクトにマッピングするObjectClass Mapperに似ています。
|
注意: スクリプトを使用したOAM/ADAMアダプタ・テンプレートを使用してアダプタを構成したら、OblixADMappingマッパー・スクリプトをOracle Virtual Directoryサーバーに明示的にデプロイする必要があります。同じ結果を得るために、スクリプトを使用したOAM/ADAMアダプタ・テンプレートまたはマッパーを使用したOAM/ADAMアダプタ・テンプレートのいずれかを使用できる場合は、マッパーを使用したOAM/ADAMアダプタ・テンプレートの使用をお薦めします。これは、スクリプトを使用したOAM/ADAMアダプタ・テンプレートでは、アダプタの構成後に、OblixADMappingマッパー・スクリプトをOracle Virtual Directoryサーバーに明示的にデプロイする必要があり、マッパーを使用したOAM/ADAMアダプタ・テンプレートではこの必要がないためです。 |
Oracle Virtual DirectoryとOracle Access Manager統合のSunOne Directoryターゲットに接続するようLDAPアダプタを構成し、SunOneの属性をOracle Access Managerで使用できるように変換します。マッパーを使用したOAM/SunOneアダプタ・テンプレートを使用すると、次のプラグインがデプロイされ、LDAPアダプタとSunOneの通信が簡単になります。
ObjectClass Mapper: nsaccountlock属性を除外し、ディレクトリ・タイプをSunOneとマークします。
Dump SunOne: プラグイン・アクティビティの出力をvde.logにダンプします。
属性名の変更にObjectClass MapperではなくOblixSunOneMapping Pythonマッピング・スクリプトを使用することを除き、マッパーを使用したOAM/SunOneアダプタ・テンプレートに似ています。最初のインストールおよびフレッシュ・インストールには、スクリプトを使用したOAM/SunOneアダプタ・テンプレートではなく、マッパーを使用したOAM/SunOneアダプタ・テンプレートの使用をお薦めします。
スクリプトを使用したOAM/SunOneアダプタ・テンプレートを使用すると、プラグインおよびマッピング・アクティビティの出力をvde.logにダンプするDump Transactionプラグインがデプロイされ、LDAPアダプタとSunOneの通信が簡単になります。
スクリプトを使用したOAM/SunOneアダプタ・テンプレートでは、アダプタの情報を使用して、OblixSunOneMappingスクリプトも構成されます。OblixSunOneMappingは、nsaccountlock属性を除外し、ディレクトリ・タイプをSunOneとマークするObjectClass Mapperに似ています。
|
注意: スクリプトを使用したOAM/SunOneアダプタ・テンプレートを使用してアダプタを構成したら、OblixSunOneMappingマッパー・スクリプトをOracle Virtual Directoryサーバーに明示的にデプロイする必要があります。同じ結果を得るために、スクリプトを使用したOAM/SunOneアダプタ・テンプレートまたはマッパーを使用したOAM/SunOneアダプタ・テンプレートのいずれかを使用できる場合は、マッパーを使用したOAM/SunOneアダプタ・テンプレートの使用をお薦めします。これは、スクリプトを使用したOAM/SunOneアダプタ・テンプレートでは、アダプタの構成後に、OblixSunOneMappingマッパー・スクリプトをOracle Virtual Directoryサーバーに明示的にデプロイする必要があり、マッパーを使用したOAM/SunOneアダプタ・テンプレートではこの必要がないためです。 |
ONames_LDAP-TYPEアダプタ・テンプレートは、Oracle Virtual DirectoryをOracle Net Servicesと統合している場合にのみ使用します。Oracle Virtual Directoryには、Microsoft Active Directory (ONames_ActiveDirectory)、Oracle Internet Directory (ONames_OID)、およびOracle Directory Server Enterprise Edition (ONames_Sun)用のONamesアダプタ・テンプレートが組み込まれています。
各ONames_LDAP-TYPEテンプレートは、ONamesプラグインのみをデプロイします。このプラグインは、ソースLDAPディレクトリに固有のエントリを削除し、Oracle Virtual DirectoryとOracle Net Servicesの統合を容易にします。
Oracle_Internet_Directoryテンプレートは、Oracle Internet Directory(OID)に接続する際に使用します。
SunOne_Directoryテンプレートは、Netscape、Sun Microsystems、FedoraなどのNetscapeファミリのディレクトリに接続する際に使用します。
User_LDAP-TYPEアダプタ・テンプレートは、Oracle Virtual DirectoryとOracle Identity Managerの統合に使用します。この統合には、Oracle Identity Managerの属性からLDAPディレクトリ・サーバーへのデータ・マッピングが必要です。Oracle Virtual Directoryには、Microsoft Active Directory (User_ActiveDirectory)、Oracle Internet Directory (User_OID)、およびOracle Directory Server Enterprise Edition (User_SunOne)用のアダプタ・テンプレートが組み込まれています。
各User_LDAP-TYPEテンプレートによって、UserManagementプラグインがデプロイされます。
次の項では、ローカル・ストア・アダプタ・テンプレートを説明します。
Local_Storage_Adapterテンプレートは、デフォルト・テンプレートと同じです。
次の項では、データベース・アダプタ・テンプレートを説明します。
Oracle Virtual DirectoryとOracle Access Manager統合のデータベース・ターゲットに接続するようデータベース・アダプタを構成し、ビジネス・ロジックの処理にPythonマッピング・スクリプトを使用します。スクリプトを使用したOAM/DBアダプタ・テンプレートを使用すると、次のプラグインがデプロイされ、データベース・アダプタとOracle Access Managerの通信が簡単になります。
DumpDB1: プラグインおよびマッピングにデータを渡す前に、操作の出力をvde.logにダンプするDump Transactionプラグインの一種。
DumpDB2: プラグインおよびマッピングにデータを渡した後に、操作の出力をvde.logにダンプするDump Transactionプラグインの一種。
スクリプトを使用したOAM/DBアダプタ・テンプレートでは、アダプタの情報を使用して、Oblix_OAMMappingスクリプトも構成されます。Oblix_OAMMappingスクリプトは、エントリの追加前に削除する必要のあるOracle Access Manager固有のオブジェクト・クラスの削除など、Oracle Access Manager統合用のビジネス・ロジックを提供します。
|
注意: スクリプトを使用したOAM/DBアダプタ・テンプレートを使用してアダプタを構成したら、Oblix_OAMMappingマッパー・スクリプトをOracle Virtual Directoryサーバーに明示的にデプロイする必要があります。 |
