test

Sun GlassFish Enterprise Server v2.1.1 管理ガイド

第 10 章 メッセージセキュリティーの設定

この章の一部の内容は、セキュリティーと Web サービスに関する基本概念の理解を前提としてます。この章では、Enterprise Server で Web サービスのメッセージレイヤーセキュリティーを設定する方法について説明します。この章の内容は次のとおりです。

メッセージセキュリティーの概要

「メッセージセキュリティー」を使用する場合、メッセージ内にセキュリティー情報が挿入され、その情報がメッセージとともにネットワークレイヤー経由でメッセージの送信先に届けられます。メッセージセキュリティーは、『Java EE 5.0 Tutorial』の「Security」の章で説明されているトランスポートレイヤーセキュリティーとは異なり、メッセージトランスポートからメッセージ保護を分離して伝送後もメッセージを保護されたままにするために使用することができます。

「Web Services Security: SOAP Message Security (WS-Security)」は、米国 Sun Microsystems, Inc. を含むすべての主要な Web サービステクノロジプロバイダによって共同開発された、相互運用可能な Web サービスセキュリティーを実現するための OASIS 国際標準です。WS-Security のメッセージセキュリティーメカニズムは、SOAP 経由で送信される Web サービスメッセージを XML 暗号化と XML デジタル署名を使ってセキュリティー保護する、というものです。WS-Security 仕様には、X.509 証明書、SAML アサーション、ユーザー名/パスワードなどの各種セキュリティートークンを使って SOAP Web サービスメッセージの認証および暗号化を実現する方法が規定されています。

WS-Security 仕様は、http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf で確認できます。

Enterprise Server のメッセージセキュリティーの理解

Enterprise Server は、Web サービスのクライアント側コンテナとサーバー側コンテナにおいて、WS-Security 標準に対する統合化されたサポートを提供します。この機能は統合化されているため、Enterprise Server のコンテナがアプリケーションに代わって Web サービスセキュリティーを適用します。また、そうしたセキュリティーで Web サービスアプリケーションを保護する際、アプリケーションの実装を変更する必要はありません。Enterprise Server は、これを実現する目的で、SOAP レイヤーメッセージセキュリティープロバイダとメッセージ保護ポリシーを、コンテナおよびコンテナ内に配備されたアプリケーションにバインドする機能を提供しています。

メッセージセキュリティーの責任の割り当て

Enterprise Server でメッセージセキュリティー設定の主要責任者として期待されるのは、「システム管理者」ロールと「アプリケーション配備担当者」ロールです。場合によっては、「アプリケーション開発者」もその責任の一端を担うことがありますが、通常は、システム管理者またはアプリケーション配備者のいずれかのロールが既存アプリケーションをセキュリティー保護し、開発者が関与することも、実装が変更されることもありません。次の各節では、各種ロールの責任を定義します。

システム管理者

システム管理者は次の責任を負います。

システム管理者は、管理コンソールを使用してサーバーセキュリティーの設定を管理し、コマンド行ツールを使用して証明書データベースを管理します。開発者プロファイルとクラスタプロファイルでは、証明書と非公開鍵はキーストア内に格納され、keytool を使って管理されます。一方、エンタープライズプロファイルでは、証明書と非公開鍵は NSS データベース内に格納され、certutil を使って管理されます。このドキュメントは主にシステム管理者を対象にしています。メッセージセキュリティータスクの概要については、「メッセージセキュリティーのための Enterprise Server の設定」を参照してください。

アプリケーション配備担当者

アプリケーション配備担当者は次の責任を負います。

アプリケーション開発者

アプリケーション開発者はメッセージセキュリティーを有効にできますが、そのようにする責任はありません。メッセージセキュリティーの設定をシステム管理者が行う場合、すべての Web サービスがセキュリティー保護されます。コンテナにバインドされているプロバイダまたは保護ポリシーと異なるものをアプリケーションにバインドする必要がある場合、アプリケーション配備担当者がメッセージセキュリティーの設定を行います。

アプリケーション開発者またはプログラマは次の責任を負います。

セキュリティートークンとセキュリティーメカニズムについて

WS-Security 仕様は、セキュリティートークンを使って SOAP Web サービスメッセージを認証および暗号化するための拡張可能なメカニズムを提供します。Enterprise Server とともにインストールされる SOAP レイヤーメッセージセキュリティープロバイダを使えば、ユーザー名 / パスワードセキュリティートークンと X.509 証明書セキュリティートークンによる SOAP Web サービスメッセージの認証と暗号化を行えます。Enterprise Server の今後のリリースでは、SAML アサーションなどのほかのセキュリティートークンを採用したプロバイダも追加される予定です。

ユーザー名トークンについて

Enterprise Server は、SOAP メッセージ内で「ユーザー名トークン」を使ってメッセージ「送信者」の認証 ID を確立します。パスワードが埋め込まれたユーザー名トークンを含むメッセージの受信者は、そのメッセージの送信者がそのトークンによって識別されるユーザーとして振る舞うことを許可されているかどうかを検証するために、その送信者がユーザーの秘密情報 (パスワード) を知っているかどうかを確認します。

ユーザー名トークンを使用する場合、有効なユーザーデータベースを Enterprise Server 上に設定する必要があります。

デジタル署名について

Enterprise Server は、XML デジタル署名を使ってメッセージの「コンテンツ」に認証 ID をバインドします。クライアントはデジタル署名を使用して、呼び出し元 ID を確立します。トランスポートレイヤーセキュリティーを使用する場合も、基本認証または SSL クライアント証明書認証を使う場合も、呼び出し元 ID を確立する方法はほぼ同様です。デジタル署名は、メッセージコンテンツのソースを認証するためにメッセージ受信者によって検証されます。このソースは、メッセージ送信者と異なる可能性があります。

デジタル署名を使用する場合、有効なキーストアおよびトラストストアファイルを Enterprise Server 上に設定する必要があります。このトピックの詳細については、「証明書ファイルについて」を参照してください。

暗号化について

暗号化の目的は、対象読者だけが理解できるようにデータを変更することです。これは、元のコンテンツを暗号化された要素に置き換えることにより行われます。公開鍵暗号方式に関して言えば、暗号化はメッセージを読み取ることができる関係者の ID を確立するために使用されます。

暗号化を使用する場合は、暗号化をサポートする JCE プロバイダがインストールされている必要があります。このトピックの詳細については、「JCE プロバイダの設定」を参照してください。

メッセージ保護ポリシーについて

メッセージ保護ポリシーは、要求メッセージ処理と応答メッセージ処理に対して定義され、ソース認証または受信者認証に関する要件として表現されます。ソース認証ポリシーは、メッセージを送信したエンティティーまたはメッセージのコンテンツを定義したエンティティーの ID がメッセージ内で確立され、その ID をメッセージ受信者が認証できる、という要件を表します。受信者認証ポリシーは、メッセージを受信可能なエンティティーの ID をメッセージ送信者が確立できるようにメッセージが送信される、という要件を表します。プロバイダは、特定のメッセージセキュリティーメカニズムを適用することで、SOAP Web サービスメッセージにおけるメッセージ保護ポリシーを実現します。

要求と応答に対するメッセージ保護ポリシーが定義されるのは、特定のプロバイダがコンテナ内に設定される時です。また、アプリケーションまたはアプリケーションクライアントの Sun 固有の配備記述子内で、アプリケーション固有のメッセージ保護ポリシー (Web サービスのポートまたは操作の粒度でのポリシー) を設定することも可能です。いずれにせよ、メッセージ保護ポリシーを定義する場合、クライアントの要求と応答に対するメッセージ保護ポリシーは、サーバーのそれと一致する (等しい) 必要があります。アプリケーション固有のメッセージ保護ポリシーの定義方法の詳細は、『開発者ガイド』の「Securing Applications」の章を参照してください。

メッセージセキュリティー用語の解説

次に、このドキュメントで使用する用語について説明します。これらの概念については、「メッセージセキュリティーのための Enterprise Server の設定」でも説明しています。

Web サービスのセキュリティー保護

Enterprise Server 上に配備された Web サービスをセキュリティー保護するには、アプリケーションの配備先コンテナ、またはそのアプリケーションがサービスを提供する Web サービスエンドポイントのいずれかに対し、SOAP レイヤーメッセージセキュリティープロバイダとメッセージ保護ポリシーをバインドします。Enterprise Server のクライアント側コンテナで SOAP レイヤーメッセージセキュリティー機能を設定するには、クライアントコンテナ、またはクライアントアプリケーションによって宣言されたポータブルサービス参照のいずれかに対し、SOAP レイヤーメッセージセキュリティープロバイダとメッセージ保護ポリシーをバインドします。

Enterprise Server のインストール時に、SOAP レイヤーメッセージセキュリティープロバイダが Enterprise Server のクライアント側コンテナとサーバー側コンテナ内に設定され、コンテナまたはコンテナ内に配備された個々のアプリケーションまたはクライアントからバインドして利用できるようになります。インストール中、プロバイダにはある単純なメッセージ保護ポリシーが設定されます。このポリシーをコンテナまたはコンテナ内のアプリケーションまたはクライアントにバインドした場合、すべての要求メッセージと応答メッセージに含まれるコンテンツのソースが、XML デジタル署名によって認証されるようになります。

Enterprise Server の管理インタフェースを使えば、既存のプロバイダをバインドして Enterprise Server のサーバー側コンテナから利用できるようにしたり、プロバイダが適用するメッセージ保護ポリシーを変更したり、別のメッセージ保護ポリシーを備えた新しいプロバイダ設定を作成したりできます。アプリケーションクライアントコンテナの SOAP メッセージレイヤーセキュリティー設定でも、これと同様の管理操作を実行できます。それらについては、「アプリケーションクライアントのメッセージセキュリティーの有効化」で定義しています。

Enterprise Server では、メッセージレイヤーセキュリティーはデフォルトで無効になっています。Enterprise Server のメッセージレイヤーセキュリティーを設定するには、「メッセージセキュリティーのための Enterprise Server の設定」に要約されている手順に従ってください。Enterprise Server 上に配備されたすべての Web サービスアプリケーションを Web サービスセキュリティーで保護するには、「メッセージセキュリティーのためのプロバイダの有効化」の手順に従ってください。

上記の手順 (Enterprise Server の再起動が必要な場合もあり) を実行し終わると、Enterprise Server 上に配備されたすべての Web サービスアプリケーションに Web サービスセキュリティーが適用されるようになります。

アプリケーション固有の Web サービスセキュリティーの設定

アプリケーション固有の Web サービスセキュリティー機能を (アプリケーション構築上で) 設定するには、そのアプリケーションの Sun 固有の配備記述子内で message-security-binding 要素を定義します。これらの message-security-binding 要素は、特定のプロバイダまたはメッセージ保護ポリシーを Web サービスエンドポイントまたはサービス参照に関連付けるために使用されます。また、この要素を修飾することで、それらのプロバイダやポリシーが対応するエンドポイントまたは参照サービスの特定のポートやメソッドに適用されるようにすることも可能です。

アプリケーション固有のメッセージ保護ポリシーの定義については、『Sun GlassFish Enterprise Server v2.1.1 Developer’s Guide』の第 5 章「Securing Applications」を参照してください。

サンプルアプリケーションのセキュリティー保護

Enterprise Server には、xms という名前のサンプルアプリケーションが付属しています。xms アプリケーションは、J2EE EJB エンドポイントと Java サーブレットエンドポイントの両方を使って実装された、単純な Web サービスです。両エンドポイントは同一のサービスエンドポイントインタフェースを共有しています。このサービスエンドポイントインタフェースには、単一の操作 sayHello が定義されています。この操作は、文字列引数を 1 つ受け取り、その呼び出し引数の前に Hello が付加された String を返します。

xms サンプルアプリケーションは、Enterprise Server の WS-Security 機能を使って既存の Web サービスアプリケーションをセキュリティー保護する方法を示す目的で提供されています。サンプルに付属する手順では、Enterprise Server の WS-Security 機能を有効にして xms アプリケーションを保護する方法が説明されています。また、このサンプルは、WS-Security 機能をアプリケーションに直接バインドする方法 (「アプリケーション固有の Web サービスセキュリティーの設定」を参照) も示しています。

xms サンプルアプリケーションは次のディレクトリにインストールされます。 as-install/samples/webservices/security/ejb/apps/xms/。

xms サンプルアプリケーションのコンパイル、パッケージ化、および実行に関する詳細については、『Developers’ Guide』の「Securing Applications」の章を参照してください。

メッセージセキュリティーのための Enterprise Server の設定

要求および応答ポリシー設定のアクション

次の表に、メッセージ保護ポリシーの設定と、その設定の結果として WS-Security SOAP メッセージセキュリティープロバイダが実行するメッセージセキュリティー処理を示します。

表 10–1 メッセージ保護ポリシーと WS-Security SOAP メッセージセキュリティー処理との対応づけ

メッセージ保護ポリシー 

結果として実行される WS-Security SOAP メッセージ保護処理 

auth-source="sender" 

メッセージに wsse:Security ヘッダーが格納され、そのヘッダー内に wsse:UsernameToken (パスワード付き) が格納されます。

auth-source="content" 

SOAP メッセージ本体のコンテンツが署名されます。メッセージに wsse:Security ヘッダーが格納され、そのヘッダー内にメッセージ本体の署名が ds: Signature として格納されます。

auth-source="sender" 

auth-recipient="before-content" 

または 

auth-recipient="after-content" 

SOAP メッセージ本体のコンテンツが暗号化され、その結果得られた xend:EncryptedData で置換されます。メッセージに wsse:Security ヘッダーが格納され、そのヘッダー内に wsse:UsernameToken (パスワード付き) と xenc:EncryptedKey が格納されます。また、xenc:EncryptedKey には SOAP メッセージ本文の暗号化に使用する鍵が含まれます。この鍵は、受信者の公開鍵内で暗号化されています。

auth-source="content" 

auth-recipient="before-content" 

SOAP メッセージ本体のコンテンツが暗号化され、その結果得られた xend:EncryptedData で置換されます。xenc:EncryptedData は署名されています。メッセージに wsse:Security ヘッダーが格納され、そのヘッダー内に xenc:EncryptedKey と ds: Signature が格納されます。また、xenc:EncryptedKey には SOAP メッセージ本文の暗号化に使用する鍵が含まれます。この鍵は、受信者の公開鍵内で暗号化されています。

auth-source="content" 

auth-recipient="after-content" 

SOAP メッセージ本体のコンテンツが、署名されたあと暗号化され、その結果得られた xend:EncryptedData で置換されます。メッセージに wsse:Security ヘッダーが格納され、そのヘッダー内に xenc:EncryptedKey と ds:Signature が格納されます。また、xenc:EncryptedKey には SOAP メッセージ本文の暗号化に使用する鍵が含まれます。この鍵は、受信者の公開鍵内で暗号化されています。

auth-recipient="before-content" 

または 

auth-recipient="after-content" 

SOAP メッセージ本体のコンテンツが暗号化され、その結果得られた xend:EncryptedData で置換されます。メッセージには、xenc:EncryptedKey を含む wsse:Security ヘッダーが含まれます。また、xenc:EncryptedKey には SOAP メッセージ本文の暗号化に使用する鍵が含まれます。この鍵は、受信者の公開鍵内で暗号化されています。

ポリシーを何も指定しない。 

モジュールはセキュリティー処理を一切行いません。 

その他のセキュリティー機能の設定

Enterprise Server は、SOAP 処理レイヤー内に統合化されたメッセージセキュリティープロバイダを使用して、メッセージセキュリティーを実装します。メッセージセキュリティープロバイダは、Enterprise Server のその他のセキュリティー機能に依存します。

  1. バージョン 1.5.0 より前のバージョンの Java SDK を使用し、暗号化技術を使用する場合は、JCE プロバイダを設定します。

  2. JCE プロバイダの設定については、「JCE プロバイダの設定」を参照してください。

  3. ユーザー名トークンを使用する場合は、必要に応じてユーザーデータベースを設定します。ユーザー名およびパスワードトークンを使用する場合は、適切なレルムを設定し、このレルムに適切なユーザーデータベースを設定する必要があります。

  4. 必要に応じて証明書と非公開鍵を管理します。

次の手順

Enterprise Server の機能の設定が完了し、メッセージセキュリティープロバイダがそれらの機能を使用できるようになると、Enterprise Server とともにインストールされたプロバイダを有効にできます。その手順については、「メッセージセキュリティーのためのプロバイダの有効化」を参照してください。

JCE プロバイダの設定

J2SE 1.4.x に付属している JCE (Java Cryptography Extension) プロバイダは RSA 暗号化をサポートしていません。通常、WS-Security で定義されている XML 暗号化は RSA 暗号化に基づいているため、WS-Security を使って SOAP メッセージを暗号化するには、RSA 暗号化をサポートする JCE プロバイダをダウンロードおよびインストールする必要があります。

注 –

RSA は RSA Data Security, Inc. が開発した公開鍵暗号化技術です。この略語は、この技術の開発者である Rivest、Shamir、および Adelman を表しています。

Java SDK Version 1.5 以上で Enterprise Server を実行している場合は、JCE プロバイダは正しく設定されています。Java SDK Version 1.4.x で Enterprise Server を実行している場合は、次のようにJCE プロバイダを JDK 環境の一部として静的に追加できます。

  1. JCE プロバイダの JAR (Java ARchive) ファイルをダウンロードし、インストールします。

    RSA 暗号化をサポートする JCE プロバイダのリストについては、http://java.sun.com/products/jce/javase_providers.html を参照してください。

  2. JCE プロバイダの JAR ファイルを java-home/jre/lib/ext/ にコピーします。

  3. Enterprise Server を停止します。

    Enterprise Server を停止せずにこの手順の最後で再起動した場合、JCE プロバイダは Enterprise Server に認識されません。

  4. 任意のテキストエディタで java-home/jre/lib/security/java.security プロパティーファイルを編集します。このファイルに、前述の手順でダウンロードした JCE プロバイダを追加します。

    java.security ファイルに、このプロバイダを追加する詳細手順が含まれています。基本的には、類似のプロパティーを持つ場所に次の形式の行を追加する必要があります。


    security.provider.n=provider-class-name

    この例では、n は、Enterprise Server がセキュリティープロバイダを評価する際に使用する優先順位を示します。追加した JCE プロバイダには、n を 2 に設定します。

    たとえば、The Legion of the Bouncy Castle JCE プロバイダをダウンロードした場合は、次のような行を追加します。


    security.provider.2=org.bouncycastle.jce.provider.
   BouncyCastleProvider

    Sun セキュリティープロバイダが、値 1 の最高の優先順位に設定されていることを確認してください。


    security.provider.1=sun.security.provider.Sun

    各レベルにセキュリティープロバイダがただ 1 つだけ設定されるように、ほかのセキュリティープロバイダのレベルを下位に調整します。

    次に示す例は、必要な JCE プロバイダを提供し、既存のプロバイダを正しい位置に保持する java.security ファイルのサンプルです。


    security.provider.1=sun.security.provider.Sun
security.provider.2=org.bouncycastle.jce.provider.
   BouncyCastleProvider
security.provider.3=com.sun.net.ssl.internal.ssl.Provider
security.provider.4=com.sun.rsajca.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider

  5. ファイルを保存して、閉じます。

  6. Enterprise Server を再起動します。

メッセージセキュリティーの設定

メッセージセキュリティーを使用できるように Enterprise Server を設定する手順のほとんどは、管理コンソールまたは asadmin コマンド行ツールを使用するか、あるいはシステムファイルを手動で編集することで実現できます。一般に、システムファイルの編集はお勧めできません。なぜなら、Enterprise Server が適切に動作しなくなるような変更を間違って施してしまう可能性があるからです。したがって、できるだけ、管理コンソールによる Enterprise Server の設定手順を最初に示し、その後に asadmin ツールコマンドによる手順を示しています。システムファイルを手動で編集する手順は、管理コンソールと asadmin に同等の方法が存在しない場合にだけ示しています。

メッセージレイヤーセキュリティーのサポートは、プラグイン可能な認証モジュールの形式で Enterprise Server とそのクライアントコンテナに統合されています。Enterprise Server では、メッセージレイヤーセキュリティーはデフォルトで無効になっています。次の各節では、メッセージセキュリティー設定とプロバイダを有効化、作成、編集、および削除する方法について、詳しく説明します。

ほとんどの場合、上記の管理操作を実行したあとで Enterprise Server を再起動する必要があります。特に、操作実行時に Enterprise Server 上にすでに配備されていたアプリケーションに管理上の変更を適用する場合に Enterprise Server の再起動が必要となります。

メッセージセキュリティーのためのプロバイダの有効化

Enterprise Server 上に配備された Web サービスエンドポイントのメッセージセキュリティーを有効にするには、サーバー側でデフォルトで使用されるプロバイダを指定する必要があります。メッセージセキュリティーのデフォルトプロバイダを有効にする場合、Enterprise Server 上に配備された Web サービスクライアントが使用するプロバイダも有効にする必要があります。クライアントが使用するプロバイダを有効にする方法については、「アプリケーションクライアントのメッセージセキュリティーの有効化」を参照してください。

配備済みエンドポイントからの Web サービス呼び出しに対してメッセージセキュリティーを有効にするには、デフォルトクライアントプロバイダを指定する必要があります。Enterprise Server のデフォルトクライアントプロバイダを有効にした場合、Enterprise Server 内に配備されたエンドポイントから呼び出されるすべてのサービスが、メッセージレイヤーセキュリティー用に正しく設定されていることを確認する必要があります。

コマンド行ユーティリティーを使用するには、次の手順に従います。

メッセージセキュリティープロバイダの設定

プロバイダの再設定は、プロバイダタイプ、実装クラス、およびプロバイダ固有の設定プロパティーを変更するために実行することもできますが、通常はメッセージ保護ポリシーを変更するために実行します。

コマンド行ユーティリティーを使用して、応答ポリシーを設定する場合は、次のコマンドの request という単語を response に置き換えてください。

メッセージセキュリティープロバイダの作成

管理コンソールを使用して既存のプロバイダを設定するには、「設定」ノード > 設定するインスタンス >「セキュリティー」ノード >「メッセージセキュリティ」ノード >「SOAP」ノード >「プロバイダ」タブの順に選択します。

メッセージセキュリティープロバイダの作成方法については、管理コンソールのオンラインヘルプを参照してください。

アプリケーションクライアントのメッセージセキュリティーの有効化

クライアントプロバイダのメッセージ保護ポリシーは、通信相手となるサーバー側プロバイダのメッセージ保護ポリシーと等しくなるように設定する必要があります。Enterprise Server がインストールされるとき、プロバイダはデフォルトでそのように設定されます (ただし、有効化はされていない)。

クライアントアプリケーションのメッセージセキュリティーを有効にするには、アプリケーションクライアントコンテナの Enterprise Server 固有の設定を変更します。

アプリケーションクライアント設定の要求および応答ポリシーの設定

「要求および応答ポリシー」は、認証プロバイダが実行する要求および応答処理に関連付けられた認証ポリシー要件を定義します。ポリシーはメッセージ送信者による順序で示されるので、「コンテンツのあと」ではメッセージ受信者が署名の検証前にメッセージを復号化することを意味します。

メッセージセキュリティーを実現するには、サーバーとクライアントの両方で要求ポリシーと応答ポリシーが有効化されている必要があります。クライアントおよびサーバーのポリシーを設定する場合は、クライアントポリシーがアプリケーションレベルのメッセージのバインドで要求および応答保護のサーバーポリシーと一致する必要があります。

アプリケーションクライアント設定の要求ポリシーを設定するには、「アプリケーションクライアントのメッセージセキュリティーの有効化」の説明に従って、アプリケーションクライアントコンテナの Enterprise Server 固有の設定を変更します。アプリケーションクライアント設定ファイル内で request-policy 要素と response-policy 要素を次のように追加することで、要求ポリシーを設定します。

その他のコードは参照用に用意されています。実際のインストールでは、その他のコードが若干異なっている可能性があります。変更しないでください。


<client-container>
  <target-server name="your-host" address="your-host"
      port="your-port"/>
  <log-service file="" level="WARNING"/>
  <message-security-config auth-layer="SOAP"
      default-client-provider="ClientProvider">
    <provider-config
        class-name="com.sun.enterprise.security.jauth.ClientAuthModule"
        provider-id="ClientProvider" provider-type="client">
      <request-policy auth-source="sender | content"
        auth-recipient="after-content | before-content"/>
      <response-policy auth-source="sender | content"
        auth-recipient="after-content | before-content"/>
       <property name="security.config"
           value="as-install/lib/appclient/wss-client-config.xml"/>
    </provider-config>
  </message-security-config>
</client-container>

auth-source の有効な値には、sender と content があります。auth-recipient の有効な値には、before-content と after-content があります。これらの値をさまざまに組み合わせた結果を記述した表については、「要求および応答ポリシー設定のアクション」を参照してください。

要求または応答ポリシーを指定しない場合は、この要素を空白のままにします。次に例を示します。


<response-policy/>

詳細情報