Route via HTTP(S) アサーション

Route via HTTP(S) アサーション は、Web サービスまたは XML アプリケーション メッセージの送信先、および使用される認証情報を定義します。 サービスがクライアント認証を要求する場合は、Gateway の応答方法を任意の数だけ設定できます。
gateway94
Route via HTTP(S)
アサーション は、Web サービスまたは XML アプリケーション メッセージの送信先、および使用される認証情報を定義します。 サービスがクライアント認証を要求する場合は、Gateway の応答方法を任意の数だけ設定できます。
  • デフォルトでは、SSL-TLS ハンドシェイクに応答するためにデフォルト SSL からのサブジェクト証明書が使用されます。
  • 使用するカスタム秘密鍵を指定できます。 Gateway は、サーバからの送信 TLS クライアント証明書チャレンジに応答するために、この秘密鍵からのサブジェクト証明書を使用します。
  • このアサーションで秘密鍵を選択するときに[Use no private key]オプションを選択することにより、すべての証明書チャレンジを拒否するように Gateway を設定できます。
    ヒント:
    このオプションは Route via HTTP(S) アサーション固有のものです。
このアサーションに対する秘密鍵の選択の詳細については、「カスタム秘密鍵の選択」を参照してください。
2
メッセージルーティング アサーションは重要なポリシー要素です。 Publish Web API ウィザード(ターゲット URL を指定)を使用してサービスを公開する場合、Policy Manager は、公開プロセス中に指定されたサービス URL を、公開されたサービスの初期ポリシーに Route via HTTP(S) アサーションとして自動的に追加します。
(1)デフォルトでは、送信 HTTP メソッドは受信リクエスト HTTP メソッドからそのまま渡されます。 受信リクエストメソッドがない場合(たとえば、コンテキスト変数が使用されている場合)は、POST アクションが使用されます。 (2) Gateway は、送信 TLS 接続用のクライアント証明書として楕円曲線証明書(ECC)の使用をサポートしません。
Route via HTTP(S) アサーション は HTTP 1.0 および 1.1 標準をサポートします。 このアサーションは、外部 REST API または HTTP-SOAP ベースの API を利用するポリシー内に存在する必要があります。
バックエンドシステムへのルーティングの障害が発生する場合は、ポリシー アサーションおよびロジック(監査ログ、syslog、SMTP、SNMP、JMS、AMQP など)を使用して、これらの障害イベントをキャプチャすることをお勧めします。このイベント処理は、バックエンド サービスから障害をキャプチャし、Gateway がバックエンド サービスが利用できないクライアントに、インテリジェントなレスポンスを返せるようにします。 Gateway ユーザは、監査およびサービス停止の問題切り分けセッション中に、バックエンド サービスに対して特定の障害の詳細な情報を提供することができます。
アサーションの使用
デフォルトでは、Policy Manager は、いずれかのサービス公開ウィザードによって作成された新しいサービス ポリシーに、Route via HTTP(S) アサーションを自動的に追加します。 アサーションが削除されたか、さらに追加する必要がある場合のこのアサーションの追加方法については、「アサーションの追加」を参照してください。
  1. ポリシー ウィンドウで[
    Route via HTTP(S) to...
    ]を右クリックして[
    HTTP(S) Routing Properties
    ]を選択するか、ポリシー ウィンドウでアサーションをダブルクリックします。 このアサーションのプロパティが表示されます。
  2. URL
    ]ボックス内のアドレスを確認して、これがサービスの正しい URL であることを確認します。必要に応じて変更を加えます。 Policy Manager は、URL の形式が正しく、ホスト名が DNS で有効であることを確認します。
    WSDL から公開された SOAP サービスについては、 Reset.png をクリックして、URL をサービス公開プロセス中に指定されたものにリセットできます。
    URL に含まれたホストが有効であるがパスが無効な場合、ルーティングの試行がサービス統計でポリシー違反(Policy Violation)として記録されます。 ただし、ホストが不明な場合、ルーティングの試行はルーティング失敗(Routing Failures)として記録されます。 サービス統計の詳細については、「Gateway のダッシュボード」の「ダッシュボード - [Service Metrics]」を参照してください。
    パスの指定ついて高い柔軟性を得るために、URL 内にコンテキスト変数を埋め込むことができます。 コンテキスト変数が、有効な URL に解決されることを確認してください。
  3. HTTP Method
    ]で、使用する HTTP メソッドをドロップダウン リストから選択します。 リストには既知のメソッドが含まれています。しかし、必要な場合、ユーザ独自のメソッド(コンテキスト変数の指定を含む)を入力できます。 デフォルト設定の[
    <Automatic>
    ]は、リクエストの HTTP メソッド(存在する場合)を使用します。存在しない場合は POST メソッドを使用します。
    カスタム HTTP メソッドがルーティング対象メッセージ内に存在する場合、それがそのまま渡されます。 HTTP メソッドの詳細については、公開サービスのプロパティの[HTTP/FTP]タブを参照してください。
  4. Request Source
    ]で、ドロップダウン リストからリクエスト ソースを選択します。 これは、送信要求として送信されるメッセージです。 通常はデフォルトの要求メッセージですが、現在のコンテキストで定義されているメッセージ コンテキスト変数を選択することができます。
  5. Response Destination
    ]で、応答の送信先を指定します。 これは、サーバから返されたレスポンスを保存する場所です。 通常はデフォルトの応答メッセージですが、デスティネーションをドロップダウン リストから選択するか、応答を保持する新しいメッセージ コンテキスト変数を入力できます。
    デフォルトの変数名「httpResponse」は、候補に過ぎません。これを使用する場合は、この名前が一意であることを確認してください。 構文エラーを受信する場合は、コンテキスト変数命名規則を参照してください。
    ルート レスポンスをメッセージ コンテキスト変数に保存する場合、レスポンス本文およびヘッダはデフォルトのレスポンスではなく変数に保存されます。 クライアントに返される応答はメッセージ変数ではなくデフォルトの応答です。 ルーティング ヘッダ ルールは、クライアントに返されたヘッダではなく、この場合メッセージ変数に保存されたヘッダに影響します。
  6. 必要に応じて各タブを設定します。 各タブの詳細な説明については、以下の該当するセクションを参照してください。
  7. 完了したら、[
    OK
    ]をクリックします。
[Authentication]タブの設定
[Authentication]タブでは、認証方式を選択します。
Authentication
説明
None (Anonymous)
匿名サービスには、このオプションを選択します。 認証情報は必要ありません。
Use OAuth Authorization
OAuth 許可を認証情報に使用するには、このオプションを選択します。
OAuth バージョン
(OAuth Version)を選択して、
トークン変数
(Token Variable)を指定します。
OAuth バージョンにより、Authorization ヘッダ値内のトークン変数の内容の先頭に何が付加されるかが決まります。
  • OAuth 1.0 の場合、これは、値「OAuth ${var}」を持つ Authorization ヘッダの追加と同等です。
  • それ以外の場合、これは、値「Bearer ${var}」を持つ Authorization ヘッダの追加と同等です。
OAuth トークンがすでに取得されており指定されたコンテキスト変数に存在することを確認してください。
Specify HTTP Credentials
基本 HTTP 認証には、このオプションを選択します。
ユーザ名
パスワード
NTLM ドメイン
および
NTLM ホスト
を入力するように求められます。
[User Name]および[Password]フィールドでは、コンテキスト変数を指定できます。
(1)認証情報が入力されていない場合、次回[Authentication]タブが開かれる時に、認証オプションは[None (Anonymous)]に戻ります。 (2)プロキシ サーバが設定されている場合、NTLM 認証はサポートされません(「proxy_tab」を参照)。 (3) NTLM v1 および v2 の両方の認証がサポートされています。
Use HTTP Credentials from Request
リクエスト内で HTTP 基本または NTLM 認証ヘッダを使用するには、このオプションを選択します。
技術注記:
このオプションを選択した場合、
com.l7tech.server.policy.assertion.ServerHttpRoutingAssertion.statePool.enable
システム プロパティが無効になります。
Attach SAML Sender-Vouches
SAML sender-vouches チケットを Gateway によって認証された各送信バックエンド リクエストに添付するには、このオプションを選択します。 このチケットには、認証されたユーザのユーザ名と共に有効期限が含まれており、SSL 証明書を使用して Gateway によって署名されています。
SAML バージョン
および分単位の
チケット有効期限
(整数のみ)を指定するように求められます。
[Attach SAML Sender-Vouches]オプションは SOAP Web サービス ポリシーに対してのみ有効化されます。 これは、以下のように Require SAML Token Profile アサーションとは異なります。
  • Attach SAML Sender-Vouches
    ]オプションは、Gateway から保護されているサービスへの送信メッセージに追加されています。
  • Require SAML Token Profile アサーション
    は、SAML セキュリティがクライアント アプリケーションから Gateway への受信メッセージ内にすでに存在していることを必要とします。
Send TAI Header
Trust Association Interceptor (TAI)サードパーティ認証パスを必要とするには、このオプションを選択します。 TAI 認証情報チェーンは、静的なユーザ名およびパスワードと共に、またはなしで使用できます。 TAI を使用すると、Gateway がユーザを認証した場合に、その認証されたユーザのユーザ名は送信リクエストの IV_USER HTTP ヘッダに含まれます。
Use Windows Integrated
統合 Windows 認証を介した送信 Kerberos 委任を有効にするには、このオプションを選択します。 処理方法を指定します。
  • Use Delegated Credentials:
    ルーティングのサービス チケットをリクエストするためにリクエスト Kerberos トークンから抽出された認証情報を使用するには、このオプションを選択します。 このオプションを使用する場合は、以下のいずれかのアサーションがポリシー内にある必要があります。Require Windows Integrated Authentication Credentials または Require WS-Security Kerberos Token Profile Credentials。
  • Use Gateway Keytab:
    Gateway で
    kerberos.keytab
    ファイルを使用するには、このオプションを選択します。
  • Use Configured Credentials:
    アサーションが指定されたアカウントを KDC を使用して認証し、ルーティング用のサービス チケットを取得するようにするには、このオプションを選択します。
(1) [Use Gateway Keytab]および[Use Configured Credentials]オプションは、Kerberos アクセス制御を必要としません(言いかえれば、Require Windows Integrated Authentication Credentials または WSS Kerberos アサーションは必要ではありません)。 Require HTTP Basic Credential アサーションの使用で十分です。 (2)プロキシ サーバが設定されている場合、Kerberos 認証はサポートされません(「proxy_tab」を参照)。
[Headers]タブの設定
[Header]タブは、パス スルーされる HTTP ヘッダを定義するために使用されます。 このタブには、リクエストおよび応答のヘッダに対する個別のセクションが含まれています。
デフォルトでは、すべてのリクエストおよび応答ヘッダはそれらの元の形式でパス スルーされます。
警告:
すべてのアプリケーション ヘッダがパス スルーされることを許可すると、セキュリティに悪影響が生じる可能性があります。 疑いがある場合は、特定のヘッダのみにパス スルーを制限します。
特定のヘッダのみをパス スルーする場合は、対応するテーブルでこれらのヘッダを定義します。 ヘッダの元の値またはカスタム値を渡すことを選択できます(コンテキスト変数使用可能)。
パス スルーするヘッダのリストを作成するためのいくつかのヒントを示します。
  • 特定のヘッダの処理に関する複数のルールを構築する場合、ヘッダ名を繰り返すことが可能です。 詳細については、以下の「複数ヘッダの使用」を参照してください。
  • 元の値を渡す場合、そのヘッダが受信リクエストに複数回存在する場合、それは元のリクエストに存在するとおりに、複数回渡されます。
  • 特定のリクエストまたは応答ヘッダをのみをパス スルーする場合、対応するテーブルでヘッダが何も指定されていない場合は、Gateway はすべてのヘッダのパス スルーに戻ります。
Gateway は、定義されているパススルー ルールに関係なく、デフォルトではこれらのヘッダを渡し
ません
connection
content-encoding
content-length
content-type
datehost
keep-alive
server
transfer-encoding
技術注記:
上記の除外されたヘッダのいずれかをパススルーするには、スキップするヘッダのリストを含むシステム プロパティ
com.l7tech.policy.assertion.HttpPassthroughRuleSet.headersToSkip
を追加します。 詳細については、「Gateway クラスタ プロパティ」を参照してください。
ヘッダのオーバーライド
Route via HTTP(S) アサーションと Manage Transport Properties/Headers アサーション間のインタラクションに注意してください。 どちらのアサーションがポリシーで後に出現するかによって、ヘッダのカスタマイズがオーバーライドされる場合があります。
Manage Transport Properties/Headers アサーションは、メッセージ内のカスタム HTTP ヘッダを操作するのに役立ちます(特に、Route via HTTP(S) アサーションでオーバーライドできないヘッダーの場合)。
例:
複数の異なる言語をホストしている場合は、Route via HTTP(S) アサーションの直後に Manage Transport Properties/Headers アサーションを使用して、適切な
文字セット
を設定できます。 以下のパラメータを使用します。
  • Type:
    HTTP Header
  • Operation:
    Add or Replace
  • Property/Header Name:
    Content-Type
  • Property/Header Value:
    text/html; charset=shift_jis
日本語を「euc-jp」でエンコーディングする必要がある場合、上記設定を
charset=euc-jp
にして使用します。
複数ヘッダの使用
特定のヘッダの処理方法を示すために複数のルールの作成が必要な場合があります。 たとえば、特定のリクエストまたは応答ヘッダの複数のカスタム値を転送したい場合があります。
以下の表では、一部のヘッダのみをパス スルーしている場合に考えられるシナリオの概要について説明します。
シナリオ
結果
値 =<オリジナル値> を持つヘッダ「ABC」を定義する
名前が「ABC」のすべてのヘッダは、それらの元の値が変更されずに転送されます。
値 = "XYZ" を持つヘッダ「ABC」を定義する
値 "XYZ" を持つ、名前が「ABC」の新しいヘッダが挿入されます。
ヘッダ "ABC" = "123" および "ABC" = '456' を定義する。
名前が「ABC」の 2 つのヘッダが挿入されます。1 つは値 "123" を持ち、もう 1 つは値 "456" を持ちます。
ヘッダ "ABC" = <オリジナル値> および "ABC" = "123" を定義する。
名前が「ABC」のすべてのヘッダは、それらの元の値が変更されずに転送されます。 カスタム値「123」を持つ追加のヘッダが挿入されます。
HTTP Host ヘッダの使用
HTTP Host ヘッダは多くの異なる方法で設定が可能です。 デフォルトでは、このヘッダは、プロパティ ダイアログ ボックスの一番上で指定された URL ホスト名に設定されます。 以下の手順に従うことにより Host ヘッダ の柔軟性を強化できます。
  1. 特定のリクエスト ヘッダのみをパス スルーしていることを確認します。
  2. 名前が「
    Host
    」の新しいリクエスト ヘッダを追加します。
  3. [Customize value]を選択し、Host ヘッダに値を入力する方法に応じて、以下のいずれかを選択します。
    • leave the value blank:
      HTTP リクエスト内の HOST ヘッダにはターゲット URL のホスト名が入力されます。
    • enter a context variable:
      HTTP リクエスト内の HOST ヘッダにはコンテキスト変数に含まれている値が入力されます。
    • any other non-blank value:
      HTTP リクエスト内の HOST ヘッダにはここに入力された値が入力されます。
[Connection]タブの設定
[Connection]タブはフェールオーバ ストラテジ、タイムアウトおよび TLS 設定を設定するために使用されます。 デフォルト設定は、ほとんどのインスタンスで動作する出発点を提供します。 ただし、デフォルトは控えめに設定されており、設定されたバックエンド サービスの可用性に応じて、クライアントに対する応答が遅くなったり断続的になったりする可能性があります。 応答性の改善については、以下の拡張設定を検討してください。
  1. IP アドレスを取得する方法を指定します。
    IP アドレス オプション
    説明
    Look Up IP Addresses in DNS
    Gateway が Domain Name Server (DNS)から IP アドレスを取得するようにするには、このオプションを選択します。 この設定はデフォルトです。また、フェールオーバ ストラテジを使用しません。
    Use the following IP addresses
    Gateway が後に続くリスト内の IP アドレスのみを使用するようにするには、このオプションを選択します。
    Use multiple URLs
    Gateway が後に続くリスト内の URL を順次使用するようにするには、このオプションを選択します。 たとえば、複数インスタンスのサービスが、別の IP アドレスではなく別の URL に存在する場合、このオプションが役立ちます。
    このオプションを使用して URL のリストを作成する場合、コンテキスト変数を指定できます。
  2. IP アドレスまたは URL が応答に失敗した場合に備えて、[
    Failover strategy
    ]で、使用するフェイルオーバ ストラテジを選択します。
    フェールオーバ ストラテジ
    説明
    Ordered Sticky with Failover
    Gateway は、IP/URL が応答しなくなる(失敗する)まで、リスト内の最初の IP/URL にサービス メッセージを送信します。 応答しなくなる(失敗する)と、リスト内の次の IP/URL が使用されます。
    クラスタ プロパティ
    io
    .failoverServerRetryDelay
    は、Gateway が失敗したサーバを再試行するまでの遅延を制御します。 「Ordered Sticky with Failover」ストラテジを使用する場合のデフォルトは、15 分間待機することです。
    Random Sticky with Failover
    Gateway は、各セッションの初めに IP/URL をランダムに選択し、それをセッションの間に使用します。 選択された IP/URL が失敗した場合、別の IP/URL がランダムに選択されます。
    Round Robin
    Gateway は、リストの先頭からはじめて、次は 2 番目というように、リクエストごとに IP/URL リスト全体を順番に使用します(ラウンド ロビン)。 リストの末尾に達すると、リストの先頭からサイクルが続行されます。
    クラスタ プロパティ
    io
    .failoverServerRetryDelay
    は、Gateway が失敗したサーバを再試行するまでの遅延を制御します。 「Round-Robin」ストラテジを使用する場合のデフォルトは、5 分間待機することです。
  3. このルーティング アサーションのみに対して以下のいずれかのタイムアウト値をオーバーライドすることができます。
    • [Connection Timeout]
      では、Gateway が TCP 接続の確立を試行する最大時間(ミリ秒単位)を定義します。 超過した場合、ルーティングは失敗します(またはフェールオーバします)。 システム デフォルトをオーバーライドするには、[
      Use System Default
      ]チェック ボックスをオフにして別の値を入力します。 コンテキスト変数を参照することもできます。
      このタイムアウトのシステム デフォルトは
      io.outConnectTimeout
      クラスタ プロパティによって定義されます。このプロパティが明示的に設定されていない場合、デフォルトで 30 秒になります。
      バックエンド サービスの距離または遅延に比例して接続タイムアウトを設定します。 同じ物理サーバまたはラック上のバックエンド サービスの場合、接続タイムアウトをそのサービスの遅延よりも数ミリ秒大きく設定します。 たとえば、バックエンドサービスに 10 ミリ秒の遅延がある場合、接続タイムアウトを約 20 ミリ秒とします。 バックエンド サービスが海外または別の大陸にある場合、接続タイムアウトを大きくします。 これは、大規模な物理的距離に伴うサービスへのネットワーク遅延の変動を考慮するためです。 たとえば、バックエンド サービスに 200 ミリ秒の遅延がある場合、接続タイムアウトを約 300 ミリ秒とします。
    • Read Timeout
      は応答データ(完全な応答とは限らない)が送信リクエストに対して読み取られることが許可されている最大時間(ミリ秒単位)を定義します。 超過した場合、ルーティングは失敗します(またはフェールオーバします)。 システム デフォルトをオーバーライドするには、[
      Use System Default
      ]チェック ボックスをオフにして値を入力します。 コンテキスト変数を参照することもできます。
      このタイムアウトのシステム デフォルトは
      io.outTimeout
      クラスタ プロパティによって定義されます。このプロパティが明示的に設定されていない場合、デフォルトで 60 秒になります。
      注:
      Read Timeout は、バックエンド サーバからの通信があるたびにトリガされます。 そのため、実際の通信時間は「Read Timeout」に設定されている値よりも長くなる可能性があります。
      読み取りタイムアウトは、サービスに定義されている SLA を超えないようにする必要があります。 SLA が定義されていない場合は作成し、クライアントに通知する必要があります。 クライアントが Gateway からの応答を 2000ms 以内だと予想している場合、読み取りタイムアウトは約 1500ms にします。 サービスの SLA を超えてはいけません。超えてしまうと、バックエンド サービスが利用できない場合に、Gateway は潜在的に SLA を満たすことができない可能性があります。
    • Maximum Retries
      ]では、初期試行とは別に、TCP 接続を確立するための試行の最大数を定義します。 たとえば、Maximum Retries = 3 は、4 回の試行、つまり初期試行と 3 回の再試行があるということを意味します。 システム デフォルトをオーバーライドするには、[
      Use System Default
      ]チェック ボックスをオフにし、次に、
      0
      から
      100
      の間の値を入力します(0 は再試行を行いません)。 デフォルトは
      3
      回です。
      最高のパフォーマンスを得るには、再試行の最大数を 0 に設定し、再試行を失くします。 障害に対応するためのインテリジェンスとロジックはクライアントで処理され、Gateway は「fail fast」モデルに従う必要があります。 クライアントに組み込みの再試行ロジックがない場合は、HTTP GET メソッドに対してのみ、1 回の再試行を有効にします。
  4. TLS Version
    ]で、HTTPS を介して接続する場合に許可する TLS バージョンを選択します。
    技術注記
    : 「TLS 1.0 with SSLv2Hello」を選択した場合、SSL-J が使用可能でも、Gateway は送信接続の TLS 実装として SunJSSE を使用します。 これは、SSL-J が SSLv2Hello をサポートしていないためです。
  5. 特定のセットの TLS 暗号スイートをこの HTTP 接続に使用するには、[
    Cipher Suites
    ]をクリックします。 詳細については、「暗号化スイートの選択」を参照してください。
  6. 送信 TLS ハンドシェイク中に信頼できる証明書のサブセットを許可するには、[
    Trusted Server Certificates
    ]をクリックし、次のいずれかを選択します。
    • Trust all Trusted Certificate:
      Gateway トラスト ストア内の信頼できる証明書をすべて信頼します。 詳細については、「証明書の管理」を参照してください。
    • Trust only the specified Trusted Certificates:
      下のテーブル内の信頼できる証明書のみを信頼します。 ここで定義する証明書のみがこのルーティング アサーションからの送信 TLS ハンドシェイク中に信頼されます。
    すべての信頼できる証明書と同様に、このリスト内の証明書は、設定に共通性のある場合にのみ信頼されます(たとえば、「送信 SSL に対して信頼される」ように設定されている場合)。
[HTTP]タブの設定
[HTTP]タブは、HTTP プロトコルの設定を詳細に調整するために使用されます。
  1. ドロップダウン リストから[
    Version
    ]を選択します。
    デフォルト
    設定では、
    io.httpVersion
    クラスタ プロパティ(工場出荷時の設定はバージョン 1.1)によって定義されたバージョンが使用されます。 クラスタ プロパティをオーバーライドする必要がある場合は、別のバージョンを選択します。
  2. リクエスト ペイロードを圧縮する場合は、[
    Compress Output
    ]チェック ボックスをオンにします。 特にペイロードが大きい場合、これによりパフォーマンスおよび転送時間を改善できます。
    サービス エンドポイントが Content-Encoding: gzip を使用して、HTTP レベルの圧縮をサポートしている場合にのみ、圧縮オプションが有効です。
  3. 永続的な接続を使用するには、[
    Use Keep-Alive
    ]チェック ボックスをオンにします。 これらの接続は複数のメッセージに対して TCP 接続の再利用を可能にするため、より効率的です。 このルーティングで永続的な接続を使用しないようにするには、このチェック ボックスをオフにします。
    「キープ アライブ」は、
    io.httpDisableKeepAlive
    クラスタ プロパティがデフォルトの「false」に設定されている場合のみ有効にできます。 このプロパティが「true」に設定された場合、「キープ アライブ」はグローバルに無効化され、個別の HTTP ルーティングに対して有効できません。
  4. ダウンストリーム ターゲットからの HTTP リダイレクト応答に従うようにアサーションに指示するには、[
    Follow Redirects
    ]チェック ボックスをオンにします。 オンにしない場合、リダイレクト応答はリクエスタに戻されます。
  5. HTTP リクエスト メソッドが通常は本文を含まないものである場合でも(例:GET、HEAD、DELETE、または OPTIONS)送信リクエストにリクエスト本文を含めるには、[
    Transmit body regardless of request method
    ]チェック ボックスをオンにします。
    リダイレクトは、リクエスト本文が強制的に含まれている場合はリクエストに対して無効化されます。これは、リクエスト メソッド(GET など)がほかの方法でリダイレクトに従った場合でも該当します。
    リクエスト本文を送信リクエストに強制的に含めないようにするには、このチェック ボックスをオフにします。 この場合、リクエスト本文は、通常リクエスト本文を含める HTTP リクエスト(POST、PUT など)のみに含まれます。
  6. ルーティングする前にリクエスト メッセージ内の Content-Type を変更またはオーバーライドするには、
    [Do not automatically include Content-Type header in request]
    チェック ボックスをオンにします。 リクエスト メッセージ内の既存の Content-Type を使用するには、このオプションをオフのままにします。
    Content-Type をオーバーライドする場合、ポリシーに Manage Transport Properties/Headers アサーションも存在することを確認します。 このアサーションは、ヘッダの完全な制御を提供するために Route via HTTP(S) アサーションと連携して動作します。 ルーティング中に Content-Type ヘッダを操作する方法の詳細については、下記の「Content-Type ヘッダの操作」を参照してください。
  7. (9.3 CR2 以上で使用可能)
    リクエスト メッセージから Host ヘッダを除外する必要がある場合、[
    Omit Host header (for HTTP/1.0)
    ]チェック ボックスをオンにします。 それ以外の場合、Host ヘッダが含まれます。 この設定は、HTTP 1.0 に対してのみ有効であることに注意してください。 この設定は、[HTTP Version]が
    [Default]
    または
    [1.1]
    の場合は使用できません (
    io.httpVersion
    クラスタ プロパティのデフォルト HTTP バージョンが変更されている場合を除く)。
  8. POST からのリクエスト パラメータの動作を変更する必要がある場合は、
    [Customize Request Form POST Parameters]
    をクリックします。 以下が可能です。
    • リクエストから受信したすべての POST からのリクエスト パラメータがパス スルーされるか、特定のパラメータのみがパス スルーされるかを指定します。
    • パス スルーへする特定のパラメータのリストを定義します。
      (1) 特定のパラメータの処理に関する複数のルールを作成している場合、パラメータ名を繰り返すことが可能です。 詳細については、このトピックの前述した「multiple_headers」を参照してください。 (2)パラメータが受信リクエストに複数回存在する場合、それは元のリクエストに存在するとおりに、複数回渡されます。
Content-Type ヘッダの操作
Manage Transport Properties/Headers アサーションを Route via HTTP(S) アサーションと共に使用することで、ルーティング中に Content-Type ヘッダを制御できます。
例 1: ルーティング前にリクエストから Content-Type ヘッダを削除する
  1. ポリシーに Route via HTTP(S) アサーションを追加して、
    [Do not automatically include Content-Type header in request]
    を選択します。
  2. Route via HTTP(S) アサーションの前に Manage Transport Properties/Headers アサーションを追加して、ターゲット メッセージを[Request]に設定します。 以下のようにプロパティを設定します。
    • Type:
      HTTP Header
    • Operation:
      Remove
    • Property/Header Name:
      Content-Type
レスポンスには、応答メッセージの本文に Content-Type ヘッダが含まれません。
例 2: ルーティング前に Content-Type ヘッダを変更する
  1. ポリシーに Route via HTTP(S) アサーションを追加して、
    [Do not automatically include Content-Type header in request]
    を選択します。
  2. Route via HTTP(S) アサーションの前に Manage Transport Properties/Headers アサーションを追加して、ターゲット メッセージを[Request]に設定します。 以下のようにプロパティを設定します。
    • Type:
      HTTP Header
    • Operation:
      Add or Replace
    • Property/Header Name:
      Content-Type
    • Property/Header Value:
      application/my-content-type
レスポンスには、応答メッセージの本文にポリシーで設定された Content-Type ヘッダ値(
application/my-content-type
)が含まれます。
例 3: ルーティング前に Content-Type ヘッダを追加する
  1. ポリシーに Route via HTTP(S) アサーションを追加して、
    [Do not automatically include Content-Type header in request]
    を選択します。
  2. Route via HTTP(S) アサーションの前に Manage Transport Properties/Headers アサーションを追加して、ターゲット メッセージを[Request]に設定します。 以下のようにプロパティを設定します。
    • Type:
      HTTP Header
    • Operation:
      Add
    • Property/Header Name:
      Content-Type
    • Property/Header Value:
      application/my-content-type
結果:
  • Content-Type ヘッダが存在せず、本文が空のリクエストの場合
    • レスポンスには、応答メッセージの本文にポリシーで追加された Content-Type ヘッダ値(
      application/my-content-type
      )が含まれます。
  • Content-Type ヘッダが存在せず、本文が空ではないリクエストの場合
    • レスポンスには、応答メッセージの本文にポリシーで追加された Content-Type ヘッダ値(
      application/my-content-type
      )および値
      application/x-www-form-urlencoded
      が含まれます。
  • Content-Type ヘッダ「text/xml」が存在し、本文が空ではないリクエストの場合
    • レスポンスには、応答メッセージの本文にポリシーで追加された Content-Type ヘッダ値(
      application/my-content-type
      )および値
      text/xml
      が含まれます。
[Proxy]タブの設定
プロキシ サーバが設定されている場合、[
Use Windows Integrated
]認証方式は使用できません。
[Proxy]タブは、HTTP プロキシ ホストが必要な場合にこれを設定するために使用されます。
プロキシ ホストを設定する場合、リテラル値を入力するか、コンテキスト変数を指定します。
  • Proxy Host:
    プロキシ ホストを入力するか、1 つ以上のコンテキストを参照します。
  • Proxy Port:
    ポート番号を入力するか、単一のコンテキスト変数を参照します。
  • Proxy Username:
    ユーザ名を入力するか、1 つ以上のコンテキスト変数を参照します。
  • Proxy Password:
    パスワードを入力するか、セキュアなパスワードの参照を使用します(推奨)。 単純なコンテキスト変数の参照は、ここでは使用
    できません
    セキュリティを最高にするには、実際のパスワードを入力する代わりに、セキュアなパスワードの参照を使用します。 これを行うには、まず、保存されたパスワードの管理タスクを使用してパスワードを定義し、このフィールドで
    ${secpass.<name>.plaintext}
    コンテキスト変数を使用して参照します。
[Other]タブの設定
[Other]タブは、さまざまな HTTP ルーティング設定を行うために使用されます。
  1. Request WSS Header Handling
    ]セクションで、セキュリティ ヘッダの処理方法を指定します。
    オプション
    説明
    Don't modify the request Security header
    送信リクエスト メッセージ内のセキュリティ ヘッダをそのまま残すように Gateway に指示します。 ただし、Gateway がメッセージ処理中に暗号化されたマテリアルを復号化する必要があった場合、リクエストのセキュリティ ヘッダが変更されている可能性があります。
    保護されたサービスがリクエストの元のセキュリティ ヘッダの独自のチェックを必要とする場合、または、保護されたサービスがそのリクエスト メッセージ内のセキュリティ ヘッダの有無に無関係な場合、この設定を使用します。
    最高のパフォーマンスを得るために、可能な場合は必ずこの設定を使用して、リクエストあたりのメッセージ変更量を最小化してください。
    ポリシーが WS-Security を使用する場合は、セキュリティ ヘッダを変更しないでください。 詳細については、「Add or Remove WS-Security アサーション」を参照してください。
    Remove Layer 7 actor and mustUnderstand attributes from processed Security header
    送信メッセージ内のセキュリティ ヘッダから「mustUnderstand」属性および「Layer 7」アクタを削除するように Gateway に指示します。
    Layer 7 アクタの存在がバックエンド サービスに関する問題を引き起こす場合は、この設定を使用します。 いくつかの場合において、このアクタが原因でバックエンド サービスがセキュリティ ヘッダを無視する可能性があります。これは、バックエンド サービスが、そのセキュリティ ヘッダが別のサービスに向けられていると認識するためです。 また、バックエンド サービスがセキュリティをサポートせず、セキュリティ ヘッダ上で「mustUnderstand」がアサートされたリクエストを拒否する場合、この設定を使用します。
    別の方法として、セキュリティ ヘッダを完全に削除することも考えられますが、メッセージからこれらを削除するには追加の処理が必要となり、これはパフォーマンスの低下を招きます。 また、ログ記録の目的で、セキュリティ ヘッダを原型のまま保持することが推奨されます。
    Remove processed Security header from request before routing
    保護されているサービスにリクエストを転送する前に Gateway によって処理されたすべてのセキュリティ ヘッダを削除するように Gateway に指示します。
    保護されているサービスが、転送されたリクエスト内のセキュリティ ヘッダを予期していない場合、この設定を使用します。
    Promote other security header as default before routing
    いずれかのダウンストリーム WSS 受信者を次のデフォルト WSS ヘッダとしてプロモートするように Gateway に指示します。 ドロップダウン リストから受信者を選択します。
    このオプションは、主に WSS アサーションの意図されている受信者が Actor 属性が含まれるセキュリティ ヘッダを受理または認識しない場合に使用されます。
    使用可能な WSS (WS-Security)メッセージ レベル アサーションの受信者の変更の詳細については、「WSS アサーション受信者の変更」を参照してください。
  2. Response Size Limit
    ]の下で、必要に応じてルーティング メッセージの許可された最大サイズをオーバーライドできます。 デフォルトでは、最大サイズは
    io.xmlPartMaxBytes
    クラスタ プロパティによって定義されます。 特定のサイズに制限する場合、コンテキスト変数を参照することも可能です。 無制限のサイズの応答メッセージを許可することは推奨されません。
    Gateway がレスポンス メッセージに対してさらなる処理を行う場合のみ、[
    Response Size Limit
    ]設定が有効になります。 この設定(
    io.xmlPartMaxBytes
    クラスタ プロパティも同様)は、Gateway で処理が必要とされず、応答がクライアントにストリーミングで戻される場合には適用
    されません
    (レスポンス ストリーミングは
    io.HttpResponseStreaming
    クラスタ プロパティによって制御されます)。クライアントに送信されるメッセージのサイズを制限するには、Limit Message Size アサーションを使用します。
    通常の状況では、[Response Size Limit]が圧縮メッセージ サイズに適用されます。 ただし、
    uncompressed
    レスポンス上で動作する必要があるアサーションがある場合(たとえば、Evaluate Response XPath アサーションなど)、
    uncompressed
    レスポンス サイズが適用されます。 たとえば、応答サイズが 50 KB に設定され、40 KB の圧縮された応答が届いたとき、そのメッセージは通常に渡されます。 ただし、圧縮されていない応答上で動作する必要があるアサーションがあり、メッセージが圧縮されていない 90 KB に展開されると、50 KB のサイズ制限を超え、ポリシーは失敗します。
  3. ダウンストリーム エンドポイントからのレスポンスに基づいてアサーション結果(
    Assertion Outcome
    )を選択します。
    オプション
    説明
    Fail if target returns error status (>=400)
    ターゲットから読み取られた応答にエラー状態(>= 400)が含まれる場合、そのアサーションは失敗します。
    このルールには例外があります。ポリシーが関連付けられるサービスが Web サービス(XML アプリケーションでない)として公開されていて、ターゲットがステータス 500 の応答を返し、コンテンツが SOAP エラーの場合、SOAP エラーは有効な応答として受理され、リクエスタに伝達されます。
    ターゲットからレスポンスを取得しているときにエラーが発生した場合、アサーションは失敗します。
    Pass through SOAP faults with error status 500
    エラー状態で失敗した場合、エラー状態 500 (内部エラー)に対して特別な処理を行えます。
    • ステータス 500 エラーが応答としてバックエンド サーバから返され、HTTP エラー コード 500 で完了することを可能にするには、このチェック ボックスをオンにします。
    • 500 エラーを SOAP エラーとして扱うには、このチェック ボックスをオフにします。これにより、カスタマイズされたエラー応答のトリガが可能になります。
    Never fail as long as target returns an answer
    エンドポイントがターゲットから読み取られた何らかの応答を返せば、そのアサーションは成功します。 このオプションを使用した場合、ターゲットからの応答を読み取ることができない場合にのみ、アサーションは失敗します。
    例外:
    以下の条件が両方とも真の場合、そのアサーションは失敗する可能性があります。
    • [Authentication]タブで、サービス認証が[Use HTTP Credentials from Request]である。
    • バックエンド サービスから 401 HTTP エラーが返される。
    このシナリオでのアサーション失敗を防ぐには、サービス認証として代わりに[Specify HTTP Credentials]メソッドを使用します。 ユーザ名およびパスワードを、リクエストからのコンテキスト変数として指定します(つまり、
    ${request.username}
    ${request.password}
    )。