| Oracle® Fusion Middleware Oracle Unified Directory管理者ガイド 11g リリース2 (11.1.2) B72794-04 |
|
 前 |
 次 |
Oracle Unified Directoryは、ストレージ、同期およびプロキシ機能を統合して、ビジネス・アプリケーションが動作するための重要な識別情報の管理を支援する、次世代の統合ディレクトリ・ソリューションです。これらの機能により、エンタープライズ・アーキテクチャの進化するニーズを満たすことができます。
この章では、Oracle Unified Directoryの基本コンポーネントの概念およびOracle Unified Directoryのアーキテクチャについて説明します。この章では、次のトピックを取り扱います:
Oracle Unified Directoryには、ネットワーク・グループ、ワークフローおよびワークフロー要素の3つの主要コンポーネントが統合されています。この項では、各コンポーネントの概要について説明します。内容は次のとおりです:
ネットワーク・グループは、Oracle Unified Directoryで処理するすべてのクライアント・リクエストのエントリ・ポイントです。
ネットワーク・グループは、クライアントの相互作用をすべて処理し、次の項目に基づいてローカル・バックエンド・ワークフローまたはプロキシ・ワークフローにディスパッチします:
条件
条件として、セキュリティ認証レベル、ポート番号、クライアントIPマスク、クライアント・バインドDN、バインドID、ドメイン名および他の条件を使用できます。
サービス品質(QoS)ポリシー
QoSポリシーとして、LDAP参照ポリシー、リクエスト・フィルタリング、クライアント接続アフィニティおよびリソース制限を使用できます。
プロパティや優先度の異なる複数のネットワーク・グループを定義できます。ただし、着信クライアント接続をアタッチできるのは、一度に1つのネットワーク・グループのみです。着信クライアント接続は、ネットワーク・グループに定義されている条件にこの接続が準拠していると最初に判断されたネットワーク・グループにアタッチされます。
クライアント接続は、ネットワーク・グループのすべての条件に準拠していることが確認されるまで、優先度順に各ネットワーク・グループによって評価されます。図5-1に示すように、リクエストはまず優先度が最も高いネットワーク・グループNetwork Group 1に送信されます。Network Group 1は、そのリクエストが必要なすべての条件に一致するかどうかを評価します。すべての条件には一致しない場合、リクエストはリストの次のネットワーク・グループNetwork Group 2に転送されます。
リクエストがネットワーク・グループのすべてのプロパティに一致する場合、このネットワーク・グループは、そのQoSポリシーにクライアント接続が一致するかどうかを評価します。QoSポリシーに一致する場合、クライアント接続は関連付けられているワークフローにルーティングされます。
ネットワーク・グループには、それぞれが異なるネーミング・コンテキストに対応している1つ以上のワークフローを関連付けることができます。ワークフローの詳細は、第5.1.2項「ワークフロー」を参照してください。クライアント接続が、ネットワーク・グループの条件には一致しても、そのQoSポリシーには一致しない場合、接続はワークフローに転送されることも、次のネットワーク・グループに送信されることもありません。かわりに、エラーの原因になったQoSポリシーを示すエラーが返されます。
ネットワーク・グループにワークフローが関連付けられていない場合、リクエストは処理されません。かわりに、サーバーからNo such entryのようなエラー・メッセージが返されます。
ネットワーク・グループの管理の詳細は、第17.1.6項「dsconfigを使用したネットワーク・グループの構成」を参照してください。
例5-1 ネットワーク・グループの条件を使用した異なるワークフローへのルーティング
次のネットワーク・グループを使用するOracle Unified Directory構成を想定します:
Network Group 1: 条件にはバインドDNとして**,dc=example,dc=comが設定されています。
このネットワーク・グループは、ネーミング・コンテキストdc=example,dc=comでWorkflow 1に関連付けられます。
Network Group 2: 条件にはバインドDNとして**,dc=test,dc=comが設定されています。
このネットワーク・グループは、ネーミング・コンテキストdc=test,dc=comでWorkflow 2に関連付けられます。
バインドDNに応じて、検索はNetwork Group 1またはNetwork Group 2を経由してルーティングされます。たとえば、バインドDNがuid=user.1,dc=test,dc=comであるリクエストは、Network Group 1には受け入れられませんが、Network Group 2に転送されて、そこで受け入れられ、Workflow 2に転送されます。
例5-2 ネットワーク・グループのQoSポリシーを使用したリクエストのフィルタリング
次のネットワーク・グループを使用するOracle Unified Directory構成を想定します:
Network Group 1: 条件にはバインドDNとして**,ou=admin,dc=example,dc=comが設定されています。
QoSポリシーには、リソース制限としてsize limit=0とtime limit=0が設定されています。したがって、adminグループには制限がありません。
このネットワーク・グループは、ネーミング・コンテキストdc=example,dc=comでWorkflow 1に関連付けられます。
Network Group 2: 条件にはバインドDNとして**,dc=example,dc=comが設定されています。
QoSポリシーには、リソース制限としてsize limit=100とtime limit=30 sが設定されています。したがって、adminグループ以外のすべての接続には、使用リソースに制限が設定されます。
また、このネットワーク・グループは、ネーミング・コンテキストdc=example,dc=comでWorkflow 1に関連付けられます。
したがって、バインドDNがdc=example,dc=comであるかぎり、リクエストはWorkflow 1に転送されます。Network Group 2に設定されているQoSポリシーにより、admin以外の任意のユーザーには、Workflow 1に対する制限付きアクセスが付与されます。adminとしてバインドされている任意のユーザーは、Network Group 1経由でWorkflow 1にアクセスし、使用リソースに制限はありません。
ワークフローは、ネーミング・コンテキスト(ベースDN)およびOracle Unified Directoryによる着信リクエストの処理方法を定義するワークフロー要素によって定義されます。ワークフローは、少なくとも1つのネットワーク・グループに登録される必要がありますが、複数のネットワーク・グループにアタッチできます。
1つのネットワーク・グループは、ワークフローのネーミング・コンテキストが異なる場合は複数のワークフローを指すことができます。一方、ネットワーク・グループのQoSポリシーが異なり、ワークフローのネーミング・コンテキストと同じである場合は、複数のネットワーク・グループが同一のワークフローを指すことができます。
各ワークフローは、アクセス制御グループによって関連付けられます。アクセス制御グループは、そのワークフローが処理する操作に適用するACIのリストを定義します。デフォルトでは、ローカル・バックエンドと呼ばれるアクセス制御グループが存在します。このアクセス制御グループには、ユーザー・データから取得されたすべてのACIが含まれています。「名前」属性は削除できません。このグループには、仮想ACIを追加することもできます。これは、仮想ACIが無効になるワークフローのアクセス制御グループとしてローカル・バックエンドを指定する必要があることを意味します。仮想ACIが無効になるワークフローの場合、任意のアクセス制御グループを使用できます。ACIの詳細は、第9章「Oracle Unified Directoryアクセス制御モデルの理解」を参照してください。
例5-3 1つのネットワーク・グループから複数のワークフローへのルーティング
(Figure 5-1に示すように)次のネットワーク・グループを使用するOracle Unified Directory構成を想定します:
Network Group 1: 条件にはバインドDNとして**,l=fr,dc=example,dc=comが設定されています。
このネットワーク・グループは、ネーミング・コンテキストl=fr,dc=oracle,dc=comでWorkflow 1に関連付けられます。
Network Group 2: 条件にはバインドDNとして**,l=uk,dc=example,dc=comが設定されています。
このネットワーク・グループは、ネーミング・コンテキストl=uk,dc=example,dc=comでWorkflow 2に関連付けられます。
Network Group 3: 条件にはバインドDNとして**,dc=example,dc=comが設定されています。
このネットワーク・グループは、ネーミング・コンテキストdc=example,dc=comでWorkflow 1とWorkflow 2に関連付けられます。
バインドDNが**,l=uk,dc=oracle,dc=comである検索はNetwork Group 2によって処理され、Workflow 2に送信されます。
バインドDNが**,dc=oracle,dc=comである検索はNetwork Group 3によって処理され、Workflow 1とWorkflow 2に送信されます。
各ワークフローには、少なくとも1つのワークフロー要素が含まれます。ワークフロー要素は、ルーティング構造の一部です。
Oracle Unified Directoryは、次のような様々なタイプのワークフロー要素をサポートします:
リーフ・ワークフロー要素: ローカル・バックエンド・ワークフロー要素とプロキシ・ワークフロー要素を構成します。
ルーティング・ワークフロー要素: ロード・バランシング・ワークフロー要素と分散ワークフロー要素を構成します。
仮想ワークフロー要素: DN名前変更ワークフロー要素、RDN変更ワークフロー要素および変換ワークフロー要素を構成します。
EUSワークフロー要素: エンタープライズ・ユーザー・セキュリティ(EUS)ワークフロー要素を構成します。
EUSコンテキスト・ワークフロー要素: EUSコンテキスト・ワークフロー要素を構成します。
LDIFワークフロー要素: LDIFローカル・バックエンド・ワークフロー要素を構成します。
メモリー・バックエンド・ワークフロー要素: メモリー・ローカル・バックエンド・ワークフロー要素を構成します。
ディレクトリ・サーバーの場合、図5-2に示すように、ワークフロー要素はDBローカル・バックエンドです。
プロキシ・サーバーの場合、ワークフロー要素は、リクエストを特定のパスに沿ってルーティングするポインタとして動作するロード・バランシング・ワークフロー要素または分散ワークフロー要素にチェーンできます。プロキシ・ワークフロー要素により、リモート・データ・ソースに直接アクセスできます。
Oracle Unified Directoryには、変更または削除が禁止されている事前構成済ワークフロー要素が多数存在します。
このセクションでは、Oracle Unified Directoryの高レベルのアーキテクチャについて説明します。
図5-3に示すように、クライアント・リクエストは、データ・ソースに転送される前は、Oracle Unified Directoryによって管理されます。このシナリオには、たとえば、ng1、ng2およびng3の3つのネットワーク・グループが存在します。最初のネットワーク・グループであるng1には2つのワークフローが関連付けられ、ng3には1つのワークフローが関連付けられています。ワークフローは、接尾辞で定義されます。w1の接尾辞はou=Xであり、ワークフローは3つのワークフロー要素からなるツリーを指しています。ワークフロー要素のツリーにより、操作に適用される処理が決定します。
クライアント・リクエストは、次のパスをたどります:
リクエスト・ハンドラは着信LDAPリクエストをワーク・キューに追加し、ワーカー・スレッドがそこからリクエストを受信します。
この操作は、割り当てられているネットワーク・グループの条件に基づいて、特定のネットワーク・グループにルーティングされます。操作は、サーバー・プロファイル、ディレクトリ・サーバーまたはプロキシ・サーバーに関係なく、ネットワーク・グループのQoSポリシーに準拠している必要があります。
ネットワーク・グループは操作をワークフローに転送します。ワークフローには、ネーミング・コンテキストが定義されています。ワークフローのネーミング・コンテキストとリクエストのベースDNの一致に基づいてワークフローが決定されます。
ワークフローはそのワークフロー要素のツリーに操作を転送します。ツリーには、リクエストの処理方法が定義されています。ワークフロー要素のツリーの内容は、サーバー・プロファイルに応じて、次のようになります:
ディレクトリ・サーバーの場合、ワークフロー要素を、ローカル・バックエンド・ワークフロー要素(ストレージ)としてのみ構成できます。
プロキシ・サーバーの場合、ワークフロー要素を、分散ワークフロー要素、ロード・バランシング・ワークフロー要素、DN名前変更ワークフロー要素またはLDAPプロキシ・ワークフロー要素として構成できます。
リクエストに割り当てられている処理が完了すると、リクエストがデータ・ソースに送信されます。
