このセクションでは、HTTP (HTTPS を含む) を介してメッセージを送信および受信するメッセージ プロキシの構成方法について説明します。
Note | ||
---|---|---|
| ||
Virtualize/SOAtest 9.10.x 以降で記録した HTTP トラフィック ファイルは、バージョン 9.9.x 以前の Virtualize/SOAtest では使用できません。 |
このセクションの内容:
Table of Contents | ||
---|---|---|
|
基本的な HTTP 接続オプションを設定するには、ターゲットとするサービスのホスト、ポート、およびパスが必要になります。サービスに直接通信するために通常使用する設定を使用してください。
Anchor | ||||
---|---|---|---|---|
|
基本的な HTTP リバース プロキシ接続オプションを指定するには、[プロキシ接続設定] タブで次のサービスおよびリスニング詳細を設定します。
プロキシ設定 (受信)
テスト対象アプリケーションと通信するために、クライアントからのメッセージが接続する場所を指定します。
リバース プロキシ: メニューからプロキシ作成時に定義したリバース プロキシ HTTP リスナーを選択するか (「Creating Proxies」を参照)、デフォルトのリスナーを使用します。
このダイアログからリバース プロキシ HTTP リスナーを追加することもできます。
- [新規] をクリックし、リスナーの名前を入力します。
- [ポートの追加] をクリックし、ポート番号を入力します。ポート番号として
0
を指定すると、メッセージ プロキシがポートを自動的に割り当てることができます。プロキシを有効にすると、割り当てられたポート番号がコンソールに表示されます。メッセージ プロキシが変更/有効化されるたびに、ポートがランダムに割り当てられます。GET リクエストをmessageProxies
API エンドポイントに送信して、自動的に割り当てられたポート番号を返すこともできます。詳細については「Creating and Modifying Assets through the REST API」を参照してください。 - クライアントが SSL 経由でトラフィックを送信する場合、[セキュア] オプションをオンにして認証オプションを有効化します。詳細については「リバース プロキシ リスナー ポートの SSL 設定」を参照してください。
- [OK] をクリックしてポート エディターを終了します。
- [追加] をクリックしてプロキシに別のポートを追加するか、[OK] をクリックしてプロキシの追加を終了します。
プロキシ リスン パス: プロキシが受信接続を待機するパスを入力します。すべてのパスをリスンするには、メニューから [All] を選択します。
複数のメッセージ プロキシが、同じプロキシ パスまたは既存の仮想アセットの HTTP パスと一致する HTTP プロキシ接続を持つことはできません。
詳細については「Service Forward Path and Proxy Listen Path」を参照してください。
プロキシ URL: テスト対象アプリケーション (AUT) に渡されるべき URL を表示します。 詳細については「Directing AUTs to Proxies」を参照してください。
サービス接続 (送信)
プライマリ接続とセカンダリ接続の両方について、ターゲット アプリケーションの仮想アセットまたはメッセージ プロキシへの URL またはパスを指定します。プライマリとセカンダリは同じ方法で設定されます。
- ターゲット アプリケーションの URL を指定するには、メニューから [カスタム] を選択し、URL フィールドにサービス ホスト、サービス ポート、および (オプションで) 転送パスで構成される完全な URL を入力します。サービス URL の各コンポーネントについては、以下の注意事項を参照してください。なお、URL フィールドにクエリ パラメーターを指定した場合、クエリ パラメーターは無視されることに注意してください。
- サービス ホスト: HTTP 接続を消費せずにローカル サーバーの仮想アセットに転送するには、実際のホスト名ではなく、サービス ホストとして
host.virt.internal
、localhost
または127.0.0.1
を入力します。localhost
または127.0.0.1
を使用する場合、サービス ポートは Virtualize がデプロイされているポートと一致する必要があります。host.virt.internal
を使用する場合、サービス ポートは使用されません。たとえば、http://localhost:9080/myVirtualAsset
にデプロイされた仮想アセットには、http://host.virt.internal/myVirtualAsset
を使用してアクセスすることもできます。 - サービス ポート: プロキシがメッセージを送信するポートです。
- 転送パス: [転送パス] を指定しない場合、[プロキシ リスン パス] が使用されます。HTTP プロキシがメッセージを localhost に送信する場合、プロキシは自分自身に転送できないため、転送パスに入力する必要があります。転送パスがリダイレクトを送信する場合、プロキシはリダイレクトを追跡し、応答します。クライアントにはリダイレクトを渡しません。詳細については「Service Forward Path and Proxy Listen Path」を参照してください。
- サービス ホスト: HTTP 接続を消費せずにローカル サーバーの仮想アセットに転送するには、実際のホスト名ではなく、サービス ホストとして
- ターゲット アプリケーションの仮想アセットまたはメッセージ プロキシへのパスを指定するには、メニューから [仮想化] を選択し、仮想アセットまたはメッセージ プロキシへのパスを [パス] フィールドに入力します。
オプション
モード: プライマリ接続とセカンダリ接続が存在する場合に、アクティブな転送接続を設定できます。たとえば、記録セッション中に、メッセージ プロキシはプライマリ接続としてライブ サービスに転送し、セカンダリ接続として仮想サービスにフォールバックする場合があります。この場合、HTTP モードをプライマリに設定し、[Use other connection if selected mode fails] を有効にすることができます。
記録が完了し、新しい仮想アセットが生成されたら、プロキシを再設定して、最初に仮想サービスに転送し、障害が発生した場合はライブサービスにフォールバックするようにすると良いでしょう。この変更は、プロキシを右クリックして、HTTPモードを「セカンダリ」に切り替えることですぐに適用できます。フェイルオーバーは実行時にそれに応じて調整されます。
Use other connection if selected mode fails: アクティブな接続 (上で選択したモードによって決定される) が失敗したときに、トラフィックをバックアップ プロキシ エンドポイントにリダイレクトしたい場合は、このオプションを有効にします。レスポンスのステータス コードが 400 レベル以上の場合、接続は " 失敗した" と見なされます。 Anchor UserOtherConnection UserOtherConnection
Info | ||
---|---|---|
| ||
メッセージ レスポンダーは、[Skip message proxy failover] オプションを有効にすることで、内部的にルーティングされるメッセージに対してこのプロキシ フェールオーバーをバイパスするように構成できます。 |
このオプションが無効な場合、アクティブな接続が記録に使用されます。
このオプションが有効な場合は、[記録] メニューから記録オプションを選択します。
- 両方の接続: プライマリ接続とセカンダリ接続の両方のトラフィックを記録します。アクティブな接続からレポートされたエラー メッセージは記録されません。メッセージはバックアップ接続に送信され、レスポンスが記録されます。バックアップ接続からレポートされたエラーは記録されます。
- プライマリ接続のみ: アクティブな接続のトラフィックを記録します。エラーは記録しません。
- セカンダリ接続のみ: エラーも含め、バックアップ接続のトラフィックを記録します。
有効な HTTP レスポンス コード範囲: メッセージ プロキシのフェイルオーバーの動作をカスタマイズし、200 番台以外のHTTPレスポンス コードを成功とすることができます。コードおよび/またはコードの範囲をカンマで区切って入力します。たとえば「404, 500-599」を使用した場合、「404 のコード」 または「500 番台の任意のコード」が許容されます。
Learn responses: ライブ エンドポイントから記録されたレスポンスを内部エンドポイントにエミュレートするように学習させる場合は、このオプションを有効にします。内部エンドポイントにはファイル レスポンダーが必要です (詳細については「Request Response Files」を参照)。このオプションは、[Use other connection if selected mode fails] が有効になっている場合にのみ使用できます (上記を参照)。プロキシを右クリックしてモードを [すべて有効] または [すべて無効] に切り替えることで、プロキシによる学習の有効/無効を簡単に切り替えることができます。
[セキュリティ] タブの設定
サービス SSL セクションは、対象のサービスが SSL を使用する場合にだけ設定する必要があります。
Security Configuration」を参照してください。
仮想化対象のサービスおよび/またはテスト対象アプリケーションが SSL および/または他の認証 (ベーシック/ダイジェスト、Kerberos、NTLM) を使用する場合、他の設定も必要になる可能性があります。サービス SSL フィールドの入力の詳細については、「[プロキシサーバー] タブの設定
このタブでメッセージ プロキシのサーバーを指定できます。これにより、さまざまなメッセージ プロキシとの間のトラフィック用に別のプロキシ サーバーを構成できます。この構成により、テスト対象アプリケーションと特定のメッセージ プロキシ間のトラフィックを処理するプロキシ サーバーを制御できます。
このレベルでプロキシ設定を指定するには、プロキシの [プロキシ サーバー] タブで詳細情報を入力します。
なお、SSL はサポートされません。
Anchor | ||||
---|---|---|---|---|
|
最も単純なケースでは、[プロキシ リスン パス ] をサービスのパスに設定し、 [サービス転送パス] は空のままにします。この構成で、プロキシはパス上で受信したすべてのメッセージを [サービス ホスト] および [サービス ポート] と同じパスへ自動的に転送します。
サービスのパスと異なるパスをプロキシにリスンさせる必要がある場合、[サービス転送パス] に実際に着信メッセージを送信したいパスを設定します。プロキシはパスとクエリー部分を対象サービスに転送します。
[プロキシ リスン パス] と [サービス転送パス] が異なる場合、 [プロキシ リスン パス] の後のリクエストのセグメントは転送されるリクエストに追加されます。[プロキシリスンパス] は本質的にサービス転送パスに置き換えられるので、すべてのパス (プロキシに受信された) はサービスに送信されます。
パスにワイルドカード文字を使用する
ワイルドカード文字を使用して、動的パス セグメントを指定できます。たとえば、パスを /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" ヘッダーを自身のホスト名と一致するよう置き換えます (ただし、ターゲットサービスからのチャンクされたリクエストおよびチャンクされたレスポンスの受信はサポートしません)。
ターゲット サービスの設定
プロキシは、 サーバーの仮想アセットまたはテスト アセットをターゲット サービスとして使用できます。
- サービス ホストとサービス ポートを、仮想アセットがデプロイされている Virtualize サーバーに設定します。HTTP 接続を消費せずにローカル サーバーの仮想アセットに転送するには、実際のホスト名ではなく、host.virt.internal、localhost または 127.0.0.1 を入力します。localhost または 127.0.0.1 を使用する場合、サービス ポートは Virtualize がデプロイされているポートと一致する必要があります。host.virt.internal を使用する場合、サービス ポートは使用されません。
- [プロキシ接続設定] の [サービス転送パス] を仮想アセットのパスに設定します。仮想アセットのパスは、[トランスポート] > [HTTP] > [パス] で確認できます。
チャンキング/アンチャンキングの動作
プロキシは、ターゲット サービスからのチャンクされたリクエストおよびチャンクされたレスポンスの受信をサポートします。サービス レスポンスが HTTP チャンキングを使用する場合、プロキシは元の呼び出し元/ テスト対象アプリケーションに返す前にレスポンスをアンチャンクします。
その他の HTTP メッセージ プロキシ設定
プロパティ ファイルを作成して、リバース プロキシ HTTP リスナー設定を指定することができます。プロパティ ファイルを使用すると、リバース プロキシ HTTP リスナーのパフォーマンスを微調整したり、追加の SSL 設定を指定できます。
- プレーン テキスト ファイルを作成し、設定するプロパティを指定します (「Reverse Proxy HTTP Listener Message Proxy Performance Properties」および「Reverse Proxy HTTP Listener Message Proxy SSL Properties」を参照)。
ファイルをワークスペースの VirtualAssets または TestAssets ディレクトリに保存し、名前を embeddedServer.properties とします。
リバース プロキシ HTTP リスナーが設定されたプロキシが有効化されるたびに、このファイルが読み込まれます。
リバース プロキシ HTTP リスナーのプロパティ
Scroll Table Layout | ||
---|---|---|
|
embedded.connector.maxHttpHeaderSize | リクエストとレスポンスの HTTP ヘッダーの最大サイズを指定します(byte)。指定しない場合、この属性は 8192 (8 KB) に設定されます。 |
---|---|
embedded.connector.parseBodyMethods | 特に PUT リクエストで POST スタイルのセマンティクスをサポートしたい場合に、POSTと同様に |
embedded.connector.relaxedPathChars | エンコードされていない形式で URI パスで許可される文字を指定します。値は、次の文字の任意の組み合わせにすることができます。
値中の他の文字はすべて無視されます。このプロパティが含まれていない場合、Tomcat は URI パス内の上記の文字のエンコードされていない形式を拒否します。 詳細については Tomcat のドキュメントを参照してください: https://tomcat.apache.org/tomcat-8.5-doc/config/http.html |
embedded.connector.relaxedQueryChars | エンコードされていない形式で URI クエリーで許可される文字を指定します。値は、次の文字の任意の組み合わせにすることができます。
値中の他の文字はすべて無視されます。このプロパティが含まれていない場合、Tomcat は URI クエリー内の上記の文字のエンコードされていない形式を拒否します。 詳細については Tomcat のドキュメントを参照してください: https://tomcat.apache.org/tomcat-8.5-doc/config/http.html |
リバース プロキシ HTTP リスナー メッセージ プロキシのパフォーマンス プロパティ
すべてのプロパティは任意であり、整数以外の値は無視されます。
Scroll Table Layout | ||
---|---|---|
|
embedded.connector.maxThreads | コネクターが作成するリクエスト処理スレッドの最大数を指定します。このプロパティにより、同時に処理可能なリクエストの最大数が決まります。デフォルトは 200 です。 |
---|---|
embedded.connector.minThreads | 常時実行するスレッドの最小数を指定します。デフォルトは 10 です。 |
embedded.connector.acceptors | 接続を受け入れるのに使用するスレッドの数を指定します。CPU を複数搭載するマシンを使用する場合、または複数の非キープアライブ接続を使用する場合、この値を増やします。1 または 2 が多くの場合、適切です。デフォルトは 1 です。 |
embedded.connector.idleTimeout | コネクターが接続を閉じる前に他の HTTP リクエストを待機する時間をミリ秒単位で指定します。-1 を指定すると、接続は無期限に待機します。デフォルトは connectTimeout を使用します。 |
embedded.connector.soLingerTime | コネクターによって使用されるソケットが接続を閉じる前に待機する時間をミリ秒単位で指定します。デフォルトでは、待機しません。 |
embedded.connector.acceptorPriorityDelta | 新規接続を受け入れるために使用するアクセプター スレッドの優先度を指定します。詳細については java.lang.Thread JavaDoc を参照してください。デフォルトは 5 です。 |
embedded.connector.acceptQueueSize | すべてのリクエスト処理スレッドが使用中の時に、受信接続リクエストを入れるキューの最大の長さを指定します。キューが満杯のときに受信されたリクエストは拒否されます。デフォルトは 100 です。 |
embedded.connector.connectTimeout | 接続を受け入れた後、リクエスト URI 行が提示されるのをコネクターが待機する時間をミリ秒単位で指定します。-1 を指定すると、接続は無期限に待機します。デフォルトは 60000 です。 |
リバース プロキシ HTTP リスナー メッセージ プロキシの SSL プロパティ
Scroll Table Layout | ||
---|---|---|
|
embedded.ssl.includeProtocols | HTTPS 接続をサポートする SSL プロトコルのカンマ区切りのリストです。このオプションが指定されている場合、リストに挙げられているプロトコルだけが JVM の SSL 実装によってサポートされます。このオプションが指定されていない場合、JVM によって使用されるプロトコルがサポートされます (JVM がデフォルトで SSLv2 または SSLv3 の両方またはどちらかを有効にする場合、これらは除きます)。 |
---|---|
embedded.ssl.includeCipherSuites | HTTPS 接続をサポートする暗号化のカンマ区切りのリストです。JSSE の暗号化名前付け規約を使用して暗号化を指定します。このオプションが指定されている場合、リストに挙げられている暗号化だけが SSL 実装によってサポートされます。このオプションが指定されていない場合、セキュアとみなされないものを除いた JVM のデフォルトの暗号化スイートがサポートされます。結果として、古い JVM では、デフォルトでは非常に限られた数の暗号化だけしか利用できません。 |
embedded.ssl.useCipherSuitesOrder |
|
embedded.ssl.maxCertPathLength | クライアント証明書を検証する際に許容される中間証明書の最大数を指定します。デフォルトは 5 です。 |
embedded.ssl.crlPath | クライアント証明書の検証に使用する証明書失効リスト ファイルへのパスを設定します。指定されていない場合、クライアント証明書と証明書失効リストの照合は行われません。 |
embedded.ssl.keyManagerAlgorithm | 証明書暗号化アルゴリズムを指定します。デフォルトでは、KeyManagerFactory.getDefaultAlgorithm() が使用され、SunJVM に対してSunX509 を返します。IBM JVM では IbmX509 を返します。 |
embedded.ssl.truststoreAlgorithm | トラストストアに使用するアルゴリズムを指定します。指定されていない場合、javax.net.ssl.TrustManagerFactory.getDefaultAlgorithm() が返すデフォルト値が使用されます。 |
embedded.ssl.useKeyManagerAlgorithmForTruststore | true を指定すると、トラスト ストアのアルゴリズムとしてキー マネージャー アルゴリズムが使用されます。これは、embedded.ssl.truststoreAlgorithm プロパティよりも優先されます。デフォルトは false です。 |
例: サービスにトラフィックを送信する
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 でサーバーを右クリックし、すべての仮想アセットを再デプロイすると、環境でこのファイルが使用されるようになります。
ヘッダー ファイルの例
Code Block |
---|
X-AUTHORIZATION ANOTHER-HEADER HEADER3 |
例: 仮想アセットにトラフィックを送信する
プロキシはトラフィックを仮想アセットへ送ることもできます。その場合は、あたかも別のサーバーであるかのように、Virtualize サーバーのホストとポートの情報を入力します。
たとえば、リモート サーバー上の仮想アセットにトラフィックを送信するには、次の設定を使用します。
- プロキシ リスン パス: /proxyPath
- サービスホスト: server.parasoft.com
- サービス ポート: 9080
- サービス転送パス: /assetPath
HTTP リスナーを使用してローカル サーバー上の仮想アセットにトラフィックを送信するには、次の設定を使用します。
- リバース プロキシ: 7070
- サービス ホスト: [Virtualize]
HTTP リスナーなしでローカル サーバー上の仮想アセットにトラフィックを送信するには、次の設定を使用します。
- プロキシ リスン パス: /proxyPath
- サービス ホスト: [Virtualize]
- サービス転送パス: /assetPath
HTTP リバース プロキシは仮想アセットと実サービスとを区別しません。両方とも同じ方法で構成されます。ただし、デフォルトの HTTP リバース プロキシ (HTTP リスナーなし) が [Virtualize]
または localhost
に送信している場合、プロキシはそれ自体への転送を許可しないため、サービス転送パスを指定する必要があります。
Info | ||
---|---|---|
| ||
Vritualize デスクトップのサーバーを使用している場合、メッセージ プロキシのヘッダーは小文字で設定されるため、HTTP ヘッダー名の大文字/小文字を区別するサービスにリクエストを転送すると、処理が失敗する可能性があります。詳細については「Forwarding Requests to Services that Require Case-sensitive Header Names」を参照してください。 |
Anchor | ||||
---|---|---|---|---|
|
セキュリティの構成には 2 つの観点があります。
- トラフィック転送先のサービスが SSL および/またはアクセス制御を使用する場合、プロキシ レベルの構成 を実施する必要があります (プロキシの GUI 画面から実施)。
- テスト対象アプリケーションが SSL および/またはアクセス制御を使用する場合、サーバー レベルの構成 を実施する必要があります (Tomcat ベースの サーバーで実施)。
構成に応じて、セキュリティ設定かまたは両方を構成します。
Anchor | ||||
---|---|---|---|---|
|
プロキシ レベルのセキュリティ設定 (トラフィックの転送先のサービスが SSL および/またはアクセス制御を使用する場合に該当) では、以下を設定できます。
Anchor | ||||
---|---|---|---|---|
|
SSL では、追加設定が必要です。コンフィギュレーション パネルで、以下について指定します。
- [自己署名証明書を信頼する] を有効にする。
- [すべてのサーバー証明書を信頼する] を有効にする。
- サーバー証明書を検証するためにトラスト ストアを設定する。
さらに、 Parasoft がどの証明書をサーバーに提示するかを判断できるように、特定のキー ストアおよび証明書を使用するために必要な情報を提供する必要があります ( たとえば、2 方向 SSL 用など)。
[サービス SSL 設定] フィールド
Scroll Table Layout | ||
---|---|---|
|
オプション | 説明 |
---|---|
サービス接続時に SSL を使用する | SSL を有効にします。 |
すべてのサーバー証明書を信頼する | 有効にすると、どんな証明書でも許可されます。証明書の検証はされません。 このオプションは、メッセージプロキシがサービスとの接続を確立するときの信頼性の検証を無効にします。サービスが提示するいかなる証明書でも接続は受け入れられます。 |
自己署名証明書を信頼する | 有効にすると、検証メソッド java.security.cert.X509Certificate.checkValidity() が証明書に対して true を返す限り、その証明書は受け入れられます。この検証メソッドは、現在の日時が証明書の有効期限内であるかを効果的にチェックします。証明書のトラストパスは評価されず、トラストストアの構成は適用されません。 このオプションは、「サービスが提示する信頼された認証局によって署名されていない証明書」を信頼するかどうかを決定します。一般的にこのオプションは、 SOAtest または Virtualize がデプロイされている環境で証明書の信頼が焦点ではない場合に有効にします。 |
注意: トラスト ストアの構成 (後述) は、すべての [すべてのサーバー証明書を信頼する] と [自己署名証明書を信頼する] が両方とも無効の場合にだけ適用可能です。
[Keystore] フィールド
Scroll Table Layout | ||
---|---|---|
|
オプション | 説明 |
---|---|
キー ストア ファイル | キー ストア ファイルへのパスを指定します。キーストアは、SSL ハンドシェイク中にメッセージ プロキシがサービスに提示する証明書とキーを指定します。 |
キー ストア パスワード | キーストアにアクセスするためのパスワードを指定します。 |
キー ストア タイプ | キーストアにアクセスするためのパスワードを指定します。 |
証明書 | サーバーへ認証するときに使用する証明書のエイリアスを指定します。 |
キーストアの詳細を入力したら、[ロード] をクリックし、[証明書] からサーバーに提示する証明書エイリアスを選択します。[ロード] をクリックしても [証明書] にデータが投入されない場合、パスワードやキーストア タイプが間違って入力されている可能性があります。
[Truststore] フィールド
これらのフィールドは、[ すべてのサーバー証明書を信頼する] と [自己署名証明書を信頼する] (上述) の両方が無効の場合にだけ適用可能です。
Scroll Table Layout | ||
---|---|---|
|
オプション | 説明 |
---|---|
キー ストア ファイル | トラストストア ファイルへのパスを指定します。トラストストアは、メッセージ プロキシがサービスとハンドシェイクを行うときに信頼するべき証明書を指定します。サービスがこのトラスト ストアに含まれていない証明書を提示するとき、接続は拒否されます。トラスト ストアが提供されない場合は、デフォルトの JRE トラスト ストアが使用されます。 このオプションは、 [すべてのサーバー証明書を信頼する] が無効の場合に利用可能です。 |
キー ストア パスワード | トラスト ストアに接続するためのパスワードを指定します。 |
キー ストア タイプ | トラスト ストアに接続するためのパスワードを指定します。 |
[NTLM 設定] フィールド
Scroll Table Layout | ||
---|---|---|
|
オプション | 説明 |
---|---|
NTLM の使用 | サービスが NTLM 認証を必要とするかどうかを指定します。 |
ユーザー名 | NTLM 認証のユーザー名を指定します。 |
パスワード | NTLM 認証のパスワードを指定します。 |
[Kerberos の設定] フィールド
Scroll Table Layout | ||
---|---|---|
|
オプション | 説明 |
---|---|
Kerberos サービス プリンシパル | リクエストを認証するためのサービス プリンシパルを指定します。 |
Anchor | ||||
---|---|---|---|---|
|
テスト対象アプリケーションが、リクエストの一部としてベーシック認証およびダイジェスト認証の証明書を提供し、HTTP ヘッダーの一部として送信する場合、プロキシはそれらを変更されていないサービスに渡します (その他の HTTP ヘッダーの扱い方と同じです)。
Anchor | ||||
---|---|---|---|---|
|
サービスが NTLM 認証を必要とする場合、[NTLM 設定] 項目にユーザー名/パスワードを入力します。
Anchor | ||||
---|---|---|---|---|
|
サービスが Kerberos 認証を必要とする場合、[Kerberos の設定] 項目に Kerberos サービス プリンシパルを設定します。
サーバーレベルの設定
サーバーレベルのセキュリティ設定 (テスト対象アプリケーションが SSL および/またはアクセス認証を使用する場合に該当) では、以下を設定できます。
- Configuring the Virtualize Server
- Using NTLM with WAFFLE
- Using Unsupported Configurations (Kerberos with WAFFLE, JAAS)
SOAtest/Virtualize Server の設定
デフォルトのポート番号(9080)を変更したり、SSL を有効にしたり、その他のサーバー設定を構成したりできます。詳細については「Configuring Virtualize Server」を参照してください。
Anchor | ||||
---|---|---|---|---|
|
NTLM にサードパーティ製ライブラリの WAFFLE を使用するには、次の操作を行います。
- 次の jar ファイルを tomcat の
lib
ディレクトリにコピーします:jna.jar, platform.jar, wafflejna.jar tomcat/conf/
ディレクトリにある server.xml ファイルに以下を追加します。Code Block <Context> <Valve className="waffle.apache.NegotiateAuthenticator" principalFormat="fqn" roleFormat="both"/> <Realm className="waffle.apache.WindowsRealm" /> </Context>
Info title server.xml の場所について - SOAtest だけをインストールした場合 (Virtualize はインストールしていない場合): SOAtest を起動し、少なくとも 1 つのレスポンダーが作成されていることを確認します。その後、<INSTALL-DIR>/plugins/com.parasoft.ptest.libs.web_<VERSION>/root/tomcat/conf にある server.xml ファイルを修正します。
- Virtualize だけをインストールした場合 (SOAtest はインストールしていない場合): Virtualize を起動し、少なくとも 1 つのレスポンダーが作成されていることを確認します。その後、<INSTALL-DIR>/plugins/com.parasoft.ptest.libs.web_<VERSION>/root/tomcat/conf にある server.xml ファイルを修正します。
- Virtualize と SOAtest を一緒にインストールした場合: Virtualize を起動し、少なくとも 1 つのレスポンダーが作成されていることを確認します。その後、<INSTALL-DIR>/plugins/com.parasoft.ptest.libs.web_<VERSION>/root/tomcat/conf にある server.xml ファイルを修正します。
tomcat/conf/ ディレクトリにある web.xml ファイルに以下を追加します。
Code Block <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>
- サーバーを再起動します。
さらに詳しい説明については、Single Sign-On: Tomcat Negotiate Authenticator (Kerberos + NTLM) w/ Waffle のチュートリアルおよびWAFFLE の Web サイトを参照してください。
Anchor | ||||
---|---|---|---|---|
|
WAFFLE は Kerberos 認証もサポートしています。使用方法とサポート内容については、WAFFLE の Web サイトを参照してください。
JAAS でも、Kerberos 認証を実行するために Tomcat ベースの Virtualize サーバーを構成できます。JAAS の使用方法については、Tomcat を参照してください。