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

このセクションの内容 

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

接続設定

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

プロキシ設定 (受信) 

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

リスナー ポートの SSL 設定

サーバー サイド SSL を設定するには、[キーストアの使用] オプションをオンにします。

次のオプションを設定します。

クライアント サイド SSL を設定するには、[クライアント認証の実行] オプションをオンにします。

次のオプションを設定します。

プライマリ接続 (送信)

セカンダリ接続 (送信)

プライマリ接続が失敗する場合またはレスポンダーを利用できない場合に、セカンダリ プロキシ エンドポイントにトラフィックをリダイレクトしたい場合、[プライマリ接続が失敗した場合にセカンダリ接続を使用] オプションを有効にします。 し、レスポンスのステータス コードが 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 接続を消費せずにローカル Virtualize サーバーの仮想アセットに転送するには、実際のホスト名ではなく localhost または 127.0.0.1 を入力します。
2. [プロキシ接続設定] の [サービス転送パス] を仮想アセットのパスに設定します。仮想アセットのパスは、[トランスポート] > [HTTP] > [パス] で確認できます。
   

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

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

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

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

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

2. ファイルをワークスペースのVirtualAssets または 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 サーバーのホストとポートの情報を入力します。

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

• サービスホスト: virtualize.parasoft.com
• サービス ポート: 9080
• プロキシ リスン パス: /path
  
  

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

• サービスホスト: localhost
• サービス ポート: 9080
• サービス転送パス: /pva
  
  

HTTP プロキシは仮想アセットと実サービスとを区別しません。両方とも同じ方法で構成されます。ただし、HTTP プロキシが 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 を参照してください。