このセクションでは、 選択した支援ツールやセットアップアクションツールでHTTP 1.0 を使用する際の構成オプションについて説明します。

セクションの内容:

HTTP 1.0 の設定

トランスポート プロトコルとして HTTP 1.0 を選択すると、クライアントのリクエストでキープアライブ接続 (NTLM および Digest HTTP 認証の場合に必要) を使用するかどうかを指定できます。また、接続は GUI またはコマンド ラインからの 1 つのテスト スイートの呼び出しで再利用されます。ツールの [トランスポート] タブから SOAP リクエストのカスタム HTTP ヘッダーを追加、変更、削除できます。

• 全般

• URL パラメーター （Messaging Client のみ)

• セキュリティ

• HTTP ヘッダー

• Cookie

全般

[全般] ページでは、次のオプションを設定できます。

• エンドポイント: サービスの任意のエンドポイント URL を指定します。 デフォルトでは、SOAP Client のエンドポイントは、WSDL に定義されたエンドポイントを使用する [WSDL] に設定されています。WSDL の他に以下の 3 つのオプションがあります。

• SOAP Action: サーバーがリクエストを処理する方法を指定します。[リクエストは WSDL に従う] チェックボックスがオンの場合、このフィールドは利用できません。このオプションは SOAP Client でだけ有効です。

• メソッド: リクエストを処理するメソッドを指定します。[リクエストは WSDL に従う] チェックボックスがオンの場合、このフィールドは利用できません。 呼び出すメソッドは、固定値、パラメータライズされた値、またはスクリプト値として指定できます。パラメータライズ値の詳細については、

  「テストのパラメータライズ (データ ソース、変数、または他のテストの値を使用)」および「データ ソース値、変数、および抽出した値でツールをパラメータライズ」を参照してください。

  固定値では、${var_name} という構文を使用してデータ ソースの値にアクセスできます。定義済みの環境変数を使用することもできます。環境の詳細については、「Virtualize 環境の構成」および「Virtualize 環境の構成」を参照してください。

  スクリプト値の詳細については、「Extensibility and Scripting Basics」を参照してください。

• メッセージ交換パターン: 同期レスポンスを期待する: レスポンス ボディを求めるかどうかを指定します。  HTTP レスポンス ヘッダーは常に求められます。  このオプションが選択されていない場合は、一方向のメッセージを送信し、通知ヘッダーを待機します ( 通常 "HTTP/1.0 202 Accepted")。
  
  

• 接続設定: 選択されたトランスポート プロトコルの接続をキープアライブするかクローズするかを指定します。
  • キープアライブ接続 : "Connection: Keep-Alive" ヘッダーを追加し、サーバーがサポートしていればキープアライブ接続を要求します。NTLM および Digest HTTP 認証では必須です。
  • 接続を閉じる (デフォルト): HTTP ヘッダーへの追加を行わず、通常の HTTP 1.0 の交換を実行します。HTTP 1.0 のデフォルトの動作です。

• リダイレクト設定 (REST、SOAP、Messaging、EDI Client など、メッセージング クライアントのみ): HTTP リダイレクトを自動的に追うかどうかを指定します。最後のリクエスト/レスポンスのペアだけでなく、オリジナルのリクエスト/レスポンス トラフィックに対してアクションまたは検証を実行したい場合は、このオプションを無効にしてください。
     
• 圧縮設定 (REST、SOAP、Messaging、EDI Client など、メッセージング クライアントのみ): リクエストを圧縮し、レスポンスを復元するかどうかを指定します。
  • Gzip リクエスト ペイロード:  ネットワーク経由で送信されるリクエスト ペイロードを gzip で圧縮します。連結されたツールに送信されるデータは、圧縮されません。添付ファイルを送信するよう設定された、または MTOM モードの SOAP Client には、圧縮は適用されないことに注意してください。
  • gzip エンコードされたレスポンス ペイロードの復元:  ヘッダーに "Content-Encoding: gzip" フィールドがあるレスポンス ペイロードを復元します。連結されたツールは、復元されたデータを受け取ります。

URL パラメーター 

[URL パラメーター] ページ では、次のオプションを設定できます。

• URL パラメーター: GET リクエストの URL にパラメーターを追加できます。[追加] ボタンをクリック後、ダイアログのパラメーター/値のペアを指定できます。データ ソースが使用可能である場合、値をパラメータライズできます。

セキュリティ

[セキュリティ] > [クライアントサイド SSL] ページでは、次のオプションを設定できます。

• クライアント キー ストアの使用: サーバーとのハンドシェイクを完了するために使用するキー ストアを指定します。

[セキュリティ] > [HTTP 認証] ページでは、次のオプションを設定できます。

• 認証の実行: basic、NTLM、Digest または Kerberos 認証を設定するには、[認証の実行] チェック ボックスをオンにし、[タイプ] ドロップダウンリストから Basic、NTLM、Kerberos、または Digest を選択します。
  
  • Basic、 NTLM または Digest を使用する場合は、リクエスト認証に必要なユーザー名とパスワードを入力します。
  • Kerberos を使用する場合は、リクエスト認証に必要な [サービス プリンシパル] を入力します。正しいユーザー名とパスワード、または正しいサービス プリンシパルが使用されていない場合、リスエストは認証されません。
• グローバル設定の使用: セキュリティ設定でグローバル HTTP 認証プロパティを設定している場合は、[グローバル設定の使用] を選択できます。  詳細については、「セキュリティの設定」を参照してください。

[セキュリティ] > [OAuth 認証] ページでは、次のオプションを設定できます。

• 認証の実行: このオプションをオンにすると、OAuth 認証を行う必要があることが示されます。OAuth 固有の情報を含む Authentication フィールドが HTTP ヘッダーに追加されます。
• コンシューマー キーおよびシークレットの設定: コンシューマー キーおよびコンシューマー シークレットは、クライアントがサーバーに対して自分自身を認証するために使用される情報です。コンシューマー キーは各クライアント固有です。すべてのステップでコンシューマー キーとコンシューマー シークレットの両方が必要です。
• OAuth 認証モード: OAuth シナリオのどのステップを実行するかを指定します。
  • リクエスト トークンの取得: コンシューマー キーおよびシークレットを使用してサーバーにリクエスト トークンを要求します。
  • スコープ: アクセスできる情報を制限します。この情報はコンシューマー キーに埋め込まれます。
  • リクエスト トークンとアクセス トークンの交換: リクエスト トークンおよび検証コードをアクセス トークンと交換します。
• リクエスト トークン: サーバーから取得された (アクセス トークンの交換で使用される) 一時的なリクエスト トークンの情報を指定します。
• リクエスト トークンのシークレット: サーバーから取得された (アクセス トークンの交換で使用される) 一時的なリクエスト トークンの情報を指定します。
• 検証コード: サーバーから提供される検証コードを指定します。リソースのオーナーが許可を与えることを確認します。
  • OAuth 認証のリクエストに署名: 指定されたアクセス トークンおよびアクセス トークン シークレットを使用し、ユーザーのプライベートなリソースへのアクセス権限をクライアントに与えます。
• OAuth パラメーター: OAuth トークンの付加的なパラメーターを指定できます。たとえば、タイムスタンプや nonce などです。

OAuth 認証の使用の詳細については、「Using OAuth Authentication」を参照してください。

HTTP ヘッダー

[HTTP ヘッダー] ページでは、次のオプションを設定できます。

• 追加: クリックするとカスタム HTTP ヘッダーを追加できます。ヘッダー名は、大文字と小文字を区別しません。
• 変更: クリックするとカスタム HTTP ヘッダーを変更できます。表示されたダイアログからヘッダーの名前および値を変更できます。ツールがデータソースを使用している場合、ヘッダーの値にデータ ソース (パラメータライズ) を設定できます。
• 削除: クリックするとカスタム HTTP ヘッダーを削除できます。

これらの設定項目は、ヘッダー フィールドを上書きするために使用されます。たとえば、これらのコントロールを介して、任意の名前および値で Content-Type ヘッダー フィールドを上書きできます。 

以下のデフォルトで設定されているヘッダー フィールドは、GUI コントロールを介して上書きできます。

ホスト

値には HTTP エンドポイントまたはリソース URL からのホスト名およびポート番号を含みます。

Content-Type

送信メッセージのメディア タイプを示します。このヘッダーは、送信メッセージが HTTP メソッドで制御されるボディを含む時のみ送信されます。  ボディは POST、PUT、および DELETE メソッドでは送信されますが、GET、OPTIONS、HEAD、および TRACE では送信されません。

デフォルト値は、送信されるメッセージのタイプに基づいて決定されます。SOAP メッセージの content-type SOAP バージョン (SOAP 1.1 の "text/xml" または SOAP 1.2 の "application/soap+xml") によって異なります。その他の XML メッセージは、デフォルトで "text/xml" を使用します。JSON メッセージは、"application/json" を使用します。テーブル ビューで構成したメッセージは、"application/x-www-form-urlencoded" を使用します。MIME アタッチメント付きのメッセージは、"multipart" content-type で "start" および "boundary" パラメーターを含みます。EDI、 Fixed Length、 CSV、またはカスタム メッセージ形式に属するメッセージは、そのメッセージ形式のメディア タイプを持ちます。

Content-Length

送信メッセージのサイズをバイト単位で表します。

以下の HTTP ヘッダーは、条件付きで設定されます。それらはテーブル外部で構成される場合や、動的に生成される必要がある値を持っています。

SOAPAction

この HTTP ヘッダーは、SOAP 1.1 使用時のみに送信されます。この設定は、[全般] ページの SOAPAction フィールドから行います。

Authorization

このヘッダーは、設定 ([セキュリティ] > [HTTP 認証および OAuth] ) で指定した HTTP 認証および OAuth 設定に基づいて、自動的に構成されます。NTLM、 Digest、および Kerberos 認証の値は、動的生成されたチャレンジ レスポンスやセキュリティ トークンを含む様々なファクターによって異なります。 

Connection

このヘッダーは、 [Keep-Alive 接続] が有効化されている場合、Keep-Alive の値がメッセージに追加されます。このヘッダーは、[接続を閉じる] (デフォルト設定値) が有効化されている場合は、送信されません。NTLM および Digest HTTP 認証には、Keep-Alive が有効化されている必要があります。

Proxy-Authorization

このヘッダーは、設定およびプロキシ認証が必要であることをサーバーが示しているかどうかに基づいて、プロキシ認証設定を構成します。

Cookie

[Cookie] ページでは、次のオプションを設定できます。

• リクエストを送信する前に、既存のクッキーをリセットする: 現在のクッキーをクリアできます。そのため、次の HTTP 呼び出しは新規セッションで開始します。

OAuth 認証の使用

Parasoft は Web サーバーフローおよびクライアント認証フロー (2 足のシナリオ) の両方をサポートしています。HTTP 1.0/HTTP 1.1 の両方で OAuth 認証を構成できます。

Rest Client の場合、[HTTP オプション] タブで構成できます。Messaging Client の場合は、[トランスポート] タブで構成します。

OAuth について

OAuth (Open Authorization) は、ユーザーがログイン情報を明かさずに第三者のアプリケーションにプライベートなリソースへのアクセスを許可する方法を提供する認証プロトコルです。また、アクセス可能な情報を限定することも可能にします。OAuth プロトコルは、ログイン情報が第三者に開示される問題に対処するために実装されました。

OAuth は従来のクライアント サーバー認証モデルに基づいていますが、ユーザー (リソース オーナーともいいます) という第 3 のロールが追加されています。従来のクライアント サーバー認証モデルでは、クライアントはサーバーに保管されたリソースに直接アクセスします。OAuth モデルでは、クライアントはサーバーのリソースにアクセスする前にリソース オーナーから許可を取得する必要があります。この許可は、トークンとそれに一致する共有シークレット キーで表されます。

たとえば、ユーザー (リソースーナー) が印刷サービス (クライアント) に写真共有サービス (サーバー) に保管されたプライベートな写真へのアクセスを許可するとします。ユーザーはログイン情報を印刷サービスに明かす代わりに、OAuth 認証を行って印刷サービスにプライベートな写真にアクセスする許可を与えることができます。 

認証は次の 3 段階で行われます。

1. 印刷サービスは写真共有サービスに一時的な認証情報を要求します。
2. 認証情報を取得したら、印刷サービスはユーザーを写真共有サービスの OAuth 認証 URL にリダイレクトし、ユーザーはログイン情報を入力します。印刷サービスはこの段階でユーザーのログイン情報を参照できないことに注意してください。ユーザーが印刷サービスにプライベートな写真へのアクセスを許可することを決定したら、検証コードが生成されます。
3. 印刷サービスは、一時的な認証情報と検証コードをアクセス トークンと交換します。アクセス トークンを取得したら、印刷サービスは写真共有サービスからユーザーのプライベートな写真を取得したり印刷したりできます。

OAuth 1.0a の使用

OAuth 1.0 の使用には、大きく分けると次の 3 つのステップがあります。

1. サービス プロバイダーからリクエスト トークンを取得し認証する
2. リクエスト トークンとアクセス トークンを交換する
3. AOuth リクエストに署名して保護されたリソースにアクセスする

次の例は、REST Client を使用してサーバーにリクエスト メッセージを送信します。Messaging Client も同じ方法で OAuth 1.0a を使用できることに注意してください。

サービス プロバイダーからリクエスト トークンを取得し認証する 

1. 新規 REST Client を作成し、リクエスト トークンを取得する場所を設定します。
2. [HTTP オプション] タブで [HTTP 1.0] または [HTTP 1.1] を選択し、[認証の実行] をオンにして OAuth 認証を有効にします。OAuth 認証の実行に必要な他のフィールドが有効になります。
3. [コンシューマー キー] および [コンシューマー シークレット] にキーおよびシークレットを追加します。
4. [OAuth モード] で [リクエスト トークンの取得] を選択します。
5. (任意) [スコープ] フィールドでスコープを指定します。
6. (任意) [OAuth パラメーター] にその他の OAuth パラメーターを追加します。
   
   
   
   
7. REST Client のレスポンス トラフィックに Text Data Bank を連結し、リクエスト トークン (通常は oauth_token) およびリクエスト トークンのシークレットを抽出します。
   
   
   
   
8. 新規 Web ブラウザー記録を作成します。[次から記録を開始] フィールドに検証コードを取得する URL を入力します (このステップは、ユーザーがサーバーにリダイレクトされ、ログイン情報を入力するステップに相当します)。URL には oauth_token パラメーターが含まれている必要があります。前のステップで抽出したリクエスト トークンの値を使用します。
   
   
   
   ブラウザーが起動すると、保護されたリソースが格納されているサーバーへのログイン ページが表示されます。 
9. ユーザーのログイン情報 (ユーザー名/パスワード) を入力してログインします。認証されると、検証コードが付加されたページにリダイレクトされます。
10. 検証コードを確認したら、ブラウザーを閉じて記録を終了します。
11. ブラウザー コンテンツ (描画された HTML) にBrowser Data Bank を連結し、検証コードの値を抽出します。
12. Browser Playback ツールを開き、リテラルなリクエスト トークン文字列を Text Data Bank によって (ステップ 7 で) 生成されたリクエスト トークンのデータ ソース列に置き換えます。次の図のように ${varName} という構文を使用します。
    
    

リクエスト トークンとアクセス トークンを交換する

1. 新規 REST Client を作成し、リクエスト トークンとアクセス トークンを交換する場所を設定します。
2. [HTTP オプション] タブで [HTTP 1.0] または [HTTP 1.1] を選択し、[認証の実行] をオンにして OAuth 認証を有効にします。OAuth 認証の実行に必要な他のフィールドが有効になります。
3. [コンシューマー キー] および [コンシューマー シークレット] にキーおよびシークレットを追加します。
4. [OAuth モード] で [リクエスト トークンとアクセス トークンの交換] を選択します。
5. [リクエストトークン] および [リクエスト トークンのシークレット] フィールドを Text Data Bank の抽出値によってパラメータライズします。
6. [検証コード] フィールドを Browser Data Bank によってパラメータライズします。
7. REST Client のレスポンス トラフィックに Text Data Bank を連結し、リクエスト トークン (通常は oauth_token) およびアクセス トークンのシークレットを抽出します。

AOuth リクエストに署名して保護されたリソースにアクセスする

1. 新規 REST Client を作成し、アクセス トークンを使用してプライベートなリソースにアクセスする場所を設定します。
2. [HTTP オプション] タブで [HTTP 1.0] または [HTTP 1.1] を選択し、[認証の実行] をオンにして OAuth 認証を有効にします。OAuth 認証の実行に必要な他のフィールドが有効になります。
3. [コンシューマー キー] および [コンシューマー シークレット] にキーおよびシークレットを追加します。
4. [OAuth モード] で [OAuth 認証のリクエストに署名] を選択します。
5. [アクセス トークン] および [アクセス トークンのシークレット] フィールドを Text Data Bank の抽出値によってパラメータライズします。
6. ユーザーのプライベートなリソースを要求します。アクセス トークンが取得されているため、アクセスが可能です。

OAuth 2.0 の使用

OAuth 2.0 は、前身の OAuth 1.0a に比べて大幅に簡略化されています。OAuth 2.0 は完全に新しいプロトコルであるため、OAuth 1.0a との後方互換性はありません。しかし、ログイン情報を開示せずに第三者のアプリケーションにプライベートなリソースへのアクセスを許可する方法をユーザーに提供するための全体的なアーキテクチャやアプローチは共通しています。

OAuth 2.0 で導入された変更の詳細については、 http://tools.ietf.org/html/draft-ietf-oauth-v2-20 のド ラフトを参照してください。

OAuth 2.0 の使用には、大きく分けると次の 3 つのステップがあります。

1. 認証を要求する
2. アクセストークンを取得する
3. 保護されたリソースにアクセスする

次の例は、REST Client を使用してサーバーにリクエスト メッセージを送信します。Messaging Client も同じ方法で OAuth 2.0 を使用できることに注意してください。

認証を要求する 

1. Web ブラウザー記録を作成し、[次から記録を開始] フィールドに URL を入力して OAuth パラメーターを指定します。認証が完了すると、サービス プロバイダーによって URL パラメーターの一部としてコードが含まれたコールバック URL にリダイレクトされます。
2. ブラウザーを閉じて記録を終了します。
3. リクエスト -> Validate Header に Text Data Bank を連結してコードを抽出します。HTTP トラフィックからブラウザー データを選択し、コードを含むリダイレクトされた URL を選択します。
   
   
   
   
   
   

アクセストークンを取得する 

1. 新規 REST Client を作成し、必要なパラメーターを含む URL を指定します。URL パラメーターには code というパラメーターが含まれていなければなりません。このパラメーターの値を前のステップで抽出した Text Data Bank の値でパラメータライズします。
   
   
   
   
2. レスポンスのフォーマットに合ったデータ バンク (Text、JSON など) をREST Client に連結し、アクセス トークンを抽出します。

保護されたリソースにアクセスする

1. REST API の呼び出しごとに新規 REST Client を作成し、必要なパラメーターを含む URL を指定します。URL パラメーターには oauth_token というパラメーターが含まれていなければなりません。このパラメーターの値は前のステップで抽出したアクセストークンの値です。