このセクションでは、HTTP (HTTPS を含む) を介してメッセージを送信および受信するメッセージ プロキシの構成方法について説明します。 

このセクションの内容: 

基本的な HTTP 接続オプションを設定するには、ターゲットとするサービスのホスト、ポート、およびパスが必要になります。サービスに直接通信するために通常使用する設定を使用してください。 

接続設定

基本的な HTTP リバース プロキシ接続オプションを指定するには、[プロキシ接続設定] タブで次のサービスおよびリスニング詳細を設定します。

プロキシ設定 (受信) 

テスト対象アプリケーションと通信するために、クライアントからのメッセージが接続する場所を指定します。 

プライマリ接続 (送信) およびセカンダリ接続 (送信)

オプション

モード: プライマリ接続とセカンダリ接続が存在する場合に、アクティブな転送接続を設定できます。たとえば、記録セッション中に、メッセージ プロキシはプライマリ接続としてライブ サービスに転送し、セカンダリ接続として仮想サービスにフォールバックする場合があります。この場合、HTTP モードをプライマリに設定し、[Use other connection if selected mode fails] を有効にすることができます。

記録が完了し、新しい仮想アセットが生成されたら、プロキシを再設定して、最初に仮想サービスに転送し、障害が発生した場合はライブサービスにフォールバックするようにすると良いでしょう。この変更は、プロキシを右クリックして、HTTPモードを「セカンダリ」に切り替えることですぐに適用できます。フェイルオーバーは実行時にそれに応じて調整されます。

Use other connection if selected mode fails: アクティブな接続 (上で選択したモードによって決定される) が失敗したときに、トラフィックをバックアップ プロキシ エンドポイントにリダイレクトしたい場合は、このオプションを有効にします。レスポンスのステータス コードが 400 レベル以上の場合、接続は " 失敗した" と見なされます。

このオプションが無効な場合、アクティブな接続が記録に使用されます。

このオプションが有効な場合は、[記録] ドロップダウンから記録オプションを選択します。

• 両方の接続: プライマリ接続とセカンダリ接続の両方のトラフィックを記録します。アクティブな接続からレポートされたエラー メッセージは記録されません。メッセージはバックアップ接続に送信され、レスポンスが記録されます。バックアップ接続からレポートされたエラーは記録されます。
• プライマリ接続のみ: アクティブな接続のトラフィックを記録します。エラーは記録しません。
• セカンダリ接続のみ: エラーも含め、バックアップ接続のトラフィックを記録します。

[セキュリティ] タブの設定

サービス SSL セクションは、対象のサービスが SSL を使用する場合にだけ設定する必要があります。

仮想化されるサービス テスト対象アプリーケション仮想化されるサービスおよび/またはテスト対象アプリケーション が SSL および/またはその他の認証（ベーシック/ダイジェスト、Kerberos、NTLM）を使用する場合、追加の構成が必要になる場合があります。

サービス SSL フィールドの入力の詳細については、「Security Configuration」を参照してください。

[プロキシサーバー] タブの設定

このタブでメッセージ プロキシのサーバーを指定できます。これにより、さまざまなメッセージ プロキシとの間のトラフィック用に別のプロキシ サーバーを構成できます。この構成により、テスト対象アプリケーションと特定のメッセージ プロキシ間のトラフィックを処理するプロキシ サーバーを制御できます。 

このレベルでプロキシ設定を指定するには、プロキシの [プロキシ サーバー] タブで詳細情報を入力します。 

なお、SSL はサポートされません。 

サービス転送パスとプロキシ リスン パス

最も単純なケースでは、[プロキシ リスン パス ] をサービスのパスに設定し、 [サービス転送パス] は空のままにします。この構成で、プロキシはパス上で受信したすべてのメッセージを [サービス ホスト] および [サービス ポート] と同じパスへ自動的に転送します。 

サービスのパスと異なるパスをプロキシにリスンさせる必要がある場合、[サービス転送パス] に実際に着信メッセージを送信したいパスを設定します。プロキシはパスとクエリー部分を対象サービスに転送します。 

[プロキシ リスン パス] と [サービス転送パス] が異なる場合、 [プロキシ リスン パス] の後のリクエストのセグメントは転送されるリクエストに追加されます。[プロキシリスンパス] は本質的にサービス転送パスに置き換えられるので、すべてのパス (プロキシに受信された) はサービスに送信されます。

パスにワイルドカード文字を使用する

ワイルドカード文字を使用して、動的パス セグメントを指定できます。たとえば、パスを  /path/*/service として設定すると、次のパスが同じプロキシにアクセスできるようになります。 

/path/1/service 

/path/2/service 

ワイルドカードはパスセグメント全体を置換できます。例:

• /path/*/service — 有効
• /path/1*2/service — 無効

ワイルド カードは、パスの 1 つのセグメントにのみ使用できます。/path/*/service として構成されたパスは、/path/1/2/service と一致しません。パスを /path/1/2/service と /path/3/4/service の両方に一致させる場合は、パターン /path/*/*/service を使用します。

転送パスの一部として、リスン パスから動的セグメントを使用できます。2 通りの方法があります。

• リクエストが受信されたパスにトラフィックを転送したい場合、転送パスは空のままにします。

• 転送パスが異なり、動的な値が使用される必要がある場合、環境変数構文を使用して構成します。例:
  リスン パス: /path/*/service
フォワード パス: /asset/path/${1}/service

ワイルドカードを使用した動的なリスン パスのセグメントは、環境変数構文を使用してアクセスできます。出現したワイルドカードは変数名として使用されます。言い換えると、最初に出現したワイルドカードは ${1}、 2 番目は ${2}、 3 番目は ${3} 、などです。次の例では、 ${2} は 2 番目に出現したワイルドカード (リクエストパスで 「bank」の箇所) を参照します。

リスンパス : /path/*/service/*/account
フォワード パス: /asset/path/${2}/service/${1}/account

リクエスト パス: /path/1/service/bank/account
フォワード パス: /asset/path/bank/service/1/account

ヘッダー属性

ほとんどの場合、プロキシはすべてのヘッダーを直接、対象サービスへ渡します。コンテンツの長さに関連する一部のヘッダーは、プロキシ サーバーの動作に合わせて変更されることがあります。たとえば、プロキシ サーバーは「チャンク形式」転送エンコーディングの応答に対応していないので、"host" ヘッダーを自身のホスト名と一致するよう置き換えます (ただし、ターゲットサービスからのチャンクされたリクエストおよびチャンクされたレスポンスの受信はサポートしません)。

ターゲット サービスの設定

プロキシは、 サーバーの仮想アセットまたはテスト アセットをターゲット サービスとして使用できます。 

1. サービス ホストとサービス ポートを、仮想アセットがデプロイされている Virtualize サーバーに設定します。HTTP 接続を消費せずにローカル サーバーの仮想アセットに転送するには、実際のホスト名ではなく、host.virt.internal、localhost または 127.0.0.1 を入力します。localhost または 127.0.0.1 を使用する場合、サービス ポートは Virtualize がデプロイされているポートと一致する必要があります。host.virt.internal を使用する場合、サービス ポートは使用されません。
2. [プロキシ接続設定] の [サービス転送パス] を仮想アセットのパスに設定します。仮想アセットのパスは、[トランスポート] > [HTTP] > [パス] で確認できます。
   

チャンキング/アンチャンキングの動作

プロキシは、ターゲット サービスからのチャンクされたリクエストおよびチャンクされたレスポンスの受信をサポートします。サービス レスポンスが HTTP チャンキングを使用する場合、プロキシは元の呼び出し元/ テスト対象アプリケーションに返す前にレスポンスをアンチャンクします。

その他の HTTP メッセージ プロキシ設定

プロパティ ファイルを作成して、リバース プロキシ HTTP リスナー設定を指定することができます。プロパティ ファイルを使用すると、リバース プロキシ HTTP リスナーのパフォーマンスを微調整したり、追加の SSL 設定を指定できます。

1. プレーン テキスト ファイルを作成し、設定するプロパティを指定します (「Reverse Proxy HTTP Listener Message Proxy Performance Properties」および「Reverse Proxy HTTP Listener Message Proxy SSL Properties」を参照)。 

2. ファイルをワークスペースの VirtualAssetsTestAssetsVirtualAssets または TestAssets ディレクトリに保存し、名前を embeddedServer.properties とします。

リバース プロキシ HTTP リスナーが設定されたプロキシが有効化されるたびに、このファイルが読み込まれます。

リバース プロキシ HTTP リスナーのプロパティ

リバース プロキシ HTTP リスナー メッセージ プロキシのパフォーマンス プロパティ

すべてのプロパティは任意であり、整数以外の値は無視されます。

リバース プロキシ HTTP リスナー メッセージ プロキシの SSL プロパティ

例: サービスにトラフィックを送信する

http://example.parasoft.com:9080/BookStore でアクセスされるサービスにメッセージを作成したいと仮定します。次の設定で HTTP リバース プロキシを作成できます。 

• プロキシ リスン パス: /BookStore
• サービスホスト:example.parasoft.com
• サービス ポート: 9080
• サービス転送パス: [空]
  

この設定は、 /BookStore をリスンし、すべてのトラフィックを実際のブックストア サービスに転送します。

サービス パス以外のパスをリスンしたい場合、次のようにプロキシの設定を変更します。

• サービス転送パス: /BookStore
• プロキシ リスン パス: /SomeOtherPath
  

この設定は、 /SomeOtherPath からのトラフィックを実際のブックストア サービスに転送します。 

いずれの場合も、これらのパス ( サブパスを含む) へ向かうすべてのトラフィックは、サービスに送信されます。2 つ目の例で、/SomeOtherPath/SubPath へ送信されるトラフィックは、 /BookStore/SubPath に送信されます。クエリーは保持されるので、/SomeOtherPath?param=value は /BookStore?param=value へ送信されます。

ヘッダー名の大文字/小文字の区別を必要とするサービスにリクエストを転送する場合

デスクトップのサーバーを使用している場合、メッセージ プロキシのヘッダーは小文字で設定されるため、HTTP ヘッダー名の大文字/小文字を区別するサービスにリクエストを転送すると、処理が失敗する可能性があります。

その場合、/VirtualAssets/ ディレクトリに _global.headers ファイルを作成し、渡したい大文字/小文字を区別したヘッダーをファイルに追加します。UI でサーバーを右クリックし、すべての仮想アセットを再デプロイすると、環境でこのファイルが使用されるようになります。

特定のメッセージ プロキシにおける HTTP ヘッダーの大文字/小文字の問題にも、同様の方法で対処できます。その場合、/VirtualAssets/ ディレクトリに <proxy-name>.headers ファイルを作成し、プロキシに渡したい大文字/小文字を区別したヘッダーをファイルに追加します。このファイルは特定のプロキシに適用され、グローバル ファイルの設定を上書きします。UI でサーバーを右クリックし、すべての仮想アセットを再デプロイすると、環境でこのファイルが使用されるようになります。

ヘッダー ファイルの例

X-AUTHORIZATION ANOTHER-HEADER HEADER3

例: 仮想アセットにトラフィックを送信する

プロキシはトラフィックを仮想アセットへ送ることもできます。その場合は、あたかも別のサーバーであるかのように、Virtualize サーバーのホストとポートの情報を入力します。

たとえば、リモート サーバー上の仮想アセットにトラフィックを送信するには、次の設定を使用します。 

• プロキシ リスン パス: /proxyPath
• サービスホスト: server.parasoft.com
• サービス ポート: 9080
• サービス転送パス: /assetPath
  

HTTP リスナーを使用してローカル サーバー上の仮想アセットにトラフィックを送信するには、次の設定を使用します。

• リバース プロキシ: 7070
• サービス ホスト: [Virtualize]

HTTP リスナーなしでローカル サーバー上の仮想アセットにトラフィックを送信するには、次の設定を使用します。

• プロキシ リスン パス: /proxyPath
• サービス ホスト: [Virtualize]
• サービス転送パス: /assetPath
  

HTTP リバース プロキシは仮想アセットと実サービスとを区別しません。両方とも同じ方法で構成されます。ただし、デフォルトの HTTP リバース プロキシ (HTTP リスナーなし) が [Virtualize] または localhost に送信している場合、プロキシはそれ自体への転送を許可しないため、サービス転送パスを指定する必要があります。

セキュリティ設定

セキュリティの構成には 2 つの観点があります。 

• トラフィック転送先のサービスが SSL および/またはアクセス制御を使用する場合、プロキシ レベルの構成 を実施する必要があります (プロキシの GUI 画面から実施)。
• テスト対象アプリケーションが SSL および/またはアクセス制御を使用する場合、サーバー レベルの構成 を実施する必要があります (Tomcat ベースの サーバーで実施)。

構成に応じて、セキュリティ設定かまたは両方を構成します。

プロキシ レベルの設定

プロキシ レベルのセキュリティ設定 (トラフィックの転送先のサービスが SSL および/またはアクセス制御を使用する場合に該当) では、以下を設定できます。

• SSL
• ベーシック認証/ ダイジェスト認証
• NTLM Authentication
• Kerberos Authentication

SSL

SSL では、追加設定が必要です。コンフィギュレーション パネルで、以下について指定します。

• [自己署名証明書を信頼する] をオンにする。
• [すべてのサーバー証明書を信頼する] をオンにする。
• サーバー証明書を検証するためにトラスト ストアを設定する。

さらに、 Parasoft がどの証明書をサーバーに提示するかを判断できるように、特定のキー ストアおよび証明書を使用するために必要な情報を提供する必要があります ( たとえば、2 方向 SSL 用など)。

[サービス SSL 設定] フィールド

注意: トラスト ストアの構成 (後述) は、すべての [すべてのサーバー証明書を信頼する] と [自己署名証明書を信頼する] が両方ともオフの場合にだけ適用可能です。

[Keystore] フィールド

キーストアの詳細を入力したら、[ロード] をクリックし、[証明書] ドロップダウンからサーバーに提示する証明書エイリアスを選択します。[ロード] をクリックしても [証明書] ドロップダウンにデータが投入されない場合、パスワードやキーストア タイプが間違って入力されている可能性があります。

[Truststore] フィールド

これらのフィールドは、[ すべてのサーバー証明書を信頼する] と [自己署名証明書を信頼する] (上述) の両方がオフの場合にだけ適用可能です。

[NTLM 設定] フィールド

[Kerberos の設定] フィールド

ベーシック認証/ ダイジェスト認証

テスト対象アプリケーションが、リクエストの一部としてベーシック認証およびダイジェスト認証の証明書を提供し、HTTP ヘッダーの一部として送信する場合、プロキシはそれらを変更されていないサービスに渡します (その他の HTTP ヘッダーの扱い方と同じです)。 

NTLM 認証

サービスが NTLM 認証を必要とする場合、[NTLM 設定] 項目にユーザー名/パスワードを入力します。

Kerberos 認証

サービスが Kerberos 認証を必要とする場合、[Kerberos の設定] 項目に Kerberos サービス プリンシパルを設定します。

サーバーレベルの設定

サーバーレベルのセキュリティ設定 (テスト対象アプリケーションが SSL および/またはアクセス認証を使用する場合に該当) では、以下を設定できます。

• Configuring the Virtualize Server
• Using NTLM with WAFFLE
• Using Unsupported Configurations (Kerberos with WAFFLE, JAAS)

SOAtest/Virtualize Server の設定

デフォルトのポート番号（9080）を変更したり、SSL を有効にしたり、その他のサーバー設定を構成したりできます。詳細については「サーバーの設定」を参照してください。 

WAFFLE で NTLM を使用する

NTLM にサードパーティ製ライブラリの WAFFLE を使用するには、次の操作を行います。

1. 次の jar ファイルを tomcat の lib ディレクトリにコピーします：jna.jar, platform.jar, wafflejna.jar

2. 以下を tomcat/conf/server.xml に追加します。
   
   

   <Context>
     <Valve className="waffle.apache.NegotiateAuthenticator" principalFormat="fqn" roleFormat="both"/> 
     <Realm className="waffle.apache.WindowsRealm" /> </Context> 

   server.xml の場所について

   - SOAtest だけをインストールした場合 (Virtualize はインストールしていない場合): SOAtest を起動し、少なくとも 1 つのレスポンダーが作成されていることを確認します。その後、<INSTALL>/plugins/com.parasoft.ptest.libs.web_<VERSION>/root/tomcat/conf/server.xml ファイルを修正します。

   - Virtualize だけをインストールした場合 (SOAtest はインストールしていない場合): Virtualize を起動し、少なくとも 1 つのレスポンダーが作成されていることを確認します。その後、<INSTALL>/plugins/com.parasoft.ptest.libs.web_<VERSION>/root/tomcat/conf/server.xml ファイルを修正します。

   - Virtualize と SOAtest を一緒にインストールした場合: Virtualize を起動し、少なくとも 1 つのレスポンダーが作成されていることを確認します。その後、<INSTALL>/plugins/com.parasoft.ptest.libs.web_<VERSION>/root/tomcat/conf/server.xml ファイルを修正します。

3. tomcat/conf/web.xml に以下を追加します。

   <security-role> 
     <role-name>Everyone</role-name> 
   </security-role> 
   <security-constraint> 
     <display-name>Waffle Security Constraint</display-name> 
     <web-resource-collection> 
       <web-resource-name>Protected Area</web-resource-name> 
       <url-pattern>/*</url-pattern> 
     </web-resource-collection> 
     <auth-constraint> 
       <role-name>Everyone</role-name> 
     </auth-constraint> 
   </security-constraint> 

4. サーバーを再起動します。

さらに詳しい説明については、Single Sign-On: Tomcat Negotiate Authenticator (Kerberos + NTLM) w/ Waffle のチュートリアルおよびWAFFLE の Web サイトを参照してください。

サポート対象外の構成を使用する (Kerberos と WAFFLE、 JAAS)

WAFFLE は Kerberos 認証もサポートしています。使用方法とサポート内容については、WAFFLE の Web サイトを参照してください。 

JAAS でも、Kerberos 認証を実行するために Tomcat ベースの Virtualize サーバーを構成できます。JAAS の使用方法については、Tomcat を参照してください。