| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionリファレンス 11g リリース1 (11.1.1.7.0) B72441-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionリファレンス 11g リリース1 (11.1.1.7.0) B72441-01 |
|
前 |
次 |
この章では、Directory Proxy ServerとバックエンドLDAPサーバー間の接続について説明します。この章の内容は次のとおりです。
Directory Proxy ServerとバックエンドLDAPサーバー間の接続は、LDAPデータソースを使用して構成されます。LDAPデータソースは、LDAPサーバーの名前とポート番号および操作をLDAPサーバーに転送するときにDirectory Proxy Serverが適用する認証ポリシーを特定します。LDAPデータソースは、LDAPサーバーの監視方法も構成します。
LDAPデータソースには、任意のLDAP v3サーバーを指定できます。Directory Proxy Serverの一部の詳細機能は、OracleのDirectory Serverのみで利用できる機能に依存している場合がありますが、この機能の構成はオプションです。たとえば、OracleのDirectory Serverの「実効権限取得」制御は、Directory Proxy Serverによってプロキシ認可で使用されます。
バックエンドLDAPサーバーのヘルスは、Directory Proxy ServerとバックエンドLDAPサーバー間の接続をテストして監視されます。Directory Proxy ServerによるLDAPデータソースの監視方法の詳細は、「データソースの監視方法」を参照してください。
LDAPデータソースの作成および構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のLDAPデータソースの作成および構成に関する説明を参照してください。
この項では、Directory Proxy ServerとバックエンドLDAPサーバー間の接続の開閉方法について説明します。また、複数のクライアント・リクエストでの接続プールの使用についても説明します。
起動時に、Directory Proxy Serverは、構成済の有効な各データソースに対して接続を開きます。
接続時にエラーが検出されると、Directory Proxy Serverは接続を閉じ、すぐに接続を再確立しようとします。Directory Proxy Serverがデータソースに接続できない場合、データソースは利用できないものとみなされます。失敗した接続に対するDirectory Proxy Serverの応答方法は、「データソースの失敗に対するレスポンス」を参照してください。
Directory Proxy ServerとLDAPサーバー間の接続は、複数のクライアント・リクエストで使用できるようにプールされます。各データソースでは、1プールのSSL接続および1プールの非SSL接続を使用できます。データソースのssl-policyプロパティおよび接続ハンドラのis-ssl-mandatoryプロパティは、データソースに接続するときにSSLを使用するかどうかを決定します。
データソースに対して開くことができる接続の数は、BIND、READおよびWRITEの各操作で別々に構成できます。同様の制限は、SSL接続および非SSL接続に適用されます。
各データソースおよび各種操作に次のプロパティを構成できます。
データソースへの初期接続数
初期接続数を超える接続がリクエストされた場合の新規接続数
データソースへの最大接続可能数
バインド・リプレイを構成する際、Directory Proxy Serverは、すでに開いている接続を再利用してパフォーマンスを最適化しようとします。クライアントが認証された接続を開くと、接続はバインド・プールから取得されます。そのため、バインド・リプレイを使用すると、バインド操作の接続プールは、読込みまたは書込み操作の接続プールより多く使用されます。バインド・リプレイの詳細は、「バインド・リプレイに構成されたDirectory Proxy Server」を参照してください。
データソースへの接続が5分間使用されない場合、接続はプールから削除されます。
クライアント・リクエストは、Directory Proxy ServerからバックエンドLDAPサーバーへ異なるレベルの認可と認証を使用して、クライアントのアイデンティティとともにまたはクライアント・アイデンティティなしで転送できます。データソースの構成は、リクエストの転送方法を決定します。クライアント・リクエストでのプロキシ認可の詳細は、「プロキシ認可に構成されたDirectory Proxy Server」を参照してください。クライアント・リクエストでのプロキシ認可の構成方法は、『Oracle Directory Server Enterprise Edition管理者ガイド』のプロキシ認可に関する説明を参照してください。
クライアント・リクエストにプロキシ認可制御が含まれる場合、コントロールは、Directory Proxy Serverによるリクエストの転送方法に関係なく、常にリクエストとともに転送されます。Directory Proxy Serverがプロキシ認可に構成されているユースケースおよびクライアント・リクエスト自体にプロキシ認可制御が含まれているユースケースは、「プロキシ認可に構成されたDirectory Proxy Serverおよびクライアント・リクエストにプロキシ認可が含まれる」の項を参照してください。
Directory Proxy ServerからバックエンドLDAPサーバーへのクライアント・リクエストの転送方法の詳細は、次の項を参照してください。
Directory Proxy Serverは、クライアントおよびクライアントの資格証明からLDAPサーバーにバインド・リクエストを転送します。バインドが成功すると、クライアントからそのLDAPサーバーへのすべての後続リクエストは、クライアントの認可を使用して処理されます。
バインド・リプレイでは、クライアントが、別のLDAPサーバーに転送される後続のリクエストを作成すると、Directory Proxy Serverは、クライアントがすでに提供した資格証明を使用して他のLDAPサーバーにバインドしてからリクエストを転送します。
クライアント・リクエストにプロキシ認可制御が含まれている場合、Directory Proxy Serverは、その制御をバックエンド・サーバーに転送します。
次の図は、バインド・リプレイが認可に使用しているクライアント・アイデンティティおよび資格証明を示しています。
Directory Proxy Serverは、開始されると各LDAPサーバーに接続を開きます。クライアントがDirectory Proxy Serverに接続すると、次の手順でリクエストが作成されます。
クライアントはバインドをリクエストし、DNおよびパスワードを提供します。
Directory Proxy Serverは、クライアントの資格証明を使用してLDAPサーバー1に対してクライアントを認可します。クライアントのエントリがLDAPサーバー1に存在し、バインド・リクエストが許可されます。
クライアントは、LDAPサーバー1をターゲットとする検索リクエストを発行します。
Directory Proxy Serverは、検索リクエストをLDAPサーバー1に転送し、接続2を再利用します。
検索リクエストは、クライアントの認可を使用して実行されます。クライアント・リクエストにプロキシ認可制御が含まれている場合、リクエストは、プロキシ認可制御で指定されているユーザーの認可を使用して処理されます。
クライアントがLDAPサーバー1をターゲットとする多数の検索リクエストを送信すると、Directory Proxy Serverは、追加のバインドを実行せずにリクエストを転送します。
クライアントは、LDAPサーバー2をターゲットとする検索リクエストを送信します。
Directory Proxy Serverは、手順1で取得したクライアントの資格証明を使用してLDAPサーバー2に対してクライアントを認可します。クライアントのエントリがLDAPサーバー2に存在し、バインド・リクエストが許可されます。
Directory Proxy Serverは、検索リクエストをLDAPサーバー2に転送し、接続3を再利用します。
クライアントがDirectory Proxy Serverに認可されない場合、バインド・リクエストは,匿名として転送されます。
クライアント・アイデンティティが別のアイデンティティにマップされている場合、Directory Proxy Serverは、マップされているアイデンティティを使用してLDAPサーバーにバインドします。その接続に対するすべてのリクエストは、マップされているアイデンティティの認可を使用して処理されます。マッピングの使用の詳細は、「代替ユーザーとしてリクエストを転送するよう構成されたDirectory Proxy Server」の項を参照してください。
Directory Proxy Serverがバインド・リプレイに構成されている場合、SASL外部バインドによる認証を使用できません。バインド・リプレイでは、クライアントDNおよびパスワードを使用して、Directory Proxy ServerがクライアントをバックエンドLDAPサーバーに認証します。SASL外部バインドでは、パスワードはクライアントから提供されません。また、ユーザー・エントリに格納されているパスワードはクリア・テキストで表示できません。
パフォーマンス上の理由から、プロキシ認可に必要な追加の構成を行うことができない場合、またはプロキシ認可がサポートされていない場合にのみバインド・リプレイを使用するようDirectory Proxy Serverを構成する必要があります。プロキシ認可の詳細は、「プロキシ認可に構成されたDirectory Proxy Server」を参照してください。
Directory Proxy Serverがプロキシ認可に構成されていると、Directory Proxy Serverはプロキシ認可制御をクライアント・リクエストに追加できます。そうすると、クライアント・リクエストは、プロキシ認可制御で指定されている認可を使用して転送されます。
Directory Proxy Serverでは、ACIの構成を簡略化するために、匿名の読込みを許可して、書込み操作に対するプロキシ認可を適用するよう構成できます。
Directory Proxy Serverがプロキシ認可に構成されていて、クライアント・リクエストに独自のプロキシ認可制御が含まれている場合、Directory Proxy Serverはプロキシ認可制御を追加しません。この場合、Directory Proxy Serverは、クライアントがそのプロキシ認可制御を使用する権限を持つバックエンドLDAPサーバーでチェックします。クライアントがそのプロキシ認可制御を使用する権限を持っている場合、Directory Proxy Serverは、クライアントのプロキシ認可制御で指定されている認可を使用してリクエストを転送します。
Directory Proxy Serverでのプロキシ認可の構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のプロキシ認可を使用したリクエストの転送に関する説明を参照してください。
Directory Proxy Serverがプロキシ認可に構成されている場合、クライアントは通常、非匿名バインドまたはSASL外部バインドによってDirectory Proxy Serverに認証されますが、クライアントを匿名にすることもできます。Directory Proxy Serverは通常、管理アイデンティティを使用してデータソースにバインドされます。
図19-2は、Directory Proxy Serverがプロキシ認可に構成されているときの、クライアント、Directory Proxy ServerおよびバックエンドLDAPサーバーの間の接続を示しています。
プロキシ認可の接続は次の手順で作成されます。
Directory Proxy Serverは、開始されると各LDAPサーバーに接続を開きます。Directory Proxy Serverは、そのDNとパスワード、DPSbindDNおよびDPSbindPWを提供して、LDAPサーバー1およびLDAPサーバー2にバインドします。
DPSbindDNのエントリが、LDAPサーバーおよび許可されているバインド・リクエストの両方に存在します。Directory Proxy Serverは、接続2および接続3でLDAPサーバーにバインドされます。
クライアントがDirectory Proxy Serverに接続すると、クライアントは、そのDNとパスワード、clientDNおよびclientPWを提供してバインドします。
Directory Proxy Serverは、クライアントの資格証明を使用し、接続2を再利用してLDAPサーバー1に対してクライアントを認可します。
クライアントのエントリがLDAPサーバー1に存在し、バインド・リクエストが許可されます。クライアントは、接続1のDirectory Proxy Serverにバインドされます。
図19-3は、Directory Proxy Serverがプロキシ認可に構成されているときの情報のフローを示しています。図19-2では、クライアントが接続を行い、Directory Proxy Serverはプロキシ認可制御を追加します。
図19-3 Directory Proxy Serverでプロキシ認可制御が追加されるときの情報フロー
クライアントは、プロキシ認可制御を含まない検索リクエストSEARCH 1を送信します。リクエストはLDAPサーバー1をターゲットにしています。
Directory Proxy Serverは、プロキシ認可制御をリクエストに追加し、接続2を再利用して検索操作をLDAPサーバー1に転送します。
検索操作は、プロキシ認可制御で指定されているユーザーの認可を使用して実行されます。その認可は、プロキシ認可制御で指定されているユーザーのLDAPサーバーのRW ACIで定義されます。
クライアントは、プロキシ認可制御を含まない2番目の検索リクエストSEARCH 2を送信します。リクエストはLDAPサーバー2をターゲットにしています。
Directory Proxy Serverは、検索操作をLDAPサーバー2に転送し、接続3を再利用します。
クライアントは、リクエストを処理する前にLDAPサーバー2にバインドする必要はなく、またそのLDAPサーバーにクライアントのエントリを含める必要もありません。
図19-3は、図19-2のクライアントがプロキシ認可制御を含むリクエストを作成するときの情報のフローを示しています。Directory Proxy Serverは、クライアントがそのプロキシ認可制御を使用する権限を持っているかを確認します。
クライアントは、プロキシ認可制御を含む検索リクエストSEARCH 1を送信します。リクエストはLDAPサーバー1をターゲットにしています。
Directory Proxy Serverは、LDAPサーバー1に対するクライアントの有効な権限を取得して、clientDNがLDAPサーバー1に対してプロキシ認可制御を使用する権限を持っているかを確認します。有効な権限を取得する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の有効な権限の表示に関する説明を参照してください。
Directory Proxy Serverは、検索操作をLDAPサーバー1に転送し、接続2を再利用します。
検索操作は、プロキシ認可制御で指定されているユーザーの認可を使用して実行されます。認可は、LDAPサーバーのRW ACIで定義されます。
クライアントは、プロキシ認可制御を含む2番目の検索リクエストSEARCH 2を送信します。リクエストはLDAPサーバー2をターゲットにしています。
Directory Proxy Serverは、LDAPサーバー2に対するクライアントの有効な権限を取得して、clientDNがLDAPサーバー2に対してプロキシ認可制御を使用する権限を持っているかを確認します。
Directory Proxy Serverは、検索操作をLDAPサーバー2に転送し、接続3を再利用します。
クライアントは、リクエストを処理する前にLDAPサーバー2にバインドする必要はなく、またそのLDAPサーバーにクライアントのエントリを含める必要もありません。
プロキシ認可にDirectory Proxy Serverを構成する前に、次のセキュリティ・リスクを検討します。
Directory Proxy Serverがプロキシ認可に構成されている場合、Directory Proxy Serverは、リクエストを転送する任意のクライアントの権限を前提としています。データに対する書込み操作の実行が認可されていないDirectory Proxy Serverは、プロキシ認可を使用して、それらの操作を実行できます。
LDAPサーバーには、プロキシ認可制御で指定されているユーザーに適切なR/W ACIを持つエントリが含まれている必要があります。このエントリは、第三者によって不正にアクセスされると、その第三者が偽装できる可能性があります。
プロキシ認可制御で構成されている認可アイデンティティを改ざんから保護する必要があります。
一部のデプロイメント・シナリオでは、クライアントがリクエストを作成するときに、クライアントのアイデンティティを維持する必要はありません。Directory Proxy Serverは、クライアント・アイデンティティなしでリクエストをLDAPサーバーに転送するよう構成できます。LDAPサーバーは、リクエストをDirectory Proxy Serverのアイデンティティおよび認可を使用して処理します。
クライアント・リクエストは、ユーザー・マッピングという機能を使用して、代替ユーザーのアイデンティティで実行できます。ユーザー・マッピングでは、クライアント・アイデンティティは、代替ユーザーのアイデンティティにマップされます。バインド操作の後、Directory Proxy Serverは、代替ユーザーとして後続の操作を送信します。
クライアント・アイデンティティが別のアイデンティティにマップされると、そのクライアントからのリクエストを、バインド・リプレイまたはプロキシ認可を使用して、バックエンドLDAPサーバーに転送できます。
クライアント・アイデンティティは、Directory Proxy Server上のローカル、またはLDAPサーバー上のリモートのいずれかで代替アイデンティティにマップできます。図19-5および図19-6は、ローカル・マッピングおよびリモート・マッピングを示しています。
ローカル・マッピングでは、アイデンティティ・マッピングは、Directory Proxy Serverで構成されます。Directory Proxy Serverを再構成しなくても構成を変更できます。ローカル・マッピングは、認証されていないクライアント、認証されているクライアントおよびプロキシによって認証されているクライアントに構成できます。
リモート・マッピングでは、アイデンティティ・マッピングは、リモートLDAPサーバーのエントリで構成されます。リモートLDAPサーバーのエントリを変更して、マッピングを構成できます。マッピングの変更にDirectory Proxy Serverの再構成は必要ありません。リモート・マッピングは、認証されていないクライアントおよびプロキシによって認証されているクライアントに構成できます。
リモート・マッピングは、バインド・リプレイに構成されているデータソースに使用できません。バインド・リプレイでは、Directory Proxy Serverは、バインド操作で提供される認証を使用して、クライアント・リクエストを転送します。ただし、リモート・マッピングでは、バインド操作で提供されるクライアントDNとパスワードは、代替DNとパスワードにマップされます。クライアントのパスワードは、バックエンドLDAPサーバーから取得できません。
ユーザー・マッピングが有効化されていてもマッピングに失敗する場合、クライアント・アイデンティティはデフォルトのアイデンティティにマップされます。クライアント・アイデンティティが、存在しない代替ユーザーにマップされている場合または構成エラーが発生している場合、ユーザー・マッピングは失敗する場合があります。
ユーザー・マッピングの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の代替ユーザーとしてリクエストを転送する方法に関する説明を参照してください。
