| Oracle® Fusion Middleware Oracle WebLogic Serverプロキシ・プラグインの使用 12c (12.1.3) E56226-05 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverプロキシ・プラグインの使用 12c (12.1.3) E56226-05 |
|
前 |
次 |
この章では、オラクル社提供のプラグインの構成において、すべての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プロトコル・バージョンを指定します。
WLSSLWallet: バージョン12.1.3のプラグインでは、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 12c (12.1.3)製品がインストールされている場合は、ORACLE_HOME変数が有効なインストール環境を指している必要があり、そうでない場合は、プラグインによるSSLの初期化が失敗します。たとえば、製品が正常に削除されなかったために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コマンドを実行し、バージョン12.1.3のプラグインがインストールされているシステム上で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アカウント)。通常、WindowsではSYSTEMアカウント、UNIXではウォレットの作成ユーザーとして実行されるため、Apache HTTP Server用Oracle WebLogic Serverプロキシ・プラグインについてはこれで十分です。ただしIISの場合は、デフォルト・ユーザーがIUSR_<Machine_Name> (IIS6.0以下)またはIUSR (IIS7.0以上)であるため、ウォレットは機能しません。 Apache HTTP Server用Oracle WebLogic Serverプロキシ・プラグインまたはMicrosoft IIS Web Serverを実行するユーザーが、ウォレットを作成するユーザー(Windowsの場合はSYSTEMアカウント)と異なる場合には、ウォレットの作成後に
|
OracleウォレットにWLS信頼証明書をインポートします。
orapki wallet add -wallet mywallet -trusted_cert -cert <cert_file_name> -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からリクエストをプロキシするサーバーまたはクラスタを選択します。
「構成」→「一般」タブが表示されます。
下にスクロールし、「詳細」セクションを開きます。
次のいずれかを実行します。
| 目的 | 選択オプション |
|---|---|
| 一方向SSLの有効化 | WebLogicプラグインの有効化 |
| 認証にクライアント証明書が使用される双方向SSLの有効化 | クライアント証明書プロキシの有効化 |
| クライアント証明書による双方向SSLの有効化 | 両方 |
手順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コマンドを実行します。また、バージョン12.1.3プラグインがインストールされているシステム上で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の構成に関する項を参照してください。
バージョン12.1.3プラグインでは、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の場合は、プロキシおよびWebLogic ServerサーバーのTcpTimedWaitDelayの設定値を小さくします。HKEY_LOCAL_MACHINE配下のレジストリ・キーを編集して、WindowsでのTIME_WAIT間隔を設定します。
SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpTimedWaitDelay
このキーが存在しない場合は、DWORD値としてこれを作成できます。数値は待機する秒数であり、30から240までの任意の値を設定できます。設定しない場合、Windowsでは、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パラメータは、クラスタ化されたバックエンド・サーバーのリストにプロキシしたり、クラスタ化されていない管理対象サーバー・インスタンスのロード・バランシングを実行するために必要となります。
クラスタ化された管理対象サーバーにプロキシする場合、WebLogicClusterパラメータを使用してWebLogic Serverのリストを指定すると、プラグインは、クラスタ・メンバー間でのロード・バランシングの起点としてそのリストを使用します。最初のリクエストがそれらのサーバーの1つにルーティングされた後、クラスタ内のサーバーの更新されたリストを含む動的サーバー・リストが返されます。クラスタ化された管理対象サーバーにプロキシする場合、WebLogicClusterパラメータを使用してWebLogic Serverのリストを指定すると、プラグインは、クラスタ・メンバー間でのロード・バランシングの起点としてそのリストを使用します。最初のリクエストがそれらのサーバーの1つにルーティングされた後、クラスタ内のサーバーの更新されたリストを含む動的サーバー・リストが返されます。更新されたリストでは、クラスタ内の新しいサーバーが追加され、停止されたサーバー、一時停止されたサーバー、クラスタ・メンバーではなくなったサーバーおよびリクエストに応答しなかったサーバーは削除されます。この機能は、DynamicServerListを使用して制御可能です。たとえば、この機能を無効にするには、DynamicServerListをOFFに設定します。この機能は、DynamicServerListを使用して制御可能です。たとえば、この機能を無効にするには、DynamicServerListをOFFに設定します。
DynamicServerList ONは、推奨されるパフォーマンス・チューニング・パラメータです。クラスタのメンバーが保守のために一時的に停止されている場合や、管理者がオンザフライで別のメンバーを追加することを決定し、Oracle HTTP Serverの再起動が必要ない場合などに役立ちます。
|
注意: DynamicServerListが、WebLogicClusterを使用してクラスタ化されたWebLogic Serverを使用する際にOFFに設定されていないと機能しない場合は、WebLogic Serverで動的リストの取得または配信の際に問題が発生します。 |
リクエストに、CookieやPOSTデータに格納されているかURLでエンコードされたセッション情報が含まれている場合、そのセッションIDには、セッションが最初に確立された特定のサーバー・インスタンス(プライマリ・サーバーと呼ばれる)への参照が含まれています。Cookieが含まれるリクエストは、プライマリ・サーバーへの接続を試みます。その試みが失敗すると、プラグインは、ラウンドロビン方式で、リスト内にある次に使用可能なサーバーへの接続を試みます。そのサーバーが元のセカンダリ・サーバーからセッションを取得し、そのサーバー自体が同一セッションの新しいプライマリ・サーバーになります。図6-1を参照してください。
|
注意: POSTデータが64Kより大きい場合、プラグインは、セッションIDを取得するため、POSTデータを解析しません。したがって、セッションIDをPOSTデータに格納した場合、プラグインはリクエストを正しいプライマリ・サーバーまたはセカンダリ・サーバーにルーティングできず、セッション・データが失われる可能性があります。 |
この図の赤色のループに許容されている最大試行回数はConnectTimeoutSecs/ConnectRetrySecsの値と等しくなります。
Secure Sockets Layer (SSL)プロトコルを使用することで、iPlanet Web Serverプラグイン用Oracle WebLogic Serverプロキシ・プラグイン12.1.3とOracle WebLogic Serverとの間の接続を保護できます。SSLプロトコルによって、Oracle iPlanet Web ServerプラグインとOracle WebLogic Serverとの間で渡されるデータの機密性と整合性が保持されます。
iPlanet Web Serverプラグイン用Oracle WebLogic Serverプロキシ・プラグイン12.1.3では、iPlanet Web Server用Oracle WebLogic Serverプロキシ・プラグイン12.1.3と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ファイル内のServiceディレクティブのSecureProxyパラメータをONに設定します。
必要に応じて、obj.confファイル内のServiceディレクティブで、SSL接続に関する情報を定義するその他のパラメータを設定します。パラメータのリストは、第7.2項「Webサーバー・プラグインのSSLパラメータ」を参照してください。
ほとんどの構成では、iPlanet Web Server用Oracle WebLogic Serverプロキシ・プラグイン12.1.3は、リクエストをクラスタのプライマリ・インスタンスに送信します。そのインスタンスを使用できないと、リクエストはセカンダリ・インスタンスにフェイルオーバーします。ただし、ファイアウォールとロード・ディレクタを組み合せて使用する一部の構成では、WebLogic Serverのプライマリ・インスタンスを使用できなくても、いずれか1つのサーバー(ファイアウォールまたはロード・ディレクタ)がリクエストを受け入れ、正常な接続を返します。WebLogic Serverの使用できないプライマリ・インスタンスへのリクエストの送信が試みられると、リクエストは接続リセットとしてプラグインに返されます。
ファイアウォールの組合せを介して(ロード・ディレクタの有無に関係なく)実行されるリクエストは、WebLogic Serverによって処理されます。つまり、接続リセットのレスポンスは、WebLogic Serverのセカンダリ・インスタンスにフェイルオーバーします。このような構成では、接続リセットのレスポンスがフェイルオーバーするため、サーブレットは多重呼出し不変である必要があります。そうでない場合は、トランザクションの処理が重複する可能性があります。
WebLogic Server 12.1.3では、WebSocketアプリケーションのデプロイがサポートされています。Oracle HTTP Server 12.1.3とApache HTTPサーバー2.2.xおよび2.4.x用のWebLogic Web Serverプラグイン12.1.3では、そのようなWebSocket接続アップグレード・リクエストを処理して、WebLogic Server 12.1.3以降でホストされるWebSocketアプリケーションに効率的にプロキシできるようになりました。このサポートが追加されたことで、新しい構成パラメータであるWLMaxWebSocketClientsが導入されています。
WLMaxWebSocketClientsは、アクティブなWebSocket接続の数をいつでも制限します。このパラメータに設定できる最大値は、ThreadsPerChildの75%(Windowsの場合)またはMaxClientsの75%(Windows以外の場合)となります。したがって、HTTPサーバーのWebSocket接続アップグレード・リクエストの最大数を調整するには、MaxClientsまたはThreadsPerChildをWebSocket接続にも対応できる値に設定してください。また、WLMaxWebSocketClientsがMaxClients/ThreadsPerChildの75%に設定されていることを確認してください。
