| Oracle® Fusion Middleware Oracle Virtual Directory管理者ガイド 11gリリース1 (11.1.1) for Windows B55922-09 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Virtual Directory管理者ガイド 11gリリース1 (11.1.1) for Windows B55922-09 |
|
前 |
次 |
この章では、Oracle Virtual Directory、そのサービスおよびアーキテクチャについて説明します。この章の内容は次のとおりです。
この項では、Oracle Virtual Directoryについて説明します。この項の内容は次のとおりです。
Oracle Virtual Directoryにようこそ。これは、1つ以上のエンタープライズ・データソースを単一のディレクトリに仮想化して抽象的に表示するLDAPバージョン3対応のサービスです。Oracle Virtual Directoryでは、インフラストラクチャまたはアプリケーションを変更することなく、またはその必要性を最小限に抑えながら、LDAP対応のアプリケーションを様々なディレクトリ環境に統合できます。図1-1に示すように、Oracle Virtual DirectoryはWebアプリケーションやポータルなど、一連の各種クライアントをサポートし、ディレクトリ、データベース、およびWebサービスに接続できます。
図1-2は、ある企業の全従業員が使用するエンタープライズ・アプリケーションの例を示しています。アプリケーションは、3つの異なるソースのディレクトリ情報にアクセスし、各ソースには異なるユーザーのグループがあります。これは企業構造に起因しており、多くの組織で一般的です。たとえば、Active Directoryリポジトリには社内の従業員ユーザーのみが含まれ、1つの企業ディレクトリに社内の別の部署またはビジネス・パートナのユーザーが含まれます。さらに、社外契約者などその他のユーザーはリレーショナル・データベースに格納されます。図に示すように、Oracle Virtual Directoryをデプロイして、3つすべてのソースのID情報を統合できます。
Oracle Virtual Directoryでは、データの場所、形式、クライアント・アプリケーションのプロトコルといった複雑さは隠されています。これはスイッチとルーターに基づくTCP/IPインターネット・ネットワーク設計に似ています。スイッチとルーターは、ネットワーク上の様々なアドレス間で接続やプロトコルを確立する方法の詳細を処理します。ルーターを使用すると全世界の情報が自分のローカル・ネットワーク上にあるように見えるのと同様に、Oracle Virtual Directoryを使用することで、多くのディレクトリが1つのローカル・リポジトリのように見えます。
次に、Oracle Virtual Directoryの主な特徴を示します。
製品の特徴
LDAPv2/v3をサポート
DSMLv2/SOAPをサポート
HTTP/XSLTゲートウェイをサポート
低コストの構成および管理
マルチバイト文字のサポートやローカライズされた言語翻訳などのグローバリゼーション機能
TLSv1およびSSLv3のサポートによる暗号化および厳密認証
ディレクトリのプロキシおよびファイアウォールとして機能させるためにデプロイ可能
メモリーおよびハードウェアの最小限に抑えられた要件
Javaがサポートされるすべてのプラットフォームで使用可能
LDAP操作レベルで構成可能なフェイルオーバーおよびインテリジェント・ロード・バランシング
IETFのアクセス制御実装インターネット草案に基づく粒度の細かいアクセス制御
JNDI準拠ディレクトリおよびJDBC準拠データベースへのアクセスのサポート
複数ディレクトリの情報とスキーマの動的マッピング
LDAP問合せのインテリジェント・ルーティング
DoSに対する保護
オーバーラップ・ネームスペースの処理
多様なデプロイに対応する複数タイプのアダプタ
メタディレクトリのような拡張可能な動的結合機能
ローカル・スキーマのサポート
結合ディレクトリ(Active Directoryなど)のクライアントの認証
カスタム拡張機能をサポートする粒度の細かいプラグイン・システム
動的ビューを使用した情報の区分化機能
統合レイヤーとデータ・アクセス・レイヤー両方でWebサービスをネイティブ・サポート
ビジネス機能と利点
実装および管理コストを削減
既存のインフラストラクチャへの投資を最大限に生かし拡大
すべてのID情報を集中管理
セキュリティおよびコンプライアンスを強化
同期の必要なく複数のディレクトリを統合
非ディレクトリ・データに対するLDAPインタフェースを提供
複数のデータ・ストアのデータを結合して仮想エントリを作成
ディレクトリ情報のアプリケーション固有のビューを提供
WebサービスをLDAPとして公開
今日の企業ディレクトリのニーズへの対応という課題を解決するために、Oracle Virtual Directoryには次の機能が備わっています。
データ・フェデレーションおよび変換
Oracle Virtual Directoryは、クライアント・リクエストを処理し、形式(LDAP、RDBMSなど)にかかわらず1つ以上の既存ディレクトリに動的に再ルーティングするディレクトリ・ゲートウェイとして機能することで、利害関係や企業の境界を越えたディレクトリ・サービス・アクセスを可能にします。Oracle Virtual Directoryは仮想ディレクトリ階層(ツリー)をクライアントに示してから、指定されたLDAPまたはRDBMSサーバーにツリーの階層ブランチを割り当てます。Oracle Virtual Directoryが、ディレクトリ間のセキュリティ、プロトコルおよびデータ変換の問題を処理するため、LDAPクライアントは、すべての情報が信頼できる1つのLDAPディレクトリ(Oracle Virtual Directory)から送られたと認識します。
データの所有権
データの所有権は、目立ちませんが仮想化の重要な利点の1つです。通常、組織は、特定の目的を想定してディレクトリを作成します。ある組織が所有するデータに他の組織がアクセスする場合、突き詰めるとデータの所有者およびデータの管理者は誰かという問題が発生します。別の組織が情報を使用および共有する場合には利害関係が発生します。既存データの再利用の価値は広く認識されていますが、データの再利用には整備や管理に関する多くの問題が伴います。多くの組織は、所有していると思っているデータのコピーが他の組織や外部に出ることを非常に心配します。次のような疑問が生じると考えられます。
データの管理者は誰でしょうか。
誰が正確さを保証するのでしょうか。
誰がセキュリティと機密保持を保証するのでしょうか。
情報がコピーされた場合、所有する組織は、他の組織がその情報を使用および管理していることをどのように確認すればよいのでしょうか。
プロキシ・テクノロジを介した仮想化では、データは所属する場所(データの所有者)に留まるため、このような利害にからむ問題の多くは解消されます。所有者はいつでもこのデータに対するアクセスを制限または禁止できます。さらに、所有者は自由にこの情報を改訂することができるため、パートナが常に適切な最新情報を利用することを確認できます。最も重要なのは、所有者が情報を保持することにより、情報の利用を所有者が継続して監視および制御できるということです。
Oracle Virtual Directoryでは、情報をコピーしないことにより、このようなタイプのデータの所有権を実現しています。Oracle Virtual Directoryがアクセスする情報はリアルタイムで取得されるため、情報が最新かつ正確で認可されていることがコンシューマとプロバイダに保証されます。
柔軟性の高いセキュリティ・ドメイン
Oracle Virtual Directoryは、新しいセキュリティ・ドメイン・コンテキストを提供してセキュリティを強化します。新しいビジネス・アプリケーションを複数のビジネス組織にわたってデプロイする場合、複数のディレクトリ・セキュリティ・インフラストラクチャが存在するためにIDとセキュリティが複雑になることがあります。Microsoft Active Directoryの管理者が認識するように、複数のWindowsインフラストラクチャ(フォレストとも呼ばれる)があることは管理とパフォーマンスにとっては長所ですが、フォレスト間の信頼関係を自動的に結ぶ機能やフォレスト間のグローバル・カタログがないことは短所です。
Oracle Virtual Directoryは、きめ細かなアクセス制御を備えた、新しい推移的なセキュリティ・コンテキストを作成します。アクセス制御に関するすべてのIETF規格をサポートし、実装のためのIETFモデルもサポートしています。また、Oracle Virtual Directoryは、プロキシ対象のソース・ディレクトリのセキュリティ制限と適切に統合するように設計されています。これにより、複数層または複数ドメインのセキュリティ概念が実現され、管理者が最大限にセキュリティを制御できます。
Oracle Virtual Directoryは幅広い認証モデルをサポートしています。Oracle Virtual Directoryは、SSL/TLS(StartTLSを含む)および証明書ベースの認証に加えて、プロキシ・サーバー(自身の認証)によるサーバー対サーバーの認証を使用できます。また、ユーザー・コンテキストをソース・ディレクトリに渡すこともできます。Oracle Virtual Directoryとソース・ディレクトリにユーザー・コンテキストを提供することにより、両方のディレクトリはエンド・ユーザーにコンテキスト・セキュリティ制御を提供できます
セキュアなデータ公開
Oracle Virtual Directoryには、次のような複数のデータ・セキュリティ機能があります。
SSL/TLSのサポート: Oracle Virtual Directoryは、LDAPクライアントとのセキュアな通信セッションを実現するSSL/TLS機能を提供します。これによりOracle Virtual Directoryは信頼できる転送メカニズムになり、セキュリティが向上します。
トランザクション・クレンジング: Oracle Virtual Directoryはプロトコル変換エンジンに基づいています。つまり、すべての問合せを分解し、再コンパイルして妥当性を調べてから、信頼できるプロキシ・ディレクトリ・ソースに送ります。これにより、不正な問合せや未認証の問合せからソースLDAPサーバーを保護します。不正なリクエストを消去した後で、Oracle Virtual Directoryは次のような項目に制限を設定する機能により、悪意のある攻撃による重い負荷から限りあるリソースを保護できます。
1接続当たりの最大操作数
最大同時接続数
特定のサブジェクトに対する特定期間の最大合計接続数
特定のアドレスに対する特定期間の最大合計接続数
アクセス制御: Oracle Virtual Directoryは独自のアクセス制御を実装し、内部プロキシ・ディレクトリ・データに対してアクセスをフィルタ処理します。
アプリケーションとディレクトリの統合
ディレクトリが役立つのは、対応するアプリケーションが必要なデータに共通の形式またはスキーマでアクセスできる場合のみです。しかし、典型的なエンタープライズ環境には、様々なスキーマ、ネームスペースおよびデータ設計を備えた無数のディレクトリ・リポジトリが含まれています。
既存のディレクトリ情報にセキュアなブリッジを提供するだけでなく、Oracle Virtual Directoryは、その場でデータを変換するメタディレクトリと同様の機能を提供します。この機能により、管理者は、異なる組織やディレクトリ・インフラストラクチャで見つかったデータの違いを簡単に標準化することができます。この結果として得られる仮想ディレクトリ・ビューには、アプリケーションが実行するために必要なすべてのディレクトリ情報が含まれます。大幅な変更や統合テクノロジをアプリケーションに組み込む必要はありません。
柔軟性の高いデプロイ・オプション
Oracle Virtual Directoryには柔軟性の高いデプロイ・オプションがあり、開発者やビジネス・アプリケーション開発者が、開発済市販アプリケーションに埋め込むことができます。また、Oracle Virtual Directoryは、企業のIT部門が、共有ディレクトリ・サービス分散ネットワークとしてデプロイすることもできます。
高可用性のサポート
Oracle Virtual Directoryには、次のような複数の高可用性機能があります。
フォルト・トレランスとフェイルオーバー: Oracle Virtual Directoryはフォルト・トレランスを次の2つの方法で提供します。
フォルト・トレラント構成
フォルト・トレラント・プロキシ・ソースへのフローの管理
構成ファイルをコピーするだけ、または構成ファイルも共有することにより、複数のOracle Virtual Directoryを迅速にデプロイできます。Oracle Virtual DirectoryをラウンドロビンDNS、リダイレクタまたはクラスタ・テクノロジと組み合せると、完璧なフォルト・トレラント・ソリューションが提供されます。
プロキシ設定された各ディレクトリ・ソースについて、特定のソースの複数のホスト(レプリカ)にアクセスするようにOracle Virtual Directoryを構成できます。ホスト間のフェイルオーバーと負荷分散もインテリジェントに実行されます。柔軟な構成オプションを使用して、管理者は特定のレプリカ・ノードに与える負荷の割合を制御したり、特定のホストを読取り専用レプリカか読取り/書込みサーバー(マスター)かに指定することができます。これにより、読取り専用レプリカに書込もうとすることから生じる不要な参照を回避できます。
ロード・バランシング: Oracle Virtual Directoryには強力なロード・バランシング機能が設計されています。これにより、プロキシLDAPディレクトリ・ソース間で負荷を分散して障害を管理することができます。
Oracle Virtual Directoryの仮想ディレクトリ・ツリー機能により、大容量のディレクトリ情報のセットを複数の個別ディレクトリ・サーバーに細分化することができます。また、独立したディレクトリ・ツリー・ブランチを結合することで、分割したデータ・セットが再び結合して1つの仮想ツリーに戻されます。
特定のソースに複数のLDAPサーバーがある場合は、Oracle Virtual Directory LDAPアダプタにより、自動的にこれらのサーバーのロード・バランシングおよびフェイルオーバーが行われます。このロード・バランシングおよびフェイルオーバーは、クライアントに対して透過的に行われるため、Oracle Virtual Directoryに接続しているクライアントにハードウェアを追加する必要も、変更を行う必要もありません。
データベース・アダプタでは、基礎となるJDBCドライバにこの機能がある場合に、ロード・バランシングおよびフェイルオーバーがサポートされます。また、Oracle Virtual DirectoryはOracle Real Application Clustersでの使用が動作保証されています。
Oracle Virtual Directoryのルーティングにも、ロード・バランシングの機能があります。ルーティングでは、最適な検索ターゲットを決定するために、検索フィルタを検索ベースに追加することができます。このロード・バランシング方法では、Oracle Virtual Directoryは問合せを適切な仮想ディレクトリ・ソースに自動的にルーティングし、数百万に及ぶディレクトリ・エントリの処理が可能になります。
|
注意: Oracle Virtual Directoryの値は仮想化およびプロキシ・サービス用で、ディレクトリ・ストア用ではありません。可用性の高いディレクトリ格納システムが必要な場合には、Oracle Internet Directoryを使用することをお薦めします。 |
カスタムApplication Program Interface
Oracle Virtual Directoryでは、次に示す3つの主要な機能に拡張性があり、顧客およびコンサルタントは、特定のビジネスまたは技術統合のニーズに合うようにOracle Virtual Directoryの機能を拡張できます。
Oracle Virtual Directoryプラグイン: Oracle Virtual Directoryは、Javaサーブレット・フィルタをモデルとする柔軟性の高いプラグイン・フレームワークを提供します。プラグインを使用して、カスタム・ロジックをトランザクションの一部として提供することや、カスタム・データ・ソースに接続することができます。プラグインは、グローバルに挿入することも特定のアダプタのみに挿入することも可能です。プラグインの順序は変更でき、特定のタイプのトランザクションに対しては分離することもできます。Oracle Virtual Directoryの管理ツールでは、新しいプラグインを作成するためのウィザードやすぐに使用できるサンプルが提供されます。
カスタム・ジョイナ: Oracle Virtual Directoryの結合ビュー・アダプタは、ジョイナと呼ばれる拡張可能なモデルに基づいています。カスタム・ジョイナを開発して、様々なジョイナの動作を提供できます。ジョイナは、マッピング、結合、ハンドラ・イベントの前処理および後処理などの機能を提供します。単純なエントリ・レベルの結合を提供するカスタム・ジョイナを作成することや、ジョイナを拡張して、複雑な結合ロジック、トランザクション処理およびロールバック機能を提供することが可能です。
Webゲートウェイ: Oracle Virtual Directoryにはカスタマイズ可能なDSML/XSLTベースのゲートウェイが組み込まれています。これにより、Apache Webサーバー・モデルに基づく基本的なWebサーバー・サポートが提供され、静的なHTMLおよびXSLTレンダリング・コンテンツがサポートされます。このゲートウェイにはディレクトリ対応インタフェースが組み込まれており、問合せ操作および変更操作が可能です。Webサーバー・セキュリティによって、このインタフェースに基づくカスタム委任管理アプリケーションの開発が可能になります。
低コスト、高価値のソリューション
従来のディレクトリ統合ソリューションは、複雑なLDAPプロビジョニングおよびレプリケーション・スキームが必要であり、同期化を実行することも必要です。このような新しいディレクトリも、維持および管理が必要な追加のディレクトリ・ソースになります。
軽量のリアルタイム・サービスであるOracle Virtual Directoryは、同期化や複製は行わずに既存のディレクトリ・インフラストラクチャを再利用することで効率を向上します。Oracle Virtual Directoryは、既存の企業ディレクトリの能力を拡張し、その価値を十分に活用します。
次の項では、Oracle Virtual Directoryのアーキテクチャおよびトポロジについて説明します。
Oracle Virtual Directoryのアーキテクチャ
Oracle Virtual DirectoryサーバーはJavaで記述されており、図1-3に示すように、内部は複数のレイヤーに分かれています。これらのレイヤーは論理レイヤーであり、管理者やクライアントにとって、Oracle Virtual Directoryは単一の完全なサービスです。
1つ目のレイヤーは、ソケット・レベルのプロトコルが通信するOracle Virtual Directoryのリスナー・レイヤーです。Oracle Virtual Directoryには、LDAPとHTTPの2種類のリスナーがあります。どちらのリスナーでも、基本プロトコルの他にSSL/TLSがサポートされています。LDAPレイヤーには、LDAP-SASLをサポートしてデジタル証明認証に対応する機能があります。
リスナーは、検索や更新など、実行するアクションを決定するための処理を行うワーカー・スレッドにリクエストを渡します。これがLDAPあるいはDSMLリクエストのどちらの場合でも、Oracle Virtual Directoryには内部的に操作は同一に見えます。操作が決定されると、最初のレベルのセキュリティ・チェックが行われます。このチェックでは、リクエストがDoSポリシーやインバウンドのOracle Virtual Directoryレベルのアクセス制御に違反していないことが確認されます。
リクエストがインバウンドのセキュリティ要件を満たす場合、次のステップでグローバル・レベルのマッピングおよびプラグインが起動します。マッピングとプラグインには、属性の名前や値の変更など、操作を変更する機能があります。構成されたグローバル・プラグインが起動されたら、Oracle Virtual Directoryにより、リクエストを処理するアダプタが決定されます。この決定は、操作中に提供される情報に基づいて行われます。
使用されるプライマリ情報は、操作のDNです。つまり、検索における検索ベース、またはバインドや追加など、その他すべてのLDAP操作におけるエントリのDNです。Oracle Virtual Directoryは、DNを参照し、そのDNの操作をサポートできる可能性のあるアダプタを決定します。これが可能なのは、各アダプタ構成に、それが関与するLDAPネームスペースが示されているためです。複数のアダプタが受信DNネームスペースをサポートできる場合(検索のベースがdc=oracle,dc=comなど、ディレクトリ・ネームスペースのルートである場合など)、Oracle Virtual Directoryは、そのリクエストを処理できる選択された各アダプタで操作を実行します。優先順位の順序は、優先度、属性またはサポートされるLDAP検索フィルタに基づいて構成できます。
Oracle Virtual Directoryによりアダプタが選択されると、次にインバウンドのアダプタ・レベルのプラグインが起動されます。このプラグインは、特定のアダプタのみでしか動作しない点を除けばグローバル・プラグインに似ています。いずれかのプラグインが起動されると、アダプタはOracle Virtual Directoryのリクエストを、その特定のアダプタ・レベルのプロトコルへマッピングする操作に変換します。LDAPアダプタの場合は、変換がほとんど行われないことが多く、受信DNをその実際のネームスペースへマッピングする値に変換するだけです。たとえば、受信する検索がou=staff,dc=oracle,dc=comの場合、これはou=hr,o=oraclecorpにマッピングされます。ただし、データベース・アダプタを使用するJDBCなどのその他のアダプタの場合、リクエストはSQLコールに変換されます。また、カスタム・アダプタの場合は、Webサービス・コールなどの独自のプロトコルに一致するメソッドに変更されます。
操作が実行されると、結果は逆の順序でクライアントへ戻ります。非検索操作では、通常はこれ以上の処理は行われません。データが戻される検索操作では、データ上でプラグイン(任意)およびアクセス制御が処理されます。Oracle Virtual Directoryアクセス制御は、データに伴う既存のすべてのアクセス制御とともに動作し、そのかわりではなく、追加のアクセス制御として機能するように設計されています。
最後に、リスナー・レベルは、データがLDAPやDSMLエントリなどの正しい形式でクライアントに戻されたことを確認します。
Oracle Directory Services Manager
11gリリース1(11.1.1)では、Oracle Virtual DirectoryおよびOracle Internet Directoryに、Oracle Directory Services Managerという統合されたグラフィカル・ユーザー・インタフェース(GUI)があります。Oracle Directory Services Managerを使用すると、Webベースのフォームとテンプレートを使用できるため、Oracle Virtual DirectoryとOracle Internet Directoryの管理および構成が簡略化されます。
|
注意: Oracle Directory Services Managerを使用するとき、Oracle Directory Services ManagerおよびOracle Virtual Directoryサーバーが同じJDKメジャー・バージョンであること、または、Oracle Virtual DirectoryがOracle Directory Services Managerよりも上位のJavaバージョンを使用していることを確認する必要があります。 |
このリリースの時点では、Oracle Directory Services Managerを構成してシングル・サインオン(SSO)を使用できます。SSOを使用するようにOracle Directory Services Managerを構成すると、SSOサーバーによって認証済のユーザーがSSO対応ディレクトリにエントリを持っている場合、ユーザーはログインせずにそのディレクトリに接続できるようになります。
詳細は、『Oracle Directory Services Managerの開始』を参照してください。
Fusion Middleware Control
11gリリース1(11.1.1)では、Oracle Enterprise Manager Fusion Middleware Controlから、Oracle Virtual Directoryの多くの機能を構成します。このコンソールを使用すると、1つのユーザー・インタフェースからすべてのOracle製品を構成および管理できます。
Oracle Enterprise Manager Fusion Middleware Controlを使用して、Oracle Virtual Directory Serverおよび関連するコンポーネントとアクティビティを監視できます。Oracle Enterprise Manager Fusion Middleware Controlにより、インストール時またはその後の構成で指定するホスト名およびポートが収集されます。リソース検出サービス(RDS)によりサーバー・インスタンスと関連するコンポーネントが識別され、これらのコンポーネントに関する情報がOracle Enterprise Manager Fusion Middleware Controlに送信されます。Oracle Enterprise Manager Fusion Middleware Controlは、ネットワークのノードが停止した際の検出や、追加のノードがインストールされ、Oracle Universal Installerから構成されたかどうかの検出をRDSに依存しています。
監視機能を使用して、合計ログイン、成功したログインと失敗したログイン、平均ログイン時間、リクエスト待機時間、LDAP接続など、システム・アクティビティやパフォーマンスを把握できます。
次に、監視できる項目を示します。
メトリック: システムの状態を監視
一般: 負荷、パフォーマンス、セキュリティ、ログイン、CPU使用率、およびその他のデータの高水準のロールアップ
パフォーマンス: ディレクトリ・サーバーおよびそのホストの主要なメトリック
レポート: 操作の成功および失敗に関するデータ
トポロジ: Oracle HTTP Serverインスタンス、ディレクトリ・サーバー・インスタンス、シングル・サインオン・サーバー、関連するデータベースなどの情報
Oracle Fusion Middlewareは、Java EEおよび開発者ツールから、統合サービス、ビジネス・インテリジェンス、コラボレーションまで、幅広いツールとサービスに対応する、標準ベースのソフトウェア製品の集合体です。Oracle Fusion Middlewareは、開発、デプロイ、管理に完全なサポートを提供します。
Oracle Virtual Directoryは、スタンドアロンJava 2 Standard Edition(J2SE)プロセスとして、Oracle Fusion Middlewareの一部を構成しています。Oracle Virtual Directoryは、Oracle Fusion Middlewareフレームワークの様々な側面を活用し、次の要素とも統合しています。
共通監査フレームワーク
共通ロギング・フレームワーク
資格証明ストア・フレームワーク
Oracle Enterprise Manager Fusion Middleware Control
次に、Oracle Virtual Directoryに関連するOracle Fusion Middlewareの概念と用語を説明します。
WebLogic Server管理ドメインは、論理的に関連するJavaコンポーネントのグループです。WebLogic Serverドメインには、ドメイン内のすべてのリソースの構成および管理の中心である管理サーバーと呼ばれる特別なWebLogic Serverインスタンスが含まれています。
Oracle WebLogic Serverドメインは、Oracleインスタンスのピアです。両方とも、それぞれのOracleホーム以外に特別な構成を保持します。
WebLogic Serverホームには、WebLogic Serverをホストするために必要なインストール済ファイルが含まれます。WebLogic Serverホーム・ディレクトリは、Oracleホーム・ディレクトリのピアで、ミドルウェア・ホームのディレクトリ構造内に配置されます。
Oracleインスタンスには、Oracle Virtual Directoryなどの1つまたは複数のシステム・コンポーネントが含まれます。Oracleインスタンスのシステム・コンポーネントは、同じコンピュータ内に存在する必要があります。Oracleインスタンス・ディレクトリは、構成ファイル、ログ・ファイル、一時ファイルなどの更新可能ファイルを保持します。
Oracleホームには、特定の製品をホストするために必要なインストール済ファイルが含まれています。たとえば、Oracle Virtual Directoryホームは、Oracle Virtual Directoryバイナリ・ファイルおよびライブラリ・ファイルが含まれるディレクトリを保持します。Oracleホームは、ミドルウェア・ホームのディレクトリ構造内に配置されます。各Oracleホームは、複数のOracleインスタンスまたはOracle WebLogic Serverドメインと関連付けることができます。
Middlewareホームは、Oracle WebLogic Serverホーム、および場合によっては1つ以上のOracleホームで構成されています。ミドルウェア・ホームは、ローカル・ファイルシステム、またはNFSを介してアクセスできるリモート共有ディスクに配置することができます。
|
関連項目: Oracle Fusion Middlewareの詳細は、『管理者ガイド』を参照してください。 |
オラクル社は、次のように幅広いディレクトリ・サービス・ソリューションを提供する唯一のベンダーです。
Oracle Internet Directoryによるスケーラブルなローカルストア・ベースのディレクトリ・サーバー
Directory Integration Platformによるメタディレクトリ
Oracle Virtual Directoryによるディレクトリの仮想化
Oracle Internet Directoryは、LDAPサーバーにデータを格納する必要があるが、既存のディレクトリ・サーバーがない場合に使用します。Directory Integration Platformは、データベースまたは他のディレクトリ情報をOracle Internet Directoryと同期化する必要がある場合に使用します。また、Directory Integration Platformを使用して、Oracle Internet Directoryと特定のOracleアプリケーション(Oracle eBusiness Suiteなど)の間でデータを同期化することもできます。Oracle Virtual Directoryを使用すると、リアルタイムに直接データ・アクセスを介して、異機種ソースのデータを1つのディレクトリ・サービスに集約できます。
Oracle Directory Services製品は、それぞれ単独で使用することも、組み合せて使用することもできます。たとえば、Oracle Virtual DirectoryをOracle Internet Directoryと一緒に使用すると、Oracle Internet Directoryデータに対するDSMLインタフェースを提供できます。Oracle Internet Directoryを使用すると、既存のディレクトリを利用できない場合にOracle Virtual Directoryを使用して管理する情報用のスケーラブルな記憶域を提供できます。また、Directory Integration PlatformとOracle Internet DirectoryでOracle Virtual Directoryを使用すると、既存の仮想データストアにフォルト・トレランス・サポートを追加することができます。たとえば、なんらかの理由でプライマリ企業ディレクトリが使用不可になった場合に、Oracle Virtual DirectoryはOracle Internet Directoryストアを使用できます。
この項では、ID管理構成へのデプロイ時に、従来のディレクトリ・サーバーや企業ディレクトリで発生する問題の多くについて説明します。また、Oracle Virtual Directoryでは、それらの問題がどのように解決されるかについても説明します。
概要: 従来のディレクトリ・サーバーのデメリット
現在のディレクトリ・サーバーは、特殊なデータベースとして設計されたものであり、これらのみでは、関連するすべてのアプリケーションを1つの企業ディレクトリに接続するために必要なツールを企業に提供できません。わずかな例外を除き、1つの企業ディレクトリしかない企業はありません。
アナリストによれば、ほとんどの企業に社内全体で使用されているディレクトリが複数(5つ以上)あります。複数のビジネス・パートナが使用するアプリケーションにデータを提供する目的がある場合、ディレクトリの数は、少なくともアプリケーションを使用するビジネス・パートナの分のみ増加します。オラクル社では、ほとんどの企業が社内および社外に複数層のディレクトリ・サービスを必要としていると考えています。Oracle Virtual Directoryは、データを重複させず、大規模なレプリケート・インフラストラクチャのコストを発生することもないため、この要件を実現する最適な方法の1つです。
典型的なディレクトリおよびデータベース・テクノロジでは、独立した事業単位、部署およびパートナから企業が構成されているときに発生する問題を解決することができません。現在のディレクトリ・サーバー・テクノロジでは、企業は1つの管理データ・インフラストラクチャを構築することを強制されます。これには、次の項目について、利害がからんだ長い話合いが必要になります。
ディレクトリ・インフラストラクチャにどのデータを含めるか。
誰が管理するか。
誰が費用を負担するか。
ディレクトリのコストを誰が負担するか、またディレクトリを誰が管理するかという問題が、比較的単純なデータベース・テクノロジのデプロイを成功させるための重大な要因になります。図1-4に示すように、いくつものディレクトリ・ソースが様々な形式で様々な場所に設置されていますが、所有者も多岐にわたります。また、このような従来の企業ディレクトリには、リレーショナル・データベースや電子メール・システムといったその他のディレクトリが追加されます。
データの配置に伴う問題は、Lotus DominoやMicrosoft ExchangeのようなLDAP対応アプリケーションが加わるとさらに複雑になります。このようなアプリケーションに含まれるディレクトリ情報は、スキーマの要件が異なるため、既存の企業ディレクトリにそのまま統合することはできません。
開発者は、これまでは特定の目的のためのデータベースの作成において成功を収めてきました。これは、ビジネス主導のアプリケーションに出資する個々のビジネス・マネージャが意思決定を行っているためです。現在、B2B Webサービスおよびビジネス間アプリケーションという新しいトレンドによって、ディレクトリ・サービスおよびセキュリティ・インフラストラクチャ戦略を作成するときに外部パートナのデータ・ソースを考慮する必要があることが示されています。
ディレクトリ・サービス統合レイヤーは、次のような現実的な問題への対応に必要です。
分散セキュリティ: 可用性および検証
ルーティング: 様々なデータの取得方法
統合: 様々な形式の処理方法
データ・レベルのフェデレーション: 信頼できるディレクトリのマージ
Oracle Virtual Directoryはこのような課題に対するオラクル社の答えです。
次の項では、従来のディレクトリ・サーバーで発生する共通の問題や、Oracle Virtual Directoryを使用してそれらの問題をどのように解決できるかを詳細に説明します。
レプリケーションの遅延
多くの場合、ディレクトリ・サービスは、長期にわたって1つの1次ノードまたはマスター・ノードと複数のレプリケーション・ノードを使用してデプロイされます。その間、ディレクトリの複数の階層を開発して、リージョン内でのレプリケーションを促進し、リージョン・ディレクトリ・ファームをサポートしていることがあります。
時間の経過につれてレプリケーションの速度が低下し、ディレクトリ・レプリカ・サーバーの情報が古いものになってしまいます。レプリケーションの速度低下の主な原因は、検索する索引の管理にあります。多くの場合、索引をみなおして数を最小限に減らすことにより、既存のインフラストラクチャの使用期間を延ばすことが可能です。
ただし、ある時点で、ディレクトリの索引付けの要求が、個々のサーバーが変更に追い付いてレプリケートできる能力を上回ります。代替策として、レプリカを目的別またはサービスクラス別のノードに分割することを検討してください。たとえば、1組のレプリカを、ユーザー検索とポリシー・サーバー・リクエストの処理専用とします。もう1組をホワイト・ページまたは電子メール検索リクエストの処理専用にします。その他のサーバーは特定のアプリケーションのニーズに合せてチューニングします。
図1-5では、索引付けの戦略が調整され、サービスクラスのレプリカを作成してレプリケーションを拡張できるようにしています。各サービスクラスは、特定のアプリケーション・クライアント用に設計された一連のディレクトリ・レプリカを定義します。
この場合、Oracle Virtual Directoryはマスター・サーバーの場所を自動的に認識し、変更されたトラフィックをそれに直接ルーティングして、不必要なディレクトリ参照操作を回避します。次の課題は、サービスクラスに基づいた正しい検索に対してアプリケーションを正しいレプリカにルーティングする方法です。
容易な方法の1つは、ディレクトリ・レプリカをアプリケーションに直接割り当てることです。ただし、アプリケーションは、特定のディレクトリ・レプリカで構成できる内容を上回る多様な検索を使用することがあるため、この戦略は機能しない場合があります。かわりに、Oracle Virtual Directory仮想ディレクトリのルーティングの組込みフィルタと除外フィルタを使用して、各検索リクエストを自動的にルーティングすることができます。これらのフィルタを使用して、各プロキシ・ノードが実行できる操作、および実行できない操作を管理者が決定できます。
図1-6は、ユーザー識別名を見つけるためにアプリケーションがUIDを検索する典型的なリクエストを示しています。Oracle Virtual Directoryは検索フィルタを認識し、リクエストを適切なディレクトリ・レプリカにルーティングします。Oracle Virtual Directoryは複数のノードから選択することができ、ノード間のロード・バランシングを提供することに注意してください。これにより、複数のノードに負荷を分散でき、1つのノードに依存する必要がないためフォルト・トレランスを保証できます。
様々な検索操作(ホワイト・ページなど)またはサービスクラスの場合、Oracle Virtual Directoryは代替のディレクトリ・レプリカにルーティングできます。
どのフィルタも一致しなかった場合は、デフォルトのサーバーを指定できます。このサーバーは、低パフォーマンス・サーバーとして設定され、多目的の索引付けが行われているためにレプリケーションが遅れることがあります。
どの場合も、ユーザーが意識するのは単一のOracle Virtual Directoryのみです。実際は、フォルト・トレランスとサーバーの負荷要件に応じて同一構成の複数のOracle Virtual Directoryがデプロイされます。Oracle Virtual Directoryはデータを保持しないため、アーキテクチャは完全に並列であり、無限に拡張することができます。たとえば、必要であればアプリケーション・クライアントごとに1組のサーバーをデプロイできます。各サーバーがデータを保持せず(つまりバックアップが不要)、単純にルーターとして機能するため、インフラストラクチャ全体には各サーバーによって最小限の管理コストが加えられるだけです。
トランザクション・フェイルオーバー
多くの企業は、すでにフォルト・トレラント・インフラストラクチャをデプロイし、使用可能なディレクトリ・サーバー・ノードにLDAPトラフィックをルーティングするために、F5 BigIPなどのデバイスを使用しています。LDAPではアトミックな単一ユニット・トランザクションが提供されるため、多くの場合、アプリケーションがトランザクション障害を処理できるとみなされます。LDAP操作が失敗した場合は、アプリケーションが認識して再接続と再試行を行うと常に想定されていました。サービス・アーキテクトにとっては、これによって多くの問題が発生していました。一部のアプリケーションが無効なトランザクションを複数のディレクトリ・サーバーで繰り返したり、アプリケーションで障害が発生して再試行が必要なことを認識しないためです。
Oracle Virtual Directoryは、アプリケーションの負荷を複数のディレクトリ・サーバーに分散するために設計されたインテリジェント接続プーリング・メカニズムを利用して、このような問題に対処します。接続プーリングは個々のトランザクションを複数のサーバーに分散するため、Oracle Virtual Directoryは、トランザクションが特定のノードでタイムアウトになるか失敗したときに認識し、その操作を別のノードに送ることができます。Oracle Virtual Directoryは、問題がデータ障害(クライアントに戻される)かサービス障害かを判別します。サービス障害が発生した場合、Oracle Virtual Directoryは、使用可能な各サーバーでトランザクションを試行し、すべてのサーバーに試します。障害をクライアントに戻すのはその後です。
保護を強化するために、ローカル以外のディレクトリ・ノードをOracle Virtual Directoryのサーバー・リストに追加することでグローバル・フェイルオーバーを構成できます。このように構成すると、LDAPアダプタのLDAPサーバー構成でこれらの非ローカル・ノードには負荷パーセンテージとして0が割り当てられます。これにより、Oracle Virtual Directoryは、他のローカル・ノードを使用できない場合のみこれらのノードを使用するようになります。これにより、ローカルにトラフィックをルーティングすることができ、必要な場合には他のサイトにトラフィックを送ることも可能です。
接続の占有
多くの大規模ディレクトリ環境では、一部のアプリケーションが接続を占有し、共有しない場合があります。アプリケーションのブートストラップ時に、アプリケーションにディレクトリ・サーバーが割り当てられ(たとえば、F5 BigIPによって)、そのサーバーとの永続接続を確立します。これにより、次のような問題が発生します。
事実上、フォルト・トレランスとロード・バランシングが省略されます。従来のほとんどの方法では、接続に基づいたロード・バランシングとフェイルオーバーが使用されるため、接続がないアプリケーションは過負荷のディレクトリ・サーバーから容易に移動することはできません。
負荷が処理できないほど大きくなります。アプリケーションは1つのディレクトリのみを使用する傾向があるため、負荷要件が、割り当てられるノードの処理能力を超える場合があります。いつまでも接続が放棄されないため、管理システムが負荷を再調整する機会はありません。
仮想ディレクトリ・テクノロジは、トランザクションごとに負荷を分散する接続プーリング・メカニズムを提供することで役立ちます。Oracle Virtual Directoryは、各プロキシ・ディレクトリと最小限の数の接続を維持し、負荷の必要に応じて接続を追加します。Oracle Virtual Directoryは、単一クライアント接続の自動切替えを提供し、その操作を複数のディレクトリ・サーバーに分散します。これにより、1つのディレクトリ・サーバー・ノードが過負荷になることがないため、ディレクトリ・サービスの安定性が高まります。Oracle Virtual Directoryは接続占有クライアントとの間に1つの接続セッションを維持する一方で、インフラストラクチャ内の優良な住人として負荷分散や定期的な接続リフレッシュを行います。
アプリケーション接続の過負荷
接続を行うアプリケーションが多すぎ、TCP/IP接続とLDAPバインド・リクエストが多すぎてディレクトリ・サーバーが過負荷になると、接続占有の問題と正反対の状況が発生します。このとき、多数のディレクトリ・サーバー(LDAPバージョンおよびX.500バージョン)が、システム・リソースの不足または処理スレッドがなくなるために不安定になることがあります。多くのベンチマークによって、同時接続スレッド数が7から10の場合にほとんどのディレクトリ・サーバーがピーク・パフォーマンス・レベルに達することがわかります。この情報は、サーバーがより多くのコールに応答できる能力がある場合でも、サーバーがリクエストの処理よりも接続の確立に時間を割くようになるにつれて、図1-7に示すように、ピーク・スループットは減少することを意味します。
Oracle Virtual Directoryの接続プーリング・メカニズムでは、この問題は解決されません。接続占有クライアントの場合と同様に、Oracle Virtual Directoryは、プールを使用して多数のクライアントで接続を共有し、必要な場合にはユーザー・コンテキストを切り替えるために再バインドを使用します(Oracle Virtual Directoryの資格証明の引渡し設定のモードによって異なります)。Oracle Virtual Directoryは多数のクライアント接続とリクエストを処理し、プロキシ・サーバーとの減少した接続においてトランザクションを多重化します。既存の接続が再利用されるため、プロキシ・サーバーでのリソースの消費量は大幅に減少し、LDAPのトランザクション処理に集中することができます。
データの過負荷
「レプリケーションの遅延」の項で説明されているように、場合によっては、ディレクトリ・レプリケーション・スキームの最適化は、非常に大規模なディレクトリに必要な規模の確保には十分ではありません。このような場合、1000万あるいは1億にもおよぶエントリのディレクトリを作成する機能は、データを細分化して、細分化されたすべてのデータが1つのディレクトリ・ビューとして表示される仮想ビューを作成する機能(いわゆる分割統治の手法)に依存します。
Oracle Virtual Directoryは、このような仮想化を達成するためにいくつかの手段を提供します。最も単純な方法はディレクトリ階層の活用です。データを階層構造に細分化できる場合、各グループが独自の1つ以上のネームスペースを持つ複数のディレクトリ・グループが作成されます。これにより、Oracle Virtual Directoryが識別名を確認して、使用するディレクトリ・グループを判別し、トラフィックをルーティングできます。
たとえば、ある架空の電話会社が市外局番別に顧客を分けていた場合、Oracle Virtual Directoryは、図1-8に示すように市外局番を含む組織単位を確認してトラフィックをルーティングできます。すべての変更とバインドの操作では、トラフィックは識別名のみに基づいてルーティングされます。検索操作では、「レプリケーションの遅延」の項で説明されているように、検索ベースがo=BigCoであることが必要でネームスペース固有にならない場合、ルーティングの組込みフィルタと除外フィルタが使用されて、検索フィルタに基づいてトラフィックが送られます。
すべてのエントリが1つの親の下にある平面的な階層が望ましい場合は、一番左の識別名またはDNコンポーネントである相対識別名(RDN)を解析するか、プリフェッチ操作を使用するかを選択できます。RDNコンポーネントを解析できる場合は、図1-9に示すように、RDNを解析してルーティング決定を行うプラグインの使用によってルーティングが確立されます。
たとえば、DNがnumber=6046331751,ou=Account,o=BigCoという形式の場合、ルーティング・フィルタは、最初の3桁(この場合は604)に基づいて特定のディレクトリ・グループを選択できます。
DNがuid=jdoe,ou=Accounts,o=BigCoという形式の場合、ルーティングはハッシュ表を使用して、aからl、mからrおよびsからzで始まるアカウントがそれぞれ3つのサーバーに分かれていることを判別します。
この場合は、標準ルーティング機能を補足するために、ルーティング・プラグイン・メカニズムを使用できます。このプラグインの目的は、データ分けの基準をユーザーが指定できるようにすることです。理想としては、選択される基準(DNの場合もフィルタとベースの場合にも)がすべてのトランザクションで使用可能であることが必要です。
別の方法はプリフェッチの使用です。データの分割が(少なくともOracle Virtual Directoryにとって)予測不可能な方法で行われた場合、Oracle Virtual Directoryは顧客固有の基準に基づいてディレクトリを検索して、正しいリポジトリを探す必要があります。たとえば、LDAPの変更操作では、変更リポジトリを探す検索を最初に実行する必要があります。バインド、削除および名前変更の操作でも同様の要件があります。LDAPの追加操作では、どのリポジトリが追加リクエストを受け取るかを判別できるように、追加リクエストに十分な情報を含める必要があります。状況によっては、サーバーがインフラストラクチャでエントリを探すために使用する特殊なマスター・ディレクトリによって、パフォーマンスのオーバーヘッドが抑えられます。
結論
図1-10に示すように、Oracle Virtual Directoryは、グローバル・ディレクトリ・サービス・デプロイの様々な局面においてフォルト・トレラント構成で使用できます。Oracle Virtual Directoryは、ロード・バランサとしてサイトのIPルーター(たとえばWebsphere Edge ServerおよびF5 BigIP)とサイトのレプリカ・サーバーの間に配置できます。Oracle Virtual Directoryは、その位置でサーバー間のトランザクション・レベルのロード・バランシングとフォルト・トレランスを提供します。ロード・バランシングに加え、Oracle Virtual Directoryは、リレーショナル・データベース・ソースの情報(JDBC経由)など、インフラストラクチャ・レベルの複数のデータ・ビューを提供できます。
特殊なディレクトリ・ビューまたはグローバル・トランザクション・フェイルオーバー機能を必要とするアプリケーションでは、Oracle Virtual Directoryをミドルウェア・コンポーネントとしてアプリケーション・サーバーに直接デプロイできます。この戦略により、サイトで障害が発生した場合に、アプリケーションが様々なロケーションを切り替えることができます。通常、この構成では、Oracle Virtual Directoryがロード・バランシングを提供するのはローカル・レベルのみですが、ローカル・サービスが失敗した場合のみ他のロケーションのノードに切り替えます。
Oracle Virtual Directoryは柔軟性が高いため、ディレクトリ設計者は、複雑で堅牢なディレクトリ・サービス・インフラストラクチャを開発することができます。統合ツールとしてのOracle Virtual Directoryは開発者を支援し、エンタープライズ・インフラストラクチャを使用する際に最も簡単な方法を活用できるようにします。情報のルーターとしてのOracle Virtual Directoryは迅速にデプロイでき、管理が容易で、非常に低いコストで運用できます。
Oracle Virtual Directoryでは、大規模デプロイを効果的に管理するために必要な機能とパフォーマンスが提供されます。企業が社内全体にわたるデータ問題の解決を模索しているとき、Oracle Virtual Directoryは最も困難な課題に対して複数のソリューションを提供します。
Oracle Virtual Directoryを複数の異なる環境にデプロイして、従来のディレクトリ・ソリューションが抱えている問題を解決できます。図1-11に、イントラネットとエクストラネットの2つの異なる環境にデプロイされたOracle Virtual Directoryの例を示します。
イントラネットでのIDの例
次の手順で、図1-11に表示されているイントラネットの例におけるOracle Virtual Directoryの一連の役割を説明します。
図の左下では、内部エンド・ユーザーがイントラネット・ベースのWebアプリケーションにアクセスしています。アプリケーションには、独自のインフラストラクチャの一部としてポリシー・サーバーが含まれる場合と含まれない場合があります。
エンド・ユーザーがアプリケーションにアクセスする際に、アプリケーションまたはポリシー・サービスにより、ユーザーのIDとパスワードが要求されます。
アプリケーションまたはポリシー・サービスは、LDAPのバインド・リクエストを使用して資格証明を検証するために、LDAPv3を使用してOracle Virtual Directoryにアクセスします。
次にOracle Virtual Directoryは、このリクエストをローカル・ディレクトリ・サーバー・ストアにルーティングし、資格証明を検証します。検証が終わると、Oracle Virtual Directoryは確認した結果をアプリケーションに戻します。
その後のリクエストでは、アプリケーションは、アプリケーションのプロファイルと権限を取得できるように、Oracle Virtual Directoryにユーザーのディレクトリ・エントリを要求します。Oracle Virtual Directoryは透過的な結合を実行して、ローカル・ディレクトリ・サーバーとRDBMSの情報の属性をまとめます。収集が終わると、Oracle Virtual Directoryは結果を1つの仮想エントリにマージして、そのエントリをイントラネット・アプリケーションに戻します。
エクストラネットでのIDの例
次の手順で、図1-11に表示されているエクストラネットの例におけるOracle Virtual Directoryの一連の役割を説明します。
右上では、外部の組織またはビジネス・パートナのエンド・ユーザーがエクストラネット・ベースのWebアプリケーションにアクセスしています。
このアプリケーションが、LDAPバインドを使用してユーザーの資格証明を確認するために、LDAPv3を使用してOracle Virtual Directoryにアクセスします。
Oracle Virtual Directoryは、資格証明が外部ディレクトリにマッピングされることを認識します。Oracle Virtual Directoryは、ビジネス・パートナのところにある外部Oracle Virtual DirectoryにSSL暗号化リンクを使用して接続し、独自の資格証明を使用して事業単位間の問合せを検証します。
ビジネス・パートナのOracle Virtual DirectoryはOracle Virtual Directoryを検証すると、リクエストを認識し、内部のLDAPv3ディレクトリに渡します。
Oracle Virtual Directoryは、適切なビジネス間アクセス制御を適用し、フィルタ結果をディレクトリからOracle Virtual Directoryに戻します。これで、ビジネス・パートナ・ユーザーのパスワードを検証でき、成功または失敗をアプリケーションに戻すことができます。
最後に、イントラネット・アプリケーションの例と同じく、アプリケーションがユーザーのその他の属性をOracle Virtual Directoryに問い合せます。Oracle Virtual Directoryは、ビジネス・パートナ・ディレクトリのクライアント提供情報と企業データベースにローカルに格納されている情報を結び付ける結合を実行します。
例のサマリー
図1-11の例では、複雑なシナリオにそって機能を説明します。Oracle Virtual Directoryは、情報のルーターおよびジョイナとして機能し、アプリケーションまたはセキュリティ・インフラストラクチャのニーズに合せて複数のセキュアなソースの情報を仲介します。Oracle Virtual Directoryは1つのイントラネット内の情報をまとめるだけでなく、ビジネス・パートナの情報を活用することもできます。ビジネス・パートナがエクストラネット・アプリケーションを使用するときに、ホスト・ビジネスのディレクトリでのプロビジョニングや管理が必要なくなるため、この機能は特に重要です。ビジネス・パートナ・ユーザーは、自身のローカル・ディレクトリでリアル・タイムに認証されます。
また、Oracle Virtual DirectoryはLDAPプロキシ・サーバーとしても重要な役割を果します。オプションとしては、Oracle Virtual Directoryをビジネス・パートナのディレクトリのファイアウォールとして使用することもできます。Oracle Virtual Directoryは、内部ディレクトリ情報への外部からのアクセスを適切に承認および認可します。図の右下では、Oracle Virtual Directory独自のルーティング機能により、複数の内部ディレクトリまたはWindows Active Directoryフォレストにルーティングして、クライアントから情報を保護する様子が示されています。ファイアウォールとしては、Oracle Virtual Directoryは情報へのアクセスを管理および制限して、承認された外部ユーザーがアクセスできるようにします。仮想ディレクトリ・コンポーネントとしては、Oracle Virtual Directoryは、データを単純化および再構成して公開し、ビジネス・パートナが使用できるようにします。
Oracle Virtual Directoryを使用すると、すべてのソース・ディレクトリ・ツリーに接続でき、そのツリーを新しい仮想ツリーにマッピングできます。たとえば、ソース・ディレクトリのエントリの識別名(DN)が次の場合について考えます。
cn=Jim Smith,ou=People,o=Division B, c=UK
このソース・ディレクトリ・エントリは、次のようにマッピングできます。
cn=Jim Smith,ou=People,ou=Division B, ou=People,o=AppView
この場合、Oracle Virtual Directoryは、o=Division B, c=UKの下のすべてのエントリをou=Division B, ou=People, o=AppViewにマッピングします。Oracle Virtual Directoryは、その場で変換を実行して、Division Bのユーザーがアプリケーション固有ディレクトリに含まれるようにします。
図1-12に、アプリケーション固有のローカル・ディレクトリ・ブランチを示します。このツリーのルートはo=AppViewです。このブランチの下にローカル情報(アプリケーション・アクセス制御またはロール)を格納できます(たとえば、cn=User Group,ou=Groups,o=AppView)。
アプリケーションにアーキテクチャの制限があり、共通のpeopleブランチの下のユーザーしか検索できない場合があります。アプリケーションの要件に合せて、設計の目的を変更し、新しいディレクトリ設計をou=Peopleブランチの下のすべてのディレクトリ・ソースにマッピングするようにできます。図1-13に、これがどのように反映されるかを示します。
図1-13では、Oracle Virtual Directoryは4つのアダプタを使用するように構成されています。
アダプタ0は、ディレクトリ・ツリーのルートを形成し、o=AppViewにマッピングされます。このアダプタは、ツリーの仮想ルート、およびアクセス制御グループなどのローカル・エントリを保持します。
アダプタ1から3は、各ディレクトリ・ソースを新しいアプリケーション・ツリーのou=Peopleブランチの下の位置にマッピングします。
