ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー1.1プラグインの使用
11g リリース1 (10.3.6)
B61009-04
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

7 共通タスクの実行

次の項では、WebLogic Serverで使用するためにOracleが提供するプラグイン用に実行する共有タスクについて説明します。

7.1 プラグインにおけるSSLの使用

プラグインとWebLogic Serverとの間の接続を保護するため、Secure Sockets Layer (SSL)プロトコルを使用できます。SSLプロトコルによって、プラグインとWebLogic Serverの間でやり取りされるデータに機密性と整合性がもたらされます。

プラグインは、プラグインとWebLogic Serverの間の接続の保護にSSLプロトコルが使用されるかどうかを決定する際に、(通常はブラウザによって)HTTPリクエストに指定されるトランスポート・プロトコル(httpまたはhttps)を使用しません。つまり、プラグインは、(通常は、ブラウザからの)HTTPリクエストがHTTPS(SSL)を使用するかどうかにまったく依存しません。

そのかわりに、プラグインは、8.3項「Webサーバー・プラグインのSSLパラメータ」に記載されているように、SSLをいつ使用をするかを決定するため、ユーザーがプラグインに対して構成したSSLパラメータを使用します。2つの重要なSSLパラメータがあります。

双方向SSLについては、WebLogic Serverが双方向SSL用に構成されていてクライアント証明書をリクエストする場合、プラグイン(SSLクライアント)は自動的に双方向SSLを使用します。

クライアント証明書がリクエストされない場合、プラグインはデフォルトで一方向SSLになります。


注意:

Apache(Oracle HTTPを含む)と同じシステムにOracle Fusion Middleware 11g リリース11 (11.1.1)製品がインストールされている場合、ORACLE_HOMEの変数が有効なインストールをポイントしている必要があり、そうでない場合プラグインはSSLの初期化に失敗します。

たとえば、製品がきちんと削除されなかったためにORACLE_HOMEが無効になっている場合、プラグインはSSLの初期化に失敗します。


7.1.1 SSL用のライブラリの構成

プラグインは、Oracleライブラリ(NZ)を使用して、SSLサポートを提供します。ライブラリは大きいため、SSLを使用する必要がある場合のみ、ロードされます。lib/*.so*にあるライブラリ・ファイルが、プラグインが動的にロードできるように適切な場所に存在することを確認する必要があります。

7.1.1.1 Apache HTTP Serverで使用するSSLライブラリの構成

Apacheプラグインのライブラリ(Apache HTTP ServerとOracle HTTP Serverの両方に使用される)を構成するには、いくつかのオプションがあります。

  1. Windowsの場合は、lib\*.dllディレクトリがPATH変数に存在する必要があります。または、*.dllファイルをApache/binディレクトリに追加します。

  2. Unixの場合は、バイナリをApacheのlibフォルダにコピーするか、またはバイナリを含むフォルダを指定するLD_LIBRARY_PATHを構成します。

    ライブラリをApache HTTP Serverディレクトリにコピーする場合、PATH (Windows)またはLD_LIBRARY_PATH (Unix)を更新するかわりに、新しいレベルのOracle WebLogic Serverプラグインをインストールする度にライブラリを再コピーする必要があります。

7.1.2 一方向SSL用プラグインの構成

各プラグインに関する章で記載されているとおりにプラグインをインストールした後、そのプラグインを構成して一方向SSLを使用できます。

一方向SSLを構成するには、次の手順を実行します。

この手順では、WebLogic Serverがインストールされているシステム上でkeytoolコマンドを実行します。バージョン1.1プラグインがインストールされているシステム上でorapkiコマンドを実行します。


注意:

この項では、例示のためにWebLogic ServerのデモCAを使用します。

本番環境でプラグインを使用している場合、プラグインおよびWebLogic Serverの信頼性のあるCAが正常に構成されていることを確認してください。


  1. SSL用WebLogic Serverを構成します。詳細は、『Oracle WebLogic Serverの保護』のSSLの構成に関する項を参照してください。

  2. SSL用WebLogic Serverリスニング・ポートを構成します。詳細は、『Oracle WebLogic Serverの保護』のSSLの構成に関する項を参照してください。

  3. 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以下:

    cacls <wallet_path>\cwallet.sso /e /g IUSR_<Machine_Name>:R

    IIS7.0:

    cacls <wallet_path>\cwallet.sso /e /g IUSR:R


    orapki wallet create -wallet mywallet -auto_login_only
    
  4. WL_HOME\server\lib\CertGenCA.derのCAをOracleウォレットにインポートします。

    orapki wallet add -wallet mywallet -trusted_cert -cert CertGenCA.der -auto_login_only
    
  5. 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ウォレットのパスを入力します。

  6. 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ウォレットのパスを入力します。

  7. Apacheプラグインの場合、SSL接続に関する情報を定義するhttpd.confファイルに追加パラメータを設定します。プラグインに対して構成できるSSLパラメータの完全なリストについては、8.3項「Webサーバー・プラグインのSSLパラメータ」を参照してください。

  8. IISプラグインの場合、SSL接続に関する情報を定義するiisproxy.iniファイルに追加パラメータを設定します。プラグインに対して構成できるSSLパラメータの完全なリストについては、8.3項「Webサーバー・プラグインのSSLパラメータ」を参照してください。

  9. ブラウザからhttp://apache-host:apache-port/mywebapp/my.jspにリクエストを送信します。レスポンスを検証します。

7.1.3 プラグインとWebLogic Server間の双方向SSLの構成

各プラグインに関する章に記載されているとおりにプラグインをインストールした後、そのプラグインを構成して双方向SSLを使用できます。

ユーザー証明書をウォレットにインポートして双方向SSLを構成します。WebLogic Serverが双方向SSL用に構成されている場合、プラグインはユーザー証明書をWebLogic Serverに転送します。WebLogic Serverがユーザー証明書を検証できるかぎり、双方向SSLを確立できます。

SSLを構成するために7.1.2項「一方向SSL用プラグインの構成」に記載されている手順に加え、プラグインとWebLogic Serverの間の双方向SSLを構成するために、次の追加手順を実行します。

この手順においても、WebLogic Serverがインストールされているシステム上でkeytoolコマンドを実行します。バージョン1.1プラグインがインストールされているシステム上でorapkiコマンドを実行します。

  1. Oracleウォレットから証明書リクエストを作成します。

  2. この証明書リクエストを使用して、CAまたはその他の方法で証明書を作成します。

  3. ユーザー証明書を信頼性のある証明書としてWebLogicトラストストアにインポートします。WebLogic Serverでは、証明書をトラストする必要があります。

    keytool -file user.crt -importcert -trustcacerts -keystore DemoTrust.jks -storepass <passphrase>
    
  4. クライアント証明書(双方向SSL用)のプレゼンテーションを必要とするWebLogic Server SSL構成オプションを設定します。Oracle WebLogic Server管理コンソール・ヘルプの双方向SSLの構成に関する項を参照してください。

7.2 プラグインにおけるIPv6の使用

バージョン1.1プラグインは、IPv6をサポートしています。具体的には、WebLogicHostおよびWebLogicClusterの構成パラメータ(表8-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ファイルに追加します。

また、mod_wl_ohs.confファイルでDynamicServerListプロパティをOFFに設定すると、IPv6に関するパフォーマンスを向上できることがわかります。OFFに設定すると、プラグインは、プラグインからプロキシされたリクエストのロード・バランシングに使用される動的クラスタ・リストを無視し、WebLogicClusterパラメータで指定された静的リストを使用します。


7.3 境界認証の設定

プラグインを介してアクセスするWebLogic Serverアプリケーションを保護するには、境界認証を使用します。

WebLogic IDアサーション・プロバイダは、WebLogic Serverアプリケーションにアクセスする外部システム(プラグインを通じてWebLogic Serverアプリケーションにアクセスするユーザーを含む)からのトークンを認証します。使用しているプラグインを安全に保護するIDアサーション・プロバイダを次のように作成します。

  1. WebLogic ServerアプリケーションにカスタムIDアサーション・プロバイダを作成します。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のカスタムIDアサーション・プロバイダの開発方法に関する項を参照してください。

  2. Certトークン・タイプをサポートするようにカスタムIDアサーション・プロバイダを構成し、Certをアクティブなトークン・タイプにします。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の新しいトークン・タイプの作成方法に関する項を参照してください。

  3. Webアプリケーションのweb.xmlのデプロイメント記述子ファイルでclientCertProxyをTrueに設定します(または、クラスタを使用している場合、必要に応じて、「管理コンソール・クラスタ」->「構成」->「一般」タブで、クラスタ全体に対して「クライアント証明書プロキシの有効化」属性をtrueに設定します)。

    ロード・バランサまたはSSLアクセラレータなどサード・パーティ・プロキシ・サーバーでclientCertProxy属性を使用して双方向SSL認証を有効にすることができます。clientCertProxy属性の詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のcontext-paramに関する項を参照してください。

  4. clientCertProxyを設定したら、接続フィルタを使用して、WebLogic Serverが、プラグインを実行しているマシンからの接続のみを受け入れるようにします。『Oracle WebLogic Serverセキュリティのプログラミング』のネットワーク接続フィルタの使用に関する項を参照してください。

  5. Webサーバー・プラグインでは、プラグインとWebLogic Serverの間にSSLを使用するには、信頼性のある認証局のファイルが存在する必要があります。SSLを構成するために行う必要がある手順は、7.1項「プラグインにおけるSSLの使用」を参照してください。

『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のIDアサーション・プロバイダに関する項を参照してください。

7.4 WebLogic ServerにおけるWebLogicプラグイン有効化制御の設定

WebLogic ServerでWebLogicプラグインの有効化制御を設定します。

WebLogicプラグインの有効化制御は、WebLogic Serverが独自のWL-Proxy-Client-IPヘッダーを使用するかどうかを指定します。これは、サーバー・インスタンスがプロキシ・プラグインからリクエストを受信する場合にお薦めします。

7.5 接続エラーとクラスタリング・フェイルオーバーについて

プラグインは、WebLogic Serverに接続しようとする際に、様々な構成パラメータを使用してWebLogic Serverホストへの接続の待機時間と、接続確立後のレスポンスの待機時間を決定します。接続できないか、またはレスポンスがない場合、プラグインはクラスタ内の別のWebLogic Serverインスタンスに接続してリクエストを送信しようとします。接続が失敗するか、またはクラスタ内のいずれのWebLogic Serverからもレスポンスがない場合は、エラー・メッセージが送信されます。

図7-1は、プラグインがどのようにフェイルオーバーを処理するのかを示しています。

7.5.1 接続失敗の考えられる原因

WebLogic Serverホストが接続リクエストに対するレスポンスに失敗した場合、次の問題が考えられます。

  • ホスト・マシンの物理的な問題

  • ネットワークの問題

  • その他のサーバーの障害

すべてのWebLogic Serverインスタンスがレスポンスしない場合、次の問題が考えられます。

  • WebLogic Serverが実行中でないか、使用不可になっている

  • サーバーのハング

  • データベースの問題

  • アプリケーション固有の障害

7.5.2 Connection_Refusedエラーを減らすためのヒント

負荷がかかっていると、プラグインはバックエンドの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
    

7.5.3 クラスタリングされていない単一のWebLogic Serverでのフェイルオーバー

WebLogic Serverインスタンスが1つだけ動作している場合、プラグインはWebLogicHostパラメータで定義されているサーバーに接続しようとします。その試行が失敗すると、HTTP 503エラー・メッセージが戻されます。プラグインは、ConnectTimeoutSecsConnectRetrySecsの比によって規定される最大再試行回数に従って、WebLogic Serverへの接続を試行します。

7.5.4 動的サーバー・リスト

クラスタリングされていない管理対象サーバー・インスタンスのロード・バランシング、またはクラスタされたバックエンド・サーバーのリストのプロキシを実行するためにWebLogicClusterパラメータが必要です。

クラスタリングされた管理対象サーバーにプロキシする場合、httpd.confまたはweblogic.confファイルでWebLogicClusterパラメータを使用してWebLogic Serverのリストを指定すると、プラグインはクラスタ・メンバー間でのロード・バランシングの起点としてそのリストを使用します。最初のリクエストがそれらのサーバーの1つに転送された後に、クラスタ内のサーバーの更新されたリストを格納する動的サーバー・リストが戻されます。更新されたリストでは、クラスタ内の新しいサーバーが追加され、クラスタを離脱したサーバーやリクエストに応答できなかったサーバーは削除されます。このリストは、クラスタ内で変化が発生したときにHTTPレスポンスによって自動的に更新されます。

7.5.5 フェイルオーバー、CookieおよびHTTPセッション

リクエストが、CookieやPOSTデータに格納されているかURLにエンコードされたセッション情報を含む場合、そのセッションIDには、セッションが最初に確立された特定のサーバー・インスタンス(プライマリ・サーバーと呼びます)への参照が含まれています。Cookieを含むリクエストは、プライマリ・サーバーに接続しようとします。その試行が失敗すると、プラグインはラウンドロビン方式でリストの次の使用可能なサーバーに接続しようとします。そのサーバーは元のセカンダリ・サーバーからセッションを取得し、その同じセッションのプライマリ・サーバーになります。図7-1を参照してください。


注意:

POSTデータが64Kを超える場合、プラグインは、セッションIDを取得するためのPOSTデータの解析を行いません。したがって、セッションIDをPOSTデータに格納した場合、プラグインはリクエストを正しいプライマリまたはセカンダリ・サーバーにルーティングできないので、セッション・データが失われるおそれがあります。

図7-1 接続のフェイルオーバー

図7-1の説明が続きます
「図7-1 接続フェイルオーバー」の説明

この図において、赤いループで許容される最大再試行回数は、ConnectTimeoutSecs/ConnectRetrySecsの値に相当します。

7.5.6 Oracle iPlanet Web ServerプラグインでのSSLの使用

Secure Sockets Layer (SSL)プロトコルを使用すると、Oracle iPlanet Web ServerプラグインとWebLogic Serverの間の接続を保護できます。SSLプロトコルは、Oracle iPlanet Web ServerプラグインとWebLogic Serverの間でやり取りするデータに機密性と整合性をもたらします。

Oracle iPlanet Web Serverプラグインは、Oracle iPlanet Web ServerプラグインとWebLogic Serverの間の接続の保護にSSLプロトコルが使用されるかどうかを決定する際に、(通常はブラウザによって)HTTPリクエストに指定されるトランスポート・プロトコル(httpまたはhttps)を使用しません。

Oracle iPlanet Web ServerプラグインとWebLogic Serverの間でSSLプロトコルを使用するには、次の手順を行います。

  1. SSL用WebLogic Serverを構成します。詳細は、「SSLの構成」を参照してください。

  2. SSL用WebLogic Serverリスニング・ポートを構成します。詳細は、「SSLの構成」を参照してください。

  3. obj.confファイルのServiceディレクティブのWebLogicPortパラメータを、ステップ2で構成したリスニング・ポートに設定します。

  4. obj.confファイルのServiceディレクティブのSecureProxyパラメータをONに設定します。

  5. obj.confファイルのServiceディレクティブに、SSL接続の情報を定義する追加パラメータを設定します。パラメータの完全なリストは、8-15ページの「Webサーバー・プラグインのSSLパラメータ」を参照してください。

7.5.7 ファイアウォールとロード・ディレクタを使用する場合のフェイルオーバーの動作

ほとんどの構成では、Oracle iPlanet Web Serverプラグインはリクエストをクラスタのプライマリ・インスタンスに送信します。そのインスタンスが使用できない場合、リクエストはセカンダリ・インスタンスにフェイルオーバーされます。ただし、ファイアウォールとロード・ディレクタを組み合わせて使用する一部の構成では、WebLogic Serverのプライマリ・インスタンスが使用できない場合でも、いずれか1つのサーバー(ファイアウォールまたはロード・ディレクタ)がリクエストを受け入れて、正常な接続を戻すことができます。WebLogic Serverの使用できないプライマリ・インスタンスへのリクエストの送信が試行された後、リクエストは「接続リセット」としてプラグインに戻されます。

ファイアウォールの組合せを介して実行するリクエストは、(ロード・ディレクタの有無に関係なく)WebLogic Serverによって処理されます。つまり、接続リセットのレスポンスは、WebLogic Serverのセカンダリ・インスタンスにフェイルオーバーします。これらの構成では接続リセットのレスポンスがフェイルオーバーするため、サーブレットは多重呼出し不変であることが必要です。そうでない場合、トランザクションの重複処理が発生する可能性があります。