ヘッダーをスキップ
Oracle® Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド
11gリリース1（11.1.1）
B56247-02
  目次
目次
戻る
戻る 		 次へ
次へ		  

9 ポリシーの環境設定

この章では、セキュリティ・ポリシーのためのFusion Middleware ControlおよびWebLogic Server環境の設定方法について説明します。

この章では次の項について説明します。

SSLに関するキーストアの構成

「SSLの構成が必要なポリシー」または「双方向SSLの構成が必要なポリシー」にあげたポリシーを使用する場合、SSL用のキーストアを構成する必要があります。

SSLでは、ネットワークを介して接続される2つのアプリケーションが互いのアイデンティティを認証できるようにし、アプリケーション間で交換されるデータを暗号化することで、安全な接続を提供します。

認証によって、サーバーと、必要に応じてクライアントが、ネットワーク接続の反対側にあるアプリケーションのアイデンティティを検証できます。暗号化によって、ネットワーク上で伝送されるデータを意図した受信者のみが認識できるようになります。クライアント証明書（双方向SSL）は、ユーザーの認証に使用できます。

この項では、SSL経由でリクエストを送信するようにWebサービス・クライアントとWebLogic Server Webサービス・コンテナを設定する方法を説明します。

Webサービス・アプリケーションでSSLを使用するには、次の作業を実行する必要があります。

これらの手順については、次の項で説明します。

SSLの構成が必要なポリシー

SSLの構成が必要な事前定義済ポリシーは次のとおりです。

  • oracle/wss_http_token_over_ssl_service_policy

  • oracle/wss_http_token_over_ssl_client_policy

  • oracle/wss_saml_token_bearer_over_ssl_service_policy

  • oracle/wss_saml_token_bearer_over_ssl_client_policy

  • oracle/wss_saml_token_over_ssl_service_policy

  • oracle/wss_saml_token_over_ssl_client_policy

  • oracle/wss_username_token_over_ssl_service_policy

  • oracle/wss_username_token_over_ssl_client_policy

さらに、次のテンプレートを使用して、SSLを必要とする新しいポリシーを作成できます。

  • oracle/wss_http_token_over_ssl_service_template

  • oracle/wss_http_token_over_ssl_client_template

  • oracle/wss_saml_token_bearer_over_ssl_service_template

  • oracle/wss_saml_token_bearer_over_ssl_client_template

  • oracle/wss_saml_token_over_ssl_service_template

  • oracle/wss_saml_token_over_ssl_client_template

  • oracle/wss_username_token_over_ssl_service_template

  • oracle/wss_username_token_over_ssl_client_template

これらのアサーションおよびポリシーの詳細は、付録C「事前定義済アサーション・テンプレート」および付録B「事前定義済ポリシー」を参照してください。

双方向SSLの構成が必要なポリシー

双方向SSLの構成が必要な事前定義済ポリシーは次のとおりです。

  • oracle/wss_saml_token_over_ssl_client_policy

  • oracle/wss_saml_token_over_ssl_service_policy

  • oracle/wss_username_token_over_ssl_client_policy（相互認証を選択した場合）

  • oracle/wss_username_token_over_ssl_service_policy（相互認証を選択した場合は、）

  • oracle/wss_http_token_over_ssl_client_policy（相互認証を選択した場合）

  • oracle/wss_http_token_over_ssl_service_policy（相互認証を選択した場合）

さらに、次のテンプレートを使用して、双方向SSLを必要とする新しいポリシーを作成できます。

  • oracle/wss_saml_token_over_ssl_client_template

  • oracle/wss_saml_token_over_ssl_service_template

WebLogic Serverへのキーストアの構成方法

秘密鍵、デジタル証明書および信頼できる認証局（CA）証明書によって、WebLogic Server環境でアイデンティティと信頼が確立され、検証されます。

この項では、WebLogic Serverにキーストアを構成するために必要な手順の概要を説明します。詳細は、次の2つの資料を参照してください。

  • 詳細は、Oracle WebLogic Server管理コンソールのヘルプ。特に「サーバー: 構成: キーストア」に関するトピック。

  • Securing Oracle WebLogic Server。特にアイデンティティと信頼の構成に関する項。

WebLogic Serverには、デフォルトのアイデンティティ・キーストアDemoIdentity.jksとデフォルトの信頼キーストアDemoTrust.jksが構成されています。さらに、WebLogic Serverでは、JDKのcacertsファイル内の認証局を信頼しています。このデフォルトのキーストア構成は、テストや開発を目的とする場合に適しています。ただし、これらのキーストアは本番環境では使用しないでください。

サーバーのアイデンティティと信頼を構成する手順は次のとおりです。

  1. Sun社のkeytoolユーティリティまたはEntrust社やVerisign社のような信頼できるベンダーから、デジタル証明書、秘密鍵および信頼できるCA証明書を取得し、キーストアに含めます。

    証明書を取得するには、証明書リクエストを作成してCAに送信する必要があります。CAは、証明書リクエストを認証し、リクエストに基づいてデジタル証明書を作成します。

    秘密鍵、デジタル証明書および信頼できる認証局（CA）には、Privacy Enhanced Mail（PEM）形式を使用することをお薦めします。

    keytoolユーティリティを使用する場合、デフォルトの鍵のペア生成アルゴリズムはDigital Signature Algorithm（DSA）です。WebLogic ServerではDSAはサポートされていません。WebLogic Serverを使用する場合は、RSAなど、別の鍵のペア生成および署名アルゴリズムを指定してください。Sun社のkeytoolユーティリティの詳細は、「keytool - Key and Certificate Management Tool」（http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/keytool.html）の説明を参照してください。

    WebLogic Serverキットで提供されるデジタル証明書、秘密鍵および信頼できるCA証明書も使用できます。デモ用のデジタル証明書、秘密鍵および信頼できるCA証明書は、開発環境でのみ使用してください。

  2. アイデンティティ用に1つと信頼用に1つ、キーストアを作成します。キーストア形式にはJavaキーストア（JKS）を使用することをお薦めします。

  3. 秘密鍵と信頼できるCAをキーストアにロードします。

  4. コンソールの左側のペインで、「環境」を開き、「サーバー」を選択します。

  5. アイデンティティと信頼キーストアを構成するサーバーの名前をクリックします。

  6. 「構成」→「キーストア」を選択します。

  7. 「キーストア」フィールドで、秘密鍵/デジタル証明書のペアおよび信頼できるCA証明書を格納および管理する方法を選択します。選択できるオプションは次のとおりです。

    • カスタムIDとカスタム信頼: ユーザーが作成するアイデンティティと信頼キーストア。

    • デモIDとデモ信頼: デモ用のアイデンティティと信頼キーストア。..\server\libディレクトリおよびJDK cacertsキーストアにあり、デフォルトで構成されています。開発目的にのみ使用してください。

    • カスタムIDとJava標準信頼: ユーザーが作成するキーストアと、JAVA_HOME\jre\lib\securityディレクトリのcacertsファイルに定義されている信頼できるCA。

    • カスタムIDとコマンドライン信頼: ユーザーが作成するアイデンティティ・キーストアと、信頼キーストアの場所を指定するコマンドライン引数。

  8. 「ID」セクションで、アイデンティティ・キーストアの属性を定義します。

    • カスタムIDキーストア: アイデンティティ・キーストアへの完全修飾パス。

    • カスタムIDキーストアのタイプ: キーストアのタイプ。一般に、この属性にはJavaキーストア（JKS）を指定します。空白のままにすると、デフォルトでJKSに設定されます。

    • カスタムIDキーストアのパスフレーズ: キーストアの読取りまたは書込み時に入力するパスワード。この属性は、キーストアのタイプに応じてオプションまたは必須になります。すべてのキーストアで、書込みにはパスフレーズが必要です。ただし、キーストアによっては読取りにパスフレーズが不要な場合もあります。WebLogic Serverは、キーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件に応じて決まります。


      注意:

      デモ・アイデンティティ・キーストアのパスフレーズは、DemoIdentityKeyStorePassPhraseです。

  9. 「信頼」セクションで、信頼キーストアのプロパティを定義します。

    キーストアとして「Java標準信頼キーストア」を選択する場合、キーストアの作成時に定義したパスワードを指定します。パスワードを確認します。

    カスタム信頼を選択した場合、次の属性を定義します。

    • カスタム信頼キーストア: 信頼キーストアへの完全修飾パス。

    • カスタム信頼キーストアのタイプ: キーストアのタイプ。一般に、この属性にはJKSを指定します。空白のままにすると、デフォルトでJKSに設定されます。

    • カスタム信頼キーストアのパスフレーズ: キーストアの読取りまたは書込み時に入力するパスワード。この属性は、キーストアのタイプに応じてオプションまたは必須になります。すべてのキーストアで、書込みにはパスフレーズが必要です。ただし、キーストアによっては読取りにパスフレーズが不要な場合もあります。WebLogic Serverは、キーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件に応じて決まります。

  10. 変更内容は自動的にアクティブ化されます。

WebLogic ServerへのSSLの構成（一方向）

一方向SSLでは、サーバーはクライアントに証明書を提示する必要がありますが、クライアントがサーバーに証明書を提示する必要はありません。

「SSLに関するキーストアの構成」の説明に従ってWebLogic Serverインスタンスのアイデンティティと信頼キーストアを構成したら、そのSSL属性を構成します。これらの属性では、「構成: キーストア」ページで指定したキーストア内のアイデンティティ鍵と証明書の場所を示します。この情報を指定するには、「構成: SSL」ページを使用します。

この項では、WebLogic ServerにSSLを構成するために必要な手順の概要を説明します。詳細は、『Securing Oracle WebLogic Server』を参照してください。

SSLを構成する手順

  1. WebLogic Server管理コンソールの左側のペインで、「環境」を開き、「サーバー」を選択します。

  2. SSLを構成するサーバーの名前をクリックします。

  3. 「構成」→「SSL」ページを選択し、WebLogic Serverのアイデンティティ（証明書と秘密鍵）と信頼（信頼できるCA）の場所を選択します。

  4. 秘密鍵の別名とパスワードのSSL属性を設定します。

  5. ページの下部で、「詳細」をクリックします。

  6. 「ホスト名の検証」を「なし」に設定します。

  7. WebLogic Serverが内部サーバーとエクスポート可能クライアントとの間で何回エクスポート可能鍵を使用したら新しい鍵を生成する必要があるか、使用できる回数を指定します。新しい鍵を生成するまでに鍵を使用する回数が少ないほど、WebLogic Serverのセキュリティが強化されます。

  8. 「相互クライアント証明書の動作」コントロールを「クライアント証明書を要求しない」に設定します。

  9. インバウンドとアウトバウンドのSSL証明書検証方法を指定します。選択できるオプションは次のとおりです。

    • 組込みSSLの検証のみ: 組込みの信頼できるCAベースの検証を使用します。これがデフォルトです。

    • 組込みSSLの検証および証明書パス検証プロバイダ: 組込みの信頼できるCAベースの検証を使用し、追加の検証を実行するために構成済のCertPathValidatorプロバイダを使用します。

WebLogic ServerへのSSLの構成（双方向）

双方向SSLでは、サーバーはクライアントに、またクライアントはサーバーに証明書を提示します。SSLハンドシェイクを完了する前に、クライアントに有効で信頼できる証明の送信を要求するようにWebLogic Serverを構成できます。

「SSLに関するキーストアの構成」の説明に従って、WebLogic Serverインスタンスのアイデンティティと信頼キーストアを構成した後、使用するポリシーまたはテンプレートで必要な場合は、「双方向SSLの構成が必要なポリシー」の説明に従って双方向SSL属性を構成できます。

この項では、WebLogic ServerにSSLを構成するために必要な手順の概要を説明します。詳細は、『Securing Oracle WebLogic Server』を参照してください。

双方向SSLの構成手順は次のとおりです。

  1. WebLogic Server管理コンソールの左側のペインで、「環境」を開き、「サーバー」を選択します。

  2. SSLを構成するサーバーの名前をクリックします。

  3. 「構成」→「SSL」ページを選択し、WebLogic Serverのアイデンティティ（証明書と秘密鍵）と信頼（信頼できるCA）の場所を選択します。

  4. 秘密鍵の別名とパスワードのSSL属性を設定します。

  5. ページの下部で、「詳細」をクリックします。

  6. 「ホスト名の検証」を「なし」に設定します。

  7. WebLogic Serverが内部サーバーとエクスポート可能クライアントとの間で何回エクスポート可能鍵を使用したら新しい鍵を生成する必要があるか、使用できる回数を指定します。新しい鍵を生成するまでに鍵を使用する回数が少ないほど、WebLogic Serverのセキュリティが強化されます。

  8. 必要に応じて、「サーバーの証明書を使用」コントロールを設定します。このコントロールを設定すると、WebLogic ServerでホストされているWebサービス・クライアントが、HTTPSを介して接続を開始するときにサーバー証明書/鍵をクライアント・アイデンティティとして使用する必要があるかどうかが決まります。

  9. 「相互クライアント証明書の動作」コントロールを「クライアント証明書を要求(強制する)」に設定します。

  10. インバウンドとアウトバウンドのSSL証明書検証方法を指定します。選択できるオプションは次のとおりです。

    • 組込みSSLの検証のみ: 組込みの信頼できるCAベースの検証を使用します。これがデフォルトです。

    • 組込みSSLの検証および証明書パス検証プロバイダ: 組込みの信頼できるCAベースの検証を使用し、追加の検証を実行するために構成済のCertPathValidatorプロバイダを使用します。

Webサービス・クライアントに関するSSLの構成

中核となるWebLogic Serverのセキュリティ・サブシステムでは、デフォルトのキーストアに格納されている秘密鍵とX.509証明書のペアをSSLに使用します。

WebLogic Serverでリクエストのデジタル署名に使用されるX.509証明書を、Webサービス・クライアントが信頼できるようにする必要があります。次のいずれかを実行します。

  1. WebLogic Serverが、信頼できる認証局から発行された、クライアントが自動的に信頼するデジタル証明書を取得するようにします。

  2. WebLogic Serverが信頼する個々の証明書をすべてリストした証明書レジストリを作成し、クライアントが登録されたこれらの証明書を信頼するようにします。

Webサービス・クライアントに関するSSLの構成手順は次のとおりです。

  1. クライアント・アプリケーションで使用するキーストアを作成します。アプリケーション・ユーザーごとに1つのクライアント・キーストアを作成することをお薦めします。

    この手順の実行には、keytoolユーティリティを使用できます。開発目的の場合、最初はkeytoolユーティリティを使用するのが最も簡単な方法です。

  2. 秘密鍵とデジタル証明書のペアを作成し、クライアント・キーストアにロードします。

    証明書の鍵が暗号化とデジタル署名の両方に使用できることを確認します。Oracleでは、鍵の長さは1024ビット以上である必要があります。

  3. クライアントのJVMに次のプロパティが設定されていることを確認します。

    • javax.net.ssl.trustStore: 信頼ストアが含まれるファイルの名前。

    • javax.net.ssl.trustStoreType: デフォルトのTrustManagerで使用するキーストア・オブジェクトのタイプ。

    • javax.net.ssl.trustStorePassword: デフォルトのTrustManagerで使用するキーストア・オブジェクトのパスワード。

Webサービス・クライアントに関する双方向SSLの構成


注意:

SOAアプリケーションが双方向SSLでのWebサービス・クライアントである場合の特定の構成手順については、Oracle Fusion Middleware管理者ガイド for Oracle SOA SuiteおよびOracle Business Process Management Suiteの双方向SSL通信のSOAコンポジット・アプリケーションの構成に関する項を参照してください。

クライアントでリクエストのデジタル署名に使用されるX.509証明書をWebLogic Serverが検証でき、WebLogic Serverがその証明書をクライアントへの応答の暗号化に使用できるようにする必要があります。次のいずれかを実行します。

  1. クライアント・アプリケーションが、信頼できる認証局から発行された、WebLogic Serverが自動的に信頼するデジタル証明書を取得するようにします。

  2. WebLogic Serverが信頼する個々の証明書をすべてリストした証明書レジストリを作成し、クライアントが登録されたこれらの証明書のいずれかを使用するようにします。

Webサービス・クライアントに関するSSLの構成手順は次のとおりです。

  1. クライアント・アプリケーションで使用するキーストアを作成します。アプリケーション・ユーザーごとに1つのクライアント・キーストアを作成することをお薦めします。

    この手順の実行には、keytoolユーティリティを使用できます。開発目的の場合、最初はkeytoolユーティリティを使用するのが最も簡単な方法です。

  2. 秘密鍵とデジタル証明書のペアを作成し、クライアント・キーストアにロードします。

    証明書の鍵が暗号化とデジタル署名の両方に使用できることを確認します。Oracleでは、鍵の長さは1024ビット以上である必要があります。

  3. クライアントのJVMに次のプロパティが設定されていることを確認します。

    • javax.net.ssl.trustStore: 信頼ストアが含まれるファイルの名前。

    • javax.net.ssl.trustStoreType: デフォルトのTrustManagerで使用するキーストア・オブジェクトのタイプ。

    • javax.net.ssl.trustStorePassword: デフォルトのTrustManagerで使用するキーストア・オブジェクトのパスワード。

    • javax.net.ssl.keyStore: キーストア・オブジェクトが含まれるファイルの名前。

    • javax.net.ssl.keyStoreType: キーストア・オブジェクトのタイプ。

    • javax.net.ssl.keyStorePassword: キーストア・オブジェクトのパスワード。

メッセージ保護に関するキーストアの設定

SOAPメッセージの署名と暗号化を行うには、最初にWebLogicドメイン用のWeb Services Managerキーストアを作成して構成する必要があります。このキーストアは、WebLogicドメイン内でSOAPメッセージの公開鍵と秘密鍵の格納に使用されます。


注意:

この章で別途説明するように、Web Services Managerランタイムでは、SSLに使用されるWebLogic Serverキーストアを使用しません。

署名と暗号化キーは、SOAPメッセージの署名、検証、暗号化、復号化に使用されます。

キーストアの構成はドメイン単位で行います。ドメイン内のすべてのWebサービスおよびWebサービス・クライアントはこのキーストアを使用します。

Web Services Managerで使用されるキーストアを設定するには、次の手順を実行します。

  1. 「Javaキーストアの作成方法」の説明に従って、keytoolを使用してJavaキーストアを作成します。

  2. ナビゲータ・ペインで「WebLogicドメイン」を開き、キーストアの構成が必要なドメインを表示します。ドメインを選択します。

  3. Fusion Middleware Controlを使用して、「WebLogicドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」をクリックします。

    ページの下部近くにある「キーストア」コントロールのプラス記号（+）をクリックして開き、「構成」をクリックします。

    図9-1に示すように、Web Services Managerの「キーストアの構成」ページが表示されます。

    図9-1 Web Services Managerの「キーストアの構成」

    図9-1の説明が続きます
    図9-1「Web Services Managerの「キーストアの構成」」の説明

  4. 「キーストア管理の構成」チェック・ボックスがまだ選択されていない場合は、選択します。

  5. 作成するキーストアのパスと名前を入力します。デフォルトのキーストア名はdefault-keystore.jksですが、変更できます。ただし、キーストアのタイプはJKSである必要があり、変更できません。

  6. キーストアのパスワードを入力して確認します。

  7. 署名と暗号化キーの別名とパスワードを入力します。パスワードを確認します。

    署名と暗号化キーの別名とパスワードによって、鍵の格納と取得に使用される文字列の別名とパスワードが定義されます。

  8. 「OK」をクリックして変更内容を送信します。

    このページのフィールドを変更した場合、変更内容を反映するにはOracle Enterprise Manager Fusion Middleware Controlを再起動する必要があります。


注意:

Oracle WSMエージェントは、キーストア名とオブジェクトをキャッシュします。キーストアの内容またはその名前を続けて変更する場合は、Oracle Enterprise Manager Fusion Middleware Controlを再起動する必要があります。

設計時のWebサービス・クライアント・キーストアの設定

クライアントのX.509トークンで必要な署名と暗号化キーを格納するには、Javaキーストア（JKS）のキーストアを作成する必要があります。鍵は、認証やデータ整合性など、様々な用途に使用されます。たとえば、次のようにします。

  • データに署名するには、署名者の秘密鍵が必要です。

  • 署名を検証するには、信頼できるCA証明書と、秘密鍵に一致する公開鍵が必要です。

  • データを暗号化するには、受信者の公開鍵が必要です。「サービス・アイデンティティ証明拡張の使用」で説明されているように、Webサービスのbase64エンコードされた公開証明書は、Webサービス・クライアントが使用するためにWSDLでパブリッシュされます。

  • データを復号化するには、公開鍵に対応する秘密鍵が必要です。

これらの信頼できる証明書、公開鍵および秘密鍵はキーストアに格納されます。次の項では、信頼できる証明書を取得できる場所と、これらのキーストアの作成および使用方法を説明します。

信頼できる証明書の取得方法

Verisign社やEntrust社のような認証局（CA）から証明書を取得し、キーストアに含めることができます。証明書を取得するには、証明書リクエストを作成してCAに送信する必要があります。CAは、証明書リクエストを認証し、リクエストに基づいてデジタル証明書を作成します。

Javaキーストアの作成および使用方法

Javaキーストア（JKS）は、Sun社によって定義された独自のキーストア形式です。鍵と証明書をJKSで作成し管理するには、keytoolユーティリティを使用します。keytoolユーティリティを使用すると、次のタスクを実行できます。

  • 公開鍵と秘密鍵のペアを作成し、他のパーティに属する公開鍵を信頼できるものとして指定し、キーストアを管理します。

  • 証明書リクエストを適切な認証局（CA）に発行し、認証局から返された証明書をインポートします。

  • 独自の公開鍵と秘密鍵のペアおよび関連する証明書を管理します。これにより、独自の鍵と証明書を使用して自分自身を他のユーザーやサービスに対して認証できます。このプロセスは自己認証と呼ばれます。また、デジタル署名を使用したデータ整合性および認証サービスにも独自の鍵と証明書を使用できます。

  • 通信するピアの公開鍵をキャッシュします。鍵は証明書の形式でキャッシュされます。

秘密鍵の作成方法と信頼できる証明書のロード方法

次の項では、keytoolユーティリティを使用してJKSを作成および管理する方法の概要を説明します。キーストアの作成方法、および秘密鍵のペアとCA証明書のロード方法を取り上げます。keytoolユーティリティのコマンドや引数の詳細は、次のWebサイト・アドレスにアクセスして参照してください。

http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/keytool.html

  1. 新しい秘密鍵と自己署名証明書を作成します。

    秘密鍵を作成するには、genKeyコマンドを使用します。既存の秘密鍵がなければ、新しい秘密鍵が作成されます。次のコマンドでは、署名アルゴリズムRSA-SHA1とtest.jksキーストアの別名テストを使用して、RSA鍵が生成されます。

    keytool -genkey -alias test -keyalg "RSA" -sigalg "SHA1withRSA" -dname "CN=test, C=US" -keystore test.jks

    keytoolユーティリティから必要な鍵とキーストアのパスワードを要求するプロンプトが表示されます。DSA鍵はサポートされていません。コマンドで、必ずパラメータ-keyalg RSAを渡してください。

  2. キーストアを表示します。

    次のコマンドでは、キーストアの内容が表示されます。キーストアのパスワードを要求するプロンプトが表示されます。

    keytool -list -v -keystore test.jks

  3. 信頼できるCA証明書をキーストアにインポートします。

    証明書のインポートには、-importコマンドを使用します。次のコマンドでは、信頼できるCA証明書がtest.jksキーストアにインポートされます。既存のキーストアがない場合、新しいキーストアが作成されます。keytoolユーティリティから必要なパスワードを要求するプロンプトが表示されます。

    keytool -import -alias aliasfortrustedcacert -trustcacerts -file trustedcafilename -keystore test.jks

  4. 証明書リクエストを生成します。

    リクエストの生成には、-certreqコマンドを使用します。次のコマンドでは、テスト別名の証明書リクエストが生成されます。CAから証明書または証明書チェーンが返されます。

    keytool -certreq -alias test -sigalg "RSAwithSHA1" -file certreq_file -storetype jks -keystore test.jks

  5. 自己署名証明書を信頼できるCA証明書で置き換えます。

    既存の自己署名証明書をCAの証明書で置き換える必要があります。これを実行するには、-importコマンドを実行します。次のコマンドでは、test.jksキーストアの信頼できるCA証明書で置き換えます。keytoolユーティリティから必要なパスワードを要求するプロンプトが表示されます。

    keytool -import -alias test -file trustedcafilename -keystore test.jks

サービス・アイデンティティ証明拡張の使用

前のリリースのOracle WSMでは、メッセージ保護ポリシーを実装したWebサービスの場合、Webサービス・クライアントはWebサービスの公開証明書をそのドメイン・レベルのキーストアに格納する必要がありました。それからクライアントはkeystore.recipient.aliasプロパティを使用して、キーストア内の証明書を識別していました。これを行うために、「構成」ページでkeystore.recipient.aliasプロパティを確認するか、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して（またはプログラムによって）、クライアントごとにプロパティをオーバーライドしていました。

このリリースのOracle WSMでは、メッセージ保護ポリシーを実装したWebサービスの場合、Webサービスのbase64エンコードされた公開証明書はWSDLでパブリッシュされます。証明書は、ポリシーがデータを暗号化または復号化するかどうかに関係なく、メッセージ保護ポリシーに含められます。

WSDLの証明書は、デフォルトではサービスの公開鍵です。これは、「メッセージ保護に関するキーストアの設定」時に指定した「暗号化鍵」によって決まります。

証明書が見つからない場合は、かわりにkeystore.recipient.aliasプロパティが使用され、以前と同様に証明書をクライアントのドメイン・レベルのキーストアに格納する必要があります。


注意:

自己署名証明書を信頼できるものにするには、クライアント側のキーストアで使用可能にする必要があります。

WSDLに含まれるホスト名検証

このリリースには、WSDLから取り出した証明書が改ざん攻撃や中間者攻撃を受けておらず、期待通りの証明書であることを確認するホスト名検証機能が含まれています。

これを行うために、Oracle WSMは、証明書内の共通名（CN）またはサブジェクトのグループ・ベース識別名（DN）がサービスのホスト名と一致していることを検証します。

この機能は、証明書のサブジェクトDNに依存します。

デフォルトでは、ホスト名検証は無効です。

サービス・アイデンティティ証明拡張およびホスト名検証の有効化または無効化

サービス・アイデンティティ証明拡張およびホスト名検証を有効化または無効化するには、Fusion Middleware Controlを使用します。

アイデンティティ拡張タブのプロパティにより、WSDLのX509資格証明をパブリッシュしてWebサービス・ポリシーを強制するかどうかを指定できます。X509資格証明をパブリッシュする必要がない場合（たとえばSSLを使用する場合など）は、デフォルト設定をオーバーライドして資格証明のパブリッシュを回避できます。また、X509をパブリッシュする場合は、ホスト名検証を無視するかどうかも指定できます。

サービス・アイデンティティ証明拡張はデフォルトで有効、ホスト名検証はデフォルトで無効です。


注意:

サービス・アイデンティティ証明拡張は、公開鍵の元となる暗号化キーを設定しません。「メッセージ保護に関するキーストアの設定」で説明されているように、最初にこのキーを指定する必要があります。

サービス・アイデンティティ証明拡張およびホスト名検証を有効化または無効化する手順

  1. 「メッセージ保護に関するキーストアの設定」で説明されているように、公開鍵の元となる暗号化キーを設定します。

    サービス側のオーバーライドを使用して暗号化キーやWebサービスのキーストアをオーバーライドする場合は、オーバーライドされるキーに対応する証明書が使用されます。

  2. ナビゲーション・ペインから、「WebLogicドメイン」を開きます。

  3. サービス・アイデンティティ証明拡張およびホスト名検証を有効化または無効化するドメインを選択します。

  4. Fusion Middleware Controlを使用して、「WebLogicドメイン」をクリックします。

  5. 「Webサービス」→「プラットフォーム・ポリシー構成」を選択します。

  6. アイデンティティ拡張タブを選択します。

  7. アイデンティティ拡張プロパティを変更するには、それを選択してから「編集」をクリックします。「プロパティの編集」ウィンドウで、「値」フィールドを編集して各プロパティのデフォルト値を変更できます。

    • wsm.ignore.identity.wsdl: クライアント側のWSDLから取得したX509証明書の使用を有効にするかどうかをドメインごとに指定します。デフォルトでは、このプロパティは有効（false）で、つまりWSDLから取得した証明書がクライアントのラインタイムで暗号化に使用されます。デフォルト設定をtrueに変更すると、X509証明書の使用を無効化できます。

    • wsm.ignore.hostname.verification: ホスト名検証機能を無効にするかどうかをドメインごとに指定します。デフォルトでは、このプロパティは無効（true）です。ただし、プロパティをfalseに設定すると、ホスト名検証を有効化できます。

  8. 既存のプロパティを削除するには、それを選択してから「削除」をクリックします。

  9. 「適用」をクリックしてプロパティの更新を適用します。

クライアントからのサービス・アイデンティティ証明拡張の無効化


注意:

クライアントがkeystore.recipient.aliasプロパティ（クライアントのプログラムによるオーバーライドではoracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_RECIPIENT_KEY_ALIAS）をオーバーライドすると、常にオーバーライドが使用され、WSDLでパブリッシュされた証明書は使用されません。

JEEクライアントの場合は、wsm.ignore.identity.wsdlプロパティの値が自動的に読み取られ、その他の構成は必要ありません。「サービス・アイデンティティ証明拡張およびホスト名検証の有効化または無効化」で説明されているように、Fusion Middleware Controlでこのプロパティを設定して、アイデンティティ検証を有効または無効にします。

JSEクライアントの場合は、Webサービス・クライアントはWSDLの証明書を無視するための明示的なアクションを行う必要があり、無視するかどうかは設定されたkeystore.recipient.aliasプロパティのみに依存します。

これを行うには、次のようにwsm.ignore.identity.wsdlの値をtrueに設定します。

BindingProvider.getRequestContext().put(SecurityConstants.ClientConstants.WSM_IGNORE_IDENTITY_WSDL, "true");

クライアントからのホスト名検証の無効化

JEEクライアントの場合は、wsm.ignore.hostname.verificationプロパティの値が自動的に読み取られ、その他の構成は必要ありません。「サービス・アイデンティティ証明拡張およびホスト名検証の有効化または無効化」で説明されているように、Fusion Middleware Controlでこのプロパティを設定して、ホスト名検証を有効または無効にします。

JSEクライアントの場合は、Webサービス・クライアントはホスト名検証を無視するための明示的なアクションを行う必要があります。

これを行うには、次のようにwsm.ignore.hostname.verificationの値をtrueに設定します。

BindingProvider.getRequestContext().put(SecurityConstants.ClientConstants.WSM_IGNORE_HOSTNAME_VERIFICATION,"false");

資格証明ストア・プロバイダの構成

資格証明ストア・プロバイダは、Webサービスやその他のアプリケーションの資格証明を格納、取得および削除する手段を提供します。

たとえば、oracle/wss_http_token_client_policyポリシーには、csf-keyプロパティが含まれており、そのデフォルト値はbasic.credentialsです。この資格証明は、資格証明ストア・プロバイダに格納されます。

資格証明ストア・プロバイダを構成するには、次の手順を実行します。

  1. ナビゲータ・ペインで「WebLogicドメイン」を開き、キーストアの構成が必要なドメインを表示します。ドメインを選択します。

  2. Fusion Middleware Controlを使用して、「WebLogicドメイン」→「セキュリティ」→「資格証明」をクリックします。

    図9-2に示すように、資格証明ストア・プロバイダの構成ページが表示されます（この図では、「資格証明ストア・プロバイダ」コントロールがすでに開かれています）。

    図9-2 資格証明ストア・プロバイダの構成ページ

    図9-2の説明が続きます
    図9-2「資格証明ストア・プロバイダの構成ページ」の説明

  3. 「マップの作成」をクリックし、図9-3に示すようにマップ名oracle.wsm.securityを入力します。

    図9-3 セキュリティ・プロバイダの設定画面

    図9-3の説明が続きます
    図9-3「セキュリティ・プロバイダの設定画面」の説明

  4. 「キーの作成」をクリックします。図9-4に示すように、「キーの作成」ダイアログ・ボックスが表示されます。

    図9-4 「キーの作成」ダイアログ・ボックス

    図9-4の説明が続きます
    図9-4「「キーの作成」ダイアログ・ボックス」の説明

  5. 選択されていない場合は、マップ名oracle.wsm.securityを選択します。

  6. キー名を入力します。

  7. キーのタイプを「パスワード」または「汎用」から選択します。パスワード資格証明には、ユーザー名とパスワードを格納できます。汎用資格証明には、資格証明オブジェクトを格納できます。

  8. パスワード資格証明の場合、ユーザー名とパスワードを入力します。

  9. 「OK」をクリックします。

  10. Fusion Middleware Controlを再起動します。

WebLogic Serverへの認証プロバイダの構成

この項では、WebLogic Serverのセキュリティ機能について説明します。この機能の詳細は、Securing Oracle WebLogic ServerおよびOracle WebLogic Server管理コンソールのヘルプで説明されています。この項では、セキュリティ機能と構成ポリシーとの関係を中心に、セキュリティ機能の概要のみを解説します。

使用するセキュリティ・ポリシーによって、WebLogic Serverに構成が必要なセキュリティ・プロバイダのタイプが決まります。ポリシーはトークンのタイプに基づいて次のようなカテゴリに分類できます。

作成が必要なWebLogicセキュリティ認証プロバイダのタイプ

NameCallbackおよびPasswordCallbackコールバック、またはNameCallbackのみで資格証明を検証できるWebLogic認証プロバイダを必要に応じて使用できます。つまり、適宜プロバイダを選択し、WebLogicのデフォルト認証プロバイダを使用して埋込みのLDAPデータストアに対してユーザーを認証したり、デフォルトのIDアサーション・プロバイダを使用したりできるということです。手順の詳細は、Oracle WebLogic Server管理コンソールのヘルプの認証プロバイダとIDアサーション・プロバイダの構成に関する項を参照してください。

SAMLおよびKerberosログイン・モジュールの構成

SAMLおよびKerberosポリシーには、ログイン・モジュールが関連付けられています。このモジュールは、ポリシーを構成するアサーションによって決まります。SAMLポリシーをWebサービスに添付する場合、ログイン・ポリシーを編集して必要な変更を加える必要があります。Kerberosログイン・モジュールの設定は、任意で構成できます。

（他のポリシー・タイプに関連付けられているログイン・モジュールには、Webサービス・ポリシーに固有の設定はありません。）

表9-1は、使用可能なログイン・モジュールとそれを使用するポリシーの一覧です。

表9-1 SAMLおよびKerberosログイン・モジュールと関連ポリシー

ログイン・モジュール・サービス名 説明 設定可能な属性と値

saml.loginmodule

SAMLログイン・モジュールは、Java Authentication and Authorization Service（JAAS）ログイン・モジュールで、SAMLアサーションを受け入れてログインを実行します。SAMLログイン・モジュールは、SAMLアサーションから作成されたプリンシパルのログイン・コンテキストを使用して、Webサービスを実行できるようにします。

発行者。SAMLトークンの発行者の名前。デフォルトはwww.oracle.comです。

krb5.loginmodule

Kerberosログイン・モジュール

principal。使用するプリンシパルの名前です。testuserのような単純なユーザー名の場合と、host/testhost.eng.sun.comのようなサービス名の場合があります。keyTabの複数のプリンシパルに対する複数の資格証明がある場合、または特定のチケット・キャッシュのみを使用する場合、使用するプリンシパルの設定にprincipalオプションを使用できます。

useKeyTab。trueまたはfalse。モジュールがkeyTabからプリンシパルの鍵を取得できるようにするには、trueに設定します（デフォルト値はfalse）。keyTabが設定されていない場合は、モジュールはKerberos構成ファイルでkeyTabを検索します。Kerberos構成ファイルに指定されていない場合は、ファイル{user.home}{file.separator}krb5.keytabを検索します。

storeKey。プリンシパルの鍵をサブジェクトの秘密資格証明に格納するには、trueに設定します。

keyTab。プリンシパルの秘密鍵を取得するには、keyTabのファイル名を設定します。

doNotPrompt。資格証明をキャッシュまたはkeyTabから取得できないときに、パスワードを要求するプロンプトを表示しない場合は、trueに設定します（デフォルト値はFalse）。trueに設定すると、資格証明をキャッシュまたはkeyTabから取得できない場合、認証は失敗します。

ログイン・モジュールを構成するには、次の手順を実行します。

  1. ナビゲータ・ペインで「WebLogicドメイン」を開き、キーストアの構成が必要なドメインを表示します。ドメインを選択します。

  2. Fusion Middleware Controlを使用して、「WebLogicドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」をクリックします。

  3. ログイン・モジュールのリストから、ログイン・モジュールを選択し、「編集」をクリックします。

  4. ログイン・モジュールの特定の属性またはカスタム・プロパティを構成します。

SAMLの構成

SAML標準では、Web上のソフトウェア・エンティティ間のセキュリティ・アサーションを作成、要求および交換するための共通のXMLフレームワークが定義されています。SAMLトークン・プロファイルは、WS-Security標準のコア・セットの一部であり、WebサービスのセキュリティのためにSAMLアサーションを使用する方法が指定されています。SAMLでは、ビジネス・プロセスまたはトランザクションの複数のステップ間で、ブラウザからポータル、Webサービスのネットワークへと渡すことのできるセキュリティ・トークンを表す標準的な方法も提供されます。

次の事前定義済ポリシーを使用する場合は、SAMLを構成する必要があります。

SAMLトークンの検証方法

SAMLログイン・モジュールは、Webサービスに代わってSAMLトークンを検証します。次に、SAMLログイン・モジュールは、検証されたトークンからユーザー名を抽出し、NameCallbackを介してOracle Platform Security Services（OPSS）に（間接的に）渡します。

使用される認証プロバイダ

NameCallbackを処理する構成済の認証プロバイダ（IDアサーション・プロバイダ）をここで呼び出すことができます。

認証プロバイダは、ユーザーが存在するかどうかのみを確認します（IDアサーション・モード）。存在する場合、ユーザーはアサートされ、サブジェクトが確立します。

設計時のSAML Webサービス・クライアントの設定

設計時にSAML Webサービス・クライアントを構成するには、この項で説明する手順を実行します（デプロイ時にWebサービス・クライアントにSAMLポリシーを添付する場合、これらのプロパティは構成が不要で、Fusion Middleware Controlに表示されることもありません）。

これ以降の項で説明するように、ユーザー・ロールをアサーションに含め、SAMLアサーション発行者名を変更することもできます。

SAMLアサーションのユーザー名の構成

JSEクライアント・アプリケーションの場合、次のようにユーザー名をBindingProviderプロパティとして構成します。

Map<String,Object>  reqContext = ((BindingProvider) proxy).getRequestContext()   reqContext.put( BindingProvider.USERNAME_PROPERTY, "jdoe")

ここで、proxyは、実際のWebサービスの起動に使用されるWebサービス・プロキシを示します。

JEEクライアントの場合は、ユーザーが認証済で、サブジェクトがコンテナ内で確立されていれば、ユーザー名はサブジェクトから自動的に取得されるため、追加の構成は必要ありません。

たとえば、ユーザーjdoeがすでにJEEアプリケーションに対して認証され、JEEアプリケーションからWebサービス・コールを行う場合、ユーザー名jdoeは自動的に伝播されます。

ただし、ユーザーが認証されていない場合、JSEと同様にBindingProviderにユーザー名を構成する必要があります。

アサーションへのユーザー・ロールの組込み

ユーザーのロールをSAMLアサーションの属性文として渡すことができます。デプロイ後にこれを実行するには、user.role.includeプロパティをtrueに構成します。ポリシー内のデフォルト値はfalseです。

設計時にユーザーのロールを構成するには、BindingProviderのuser.role.includeプロパティをtrueに設定します。

SAMLポリシーに関するOracle Platform Security Services（OPSS）の構成方法

事前定義済SAMLポリシーに関してOPSSを構成するには、次の手順を実行します。

  1. 「SAMLおよびKerberosログイン・モジュールの構成」の説明に従って、SAMLログイン・モジュールを構成します。

    デフォルトでは、SAMLアサーション発行者名はwww.oracle.comです。Webサービス・クライアントとWebサービス側の両方で事前定義済SAMLポリシー（またはアサーション）を使用している場合、saml.issuer.nameプロパティはwww.oracle.comである必要があります。このため、通常はデフォルト値を使用でき、発行者の構成は不要です。

    別の発行者名を使用するには、図9-5に示すように、「追加」をクリックして追加の発行者名を追加します。

    図9-5 SAML発行者のログイン・モジュールへの追加

    図9-5の説明が続きます
    「図9-5 SAML発行者のログイン・モジュールへの追加」の説明

  2. IDアサーション・プロバイダをWebLogic Server管理コンソールで構成します。

  3. SAML鍵所有者ポリシーなど、SAMLアサーションに関連する署名が含まれるポリシー（アサーションから参照される鍵がメッセージの署名に使用される）、または送信者保証ポリシー（送信者の鍵がメッセージの署名に使用される）を使用する場合、「メッセージ保護に関するキーストアの設定」の説明に従って、署名と検証のための鍵と証明書を構成する必要があります。

  4. SSLが必要なポリシーを使用する場合、「SSLに関するキーストアの構成」の説明に従ってSSLを構成する必要があります。

別のSAMLアサーション発行者名の追加

Webサービス・クライアント側とWebサービス側の両方で事前定義済SAMLポリシー（またはアサーション）が使用されている場合は、saml.issuer.nameプロパティは通常www.oracle.comです。そのため、通常はデフォルト値を使用でき、発行者は構成しません。NET/WLSなどの異なるクライアントが事前定義済SAMLポリシーで保護されているWebサービスと通信する場合、または異なるSAML発行者を使用する必要がある場合は、別の発行者名を追加する必要があります。

別のSAMLアサーション発行者名を追加する手順

  1. 「SAMLおよびKerberosログイン・モジュールの構成」の説明に従って、SAMLログイン・モジュールを構成します。別の発行者名を追加するには、図9-5に示すように、「追加」をクリックします。

  2. デプロイ時に、SAMLクライアント・ポリシーの「構成」ページでsaml.issuer.nameの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。ポリシーのデフォルト値はwww.oracle.comです。

    設計時に発行者を構成するには、BindingProviderのsaml.issuer.nameプロパティを設定します。

アイデンティティ切替えのためのSAML Webサービス・クライアントの構成

Oracle WSMには、アイデンティティ切替えを有効にするwss11_saml_token_identity_switch_with_message_protection_client_policyポリシーが含まれます。アイデンティティ切替えとは、ポリシーが、認証されたサブジェクトに基づいたアイデンティティとは異なるアイデンティティを伝播することを意味します。

SOAアプリケーションではクライアント側のWebサービス・ポリシーで使用されるユーザー・アイデンティティを指定する必要があり、アウトバウンドWebサービス・リクエストでSAMLトークンに関連するユーザーに動的に切替えるシナリオが考えられます。このポリシーにより、サブジェクトから取得したユーザー名を使用するかわりに、SAML Webサービス・リクエストの送信時に新しいユーザー名を設定できます。

wss11_saml_token_identity_switch_with_message_protection_client_policyポリシーは、プロパティjavax.xml.ws.security.auth.usernameを介してユーザーIDセットに基づいてSAMLトークンを作成します。

Webサービス・クライアントがSOAアプリケーションを呼び出し、SOAアプリケーションがWebサービスのクライアントとなる次のようなユースケースについて検討します。

client -> SOA -> web service

このユースケースでは、次のようになります。

  • クライアントは、wss11_username_with_message_protection_client_policyポリシーを使用して安全性を確保します。これはユーザーend_user1としてSOAエントリ・ポイントと通信します。

  • SOAエントリ・ポイントは、wss11_username_with_message_protection_service_policyによって保護されます。SOAアプリケーションはエンド・ユーザーを認証し、end_user1に基づいてサブジェクトを確立します。ただし、外部Webサービスには別のアイデンティティを伝播することが求められます。

    そのため、アイデンティティ切替えを行うために、wss11_saml_identity_switch_message_protection_client_policyポリシーをSOA参照のバインディング・コンポーネントに添付します。

  • 伝播されるユーザー名は、SOAアプリケーションのコンポーネントであるBPELプロセスによって動的に決定されます。ユーザー名は、動的に決定されたユーザー名の値を含むBPELプロパティjavax.xml.ws.security.auth.usernameとして設定されます。外部Webサービスは、wss11_saml_with_message_protection_service_policyによって保護できます。これで、end_user1ではなく、切り替わったユーザーを受け取ります。

  • エンド・ユーザーに基づいてサブジェクトを確立するが、別のアイデンティティを伝播する必要があるJ2EEアプリケーションにも、同様のシナリオが適用できます（このシナリオのSOAをJ2EEアプリケーションに置き換えます）。J2EEの場合は、次のようにユーザー名をプログラムによって設定できます。

    ((BindingProvider) port).getRequestContext().put(BindingProvider.USERNAME_PROPERTY, config.get(USERNAME));

  • Fusion Middleware Controlを使用して、WSIdentityPermission権限をSOA参照バインディング・コンポーネントに追加します。

    wss11_saml_token_identity_switch_with_message_protection_client_policyポリシーでは、このポリシーを添付するアプリケーションがWSIdentityPermission権限を持つことが要求されます。つまり、Oracle WSMが外部から提供されるアイデンティティをアプリケーションから受け入れるには、そのアプリケーションがWSIdentityPermission権限を持つ必要があります。

    これにより、Oracle WSMが潜在的に悪質なアプリケーションからアイデンティティを提供されるのを回避します。


注意:

wss11_saml_token_identity_switch_with_message_protection_client_policyポリシーは、同じサーバー上でのSOA間のやり取りに対して、ローカルの最適化を無効にします（「ポリシーに対するローカルの最適化の構成」を参照）。

このポリシーは、Webサービスのwss11_saml_token_with_message_protection_service_policyポリシーと互換性があります。

javax.xml.ws.security.auth.usernameプロパティの設定

SOAの場合:

SOAコンポジットは、1つのSOAサービス・コンポーネントとしてBPELプロセスを持ちます。BPELプロセスは、同期および非同期プロセスのプロセス編成と格納を行います。

BPELプロパティは、正確な名前javax.xml.ws.security.auth.usernameを使用して定義できます。このプロパティの値を、SOAアプリケーションが伝播するアイデンティティにすることができます。これは潜在的にBPELプロセスによって動的に決定できます。

J2EEの場合:

BindingProvider.USERNAME_PROPERTYプロパティを設定します。

WSIdentityPermission権限の設定

wss11_saml_token_identity_switch_with_message_protection_client_policyポリシーを添付するWebサービス・クライアント（たとえば、SOA参照バインディング・コンポーネント）は、oracle.wsm.security.WSIdentityPermission権限を持つ必要があります。

次のように、Fusion Middleware Controlを使用して、oracle.wsm.security.WSIdentityPermission権限をSOA参照バインディング・コンポーネントにシステム権限として追加します。

  1. ナビゲータ・ペインで「WebLogicドメイン」を開き、アプリケーションの構成が必要なドメインを表示します。ドメインを選択します。

  2. Fusion Middleware Controlを使用して、「WebLogicドメイン」→「セキュリティ」→「セキュリティ・ポリシー」をクリックします。システム・ポリシーは、現在のWebLogicドメインにデプロイされるすべてのアプリケーションに適用されるシステム全体のポリシーです。

  3. 「システム・ポリシー」ページで、「権限」フィールドの矢印アイコンを選択し、システム・セキュリティ権限を検索します。

  4. コードベース権限のいずれかを選択して開始点として使用し、「類似作成」をクリックします。

  5. ページの権限の詳細セクションで、「コードベース」フィールドにfile:${common.components.home}/modules/oracle.wsm.agent.common_11.1.1/wsm-agent-core.jarと入力します。

  6. ページの「権限」セクションで、開始点の権限クラスを選択して「編集」をクリックします。

  7. 「権限クラス」フィールドにoracle.wsm.security.WSIdentityPermissionと入力します。リソース名はSOAのコンポジット名で、J2EEクライアントのアプリケーション名です。図9-6に示すように、アクションは常にassertです。

    図9-6 WSIdentityPermissionの追加

    図9-6の説明が続きます
    「図9-6 WSIdentityPermissionの追加」の説明

Kerberosトークンの使用

Oracle Fusion Middleware 11gリリース1（11.1.1）では、次に示す事前定義済のポリシーとともに、Kerberosトークンもサポートされています。

また、次のアサーション・テンプレートを使用して、ポリシーを作成することもできます。

これらのアサーションおよびポリシーの詳細は、付録C「事前定義済アサーション・テンプレート」および付録B「事前定義済ポリシー」を参照してください。

KDCの構成

この項に記載されている手順に従って、Key Distribution Center（KDC）をWebサービス・クライアントとWebサービスで使用できるように構成します。

Microsoft Active DirectoryをKDCとともに使用することもできます。「Active DirectoryのKerberosおよびメッセージ保護との使用」を参照してください。

KDCの初期化と起動

KDCデータベースを初期化します。たとえば、UNIXでは次のコマンドをルートとして実行する場合があります。ここで、oracle.comはデフォルトのレルムです。

root# /usr/kerberos/sbin/kdb5_util -r oracle.com -s

kerberosサービス・プロセスを起動します。たとえば、UNIXでは次のコマンドをルートとして実行します。

root# /usr/kerberos/sbin/krb5kdc &
root# /usr/kerberos/sbin/kadmind &

プリンシパルの作成

KDCユーザー・レジストリに2つのアカウントを作成します。最初のアカウントは、エンド・ユーザー用のもの、つまりWebサービス・クライアント・プリンシパルです。2つ目のアカウントは、Webサービス・プリンシパル用のものです。

これらのアカウントを作成する方法には、kadmin.localツールを使用する方法があります。このツールは通常、MIT KDCの配布に含まれています。たとえば、次のようにします。

>sudo su - # become root
>cd /usr/kerberos/sbin/kadmin.local
>kadmin.local>addprinc fmwadmin -pw welcome1
>kadmin.local> addprinc SOAP/myhost.oracle.com -randkey
>kadmin.local>listprincs # to see the added principals

この例のWebサービス・プリンシパル名（SOAP/myhost.oracle.com）は、ランダム・パスワードを使用して作成されています。Webサービス・プリンシパルは、キー表（サービス・プリンシパル名とキーを格納するファイル）を使用して、Kerberosシステムにログインします。ランダム・パスワードを使用することにより、セキュリティが強化されます。

正しいKDCを使用するためのWebサービス・クライアントの構成

Webサービス・クライアントは、正しいKDCに対して認証するように構成する必要があります。

KDCの構成は、UNIXホストの場合は/etc/krb5.confに存在し、Windowsホストの場合はC:\windows\krb5.iniに存在します。

例9-1に、サンプルのkrb5.confを示します。次の事項に注意してください。

  • ファイルは、Kerberosランタイムに対して、操作のレルムと接続先のKDCエンドポイントを通知します。

  • Kerberosトークン・ポリシーが動作するためには、このファイルのlibdefaultsセクションで、次の3つの追加プロパティが指定されている必要があります。

    • default_tkt_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc

    • default_tgs_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc

    • permitted_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc

  • 暗号スイートの順序は重要です。Keberosメッセージ保護が動作するためには、リストの先頭がdes3-cbc-sha1になっている必要があります。これは、Oracle WSMでは暗号化アルゴリズムTripleDESがサポートされていますが、プレーンDESはサポートされていないためです。

例9-1 サンプルのkrb5.confファイル

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
 
[libdefaults]
default_realm = oracle.com
dns_lookup_realm = false
dns_lookup_kdc = false
default_tkt_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc
default_tgs_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc
permitted_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc
 
[realms]
oracle.com =
{kdc = someadminserver.com:88  admin_server = someadminserver.com:749   
 
 
default_domain = us.oracle.com  }
[domain_realm]
us.oracle.com = oracle.com
 
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf
 
[appdefaults]
pam =
{   debug = false    ticket_lifetime = 36000   renew_lifetime = 36000    
 
 
forwardable = true    krb4_convert = false  }

Webサービス・クライアントでのサービス・プリンシパル名の設定

Kerberosクライアント側ポリシーを実行するWebサービス・クライアントは、アクセスを試行するサービスのサービス・プリンシパル名を認識している必要があります。サービス・プリンシパル名の設定は、「プリンシパルの作成」で行います。

「構成」ページでservice.principal.nameの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。デフォルト（プレースホルダ）値は、HOST/localhost@oracle.comです。

設計時のWebサービス・クライアントでのサービス・プリンシパル名の設定

Kerberosクライアント側ポリシーを実行するWebサービス・クライアントは、アクセスを試行するサービスのサービス・プリンシパル名を認識している必要があります。サービス・プリンシパル名の設定は、「プリンシパルの作成」で行います。

設計時に構成のオーバーライドを使用し、次のようにサービス・プリンシパル名を指定します。

JAX-WS Clients: 
((BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSSEC_KERBEROS_SERVICE_PRINCIPAL, 
SOAP/myhost.oracle.com@oracle.com);

正しいKDCを使用するためのWebサービスの構成

正しいKDCに対してWebサービスを認証するように構成します。KDCの構成は、UNIXホストの場合は/etc/krb5.confに存在し、Windowsホストの場合はC:\windows\krb5.iniに存在します。

例9-1に、Webサービス・クライアント用のサンプルのKDC構成を示します。この例は、WebサービスのKDC構成にも適用されます。

Enterprise Managerでの正しいkeytabファイルの使用方法

正しいkeytabファイルを使用するには、次の作業を行います。

  • keytabファイルの抽出とインストール

  • krb5ログイン・モジュールの変更

これらの作業は、後続の項で説明されています。

keytabファイルの抽出とエクスポート

KDCからサービス・プリンシパル・アカウントのキー表ファイル（キー・タブとも呼ばれる）を抽出し、Webサービス実装のホストとなるマシンにインストールします。

たとえば、kadmin.localなどのツールを使用し、次のようにサービス・プリンシパル名のキー・タブを抽出できます。

>kadmin.local>ktadd -k /tmp/krb5.keytab SOAP/myhost.oracle.com

keytabファイルを、Webサービスのホストとなるマシンにエクスポートします。キー・タブはバイナリ・ファイルです。これをFTPで転送する場合は、バイナリ・モードを使用してください。

keytabファイルを使用するためのkrb5ログイン・モジュールの変更

「Configuring the SAML and Kerberos Login Modules」の説明に従って、WebサービスのKDCファイルの場所を識別するようにkrb5ログイン・モジュールを変更します。

たとえば、keytabファイルが/scratch/myhome/krb5.keytabにインストールされているとします。キー・タブとプリンシパルのプロパティを次のように変更します。

  • principal value=SOAP/myhost.oracle.com@oracle.com

  • useKeyTab value=true

  • storeKey value=true

  • keyTab value=/scratch/myhome/krb5.keytab

  • doNotPrompt value=true

サービス・プリンシパルに対応するユーザーの認証

Webサービス・ランタイムでは、Kerberosトークンの妥当性を確認できる必要があります。

トークンが有効の場合、Oracle Platform Security Services（OPSS）は、サービス・プリンシパルに対応するユーザーを、構成済のWebLogic Server認証プロバイダのいずれかに対して認証できる必要があります（認証プロバイダは、「WebLogic Serverへの認証プロバイダの構成」で説明されています）。

そのため、ユーザーは、認証プロバイダで使用されるアイデンティティ・ストアに存在し、有効になっている必要があります。

たとえば、SOAP/myhost.oracle.com@oracle.comなどのサービス・プリンシパルについて考えます。この例では、SOAP/myhost.oracle.comという名前のユーザーがアイデンティティ・ストアに存在する必要があります。@domainは、ユーザー・エンティティに含めないでください。

Webサービス・クライアントのチケット・キャッシュの作成

Webサービス・クライアントのチケット・キャッシュを作成するには、次の手順を実行します。

  1. クライアント用に作成したユーザー・プリンシパルを使用して、Kerberosシステムにログインします。

    >kinit fmwadmin welcome1

  2. これにより、チケット認可チケットを含むファイルシステムにチケット・キャッシュが作成されます。このことを確認するには、次のコマンドを入力します。

    >klist -e

    次のような情報が表示されます。

    Credentials cache: /tmp/krb5cc_36687
Default principal: fmwadmin@oracle.com, 1 entry found.
[1]  Service Principal:  krbtgt/oracle.com@oracle.com
     Valid starting:  Sep 28, 2007 17:20
     Expires:         Sep 29, 2007 17:20
         Encryption type: DES3 CBC mode with SHA1-KD

    暗号化タイプが前述の情報を反映していることを確認します。

  3. Webサービス・クライアントを実行します。

別の方法として、最初にKerberosにログインすることなく、Webサービス・クライアントを実行することもできます。Kerberosユーザー名とパスワードの入力を求められます。この場合、チケット・キャッシュはファイルシステムに作成されず、メモリーに保持されます。

Active DirectoryのKerberosおよびメッセージ保護との使用

Microsoft Active DirectoryをKey Distribution Center（KDC）とともに使用することもできます。この項では、Active DirectoryをKerberosとメッセージ保護とともに使用する場合のKDCの構成方法について説明します。

この項では、Active Directoryに習熟していることを前提として説明します。詳細については、Active Directoryのドキュメントを参照してください。

Webサービス・クライアントの設定

この項では、次のタスクについて説明します。

ユーザー・アカウントの作成

Active Directoryを使用してユーザー・アカウントを新規作成します。DES暗号化は使用しないでください。デフォルトでは、ユーザー・アカウントはRC4-HMACを使用して作成されます。

たとえば、ユーザーtestpolをユーザー・ログオン名test/testpolで作成できます。

ユーザー・ログオン名は、container/nameの形式にする必要があります。アカウントは任意のコンテナに作成できます。

Keytabファイルの作成

ktpassを使用してkeytabファイルを作成します。

ktpass -princ test/testpol@{domain} -pass {...}  -mapuser testpol -out
 testpol.keytab -ptype KRB5_NT_PRINCIPAL  -target {domain}

ここで、test/testpolはサービス・プリンシパル名で、ユーザーtestpolにマッピングされています。/desonlyまたはcyrptoをdes-cbc-crcとして設定しないでください。

サービス・プリンシパル名の設定

setSpnを使用して、サービス・プリンシパル名をユーザーにマッピングします。

setSpn -A test/testpol testpol
setSpn -L testpol (this should display the availabel mapping)

ユーザーにマッピングするサービス・プリンシパル名は1つのみにする必要があります。ユーザーにマッピングされたサービス・プリンシパル名が複数ある場合は、setSpn -D <spname> <username>を使用して削除します。

Webサービスの設定

次の手順を実行して、Webサービスを設定します。

  1. KerberosポリシーをWebサービスに添付します。

  2. 正しいKDCに対してWebサービスを認証するように構成します。

    KDCの構成は、UNIXホストの場合は/etc/krb5.confに存在し、Windowsホストの場合はC:\windows\krb5.iniに存在します。

    デフォルトのドメインとレルムをkrb5.confまたはkrb5.iniファイルで構成します。RC4-HMAC暗号化タイプを有効にします（JDK6で使用可能）。

    [libdefaults]
 
default_tkt_enctypes = rc4-hmac
default_tgs_enctypes = rc4-hmac
permitted_enctypes = rc4-hmac

  3. 「Keytabファイルの作成」で作成したkeytabファイルを、Webサービスのホストとなるシステムにエクスポートします。キー・タブはバイナリ・ファイルです。これをFTPで転送する場合は、バイナリ・モードを使用してください。

  4. 次のように、kinitを使用してkeytabファイルを検証します。

    kinit -k -t <absolute path the the keytab file> <Service Principal Name>

  5. 「SAMLおよびKerberosログイン・モジュールの構成」の説明に従って、krb5ログイン・モジュールを変更し、keytabの場所とサービス・プリンシパル名を指定します。

    keytabファイルへの絶対パスを使用してください。また、サービス・プリンシパル名には必ず@realmnameを追加してください。たとえば、次のようにします。

    principal value=test/testpol@oracle.com

SAMLメッセージ保護のユースケース

Webサービス・クライアントをwss11_saml_token_with_message_protection_client_policy policyで保護し、対応するWebサービスをwss11_saml_token_with_message_protection_service_policy policyで保護すると仮定します。

この項では、この2つのポリシーを使用して手順を説明します。

次の項目について説明します。

必要知識

この項では、このSAMLメッセージ保護のユースケースを構成するために必要となる知識について説明します。次の項目について説明します。

wss11_saml_token_with_message_protection_service_policyポリシーの要件

wss11_saml_token_with_message_protection_service_policyは、WS-Security 1.1標準に従って、インバウンドSOAPリクエストに対して、メッセージ・レベルの保護（つまり、メッセージ整合性とメッセージの機密保護）とSAMLベースの認証を行います。

メッセージは、WS-Securityの対称鍵テクノロジのBasic 128スイートを使用して保護されます。具体的には、メッセージ機密保護にはRSA鍵メカニズム、メッセージ整合性にはSHA-1ハッシュ・アルゴリズムが使用され、AES-128ビット暗号化も使用されます。メッセージ保護に使用できるアルゴリズムの詳細は、「サポートされているアルゴリズム・スイート」を参照してください。

そのため、キーツール（またはその他のツール）を使用してこのポリシーに必要な署名や暗号化キーを作成する場合は、必ずRSA鍵メカニズム、SHA-1アルゴリズム、そしてAES-128ビット暗号化を使用して、キーのポリシー要件を満たす必要があります。

対称鍵によるメッセージ保護の方法

このポリシーは対称鍵テクノロジを使用しています。対称鍵暗号は、次のような単一の共有の秘密鍵に依存します。

  1. クライアントは、対称鍵を作成し、それを使用して署名してメッセージを暗号化し、そしてリクエスト・メッセージでWebサービスとそれを共有します。

    対称鍵を保護するために、リクエスト・メッセージで送信された対称鍵は、サービスの証明書を使用して暗号化されます。

  2. Webサービスはリクエスト・メッセージ内の対称鍵を使用して、リクエスト・メッセージの署名を検証してそれを復号化し、それからレスポンス・メッセージに署名して暗号化します。

次のプロセス・フローを考慮します。

リクエストを作成するために、Oracle WSMエージェントは次のことを行います。

  1. 共有の対称鍵を生成し、それを使用してリクエスト・メッセージの署名と暗号化の両方を行います。

  2. その独自の秘密鍵を使用して、リクエスト・メッセージの署名を裏書きします。

  3. Webサービスの公開鍵を使用して、対称鍵を暗号化します。

  4. 対称鍵をリクエストとともにWebサービスに送信します。クライアントはリクエストで公開鍵を送信して、Webサービスがその署名を検証できるようにします。

Webサービスがリクエストを受け取ると、次のことを行います。

  1. 秘密鍵を使用して、対称鍵を復号化します。

  2. 対称鍵を使用して、リクエスト・メッセージを復号化し、その署名を検証します。

  3. リクエスト・メッセージ内のクライアントの公開鍵を使用して、その裏書署名を検証します。

クライアントにレスポンスを送信するために、Webサービスは次のことを行います。

  1. リクエストとともに送信されたクライアントが生成した同じ対称鍵を使用して、レスポンス・メッセージに署名します。

  2. クライアントが生成した同じ対称鍵を使用して、レスポンス・メッセージを暗号化します。

Oracle WSMエージェントはレスポンス・メッセージを受け取ると、次のことを行います。

  1. 最初に生成した対称鍵を使用して、レスポンス・メッセージを復号化します。

  2. 最初に生成した対称鍵を使用して、レスポンス・メッセージの署名を検証します。

キーストアに必要なキー

クライアントとWebサーバーが、同じキーストアにアクセスする同じドメインにある場合は、同じ秘密/公開鍵のペアを共有できます。

つまり、クライアントが秘密鍵"orakey"を使用してリクエスト・メッセージの署名を裏書きし、公開鍵"orakey"を使用して対称鍵を暗号化できます。次に、Webサービスが公開鍵"orakey"を使用して裏書きを検証し、秘密鍵"orakey"を使用して対称鍵を復号化します。

デモの目的で、このユースケースでは1つの鍵ペアを作成します。

マルチドメインのユースケース（キーストアの強化）

クライアントとWebサーバーが同じドメインになく、同じキーストアにアクセスしない場合は、クライアントとWebサービスは各自が秘密/公開鍵のペアを持つ必要があります。

表9-2に示すように、マルチドメインのユースケースで次の要件について考慮します。

表9-2 マルチドメインのユースケース要件

Webサービス・クライアント Webサービス

クライアントのキーストアに独自の秘密/公開鍵のペアが必要です。

サービス・キーストアに独自の秘密/公開鍵のペアが必要です。

Webサービスの公開鍵が必要です。

クライアントのキーストア内の公開鍵に対応する中間証明書とルート証明書が必要です。

これらの証明書を使用して、信頼される証明チェーンを生成して署名を検証します。

ランタイム時に対称鍵を生成

対称鍵が必要ですが、これはリクエスト・メッセージで送信されます。

クライアントが対称鍵を暗号化するために使用する公開鍵、つまりWebサービスの公開鍵については、次の2つのアプローチがあります。

  • 「サービス・アイデンティティ証明拡張の使用」で説明されているように、Webサービスのbase64エンコードされた公開証明書は、Webサービス・クライアントが使用するためにWSDLでパブリッシュされます。そのため、この使用方法では、Webサービスの公開鍵はクライアントのキーストアになくても構いません。

  • 別の方法として、「構成」ページでkeystore.recipient.aliasの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。キーストア受信者の別名は、アウトバウンドSOAPメッセージの暗号化用のキーを取得するときにキーストア内の公開鍵を検索するために使用される別名を指定します。この使用方法では、Webサービスの公開鍵はクライアントのキーストアにある必要があります。

SAML発行者をオーバーライドするタイミング

クライアント・ポリシーのsaml.issuer.nameプロパティは、SAMLトークンの発行者とwww.oracle.comの値のデフォルトを特定します。このユースケースでは、www.oracle.comデフォルトを使用します。

オプションで、「構成」ページでsaml.issuer.nameの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。

ポリシーで別のSAML認証局（発行者）を使用する場合は、その発行者名をクライアントで構成し、SAMLログイン・モジュール内の使用可能な発行者のリストに含める必要があります。この方法については、「別のSAMLアサーション発行者名の追加」を参照してください。

メイン手順

この項では、SAMLメッセージ保護のユースケースを構成する手順について説明します。次の項目について説明します。

WebLogic Serverユーザーの作成

SAMLトークン内のユーザーは、WebLogic Serverアイデンティティ・ストアにすでに存在している必要があります。

Webサービスのランタイムは、WS-SecurityヘッダーからSAMLトークンを抽出し、SAMLトークン内の名前を使用してWebLogic Serverアイデンティティ・ストアに対してユーザーを検証します。

特に、SAMLログイン・モジュール（「SAMLおよびKerberosログイン・モジュールの構成」を参照）では、WebサービスのかわりにSAMLトークンが検証されます。次に、SAMLログイン・モジュールは、検証されたトークンからユーザー名を抽出し、NameCallbackを介してOracle Platform Security Services（OPSS）に（間接的に）渡します。

デフォルトの認証プロバイダなど、JAAS NameCallbackを処理する構成済のWebLogic Server認証プロバイダ（IDアサーション・プロバイダ）をここで呼び出すことができます。

WebLogic認証プロバイダは、ユーザーが存在するかどうかのみを確認します（IDアサーション・モード）。存在する場合、ユーザーはアサートされ、サブジェクトが確立します。

ユーザーの作成

Oracle WebLogic Server管理コンソールのヘルプで説明されているように、WebLogic Server管理コンソールを使用して、ユーザーをアイデンティティ・ストアに追加します。

便宜のために、ここにも手順を掲載します。

WebLogic Server管理コンソールでユーザーを作成する手順

  1. 左側のペインで、「セキュリティ・レルム」を選択します。

  2. 「セキュリティ・レルム」ページの「サマリー」で、レルムの名前を選択します（たとえば、myrealm）。

  3. 「レルム名」ページの「設定」で、「ユーザーとグループ」→「ユーザー」を選択します。

    「ユーザー」表に、管理プロバイダで定義されているすべてのユーザーの名前が表示されます。

  4. 「新規」をクリックします。

  5. 「新規ユーザーの作成」ページの「名前」フィールドに、ユーザーの名前を入力します。

    ユーザー名は大文字と小文字が区別され、一意である必要があります。カンマ、タブ、および次の「、」で区切ったリストの文字は使用しないでください。<>、#、|、&、?、( )、{ }

  6. （オプション）「説明」フィールドに説明を入力します。説明は、ユーザーの完全な名前にします。

  7. 「プロバイダ」ドロップダウン・リストで、ユーザーの認証プロバイダを選択します。

    セキュリティ・レルムに複数のWebLogic認証プロバイダが構成されている場合は、それらがリストに表示されます。新規ユーザーの情報を格納するWebLogic認証プロバイダのデータベースを選択します。

  8. 「パスワード」フィールドに、ユーザーのパスワードを入力します。

    WebLogic認証プロバイダで定義されるユーザーの最大パスワード長は8文字です。

  9. 「パスワードの確認」フィールドにユーザーのパスワードを再入力します。

  10. 「OK」をクリックして変更内容を保存します。

    ユーザー名が「ユーザー」表に表示されます。

Javaキーストアの作成

この項では、keytoolユーティリティを使用してJavaキーストアを作成および管理する方法の概要を説明します。キーストアの作成方法、および秘密鍵のペアとCA証明書のロード方法を取り上げます。

keytoolユーティリティのコマンドや引数の詳細は、次のWebサイトを参照してください。http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/keytool.html


注意:

-genkeyコマンドを使用してエンティティをキーストアに追加してキーペア（公開鍵と秘密鍵）を生成する場合、または-importコマンドを使用して証明書または証明書チェーンを信頼できる証明書のリストに追加する場合は、別名を指定します。

その後のkeytoolコマンドでは、この同じ別名を使用してエンティティを参照する必要があります。

  1. 新しいキー・ペアと自己署名証明書を作成します。

    genKeyコマンドを使用してキー・ペア（公開鍵と秘密鍵）を作成します。秘密鍵が存在しない場合、genKeyは新しい秘密鍵を作成します。

    次のコマンドでは、署名アルゴリズムRSA-SHA1とdefault-keystore.jksキーストアの別名「orakey」を使用して、RSA鍵が生成されます。任意の別名を選択できます。別名を「orakey」にする必要はありません。

    keytool -genkey -alias orakey -keyalg "RSA" -sigalg "SHA1withRSA"-dname "CN=test, C=US" -keystore default-keystore.jks

    keytoolユーティリティから必要な鍵とキーストアのパスワードを要求するプロンプトが表示されます。これらのパスワードは後で必要になります。

  2. 認証局への証明書リクエストを生成します。

    リクエストの生成には、-certreqコマンドを使用します。次のコマンドでは、orakey別名の証明書リクエストが生成されます。

    CAから証明書または証明書チェーンが返されます。

    keytool -certreq -alias orakey -sigalg "RSAwithSHA1" -file certreq_file -storetype jks -keystore client-default-keystore.jks

  3. 自己署名証明書を信頼できるCA証明書で置き換えます（インポートします）。

    既存の自己署名証明書をCAから返される証明書で置き換える必要があります。これを実行するには、-importコマンドを実行します。次のコマンドでは、default-keystore.jksキーストアの信頼できるCA証明書で置き換えます。keytoolユーティリティから必要なパスワードを要求するプロンプトが表示されます。

    keytool -import -alias orakey -file trustedcafilename -keystore default-keystore.jks

Web Services Managerキーストアの構成

次の手順を実行して、Oracle Web Services Managerキーストアを構成します。

  1. ナビゲータ・ペインで「WebLogicドメイン」を開き、キーストアの構成が必要なドメインを表示します。ドメインを選択します。

  2. Fusion Middleware Controlを使用して、「WebLogicドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」をクリックします。

    ページの下部近くにある「キーストア」コントロールのプラス記号（+）をクリックして開き、「構成」をクリックします。

    図9-1に示すように、Web Services Managerの「キーストアの構成」ページが表示されます。

  3. 「キーストア管理の構成」チェック・ボックスがまだ選択されていない場合は、選択します。

  4. 作成するキーストアのパスと名前を入力します。デフォルトのキーストア名は、このユースケースで使用したように、default-keystore.jksです。キーストア・タイプはJKSにする必要があります。

  5. キーストアのパスワードを入力して確認します。

  6. 署名と暗号化キーの別名とパスワードを入力します。

    このユースケースでは、orakeyは署名と暗号化キーの両方の別名です。

    パスワードを確認します。

  7. 「OK」をクリックして変更内容を送信します。

    このページのフィールドを変更した場合、変更内容を反映するにはFusion Middleware Controlを再起動する必要があります。

復号化キーのパスワードを資格証明ストアに格納

「資格証明ストア・プロバイダの構成」で説明されているように、資格証明ストアには復号化キーのパスワードを格納する必要があります。キー名としてkeystore.enc.csf.keyを使用します。

ポリシーをWebサービスに添付

「単一のサブジェクトへのポリシーの添付」の説明に従って、wss11_saml_token_with_message_protection_service_policyをWebサービスに添付します。

ポリシー・アサーションを、メッセージの署名およびメッセージの暗号化に構成します。

デフォルトでは、リクエストおよびレスポンスの本体全体を署名および暗号化します。そのかわりに、特定の本体要素を指定して署名および暗号化する方法もあります。署名および暗号化するヘッダー要素を追加で指定することもできます。ここで設定したものは、クライアント・ポリシー設定と一致している必要があります。


注意:

ore.sig.csf.key and keystore.enc.csf.key, as described in 「オーバーライド可能なWebサービス・ポリシーの添付」で説明されているように、keystore.sig.csf.keyおよびkeystore.enc.csf.keyをオーバーライドできます。

これらの値をオーバーライドする場合は、新しい値のキーがキーストアにあることが必要です。つまり、値をオーバーライドしても、これらのキーをキーストアに構成する必要がなくなるわけではありません。

ポリシーをWebサービス・クライアントに添付

「Webサービス・クライアントへのポリシーの添付」の説明に従って、wss11_saml_token_with_message_protection_client_policyをWebサービス・クライアントに添付します。

ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。

デフォルトでは、本体全体を署名および暗号化します。そのかわりに、特定の本体要素を指定して署名および暗号化する方法もあります。署名および暗号化するヘッダー要素を追加で指定することもできます。ここで設定したものは、Webサービス・ポリシー設定と一致している必要があります。

「サービス・アイデンティティ証明拡張の使用」で説明されているように、Webサービスのbase64エンコードされた公開証明書は、Webサービス・クライアントが使用するためにWSDLでパブリッシュされます。WSDLの証明書は、デフォルトではサービスの公開鍵です。これはWeb Services Managerキーストアを構成したときに指定した暗号化キー（"orakey"）によって決まります。

そのため、keystore.recipient.aliasを設定または変更する必要はありません。

オプションで、「構成」ページでsaml.issuer.nameの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。saml.issuer.nameプロパティのデフォルトは、www.oracle.comです。詳細は、「SAML発行者をオーバーライドするタイミング」を参照してください。

「構成」ページでuser.roles.includeの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。

  戻る
戻る 		 次へ
次へ
  目次
目次