ワークベンチで使用する Java ランタイム環境 (JRE) で、選択したデジタル証明書で必要な暗号化のレベルがサポートされている必要があります。 例えば、 128 ビット暗号化しかサポートされない JRE では、256 ビット暗号化を必要とするデジタル証明書は使用できません。 デフォルトでは、ワークベンチは制限された強度の暗号で構成されます。 あまり制限が厳しくない暗号化アルゴリズムを使用するには、 無制限の管轄ポリシー・ファイル (local_policy.jar および US_export_policy.jar) をダウンロードして適用する必要があります。
無制限の管轄ポリシー・ファイルは、http://www.ibm.com/developerworks/java/jdk/security/50/ のサイトからダウンロードできます。
無制限の管轄ポリシー・ファイルを取得するには、「IBM SDK ポリシー・ファイル」をクリックし、developerWorks® にログインします。 これらのポリシー・ファイルをインストールする前に、 後で元ファイルを復元する場合のために、既存のポリシー・ファイルをバックアップします。 その後、/jre/lib/security/ ディレクトリー内のファイルを無制限の管轄ポリシー・ファイルで上書きします。
単純認証 (サーバー認証): この場合、テスト・クライアントは、サービスが信頼できるかどうかを判断する必要があります。 鍵ストアをセットアップする必要はありません。 「常に信用する」オプションを選択している場合、サーバー証明書の鍵ストアを提供する必要はありません。
サービスの認証を必要とする場合は、信頼されているサービスの証明書を含む、証明書トラストストアを構成できます。 この場合、テストでは有効な証明書の受信が想定されます。
二重認証 (クライアントおよびサーバー認証): この場合、サービスはルート権限に従ってテスト・クライアントを認証する必要があります。 認証済みクライアントとしてテストを認証するために作成する必要がある、クライアント証明書鍵ストアを用意する必要があります。
プロキシーを介してサービス・テストを記録する際、記録プロキシーはサービスとクライアント間に存在します。 この場合、記録プロキシーの SSL 設定を構成して、それ自体を、クライアントに対する実際のサービスとして認証し (単純認証)、さらにサービスに対するクライアントとして認証 (二重認証) する必要があります。 これは、適切な証明書で記録プロキシーを指定しなければならないことを意味します。
スタブ・サービスを使用する際には、スタブ・サービスの SSL 設定を構成して、それ自体を実際のサーバーとして認証することもできます。 これは、適切な証明書のサービス・スタブを指定 しなければならないことを意味します。
この製品は、Microsoft NT LAN Manager (NTLMv1 および NTLMv2) と Kerberos 認証をサポートしています。認証情報は、記録フェーズでテストの一部として記録されます。
NTLMv2 のサポートを有効にするには、サード・パーティーのライブラリーをワークベンチに追加する必要があります。詳しくは、『NTLMv2 認証のためのワークベンチの構成』を参照してください。
SSL および SOAP セキュリティー・プロトコルの両方について、デジタル証明書を使用してサービスをテストできます。 デジタル証明書は、ワークスペース内でアクセス可能な Java Key Store (JKS) キー・ストア・リソース内に含める必要があります。 鍵ストア・ファイルを扱うときは、セキュリティー・エディターとテスト・エディターの両方で、 鍵にアクセスする際に必要なパスワードを設定する必要があります。 SOAP セキュリティーの場合は、鍵の明示的な名前と、鍵ストア内の秘密鍵にアクセスするためのパスワードを指定 しなければならない場合があります。
配列はサポートされません。
仕様が存在しないため、Java Message Service (JMS) トランスポートでは、添付はサポートされません。 エンベロープは、UTF-8 エンコードを使用して直接送信されます。
すべての Java ランタイム環境 (JRE) 実装で、すべてのセキュリティー・アルゴリズムが常に使用可能というわけではありません。 特定のセキュリティー実装が使用できない場合、この製品で使用する JRE のクラスパスに、必要なライブラリーを追加します。
汎用サービス・テスターは、XML 文書内で反映されているようにエンベロープを表示します。 ただし、セキュリティー・アルゴリズムでは、エンベロープはバイナリーとして考慮されます。 したがって、着信メッセージと出力メッセージを正しく暗号化する一方で、テスト内では常に暗号化解除しておくよう、SOAP セキュリティー構成をセットアップする必要があります。
仮想ユーザーのパフォーマンスは、コンテナー・アプリケーションの実装に応じて異なります。 HTTP トランスポートの場合、Windows では最大 900 の同時仮想ユーザー、Linux では最大 600 の同時仮想ユーザーを使用して製品がテストされています。 JMS の場合、同時仮想ユーザーの最大数は 100 ですが、 この数値は、JMS が非同期で実装されているために変化する場合があります。 これらの値を超えると、接続エラーが発生することがあり、トランザクション速度が低下します。