| Oracle® Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー1.1プラグインの使用 11g リリース1 (11.1.1) B61009-06 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー1.1プラグインの使用 11g リリース1 (11.1.1) B61009-06 |
|
前 |
次 |
この章では、すべてのWebサーバーに共通するOracleが提供したプラグインを構成するためのタスクを説明します。内容は以下のとおりです。
プラグインとOracle WebLogic Serverとの間の接続を保護するため、SSL (Secure Sockets Layer)プロトコルを使用できます。SSLプロトコルによって、プラグインとWebLogic Serverの間でやり取りされるデータに機密性と整合性がもたらされます。
プラグインは、プラグインとWebLogic Server間の接続の保護にSSLプロトコルが使用されるかどうかを決定する際に、(通常はブラウザによって)HTTPリクエストに指定されるトランスポート・プロトコル(httpまたはhttps)を使用しません。つまり、プラグインはHTTPリクエストが(通常はブラウザによって)HTTPS (SSL)を使用するかしないかに依存しません。
そのかわりに、プラグインは、7.2項「Webサーバー・プラグインのSSLパラメータ」に記載されているように、SSLをいつ使用をするかを決定するため、ユーザーがプラグインに対して構成したSSLパラメータを使用します。2つの重要なSSLパラメータがあります。
WLSSLWallet: バージョン1.1のプラグインは、OracleウォレットにSSL構成情報を格納します。プラグインは、Oracleウォレットを使用するために新しいSSL構成パラメータWLSSLWalletを導入します。そのため、orapkiユーティリティがプラグイン配布で提供されています。
orapkiユーティリティは、ウォレットおよび証明書失効リストなどの公開鍵インフラストラクチャ(PKI)の要素をコマンド・ラインで管理するので、実行するタスクをスクリプトに組み込むことができます。これによって、PKIを管理する多数のルーチン・タスクを自動化できます。
詳細は、「証明書の検証およびCRL管理用orapkiユーティリティの使用」を参照してください。
SecureProxy: SecureProxyパラメータは、SSLが有効化されるかどうかを決定します。
双方向SSLについては、Oracle WebLogic Serverが双方向SSL用に構成されていてクライアント証明書をリクエストする場合、プラグイン(SSLクライアント)は自動的に双方向SSLを使用します。
クライアント証明書がリクエストされない場合、プラグインはデフォルトで一方向SSLになります。
|
注意: Apache (Oracle HTTP Serverを含む)プラグインと同じシステムにOracle Fusion Middleware 11gR1製品がインストールされている場合、 たとえば、製品がきちんと削除されなかったために |
プラグインは、Oracleライブラリ(NZ)を使用して、SSLサポートを提供します。ライブラリは大きいため、SSLを使用する必要がある場合のみ、ロードされます。lib/*.so*にあるライブラリ・ファイルが、プラグインによって動的にロードされるように適切な場所に配置されていることを確認してください。
次に示す方法でApache HTTP Server用プラグインのライブラリを構成できます。
Windowsの場合: .dllファイルを含むlibディレクトリをPATH変数に指定するか、*.dllファイルをbinディレクトリにコピーします。
UNIXの場合: ライブラリを含むフォルダをポイントするようにLD_LIBRARY_PATHを構成するか、libディレクトリにライブラリをコピーします。
PATH (Windows)またはLD_LIBRARY_PATH (UNIX)変数を更新するかわりにライブラリをコピーする方法を選択した場合、プラグインの新しいバージョンをインストールするたびにライブラリをコピーし直す必要があります。
一方向SSLを構成するには、次の手順を実行します。
この手順では、WebLogic Serverがインストールされているシステム上でkeytoolコマンドを実行します。また、バージョン1.1のプラグインがインストールされているシステム上でorapkiコマンドを実行します。
|
注意: この項で取り上げられる例では、WebLogic ServerのデモCAが使用されています。本番環境でプラグインを使用している場合、プラグインおよびOracle WebLogic Server用に信頼性のあるCAが正常に構成されていることを確認してください。 |
Oracle WebLogic ServerをSSL用に構成します。詳細は、『Oracle WebLogic Serverの保護』のSSLの構成に関する項を参照してください。
orapkiユーティリティを使用してOracleウォレットを作成します。
orapki wallet create -wallet mywallet -auto_login_only
詳細は、『Oracle Fusion Middleware管理者ガイド』の証明書の検証およびCRL管理用orapkiユーティリティの使用に関する項を参照してください。
|
注意: ウォレットの作成ユーザー(Windowsの場合はSYSTEMアカウント)のみがウォレットへのアクセス権を持ちます。 通常、WindowsではSYSTEMアカウント、UNIXではウォレットの作成ユーザーとしてApacheが実行されるため、Apacheプラグインではこれで十分です。ただし、IISの場合、デフォルト・ユーザーがIUSR_<Machine_Name>(IIS6.0以下)またはIUSR (IIS7.0以上)であるため、ウォレットは機能しません。 ApacheプラグインまたはIISプラグインを実行するユーザーがウォレットの作成ユーザー(Windowsの場合はSYSTEMアカウント)と同一ではない場合、ウォレットの作成後に IIS 6.0:
IIS 7.5:
|
WL_HOME\server\lib\CertGenCA.derのCAをOracleウォレットにインポートします。
orapki wallet add -wallet mywallet -trusted_cert -cert CertGenCA.der -auto_login_only
Webサーバーの構成ファイルを次のように構成します。
Apache HTTP Serverの場合、httpd.confファイルを次のように編集します。
<IfModule mod_weblogic.c> WebLogicHost host WebLogicPort port SecureProxy ON WLSSLWallet path_to_wallet </IfModule>
Microsoft IISの場合、iisproxy.iniファイルを次のように編集します。
WebLogicHost=host WebLogicPort=port SecureProxy=ON WLSSLWallet=path_to_wallet
これらの例で使用されているパラメータに関する詳細情報は、第7章「Web Serverプラグインのパラメータ」を参照してください。
バックエンドのOracle WebLogic Serverのインスタンスが10.3.4以降の場合、次の手順に従います。
Oracle WebLogic Serverの管理コンソールにログインします。
「ドメイン構造」ペインで、「環境」ノードを展開します。
Oracle HTTP Serverからリクエストをプロキシするサーバー・インスタンスがクラスタにある場合、「クラスタ」を選択します。
その他の場合は、「サーバー」を選択します。
Oracle HTTP Serverからリクエストをプロキシするサーバーまたはクラスタを選択します。
「構成: 一般」タブが表示されます。
「詳細」セクションまでスクロール・ダウンし、展開します。
「WebLogicプラグインの有効化」チェックボックスを選択します。
「クライアント証明書プロキシの有効化」チェックボックスを選択します。
ステップbで「サーバー」を選択した場合、Oracle HTTP Serverからリクエストをプロキシする他のサーバーに対してステップcとdを繰り返します。
「保存」をクリックします。
サーバー・インスタンスを再起動したら変更が適用されます。
ブラウザからhttp://host:port/mywebapp/my.jspにリクエストを送信し、レスポンスを検証します。
Oracle WebLogic Serverが双方向SSL用に構成されている場合、プラグインはユーザー証明書をWebLogic Serverに転送します。WebLogic Serverがユーザー証明書を検証できるかぎり、双方向SSLを確立できます。
6.1.2項「一方向SSL用プラグインの構成」で説明した手順に加えて、次の手順も実施します。
この手順では、WebLogic Serverがインストールされているシステム上でkeytoolコマンドを実行します。バージョン1.1プラグインがインストールされているシステム上でorapkiコマンドを実行します。
Oracleウォレットから証明書リクエストを作成します。
この証明書リクエストを使用して、CAまたはその他の方法で証明書を作成します。
WebLogic信頼ストアにユーザー証明書を信頼性のある証明書としてインポートします。証明書はOracle WebLogic Serverによって信頼される必要があります。
keytool -file user.crt -importcert -trustcacerts -keystore DemoTrust.jks -storepass <passphrase>
クライアント証明書(双方向SSL用)のプレゼンテーションを必要とするWebLogic Server SSL構成オプションを設定します。詳細は、Oracle WebLogic Server管理コンソール・ヘルプの双方向SSLの構成に関する項を参照してください。
バージョン1.1プラグインは、IPv6をサポートしています。具体的には、WebLogicHostおよびWebLogicClusterの構成パラメータ(表7-1を参照)は、IPv6アドレスをサポートするようになっています。例:
<IfModule mod_weblogic.c> WebLogicHost [a:b:c:d:e:f] WebLogicPort 7002 ... </IfModule>
または
<IfModule mod_weblogic.c> WebLogicCluster [a:b:c:d:e:f]:<port>, [g:h:i:j:k:l]:<port> .... </IfModule>
IPv6アドレスでマップされているホスト名を使用できます。
|
注意: Windows 2008の時点では、DNSサーバーはIPv4アドレスにプリファレンスしてIPv6アドレスを返します。IPv4を使用してWindows 2008 (以降)に接続している場合、ローカル・リンクIPv6アドレス形式が最初に試行され、結果的に遅延が目立ちパフォーマンスが落ちる場合があります。IPv4アドレス形式を使用するには、システムを構成して構成ファイルでかわりのIPアドレスを使用するか、またはIPv4アドレスを また、 |
プラグインを介してアクセスするWebLogic Serverアプリケーションを保護するには、境界認証を使用します。
WebLogic IDアサーション・プロバイダは、WebLogic Serverアプリケーションにアクセスする外部システム(プラグインを通じてWebLogic Serverアプリケーションにアクセスするユーザーを含む)からのトークンを認証します。使用しているプラグインを安全に保護するIDアサーション・プロバイダを次のように作成します。
WebLogic ServerアプリケーションにカスタムIDアサーション・プロバイダを作成します。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のカスタムIDアサーション・プロバイダの開発方法に関する項を参照してください。
Certトークン・タイプをサポートするようにカスタムIDアサーション・プロバイダを構成し、Certをアクティブなトークン・タイプにします。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の新しいトークン・タイプの作成方法に関する項を参照してください。
Webアプリケーションのweb.xmlのデプロイメント記述子ファイルでclientCertProxyをTrueに設定します(または、クラスタを使用している場合、必要に応じて、「管理コンソール・クラスタ」->「構成」->「一般」タブで、クラスタ全体に対して「クライアント証明書プロキシの有効化」属性をtrueに設定します)。
ロード・バランサまたはSSLアクセラレータなどサード・パーティ・プロキシ・サーバーでclientCertProxy属性を使用して双方向SSL認証を有効にすることができます。clientCertProxy属性の詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のcontext-paramを参照してください。
clientCertProxyを設定したら、接続フィルタを使用して、WebLogic Serverが、プラグインを実行しているマシンからの接続のみを受け入れるようにします。『Oracle WebLogic Serverセキュリティのプログラミング』のネットワーク接続フィルタの使用に関する項を参照してください。
Webサーバー・プラグインでは、プラグインとWebLogic Serverの間にSSLを使用するには、信頼性のある認証局のファイルが存在する必要があります。SSLを構成するために行う必要がある手順は、6.1項「プラグインでのSSLの使用」を参照してください。
『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のIDアサーション・プロバイダに関する項を参照してください。
プラグインは、WebLogic Serverに接続しようとする際に、様々な構成パラメータを使用してWebLogic Serverホストへの接続の待機時間と、接続確立後のレスポンスの待機時間を決定します。接続できないか、またはレスポンスがない場合、プラグインはクラスタ内の別のWebLogic Serverインスタンスに接続してリクエストを送信しようとします。接続が失敗するか、またはクラスタ内のいずれのWebLogic Serverからもレスポンスがない場合は、エラー・メッセージが送信されます。
図6-1は、プラグインがどのようにフェイルオーバーを処理するかを示しています。
WebLogic Serverホストが接続リクエストに対するレスポンスに失敗した場合、次の問題が考えられます。
ホスト・マシンの物理的な問題
ネットワークの問題
その他のサーバーの障害
すべてのWebLogic Serverインスタンスがレスポンスしない場合、次の問題が考えられます。
WebLogic Serverが実行中でないか、使用不可になっている
サーバーのハング
データベースの問題
アプリケーション固有の障害
負荷がかかっていると、プラグインはバックエンドのWebLogic ServerインスタンスからCONNECTION_REFUSEDエラーを受け取ることがあります。CONNECTION_REFUSEDエラーを減らすには、チューニングに関する次のヒントに従ってください。
WebLogic Serverドメインの構成のAcceptBackLog設定を増やします。
待機時間を短くします。この設定は、使用するオペレーティング・システムによって異なります。例:
Windows NTでは、プロキシおよびWebLogic ServerのTcpTimedWaitDelayをより小さな値に設定します。HKEY_LOCAL_MACHINE配下のレジストリ・キーを編集して、Windows NTでのTIME_WAIT間隔を設定します。
SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpTimedWaitDelay
このキーが存在しない場合、DWORD値として作成します。数値は待機する秒数で、30と240の間の任意の値を設定できます。設定しない場合、Windows NTでは、デフォルトで240秒がTIME_WAITに設定されます。
Windows 2000では、HKEY_LOCAL_MACHINE配下のレジストリ・キーを編集してTcpTimedWaitDelayの値を小さくします。
SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Solarisでは、WebLogic ServerマシンとApacheマシンに対して(可能な場合)tcp_time_wait_interval設定を1秒に減らします。
$ndd /dev/tcp param name to set - tcp_time_wait_interval value=1000
マシン上でオープン・ファイル記述子の制限値を増加します。この制限はオペレーティング・システムによって異なります。limit (.csh)またはulimit (.sh)ディレクティブを使用して、制限値を増やすスクリプトを作成できます。例:
#!/bin/sh ulimit -S -n 100 exec httpd
Solarisでは、WebLogic Serverマシンの次のチューニング可能項目の値を増やします。
tcp_conn_req_max_q tcp_conn_req_max_q0
WebLogic Serverインスタンスが1つだけ動作している場合、プラグインはWebLogicHostパラメータで定義されているサーバーに接続しようとします。その試行が失敗すると、HTTP 503エラー・メッセージが戻されます。プラグインは、ConnectTimeoutSecsとConnectRetrySecsの比によって規定される最大再試行回数に従って、WebLogic Serverへの接続を試行します。
クラスタリングされていない管理対象サーバー・インスタンスのロード・バランシング、またはクラスタされたバックエンド・サーバーのリストのプロキシを実行するためにWebLogicClusterパラメータが必要です。
クラスタリングされた管理対象サーバーにプロキシする場合、httpd.confまたはweblogic.confファイルでWebLogicClusterパラメータを使用してWebLogic Serverのリストを指定すると、プラグインはクラスタ・メンバー間でのロード・バランシングの起点としてそのリストを使用します。最初のリクエストがそれらのサーバーの1つに転送された後に、クラスタ内のサーバーの更新されたリストを格納する動的サーバー・リストが戻されます。更新されたリストでは、クラスタ内の新しいサーバーが追加され、クラスタを離脱したサーバーやリクエストに応答できなかったサーバーは削除されます。このリストは、クラスタ内で変化が発生したときにHTTPレスポンスによって自動的に更新されます。
リクエストが、CookieやPOSTデータに格納されているかURLにエンコードされたセッション情報を含む場合、そのセッションIDには、セッションが最初に確立された特定のサーバー・インスタンス(プライマリ・サーバーと呼びます)への参照が含まれています。Cookieを含むリクエストは、プライマリ・サーバーに接続しようとします。その試行が失敗すると、プラグインはラウンドロビン方式でリストの次の使用可能なサーバーに接続しようとします。そのサーバーは元のセカンダリ・サーバーからセッションを取得し、その同じセッションのプライマリ・サーバーになります。詳細は、図6-1を参照してください。
|
注意: POSTデータが64Kを超える場合、プラグインは、セッションIDを取得するためのPOSTデータの解析を行いません。したがって、セッションIDをPOSTデータに格納した場合、プラグインはリクエストを正しいプライマリまたはセカンダリ・サーバーにルーティングできないので、セッション・データが失われるおそれがあります。 |
この図において、赤いループで許容される最大再試行回数は、ConnectTimeoutSecs/ConnectRetrySecsの値に相当します。
SSL (Secure Sockets Layer)プロトコルを使用すると、Oracle iPlanet Web ServerプラグインとOracle WebLogic Server間の接続を保護できます。SSLプロトコルは、Oracle iPlanet Web ServerプラグインとOracle WebLogic Serverの間で通信されるデータの機密性と整合性を確保します。
Oracle iPlanet Web Serverプラグインは、Oracle iPlanet Web ServerプラグインとOracle WebLogic Server間の接続の保護にSSLプロトコルが使用されるかどうかを決定する際に、(通常はブラウザによって)HTTPリクエストに指定されるトランスポート・プロトコル(httpまたはhttps)を使用しません。
Oracle iPlanet Web ServerプラグインとOracle WebLogic Server間でSSLプロトコルを使用するには:
Oracle WebLogic ServerをSSL用に構成します。詳細は、『Oracle WebLogic Serverの保護』のSSLの構成に関する項を参照してください。
obj.confファイルのServiceディレクティブのWebLogicPortパラメータを、ステップ1で構成したリスニング・ポートに設定します。
obj.confファイルのServiceディレクティブのSecureProxyパラメータをONに設定します。
必要に応じて、obj.confファイルのServiceディレクティブに、SSL接続の情報を定義する追加パラメータを設定します。パラメータのリストは、7.2項「Webサーバー・プラグインのSSLパラメータ」を参照してください。
ほとんどの構成では、Oracle iPlanet Web Serverプラグインはリクエストをクラスタのプライマリ・インスタンスに送信します。そのインスタンスが使用できない場合、リクエストはセカンダリ・インスタンスにフェイルオーバーされます。ただし、ファイアウォールとロード・ディレクタを組み合わせて使用する一部の構成では、WebLogic Serverのプライマリ・インスタンスが使用できない場合でも、いずれか1つのサーバー(ファイアウォールまたはロード・ディレクタ)がリクエストを受け入れて、正常な接続を戻すことができます。WebLogic Serverの使用できないプライマリ・インスタンスへのリクエストの送信が試行された後、リクエストは「接続リセット」としてプラグインに戻されます。
ファイアウォールの組合せを介して実行するリクエストは、(ロード・ディレクタの有無に関係なく)WebLogic Serverによって処理されます。つまり、接続リセットのレスポンスは、WebLogic Serverのセカンダリ・インスタンスにフェイルオーバーします。これらの構成では接続リセットのレスポンスがフェイルオーバーするため、サーブレットは多重呼出し不変であることが必要です。そうでない場合、トランザクションの重複処理が発生する可能性があります。
