| Oracle® Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド 11g リリース2 (11.1.2.1) B71694-06 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド 11g リリース2 (11.1.2.1) B71694-06 |
|
前 |
次 |
この章では、Oracle Identity Managementインフラストラクチャのエンタープライズ・デプロイメント・トポロジの前提条件について説明します。
この章の内容は次のとおりです。
様々な種類のネットワーク・トラフィックや監視に対応するように、仮想サーバーや関連するポートをロード・バランサに構成する必要があります。これらの仮想サーバーは、サービスを実行するために適切な実際のホストおよびポートに対して構成する必要があります。また、ロード・バランサは、可用性を確保するために実際のホストおよびポートを監視するように構成し、サービスがダウンしたときにこれらのホストおよびポートへのトラフィックをできるだけ早く停止できるようにする必要があります。これにより、特定の仮想ホストの受信トラフィックが、他の層にある使用できないサービスに送信されないようになります。
第2.2項「トポロジについて」のデプロイメント・トポロジの図に示すように、各デプロイメントは複数のゾーン間に広がっています。ゾーンは、インフラストラクチャのコンポーネントへのアクセスを実際にアクセスを必要とする人に制限する方法です。このガイドの例では、2つのゾーンを示します。
パブリック・ゾーン: ここでは外部からシステムにアクセスできます。ロード・バランサやWeb層など外部からアクセスする必要があるコンポーネントのみをこのゾーンに配置します。このゾーンの下の任意のサーバーまたはサービスに外部のユーザーがアクセスしようとすると、ファイアウォールがアクセスを阻止します。
パブリック・ゾーンは、このゾーンのサーバーがプライベート・ゾーンのアプリケーション・サーバーとやり取りできるように構成されます。
イントラネットゾーン: これは、データベースなどのコア・サービスを含むサーバーを配置する場所です。これらのサービスは、最も機密性の高いデータが含まれているため、組織によって非常に厳密に制御されます。
この方法を使用することによって、情報を必要とするコンポーネントのみに情報へのアクセスを制限します。この方法は、組織の外部のユーザーがいる場合に有効です。エクストラネットのかわりに(すべての通信が信頼できるソースからである)イントラネットを設定している場合、ゾーンの1つまたは複数を合理的に廃棄できる場合があります。
仮想サーバー名はロード・バランサ上で構成されます。指定のIPアドレスで受信したトラフィックをそのIPアドレスと関連付けられた専用サーバーのプールに分散するようにロード・バランサを構成できます。
このロード・バランサのIPアドレスは、仮想サーバー名と呼ばれる名前と関連付けられています。この名前はDNSで定義されます。ロード・バランサはHTTPヘッダーにこの名前を格納し、Oracle HTTP Serverによって識別できるようにしています。
この項には次のトピックが含まれます:
ロード・バランサは、これらの仮想ホスト名が使用される領域でアクセスできるような方法でDNSが設定される際に必要なアクセスに応じて、複数の仮想ホスト名を使用して構成されます。例:
パブリック通信は、組織の内部と外部の両方で解決可能な仮想ホストを使用して構成されます。
プロセス間通信は、プライベート・ゾーンでのみ解決可能な仮想ホストを使用して構成されます。
管理アクセスは、組織内でのみ解決可能です。
Identity Managementエンタープライズ・トポロジは、次の仮想サーバー名を使用します。
仮想サーバー名がIPアドレスと関連付けられており、DNSの一部になっていることを確認してください。Oracle Fusion Middlewareを実行するコンピュータでは、これらの仮想サーバー名を解決できる必要があります。
第3.4項「ロード・バランサの構成」の手順に従って、ロード・バランサで仮想サーバー名を定義します。
このガイドの残りの部分では、デプロイメントは第2章「導入と計画」で示したデプロイメントの1つであることを前提とします。
この仮想サーバーはLBR2上で有効になっています。これは、すべてのアイデンティティ・ストアLDAPトラフィックに対してアクセス・ポイントの役割を果たします。SSLと非SSLの両方へのトラフィックが構成されます。クライアントは、アドレスIDSTORE.mycompany.com:636 (SSLの場合)およびIDSTORE.mycompany.com:389(非SSLの場合)を使用してこのサービスにアクセスします。
アイデンティティ・ストアにOracle Virtual Directory経由でアクセスする場合は、OVDHOST1およびOVDHOST2上でOracle Virtual Directoryプロセスのハートビートを監視します。Oracle Virtual Directoryプロセスが停止した場合、ロード・バランサは稼動しているOracle Virtual DirectoryインスタンスへのLDAPトラフィックのルーティングを継続する必要があります。
アイデンティティ・ストアがOracle Internet Directory内にあり、直接アクセスを受ける場合は、Oracle Internet Directoryホスト上でOracle Internet Directoryプロセスのハートビートを監視します。Oracle Internet Directoryプロセスが停止した場合、ロード・バランサは稼動しているOracle Internet DirectoryインスタンスへのLDAPトラフィックのルーティングを継続する必要があります。
アイデンティティ・ストアがOracle Unified Directoryに配置されていて、直接アクセスされる場合、Oracle Unified Directoryプロセスのハートビートを監視します。Oracle Unified Directoryプロセスが停止した場合、ロード・バランサは稼動しているOracle Unified DirectoryインスタンスへのLDAPトラフィックのルーティングを継続する必要があります。
アイデンティティ・ストアがOracle Unified Directoryに配置されている場合、この仮想サーバーは、ポート389 (LDAP_LBR_PORT)で受信したトラフィックをポート1389 (LDAP_DIR_PORT)でOracle Unified Directoryの各インスタンスに転送します。
アイデンティティ・ストアがOracle Unified Directoryに配置されている場合、この仮想サーバーは、ポート636 (LDAP_LBR_SSL_PORT)で受信したトラフィックをポート1636 (LDAP_DIR_SSL_PORT)でOracle Unified Directoryの各インスタンスに転送します。
アイデンティティ・ストアがOracle Internet Directoryに配置されている場合、この仮想サーバーは、ポート389 (LDAP_LBR_PORT)で受信したトラフィックをポート3060でOracle Internet Directoryの各インスタンスに転送します。
アイデンティティ・ストアがOracle Internet Directoryに配置されている場合、この仮想サーバーは、ポート636 (LDAP_LBR_SSL_PORT)で受信したトラフィックをポート3131でOracle Internet Directoryの各インスタンスに転送します。
アイデンティティ・ストアがOracle Virtual Directoryに配置されている場合、この仮想サーバーは、ポート389 (LDAP_LBR_PORT)で受信したトラフィックをポート6501でOracle Virtual Directoryの各インスタンスに転送します。
アイデンティティ・ストアがOracle Virtual Directoryに配置されている場合、この仮想サーバーは、ポート636 (LDAP_LBR_SSL_PORT)で受信したトラフィックをポート7501でOracle Virtual Directoryの各インスタンスに転送します。
この仮想サーバーはLBR1上で有効になっています。管理サービスに送信されるすべての内部HTTPトラフィック用のアクセス・ポイントとして機能します。クライアントからの受信トラフィックはすべて非SSLに対応しています。このため、クライアントはアドレスADMIN.mycompany.com:80を使用してこのサービスにアクセスし、トラフィックはWEBHOST1およびWEBHOST2のポート7777 (OHS_PORT)に転送されます。この仮想ホストでアクセスされるサービスには、WebLogic管理サーバー・コンソール、Oracle Enterprise Manager Fusion Middleware Control、Oracle Authorization Policy Manager、Oracle Directory Services Managerなどがあります。
ファイアウォールでルールを作成し、この仮想ホストを使用して外部トラフィックが/console URLおよび/em URLにアクセスすることを防止します。DMZ内部のトラフィックのみがADMIN.mycompany.com仮想ホスト上のこれらのURLにアクセスできる必要があります。
この仮想サーバーはLBR1上で有効になっています。クライアントからの受信トラフィックはすべて非SSLに対応しています。このため、クライアントは、アドレスIDMINTERNAL.mycompany.com:80を使用してこのサービスにアクセスし、トラフィックはWEBHOST1およびWEBHOST2のポート7777 (OHS_PORT)に転送されます。SOA管理対象サーバーは、この仮想ホストにアクセスして、Oracle Identity Manager Webサービスのコールバックを行います。
ファイアウォールでルールを作成し、外部トラフィックがこの仮想ホストにアクセスすることを防止します。DMZ内部のトラフィックのみがIDMINTERNAL.mycompany.com仮想ホスト上のこれらのURLにアクセスできる必要があります。
これは、すべてのアイデンティティ管理コンポーネント(Oracle Access Management、Oracle Identity Managerなど)に対する仮想名です。
この仮想サーバーはLBR1上で有効になっています。これは、シングル・サインオン・サービスに送信されるすべてのHTTPトラフィックのアクセス・ポイントとして機能します。クライアントからの受信トラフィックはSSLに対応しています。このため、クライアントはアドレスSSO.mycompany.com:443を使用してこのサービスにアクセスし、トラフィックはWEBHOST1およびWEBHOST2のポート7777 (OHS_PORT)に転送されます。シングル・サインオン対応の保護リソースへのアクセスは、すべてこの仮想ホスト上で行われます。
ロード・バランサでポート80 (HTTP_PORT)とポート443 (HTTP_SSL_PORT)の両方を使用してこの仮想サーバーを構成します。
この仮想ホストは、リクエストのクライアントIPアドレスを保持するように構成する必要があります。一部のロード・バランサでは、ロード・バランサを有効にしてリクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入することにより、これを構成します。
ロード・バランサ上には、各種のネットワーク・トラフィックおよび監視用に、いくつかの仮想サーバーおよびそれらに関連付けられたポートを構成する必要があります。これらは、サービスを実行するために適切な実際のホストおよびポートに対して構成する必要があります。また、ロード・バランサは、可用性を確保するために実際のホストおよびポートを監視するように構成し、サービスがダウンしたときにこれらのホストおよびポートへのトラフィックをできるだけ早く停止できるようにする必要があります。これにより、特定の仮想ホストの受信トラフィックが、他の層にある使用できないサービスに送信されないようになります。
推奨トポロジ内には、2つのロード・バランサ・デバイスがあります。一方のロード・バランサは外部HTTPトラフィック用に設定し、もう一方のロード・バランサは内部LDAPトラフィック用に設定します。様々な理由から、デプロイメントで使用されるロード・バランサ・デバイスが1つになる場合があります。このような構成もサポートされていますが、これに伴うセキュリティへの影響を考慮する必要があります。その構成が適切であることがわかったら、様々なゾーン間のトラフィックを許可するように、関連するファイアウォール・ポートを開いてください。いずれの場合も、特定のロード・バランサ・デバイスをフォルト・トレラント・モードでデプロイすることを強くお薦めします。
この項には次のトピックが含まれます:
エンタープライズ・トポロジでは、外部のロード・バランサを使用します。この外部ロード・バランサは次の機能を備えている必要があります。
仮想ホスト名を使用してトラフィックを実際のサーバーのプールにロード・バランシングする機能: クライアントは仮想ホスト名を使用してサービスにアクセスします(実際のホスト名は使用しない)。ロード・バランサは、リクエストをプールのサーバーにロード・バランスできるようになります。
ポート変換の構成。
ポート(HTTPおよびHTTPS)の監視。
仮想サーバーとポート構成: 外部ロード・バランサの仮想サーバー名とポートを構成する機能。仮想サーバー名とポートは次の要件を満たす必要があります。
ロード・バランサは複数の仮想サーバーの構成が可能である必要がある。各仮想サーバーに対して、ロード・バランサは複数のポート上でトラフィック管理の構成を行える必要があります。たとえば、Oracle WebLogicクラスタの場合は、1つの仮想サーバーとHTTPおよびHTTPSの両トラフィック用のポートを指定してロード・バランサを構成する必要があります。
仮想サーバー名は、IPアドレスに関連付けられていて、DNSの一部である必要がある。クライアントは仮想サーバー名を使用して外部ロード・バランサにアクセスできる必要があります。
ノードの障害を検出し、障害のあるノードへのトラフィックのルーティングを即時に停止する機能。
リソースの監視/ポートの監視/プロセス障害の検出: ロード・バランサは、サービス障害およびノード障害を(通知またはその他の方法によって)検出し、障害のあるノードへの非Oracleネット・トラフィックの転送を停止する必要があります。ご使用の外部ロード・バランサに障害の自動検出機能がある場合、これを使用する必要があります。
フォルト・トレラント・モード: ロード・バランサはフォルト・トレラント・モードで構成することを強くお薦めします。
その他: トラフィックの転送先となるバックエンド・サービスが使用不可の場合に、即座にコール元クライアントに戻るようにロード・バランサの仮想サーバーを構成しておくことを強くお薦めします。これは、クライアントのマシンのTCP/IP設定に基づくタイムアウトの後、自ら接続解除するクライアントに対して好ましい構成です。
SSLアクセラレーション: SSLトランザクションで実行され、公開鍵暗号化アルゴリズムをハードウェア・アクセラレータにオフロードします。この機能は推奨されますが、必須ではありません。
SSLリクエストをロード・バランサで終了して、同等の非SSLプロトコルを使用してトラフィックを実際のバックエンド・サーバーに転送する機能。たとえば、ロード・バランサは、HTTPSリクエストをHTTPとして転送できる必要があります。この機能は「SSL終端」と呼ばれることがあります。これは、このエンタープライズ・デプロイメントで必要です。
クライアントIPアドレスを保持する機能: ロード・バランサには、リクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入し、クライアントIPアドレスを保持する機能がある必要があります。
WL-Proxy-SSL: trueをHTTP要求ヘッダーに追加する機能。これを自動で行うロード・バランサもあります。
ロード・バランサの構成手順は、ロード・バランサの特定のタイプによって異なります。実際の手順は、ベンダーが提供するドキュメントを参照してください。次の手順では、一般的な構成フローを示します。
サーバーのプールを作成します。このプールには、ロード・バランシング定義に含まれるサーバーおよびポートのリストが存在します。たとえば、Webホスト間のロード・バランシングの場合、リクエストをポート7777 (OHS_PORT)でWEBHOST1およびWEBHOST2のホストに送信するサーバーのプールを作成します。
特定のホストとサービスが使用可能かどうかを決定するルールを作成し、手順1で説明したサーバーのプールに割り当てます。
ロード・バランサ上に仮想サーバーを作成します。これは、アプリケーションにより使用されるリクエストを受信するアドレスとポートです。たとえば、Web層のリクエストをロード・バランシングするには、SSO.mycompany.com:80に対する仮想ホストを作成します。
ロード・バランサでサポートされている場合は、仮想サーバーが内部から、外部から、またはその両方から利用できるのかどうかを指定します。内部アドレスはネットワーク内からのみ解決可能であることを確認します。
適用可能な場合は、仮想サーバーに対するSSL終端を構成します。
手順1で作成したサーバーのプールを、仮想サーバーに割り当てます。
表3-3「Oracle Identity Managementエンタープライズ・デプロイメント・トポロジで使用されるポート」にリストされているタイムアウト設定を調整します。これには、サービスが停止しているかどうかを検出する時間も含まれます。
アイデンティティ管理デプロイメントの場合、表3-1に示すようにロード・バランサを構成します。
表3-1 ロード・バランサの構成
| 仮想ホスト | サーバー・プール | プロトコル | SSL終端 | 外部 | 必要なその他の構成/コメント |
|---|---|---|---|---|---|
|
|
|
HTTP |
いいえ |
はい |
アイデンティティ管理では、次のコードをHTTPヘッダーに追加する必要があります。
|
|
|
|
HTTP |
はい |
はい |
アイデンティティ管理では、次のコードをHTTPヘッダーに追加する必要があります。
|
|
|
|
HTTP |
いいえ |
いいえ |
|
|
|
|
HTTP |
いいえ |
いいえ |
|
|
|
|
LDAP |
いいえ |
いいえ |
アイデンティティ管理ユーザーがOracle Unified Directoryに格納されている場合のみ必要です。 |
|
|
|
LDAP |
いいえ |
いいえ |
アイデンティティ管理ユーザーがOracle Unified Directoryに格納されている場合のみ必要です。 |
|
|
|
LDAP |
いいえ |
いいえ |
通常これは、OIDのインストールの一部として設定済です。OIDに対してLDAPコールをロード・バランスするために使用されます。 |
|
|
|
LDAP |
いいえ |
いいえ |
通常これは、OIDのインストールの一部として設定済です。OIDに対してLDAPコールをロード・バランスするために使用されます。 |
|
|
|
LDAP |
いいえ |
いいえ |
通常これは、OVDのインストールの一部として設定済です。OVDに対してLDAPコールをロード・バランスするために使用されます。 |
|
|
|
LDAP |
いいえ |
いいえ |
通常これは、OVDのインストールの一部として設定済です。OVDに対してLDAPコールをロード・バランスするために使用されます。 |
脚注 1 IS_SSLの構成の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のユーザー定義のWebゲート・パラメータに関する項を参照してください。
仮想IPアドレスは、ホストの主要IPアドレスと同じサブネットに属する、未使用のIPアドレスです。このアドレスはホストに手動で割り当てられ、Oracle WebLogic管理対象サーバーはこのIPアドレスをリスニングするように構成されます。IPアドレスが割り当てられたノードに障害が発生した場合は、割り当てられた管理対象サーバーの実行を新しいノードが引き継ぐことができるように、このIPアドレスは同じサブネット内の別のノードに割り当てられます。
次に、Oracle Identity Managementが必要とする仮想IPアドレスのリストを示します。
ADMINVHN.mycompany.com
エンタープライズ・デプロイメントでは、WebLogic管理サーバーが、配置されているホストに障害が発生した後でも、リクエストの処理を継続できることが必要です。仮想IPアドレスは、アプリケーション層内の任意のホスト上でネットワーク・インタフェースにバインドできるように、アプリケーション層内でプロビジョニングされる必要があります。WebLogic管理サーバーは、後でこの仮想IPアドレスをリスニングするように構成されます。これについては、本ドキュメントで後述します。この仮想IPアドレスは、管理サーバーとともに、IDMHOST1からIDMHOST2に(またはIDMHOST2からIDMHOST1に)フェイルオーバーします。
SOAHOSTXVHN.mycompany.com
SOA管理対象サーバーごとに1つの仮想IPアドレスが必要です。これにより、サーバーをサーバー移行の処理対象にすることができます。
アプリケーション層内で仮想IPアドレスをプロビジョニングすることにより、アプリケーション層にある任意のホストのネットワーク・インタフェースにこのアドレスをバインドできるようにします。
OIMHOSTXVHN.mycompany.com
Oracle Identity Manager管理対象サーバーごとに1つの仮想IPアドレスが必要です。これにより、サーバーをサーバー移行の処理対象にすることができます。
アプリケーション層内で仮想IPアドレスをプロビジョニングすることにより、アプリケーション層にある任意のホストのネットワーク・インタフェースにこのアドレスをバインドできるようにします。
図3-1に示すように、異なる仮想IPと物理IPでリスニングするように、管理サーバーと管理対象サーバーを構成してください。
表3-2には、様々な仮想ホストの説明が記載されています。
表3-2 VIPアドレスおよび仮想ホスト
| 仮想IP | VIPのマップ先 | 説明 |
|---|---|---|
|
VIP1 |
ADMINVHN |
ADMINVHNは、管理サーバーのリスニング・アドレスである仮想ホスト名であり、管理サーバーの手動フェイルオーバーによりフェイルオーバーします。管理サーバー・プロセスが実行されているノード(デフォルトはIDMHOST1)で有効化されます。 |
|
VIP2 |
SOAHOST1VHN |
SOAHOST1VHNは、WLS_SOA1のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_SOA1プロセスが実行されているノード(デフォルトはIDMHOST1)で有効化されます。 |
|
VIP3 |
OIMHOST1VHN |
OIMHOST1VHNは、WLS_OIM1サーバーのリスニング・アドレスにマップし、このサーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_OIM1プロセスが実行されているノード(デフォルトはIDMHOST1)で有効化されます。 |
|
VIP4 |
SOAHOST2VHN |
SOAHOST2VHNは、WLS_SOA2のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_SOA2プロセスが実行されているノード(デフォルトはIDMHOST2)で有効化されます。 |
|
VIP5 |
OIMHOST2VHN |
OIMHOST2VHNは、WLS_OIM2サーバーのリスニング・アドレスにマップし、このサーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_OIM2プロセスが実行されているノード(デフォルトはIDMHOST2)で有効化されます。 |
多くのOracle Fusion Middlewareコンポーネントとサービスではポートを使用します。管理者はこれらのサービスに使用するポート番号を把握し、ホスト上の2つのサービスが同じポート番号を使用しないようにする必要があります。
ほとんどのポート番号はインストール後に割り当てられます。必要に応じて別のポート番号を使用できます。表3-3に示したポート番号は、一貫性を保つためにこのガイド全体にわたって使用する例です。別のポート番号を使用する場合、その値が使用される場所では必ずその値を表の値のかわりに使用する必要があります。
表3-3は、Oracle Identity Managementトポロジで使用されるポートの一覧です。これには、トポロジ内のファイアウォール上で開く必要があるポートが含まれます。
ファイアウォールの表記法
FW0は、最も外側のファイアウォールを表します。
FW1は、Web層とアプリケーション層の間のファイアウォールを表します。
FW2は、アプリケーション層とデータベース層の間のファイアウォールを表します。
付録Bのポート・マッピング・ワークシートを使用して、ポートの使用を追跡できます。
表3-3 Oracle Identity Managementエンタープライズ・デプロイメント・トポロジで使用されるポート
| タイプ | ファイアウォール | ポートとポートの範囲 | プロトコル/アプリケーション | インバウンド/アウトバウンド | タイムアウト |
|---|---|---|---|---|---|
|
ブラウザ・リクエスト |
FW0 |
80 |
HTTP/ロード・バランサ |
両方 |
Oracle Identity Managementで使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツに応じて、タイムアウトは異なります。 |
|
ブラウザ・リクエスト |
FW0 |
443 |
HTTPS/ロード・バランサ |
両方 |
Oracle Identity Managementで使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツに応じて、タイムアウトは異なります。 |
|
ブラウザ・リクエスト |
FW1 |
80 |
HTTPS/ロード・バランサ |
アウトバウンド(イントラネット・クライアント) |
タイムアウトは、IDMによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。 |
|
ブラウザ・リクエスト |
FW1 |
443 |
HTTPS/ロード・バランサ |
アウトバウンド(イントラネット・クライアント) |
タイムアウトは、IDMによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。 |
|
ロード・バランサからOracle HTTP Serverへ |
n/a |
7777 |
HTTP |
n/a |
第3.4項「ロード・バランサの構成」を参照してください。 |
|
管理サーバーによるOHS登録 |
FW1 |
7001 |
HTTP/t3 |
インバウンド |
タイムアウトを短い時間(5から10秒)に設定します。 |
|
Web層からのOracle WebLogic管理サーバー・アクセス |
FW1 |
7001 |
HTTP/Oracle HTTP Serverと管理サーバー |
インバウンド |
N/A |
|
Enterprise Managerエージェント - Web層からEnterprise Managerへ |
FW1 |
5160 |
HTTP/Enterprise ManagerエージェントとEnterprise Manager |
両方 |
N/A |
|
Oracle HTTP ServerからWLS_OAMへ |
FW1 |
14100 |
HTTP/Oracle HTTP ServerからWebLogic Serverへ |
インバウンド |
使用される |
|
Oracle HTTP ServerWLS_OIM |
FW1 |
14000 |
HTTP/Oracle HTTP ServerからWebLogic Serverへ |
インバウンド |
使用されるmod_weblogicパラメータに応じて、タイムアウトは異なります。 |
|
Oracle HTTP ServerWLS_SOA |
FW1 |
8001 |
HTTP/Oracle HTTP ServerからWebLogic Serverへ |
両方 |
使用されるmod_weblogicパラメータに応じて、タイムアウトは異なります。 |
|
管理サーバーによるOracle HTTP Serverの管理 |
FW1 |
OPMNのリモート・ポート(6701)およびOHSの管理ポート(7779) |
それぞれTCPとHTTP |
アウトバウンド |
タイムアウトを短い時間(5-10秒など)に設定します。 |
|
OAMサーバー |
FW1 |
5575 |
OAP |
両方 |
N/A |
|
Access Manager Coherenceポート |
FW1 |
9095 |
TCMP |
両方 |
N/A |
|
Oracle Coherenceポート |
FW1 |
8000 - 8088 |
TCMP |
両方 |
N/A |
|
ディレクトリ層からのIDMDomain Oracle WebLogic管理サーバー・アクセス |
FW2 |
7001 |
HTTP/Oracle Internet Directory、Oracle Virtual Directory、および管理サーバー |
アウトバウンド |
N/A |
|
Enterprise Managerエージェント: ディレクトリ層からEnterprise Managerへ(ディレクトリ層が実装されている場合)。 |
FW2 |
5160 |
HTTP/Enterprise ManagerエージェントとEnterprise Manager |
両方 |
N/A |
|
Oracle HTTP Serverから管理サーバーへ |
FW2 |
OPMNリモート・ポート |
HTTP/管理サーバーからOPMNへ |
インバウンド |
N/A |
|
アプリケーション層からデータベース・リスナーへ |
FW2 |
1521 |
SQL*Net |
両方 |
Oracle Identity Managementで使用されるプロセス・モデルのタイプとすべてのデータベース・コンテンツに応じて、タイムアウトは異なります。 |
|
Oracle Notification Server (ONS) |
FW2 |
6200 |
ONS |
両方 |
Gridlink用に必要。ONSサーバーは各データベース・サーバー上で稼働します。 |
|
LDAPポート |
FW2 |
ディレクトリに依存 |
LDAP |
インバウンド |
理想的には、タイムアウトが発生しないようにこれらの接続を構成します。 |
|
LDAP SSLポート |
FW2 |
ディレクトリに依存 |
LDAP SSL |
インバウンド |
理想的には、タイムアウトが発生しないようにこれらの接続を構成します。 |
|
ノード・マネージャ |
N/A |
5556 |
TCP/IP |
N/A |
N/A |
|
注意: 外部ドメイン(SOA、WebCenter Portalドメインなど)のアプリケーションをこのアイデンティティ管理ドメインで認証できるように、ファイアウォール間で追加のポートを開く必要が生じることがあります。 |
ここでは、Oracle Accessプロトコル(OAP)について説明し、ユーザー・リクエストの概要を示します。
この項には次のトピックが含まれます:
Oracle Accessプロトコル(OAP)は、ユーザー認証および認可の間に、アクセス・システム・コンポーネント(OAMサーバー、Webゲートなど)間の通信を可能にします。このプロトコルは、以前NetPointアクセス・プロトコル(NAP)またはCOREidアクセス・プロトコルと呼ばれていました。
Oracle Access Management Access Managerは、ユーザーのセッションを作成します。Access Managerが別のアイデンティティ管理コンポーネント(Oracle Identity Managerなど)と統合すると、認証はそのコンポーネントに委任されます。
典型的なリクエスト・フローは次のようになります。
ユーザーは、最初にリソースにアクセスしようとします。
Webゲートは、リクエストを捕捉し、ユーザーが認証されていないことを検出します。
Access Managerの資格証明コレクタが呼び出され、ユーザーはプロンプトに応答してユーザー名およびパスワードを入力します。Access Managerは、パスワード・ポリシーが最初のログイン時にパスワードの変更を要求することを認識しているため、ユーザーのブラウザはOracle Identity Managerにリダイレクトされます。
ユーザーは、パスワードの変更およびチャレンジ質問の設定を求められます。
この時点で、Oracle Identity Managerは、新しく入力したパスワードを使用してユーザーを認証しています。Oracle Identity Managerは、TAPリクエストを作成し、Access Managerがユーザーにセッションを作成できることを通知します。つまり、ユーザーは再ログインを求められません。これは、Access Managerが読み取ることができるユーザーのブラウザにトークンを追加することによって行われます。
Access ManagerへのTAPリクエストには次のことが含まれています。
Access Managerサーバーの配置場所。
使用するWebゲート・プロファイル。
Webゲート・プロファイルのパスワード。
証明書(Access Managerが簡易モードまたは証明書モードで動作している場合)。
ユーザーがアクセスをリクエストするときのリクエスト・フローは、次のとおりです。
ユーザーは、HTTPまたはHTTPSを介して保護されたリソースへのアクセスをリクエストします。
Webゲートはリクエストを捕捉します。
Webゲートは、Oracle Accessプロトコルを介してリクエストをOAMサーバーに転送し、リソースが保護されているかどうか、ユーザーの認証方法およびユーザーが認証されているかどうかを判定します(認証されていない場合は問題になります)。
OAMサーバーは、ディレクトリ・サーバーで資格証明(ユーザーIDとパスワードなど)を確認し、Oracle Accessプロトコルを介して情報をWebゲートに戻し、暗号化Cookieを生成してユーザーを認証します。
認証に従い、WebゲートがOracle Accessプロトコルを介してOAMサーバーに要求し、OAMサーバーは適切なセキュリティ・ポリシーを検索し、そのポリシーをユーザーのアイデンティティと比較してユーザーの認証レベルを判別します。
アクセス・ポリシーが有効な場合、ユーザーは目的のコンテンツまたはアプリケーション(あるいはこれら両方)へのアクセスを許可されます。
ポリシーが偽の場合、ユーザーはアクセスを拒否され、組織の管理者が決めた別のURLにリダイレクトされます。
トポロジにあるノードはユニキャスト通信を使用して通信することをお薦めします。マルチキャスト通信と異なり、ユニキャストはクロスネットワーク構成を必要としません。ユニキャストを使用することによって、マルチキャスト・アドレスの競合によるネットワーク・エラーを回避します。
ユニキャスト・メッセージング・モードでは、チャンネルが構成されていないとサーバーのデフォルトのリスニング・ポートが使用されます。クラスタ・メンバーは、ブロードキャスト・メッセージ(通常はハートビート・メッセージ)を送信する必要がある場合、グループ・リーダーと通信します。クラスタ・メンバーがグループ・リーダーの障害を検出すると、その次に古いメンバーがグループ・リーダーになります。ユニキャスト・モードでの通信頻度は、マルチキャスト・ポートでのメッセージの送信頻度と同程度です。
ユニキャストを使用してクラスタ通信を処理する際に次の考慮事項が適用されます。
WebLogicクラスタのすべてのメンバーでは、同じメッセージ・タイプを使用する必要があります。マルチキャストとユニキャストのメッセージを混在させることはできません。
個々のクラスタ・メンバーでは、クラスタのメッセージ・タイプのオーバーライドはできません。
メッセージ・モードをユニキャストからマルチキャストまたはマルチキャストからユニキャストに変更するには、クラスタ全体を停止してから再起動する必要があります。
マルチキャスト通信用に構成されたJMSトピックは、ユニキャスト通信用に構成されたWebLogicクラスタにアクセスできます。クラスタ・アドレスとは関係なく固有のマルチキャスト・アドレスでJMSトピックがメッセージを発行するためです。ただし、次の考慮事項が適用されます。
クラスタでユニキャスト通信が可能なルーター・ハードウェア構成では、JMSマルチキャスト・サブスクライバが機能できない場合があります。
JMSマルチキャスト・サブスクライバでは、マルチキャスト・アクセスが可能なネットワーク・ハードウェア構成で動作する必要があります。つまり、JMSサブスクライバは、マルチキャストのトピックにアクセスするために、マルチキャスト対応ネットワークで動作する必要があります。
