このセクションでは、HTTP (HTTPS を含む) を介してメッセージを送信および受信するメッセージ プロキシの構成方法について説明します。
Note | ||
---|---|---|
| ||
Virtualize または SOAtest 9.10.x 以降で記録された HTTP トラフィック ファイルは、9.9.x 以前のバージョンでは使用できません。 |
このセクションの内容
Table of Contents | ||
---|---|---|
|
基本的な HTTP 接続オプションを設定するには、ターゲットとするサービスのホスト、ポート、およびパスが必要になります。サービスに直接通信するために通常使用する設定を使用してください。
接続設定
基本的な HTTP 接続オプションを指定するには、[プロキシ接続設定] タブで次のサービスおよびリスニング詳細を設定します。
プロキシ設定 (受信)
テスト対象アプリケーションと通信するために、クライアントからのメッセージが接続する場所を指定します。
Scroll Table Layout | ||
---|---|---|
|
リスナー | ドロップダウン メニューからプロキシ作成時に定義した HTTP リスナーを選択するか (「Creating Proxies」を参照)、デフォルトのリスナーを使用します。 このセクションで HTTP リスナーを追加できます:
|
---|---|
プロキシ リスン パス | プロキシが着信接続をリスンするべきパスを入力します。 2 つのメッセージプロキシが、同じプロキシパスまたは既存の仮想アセットの HTTP パスと一致するパスで HTTP 接続を持つことはできません。 詳細については「サービス転送パスとプロキシ リスン パス」を参照してください。 |
プロキシ URL | テスト対象アプリケーション (AUT) に渡されるべき URL を表示します。詳細については「Directing AUTs to Proxies」を参照してください。 |
Anchor | ||||
---|---|---|---|---|
|
サーバー サイド SSL を設定するには、[キーストアの使用] オプションをオンにします。
次のオプションを設定します。
Scroll Table Layout | ||
---|---|---|
|
キー ストア ファイル | キー ストア ファイルへのパスを指定します。手動でパスを入力するか、ファイル システムまたはワークスペース内で参照します。 |
---|---|
キー ストア パスワード | キーストアにアクセスするためのパスワードを指定します。 |
キー ストア タイプ | ドロップダウン メニューからキーストア タイプを選択し、[ロード] をクリックします。 |
証明書 | [Certificate] ドロップダウン メニューからサーバーに提示する証明書のエイリアスを選択します。パスワードまたはキーストア タイプが誤っているなどの設定エラーがある場合、このメニューは空になります。 |
クライアント サイド SSL を設定するには、[クライアント認証の実行] オプションをオンにします。
次のオプションを設定します。
Scroll Table Layout | ||
---|---|---|
|
キー ストア ファイル | キー ストア ファイルへのパスを指定します。手動でパスを入力するか、ファイル システムまたはワークスペース内で参照します。 |
---|---|
キー ストア パスワード | キーストアにアクセスするためのパスワードを指定します。 |
キー ストア タイプ | ドロップダウン メニューからキーストア タイプを選択し、[ロード] をクリックします。 |
プライマリ接続 (送信)
サービス URL | ターゲット アプリケーションの完全な URL が表示されます (サービス ホスト、サービス ポート、サービス転送パスを合成したものです)。ここで URL 全体を入力するか、または以下のフィールドで個々のコンポーネントを編集します。1 つのエリアで行われた変更は、他のエリアにも波及します (つまり、URL のポートを変更すると、サービス ポート フィールドの値も自動的に変更されます)。 |
---|---|
サービス ホスト | サービスが存在するマシンのホスト名を入力します。プロキシがメッセージを送信する先となるマシンです。 HTTP 接続を消費せずにローカル サーバーの仮想アセットに転送するには、実際のホスト名ではなく、 |
サービス ポート | サービスがリスンしているポートを入力します。プロキシがメッセージを送信する先となるポートです。 |
サービス転送パス | (任意) プロキシが受信したメッセージを転送する先となるパスを入力します。このフィールドを空のままにすると、[プロキシ リスン パス] フィールドの値がデフォルト値となります。 HTTP プロキシが localhost に送信している場合、[サービス転送パス] を入力する必要があります。プロキシは自分自身への転送を許可していないからです。 [サービス転送パス] がリダイレクトを送信する場合、プロキ シはリダイレクトを追跡し、応答します。クライアントにはリダイレクトを渡しません。 詳細については「サービス転送パスとプロキシ リスン パス」を参照してください。 |
セカンダリ接続 (送信)
プライマリ接続が失敗する場合またはレスポンダーを利用できない場合に、セカンダリ プロキシ エンドポイントにトラフィックをリダイレクトしたい場合、[プライマリ接続が失敗した場合にセカンダリ接続を使用] オプションを有効にします。 レスポンスのステータス コードが 400 レベル以上の場合、接続は " 失敗した" と見なされます。
たとえば、実エンドポイントが利用できない場合に仮想アセットを使用したいときなどにセカンダリ エンドポイントを指定します。仮想アセットが特定のユース ケースを処理しない場合は、セカンダリ エンドポイントを使用してトラフィックをライブ エンドポイントにリダイレクトし、ライブ トラフィックを記録して、そのユース ケースをカバーする新しい仮想アセットを作成することもできます。
このオプションが無効な場合、プライマリ接続が記録に使用されます。
このオプションが有効な場合、下記で説明する記録オプションを選択できます。
記録オプション
セカンダリ エンドポイントを指定する際にトラフィックの記録方法を決定します。
- 両方の接続を記録: プライマリ接続とセカンダリ接続の両方についてトラフィックを記録します。プライマリからのエラー メッセージは記録されません。その代わ り、エラー メッセージはセカンダリに送られ、レスポンスが記録されます。セカンダリがレポートするエラーは記録されます。
- プライマリ接続だけを記録: プライマリ接続のトラフィックを記録します。エラーは記録しません。
- セカンダリ接続だけを記録: セカンダリ接続のトラフィックを記録します。
エラーも記録します。
サービス SSL セクションは、対象のサービスが SSL を使用する場合にだけ設定する必要があります。
仮想化されるサービスおよび/またはテスト対象アプリケーション が 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 設定を指定できます。
- プレーン テキスト ファイルを作成し、設定するプロパティを指定します (「HTTP Listener Message Proxy Performance Properties」および「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.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 | コネクターが作成するリクエスト処理スレッドの最大数を指定します。このプロパティにより、同時に処理可能なリクエストの最大数が決まります。デフォルト値は |
---|---|
embedded.connector.minThreads | 常時実行するスレッドの最小数を指定します。デフォルト値は |
embedded.connector.acceptors | 接続を受け入れるのに使用するスレッドの数を指定します。CPU を複数搭載するマシンを使用する場合、または複数の非キープアライブ接続を使用する場合、この値を増やします。 |
embedded.connector.idleTimeout | コネクターが接続を閉じる前に他の HTTP リクエストを待機する時間をミリ秒単位で指定します。-1 を指定すると、接続は無期限に待機します。デフォルト値は connectTimeout を使用します。 |
embedded.connector.soLingerTime | コネクターによって使用されるソケットが接続を閉じる前に待機する時間をミリ秒単位で指定します。デフォルトでは、待機しません。 |
embedded.connector.acceptorPriorityDelta | 新規接続を受け入れるために使用するアクセプター スレッドの優先度を指定します。詳細については java.lang.Thread JavaDoc を参照してください。デフォルト値は 5 です。 |
embedded.connector.acceptQueueSize | すべてのリクエスト処理スレッドが使用中の時に、受信接続リクエストを入れるキューの最大の長さを指定します。キューが満杯のときに受信されたリクエストは拒否されます。デフォルト値は |
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 サーバーのホストとポートの情報を入力します。
たとえば、リモート サーバー上の仮想アセットにトラフィックを送信するには、次の設定を使用します。
- サービスホスト: virtualize.parasoft.com
- サービス ポート: 9080
- プロキシ リスン パス: /path
ローカル サーバー上の仮想アセットにトラフィックを送信するには、次の設定を使用します。
- サービスホスト: localhost
- サービス ポート: 9080
- サービス転送パス: /pva
HTTP プロキシは仮想アセットと実サービスとを区別しません。両方とも同じ方法で構成されます。ただし、HTTP プロキシが localhost に送信している場合、[サービス転送パス] を入力する必要があります。プロキシは自分自身への転送を許可していないからです。
Info | ||
---|---|---|
| ||
Vritualize デスクトップのサーバーを使用している場合、メッセージ プロキシのヘッダーは小文字で設定されるため、HTTP ヘッダー名の大文字/小文字を区別するサービスにリクエストを転送すると、処理が失敗する可能性があります。詳細については「Forwarding Requests to Services that Require Case-sensitive Header Names」を参照してください。 |
Anchor | ||||
---|---|---|---|---|
|
セキュリティの構成には 2 つの観点があります。
- トラフィック転送先のサービスが SSL および/またはアクセス制御を使用する場合、プロキシ レベルの構成 を実施する必要があります (プロキシの GUI 画面から実施)。
- テスト対象アプリケーションが SSL および/またはアクセス制御を使用する場合、サーバー レベルの構成 を実施する必要があります (Tomcat ベースの サーバーで実施)。
構成に応じて、セキュリティ設定かまたは両方を構成します。
プロキシ レベルの設定
プロキシ レベルのセキュリティ設定 (トラフィックの転送先のサービスが 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>/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 ファイルを修正します。
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 を参照してください。