You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

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

バージョン互換性についての注意事項

Virtualize または SOAtest 9.10.x 以降で記録された HTTP トラフィック ファイルは、9.9.x 以前のバージョンでは使用できません。 

このセクションの内容 

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

接続設定

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

プロキシ設定 (受信) 

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

リスナー

ドロップダウン メニューからプロキシ作成時に定義した HTTP リスナーを選択するか (「プロキシの作成」を参照)、デフォルトのリスナーを使用します。

このセクションで HTTP リスナーを追加できます:

  1. [新規] をクリックし、リスナーの名前を入力します。
  2. [ポートの追加] をクリックし、ポート番号を入力します。ポート番号として 0 を指定すると、メッセージ プロキシがポートを自動的に割り当てることができます。プロキシを有効にすると、割り当てられたポート番号がコンソールに表示されます。メッセージ プロキシが変更/有効化されるたびに、ポートがランダムに割り当てられます。GET リクエストを messageProxies API エンドポイントに送信して、自動的に割り当てられたポート番号を返すこともできます。詳細については「REST API によるテスト」を参照してください。  
  3. クライアントが SSL 経由でトラフィックを送信する場合、[セキュア] オプションをオンにして認証オプションを有効化します。詳細については「SSL Settings for Listener Ports」を参照してください。
  4. [OK] をクリックしてポート エディターを終了します。
  5. [追加] をクリックしてリスナーに別のポートを追加するか、[OK] をクリックしてリスナーの追加を終了します。
プロキシ リスン パス

プロキシが着信接続をリスンするべきパスを入力します。

2 つのメッセージプロキシが、同じプロキシパスまたは既存の仮想アセットの HTTP パスと一致するパスで HTTP 接続を持つことはできません。

詳細については「Service Forward Path and Proxy Listen Path」を参照してください。

プロキシ URL

テスト対象アプリケーション (AUT) に渡されるべき URL を表示します。詳細については「テスト対象アプリケーションをプロキシに向ける」を参照してください。

リスナー ポートの SSL 設定

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

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

キー ストア ファイルキー ストア ファイルへのパスを指定します。手動でパスを入力するか、ファイル システムまたはワークスペース内で参照します。
キー ストア パスワードキーストアにアクセスするためのパスワードを指定します。
キー ストア タイプ

ドロップダウン メニューからキーストア タイプを選択し、[ロード] をクリックします。

証明書[Certificate] ドロップダウン メニューからサーバーに提示する証明書のエイリアスを選択します。パスワードまたはキーストア タイプが誤っているなどの設定エラーがある場合、このメニューは空になります。

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

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

キー ストア ファイルキー ストア ファイルへのパスを指定します。手動でパスを入力するか、ファイル システムまたはワークスペース内で参照します。
キー ストア パスワードキーストアにアクセスするためのパスワードを指定します。
キー ストア タイプ

ドロップダウン メニューからキーストア タイプを選択し、[ロード] をクリックします。

プライマリ接続 (送信)

サービス URLターゲット アプリケーションの完全な URL が表示されます (サービス ホスト、サービス ポート、サービス転送パスを合成したものです)。ここで URL 全体を入力するか、または以下のフィールドで個々のコンポーネントを編集します。1 つのエリアで行われた変更は、他のエリアにも波及します (つまり、URL のポートを変更すると、サービス ポート フィールドの値も自動的に変更されます)。 
サービス ホスト

サービスが存在するマシンのホスト名を入力します。プロキシがメッセージを送信する先となるマシンです。

HTTP 接続を消費せずにローカル サーバーの仮想アセットに転送するには、実際のホスト名ではなく localhost または 127.0.0.1 を入力します。 

サービス ポートサービスがリスンしているポートを入力します。プロキシがメッセージを送信する先となるポートです。
サービス転送パス

(任意) プロキシが受信したメッセージを転送する先となるパスを入力します。このフィールドを空のままにすると、[プロキシ リスン パス] フィールドの値がデフォルト値となります。

HTTP プロキシが localhost に送信している場合、[サービス転送パス] を入力する必要があります。プロキシは自分自身への転送を許可していないからです。 

[サービス転送パス] がリダイレクトを送信する場合、プロキ シはリダイレクトを追跡し、応答します。クライアントにはリダイレクトを渡しません。

詳細については「Service Forward Path and Proxy Listen Path」を参照してください。

セカンダリ接続 (送信)

プライマリ接続が失敗する場合またはレスポンダーを利用できない場合に、セカンダリ プロキシ エンドポイントにトラフィックをリダイレクトしたい場合、[プライマリ接続が失敗した場合にセカンダリ接続を使用] オプションを有効にします。 し、レスポンスのステータス コードが 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 リスナー メッセージ プロキシのプロパティ

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 リスナー メッセージ プロキシのパフォーマンス プロパティ

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

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 プロパティ

embedded.ssl.includeProtocols

HTTPS 接続をサポートする SSL プロトコルのカンマ区切りのリストです。このオプションが指定されている場合、リストに挙げられているプロトコルだけが JVM の SSL 実装によってサポートされます。このオプションが指定されていない場合、JVM によって使用されるプロトコルがサポートされます (JVM がデフォルトで SSLv2 または SSLv3 の両方またはどちらかを有効にする場合、これらは除きます)

embedded.ssl.includeCipherSuites

HTTPS 接続をサポートする暗号化のカンマ区切りのリストです。JSSE の暗号化名前付け規約を使用して暗号化を指定します。このオプションが指定されている場合、リストに挙げられている暗号化だけが SSL 実装によってサポートされます。このオプションが指定されていない場合、セキュアとみなされないものを除いた JVM のデフォルトの暗号化スイートがサポートされます。結果として、古い JVM では、デフォルトでは非常に限られた数の暗号化だけしか利用できません。

embedded.ssl.useCipherSuitesOrder

true を指定すると、サーバーの (暗号化セットからの) 暗号化の順序を強制できます。false を指定すると、クライアントによって提示された最初の利用可能な暗号化が選択されます。この機能を使用するには、Java 8 以降が必要です。デフォルトは undefined であり、JSSE 実装で定義された順序になります。

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.useKeyManagerAlgorithmForTruststoretrue を指定すると、トラスト ストアのアルゴリズムとしてキー マネージャー アルゴリズムが使用されます。これは、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 でサーバーを右クリックし、すべての仮想アセットを再デプロイすると、環境でこのファイルが使用されるようになります。

ヘッダー ファイルの例

X-AUTHORIZATION ANOTHER-HEADER HEADER3

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

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

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

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

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

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

HTTP プロキシは仮想アセットと実サービスとを区別しません。両方とも同じ方法で構成されます。ただし、HTTP プロキシが localhost に送信している場合、[サービス転送パス] を入力する必要があります。プロキシは自分自身への転送を許可していないからです。

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

Vritualize デスクトップのサーバーを使用している場合、メッセージ プロキシのヘッダーは小文字で設定されるため、HTTP ヘッダー名の大文字/小文字を区別するサービスにリクエストを転送すると、処理が失敗する可能性があります。詳細については「Forwarding Requests to Services that Require Case-sensitive Header Names」を参照してください。


セキュリティ設定

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

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

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

プロキシ レベルの設定

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

SSL

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

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

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

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

オプション説明
サービス接続時に SSL を使用するSSL を有効にします。
すべてのサーバー証明書を信頼する

有効にすると、どんな証明書でも許可されます。証明書の検証はされません。

このオプションは、メッセージプロキシがサービスとの接続を確立するときの信頼性の検証を無効にします。サービスが提示するいかなる証明書でも接続は受け入れられます。一般的にこのオプションは、 がデプロイされている環境で証明書の信頼が焦点ではない場合に有効にします。

自己署名証明書を信頼する

有効にすると、検証メソッド java.security.cert.X509Certificate.checkValidity() が証明書に対して true を返す限り、その証明書は受け入れられます。この検証メソッドは、現在の日時が証明書の有効期限内であるかを効果的にチェックします。証明書のトラストパスは評価されず、トラストストアの構成は適用されません。

このオプションは、「サービスが提示する信頼された認証局によって署名されていない証明書」を信頼するかどうかを決定します。一般的にこのオプションは、SOAtest または Virtualizeがデプロイされている環境で証明書の信頼が焦点ではない場合に有効にします。

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

[Keystore] フィールド

オプション説明
キー ストア ファイルキー ストア ファイルへのパスを指定します。キーストアは、SSL ハンドシェイク中にメッセージ プロキシがサービスに提示する証明書とキーを指定します。
キー ストア パスワードキーストアにアクセスするためのパスワードを指定します。
キー ストア タイプキーストアにアクセスするためのパスワードを指定します。
証明書サーバーへ認証するときに使用する証明書のエイリアスを指定します。

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


[Truststore] フィールド

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

オプション説明
キー ストア ファイル

トラストストア ファイルへのパスを指定します。トラストストアは、メッセージ プロキシがサービスとハンドシェイクを行うときに信頼するべき証明書を指定します。サービスがこのトラスト ストアに含まれていない証明書を提示するとき、接続は拒否されます。トラスト ストアが提供されない場合は、デフォルトの JRE トラスト ストアが使用されます。 

このオプションは、 [すべてのサーバー証明書を信頼する] をオンにしていない場合に利用可能です。

キー ストア パスワードトラスト ストアに接続するためのパスワードを指定します。
キー ストア タイプトラスト ストアに接続するためのパスワードを指定します。


[NTLM 設定] フィールド

オプション説明
NTLM の使用サービスが NTLM 認証を必要とするかどうかを指定します。
ユーザー名NTLM 認証のユーザー名を指定します。
パスワードNTLM 認証のパスワードを指定します。


[Kerberos の設定] フィールド

オプション説明
Kerberos サービス プリンシパルリクエストを認証するためのサービス プリンシパルを指定します。

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

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

NTLM 認証

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


Kerberos 認証

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

サーバーレベルの設定

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

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 を参照してください。

  • No labels