5 Oracle Unified Directoryの概念およびアーキテクチャの理解
次の各トピックでは、Oracle Unified Directoryの基本コンポーネントの概念およびOracle Unified Directoryのアーキテクチャについて説明します。
5.1 Oracle Unified Directoryのコンポーネントの理解
Oracle Unified Directoryには、ネットワーク・グループ、ワークフローおよびワークフロー要素の3つの主要コンポーネントが統合されています。製品の全機能を把握するには、各コンポーネントの役割を理解する必要があります。
この項では、各コンポーネントの概要について説明します。内容は次のとおりです:
5.1.1 ネットワーク・グループの理解
ネットワーク・グループは、Oracle Unified Directoryで処理するすべてのクライアント・リクエストのエントリ・ポイントです。
ネットワーク・グループについては、次のトピックで説明します。
5.1.1.1 ネットワーク・グループについて
ネットワーク・グループは、クライアントの相互作用をすべて処理し、いくつかの基準に基づいてローカル・バックエンド・ワークフローまたはプロキシ・ワークフローにディスパッチします。堅牢な構成を定義するには、それらの標準を理解する必要があります。
ネットワーク・グループは、次の標準を使用して、クライアントの相互作用を処理します。
-
条件
条件として、セキュリティ認証レベル、ポート番号、クライアントIPマスク、クライアント・バインドDN、バインドID、ドメイン名および他の条件を使用できます。
-
サービス品質(QoS)ポリシー
QoSポリシーとして、LDAP参照ポリシー、リクエスト・フィルタリング、クライアント接続アフィニティおよびリソース制限を使用できます。
プロパティや優先度の異なる複数のネットワーク・グループを定義できます。ただし、着信クライアント接続をアタッチできるのは、一度に1つのネットワーク・グループのみです。着信クライアント接続は、ネットワーク・グループに定義されている条件にこの接続が準拠していると最初に判断されたネットワーク・グループにアタッチされます。
クライアント接続は、ネットワーク・グループのすべての条件に準拠していることが確認されるまで、優先度順に各ネットワーク・グループによって評価されます。図5-1に示すように、リクエストはまず優先度が最も高いネットワーク・グループNetwork Group 1
に送信されます。Network Group 1
は、そのリクエストが必要なすべての条件に一致するかどうかを評価します。すべての条件には一致しない場合、リクエストはリストの次のネットワーク・グループNetwork Group 2
に転送されます。
リクエストがネットワーク・グループのすべてのプロパティに一致する場合、このネットワーク・グループは、そのQoSポリシーにクライアント接続が一致するかどうかを評価します。QoSポリシーに一致する場合、クライアント接続は関連付けられているワークフローにルーティングされます。
ネットワーク・グループには、それぞれが異なるネーミング・コンテキストに対応している1つ以上のワークフローを関連付けることができます。ワークフローの詳細は、「ワークフローの理解」を参照してください。クライアント接続が、ネットワーク・グループの条件には一致しても、そのQoSポリシーには一致しない場合、接続はワークフローに転送されることも、次のネットワーク・グループに送信されることもありません。かわりに、エラーの原因になったQoSポリシーを示すエラーが返されます。
ネットワーク・グループにワークフローが関連付けられていない場合、リクエストは処理されません。かわりに、サーバーからNo such entry
のようなエラー・メッセージが返されます。
ネットワーク・グループの管理の詳細は、「dsconfigを使用したネットワーク・グループの構成」を参照してください。
5.1.1.2 ネットワーク・グループの条件を使用した異なるワークフローへのルーティング
ネットワーク・グループの条件を使用して異なるワークフローにルーティングするには、この項で説明するステップを実行します。
次のネットワーク・グループを使用するOracle Unified Directory構成を想定します。
バインドDNに応じて、検索はNetwork Group 1
またはNetwork Group 2
を経由してルーティングされます。たとえば、バインドDNがuid=user.1,dc=test,dc=com
である場合、リクエストはNetwork Group 1
には受け入れられませんが、Network Group 2
に転送されて、そこで受け入れられ、Workflow 2
に転送されます。
5.1.1.3 ネットワーク・グループのQOSポリシーを使用したリクエストのフィルタリング
ネットワーク・グループのQOSポリシー・セットを使用してリクエストをフィルタリングするには、この項で説明するステップを実行します。
次のネットワーク・グループを使用するOracle Unified Directory構成を想定します。
したがって、バインドDNがdc=example,dc=com
である場合、リクエストはWorkflow 1
に転送されます。Network Group 2
に設定されているQoSポリシーにより、admin
以外の任意のユーザーには、Workflow 1
に対する制限付きアクセスが付与されます。admin
としてバインドされている任意のユーザーは、Network Group 1
経由でWorkflow 1
にアクセスし、使用リソースに制限はありません。
5.1.2 ワークフローの理解
ワークフローは、データのフローを表します。これは、ワークフロー要素とその関連する接続で構成されています。
ワークフローは、ネーミング・コンテキスト(ベースDN)およびOracle Unified Directoryによる着信リクエストの処理方法を定義するワークフロー要素によって定義されます。
ワークフローは、少なくとも1つのネットワーク・グループに登録される必要がありますが、複数のネットワーク・グループにアタッチできます。
ワークフローについてさらに学習するには、次のトピックを参照してください。
5.1.2.1 ワークフローについて
ワークフローは、ネットワーク・グループとネーミング・コンテキスト(接尾辞)間のリンクです。ワークフローは、ロード・バランシングまたは分散構成へのリクエストを処理する際に、特定のネットワーク・グループに対してアクセス可能なネーミング・コンテキストを定義します。
1つのネットワーク・グループは、ワークフローのネーミング・コンテキストが異なる場合は複数のワークフローを指すことができます。一方、ネットワーク・グループのQoSポリシーが異なり、ワークフローのネーミング・コンテキストと同じである場合は、複数のネットワーク・グループが同一のワークフローを指すことができます。
各ワークフローは、アクセス制御グループによって関連付けられます。アクセス制御グループは、そのワークフローが処理する操作に適用するACIのリストを定義します。デフォルトでは、ローカル・バックエンド
と呼ばれるアクセス制御グループが存在します。このアクセス制御グループには、ユーザー・データから取得されたすべてのACIが含まれています。「名前」属性は削除できません。このグループに仮想ACIを追加することもできます。これは、仮想ACIが無効なワークフローのアクセス制御グループとしてローカル・バックエンド
を指定する必要があることを意味します。仮想ACIが有効なワークフローには任意のアクセス制御グループを指定できます。ACIの詳細は、「Oracle Unified Directoryのアクセス制御モデルの理解」を参照してください。
5.1.2.2 ネットワーク・グループを使用した異なるワークフローへのルーティング
ネットワーク・グループを使用して、複数の異なるワークフローにルーティングします。
Oracle Unified Directoryが次のネットワーク・グループで構成されているとします(図5-1を参照)。
-
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
に送信されます。
5.1.3 ワークフロー要素の理解
ワークフロー要素は、ルーティング構造の一部です。各ワークフローには、少なくとも1つのワークフロー要素が含まれます。
Oracle Unified Directoryは、次のような様々なタイプのワークフロー要素をサポートします。
-
リーフ・ワークフロー要素: このタイプは、ローカル・バックエンド・ワークフロー要素とプロキシ・ワークフロー要素を構成します。
-
ルーティング・ワークフロー要素: このタイプは、ロード・バランシング・ワークフロー要素と分散ワークフロー要素を構成します。
-
仮想ワークフロー要素: このタイプは、DNリネーム・ワークフロー要素、RDN変更ワークフロー要素および変換ワークフロー要素を構成します。
-
EUSワークフロー要素: このタイプは、エンタープライズ・ユーザー・セキュリティ(EUS)ワークフロー要素を構成します。
-
EUSコンテキスト・ワークフロー要素: このタイプは、EUSコンテキスト・ワークフロー要素を構成します。
-
LDIFワークフロー要素: このタイプは、LDIFローカル・バックエンド・ワークフロー要素を構成します。
-
メモリー・バックエンド・ワークフロー要素: このタイプは、メモリー・ローカル・バックエンド・ワークフロー要素を構成します。
ディレクトリ・サーバーの場合、図5-2に示すように、ワークフロー要素はDBローカル・バックエンドです。
プロキシ・サーバーの場合、ワークフロー要素は、リクエストを特定のパスに沿ってルーティングするポインタとして動作するロード・バランシング・ワークフロー要素または分散ワークフロー要素にチェーンできます。プロキシ・ワークフロー要素により、リモート・データ・ソースに直接アクセスできます。
Oracle Unified Directoryには、変更または削除が禁止されている事前構成済ワークフロー要素がいくつか存在します。
5.2 Oracle Unified Directoryのアーキテクチャの概要
Oracle Unified Directoryは、記憶域、同期、プロキシおよび仮想機能を提供するJavaベースのディレクトリ・サービスです。統合ソリューションは柔軟かつ最適化されたアーキテクチャを備え、アプリケーション・デプロイメントを拡張して、総所有コストを削減します。
この項の例では、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プロキシ・ワークフロー要素として構成できます。
-
-
リクエストに割り当てられている処理が完了すると、リクエストがデータ・ソースに送信されます。