ポリシーの作成と使用

構成クラスの影響

構成クラスをコンパイルすると、Web サービスまたはクライアントの以降の動作は次のような影響を受けます。

• Web サービスまたはクライアントでは、ポリシーの詳細に従って、発信メッセージに追加のヘッダ要素が含まれます。

• Web サービスまたはクライアントは、ポリシーに基づいて着信 SOAP メッセージを検証します。これには、必要に応じた着信メッセージの解読も含まれます。

• Web サービスまたはクライアントは、オプションで、発信メッセージを必要に応じて暗号化します。

• Web サービスでは、WSDL が自動的に影響を受けます。具体的には、<wsp:Policy> 要素が追加され、ネームスペース宣言に次の行が含まれるようになります。

  xmlns:wsp="http://www.w3.org/ns/ws-policy"
  

  

WS-Security、WS-Addressing、および MTOM サポートとの関係

WS-Policy に対する Caché のサポートは、WS-Security、WS-Addressing、および MTOM に対する Caché のサポートに基づいています。以下の点に注意してください。

• ポリシーにセキュリティ・ポリシーが含まれていない場合、Caché は、Web サービスまたは Web クライアントの SecurityOut プロパティを使用します (Web サービスまたは Web クライアントにセキュリティ・ヘッダ要素を手動で追加するには、このドキュメントで後述するように、SecurityOut プロパティに追加します)。

• ポリシーにセキュリティ ポリシーが含まれている場合、Caché は、そのポリシーに関連するすべての要素を除いて、Web サービスまたは Web クライアントの SecurityOut プロパティを無視します。

  例えば、X.509 相互証明書セキュリティ・ポリシーを使用する場合、ポリシー内で直接使用する Caché 資格情報セットを指定することも、%SYS.X509CredentialsOpens in a new tab のインスタンスを作成し、バイナリ・セキュリティ・トークンに格納して SecurityOut プロパティに追加することもできます。ポリシー内で直接資格情報セットが指定されない場合、Caché は、SecurityOut プロパティからバイナリ・セキュリティ・トークンを取得し、それを使用します。ただし、SecurityOut プロパティの他の要素はこのシナリオには適用されないため、Caché はそれらを無視します。

• ポリシーで WS-Addressing を必要とする場合、Caché は、WSADDRESSING クラス・パラメータを無視します。

  ただし、AddressingOut プロパティが設定されていると、Caché は、指定の WS-Addressing ヘッダを使用します。それ以外の場合、WS-Addressing ヘッダの既定のセットが使用されます。

• ポリシーで MTOM を必要とする場合、Caché は、MTOMREQUIRED クラス・パラメータおよび MTOMRequired プロパティを無視します。

Web サービスと Web クライアントの関係

Web サービスにポリシーを添付する場合、すべてのクライアントは、そのポリシーに従うことが可能でなければなりません。Web サービス・ポリシーに代替ポリシーが何も含まれていない場合、クライアントには、Web サービスと同じポリシーが必要です。このとき、必要に応じて、サーバ側の証明書の代わりにクライアント側の証明書を使用します。

同様に、Web クライアントにポリシーを添付する場合、サービスは、そのポリシーに従うことが可能でなければなりません。

実際には、Caché にサービスとクライアントの両方が作成される場合、最も簡単な手順は次のとおりです。

1. Web サービス・クラスを作成します。

2. Web サービス構成クラスを、サービス・ポリシーと共に作成します。

3. SOAP ウィザードを使用して、クライアント構成クラスなどのクライアント・クラスを生成します。

   これを実行した後、生成されたクライアント・クラスを検証し、必要に応じて変更を加えます。最も一般的な変更は、メソッド・シグニチャを長い文字列に調整することです。

   通常、このためにラッパ・クラスも作成します。

   これらのタスクの詳細は、"Caché での Web サービスおよび Web クライアントの作成" を参照してください。

4. 生成された構成クラスを検証し、必要に応じて変更を加えます。“生成されたポリシーの編集” を参照してください。

構成クラスの詳細は、次の章 “WS-Policy 構成クラスの詳細” を参照してください。

Web サービス/クライアント構成ウィザードの使用法

スタジオの Web サービス/クライアント構成ウィザードを使用して、ポリシーを作成および添付することができます。このウィザードを使用する手順は次のとおりです。

1. [ファイル]→[新規作成] をクリックします。

2. [一般] タブで、[Web サービス/クライアント構成] をクリックします。

3. [OK] をクリックします。

   スタジオにダイアログ・ボックスが表示されます。

4. ポリシーの適用対象とする Web サービスまたは Web クライアントを選択します。ウィザードには、コンパイルされるサービスおよびクライアントのみが一覧表示されます。

   そのためには、必要に応じて [サービス] または [クライアント] ドロップダウン・メニューをクリックし、Web サービス・クラスまたは Web クライアント・クラスをクリックします。

5. [次へ] をクリックします。

   スタジオに別のダイアログ・ボックスが表示されます。

6. オプションで、このダイアログ・ボックスの 2 番目のフィールドに表示されている構成クラス名を編集します。

   Note:

   このクラスが既に存在する場合、ウィザードは、既存のコンテンツを無視し、それを上書きします。ウィザードの最後に到達しない限り、新しいクラスは作成されません。

   既定の構成クラス名は、Web サービスまたはクライアント・クラス名に Config を追加したものです。

7. このページの残りの詳細は、“セキュリティ・ポリシーの説明” および “ポリシー・オプションのリファレンス” を参照してください。

8. [完了] をクリックします。

   ウィザードにより、クラスが作成され、保存されます。

9. 生成された構成クラスを確認します。構成クラスには、発信メッセージにタイムスタンプを追加するポリシー式も含まれています。

   <sp:IncludeTimestamp/>
   

   

10. オプションで、構成クラスを編集し、再保存します。

    例えば、代替ポリシーを追加したり、ウィザードによって作成されたポリシーを調整したりするには、この操作を行います。

クラスは、自動的にはコンパイルされません。また、ポリシーは、クラスがコンパイルされないと有効になりません。

WSDL からのポリシーの生成

クライアント・クラスは既にあるものの、対応する構成クラスがない場合があります。これは、WSDL からクライアント・クラスを生成し、その後 WS-Policy 情報を含むように WSDL が変更された場合などに発生します。このような場合、以下のように、%SOAP.WSDL.ReaderOpens in a new tab のユーティリティ・メソッドを使用して、構成クラスのみを生成できます。

1. %SOAP.WSDL.ReaderOpens in a new tab のインスタンスを作成します。

2. そのインスタンスのプロパティを規定どおりに設定します。%SOAP.WSDL.ReaderOpens in a new tab については、クラス・ドキュメントを参照してください。

   Process() メソッドは使用しないでください。

3. インスタンスの GeneratePolicyFromWSDL() メソッドを呼び出します。

   このメソッドには、以下のシグニチャがあります。

   method GeneratePolicyFromWSDL(wsdlURL As %String, 
       clientWebServiceClass As %String, 
       policyConfigClass As %String) as %Status
   

   

   以下はその説明です。

   • wsdlURL は、ポリシーを含む WSDL の URL です。WSDL が 1 つのポートのみを指定することが前提となっています。

   • clientWebServiceClass は、Web クライアント・クラスの名前です。この Web クライアントが指定の WSDL と一致することを確認する必要があります。

   • policyConfigClass は、作成される構成クラスの名前です。

Web サービスの WSDL が指定するポリシーを含む Web サービス・クライアントの構成クラスが作成 (または上書き) されます。WSDL にポリシーがない場合は、空の構成クラスが作成されます。インスタンスの CompileClasses プロパティが 1 の場合は、この構成クラスがコンパイルされます。

SSL/TLS 接続セキュリティ

このポリシーは、Web クライアントと Web サービス間で HTTP over SSL/TLS (HTTPS) を使用することを要求します。これにより、データ・ストリームの機密性と整合性、サーバの認証、およびクライアントのオプションの認証が提供されます。

SSL/TLS 経由のユーザ名認証

このポリシーは、クライアントに、(ユーザ名およびパスワードと共に) <UsernameToken> を送信することを要求します。また、HTTP over SSL/TLS (HTTPS) も要求します。これにより、データ・ストリームの機密性と整合性の維持、サーバの認証、およびクライアントのオプションの認証が可能となります。

実行時、Web クライアントは、既定のパスワード・タイプを使用してユーザ名トークンを作成および追加する必要があります。このドキュメントで後述する “ユーザ名トークンの追加” を参照してください。

SSL/TLS 経由の X.509 証明書認証

このポリシーは、クライアントに、署名済みの本文とタイムスタンプ、およびシグニチャを検証できる X.509 証明書と共にメッセージを送信することを要求します。WS-Addressing ヘッダが含まれている場合は、それも署名されます。また、HTTP over SSL/TLS (HTTPS) も要求します。これにより、データ・ストリームの機密性と整合性の維持、サーバの認証、およびクライアントのオプションの認証が可能となります。

対称鍵による認証

このポリシーは、メッセージの署名と暗号化の両方に使用する、1 つの共有秘密鍵を必要とします。この対称鍵は、実行時に生成され、サービスの証明書の公開鍵を使用して暗号化されます。

サービスは、認証のために、暗号化されたユーザ名および既定のパスワード・タイプのパスワードを必要に応じて要求することができます。このオプションを選択した場合、クライアントは、このドキュメントで後述の “ユーザー名トークンの追加” の説明に従って、実行時に <UsernameToken> を追加する必要があります。手動で <UsernameToken> を暗号化する必要はありません。Caché が自動的に暗号化します。

保証証明書を使用した対称鍵

このポリシーは、メッセージの署名と暗号化の両方に使用する、1 つの共有秘密鍵を必要とします。この対称鍵は、実行時に生成され、サービスの証明書の公開鍵を使用して暗号化されます。

サービスは、認証のために、暗号化されたユーザ名および既定のパスワード・タイプのパスワードを必要に応じて要求することができます。このオプションを選択した場合、クライアントは、このドキュメントで後述の “ユーザー名トークンの追加” の説明に従って、実行時に <UsernameToken> を追加する必要があります。手動で <UsernameToken> を暗号化する必要はありません。Caché が自動的に暗号化します。

このメカニズムは、クライアント保証証明書を使用して、メッセージ・シグニチャに関連付けられたトークンを拡張します。

X.509 相互証明書セキュリティ

このポリシーは、すべての相手に、メッセージ本文とタイムスタンプ、および WS-Addressing ヘッダ (含まれている場合) に署名することを要求します。また、オプションで、相手の証明書の公開鍵を使用してメッセージ本文を暗号化します。

サービスは、認証のために、暗号化されたユーザ名および既定のパスワード・タイプのパスワードを必要に応じて要求することができます。このオプションを選択した場合、クライアントは、このドキュメントで後述の “ユーザー名トークンの追加” の説明に従って、実行時に <UsernameToken> を追加する必要があります。手動で <UsernameToken> を暗号化する必要はありません。Caché が自動的に暗号化します。

SSL/TLS 経由の SAML 承認

このポリシーは、クライアントに、X.509 証明書または公開鍵を含む SAML トークンを送信することを要求します。対応する秘密鍵は、メッセージ本文とタイムスタンプ、および WS-Addressing ヘッダ (含まれている場合) に署名します。また、HTTP over SSL/TLS (HTTPS) も要求します。これにより、データ・ストリームの機密性と整合性の維持、サーバの認証、およびクライアントのオプションの認証が可能となります。

X.509 証明書を持つ SAML

このポリシーは、SAML トークンを送信することをクライアントに要求します。このポリシーはまた、メッセージ本文とタイムスタンプ、および WS-Addressing ヘッダ (含まれている場合) に署名します。また、オプションで、相手の証明書の公開鍵を使用してメッセージ本文を暗号化します。

資格情報セット

多くのポリシーにおいて、以下のように Caché 資格情報セットを選択できます。

• [X.509 証明書] ドロップダウン・リストから資格情報セットを選択します。

• 証明書のフィールドの値を指定して、資格情報セットを選択します。そのためには、[フィールド] ドロップダウン・リストからフィールドを選択し、入力ボックスに値を入力します。

  使用できるフィールドは次のとおりです。

  • Alias

  • SubjectKeyIdentifier

  • Thumbprint

  • SerialNumber

  • IssuerDN

  • IssuerName — IssuerDN フィールドの検索文字列として動作します。システムは、IssuerDN フィールドに指定の文字列が含まれている最初の資格情報セットを選択します (一方、IssuerDN を使用する場合は、正確に一致しなければなりません)。

  • SubjectDN

  • SubjectName — SubjectDN フィールドの検索文字列として動作します。システムは、SubjectDN フィールドに指定の文字列が含まれている最初の資格情報セットを選択します (一方、SubjectDN を使用する場合は、正確に一致しなければなりません)。

または、プログラムで資格情報セットを選択できます。このドキュメントで前述の “プログラムによる資格情報セットの取得” を参照してください。この場合、この章で後述の “実行時の証明書の追加” の説明に従って、証明書をバイナリ・セキュリティ・トークンでパッケージ化し、これを発信メッセージに追加する必要もあります。