この章では、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=example,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=example,dc=com
である検索はNetwork Group 2
によって処理され、Workflow 2
に送信されます。
バインドDNが**,dc=example,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プロキシ・ワークフロー要素として構成できます。
リクエストに割り当てられている処理が完了すると、リクエストがデータ・ソースに送信されます。