| Oracle® Fusion Middleware Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド 11gリリース2 (11.1.2.2.0) B71694-10 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド 11gリリース2 (11.1.2.2.0) B71694-10 |
|
前 |
次 |
この章では、Oracle Identity and Access Managementインフラストラクチャのエンタープライズ・デプロイメント・トポロジの前提条件について説明します。
この章の内容は次のとおりです。
様々な種類のネットワーク・トラフィックや監視に対応するように、仮想サーバーや関連するポートをロード・バランサに構成する必要があります。これらの仮想サーバーは、サービスを実行するために適切な実際のホストおよびポートに対して構成する必要があります。また、ロード・バランサは、可用性を確保するために実際のホストおよびポートを監視するように構成し、サービスがダウンしたときにこれらのホストおよびポートへのトラフィックをできるだけ早く停止できるようにする必要があります。これにより、特定の仮想ホストの受信トラフィックが、他の層にある使用できないサービスに送信されないようになります。
第2.3項「トポロジの理解」のデプロイメント・トポロジの図に示すように、各デプロイメントは複数のゾーン間に広げることができます。ゾーンは、インフラストラクチャのコンポーネントへのアクセスを実際にアクセスを必要とする人に制限する方法です。このガイドの例では、2つのゾーンを示します。
パブリック・ゾーン: ここでは外部からシステムにアクセスできます。ロード・バランサやWeb層など外部からアクセスする必要があるコンポーネントのみをこのゾーンに配置します。このゾーンの下の任意のサーバーまたはサービスに外部のユーザーがアクセスしようとすると、ファイアウォールがアクセスを阻止します。
パブリック・ゾーンは、このゾーンのサーバーがプライベート・ゾーンのアプリケーション・サーバーとやり取りできるように構成されます。
イントラネットゾーン: これは、データベースなどのコア・サービスを含むサーバーを配置する場所です。これらのサービスは、最も機密性の高いデータが含まれているため、組織によって非常に厳密に制御されます。
この方法を使用することによって、情報を必要とするコンポーネントのみに情報へのアクセスを制限します。この方法は、組織の外部のユーザーがいる場合に有効です。
エクストラネットのかわりに(すべての通信が信頼できるソースからである)イントラネットを設定している場合、ゾーンの1つまたは複数を合理的に廃棄できる場合があります。
仮想サーバー名は、組織で使用される実際のホスト名のIDを隠すために使用され、アプリケーションへのエントリ・ポイントとして使用されます。
仮想サーバー名を使用する利点の1つは、新しいホスト名でアプリケーションを再構成する必要なく、バックエンド・サーバー名を変更できることです。
仮想サーバー名を使用する他の利点は、これらのサーバー名をロード・バランサに追加することで、ロード・バランサで単一の名前を使用して、同じ機能の複数のバックエンド・サーバー間でリクエストを分散できることです。これにより、可用性が実現し、スケーラビリティを簡単に向上できます。
ロード・バランサに追加すると、アプリケーションとクライアント間で暗号化されたトラフィックの維持をアプリケーションで可能にする、SSLをロード・バランサで終了することもできますが、同時に、各コンポーネント間でトラフィックを暗号化する必要なく、アプリケーションを効率的に実行できます。
仮想サーバー名は、組織のDNSサーバーに含まれます。外部アプリケーションのエントリは外部DNSサーバーに構成されます。
これにより、公衆アクセス・ポイントがインターネットで解決可能になり、プライベート・アクセス・ポイントを組織内でのみ使用可能にすることができます。
Premのみ:
IDSTORE.mycompany.comやIDMINTERNALなどの仮想サーバーの一部では、DNSから一緒に除外し、使用中のこれらのサーバーのみを解決する必要が生じる場合があります。
両方:
仮想サーバー名は単一のIPアドレスに解決されます。このIPアドレスは、ロード・バランサの仮想ホストに関連付けられます。
Exalogic:
仮想サーバー名がIPアドレスと関連付けられており、DNSの一部になっていることを確認してください。Oracle Fusion Middlewareを実行するコンピュータでは、これらの仮想サーバー名を解決できる必要があります。
第3.4項「ハードウェア・ロード・バランサの構成」の手順に従って、ロード・バランサで仮想サーバー名を定義します。
このガイドの残りの部分では、デプロイメントは第2章「導入と計画」で示したデプロイメントの1つであることを前提とします。
この仮想サーバーは、すべてのアイデンティティ・ストアのLDAPトラフィックのアクセス・ポイントとして機能します。SSLと非SSLの両方へのトラフィックが構成されます。クライアントは、アドレスIDSTORE.mycompany.com:636 (SSLの場合)およびIDSTORE.mycompany.com:389(非SSLの場合)を使用してこのサービスにアクセスします。
Oracle Unified Directoryのアイデンティティ・ストアが直接アクセスされたため、Oracle Unified Directoryプロセスのハートビートを監視する必要があります。Oracle Unified Directoryプロセスが停止した場合、ロード・バランサは稼動しているOracle Unified DirectoryインスタンスへのLDAPトラフィックのルーティングを継続する必要があります。
この仮想サーバーは、ポート389 (LDAP_LBR_PORT)で受信したトラフィックを、ポート1389 (LDAP_DIR_PORT)でOracle Unified Directoryの各インスタンスに転送します。
この仮想サーバーは、ポート1636 (LDAP_LBR_SSL_PORT)で受信したトラフィックを、ポート1636 (LDAP_DIR_SSL_PORT)でOracle Unified Directoryの各インスタンスに転送します。
この仮想サーバーは、ローカル(Exalogic内)でのみ解決可能です。
この仮想サーバーは、アクセス・ドメイン内の管理サービスに送信されるすべての内部HTTPトラフィック用のアクセス・ポイントとして機能します。クライアントからの受信トラフィックはすべて非SSLに対応しています。このため、クライアントはアドレスIADADMIN.mycompany.com:80を使用してこのサービスにアクセスし、トラフィックはWEBHOST1およびWEBHOST2のポート7777 (WEB_HTTP_PORT)に転送されます。この仮想ホスト上でアクセスされるサービスには、WebLogic管理サーバー・コンソール、Oracle Enterprise Manager Fusion Middleware Controlなどがあります。
この仮想サーバーは、企業のDNSでのみ解決可能です。
ファイアウォールでルールを作成し、この仮想ホストを使用して外部トラフィックが/console、/oamconsole、/oaam_adminおよび/emのURLにアクセスすることを防止します。DMZ内部のトラフィックのみがIADADMINVHN.mycompany.com仮想ホスト上のこれらのURLにアクセスできる必要があります。
この仮想サーバーは、ガバナンス・ドメイン内の管理サービスに送信されるすべての内部HTTPトラフィック用のアクセス・ポイントとして機能します。クライアントからの受信トラフィックはすべて非SSLに対応しています。このため、クライアントはアドレスIGDADMIN.mycompany.com:80 (HTTP_PORT)を使用してこのサービスにアクセスし、続いてトラフィックがWEBHOST1およびWEBHOST2のポート7777(WEB_HTTP_PORT)に転送されます。この仮想ホストでアクセスされるサービスには、WebLogic管理サーバー・コンソール、Oracle Enterprise Manager Fusion Middleware Control、Oracle Authorization Policy Managerなどがあります。
ファイアウォールでルールを作成し、この仮想ホストを使用して外部トラフィックが/sysadmin、/apm、/consoleおよび/emのURLにアクセスすることを防止します。DMZ内部のトラフィックのみがIGDADMINVHN.mycompany.com仮想ホスト上のこれらのURLにアクセスできる必要があります。
この仮想サーバーは、企業のDNSでのみ解決可能にする必要があります。
クライアントからの受信トラフィックはすべて非SSLに対応しています。このため、クライアントはアドレスIDMINTERNAL.mycompany.com:80を使用してこのサービスにアクセスし、トラフィックはWEBHOST1およびWEBHOST2のポート7777 (WEB_HTTP_PORT)に転送されます。SOA管理対象サーバーは、この仮想ホストにアクセスして、Oracle Identity Manager Webサービスのコールバックを行います。
ファイアウォールでルールを作成し、外部トラフィックがこの仮想ホストにアクセスすることを防止します。DMZ内部のトラフィックのみがIDMINTERNAL.mycompany.com仮想ホスト上のこれらのURLにアクセスできる必要があります。
この仮想サーバーは、ローカルまたは企業のDNSのいずれかで解決可能にする必要があります。
IDMINTERNALはプロセス間通信用に設計されているため、これをDNSには含めず、内部ホスト・ファイル内でのみ解決可能にすることが期待されます。
これは、すべてのIdentity and Access Managementコンポーネント(Access Management、Oracle Identity Managerなど)に対する仮想名です。
この仮想サーバーは、シングル・サインオン・サービスへ送信されるすべてのHTTPトラフィックのアクセス・ポイントとして機能します。クライアントからの受信トラフィックはSSLに対応しています。このため、クライアントはアドレスSSO.mycompany.com:443を使用してこのサービスにアクセスし、トラフィックはWEBHOST1およびWEBHOST2のポート7777 (WEB_HTTP_PORT)に転送されます。シングル・サインオン対応の保護リソースへのアクセスは、すべてこの仮想ホスト上で行われます。
ロード・バランサでポート80 (HTTP_PORT)とポート443 (HTTP_SSL_PORT)の両方を使用してこの仮想サーバーを構成します。
この仮想サーバーは、ローカルまたは企業のDNSのいずれかで解決可能にする必要があります。
この仮想ホストは、リクエストのクライアントIPアドレスを保持するように構成する必要があります。一部のロード・バランサでは、ロード・バランサを有効にしてリクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入することにより、これを構成します。
ハードウェア・ロード・バランサは、アプリケーション(この場合はOracle Identity and Access Management)から、アプリケーション・コンポーネントを構成する各ホストにリクエストを送信します。
ロード・バランサは仮想ホストとともに構成されます。各仮想ホストは、ロード・バランサで提供される異なるIPアドレスに関連付けられます。ロード・バランサの仮想ホストは、次に、デプロイメントのWebサーバーで構成される元のサーバーのプールに関連付けられます。
様々な種類のネットワーク・トラフィックや監視に対応するように、仮想サーバーや関連するポートをロード・バランサに構成する必要があります。これらは、サービスを実行する適切な実際のホストおよびポートに対してリクエストをルーティングするように構成する必要があります。ロード・バランサは、可用性を確保するために実際のホストおよびポートを監視するように構成し、サービスがダウンしたときにこれらのホストおよびポートへのトラフィックをできるだけ早く停止できるようにする必要があります。これにより、特定の仮想ホストの受信トラフィックが、他の層にある使用できないサービスに送信されないようになります。
推奨トポロジ内には、2つのロード・バランサ・デバイスがあります。一方のロード・バランサは外部HTTPトラフィック用に設定し、もう一方のロード・バランサは内部LDAPトラフィック用に設定します。様々な理由から、デプロイメントで使用されるロード・バランサ・デバイスが1つになる場合があります。このような構成もサポートされていますが、これに伴うセキュリティへの影響を考慮する必要があります。その構成が適切であることがわかったら、様々なゾーン間のトラフィックを許可するように、関連するファイアウォール・ポートを開いてください。いずれの場合も、特定のロード・バランサ・デバイスをフォルト・トレラント・モードでデプロイすることを強くお薦めします。
この項には次のトピックが含まれます:
このエンタープライズ・トポロジでは、外部のロード・バランサを使用します。この外部ロード・バランサは次の機能を備えている必要があります。
仮想サーバー名を使用してトラフィックを実際のサーバーのプールにロード・バランシングする機能: クライアントは仮想サーバー名を使用してサービスにアクセスします(実際のサーバー名は使用しない)。ロード・バランサは、リクエストをプールのサーバーにロード・バランスできるようになります。
ポート変換の構成。
ポート(HTTPおよびHTTPS)の監視。
仮想サーバーとポート構成: 外部ロード・バランサの仮想サーバー名とポートを構成する機能。仮想サーバー名とポートは次の要件を満たす必要があります。
ロード・バランサは複数の仮想サーバーの構成が可能である必要がある。各仮想サーバーに対して、ロード・バランサは複数のポート上でトラフィック管理の構成を行える必要があります。たとえば、Oracle WebLogicクラスタの場合は、1つの仮想サーバーとHTTPおよびHTTPSの両トラフィック用のポートを指定してロード・バランサを構成する必要があります。
仮想サーバー名は、IPアドレスに関連付けられていて、DNSの一部である必要がある。クライアントは仮想サーバー名を使用して外部ロード・バランサにアクセスできる必要があります。
ノードの障害を検出し、障害のあるノードへのトラフィックのルーティングを即時に停止する機能。
リソースの監視/ポートの監視/プロセス障害の検出: ロード・バランサは、サービス障害およびノード障害を(通知またはその他の方法によって)検出し、障害のあるノードへの非Oracleネット・トラフィックの転送を停止する必要があります。ご使用の外部ロード・バランサに障害の自動検出機能がある場合、これを使用する必要があります。
フォルト・トレラント・モード: ロード・バランサはフォルト・トレラント・モードで構成することを強くお薦めします。
スティッキーなルーティング機能: CookieまたはURLに基づくコンポーネントへのスティッキーな接続を維持する機能
その他: トラフィックの転送先となるバックエンド・サービスが使用不可の場合に、即座にコール元クライアントに戻るようにロード・バランサの仮想サーバーを構成しておくことを強くお薦めします。これは、クライアントのマシンのTCP/IP設定に基づくタイムアウトの後、自ら接続解除するクライアントに対して好ましい構成です。
SSLアクセラレーション: SSLトランザクションで実行され、公開鍵暗号化アルゴリズムをハードウェア・アクセラレータにオフロードします。この機能は推奨されますが、必須ではありません。
SSLリクエストをロード・バランサで終了して、同等の非SSLプロトコルを使用してトラフィックを実際のバックエンド・サーバーに転送する機能。たとえば、ロード・バランサは、HTTPSリクエストをHTTPとして転送できる必要があります。この機能は「SSL終端」と呼ばれることがあります。これは、このエンタープライズ・デプロイメントで必要です。
クライアントIPアドレスを保持する機能: ロード・バランサには、リクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入し、クライアントIPアドレスを保持する機能がある必要があります。
WL-Proxy-SSL: trueをHTTP要求ヘッダーに追加する機能。これを自動で行うロード・バランサもあります。
ロード・バランサの構成手順は、ロード・バランサの特定のタイプによって異なります。実際の手順は、ベンダーが提供するドキュメントを参照してください。次の手順では、一般的な構成フローを示します。
サーバーのプールを作成します。このプールには、ロード・バランシング定義に含まれるサーバーおよびポートのリストが存在します。たとえば、Webホスト間のロード・バランシングの場合、リクエストをポート7777 (WEB_HTTP_PORT)で受信するトポロジのWebサーバーに、リクエストを送信するサーバーのプールを作成します。
特定のホストとサービスが使用可能かどうかを決定するルールを作成し、手順1で説明したサーバーのプールに割り当てます。
ロード・バランサ上に仮想サーバーを作成します。これは、アプリケーションにより使用されるリクエストを受信するアドレスとポートです。たとえば、Web層のリクエストをロード・バランシングするには、SSO.mycompany.com:80に対する仮想サーバーを作成します。
ロード・バランサでサポートされている場合は、仮想サーバーが内部から、外部から、またはその両方から利用できるのかどうかを指定します。内部アドレスはネットワーク内からのみ解決可能であることを確認します。
適用可能な場合は、仮想サーバーに対するSSL終端を構成します。
手順1で作成したサーバーのプールを、仮想サーバーに割り当てます。
表3-3「Oracle Identity and Access Managementエンタープライズ・デプロイメント・トポロジで使用されるポート」にリストされているタイムアウト設定を調整します。これには、サービスが停止しているかどうかを検出する時間も含まれます。
Identity and Access Managementデプロイメントの場合、表3-1に示すようにロード・バランサを構成します。
表3-1 ロード・バランサの構成
| 仮想ホスト | サーバー・プール | プロトコル | SSL終端 | 外部 | 必要なその他の構成/コメント |
|---|---|---|---|---|---|
|
|
|
HTTP |
いいえ |
はい |
Identity and Access Managementでは、次のコードをHTTPヘッダーに追加する必要があります。
|
|
|
|
HTTPS |
はい |
はい |
Identity and Access Managementでは、次のコードをHTTPヘッダーに追加する必要があります。
|
|
|
|
HTTP |
いいえ |
いいえ |
|
|
|
|
HTTP |
いいえ |
いいえ |
|
|
|
|
HTTP |
いいえ |
いいえ |
|
|
|
|
LDAP |
いいえ |
いいえ |
Identity and Access ManagementユーザーがOracle Unified Directoryに格納されている場合のみ必要です。 |
|
|
|
LDAPS |
いいえ |
いいえ |
Identity and Access ManagementユーザーがOracle Unified Directoryに格納されている場合のみ必要です。 |
仮想IPアドレスは、ホストの主要IPアドレスと同じサブネットに属する、未使用のIPアドレスです。このアドレスはホストに手動で割り当てられ、Oracle WebLogic管理対象サーバーはこのIPアドレスをリスニングするように構成されます。障害が発生した場合、割り当てられた管理対象サーバーの実行を新しいノードが引き継ぐことができるように、IPアドレスが同じサブネット内の別のノードに割り当てられます。
次に、Oracle Identity and Access Managementが必要とする仮想IPアドレスのリストを示します。
IADADMINVHN.mycompany.com
エンタープライズ・デプロイメントでは、WebLogic管理サーバーが、配置されているホストに障害が発生した後でも、リクエストの処理を継続できることが必要です。仮想IPアドレスは、アプリケーション層内の任意のホスト上でネットワーク・インタフェースにバインドできるように、アプリケーション層内でプロビジョニングされる必要があります。WebLogic管理サーバーは、後でこの仮想IPアドレスをリスニングするように構成されます。これについては、本ドキュメントで後述します。この仮想IPアドレスは、管理サーバーとともに、OAMHOST1からOAMHOST2に(またはその逆に)フェイルオーバーします。
IGDADMINVHN.mycompany.com
エンタープライズ・デプロイメントでは、WebLogic管理サーバーが、配置されているホストに障害が発生した後でも、リクエストの処理を継続できることが必要です。仮想IPアドレスは、アプリケーション層内の任意のホスト上でネットワーク・インタフェースにバインドできるように、アプリケーション層内でプロビジョニングされる必要があります。WebLogic管理サーバーは、後でこの仮想IPアドレスをリスニングするように構成されます。これについては、本ドキュメントで後述します。この仮想IPアドレスは、管理サーバーとともに、OIMHOST1からOIMHOST2に(またはOIMHOST2からOIMHOST1に)フェイルオーバーします。
SOAHOSTxVHN.mycompany.com
SOA管理対象サーバーごとに1つの仮想IPアドレスが必要です。これにより、サーバーをサーバー移行の処理対象にすることができます。
アプリケーション層内で仮想IPアドレスをプロビジョニングすることにより、アプリケーション層にある任意のホストのネットワーク・インタフェースにこのアドレスをバインドできるようにします。
OIMHOSTxVHN.mycompany.com
Oracle Identity Manager管理対象サーバーごとに1つの仮想IPアドレスが必要です。これにより、サーバーをサーバー移行の処理対象にすることができます。
アプリケーション層内で仮想IPアドレスをプロビジョニングすることにより、アプリケーション層にある任意のホストのネットワーク・インタフェースにこのアドレスをバインドできるようにします。
図3-0に示すように、異なる仮想IPと物理IPでリスニングするように、管理サーバーと管理対象サーバーを構成してください。
表3-2には、各種の仮想ホストの説明が記載されています。
表3-2 VIPアドレスおよび仮想ホスト
| 仮想IP | VIPのマップ先 | 説明(統合) | デフォルト・ホスト(統合) | デフォルト・ホスト(分散) |
|---|---|---|---|---|
|
VIP1 |
IADADMINVHN |
IADADMINVHNは、管理サーバーのリスニング・アドレスである仮想ホスト名であり、管理サーバーの手動フェイルオーバーによりフェイルオーバーします。管理サーバー・プロセスが実行されているノードで有効化されます。 |
IAMHOST1 |
OAMHOST1 |
|
VIP2 |
IGDADMINVHN |
IGDADMINVHNは、Oracle Identity Manager管理サーバーのリスニング・アドレスとなる仮想ホスト名です。これは、管理サーバーの手動フェイルオーバーに伴ってフェイルオーバーします。これは、Oracle Identity Manager管理サーバー・プロセスが実行されているノードで有効化されます。 |
IAMHOST1 |
OIMHOST1 |
|
VIP3 |
SOAHOST1VHN |
SOAHOST1VHNは、WLS_SOA1のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。WLS_SOA1プロセスが実行されているノードで有効化されます。 |
IAMHOST1 |
OIMHOST1 |
|
VIP4 |
OIMHOST1VHN |
OIMHOST1VHNは、WLS_OIM1サーバーのリスニング・アドレスにマップし、このサーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_OIM1プロセスが実行されているノードで有効化されます。 |
IAMHOST1 |
OIMHOST1 |
|
VIP5 |
SOAHOST2VHN |
SOAHOST2VHNは、WLS_SOA2のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。WLS_SOA2プロセスが実行されているノードで有効化されます。 |
IAMHOST2 |
OIMHOST2 |
|
VIP6 |
OIMHOST2VHN |
OIMHOST2VHNは、WLS_OIM2サーバーのリスニング・アドレスにマップし、このサーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_OIM2プロセスが実行されているノードで有効化されます。 |
IAMHOST2 |
OIMHOST2 |
多くのOracle Fusion Middlewareコンポーネントとサービスではポートを使用します。管理者はこれらのサービスに使用するポート番号を把握し、ホスト上の2つのサービスが同じポート番号を使用しないようにする必要があります。
ほとんどのポート番号はインストール後に割り当てられます。必要に応じて別のポート番号を使用できます。表3-3に示したポート番号は、一貫性を保つためにこのガイド全体にわたって使用する例です。別のポート番号を使用する場合、その値が使用される場所では必ずその値を表の値のかわりに使用する必要があります。
表3-3は、Oracle Identity and Access Managementトポロジで使用されるポートの一覧です。これには、トポロジ内のファイアウォール上で開く必要があるポートが含まれます。
ファイアウォールの表記法
FW0は、最も外側のファイアウォールを表します。
FW1は、Web層とアプリケーション層の間のファイアウォールを表します。
FW2は、アプリケーション層とデータベース層の間のファイアウォールを表します。
表3-3 Oracle Identity and Access Managementエンタープライズ・デプロイメント・トポロジで使用されるポート
| タイプ | ファイアウォール | ポートとポートの範囲 | プロトコル/アプリケーション | インバウンド/アウトバウンド | タイムアウト |
|---|---|---|---|---|---|
|
ブラウザ・リクエスト |
FW0 |
80 |
HTTP/ロード・バランサ |
両方 |
Oracle Identity and Access Managementで使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツに応じて、タイムアウトは異なります。 |
|
ブラウザ・リクエスト |
FW0 |
443 |
HTTPS/ロード・バランサ |
両方 |
Oracle Identity and Access Managementで使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツに応じて、タイムアウトは異なります。 |
|
ブラウザ・リクエスト |
FW1 |
80 |
HTTPS/ロード・バランサ |
アウトバウンド(イントラネット・クライアント) |
タイムアウトは、IAMによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。 |
|
ブラウザ・リクエスト |
FW1 |
443 |
HTTPS/ロード・バランサ |
アウトバウンド(イントラネット・クライアント) |
タイムアウトは、IAMによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。 |
|
ロード・バランサからOracle HTTP Serverへ |
n/a |
7777 |
HTTP |
n/a |
第3.4項「ハードウェア・ロード・バランサの構成」を参照してください。 |
|
管理サーバーによるOHS登録 |
FW1 |
7001 |
HTTP/t3 |
インバウンド |
タイムアウトを短い時間(5から10秒)に設定します。 |
|
Oracle Weblogic管理サーバー(IAMAccessDomain)へのWeb層アクセス |
FW1 |
7001 |
HTTP/Oracle HTTP Serverと管理サーバー |
インバウンド |
N/A |
|
Oracle Weblogic管理サーバー(IAMGovernanceDomain)へのWeb層アクセス |
FW1 |
7101 |
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 Server WLS_OIM |
FW1 |
14000 |
HTTP/Oracle HTTP ServerからWebLogic Serverへ |
インバウンド |
使用されるmod_weblogicパラメータに応じて、タイムアウトは異なります。 |
|
Oracle HTTP Server WLS_SOA |
FW1 |
8001 |
HTTP/Oracle HTTP ServerからWebLogic Serverへ |
両方 |
使用されるmod_weblogicパラメータに応じて、タイムアウトは異なります。 |
|
管理サーバーによるOracle HTTP Serverの管理 |
FW1 |
OPMNリモート・ポート(6701)およびOHS管理ポート(7779) |
それぞれTCPとHTTP |
アウトバウンド |
タイムアウトを短い時間(5-10秒など)に設定します。 |
|
Access Managerサーバー |
FW1 |
5575 |
OAP |
両方 |
N/A |
|
Access Manager Coherenceポート |
FW1 |
9095 |
TCMP |
両方 |
N/A |
|
OAAMサーバー・ポート |
FW1 |
14300 |
HTTP/Enterprise Manager |
両方 |
N/A |
|
OAAM管理ポート |
FW1 |
14200 |
HTTP/Enterprise Manager |
両方 |
N/A |
|
Oracle Coherenceポート |
FW1 |
8000 - 8088 |
TCMP |
両方 |
N/A |
|
WLS_OAAMから管理サーバー |
FW2 |
OPMNリモート・ポート |
HTTP/管理サーバーからOPMNへ |
インバウンド |
N/A |
|
アプリケーション層からデータベース・リスナーへ |
FW2 |
1521 |
SQL*Net |
両方 |
Oracle Identity and Access Managementで使用されるプロセス・モデルのタイプとすべてのデータベース・コンテンツに応じて、タイムアウトは異なります。 |
|
Oracle Notification Server (ONS) |
FW2 |
6200 |
ONS |
両方 |
Gridlink用に必要。ONSサーバーは各データベース・サーバー上で稼働します。 |
|
OUDポート |
FW2 |
1389 |
LDAP |
インバウンド |
理想的には、タイムアウトが発生しないようにこれらの接続を構成します。 |
|
OUD SSLポート |
FW2 |
14636 |
LDAPS |
インバウンド |
理想的には、タイムアウトが発生しないようにこれらの接続を構成します。 |
|
ロード・バランサLDAPポート |
FW2 |
386 |
LDAP |
インバウンド |
理想的には、タイムアウトが発生しないようにこれらの接続を構成します。 |
|
ロード・バランサLDAP SSLポート |
FW2 |
636 |
LDAPS |
インバウンド |
理想的には、タイムアウトが発生しないようにこれらの接続を構成します。 |
|
ノード・マネージャ |
N/A |
5556 |
TCP/IP |
N/A |
該当なし |
|
Oracle Unified Directoryレプリケーション |
該当なし |
8989 |
TCP/IP |
該当なし |
該当なし |
|
注意: 外部ドメイン(SOA、WebCenter Portalドメインなど)のアプリケーションをこのIdentity and Access Managementドメインで認証できるように、ファイアウォール間で追加のポートを開く必要が生じることがあります。 |
ここでは、Oracle Accessプロトコル(OAP)について説明し、ユーザー・リクエストの概要を示します。
この項には次のトピックが含まれます:
Oracle Accessプロトコル(OAP)は、ユーザー認証および認可の間に、アクセス・システム・コンポーネント(Access Managerサーバー、Webゲートなど)間の通信を可能にします。このプロトコルは、以前NetPointアクセス・プロトコル(NAP)またはCOREidアクセス・プロトコルと呼ばれていました。
Oracle Access Management Access Managerは、ユーザーのセッションを作成します。Identity and Access Managementが別のアイデンティティ管理コンポーネント(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プロトコルを使用してリクエストをAccess Managerサーバーに転送し、リソースが保護されているかどうか、どのように保護されているか、またユーザーが認証されているかどうかを判別します(認証されていない場合は、チャレンジが行われます)。
Access Managerサーバーは、ユーザーIDやパスワードなどの資格証明についてディレクトリ・サーバーを確認し、Oracle Accessプロトコルを使用してWebゲートに情報を送り返し、ユーザーを認証するための暗号化Cookieを生成します。
認証の後、WebゲートはOracle Accessプロトコルを使用してAccess Managerサーバーに指示し、Access Managerサーバーは該当するセキュリティ・ポリシーを検索してユーザーのアイデンティティと比較し、ユーザーの認証レベルを判別します。
アクセス・ポリシーが有効な場合、ユーザーは目的のコンテンツまたはアプリケーション(あるいはこれら両方)へのアクセスを許可されます。
ポリシーが偽の場合、ユーザーはアクセスを拒否され、組織の管理者が決めた別のURLにリダイレクトされます。
トポロジにあるノードはユニキャスト通信を使用して通信することをお薦めします。マルチキャスト通信と異なり、ユニキャストはクロスネットワーク構成を必要としません。ユニキャストを使用することによって、マルチキャスト・アドレスの競合によるネットワーク・エラーを回避します。
ユニキャスト・メッセージング・モードでは、チャンネルが構成されていないとサーバーのデフォルトのリスニング・ポートが使用されます。クラスタ・メンバーは、ブロードキャスト・メッセージ(通常はハートビート・メッセージ)を送信する必要がある場合、グループ・リーダーと通信します。クラスタ・メンバーがグループ・リーダーの障害を検出すると、その次に古いメンバーがグループ・リーダーになります。ユニキャスト・モードでの通信頻度は、マルチキャスト・ポートでのメッセージの送信頻度と同程度です。
ユニキャストを使用してクラスタ通信を処理する際に次の考慮事項が適用されます。
WebLogicクラスタのすべてのメンバーでは、同じメッセージ・タイプを使用する必要があります。マルチキャストとユニキャストのメッセージを混在させることはできません。
個々のクラスタ・メンバーでは、クラスタのメッセージ・タイプのオーバーライドはできません。
メッセージ・モードをユニキャストからマルチキャストまたはマルチキャストからユニキャストに変更するには、クラスタ全体を停止してから再起動する必要があります。
マルチキャスト通信用に構成されたJMSトピックは、ユニキャスト通信用に構成されたWebLogicクラスタにアクセスできます。クラスタ・アドレスとは関係なく固有のマルチキャスト・アドレスでJMSトピックがメッセージを発行するためです。ただし、次の考慮事項が適用されます。
クラスタでユニキャスト通信が可能なルーター・ハードウェア構成では、JMSマルチキャスト・サブスクライバが機能できない場合があります。
JMSマルチキャスト・サブスクライバでは、マルチキャスト・アクセスが可能なネットワーク・ハードウェア構成で動作する必要があります。(つまり、JMSサブスクライバは、マルチキャストのトピックにアクセスするために、マルチキャスト対応ネットワークで動作する必要があります。)
|
注意: ユニキャストを使用してクラスタ通信を設定できますが、キャッシングに使用する場合、Oracle Identity Managerでは、マルチキャストを使用します(キャッシングに使用する場合)。このため、マシン間でマルチキャストを有効にする必要があります。 |
ネットワークを定義したら、すべてのネットワーク名が各計算ノード/vServerから解決可能であることを確認します。
これを行うには、各計算ノード/vServer上で次のコマンドを実行します。
ping -I interface hostname
