Oracle® Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー1.1プラグインの使い方 11g リリース1 (10.3.4) B61009-02 |
|
前 |
次 |
次の項では、WebLogic Serverで使用するためにOracleが提供するプラグイン用に実行する共有タスクについて説明します。
プラグインとWebLogic Serverとの間の接続を保護するため、Secure Sockets Layer (SSL)プロトコルを使用できます。SSLプロトコルによって、Apache HTTP ServerプラグインとWebLogic Serverの間でやり取りされるデータに機密性と整合性がもたらされます。
プラグインは、プラグインとWebLogic Serverの間の接続の保護にSSLプロトコルが使用されるかどうかを決定する際に、(通常はブラウザによって)HTTPリクエストに指定されるトランスポート・プロトコル(httpまたはhttps)を使用しません。つまり、プラグインは、(通常は、ブラウザからの)HTTPリクエストがHTTPS(SSL)を使用するかどうかにまったく依存しません。
そのかわりに、プラグインは、「Webサーバー・プラグインのSSLパラメータ」に記載されているように、SSLをいつ使用をするかを決定するため、ユーザーがプラグインに対して構成したSSLパラメータを使用します。2つの重要なSSLパラメータがあります。
WLSSLWallet
-- バージョン1.1のプラグインは、Oracleウォレットを使用してSSL構成情報を格納します。プラグインは、Oracleウォレットを使用するために新しいSSL構成パラメータWLSSLWallet
を導入します。この目的のため、orapkiユーティリティがプラグイン配布で提供されています。
orapkiユーティリティは、ウォレットおよび証明書失効リストなどの公開鍵インフラストラクチャ(PKI)の要素をコマンド・ラインで管理するので、実行するタスクをスクリプトに組み込むことができます。これによって、PKIを管理する多数のルーチン・タスクを自動化できます。
このツールの情報は、「証明書の検証およびCRL管理用orapkiユーティリティの使用」を参照してください。
SecureProxy
-- SecureProxy
パラメータは、SSLが有効化されるかどうかを決定します。
双方向SSLについては、WebLogic Serverが双方向SSL用に構成されていてクライアント証明書をリクエストする場合、プラグイン(SSLクライアント)は自動的に双方向SSLを使用します。
クライアント証明書がリクエストされない場合、プラグインはデフォルトで一方向SSLになります。
注意: Apache(Oracle HTTPを含む)と同じシステムにOracle Fusion Middleware 11g リリース11 (11.1.1)製品がインストールされている場合、ORACLE_HOME の変数が有効なインストールをポイントしている必要があり、そうでない場合プラグインはSSLの初期化に失敗します。
たとえば、製品がきちんと削除されなかったために |
プラグインは、Oracleライブラリ(NZ)を使用して、SSLサポートを提供します。ライブラリは大きいため、SSLを使用する必要がある場合のみ、動的にリンクされます。lib/*.so*
にあるライブラリ・ファイルが、プラグインが動的にロードできるように適切な場所に存在することを確認する必要があります。
各プラグインに関する章で記載されているとおりにプラグインをインストールした後、そのプラグインを構成して一方向SSLを使用できます。
一方向SSLを構成するには、次の手順を実行します。
この手順では、WebLogic Serverがインストールされているシステム上でkeytool
コマンドを実行します。バージョン1.1プラグインがインストールされているシステム上でorapki
コマンドを実行します。
注意: この項では、例示のためにWebLogic ServerのデモCAを使用します。本番環境でプラグインを使用している場合、プラグインおよびWebLogic Serverの信頼性のあるCAが正常に構成されていることを確認してください。 |
SSL用WebLogic Serverを構成します。詳細は、『Oracle WebLogic Serverの保護』のSSLの構成に関する項を参照してください。
SSL用WebLogic Serverリスニング・ポートを構成します。詳細は、『Oracle WebLogic Serverの保護』のSSLの構成に関する項を参照してください。
orapkiユーティリティを使用してOracleウォレットを作成します。
このツールの情報は、『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アカウント)と同一ではない場合、ウォレットの作成後にcacls (Windows)またはchmod (UNIX)コマンドを実行して、ウォレットへのユーザー・アクセス権限を付与する必要があります。例: IIS6.0以下:
IIS7.0:
|
orapki wallet create -wallet mywallet -auto_login_only
WL_HOME\server\lib\CertGenCA.der
のCAをOracleウォレットにインポートします。
orapki wallet add -wallet mywallet -trusted_cert -cert CertGenCA.der -auto_login_only
Apacheプラグインの場合、HTTPサーバーでhttpd.conf
ファイルを次のように編集します。
<IfModule mod_weblogic.c> WebLogicHost my-weblogic.server.com WebLogicPort weblogic-server-secure-port SecureProxy ON WLSSLWallet /home/myhome/mywallet </IfModule>
説明:
my-weblogic-server.com
はWebLogic Serverシステムです。
weblogic-server-secure-port
は、SSL(通常は7002)に対して使用するポートです。
SecureProxy
パラメータは、SSLが有効化されるかどうかを決定します。
WLSSLWallet
には、引数としてOracleウォレットのパスを入力します。
IISプラグインの場合、Microsoft Internet Information Serverのiisproxy.ini
ファイルを次のように編集します。
WebLogicHost=my-weblogic.server.com WebLogicPort=weblogic-server-secure-port SecureProxy=ON WLSSLWallet=c:\home\myhome\mywallet
説明:
my-weblogic-server.com
はWebLogic Serverシステムです。
weblogic-server-secure-port
は、SSL(通常は7002)に対して使用するポートです。
SecureProxy
パラメータは、SSLが有効化されているかどうかを決定します。
WLSSLWallet
には、引数としてOracleウォレットのパスを入力します。
Apacheプラグインの場合、SSL接続に関する情報を定義するhttpd.conf
ファイルに追加パラメータを設定します。プラグインに対して構成できるSSLパラメータの完全なリストについては、「Webサーバー・プラグインのSSLパラメータ」を参照してください。
IISプラグインの場合、SSL接続に関する情報を定義するiisproxy.ini
ファイルに追加パラメータを設定します。プラグインに対して構成できるSSLパラメータの完全なリストは、「Webサーバー・プラグインのSSLパラメータ」を参照してください。
ブラウザからhttp://apache-host:apache-port/mywebapp/my.jsp
にリクエストを送信します。レスポンスを検証します。
各プラグインに関する章に記載されているとおりにプラグインをインストールした後、そのプラグインを構成して双方向SSLを使用できます。
ユーザー証明書をウォレットにインポートして双方向SSLを構成します。WebLogic Serverが双方向SSL用に構成されている場合、プラグインはユーザー証明書をWebLogic Serverに転送します。WebLogic Serverがユーザー証明書を検証できるかぎり、双方向SSLを確立できます。
SSLを構成するために「一方向SSL用プラグインの構成」に記載されている手順に加え、プラグインとWebLogic Serverの間の双方向SSLを構成するために、次の追加手順を実行します。
この手順においても、WebLogic Serverがインストールされているシステム上でkeytool
コマンドを実行します。バージョン1.1プラグインがインストールされているシステム上でorapki
コマンドを実行します。
Oracleウォレットから証明書リクエストを作成します。
この証明書リクエストを使用して、CAまたはその他の方法で証明書を作成します。
ユーザー証明書を信頼性のある証明書としてWebLogicトラストストアにインポートします。WebLogic Serverでは、証明書をトラストする必要があります。
keytool -file user.crt -importcert -trustcacerts -keystore DemoTrust.jks -storepass <passphrase>
クライアント証明書(双方向SSL用)のプレゼンテーションを必要とするWebLogic Server SSL構成オプションを設定します。Oracle WebLogic Server管理コンソール・ヘルプの双方向SSLの構成に関する項を参照してください。
SSLを使用するためにApacheプラグインを構成する際に、次の既知の問題が発生します:
PathTrim
パラメータ(「Webサーバー・プラグインのSSLパラメータ」を参照)を<Location>
タグ内に構成する必要があります。
次の構成は正しくありません:
<Location /weblogic> SetHandler weblogic-handler </Location> <IfModule mod_weblogic.c> WebLogicHost localhost WebLogicPort 7001 PathTrim /weblogic </IfModule>
次の構成は正しい設定です。
<Location /weblogic> SetHandler weblogic-handler PathTrim /weblogic </Location>
WebLogic Server Apacheプラグインの現在の実装では、Apache 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アドレスを返します。Windows 2008 (以降)システムにIPv4を使用して接続している場合、IPv6アドレス形式が最初に試行されますが、これによって著しい遅延とパフォーマンスの低下という結果になってしまいます。IPv4アドレス形式を使用するには、システムを構成して構成ファイルでかわりのIPアドレスを使用するか、またはIPv4アドレスをetc/hosts ファイルに追加します。
また、 |
プラグインを介してアクセスする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を構成するために行う必要がある手順は、「プラグインにおけるSSLの使用」を参照してください。
『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のIDアサーション・プロバイダに関する項を参照してください。
WebLogic ServerでWebLogicプラグインの有効化制御を設定します。
WebLogicプラグインの有効化制御は、WebLogic Serverが独自のWL-Proxy-Client-IPヘッダーを使用するかどうかを指定します。これは、サーバー・インスタンスがプロキシ・プラグインからリクエストを受信する場合にお薦めします。
プラグインは、WebLogic Serverに接続しようとする際に、様々な構成パラメータを使用してWebLogic Serverホストへの接続の待機時間と、接続確立後のレスポンスの待機時間を決定します。接続できないか、またはレスポンスがない場合、プラグインはクラスタ内の別のWebLogic Serverインスタンスに接続してリクエストを送信しようとします。接続が失敗するか、またはクラスタ内のいずれのWebLogic Serverからもレスポンスがない場合は、エラー・メッセージが送信されます。
図6-1は、プラグインがどのようにフェイルオーバーを処理するかを示しています。
WebLogic Serverホストが接続リクエストに対するレスポンスに失敗した場合、次の問題が考えられます。
ホスト・マシンの物理的な問題
ネットワークの問題
その他のサーバーの障害
すべてのWebLogic Serverインスタンスがレスポンスしない場合、次の問題が考えられます。
WebLogic Serverが実行中でないか、使用不可になっている
サーバーのハング
データベースの問題
アプリケーション固有の障害
負荷がかかっていると、Apacheプラグインはバックエンドの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
の値に相当します。