Oracle® Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー1.1プラグインの使用 11g リリース1 (11.1.1) B61009-08 |
|
![]() 前 |
![]() 次 |
この章では、オラクル社提供のプラグインの構成において、すべてのWebサーバーに共通するタスクを説明します。次の項で構成されます。
Secure Sockets Layer (SSL)プロトコルを使用することで、プラグインとOracle WebLogic Serverとの間の接続を保護できます。SSLプロトコルによって、プラグインとWebLogic Serverとの間で渡されるデータの機密性と整合性が保持されます。
プラグインでは、プラグインとWebLogic Serverとの間の接続の保護にSSLを使用するかどうかの決定に、HTTPリクエストで指定された(通常はブラウザによって指定)トランスポート・プロトコル(HTTPまたはHTTPS)を使用しません。つまり、プラグインは、(通常はブラウザからの)HTTPリクエストでHTTPS (SSL)が使用されるかどうかには一切依存しません。
かわりに、プラグインでは、第7.2項「Webサーバー・プラグインのSSLパラメータ」で説明されているように、SSLをいつ使用をするかを決定するため、プラグインに対して次のように構成したSSLパラメータを使用します。
WebLogicSSLVersion
—プラグインとWebLogic Serverの間の通信に使用するSSLプロトコル・バージョンを指定します。これは11.1.1.9リリースの新規パラメータでWeb Serverプラグインの古いリリースでは使用できません。
WLSSLWallet
-バージョン1.1のプラグインでは、SSL構成情報の格納にOracleウォレットが使用されます。プラグインには、Oracleウォレットの使用のために、新しいSSL構成パラメータであるWLSSLWallet
が導入されています。この目的のために、プラグインのディストリビューション内にorapki
ユーティリティが用意されています。
orapki
ユーティリティでは、ウォレット、証明書失効リストなど、公開鍵インフラストラクチャ(PKI)の要素をコマンド行で管理するため、実行するタスクをスクリプトに組み込むことができます。これを使用して、PKIを保守するルーチン・タスクの多くを自動化できます。
詳細は、orapkiユーティリティを使用した証明書検証およびCRL管理に関する項を参照してください。
SecureProxy
-SecureProxy
パラメータによって、SSLを有効にするかどうかを決定します。
注意: 有効なセキュリティ・プロトコルおよび現行リリースの暗号に関する詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』のSSLCipherSuiteに関する項およびSSLProtocolに関する項を参照してください。 |
双方向SSLについては、Oracle WebLogic Serverが双方向SSLを使用するように構成されている場合にクライアント証明書をリクエストすると、プラグイン(SSLクライアント)によって自動的に双方向SSLが使用されます。
クライアント証明書がリクエストされない場合は、デフォルトでプラグインは一方向SSLになります。
注意: Apacheプラグイン(Oracle HTTP Serverを含む)と同じシステム上にOracle Fusion Middleware 11gR1製品がインストールされている場合は、ORACLE_HOME 変数が有効なインストール環境を指している必要があり、そうでない場合は、プラグインによるSSLの初期化が失敗します。
たとえば、製品が正常に削除されなかったために |
プラグインでは、SSLをサポートするためにOracleライブラリ(NZ)が使用されます。ライブラリはサイズが大きいため、SSLの使用が必要な場合のみロードされます。lib/*.so*
にあるライブラリ・ファイルは、必ず、プラグインによる動的なロードが可能な適切な場所に配置する必要があります。
Apache HTTPサーバー用プラグインのライブラリを構成するには、次のような方法があります。
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が正しく構成されていることを確認してください。 |
SSL用にOracle WebLogic Serverを構成します。詳細は、Oracle WebLogic Serverの保護のSSLの構成を参照してください。
orapki
ユーティリティを使用してOracleウォレットを作成します。
orapki wallet create -wallet mywallet -auto_login_only
詳細は、『Oracle Fusion Middleware管理者ガイド』のorapkiユーティリティを使用した証明書検証およびCRL管理に関する項を参照してください。
注意: ウォレットにアクセスできるのは、そのウォレットを作成したユーザーのみです(Windowsの場合はSYSTEMアカウント)。通常、Apacheは、WindowsではSYSTEMアカウント、UNIXではウォレットの作成ユーザーとして実行されるため、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 Walletにインポートします。
orapki wallet add -wallet mywallet -trusted_cert -cert CertGenCA.der -auto_login_only
Webサーバーの構成ファイルを次のように構成します。
Oracle HTTP Server用にmod_wl_ohs.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
iPlanet Web Serverの場合、次のように、config/obj.conf
またはconfig/<vs>-obj.conf
ファイルを編集します。
<Object ppath="*/weblogic/*">> Service fn=wl-proxy WebLogicHost=myserver.com WebLogicPort=7001 PathTrim="/weblogic" SecureProxy=ON WLSSLWallet=path_to_wallet </Object>
これらの例で使用されているパラメータの詳細は、第7章「Webサーバー・プラグインのパラメータ」を参照してください。
バックエンドの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アドレスをetc/hosts ファイルに追加します。
また、 |
プラグインを介してアクセスされる、WebLogic Serverアプリケーションを保護するには、境界認証を使用します。
WebLogic IDアサーション・プロバイダでは、WebLogic Serverアプリケーションにアクセスする外部システム(プラグインを介してWebLogic Serverアプリケーションにアクセスするユーザーを含む)からのトークンを認証します。次の手順に従って、プラグインを安全に保護するIDアサーション・プロバイダを作成します。
WebLogic Serverアプリケーションに対してカスタムIDアサーション・プロバイダを作成します。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のカスタムIDアサーション・プロバイダの開発方法に関する項を参照してください。
Certトークン・タイプをサポートしてCertをアクティブなトークン・タイプにするよう、カスタムIDアサーション・プロバイダを構成します。『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では、TIME_WAITにデフォルトの240秒が設定されます。
Windows 2000の場合は、HKEY_LOCAL_MACHINEの下の次のレジストリ・キーを編集することで、TcpTimedWaitDelay
の値を小さくします。
SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Solarisの場合は、tcp_time_wait_interval
の設定を1秒に減らします(可能な場合は、WebLogic ServerマシンとApacheマシンの両方に対して設定)。
$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
の値と等しくなります。
Secure Sockets Layer (SSL)プロトコルを使用することで、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プロトコルを使用するには:
SSL用にOracle WebLogic Serverを構成します。詳細は、Oracle WebLogic Serverの保護のSSLの構成を参照してください。
obj.conf
ファイル内のService
ディレクティブのWebLogicPort
パラメータを、手順1で構成したリスニング・ポートに設定します。
obj.conf
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のセカンダリ・インスタンスにフェイルオーバーします。このような構成では、接続リセットのレスポンスがフェイルオーバーするため、サーブレットは多重呼出し不変である必要があります。そうでない場合は、トランザクションの処理が重複する可能性があります。
WebLogicプロキシ・プラグイン11.1.1.9は、追加のSSLプロトコル(TLS 1.1およびTLS 1.2など)をサポートし、WebLogic ServerとのSSLハンドシェイク中にこれらのセキュア・プロトコルにデフォルト設定されます。WebLogic Serverプロキシ・プラグインに11.1.1.9がHTTPSトラフィックをWebLogic Serverからフロントエンドする際に、管理者は次の処理のいずれかを実行する必要があります。
WebLogic ServerでTLS 1.2プロトコルがサポートされることを確認します。
WebLogic Server 10.3.xは、TLS 1.2プロトコルを使用するように明示的に構成する必要があります。詳細については、以下を参照してください。
詳細は、『Oracle WebLogic Serverの新機能』のトランスポート層セキュリティ(TLS)1.2サポートに関する項およびOracle Supportドキュメントを参照してください。
詳細は、Oracle WebLogic Serverの保護の「JSSEベースのSSL実装の有効化および無効化」を参照してください。
https://support.oracle.com
の「Oracle Fusion Middleware製品でSSLプロトコルを変更する(SSL 3.0を無効にする)方法(ドキュメントID 1936300.1)」
WebLogic Server 12.1以降のリリースでは、デフォルトでTLS 1.2プロトコルがサポートされます。追加の構成は不要です。
WebLogic Server 10.3.6でTLS 1.2プロトコルをサポートするように構成できない場合、次の例のようにWebLogicSSLVersionディレクティブを使用して、WebLogic Server 10.3.6とのSSLハンドシェイク中に、TLS1.0プロトコルを使用してWebLogic Serverプロキシ・プラグイン11.1.1.9を通信するように明示的に構成する必要があります。
<IfModule mod_weblogic.c> WebLogicSSLVersion TLSv1 </IfModule>
注意: WebLogicSSLVersionディレクティブは、Oracle HTTP ServerおよびApache HTTPサーバーに対してのみ使用可能です。 |
このディレクティブに関する詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』のWebLogicSSLVersionに関する項を参照してください。