| Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド 11g リリース1(11.1.1) B56247-03 |
|
 前 |
 次 |
この章では、セキュリティ・ポリシーのためのFusion Middleware ControlおよびWebLogic Server環境の設定方法について説明します。
この章では次の項について説明します。
「SSLの構成が必要なポリシー」または「双方向SSLの構成が必要なポリシー」にあげたポリシーを使用する場合、SSL用のキーストアを構成する必要があります。
SSLでは、ネットワークを介して接続される2つのアプリケーションが互いのアイデンティティを認証できるようにし、アプリケーション間で交換されるデータを暗号化することで、安全な接続を提供します。
認証によって、サーバーと、必要に応じてクライアントが、ネットワーク接続の反対側にあるアプリケーションのアイデンティティを検証できます。暗号化によって、ネットワーク上で伝送されるデータを意図した受信者のみが認識できるようになります。クライアント証明書(双方向SSL)は、ユーザーの認証に使用できます。
この項では、SSL経由でリクエストを送信するようにWebサービス・クライアントとWebLogic Server Webサービス・コンテナを設定する方法を説明します。
Webサービス・アプリケーションでSSLを使用するには、次の作業を実行する必要があります。
WebLogic ServerのキーストアとSSL設定を構成します。
Webサービス・クライアントのキーストアと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_server_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_sts_issued_saml_bearer_token_over_ssl_client_template
oracle/wss_sts_issued_saml_bearer_token_over_ssl_service_template
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_sts_issued_saml_bearer_token_over_ssl_client_template
oracle/wss_sts_issued_saml_bearer_token_over_ssl_service_template
oracle/wss_username_token_over_ssl_service_template
oracle/wss_username_token_over_ssl_client_template
これらのアサーションおよびポリシーの詳細は、付録C「事前定義済アサーション・テンプレート」および付録B「事前定義済ポリシー」を参照してください。
双方向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
秘密鍵、デジタル証明書および信頼できる認証局(CA)証明書によって、WebLogic Server環境でアイデンティティと信頼が確立され、検証されます。
この項では、WebLogic Serverにキーストアを構成するために必要な手順の概要を説明します。詳細は、次の2つの資料を参照してください。
詳細は、Oracle WebLogic Server管理コンソール・ヘルプ。特に「サーバー: 構成: キーストア」に関するトピック。
Securing Oracle WebLogic Server。特にアイデンティティと信頼の構成に関する項。
WebLogic Serverには、デフォルトのアイデンティティ・キーストアDemoIdentity.jksとデフォルトの信頼キーストアDemoTrust.jksが構成されています。さらに、WebLogic Serverでは、JDKのcacertsファイル内の認証局を信頼しています。このデフォルトのキーストア構成は、テストや開発を目的とする場合に適しています。ただし、これらのキーストアは本番環境では使用しないでください。
サーバーのアイデンティティと信頼を構成する手順は次のとおりです。
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://download.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html)の説明を参照してください。
WebLogic Serverキットで提供されるデジタル証明書、秘密鍵および信頼できるCA証明書も使用できます。デモ用のデジタル証明書、秘密鍵および信頼できるCA証明書は、開発環境でのみ使用してください。
アイデンティティ用に1つと信頼用に1つ、キーストアを作成します。キーストア形式にはJavaキーストア(JKS)を使用することをお薦めします。
秘密鍵と信頼できるCAをキーストアにロードします。
コンソールの左側のペインで、「環境」を開き、「サーバー」を選択します。
アイデンティティと信頼キーストアを構成するサーバーの名前をクリックします。
「構成」→「キーストア」を選択します。
「キーストア」フィールドで、秘密鍵/デジタル証明書のペアおよび信頼できるCA証明書を格納および管理する方法を選択します。選択できるオプションは次のとおりです。
カスタムIDとカスタム信頼: ユーザーが作成するアイデンティティと信頼キーストア。
デモIDとデモ信頼: デモ用のアイデンティティと信頼キーストア。..\server\libディレクトリおよびJDK cacertsキーストアにあり、デフォルトで構成されています。開発目的にのみ使用してください。
カスタムIDとJava標準信頼: ユーザーが作成するキーストアと、JAVA_HOME\jre\lib\securityディレクトリのcacertsファイルに定義されている信頼できるCA。
カスタムIDとコマンドライン信頼: ユーザーが作成するアイデンティティ・キーストアと、信頼キーストアの場所を指定するコマンドライン引数。
「ID」セクションで、アイデンティティ・キーストアの属性を定義します。
カスタムIDキーストア: アイデンティティ・キーストアへの完全修飾パス。
カスタムIDキーストアのタイプ: キーストアのタイプ。一般に、この属性にはJavaキーストア(JKS)を指定します。空白のままにすると、デフォルトでJKSに設定されます。
カスタムIDキーストアのパスフレーズ: キーストアの読取りまたは書込み時に入力するパスワード。この属性は、キーストアのタイプに応じてオプションまたは必須になります。すべてのキーストアで、書込みにはパスフレーズが必要です。ただし、キーストアによっては読取りにパスフレーズが不要な場合もあります。WebLogic Serverは、キーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件に応じて決まります。
|
注意: デモ・アイデンティティ・キーストアのパスフレーズは、DemoIdentityKeyStorePassPhraseです。 |
「信頼」セクションで、信頼キーストアのプロパティを定義します。
キーストアとして「Java標準信頼キーストア」を選択する場合、キーストアの作成時に定義したパスワードを指定します。パスワードを確認します。
カスタム信頼を選択した場合、次の属性を定義します。
カスタム信頼キーストア: 信頼キーストアへの完全修飾パス。
カスタム信頼キーストアのタイプ: キーストアのタイプ。一般に、この属性にはJKSを指定します。空白のままにすると、デフォルトでJKSに設定されます。
カスタム信頼キーストアのパスフレーズ: キーストアの読取りまたは書込み時に入力するパスワード。この属性は、キーストアのタイプに応じてオプションまたは必須になります。すべてのキーストアで、書込みにはパスフレーズが必要です。ただし、キーストアによっては読取りにパスフレーズが不要な場合もあります。WebLogic Serverは、キーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件に応じて決まります。
変更内容は自動的にアクティブ化されます。
一方向SSLでは、サーバーはクライアントに証明書を提示する必要がありますが、クライアントがサーバーに証明書を提示する必要はありません。
「SSLに関するキーストアの構成」の説明に従ってWebLogic Serverインスタンスのアイデンティティと信頼キーストアを構成したら、そのSSL属性を構成します。これらの属性では、「構成: キーストア」ページで指定したキーストア内のアイデンティティ鍵と証明書の場所を示します。この情報を指定するには、「構成: SSL」ページを使用します。
この項では、WebLogic ServerにSSLを構成するために必要な手順の概要を説明します。詳細は、『Securing Oracle WebLogic Server』を参照してください。
SSLを構成する手順
WebLogic Server管理コンソールの左側のペインで、「環境」を開き、「サーバー」を選択します。
SSLを構成するサーバーの名前をクリックします。
「構成」→「SSL」ページを選択し、WebLogic Serverのアイデンティティ(証明書と秘密鍵)と信頼(信頼できるCA)の場所を選択します。
秘密鍵の別名とパスワードのSSL属性を設定します。
ページの下部で、「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
WebLogic Serverが内部サーバーとエクスポート可能クライアントとの間で何回エクスポート可能鍵を使用したら新しい鍵を生成する必要があるか、使用できる回数を指定します。新しい鍵を生成するまでに鍵を使用する回数が少ないほど、WebLogic Serverのセキュリティが強化されます。
「相互クライアント証明書の動作」コントロールを「クライアント証明書を要求しない」に設定します。
インバウンドとアウトバウンドのSSL証明書検証方法を指定します。選択できるオプションは次のとおりです。
組込みSSLの検証のみ: 組込みの信頼できるCAベースの検証を使用します。これがデフォルトです。
組込みSSLの検証および証明書パス検証プロバイダ: 組込みの信頼できるCAベースの検証を使用し、追加の検証を実行するために構成済のCertPathValidatorプロバイダを使用します。
双方向SSLでは、サーバーはクライアントに、またクライアントはサーバーに証明書を提示します。SSLハンドシェイクを完了する前に、クライアントに有効で信頼できる証明の送信を要求するようにWebLogic Serverを構成できます。
「SSLに関するキーストアの構成」の説明に従って、WebLogic Serverインスタンスのアイデンティティと信頼キーストアを構成した後、使用するポリシーまたはテンプレートで必要な場合は、「双方向SSLの構成が必要なポリシー」の説明に従って双方向SSL属性を構成できます。
この項では、WebLogic ServerにSSLを構成するために必要な手順の概要を説明します。詳細は、『Securing Oracle WebLogic Server』を参照してください。
双方向SSLの構成手順は次のとおりです。
WebLogic Server管理コンソールの左側のペインで、「環境」を開き、「サーバー」を選択します。
SSLを構成するサーバーの名前をクリックします。
「構成」→「SSL」ページを選択し、WebLogic Serverのアイデンティティ(証明書と秘密鍵)と信頼(信頼できるCA)の場所を選択します。
秘密鍵の別名とパスワードのSSL属性を設定します。
ページの下部で、「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
WebLogic Serverが内部サーバーとエクスポート可能クライアントとの間で何回エクスポート可能鍵を使用したら新しい鍵を生成する必要があるか、使用できる回数を指定します。新しい鍵を生成するまでに鍵を使用する回数が少ないほど、WebLogic Serverのセキュリティが強化されます。
必要に応じて、「サーバーの証明書を使用」コントロールを設定します。このコントロールを設定すると、WebLogic ServerでホストされているWebサービス・クライアントが、HTTPSを介して接続を開始するときにサーバー証明書/鍵をクライアント・アイデンティティとして使用する必要があるかどうかが決まります。
「相互クライアント証明書の動作」コントロールを「クライアント証明書を要求(強制する)」に設定します。
インバウンドとアウトバウンドのSSL証明書検証方法を指定します。選択できるオプションは次のとおりです。
組込みSSLの検証のみ: 組込みの信頼できるCAベースの検証を使用します。これがデフォルトです。
組込みSSLの検証および証明書パス検証プロバイダ: 組込みの信頼できるCAベースの検証を使用し、追加の検証を実行するために構成済のCertPathValidatorプロバイダを使用します。
中核となるWebLogic Serverのセキュリティ・サブシステムでは、デフォルトのキーストアに格納されている秘密鍵とX.509証明書のペアをSSLに使用します。
WebLogic Serverでリクエストのデジタル署名に使用されるX.509証明書を、Webサービス・クライアントが信頼できるようにする必要があります。次のいずれかを実行します。
WebLogic Serverが、信頼できる認証局から発行された、クライアントが自動的に信頼するデジタル証明書を取得するようにします。
WebLogic Serverが信頼する個々の証明書をすべてリストした証明書レジストリを作成し、クライアントが登録されたこれらの証明書を信頼するようにします。
Webサービス・クライアントに関するSSLの構成手順は次のとおりです。
クライアント・アプリケーションで使用するキーストアを作成します。アプリケーション・ユーザーごとに1つのクライアント・キーストアを作成することをお薦めします。
この手順の実行には、keytoolユーティリティを使用できます。開発目的の場合、最初はkeytoolユーティリティを使用するのが最も簡単な方法です。
秘密鍵とデジタル証明書のペアを作成し、クライアント・キーストアにロードします。
証明書の鍵が暗号化とデジタル署名の両方に使用できることを確認します。Oracleでは、鍵の長さは1024ビット以上である必要があります。
クライアントのJVMに次のプロパティが設定されていることを確認します。
javax.net.ssl.trustStore: 信頼ストアが含まれるファイルの名前。
javax.net.ssl.trustStoreType: デフォルトのTrustManagerで使用するキーストア・オブジェクトのタイプ。
javax.net.ssl.trustStorePassword: デフォルトのTrustManagerで使用するキーストア・オブジェクトのパスワード。
|
注意: SOAアプリケーションが双方向SSLでのWebサービス・クライアントである場合の特定の構成手順については、Oracle Fusion Middleware管理者ガイド for Oracle SOA SuiteおよびOracle Business Process Management Suiteの双方向SSL通信のSOAコンポジット・アプリケーションの構成に関する項を参照してください。 |
クライアントでリクエストのデジタル署名に使用されるX.509証明書をWebLogic Serverが検証でき、WebLogic Serverがその証明書をクライアントへの応答の暗号化に使用できるようにする必要があります。次のいずれかを実行します。
クライアント・アプリケーションが、信頼できる認証局から発行された、WebLogic Serverが自動的に信頼するデジタル証明書を取得するようにします。
WebLogic Serverが信頼する個々の証明書をすべてリストした証明書レジストリを作成し、クライアントが登録されたこれらの証明書のいずれかを使用するようにします。
Webサービス・クライアントに関するSSLの構成手順は次のとおりです。
クライアント・アプリケーションで使用するキーストアを作成します。アプリケーション・ユーザーごとに1つのクライアント・キーストアを作成することをお薦めします。
この手順の実行には、keytoolユーティリティを使用できます。開発目的の場合、最初はkeytoolユーティリティを使用するのが最も簡単な方法です。
秘密鍵とデジタル証明書のペアを作成し、クライアント・キーストアにロードします。
証明書の鍵が暗号化とデジタル署名の両方に使用できることを確認します。Oracleでは、鍵の長さは1024ビット以上である必要があります。
クライアントの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で使用されるキーストアを設定するには、次の手順を実行します。
「Javaキーストアの作成方法」の説明に従って、keytoolを使用してJavaキーストアを作成します。
ナビゲータ・ペインで「WebLogicドメイン」を開き、キーストアの構成が必要なドメインを表示します。ドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」をクリックします。
ページの下部近くにある「キーストア」コントロールのプラス記号(+)をクリックして開き、「構成」をクリックします。
図10-1に示すように、Web Services Managerの「キーストアの構成」ページが表示されます。
「キーストア・タイプ」ドロップダウンで、デフォルトある「Javaキーストア」を選択します。
|
注意: また、ハードウェア・セキュリティ・モジュール(HSM)はOracle Advanced Securityで動作保証されています。詳細は、「ハードウェア・セキュリティ・モジュールとOracle WSMの併用」を参照してください。 |
作成するキーストアのパスと名前を入力します。デフォルトのキーストア名はdefault-keystore.jksですが、変更できます。
キーストアのパスワードを入力して確認します。
署名と暗号化キーの別名とパスワードを入力します。パスワードを確認します。
署名と暗号化キーの別名とパスワードによって、鍵の格納と取得に使用される文字列の別名とパスワードが定義されます。
「OK」をクリックして変更内容を送信します。
このページのフィールドを変更した場合、変更内容を反映するにはOracle Enterprise Manager Fusion Middleware Controlを再起動する必要があります。
|
注意: Oracle WSMエージェントは、キーストア名とオブジェクトをキャッシュします。キーストアの内容またはその名前を続けて変更する場合は、Oracle Enterprise Manager Fusion Middleware Controlを再起動する必要があります。 |
クライアントのX.509トークンで必要な署名と暗号化キーを格納するには、Javaキーストア(JKS)のキーストアを作成する必要があります。鍵は、認証やデータ整合性など、様々な用途に使用されます。たとえば、次のようにします。
データに署名するには、署名者の秘密鍵が必要です。
署名を検証するには、信頼できるCA証明書と、秘密鍵に一致する公開鍵が必要です。
データを暗号化するには、受信者の公開鍵が必要です。「サービス・アイデンティティ証明拡張の使用」で説明されているように、Webサービスのbase64エンコードされた公開証明書は、Webサービス・クライアントが使用するためにWSDLでパブリッシュされます。
データを復号化するには、公開鍵に対応する秘密鍵が必要です。
これらの信頼できる証明書、公開鍵および秘密鍵はキーストアに格納されます。次の項では、信頼できる証明書を取得できる場所と、これらのキーストアの作成および使用方法を説明します。
Verisign社やEntrust社のような認証局(CA)から証明書を取得し、キーストアに含めることができます。証明書を取得するには、証明書リクエストを作成してCAに送信する必要があります。CAは、証明書リクエストを認証し、リクエストに基づいてデジタル証明書を作成します。
Javaキーストア(JKS)は、Sun社によって定義された独自のキーストア形式です。鍵と証明書をJKSで作成し管理するには、keytoolユーティリティを使用します。keytoolユーティリティを使用すると、次のタスクを実行できます。
公開鍵と秘密鍵のペアを作成し、他のパーティに属する公開鍵を信頼できるものとして指定し、キーストアを管理します。
証明書リクエストを適切な認証局(CA)に発行し、認証局から返された証明書をインポートします。
独自の公開鍵と秘密鍵のペアおよび関連する証明書を管理します。これにより、独自の鍵と証明書を使用して自分自身を他のユーザーやサービスに対して認証できます。このプロセスは自己認証と呼ばれます。また、デジタル署名を使用したデータ整合性および認証サービスにも独自の鍵と証明書を使用できます。
通信するピアの公開鍵をキャッシュします。鍵は証明書の形式でキャッシュされます。
次の項では、keytoolユーティリティを使用してJKSを作成および管理する方法の概要を説明します。キーストアの作成方法、および秘密鍵のペアとCA証明書のロード方法を取り上げます。keytoolユーティリティのコマンドや引数の詳細は、次のWebサイト・アドレスにアクセスして参照してください。
http://download.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html
新しい秘密鍵と自己署名証明書を作成します。
秘密鍵を作成するには、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を渡してください。
キーストアを表示します。
次のコマンドでは、キーストアの内容が表示されます。キーストアのパスワードを要求するプロンプトが表示されます。
keytool -list -v -keystore test.jks
信頼できるCA証明書をキーストアにインポートします。
証明書のインポートには、-importコマンドを使用します。次のコマンドでは、信頼できるCA証明書がtest.jksキーストアにインポートされます。既存のキーストアがない場合、新しいキーストアが作成されます。keytoolユーティリティから必要なパスワードを要求するプロンプトが表示されます。
keytool -import -alias aliasfortrustedcacert -trustcacerts -file trustedcafilename -keystore test.jks
証明書リクエストを生成します。
リクエストの生成には、-certreqコマンドを使用します。次のコマンドでは、テスト別名の証明書リクエストが生成されます。CAから証明書または証明書チェーンが返されます。
keytool -certreq -alias test -sigalg "RSAwithSHA1" -file certreq_file -storetype jks -keystore test.jks
自己署名証明書を信頼できるCA証明書で置き換えます。
既存の自己署名証明書をCAの証明書で置き換える必要があります。これを実行するには、-importコマンドを実行します。次のコマンドでは、test.jksキーストアの信頼できるCA証明書で置き換えます。keytoolユーティリティから必要なパスワードを要求するプロンプトが表示されます。
keytool -import -alias test -file trustedcafilename -keystore test.jks
HTTPSプロトコルではSecure Sockets Layer (SSL)という業界標準のプロトコルを使用してクライアントおよびサーバー間のセキュアな接続を確立します。Oracle HTTP Serverが提供するHTTPS/SSLサポートを通信プロトコルの1つとして使用し、クライアントとWebサービス間で通信します。この項では、SSLを介してリクエストを送信できるようにOracle WSMポリシーを使用してWebサービス・クライアントおよびWebサービスの設定方法について説明します。Oracle HTTP ServerはクライアントとOracle WebLogic Serverとの間を仲介するWebプロキシとして構成されます。Oracle HTTP ServerではSSLが有効になっており、クライアントとOracle HTTP Serverとの間のSSLトランスポートが有効になっています。通信は Oracle HTTP ServerとWebLogic Serverとの間ではSSL以外の通信が維持されます。この項では、一方向SSLおよび双方向SSLを必要とするポリシーを構成する方法について説明します。
詳細は、次の項目を参照してください。
『Oracle Fusion Middleware管理者ガイド』のOracle Fusion MiddlewareでのSSL構成"
Oracle WebLogic Serverの保護のSSLの構成
Oracle WebLogic Server管理コンソール・ヘルプSSLの設定
『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』のSecure Sockets Layer認の構成
一方向SSL構成が必要なOracle WSMのポリシーの詳細は、「SSLの構成が必要なポリシー」を参照してください。
一方向SSLを使用するには、次の作業を実行する必要があります。
次のようにOracle HTTP Serverを構成します。
ファイルORACLE_INSTANCE/config/OHS/<ohs_name>/ssl.confで、WebプロキシとOracle HTTP Serverを構成し、例10-1に示すようにアクセスするURLのリストを指定します。
例10-1 ssl.confのURLの指定
# added properties for configuring OHS as webproxy
<IfModule weblogic_module>
WebLogicHost <host>
WebLogicPort <port>
SecureProxy Off
WlProxySSL On
Debug ALL
WlLogFile /tmp/weblogic.log
#the location attributes list the urls you want to access via OHS
<Location
/myWlsService>
SetHandler weblogic-handler
WebLogicHost <host>
WeblogicPort <port>
</Location>
同じファイルで、仮想ホスト構成で次のプロパティを設定して、クライアント証明書情報をWebLogic Serverに送信します。
SSLVerifyClient optional
デフォルトでは、Oracle HTTP Serverで有効になっています。デフォルトのhttpsポートは4443です。このポートの構成の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion MiddlewareのSSL構成」を参照してください。
Oracle HTTP Serverを再起動します。
詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion MiddlewareのSSL構成」を参照してください。
『Oracle Fusion Middleware管理者ガイド』の「キーストア、ウォレット、証明書の管理」の説明に従ってウォレットを作成し、デフォルトのウォレットに置き換えます。デフォルトのウォレットはORACLE_INSTANCE/config/OHS/<ohs_name>/keystores/defaultディレクトリにあります。ウォレット作成のサンプル・コマンドは、例10-2を参照してください。
例10-2 一方向SSLのサンプル・コマンド
./orapki wallet create -wallet <wallet_location> -pwd welcome1 -auto_login ./orapki wallet display -wallet <wallet_location> -pwd welcome1 ./orapki cert display -cert <wallet_location>/ohs.crt ./orapki wallet add -wallet <wallet_location> -keysize 512 -dn "CN=<host_name>,OU=st,O=owsm,L=N,ST=delhi,C=IN" -self_signed -validity 700 -serial_num 20 -cert <wallet_location>/ohs.crt -user_cert -pwd welcome1 ./orapki wallet display -wallet <wallet_location> -pwd welcome1 JAVA_HOME/bin/keytool -import -trustcacerts -file ohs.crt -alias sslcert -keystore client_keystore.jks -storepass welcome1
Oracle WebLogic管理コンソールで、次の作業を実行します。
「環境」タブで「サーバー」ページに移動します。
Adminserverをクリックして、「構成」で「一般」を選択します。
「拡張」セクションで「WebLogicプラグインの有効化」および「クライアント証明書プロキシの有効化」を確認します。
変更を保存します。
SOAサーバーに同じパラメータを設定します。
詳細は、Oracle WebLogic Server管理コンソール・ヘルプの「サーバー:構成:一般」を参照してください。
一方向(サーバー認証モード)を使用するようにクライアントを変更するには、JDeveloperを使用してWebサービスからJSEクライアントを作成します。例10-3の説明に従って、パラメータおよびプロパティを変更します。
例10-3 SSLを使用するJSEクライアント
public static void main(String [] args)
{
class1Service = new Class1Service();
SecurityPolicyFeature[] securityFeatures =
new SecurityPolicyFeature[] { new SecurityPolicyFeature("oracle/wss_
saml_token_over_ssl_client_policy") };
Class1 class1 = class1Service.getClass1Port(securityFeatures);
((BindingProvider) class1).getRequestContext().put(BindingProvider.ENDPOINT_
ADDRESS_PROPERTY,
"https://<host>:4443/myWlsService/Class1Port");
((BindingProvider) class1).getRequestContext().put(BindingProvider.USERNAME_
PROPERTY, "weblogic");
System.setProperty("javax.net.ssl.trustStore","D:\\OWSM_
QA\\11g\\PS2\\OHS\\wallet\\client_keystore.jks");
System.setProperty("javax.net.ssl.trustStorePassword","welcome1");
System.setProperty("javax.net.ssl.trustStoreType","JKS");
System.setProperty("weblogic.security.SSL.ignoreHostnameVerification" ,
"true");
System.setProperty("java.protocol.handler.pkgs",
"com.sun.net.ssl.internal.www.protocol");
System.setProperty("javax.net.debug","all");
System.out.println("Call to the SSL service...");
String response1 = class1.sayHello("test");
System.out.println("Response = " + response1);
}
双方向SSL構成が必要なOracle WSMのポリシーの詳細は、「双方向SSLの構成が必要なポリシー」を参照してください。
双方向SSLを使用するには、次の作業を実行する必要があります。
次のようにOracle HTTP Serverを構成します。
ファイルORACLE_INSTANCE/config/OHS/<ohs_name>/ssl.confで、WebプロキシとOracle HTTP Serverを構成し、例10-4に示すようにアクセスするURLのリストを指定します。
例10-4 ssl.confのURLの指定
# added properties for configuring OHS as webproxy
<IfModule weblogic_module>
WebLogicHost <host>
WebLogicPort <port>
SecureProxy Off
WlProxySSL On
Debug ALL
WlLogFile /tmp/weblogic.log
#the location attributes list the urls you want to access via OHS
<Location /myWlsService>
SetHandler weblogic-handler
WebLogicHost <host>
WeblogicPort <port>
</Location>
同じファイルで、仮想ホスト構成で次のプロパティを設定して、クライアント証明書情報をWebLogic Serverに送信します。
SSLVerifyClient optional
SSLOptions +StdEnvVars +ExportCertData
SSLOptions +ExportCertDataは証明書関連情報がWebLogic Serverに送信されていることを確認するmod_sslディレクティブです。SSLOptions +StdEnvVars +ExportCertDataではSSL関連情報が送信されていることを確認します。
デフォルトでは、Oracle HTTP Serverで有効になっています。デフォルトのhttpsポートは4443です。このポートの構成の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion MiddlewareのSSL構成」を参照してください。
Oracle HTTP Serverを再起動します。
詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion MiddlewareのSSL構成」を参照してください。
『Oracle Fusion Middleware管理者ガイド』の「キーストア、ウォレット、証明書の管理」の説明に従ってウォレットを作成し、デフォルトのウォレットに置き換えます。デフォルトのウォレットはORACLE_INSTANCE/config/OHS/<ohs_name>/keystores/defaultディレクトリにあります。サンプル・コマンドは、例10-5を参照してください。
Oracle WebLogic管理コンソールで、次の作業を実行します。
「環境」タブで「サーバー」ページに移動します。
Adminserverをクリックして、「構成」で「一般」を選択します。
「拡張」セクションで「WebLogicプラグインの有効化」および「クライアント証明書プロキシの有効化」を確認します。
変更を保存します。
SOAサーバーに同じパラメータを設定します。
詳細は、Oracle WebLogic Server管理コンソール・ヘルプの「サーバー:構成:一般」を参照してください。
双方向(相互認証モード)SSLを使用するようにクライアントを変更するには、JDeveloperを使用してWebサービスからJSEクライアントを作成します。例10-6の説明に従って、パラメータおよびプロパティを変更します。
例10-6 SSLを使用するJSEクライアント
public static void main(String [] args)
{
class1Service = new Class1Service();
SecurityPolicyFeature[] securityFeatures =
new SecurityPolicyFeature[] { new SecurityPolicyFeature("oracle/wss_
username_token_over_ssl_client_policy") };
Class1 class1 = class1Service.getClass1Port(securityFeatures);
((BindingProvider) class1).getRequestContext().put(BindingProvider.ENDPOINT_
ADDRESS_PROPERTY,
"https://<host>:4443/myWlsService/Class1Port");
((BindingProvider) class1).getRequestContext().put(BindingProvider.USERNAME_
PROPERTY, "weblogic");
((BindingProvider) class1).getRequestContext().put(BindingProvider.PASSWORD_
PROPERTY, "welcome1");
System.setProperty("javax.net.ssl.trustStore","D:\\OWSM_
QA\\11g\\PS2\\OHS\\wallet\\twowaykeystore.jks");
System.setProperty("javax.net.ssl.trustStorePassword","welcome1");
System.setProperty("javax.net.ssl.trustStoreType","JKS");
System.setProperty("javax.net.ssl.keyStore","D:\\OWSM_QA\\11g\\PS2\\OHS\\wallet\\twowaykeystore.jks");
System.setProperty("javax.net.ssl.keyStorePassword","welcome1");
System.setProperty("javax.net.ssl.keyStoreType","JKS");
System.setProperty("weblogic.security.SSL.ignoreHostnameVerification" ,
"true");
System.setProperty("java.protocol.handler.pkgs",
"com.sun.net.ssl.internal.www.protocol");
System.setProperty("javax.net.debug","all");
System.out.println("Call to the SSL service...");
String response1 = class1.sayHello("test");
System.out.println("Response = " + response1);
}
ハードウェア・セキュリティ・モジュール(HSM)はOracle Advanced Securityで動作保証されています。これらのモジュールでは、鍵を安全に格納する手段を提供し、暗号処理の負荷を軽減します。
SafeNet Luna SAはネットワーク接続されたHSMで、アプリケーション用の暗号化処理およびハードウェアキー管理機能を備えています。Luna SAは幅広いセキュリティ・アプリケーションを対象として重要な暗号化鍵を保護するように作成されています。
Luna SAとOracle WSMを併用するうえでの主な利点の一部を次に挙げます。
ネットワークの共有可能性
ハードウェアで鍵に対する最大の安全性が常に確保される
FIPS検証済
|
注意: SafeNetの担当者に問い合わせ、Oracle Advanced Securityで使用する認証済のハードウェアおよびソフトウェアを取得する必要があります。 |
デフォルトでは、Oracle Web Services Manager (Oracle WSM)ではJava Key Store (JKS)を使用して鍵を格納します。暗号化操作のためにOracle WSMが必要とする鍵と証明書はキーストア・ファイルからフェッチされます。Luna SAがネットワーク内で使用可能な場合、鍵の格納のためおよび暗号化操作のためOracle WSMで活用可能です。
この項の項目は次のとおりです。
Luna SA HSMクライアントは、Oracle WSMのインスタンスを実行しているホスト上にインストールする必要があります。次に、Luna SA HSMクライアントは使用可能なLuna SA HSMネットワークと通信します。ただし、この項では、Luna SAクライアント・インストールおよびLuna SAネットワーク・インストールおよび設定について説明しません。これは、この文書の範囲に含まれません。代わりに、http://www.safenet-inc.com/Products/Detail.aspx?id=2147483853&terms=searchにあるLuna SA文書の説明を参照してください。
Luna SA HSMクライアントをインストールする前に、次のチェックリストを確認します。
Luna SAがインストールされており、ネットワークで使用可能です。
ルートまたはインストール権限を持つユーザーとしてログインされています。
Luna SAクライアントのインストールCDまたはソフトウェア・イメージがあります。
管理者パスワード、パーティション・パスワードを含むLuna SAのすべての必要なパスワードを含みます。
|
注意: SafeNetの担当者に問い合わせ、ハードウェア・セキュリティ・モジュールを所有し、必要なライブラリを取得する必要があります。Luna SAハードウェア・セキュリティ・モジュールとOracle WSMを併用するには、次のタスクを実行する必要があります。 |
Luna SAクライアントのインストール後、Oracle WSM設定で使用するJREを構成する必要があります。
/usr/lunasa/jsp/libディレクトリから$JAVA_HOME/jre/lib/extディレクトリに次のJARファイルをコピーします。
LunaJCASP.jar
LunaJCESP.jar
libLunaAPI.soファイルをjava.library.pathにコピーします。
2つのLunaプロバイダを含むように$JAVA_HOME/jre/lib/security/java.securityファイルを編集します。
security.providersリストの末尾に、これらの2つのプロバイダを追加します。
security.provider.n=com.chrysalisits.crypto.LunaJCAProvider security.provider.n+1=com.chrysalisits.cryptox.LunaJCEProvider
説明:
nでは、要求される特定のプロバイダがない場合、要求されたアルゴリズムに対してプロバイダが検索される順序を決定する優先順位を指定します。順序は1ベースであるため、1が最も望ましく、その後2、3と続きます。
Luna SAをOracle WSMと併用するには、Luna SAサーバーにログオンする必要があります。これは、クライアント・マシンでLunaログイン セッションを作成する1回のプロセスです。このセッションは、クライアントまたはサーバ・マシンが再起動されるまで、またはユーザーがLunaセッションからログアウトするまでアクティブなまま保持されます。
saloginユーティリティを使用してログインする必要があります。saloginユーティリティでは特定のアプリケーションのクライアントとHSMパーティション間の接続を確立します。アプリケーションIDを引数として取ります。このアプリケーションIDは高IDと低IDの2つの部分で構成されています。
saloginユーティリティを起動するには、Chrystoki.confファイルにエントリを追加する必要があります。このファイルはアプリケーション ID を登録します。Chrystoki.confファイルは、通常、/etc/ディレクトリにあります。また、1回のプロセスです。
ファイルの末尾にアプリケーション ID を追加することにより、/etc/Chrystoki.confファイルを編集します。次の例を挙げます。
Misc = { AppIdMajor=<major id>; AppIdMinor=<minor id>; }
次を入力して、Luna SAサーバーにログインします。
/salogin -o -s <partition number> -i <AppIdMajor>:<AppIdMinor> -v -p <partition_password>
これにより、指定したアプリケーション ID のセッションが開きます。saloginは/usr/lunasa/binディレクトリにあります。
Luna SAサーバーからログアウトするには、次を入力します。
salogin -c -s <slot number> -i <AppIdMajor>:<AppIdMinor>
鍵および証明書が現在JKS内にある場合、すべての鍵および証明書をLunaSAに移動する必要があります。鍵および証明書のLunaSAが提供するcmuスクリプトを使用できます。
cmu importKeyコマンドではHSM上のファイルからRSA|DSA秘密鍵をインポートします。(PKCS12(RSA)、PKCS8(RSA/DSA)、またはPKCS1(RSA)のサポート)。
cmu importKeyコマンドではHSM上のファイルからX.509証明書をインポートします。
Luna SAを使用できるようにOracle WSMを構成する一環として、キーストア・タイプがLunaからデフォルトのJava Key Store (JKS)値に変更されました。
次の手順に従って、キーストア・タイプを構成します。
ナビゲータ・ペインで「WebLogicドメイン」を開き、キーストアの構成が必要なドメインを表示します。ドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」をクリックします。
ページの下部近くにある「キーストア」コントロールのプラス記号(+)をクリックして開き、「構成」をクリックします。
図10-2に示すように、Web Services Managerの「キーストアの構成」ページが表示されます。
「キーストア・タイプ」ドロップダウンで、Hardware Security Module (HSM)を選択します。
「キーストアの構成」ページの更新後、図10-3に示すように、HSM Provider Typeフィールドで、Lunaと入力します。
「キーの別名」および「Crypt別名」フィールドで、署名と暗号化キーの別名を入力します(Luna SAにはキーストアおよび秘密鍵にアクセスするパスワードは必要ありません)。
HSMでは、すべての*csf.key(keystore.sig.csf.keyおよびkeystore.enc.csf.key)プロパティが資格証明ストア・キーを持つのではなく、直接の別名を持つようにキーの別名のみが必要です。また、この情報も*csf.keyプロパティの構成のオーバーライドに適用可能です。
「OK」をクリックして変更内容を送信します。
Fusion Middleware Controlを再起動します。
前のリリースのOracle WSMでは、メッセージ保護ポリシーを実装したWebサービスの場合、Webサービス・クライアントはWebサービスの公開証明書をそのドメイン・レベルのキーストアに格納する必要がありました。それからクライアントはkeystore.recipient.aliasプロパティを使用して、キーストア内の証明書を識別していました。これを行うために、「構成」ページでkeystore.recipient.aliasプロパティを確認するか、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して(またはプログラムによって)、クライアントごとにプロパティをオーバーライドしていました。
このリリースのOracle WSMでは、メッセージ保護ポリシーを実装したWebサービスの場合、Webサービスのbase64エンコードされた公開証明書はWSDLでパブリッシュされます。証明書は、ポリシーがデータを暗号化または復号化するかどうかに関係なく、メッセージ保護ポリシーに含められます。
WSDLの証明書は、デフォルトではサービスの公開鍵です。これは、「メッセージ保護に関するキーストアの設定」時に指定した「暗号化鍵」によって決まります。
証明書が見つからない場合は、かわりにkeystore.recipient.aliasプロパティが使用され、以前と同様に証明書をクライアントのドメイン・レベルのキーストアに格納する必要があります。
|
注意: 自己署名証明書を信頼できるものにするには、クライアント側のキーストアで使用可能にする必要があります。 |
このリリースには、WSDLから取り出した証明書が改ざん攻撃や中間者攻撃を受けておらず、期待通りの証明書であることを確認するホスト名検証機能が含まれています。
これを行うために、Oracle WSMは、証明書内の共通名(CN)またはサブジェクトのグループ・ベース識別名(DN)がサービスのホスト名と一致していることを検証します。
この機能は、証明書のサブジェクトDNに依存します。
デフォルトでは、ホスト名検証は無効です。
サービス・アイデンティティ証明拡張およびホスト名検証を有効化または無効化するには、Fusion Middleware Controlを使用します。
「アイデンティティ拡張」タブのプロパティでは、WSDLでX509証明書を公開してWebサービス・ポリシーを強制するかどうかを指定できます。さらに、X509を公開する場合、ホスト名検証を無視するかどうかも指定できます。
サービス・アイデンティティ証明拡張はデフォルトで有効、ホスト名検証はデフォルトで無効です。
サービス・アイデンティティ証明拡張およびホスト名検証を有効化または無効化する手順
「メッセージ保護に関するキーストアの設定」で説明されているように、公開鍵の元となる暗号化キーを設定します。
サービス側のオーバーライドを使用して暗号化キーやWebサービスのキーストアをオーバーライドする場合は、オーバーライドされるキーに対応する証明書が使用されます。
ナビゲーション・ペインから、「WebLogicドメイン」を開きます。
サービス・アイデンティティ証明拡張およびホスト名検証を有効化または無効化するドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」をクリックします。
「Webサービス」→「プラットフォーム・ポリシー構成」を選択します。
アイデンティティ拡張タブを選択します。
アイデンティティ拡張プロパティを変更するには、それを選択してから「編集」をクリックします。「プロパティの編集」ウィンドウで、「値」フィールドを編集して各プロパティのデフォルト値を変更できます。
wsm.ignore.identity.wsdl: クライアント側のWSDLから取得したX509証明書の使用を有効にするかどうかをドメインごとに指定します。デフォルトでは、このプロパティは有効(false)で、つまりWSDLから取得した証明書がクライアントのラインタイムで暗号化に使用されます。デフォルト設定をtrueに変更すると、X509証明書の使用を無効化できます。
wsm.ignore.hostname.verification: ホスト名検証機能を無効にするかどうかをドメインごとに指定します。デフォルトでは、このプロパティは無効(true)です。ただし、プロパティをfalseに設定すると、ホスト名検証を有効化できます。
既存のプロパティを削除するには、それを選択してから「削除」をクリックします。
「適用」をクリックしてプロパティの更新を適用します。
|
注意: クライアントがkeystore.recipient.aliasプロパティ(クライアントのプログラムによるオーバーライドではoracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_RECIPIENT_KEY_ALIAS)をオーバーライドすると、常にオーバーライドが使用され、WSDLでパブリッシュされた証明書は使用されません。 |
Java 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");
Java EEクライアントの場合は、wsm.ignore.identity.wsdlプロパティの値が自動的に読み取られ、その他の構成は必要ありません。「サービス・アイデンティティ証明拡張およびホスト名検証の有効化または無効化」で説明されているように、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です。このbasic.credentials資格証明は、資格証明ストア・プロバイダに格納されます。Oracle Platform Security Servicesアイデンティティ・ストアにbasic.credentials資格証明の値を有効なユーザー名およびパスワードに変更する必要があります。
資格証明ストア・プロバイダを構成するには、次の手順を実行します。
ナビゲータ・ペインで「WebLogicドメイン」を開き、キーストアの構成が必要なドメインを表示します。ドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」→「セキュリティ」→「資格証明」をクリックします。
図10-4に示すように、資格証明ストア・プロバイダの構成ページが表示されます(この図では、「資格証明ストア・プロバイダ」コントロールがすでに開かれています)。
「マップの作成」をクリックし、図10-5に示すようにマップ名oracle.wsm.securityを入力します。
「キーの作成」をクリックします。図10-6に示すように、「キーの作成」ダイアログ・ボックスが表示されます。
選択されていない場合は、マップ名oracle.wsm.securityを選択します。
キー名を入力します。
キーのタイプを「パスワード」または「汎用」から選択します。パスワード資格証明には、ユーザー名とパスワードを格納できます。汎用資格証明には、資格証明オブジェクトを格納できます。
パスワード資格証明の場合、ユーザー名とパスワードを入力します。
「OK」をクリックします。
Fusion Middleware Controlを再起動します。
この項では、WebLogic Serverのセキュリティ機能について説明します。この機能の詳細は、Securing Oracle WebLogic ServerおよびOracle WebLogic Server管理コンソール・ヘルプで説明されています。この項では、セキュリティ機能と構成ポリシーとの関係を中心に、セキュリティ機能の概要のみを解説します。
使用するセキュリティ・ポリシーによって、WebLogic Serverに構成が必要なセキュリティ・プロバイダのタイプが決まります。ポリシーはトークンのタイプに基づいて次のようなカテゴリに分類できます。
ユーザー名トークンを使用するポリシーでは、NameCallbackとPasswordCallbackを処理できる認証プロバイダが必要です。WebLogicのデフォルト認証プロバイダは、これに該当します。
次のポリシーはこのカテゴリに分類されます。
oracle/wss_http_token_service_policy
oracle/wss_username_token_service_policy
oracle/wss_username_token_over_ssl_service_policy
oracle/wss11_username_token_with_message_protection_service_policy
oracle/wss10_username_token_with_message_protection_service_policy
oracle/wss10_username_token_with_message_protection_ski_basic256_service_policy
X.509トークンおよびSAMLトークンを使用するポリシーでは、NameCallbackを介して境界認証を処理できる認証プロバイダ(またはIDアサーション・プロバイダ)が必要です。Webサービス・ランタイムでは、ユーザーにかわりトークンを処理してユーザー名を判定し、Oracle Platform Security Service (OPSS)レイヤーを起動して認証を完了します。このように、セキュリティ・プロバイダはX.509トークンやSAMLトークンを直接処理しないため、WebLogicのプロバイダはこのようなタイプのトークンをサポートする必要がありません。
次のポリシーはこのカテゴリに分類されます。
oracle/wss10_x509_token_with_message_protection_service_policy
oracle/wss10_saml_token_service_policy
oracle/wss10_saml_token_with_message_protection_service_policy
oracle/wss_saml_token_over_ssl
oracle/wss_saml_token_bearer_over_ssl_service_policy
oracle/wss10_saml_hok_token_with_message_protection_service_policy
oracle/wss11_saml_token_with_message_protection_service_policy
oracle/wss10_saml_token_with_message_protection_ski_basic256_service_policy
oracle/wss11_x509_token_with_message_protection_service_policy
NameCallbackおよびPasswordCallbackコールバック、またはNameCallbackのみで資格証明を検証できるWebLogic認証プロバイダを必要に応じて使用できます。つまり、適宜プロバイダを選択し、WebLogicのデフォルト認証プロバイダを使用して埋込みのLDAPデータストアに対してユーザーを認証したり、デフォルトのIDアサーション・プロバイダを使用したりできるということです。手順の詳細は、Oracle WebLogic Server管理コンソール・ヘルプの認証プロバイダとIDアサーション・プロバイダの構成に関する項を参照してください。
SAMLおよびKerberosポリシーには、ログイン・モジュールが関連付けられています。このモジュールは、ポリシーを構成するアサーションによって決まります。SAMLポリシーをWebサービスに添付する場合、ログイン・ポリシーを編集して必要な変更を行うことができます。
次のSAMLおよびKerberosログイン・モジュールを構成できます。
saml.loginmodule — SAMLログイン・モジュールは、Java Authentication and Authorization Service (JAAS)ログイン・モジュールで、SAMLアサーションを受け入れてログインを実行します。SAMLログイン・モジュールは、SAMLアサーションから作成されたプリンシパルのログイン・コンテキストを使用して、Webサービスを実行できるようにします。
saml2.loginmodule — SAML2ログイン・モジュールは、JAASログイン・モジュールで、SAML2アサーションを受け入れてログインを実行します。SAML2ログイン・モジュールは、SAML2アサーションから作成されたプリンシパルのログイン・コンテキストを使用して、Webサービスを実行できるようにします。
krb5.loginmodule — Kerberosログイン・モジュールはKerberosプロトコルを使用してユーザーを認証するJAASログイン・モジュールです。Kerberosログイン・モジュールには構成可能なオプションのプロパティがあります。
(他のポリシー・タイプに関連付けられているログイン・モジュールには、Webサービス・ポリシーに固有の設定はありません。)
ログイン・モジュールを構成するには、次の手順を実行します。
ナビゲータ・ペインで「WebLogicドメイン」を開き、ログイン・モジュールの構成が必要なドメインを表示します。ドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」をクリックします。
ログイン・モジュールのリストから、ログイン・モジュールを選択し、「編集」をクリックします。
たとえば、ログイン・モジュールのリストからsaml.loginmoduleを選択し、「編集」をクリックすると、図10-7に示す「ログイン・モジュールの編集」ページが表示されます。
|
注意: 「一般プロパティ」セクションのデフォルト値は編集しないでください。編集すると、予測しない結果が発生します。これらのプロパティのデフォルト値は次のとおりです。
|
オプションで、SAML Specific Attributesセクションでは、構成の必要に応じて、代替発行者の属性を構成します。SAMLポリシーでは、発行者属性が必要です。この属性では、SAMLまたはSAML2トークンの発行者の名前を指定します。事前定義済のOracle SAMLポリシーおよびアサーションでは、デフォルト値はwww.oracle.comです。Webサービス・クライアントおよびWebサービス側の両方で事前定義済のSAMLポリシー(アサーション)を使用する場合、通常、デフォルトを使用できますが、発行元は構成できません。詳細は、「別のSAMLアサーション発行者名の追加」を参照してください。
ページの「カスタム・プロパティ」セクションで、ログイン・モジュールのカスタム・プロパティを構成します。
プロパティを追加するには、「追加」をクリックして「新規プロパティの追加」ウィンドウにプロパティ名とその値を入力します。「OK」をクリックすると、「カスタム・プロパティ」・リストにプロパティが追加されます。
既存のプロパティの値を変更するには、「カスタム・プロパティ」リストからプロパティを削除して、改訂された値を持つ新しいプロパティを追加する必要があります。
表10-1では、SAMLおよびKerberosログイン・モジュールを示し、構成可能なプロパティを説明しています。
表10-1 SAMLおよびKerberosログイン・モジュールの属性およびプロパティ
| ログイン・モジュール・サービス名 | プロパティ | 説明 |
|---|---|---|
|
saml.loginmodule saml2.loginmodule |
oracle.security.jps.assert.saml.identity |
SAMLサブジェクトおよびユーザー間のマッピングの決定に使用するドメイン全体のプロパティ。有効な値には次のものが含まれます。
|
|
oracle.security.jps.add.assertion.to.subject |
プライベートな資格証明として認証済のサブジェクトにSAMLアサーションを追加するかどうかを示すために使用するブール・フラグ。デフォルトは |
|
|
krb5.loginmodule |
プリンシパル(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から取得できない場合、認証は失敗します。 |
SAML標準では、Web上のソフトウェア・エンティティ間のセキュリティ・アサーションを作成、要求および交換するための共通のXMLフレームワークが定義されています。SAMLトークン・プロファイルは、WS-Security標準のコア・セットの一部であり、WebサービスのセキュリティのためにSAMLアサーションを使用する方法が指定されています。SAMLでは、ビジネス・プロセスまたはトランザクションの複数のステップ間で、ブラウザからポータル、Webサービスのネットワークへと渡すことのできるセキュリティ・トークンを表す標準的な方法も提供されます。
次の事前定義済ポリシーを使用する場合は、SAMLを構成する必要があります。
oracle/wss_saml_token_bearer_over_ssl_server_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/wss10_saml_token_service_policy
oracle/wss10_saml_token_client_policy
oracle/wss10_saml20_token_service_policy
oracle/wss10_saml20_token_client_policy
oracle/wss10_saml_token_with_message_protection_client_policy
oracle/wss10_saml_token_with_message_protection_service_policy
oracle/wss10_saml20_token_with_message_protection_client_policy
oracle/wss10_saml20_token_with_message_protection_service_policy
oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy
oracle/wss10_saml_token_with_message_protection_ski_basic256_service_policy
oracle/wss10_saml_hok_token_with_message_protection_service_policy
oracle/wss10_saml_hok_token_with_message_protection_client_policy
oracle/wss10_saml_token_with_message_integrity_service_policy
oracle/wss10_saml_token_with_message_integrity_client_policy
oracle/wss11_saml_token_with_message_protection_service_policy
oracle/wss11_saml_token_with_message_protection_client_policy
oracle/wss11_saml20_token_with_message_protection_service_policy
oracle/wss11_saml20_token_with_message_protection_client_policy
SAML構成の詳細は、次の各セクションを参照してください。
SAMLログイン・モジュールは、Webサービスに代わってSAMLトークンを検証します。次に、SAMLログイン・モジュールは、検証されたトークンからユーザー名を抽出し、Oracle Platform Security Services (OPSS)に(間接的に)渡します。
「WebLogic Serverの認証プロバイダの構成」の説明のように、NameCallbackを処理する構成済のアイデンティティ・アサーション・プロバイダを呼び出すことはできません。
プロバイダは、ユーザーが存在するかどうかのみを確認します(IDアサーション・モード)存在する場合、ユーザーはアサートされ、サブジェクトが確立します。
設計時にSAML Webサービス・クライアントを構成するには、この項で説明する手順を実行します(デプロイ時にWebサービス・クライアントにSAMLポリシーを添付する場合、これらのプロパティは構成が不要で、Fusion Middleware Controlに表示されることもありません)。
これ以降の項で説明するように、ユーザー・ロールをアサーションに含め、SAMLアサーション発行者名を変更することもできます。
JSEクライアント・アプリケーションの場合、次のようにユーザー名をBindingProviderプロパティとして構成します。
Map<String,Object> reqContext = ((BindingProvider) proxy).getRequestContext() reqContext.put( BindingProvider.USERNAME_PROPERTY, "jdoe")
ここで、proxyは、実際のWebサービスの起動に使用されるWebサービス・プロキシを示します。
Java EEクライアントの場合は、ユーザーが認証済で、サブジェクトがコンテナ内で確立されていれば、ユーザー名はサブジェクトから自動的に取得されるため、追加の構成は必要ありません。
たとえば、ユーザーjdoeがすでにJEEアプリケーションに対して認証され、Java EEアプリケーションからWebサービス・コールを行う場合、ユーザー名jdoeは自動的に伝播されます。
ただし、ユーザーが認証されていない場合、JSEと同様にBindingProviderにユーザー名を構成する必要があります。
SAMLクライアント・ポリシーには、SAMLアサーションへのユーザー属性の追加に使用できるuser.attributesプロパティが含まれます。
このためには、カンマ区切りリストとして組み込む属性を指定します。たとえば、attrib1,attrib2です。指定する属性名は構成済のアイデンティティ・ストアの有効な属性に厳密に一致する必要があります。
user.attributesではサブジェクトが使用可能であり、subject.precedenceがtrueに設定されている必要があります。
Oracle WSMランタイムでは構成済のアイデンティティ・ストアからこれらの属性の値を読取り、SAMLアサーションに属性およびその値を組み込みます。
user.attributesプロパティは単一のアイデンティティ・ストアでサポートされます。デフォルトでは、リストの最初のアイデンティティ・ストアのみが使用されます。そのため、ユーザーは存在する必要があり、構成済のWebLogic Server認証プロバイダが使用するアイデンティティ・ストアで有効である必要があります。認証プロバイダは「WebLogic Serverの認証プロバイダの構成」で説明されています。
1つ以上のアイデンティティ・ストアが構成されており、すべてのアイデンティティ・ストアでユーザーを検索する必要がある場合は、次の手順を実行してすべての構成済のアイデンティティ・ストアで検索を有効にします。
ナビゲータ・ペインで「WebLogicドメイン」を開き、アイデンティティ・ストア・プロバイダの構成が必要なドメインを表示します。ドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」をクリックします。
ページのアイデンティティ・ストア・プロバイダセクションで、「構成」をクリックしてアイデンティティ・ストアを操作するパラメータを構成します。
図10-8に示すように、アイデンティティ・ストア構成ページが表示されます。
「追加」をクリックして、カスタム・プロパティを追加します。
図10-9に示すように、「true」の値を持つ「virtualize」プロパティを追加します。
「OK」をクリックして変更内容を送信します。
Fusion Middleware Controlを再起動します。
ユーザーのロールをSAMLアサーションの属性文として渡すことができます。デプロイ後にこれを実行するには、user.role.includeプロパティをtrueに構成します。ポリシー内のデフォルト値はfalseです。
設計時にユーザーのロールを構成するには、BindingProviderのuser.role.includeプロパティをtrueに設定します。
事前定義済SAMLポリシーに関してOPSSを構成するには、次の手順を実行します。
「SAMLおよびKerberosログイン・モジュールの構成」の説明に従って、SAMLログイン・モジュールを構成します。
デフォルトでは、SAMLアサーション発行者名はwww.oracle.comです。Webサービス・クライアントとWebサービス側の両方で事前定義済SAMLポリシー(またはアサーション)を使用している場合、saml.issuer.nameクライアント・プロパティはwww.oracle.comである必要があります。このため、通常はデフォルト値を使用できますが、発行者を構成することはできません。
別のユーザーの追加の詳細は、「別のSAMLアサーション発行者名の追加」を参照してください。
IDアサーション・プロバイダをWebLogic Server管理コンソールで構成します。
SAML鍵所有者ポリシーなど、SAMLアサーションに関連する署名が含まれるポリシー(アサーションから参照される鍵がメッセージの署名に使用される)、または送信者保証ポリシー(送信者の鍵がメッセージの署名に使用される)を使用する場合、「メッセージ保護に関するキーストアの設定」の説明に従って、署名と検証のための鍵と証明書を構成する必要があります。
SSLが必要なポリシーを使用する場合、「SSLに関するキーストアの構成」の説明に従ってSSLを構成する必要があります。
Webサービス・クライアントとWebサービス側の両方で事前定義済SAMLポリシー(またはアサーション)を使用している場合、SAMLアサーション発行者名は、通常、www.oracle.comです。このため、通常はデフォルト値を使用でき、発行者は構成できません。
次の2つの状況で、他の発行者を追加する必要があります。
SAMLの事前定義済Webサービス・ポリシーまたはアサーションでは、saml.trusted.issuerプロパティの値を設定します。このプロパティの値を設定する場合、信頼できる発行者を発行者リストに追加する必要があります。
SAMLクライアント側のポリシーまたはアサーションでは、saml.issuer.nameプロパティの値を設定します。このプロパティの値を設定する場合、信頼できる発行者を同じ値を持つ発行者リストに追加する必要があります。
NET/STSなどの異なるクライアントが事前定義済SAMLポリシーで保護されているWebサービスと通信する場合、その発行者を発行者リストに追加する必要があります。
発行者リストに別のSAMLアサーション発行者を追加する手順
ナビゲータ・ペインで「WebLogicドメイン」を開き、発行者の追加が必要なドメインを表示します。ドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」をクリックします。
適宜SAMLまたはSAML2ログイン・モジュールを選択し、「編集」をクリックします。
ページのSAML固有の属性セクションから、図10-10に示すように、「追加」をクリックして別の発行者名を追加します。
クライアント・ポリシーでは、デプロイ時に、SAMLクライアント・ポリシーの「構成」ページでsaml.issuer.nameの値を指定します。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドします。ポリシーのデフォルト値はwww.oracle.comです。
設計時に発行者を構成するには、BindingProviderのsaml.issuer.nameプロパティを設定します。
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サービスの |
SOAの場合:
SOAコンポジットは、1つのSOAサービス・コンポーネントとしてBPELプロセスを持ちます。BPELプロセスは、同期および非同期プロセスのプロセス編成と格納を行います。
BPELプロパティは、正確な名前javax.xml.ws.security.auth.usernameを使用して定義できます。このプロパティの値を、SOAアプリケーションが伝播するアイデンティティにすることができます。これは潜在的にBPELプロセスによって動的に決定できます。
J2EEの場合:
BindingProvider.USERNAME_PROPERTYプロパティを設定します。
wss11_saml_token_identity_switch_with_message_protection_client_policyポリシーを添付するWebサービス・クライアント(たとえば、SOA参照バインディング・コンポーネント)は、oracle.wsm.security.WSIdentityPermission権限を持つ必要があります。
Fusion Middleware Controlを使用して、oracle.wsm.security.WSIdentityPermission権限をSOA参照バインディング・コンポーネントにシステム権限として追加するには、次の手順を実行します。
ナビゲータ・ペインで「WebLogicドメイン」を開き、アプリケーションの構成が必要なドメインを表示します。ドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」→「セキュリティ」→「システム・ポリシー」をクリックします。システム・ポリシーは、現在のWebLogicドメインにデプロイされるすべてのアプリケーションに適用されるシステム全体のポリシーです。
「システム・ポリシー」ページで、「権限」フィールドの矢印アイコンを選択し、システム・セキュリティ権限を検索します。
コードベース権限のいずれかを選択して開始点として使用し、「類似作成」をクリックします。
ページの権限の詳細セクションで、「コードベース」フィールドにfile:${common.components.home}/modules/oracle.wsm.agent.common_11.1.1/wsm-agent-core.jarと入力します。
ページの「権限」セクションで、開始点の権限クラスを選択して「編集」をクリックします。
「権限クラス」フィールドにoracle.wsm.security.WSIdentityPermissionと入力します。リソース名はSOAのコンポジット名で、J2EEクライアントのアプリケーション名です。図10-11に示すように、アクションは常にassertです。
WLSTを使用してoracle.wsm.security.WSIdentityPermission権限を追加するには、次のコマンドを実行します。
grantPermission(codeBaseURL="file:${common.components.home}/modules/
oracle.wsm.agent.common_11.1.1/wsm-agent-core.jar",
permClass="oracle.wsm.security.WSIdentityPermission",
permTarget="resource=yourAppName",
permActions="assert")
このコマンドの説明
codeBaseURLはwsm-agent-core.jarを指し示している必要があります。
permTarget構文は"resource=yourAppName/compositeName"です。リソース名はSOAのコンポジット名で、J2EEクライアントのアプリケーション名です。
permActionsは必ず"assert"です。
セキュリティを強化するため、SAML署名証明書の信頼できる識別名(DN)リストを定義できます。
デフォルトの場合、Oracle WSMでは、受信した発行者名を構成済の発行者のリストと照合してチェックし、SAML署名をOWSMキーストアにある構成済の証明書と照合してチェックします。また、信頼できるDNリストを定義する場合は、SAML署名がその発行者に関連付けられている特定の証明書に基づいて署名されているかどうかが検証されます。
信頼できるDNリストの構成はオプションです。この構成オプションは、1つ以上の署名証明書を含むリストに各発行者を関連付けるためにより高度なファイングレイン制御を必要とするユーザが使用できるオプションです。信頼できる発行者のDNリストを自分で定義しない場合には、その証明書がOracle WSMのキーストアに存在する証明書によって信頼されている限り、Oracle WSMが任意の証明書による署名を許可します。
SAML署名証明書の信頼できるDNリストの定義の詳細は、「SAML署名証明書の信頼できる識別名(DN)リスト」を定義できます。
|
注意: このリリースでは、信頼できるDNリストはSAML送信者保証およびキー所有者ポリシーに対してのみ有効であり、SAML Bearerポリシーでは無効です。 |
Oracle Fusion Middleware 11g リリース1(11.1.1)では、次に示す事前定義済のポリシーとともに、Kerberosトークンもサポートされています。
oracle/wss11_kerberos_token_client_policy
oracle/wss11_kerberos_token_service_policy
oracle/wss11_kerberos_token_with_message_protection_client_policy
oracle/wss11_kerberos_token_with_message_protection_service_policy
また、次のアサーション・テンプレートを使用して、ポリシーを作成することもできます。
oracle/wss11_kerberos_token_client_template
oracle/wss11_kerberos_token_service_template
oracle/wss11_kerberos_token_with_message_protection_client_template
oracle/wss11_kerberos_token_with_message_protection_service_template
これらのアサーションおよびポリシーの詳細は、付録C「事前定義済アサーション・テンプレート」および付録B「事前定義済ポリシー」を参照してください。
この項に記載されている手順に従って、Key Distribution Center (KDC)をWebサービス・クライアントとWebサービスで使用できるように構成します。
Microsoft Active DirectoryをKDCとともに使用することもできます。「Active DirectoryのKerberosおよびメッセージ保護との使用」を参照してください。
KDCデータベースを初期化します。たとえば、UNIXでは次のコマンドをルートとして実行する場合があります。ここで、oracle.comはデフォルトのレルムです。
root# /usr/kerberos/sbin/krb5_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システムにログインします。ランダム・パスワードを使用することにより、セキュリティが強化されます。
Webサービス・クライアントは、正しいKDCに対して認証するように構成する必要があります。
KDCの構成は、UNIXホストの場合は/etc/krb5.confに存在し、Windowsホストの場合はC:\windows\krb5.iniに存在します。
例10-7に、サンプルの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はサポートされていないためです。
例10-7 サンプルの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 }
Kerberosクライアント側ポリシーを実行するWebサービス・クライアントは、アクセスを試行するサービスのサービス・プリンシパル名を認識している必要があります。サービス・プリンシパル名の設定は、「プリンシパルの作成」で行います。
「構成」ページでservice.principal.nameの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。デフォルト(プレースホルダ)値は、HOST/localhost@oracle.comです。
Kerberosクライアント側ポリシーを実行するWebサービス・クライアントは、アクセスを試行するサービスのサービス・プリンシパル名を認識している必要があります。サービス・プリンシパル名の設定は、「プリンシパルの作成」で行います。
設計時に構成のオーバーライドを使用し、次のようにサービス・プリンシパル名を指定します。
JAX-WS Clients: ((BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSSEC_KERBEROS_SERVICE_PRINCIPAL, SOAP/myhost.oracle.com@oracle.com);
正しいKDCに対してWebサービスを認証するように構成します。KDCの構成は、UNIXホストの場合は/etc/krb5.confに存在し、Windowsホストの場合はC:\windows\krb5.iniに存在します。
例10-7に、Webサービス・クライアント用のサンプルのKDC構成を示します。この例は、WebサービスのKDC構成にも適用されます。
正しいキータブ・ファイルを使用するには、次の作業を行います。
キータブ・ファイルの抽出とインストール
krb5ログイン・モジュールの変更
これらの作業は、後続の項で説明されています。
KDCからサービス・プリンシパル・アカウントのキー表ファイル(キー・タブとも呼ばれる)を抽出し、Webサービス実装のホストとなるマシンにインストールします。
たとえば、kadmin.localなどのツールを使用し、次のようにサービス・プリンシパル名のキー・タブを抽出できます。
>kadmin.local>ktadd -k /tmp/krb5.keytab SOAP/myhost.oracle.com
キータブ・ファイルを、Webサービスのホストとなるマシンにエクスポートします。キー・タブはバイナリ・ファイルです。これをFTPで転送する場合は、バイナリ・モードを使用してください。
「Configuring the SAML and Kerberos Login Modules」の説明に従って、WebサービスのKDCファイルの場所を識別するようにkrb5ログイン・モジュールを変更します。
たとえば、キータブ・ファイルが/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サービス・クライアントのチケット・キャッシュを作成するには、次の手順を実行します。
クライアント用に作成したユーザー・プリンシパルを使用して、Kerberosシステムにログインします。
>kinit fmwadmin welcome1
これにより、チケット認可チケットを含むファイルシステムにチケット・キャッシュが作成されます。このことを確認するには、次のコマンドを入力します。
>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
暗号化タイプが前述の情報を反映していることを確認します。
Webサービス・クライアントを実行します。
別の方法として、最初にKerberosにログインすることなく、Webサービス・クライアントを実行することもできます。Kerberosユーザー名とパスワードの入力を求められます。この場合、チケット・キャッシュはファイルシステムに作成されず、メモリーに保持されます。
Microsoft Active DirectoryをKey Distribution Center (KDC)とともに使用することもできます。この項では、Active DirectoryをKerberosとメッセージ保護とともに使用する場合のKDCの構成方法について説明します。
この項では、Active Directoryに習熟していることを前提として説明します。詳細については、Active Directoryのドキュメントを参照してください。
この項では、次のタスクについて説明します。
Active Directoryを使用してユーザー・アカウントを新規作成します。DES暗号化は使用しないでください。デフォルトでは、ユーザー・アカウントはRC4-HMACを使用して作成されます。
たとえば、ユーザーtestpolをユーザー・ログオン名test/testpolで作成できます。
ユーザー・ログオン名は、container/nameの形式にする必要があります。アカウントは任意のコンテナに作成できます。
ktpassを使用してキータブ・ファイルを作成します。
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サービスを設定します。
KerberosポリシーをWebサービスに添付します。
正しい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
「キータブ・ファイルの作成」で作成したキータブ・ファイルを、Webサービスのホストとなるシステムにエクスポートします。キー・タブはバイナリ・ファイルです。これをFTPで転送する場合は、バイナリ・モードを使用してください。
次のように、kinitを使用してキータブ・ファイルを検証します。
kinit -k -t <absolute path the the keytab file> <Service Principal Name>
「SAMLおよびKerberosログイン・モジュールの構成」の説明に従って、krb5ログイン・モジュールを変更し、キータブの場所とサービス・プリンシパル名を指定します。
キータブ・ファイルへの絶対パスを使用してください。また、サービス・プリンシパル名には必ず@realmnameを追加してください。たとえば、次のようにします。
principal value=test/testpol@oracle.com
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は、WS-Security 1.1標準に従って、インバウンドSOAPリクエストに対して、メッセージ・レベルの保護(つまり、メッセージ整合性とメッセージの機密保護)とSAMLベースの認証を行います。
メッセージは、WS-Securityの対称鍵テクノロジのBasic 128スイートを使用して保護されます。具体的には、メッセージ機密保護にはRSA鍵メカニズム、メッセージ整合性にはSHA-1ハッシュ・アルゴリズムが使用され、AES-128ビット暗号化も使用されます。メッセージ保護に使用できるアルゴリズムの詳細は、「サポートされているアルゴリズム・スイート」を参照してください。
そのため、キーツール(またはその他のツール)を使用してこのポリシーに必要な署名や暗号化キーを作成する場合は、必ずRSA鍵メカニズム、SHA-1アルゴリズム、そしてAES-128ビット暗号化を使用して、キーのポリシー要件を満たす必要があります。
このポリシーは対称鍵テクノロジを使用しています。対称鍵暗号は、次のような単一の共有の秘密鍵に依存します。
クライアントは、対称鍵を作成し、それを使用して署名してメッセージを暗号化し、そしてリクエスト・メッセージでWebサービスとそれを共有します。
対称鍵を保護するために、リクエスト・メッセージで送信された対称鍵は、サービスの証明書を使用して暗号化されます。
Webサービスはリクエスト・メッセージ内の対称鍵を使用して、リクエスト・メッセージの署名を検証してそれを復号化し、それからレスポンス・メッセージに署名して暗号化します。
次のプロセス・フローを考慮します。
リクエストを作成するために、Oracle WSMエージェントは次のことを行います。
共有の対称鍵を生成し、それを使用してリクエスト・メッセージの署名と暗号化の両方を行います。
その独自の秘密鍵を使用して、リクエスト・メッセージの署名を裏書きします。
Webサービスの公開鍵を使用して、対称鍵を暗号化します。
対称鍵をリクエストとともにWebサービスに送信します。クライアントはリクエストで公開鍵を送信して、Webサービスがその署名を検証できるようにします。
Webサービスがリクエストを受け取ると、次のことを行います。
秘密鍵を使用して、対称鍵を復号化します。
対称鍵を使用して、リクエスト・メッセージを復号化し、その署名を検証します。
リクエスト・メッセージ内のクライアントの公開鍵を使用して、その裏書署名を検証します。
クライアントにレスポンスを送信するために、Webサービスは次のことを行います。
リクエストとともに送信されたクライアントが生成した同じ対称鍵を使用して、レスポンス・メッセージに署名します。
クライアントが生成した同じ対称鍵を使用して、レスポンス・メッセージを暗号化します。
Oracle WSMエージェントはレスポンス・メッセージを受け取ると、次のことを行います。
最初に生成した対称鍵を使用して、レスポンス・メッセージを復号化します。
最初に生成した対称鍵を使用して、レスポンス・メッセージの署名を検証します。
クライアントとWebサーバーが、同じキーストアにアクセスする同じドメインにある場合は、同じ秘密/公開鍵のペアを共有できます。
つまり、クライアントが秘密鍵"orakey"を使用してリクエスト・メッセージの署名を裏書きし、公開鍵"orakey"を使用して対称鍵を暗号化できます。次に、Webサービスが公開鍵"orakey"を使用して裏書きを検証し、秘密鍵"orakey"を使用して対称鍵を復号化します。
デモの目的で、このユース・ケースでは1つの鍵ペアを作成します。
クライアントとWebサーバーが同じドメインになく、同じキーストアにアクセスしない場合は、クライアントとWebサービスは各自が秘密/公開鍵のペアを持つ必要があります。
表10-2に示すように、マルチドメインのユース・ケースで次の要件について考慮します。
表10-2 マルチドメインのユース・ケース要件
| Webサービス・クライアント | Webサービス |
|---|---|
|
クライアントのキーストアに独自の秘密/公開鍵のペアが必要です。 |
サービス・キーストアに独自の秘密/公開鍵のペアが必要です。 |
|
Webサービスの公開鍵が必要です。 |
クライアントのキーストア内の公開鍵に対応する中間証明書とルート証明書が必要です。 これらの証明書を使用して、信頼される証明チェーンを生成して署名を検証します。 |
|
ランタイムに対称鍵を生成します。 |
対称鍵が必要ですが、これはリクエスト・メッセージで送信されます。 |
クライアントが対称鍵を暗号化するために使用する公開鍵、つまりWebサービスの公開鍵については、次の2つのアプローチがあります。
「サービス・アイデンティティ証明拡張の使用」で説明されているように、Webサービスのbase64エンコードされた公開証明書は、Webサービス・クライアントが使用するためにWSDLでパブリッシュされます。そのため、この使用方法では、Webサービスの公開鍵はクライアントのキーストアになくても構いません。
別の方法として、「構成」ページでkeystore.recipient.aliasの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。キーストア受信者の別名は、アウトバウンドSOAPメッセージの暗号化用のキーを取得するときにキーストア内の公開鍵を検索するために使用される別名を指定します。この使用方法では、Webサービスの公開鍵はクライアントのキーストアにある必要があります。
クライアント・ポリシーのsaml.issuer.nameプロパティは、SAMLトークンの発行者とwww.oracle.comの値のデフォルトを特定します。このユース・ケースでは、www.oracle.comデフォルトを使用します。
オプションで、「構成」ページでsaml.issuer.nameの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。
ポリシーで別のSAML認証局(発行者)を使用する場合は、その発行者名をクライアントで構成し、SAMLログイン・モジュール内の使用可能な発行者のリストに含める必要があります。この方法については、「別のSAMLアサーション発行者名の追加」を参照してください。
この項では、SAMLメッセージ保護のユース・ケースを構成する手順について説明します。次の項目について説明します。
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管理コンソールでユーザーを作成する手順
左側のペインで、「セキュリティ・レルム」を選択します。
「セキュリティ・レルム」ページの「サマリー」で、レルムの名前を選択します(たとえば、myrealm)。
「レルム名」ページの「設定」で、「ユーザーとグループ」→「ユーザー」を選択します。
「ユーザー」表に、管理プロバイダで定義されているすべてのユーザーの名前が表示されます。
「新規」をクリックします。
「新規ユーザーの作成」ページの「名前」フィールドに、ユーザーの名前を入力します。
ユーザー名は大文字と小文字が区別され、一意である必要があります。カンマ、タブ、および次の「、」で区切ったリストの文字は使用しないでください。<>、#、|、&、?、( )、{ }
(オプション)「説明」フィールドに説明を入力します。説明は、ユーザーの完全な名前にします。
「プロバイダ」ドロップダウン・リストで、ユーザーの認証プロバイダを選択します。
セキュリティ・レルムに複数のWebLogic認証プロバイダが構成されている場合は、それらがリストに表示されます。新規ユーザーの情報を格納するWebLogic認証プロバイダのデータベースを選択します。
「パスワード」フィールドに、ユーザーのパスワードを入力します。
WebLogic認証プロバイダで定義されるユーザーの最大パスワード長は8文字です。
「パスワードの確認」フィールドにユーザーのパスワードを再入力します。
「OK」をクリックして変更内容を保存します。
ユーザー名が「ユーザー」表に表示されます。
この項では、keytoolユーティリティを使用してJavaキーストアを作成および管理する方法の概要を説明します。キーストアの作成方法、および秘密鍵のペアとCA証明書のロード方法を取り上げます。
keytoolユーティリティのコマンドや引数の詳細は、次のWebサイトを参照してください。http://download.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html
|
注意: -genkeyコマンドを使用してエンティティをキーストアに追加してキーペア(公開鍵と秘密鍵)を生成する場合、または-importコマンドを使用して証明書または証明書チェーンを信頼できる証明書のリストに追加する場合は、別名を指定します。その後のkeytoolコマンドでは、この同じ別名を使用してエンティティを参照する必要があります。 |
新しいキー・ペアと自己署名証明書を作成します。
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ユーティリティから必要な鍵とキーストアのパスワードを要求するプロンプトが表示されます。これらのパスワードは後で必要になります。
認証局への証明書リクエストを生成します。
リクエストの生成には、-certreqコマンドを使用します。次のコマンドでは、orakey別名の証明書リクエストが生成されます。
CAから証明書または証明書チェーンが返されます。
keytool -certreq -alias orakey -sigalg "SHA1withRSA" -file certreq_file -storetype jks -keystore default-keystore.jks
自己署名証明書を信頼できるCA証明書で置き換えます(インポートします)。
既存の自己署名証明書をCAから返される証明書で置き換える必要があります。これを実行するには、-importコマンドを実行します。次のコマンドでは、default-keystore.jksキーストアの信頼できるCA証明書で置き換えます。keytoolユーティリティから必要なパスワードを要求するプロンプトが表示されます。
keytool -import -alias orakey -file trustedcafilename -keystore default-keystore.jks
次の手順を実行して、Oracle Web Services Managerキーストアを構成します。
ナビゲータ・ペインで「WebLogicドメイン」を開き、キーストアの構成が必要なドメインを表示します。ドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」をクリックします。
ページの下部近くにある「キーストア」コントロールのプラス記号(+)をクリックして開き、「構成」をクリックします。
図10-1に示すように、Web Services Managerの「キーストアの構成」ページが表示されます。
「キーストア管理の構成」チェック・ボックスがまだ選択されていない場合は、選択します。
作成するキーストアのパスと名前を入力します。デフォルトのキーストア名は、このユース・ケースで使用したように、default-keystore.jksです。キーストア・タイプはJKSにする必要があります。
キーストアのパスワードを入力して確認します。
署名と暗号化キーの別名とパスワードを入力します。
このユース・ケースでは、orakeyは署名と暗号化キーの両方の別名です。
パスワードを確認します。
「OK」をクリックして変更内容を送信します。
このページのフィールドを変更した場合、変更内容を反映するにはFusion Middleware Controlを再起動する必要があります。
「資格証明ストア・プロバイダの構成」で説明されているように、資格証明ストアには復号化キーのパスワードを格納する必要があります。キー名としてkeystore.enc.csf.keyを使用します。
「単一のサブジェクトへのポリシーの添付」の説明に従って、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サービス・クライアントへのポリシーの添付」の説明に従って、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の値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。
この項では、事前定義済WS-Trustポリシーとその構成および使用方法について説明します。次の項目について説明します。
WS-Trust 1.3仕様ではセキュリティ・トークンを要求および発行するためのフレームワークを提供するWS-Securityおよびブローカ信頼関係への拡張が定義されます。WS-Trust拡張では、セキュリティ・トークンの発行、更新および検証のための方法を提供します。
Webサービス・クライアントとWebサービス間の通信を保護するには、両者がセキュリティ証明書を交換する必要があります。WS-Trust仕様の定義に従って、これらの証明書は信頼できるSecurityTokenService(STS)から取得できます。これは、信頼ブローカとしての役割を果たします。つまり、Webサービス・クライアントおよびWebサービスの両方がSTSを信頼し、相互運用セキュリティ・トークンを提供する必要があります。
この項の内容は次のとおりです。
通常、環境はSTSが1つのみあります。多数のさまざまなWebサービスがあり、それらのすべてがこのSTS構成ポリシーに接続されている場合、ポリシーを変更することによって別のSTSを参照するようにすべてのWebサービスを変更することができます。
また、STSもWebサービスです。STSと通信するには、クライアント・アプリケーションが認証を試みるクライアントから受け付けることのできるport-uri、port-endpoint、wsdl-uri、およびセキュリティ・トークンなどのSTSの詳細を把握する必要があります。
STS情報をクライアントに対して使用可能にできる2つのメカニズムがあります。
自動(クライアントSTS)ポリシー構成(STS用の自動ポリシー構成の設定を参照)が含まれています。STS WSDL ドキュメント自動ポリシー構成はSTSに関する情報をダイナミックに生成します。
クライアントではなく、WebサービスにSTS構成ポリシーが添付されている場合、自動ポリシー構成ががトリガーされます。また、STS構成ポリシーで指定されている情報のみがターゲットSTSのport-uriです。
このポリシーが発行済のトークン・サービス・ポリシーと一緒にWebサービスに添付されている場合、STSのport-uriはWebサービスWSDLのIssuedTokenアサーションでIssuer-Addressとして表示されます。結果として、その他すべてのSTS情報(ターゲット・ネームスペース、サービス名、エンドポイントなど)がSTS WSDLにアクセスすることにより取得され、STS構成としてメモリーに保存されます。この情報はメモリー内にのみ格納され、MDS内には保持されません。
WebサービスのSTS構成ポリシーでSTS URIを指定し、Webサービスに接続すると、クライアントはそのSTSを強制的に使用するため、オーバーライドできません。
自動ポリシー構成を使用せず、代わりに、STS構成ポリシーをクライアントに添付し、Webサービスを呼び出す前にSTS関連のすべての情報(port-endpoint、port-uri、公開鍵の別名、STSの認証に使用するOracle WSMクライアント・ポリシーへの参照)を指定します。この場合、STS構成ポリシーのランタイムですべての情報がすでに使用可能です。
通常のトークン・リクエスト/レスポンス・プロセスは次のように動作します。これらのステップの詳細は、WS-Trustユース・ケースの例で説明しています。
Webサービス・クライアントでWebサービスの起動を必要とします。Oracle WSMエージェントではWebサービスのWSDLを取得して、発行済のトークン・サービス・ポリシーの抽出を試みます。Oracle WSMエージェントでは(オプションでオーバーライドされる)ローカル・クライアント・ポリシーを使用してWSDLで特定されているSTSと通信します。
Webサービス・ポリシーでは特定のSTSからの発行済のトークンを要求できます。
Webサービス・クライアントでは、STSによるトークンの発行を要求します。Webサービス・クライアントでは特定のSTSからトークンを要求できます。
リクエスト・セキュリティ・トークン(RST)はセキュリティ・トークンのリクエストです。RequestSecurityTokenResponse (RSTR)は、要求したユーザーのリクエスト内容を使用してRSTにレスポンスしてSTSが生成するリクエストです。
Webサービス・クライアントでは、STSが送信したRSTRを処理し、発行済のトークンをWebサービスに伝搬します。
Webサービスは、発行済のトークンを処理および検証して、レスポンスを生成して戻します。
この項では、WS-Trustのサンプルのユース・ケースについて説明します。
Webサービス・クライアントではWebサービスを起動します。WebサービスのWSDLはWebサービスが特定のSTSからのセキュリティ・トークンを要求していることを示します。
Webサービス・クライアント(リクエスタ)は、付随する資格証明を使用して認証リクエストをSTSに送信します。
STSではクライアントが示す資格証明を検証し、レスポンスで、クライアントがSTSで認証されていることをの証明を提供するセキュリティ・トークンを発行します。レスポンス・メッセージRSTRにはトークンが含まれており、オプションで認証されたユーザー・リクエストが含まれています。
リクエスタはRSTRを検証し、トークンを抽出して、Webサービスにそのトークンを渡します。
Webサービスでは発行済のトークンを受信し、トークンが信頼できるSTSによって発行されていることを検証します。これにより、クライアントはSTSに正常に認証されることが証明されます。
トークンが検証されると、Webサービスでは要求を処理し、レスポンスを返します。
図10-12に、リクエスタ、STS、およびWebサービス間のメッセージ・フローを示します。
「On Behalf Of」はアイデンティティ伝播のユース・ケースです。このユース・ケースではWebサービス・クライアントが別のエンティティに代わってSTSトークンを要求します。
次のシナリオを考えてみます。
Webサービス・クライアントはSTSを起動して、他のエンティティのトークンを取得します。このエンティティはエンド・ユーザーであったり、他の外部エンティティである場合があります。エンティティの証明書はonBehalfOf要素のRSTに含まれています。
STSではWebサービス・クライアントが提示する証明書を検証し、onBehalfOf要素で特定されるエンティティのセキュリティ・トークンを発行します。
Webサービス・クライアントではRSTRを検証し、トークンを抽出して、Webサービスにそのトークンを渡します。
Webサービスでは、エンド・ユーザーのSAMLアサーションを受信し、そのトークンが信頼できるSTSによって発行されたことを検証します。
「On Behalf Of」ユース・ケースは、表8-1に示すsts.auth.on.behalf.of.csf.keyプロパティおよびon.behalf.ofプロパティに依存しています。「On Behalf Of」のユーザー名をサブジェクトから取得すると、パスワードのないユーザー名になります。
sts.auth.on.behalf.of.csf.keyにより「On Behalf Of」ユーザー・エンティティのCSFキーが特定される場合は、CSFキーを使用して確立されるアイデンティティが他のエンティティの代理で送信されます。このアイデンティティはパスワード付きまたはなしのユーザー名として使用できます。
STSからのRSTRレスポンス・メッセージには、戻されるトークンの有効性を示す存続期間の要素(<trust:Lifetime>)を含む場合があります。存続期間の要素がある場合、Oracle WSMでタイムスタンプが検証され、レスポンスの有効期限が切れている場合はメッセージを拒否します。
STSでは理論的にはクライアントからどのようなトークンでも受信し、他のトークンと交換しますが、実際は、STSは、通常、次のいずれかのトークンを受け入れ、SAMLアサーションを戻します。
ユーザー名トークン。このトークン・タイプでは、次のように処理されます。
Webサービス・クライアントでユーザー名およびパスワードがSTSに送信されます。
STSでパスワードが検証され、SAMLアサーションが戻されます。
クライアントでSAMLアサーションがWebサービスに送信されます。
このシナリオはWebサービスにパスワードを検証する機能がなく、パスワードの検証をSTSに依存している場合に役立ちます。
Kerberosトークン。このトークン・タイプでは、次のように処理されます。
クライアントでユーザー名およびパスワードがKDCに送信され、Kerberosトークンが取得されます。
クライアントでKerberosトークンがSTSに送信され、SAMLアサーションが取得されます。
クライアントでSAMLアサーションがWebサービスに送信されます。
このシナリオはWindows環境で役立ちます。Windowsマシンで稼働するクライアントにはログオン・ユーザー・コンテキストが含まれており、このコンテキストを使用してそのユーザーのSTSからSAMLアサーションを取得できます。
このシナリオでは、クライアントがパスワードを持たないため、ユーザー名トークンを使用できません。使用できるのはKerberosのみです。
X509トークン -- このトークン・タイプでは、クライアントが秘密鍵を使用してSTSに対するクライアント自身の認証を行います。
レスポンスでは、STSは、通常、次のトークンのいずれかを戻します。
Key SymmetricのSAML Holder。STSにより戻されるSAMLアサーションは、そのクライアントのトークン(ユーザー名トークン、Kerberos、X509など)をSTSに送信する特定のクライアントのみを対象としています。
統制外クライアントはこのSAMLアサーションを独占し、使用することはできません。これは、対称または非対称の「証明鍵」によって実現します。
証明鍵の特定方法(SAML HOKのみ)に説明するように、対称証明鍵がSTS側またはクライアント側で、または、両方の側から入力を取得して、生成されます。
STSでは、Webサービスのみを複合化できる暗号化フォーム内にSAML HOKアサーションにこの対称証明鍵を入力します。その後、STSではSAMLアサーション全体(暗号化証明鍵)に署名し、クライアントに送信します。
クライアントでこのSAMLアサーションをサーバーに送信する場合は、この署名鍵を使用して内容を署名する必要もあります。Webサービスでは、まず、SAMLアサーションのSTS署名を検証し、SAMLアサーションから証明鍵を抽出して、その鍵を複合化し、クライアントの署名を検証します。このクライアントの署名は、クライアントに署名鍵があることをサーバーに「証明」します。
この証明鍵がクリア・テキストに送信されることはないため、統制外クライアントがネットワーク・スニフィングにより証明鍵を取得することはできません。統制外クライアントがネットワーク・スニッフィングによりSAMLアサーションを取得したとしても使用できません。これは、証明鍵がなく、証明鍵により取得したアサーションを署名できないためです。そのため、統制外クライアントは自身がサーバーSAMLアサーションを使用できることをサーバーに対して署名できません。
非対称鍵のSAML Holder。非対称証明鍵は次のように動作します。
クライアントで公開鍵/秘密鍵の組合せが生成されます。
クライアントでは公開鍵を維持し、トークン(ユーザー名トークン、Kerberos、X509など)と一緒にSTSに安全に送信します。
STSでクライアントのトークンが検証され、公開鍵を含むSAMLアサーションが戻されます。SAMLアサーション全体(公開鍵を含む)はSTSで署名され、クライアントに戻されます。
その後、クライアントでSAML HOK非対称アサーションがWebサービスに送信され、その公開鍵-秘密鍵ペアの公開鍵を使用して署名されます。
WebサービスでSAMLアサーションのSTSの署名が検証され、SAMLアサーションから公開鍵が抽出され、この公開鍵を使用してクライアントの署名が検証されます。
このクライアントの署名により、SAMLアサーションが正しく使用されており、独占され、再実行されないことがWebサービスに対して証明されます。
|
注意: SAML HOKの対称鍵の場合とは異なり、SAML HOKのこの公開鍵は暗号化されません。これにより、STS側で必要な構成が削減されます。SAML HOK対称では、そのWebサービスの対称鍵を暗号化できるように各Webサービスの証明書でSTSを構成する必要があります。これは、SAML HOK非対称では不要です。 また、同じSAML HOK非対称トークンは特定のWebサービスの鍵に暗号化されないため、Webサービスに送信できます。 |
|
注意: 公開鍵/秘密鍵の組合せがある場合でも、証明書は含まれていません。つまり、公開鍵は証明書を必要とする認証局には送信されません。代わりに、STSがCAと同様の役割を果たします。CAが公開鍵を取り込み、証明書を戻します。この場合、STSが公開鍵を取り込み、SAMLアサーションを戻します。 ただし、存続期間が通常長年にわたる証明書とは異なり、STSが発行するSAMLアサーションの存続期間は通常数時間です。この後、クライアントは新し鍵ペアを生成し、新しいSAMLアサーションを要求する必要があります。 存続期間が短いため、証明書が必要な失効確認を行う必要がありません。このため、管理するクライアント鍵がないためクライアント側で役立ちます。 |
SAML Bearer -- SAML Bearer鍵にはこの鍵に関連付けられている署名鍵がありません。そのため、孤立クライアントによる独占および再実行を防止するためにはSSLを介してSAML Bearer鍵を使用する必要があります。
鍵のSAML Holder (HOK)では、クライアントおよびWebサービス間の通信の保護に署名鍵が必要です。証明鍵は必要なセキュリティ・トークンに関連付けられているトークンの所有の証明を示します。
<sp:IssuedToken>ポリシー・アサーションの<key-type>エントリのoracle/wss11_sts_issued_saml_hok_with_message_protection_service_policyポリシーに証明鍵のタイプの要件を指定します。例:
<orasp:request-security-token-templateorasp:key-type = "Symmetric"
または
orasp:key-type = "Public"
対称証明鍵、非対称証明鍵および証明鍵なし(未定義)がサポートされています。
<key-type>のこれらの使用可能な値はWS-Trust 1.3仕様に含まれています。
http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey
http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey
Webサービスのセキュリティによって対称証明鍵が要求される場合、リクエスタは証明鍵の計算に含めることのできる鍵資料(エントロピー)を渡すことができます。クライアント・エントロピー、STSエントロピーまたはその両方を要求するかどうかは、Webサービス・ポリシーで指定できます。
ただし、STSでは証明書鍵で使用する内容を決定します。トークン・リクエストを処理するときは、STSでは次を実行できます。
クライアントのエントロピーを証明鍵の唯一の鍵構成要素として受け入れます。この場合、RSTRにある<wst:RequestedProofToken>要素はありません。証明鍵は暗黙的に指定されます。
Oracle WSMエージェントでは鍵構成要素としてクライアント・エントロピーを使用し、署名および暗号化を行います。
クライアントのエントロピーを証明鍵の唯一の鍵構成要素として受け入れ、追加のSTSサーバー側のエントロピーを、両方の部分鍵構成要素の関数として証明鍵を計算するための部分的な鍵構成要素として含めます。
RSTRのSTS提供のエントロピーを含む<wst:Entropy>要素があります。<wst:RequestedProofToken>要素はRSTRにもあり、計算された鍵メカニズムを含みます。アルゴリズムのデフォルト値はhttp://docs.oasis-open.org/ws-sx/ws-trust/200512/CK/PSHA1です。
Oracle WSMエージェントおよびSTSは、指定された計算済鍵メカニズムを使用する両方のエントロピーを組み合せることにより、証明鍵を計算します。
クライアント側のエントロピーを拒否し、STSサーバー側のエントロピーを証明鍵の唯一の鍵構成要素として使用します。
証明鍵を含むRSTR内には<wst:RequestedProofToken>要素があります。Oracle WSMエージェントでは鍵構成要素としてSTSエントロピーを使用し、署名および暗号化を行います。
通常、STSではSAML HOKトークンまたはSAML Bearerトークンが戻されます。ただし、STSではSAML送信者保証トークンを戻すことができます。
SAML送信者保証ではまったく異なる信頼モデルが使用されます。HOKおよびBearerでは、STSによりSAMLアサーションが発行され、STSによって署名されます。この場合、Webサービスはクライアントを直接信頼せず、STSを信頼します。WebサービスはHOKトークンまたはBearerトークンを受信し、信頼できるSTSに対して署名が検証されます。
この間接的な信頼モデルはトラスト・ストア管理を大幅に簡略化します。つまり、メッセージ保護を使用する5つのWebサービスと通信する5つのクライアントがある場合、それぞれのWebサービスが5つのクライアントの公開鍵を把握している必要があります。そのため、Webサービスとクライアントの間にSTSが介在する場合、WebサービスがSTSの公開鍵のみを把握している必要があります。
SAML送信者保証では、Webサービスがクライアントを直接信頼します。SAML送信者保証トークンは、通常、クライアントにより直接生成され、クライアントの公開鍵によって署名されます。ただし、クライアントがトークンの生成をSTSに依頼することができます。この場合、STSはSAMLアサーションを署名しないで、クライアントにこのアサーションを戻すだけです。クライアントではSAML送信者保証トークンを以前と同様に署名して、Webサービスに送信します。Webサービスは、クライアントがSTSから取得されるSAML送信者保証を取得済であることを認識していないため、クライアントの署名を確認します。
自動ポリシー構成では、STS WSDLドキュメントを解析してSTSに関する情報を動的に生成します。
STS構成ポリシーが(クライアントではなく)Webサービスに添付されている場合は、クライアントからサーバーへの最初の接続で自動ポリシー構成がランタイム時に実行されます。
STS構成ポリシー(oracle/sts_trust_config_service_policy)で指定する唯一の情報は、ターゲットSTSのport-uriです。このポリシーが(発行済のトークン・サービス・ポリシーと一緒に)Webサービスに添付されている場合、STSのport-uriはWebサービスWSDLのIssuedTokenアサーションのIssuer-Addressとして表示されます。
その結果、Oracle WSMではSTS WSDLにアクセスすることによってその他のSTS情報(ターゲット・ネームスペース、サービス名、エンドポイントなど)が取得され、STS構成としてメモリー内に保存ます。この情報はメモリー内に保存されますが、MDSでは保持されません。
この項の内容は次のとおりです。
自動ポリシー構成を使用してSTSとの通信を問題なく行うためにはいくつかの要件があります。
oracle/sts_trust_config_service_policyポリシーをWebサービスに添付する必要があります。添付しない場合、自動ポリシー構成を使用できないため、代わりに、「Webサービス・クライアントからのSTS構成ポリシーの手動による構成: 主要な手順」の説明に従って、クライアントのoracle/sts_trust_config_client_policyポリシーを手動で構成する必要があります。
信頼はWebサービスおよびクライアント間のものであるため、SAML送信者保証確認で自動ポリシー構成を使用することはできません。WebサービスのWSDLにはSTSに関する情報が一切ありません。
STSの証明書および公開鍵の別名がキーストア内にある必要があります。デフォルトの別名はsts-csf-keyです。これを実施する方法の詳細は、「メッセージ保護のためのキーストアの設定」を参照してください。
クライアントの公開鍵がSTSキーストアで使用可能である必要があります。
自動ポリシー構成を使用するには、次の手順を実行します。
自動ポリシー構成用のポリシーの構成
自動ポリシー構成のポリシーを構成するには、次の手順を実行します。
Webサービスが信頼し、そのSTSの公開証明書をOracle WSMキーストアにインポートするSTSを決定します。
オプションで、「証明書のSAMLによる署名のための信頼できる識別名リストの定義」の説明に従って、STSの識別名を信頼できるSTSリストに追加します。
SAML HOK対称を使用する場合は、WebサービスのOracle OpenSSO STS構成およびWebサービスの証明書にエントリを追加する必要があります。STSではこの証明書を使用して対称鍵を暗号化します。
sts_trust_config_service_policyポリシーのコピーを作成します。
orasp:port-uriフィールドを編集してSTSのport-uriを追加します。
STSは、通常、異なる入力および出力トークン・タイプに対して複数のURIポイントを公開しているため、必要なトークンに対応するURIを使用します。Oracle OpenSSO STSでは、orasp:port-uriの使用可能な値は次のとおりです。
http://<host:port>/openssosts/sts/wss10x509
http://<host:port>/openssosts/sts/wss10un
http://<host:port>/openssosts/sts/wss11kerberos
https://<host:ssl_port>/openssosts/sts/tlswss10un
自動ポリシー構成用のWebサービス・クライアントの構成
自動ポリシー構成のWebサービス・クライアントを構成するには、次の手順を実行します。
Webサービスが要求するトークンの種類に応じて、Webサービス・クライアントに発行されたトークン・ポリシーを添付します。
次の事前定義済の発行されたトークン・ポリシーが提供されます。
SAML HOKでは、oracle/wss11_sts_issued_saml_hok_with_message_protection_client_policy。
SAML Bearerでは、oracle/wss_sts_issued_saml_bearer_token_over_ssl_client_policy。
ユース・ケースに応じて発行されたトークン・ポリシーの次のプロパティを設定またはオーバーライドします。プロパティの説明については、表8-1を参照してください。
sts.auth.user.csf.key
sts.auth.x509.csf.key
sts.keystore.recipient.alias
sts.auth.keytab.location
sts.auth.caller.principal.name
sts.auth.service.principal.name
sts.auth.on.behalf.of.csf.key
on.behalf.of
メッセージ保護のためSTS通信を行うクライアントでは、sts.keystore.recipient.aliasを使用します。STS通信を行うクライアントがwss11メッセージ保護を使用する場合はsts.keystore.recipient.aliasで十分です。
ただし、wss10メッセージ保護を使用する場合は、さらに、クライアントに署名鍵および暗号化鍵を設定して、これらの鍵の信頼をSTS構成にインポートする必要があります。
STSの公開証明書および資格証明がキーストアにあり、クライアントの公開鍵がSTSキーストアで使用可能であることを確認します。これを実施する方法の詳細は、「メッセージ保護のためのキーストアの設定」を参照してください。
自動ポリシー構成用のWebサービスの構成
編集されたsts_trust_config_service_policyをWebサービスに添付します。
issued-tokenサービス・ポリシー(クライアントに添付するポリシーに対応する)を添付します。事前定義済の発行済トークン・ポリシーには次の2つがあります。
oracle/wss11_sts_issued_saml_hok_with_message_protection_service_policy -- これは、サービスでSAML HOK非対称または対称を受け入れる必要がある場合に使用します。このポリシーではSSLを使用しないでください。
他のすべてのwss11メッセージ保護ポリシーと同様に、暗号化鍵を設定する必要があります。
ポリシーの一部のオプションを変更できます。たとえば、SAML 1.1または2.0のどちらが必要であるか、非対称鍵または対称鍵のどちらが必要かなどのオプションです。
oracle/wss_sts_issued_saml_bearer_token_over_ssl_service_policy -- SAML Bearerが必要な場合にこれを使用します。ただし、このポリシーを使用するにはSSLのWebサービスを設定する必要があります。
SAML 1.1または2.0のどちらが必要かを指定できます。
必要に応じて、issued-tokenサービス・ポリシーのkeystore.enc.csf.keyをオーバーライドします。
クライアントの公開鍵がWebサービス・キーストアで使用可能であることを確認します。
「STS用の自動ポリシー構成の設定」の説明に従って、WebサービスからSTS構成ポリシーを構成することをお勧めします。ただし、WebサービスからSTS構成ポリシーを構成しなかった場合、またはSAML送信者保証確認方法を使用する場合は、Webサービス・クライアントからこのポリシーを構成する必要があります。
Webサービス・クライアントからSTS構成ポリシーを構成するには、次の手順を実行します。
オプションで、Fusion Middleware Controlを使用して、oracle/sts_trust_config_template(「新しいWebサービス・ポリシーの作成」参照)または既存のoracle/sts_trust_config_client_policyポリシー(「既存のポリシーからのWebサービス・ポリシーの作成」を参照)から新しいポリシーを作成します。
独自のポリシーを設定すると、構成がより明確になる場合があります。
Fusion Middleware Controlを使用して選択したoracle/sts_trust_config_client_policyポリシーを編集します。
事前定義済oracle/sts_trust_config_client_policyポリシーが例10-8に示されます。少なくとも、次の情報を指定する必要があります。
発行者アドレス -- Port-uriはSTSの実際のエンドポイントURIです。
OWSMセキュリティ・ポリシー参照 -- policy-reference-uriはクライアント・ポリシーのURIで、クライアントがSTSと通信するために使用されます。選択するポリシーは、WSDLで特定されるSTSの認証要件に応じて異なります。
このパラメータをどのように設定するかにより、後で設定する内容または発行トークン・クライアント・ポリシーでオーバーライドする必要のある内容が決定されます。
policy-reference-uriユーザー名ベースのポリシーを参照している場合、sts.auth.user.csf.keyパラメータを後で構成し、STSを認証してユーザー名トークンを作成します。また、sts.auth.x509.csf.keyを構成して、署名および暗号化鍵の別名を指定します。
policy-reference-uriでx509ベースのポリシーを参照している場合は、後で、sts.auth.x509.csf.keyパラメータを構成して、STSを認証するX509証明書を指定します。
port-endpoint -- これは、target-namespace#wsdl.endpoint(service-name/port-name)と指定されるWebサービスのエンドポイントです。
STS証明書の別名 -- sts-keystore-recipient-aliasは、キーストアに追加したSTS証明書の別名です。デフォルトの別名はsts-csf-keyです。
例10-8 oracle/sts_trust_config_client_policy
<orasp:sts-trust-config xmlns:orasp="http://schemas.oracle.com/ws/2006/01/securitypolicy" xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy" orasp:policy-reference-uri="oracle/wss10_username_token_with_message_protection_client_policy" orasp:port-endpoint="target-namespace#wsdl.endpoint(service-name/port-name)" orasp:port-uri="http://host:port/sts-service" orasp:soap-version="12" orasp:sts-keystore-recipient-alias="sts-csf-key" orasp:wsdl-uri="http://host:port/sts?wsdl" orawsp:Enforced="true" orawsp:Silent="true" orawsp:category="security/sts-config" orawsp:name="STS Trust Configuration"> <orawsp:bindings> <orawsp:Config orawsp:configType="declarative" orawsp:name="StsTrustConfig"> <orawsp:PropertySet orawsp:name="standard-security-properties"> <orawsp:Property orawsp:contentType="constant" orawsp:name="role" orawsp:type="string"> <orawsp:Value>ultimateReceiver</orawsp:Value> </orawsp:Property> </orawsp:PropertySet> </orawsp:Config> </orawsp:bindings> </orasp:sts-trust-config>
変更内容を保存します。
未選択の場合は、表10-3に示されている発行トークン・クライアント・ポリシーを選択します。選択肢は次のとおりです。
oracle/wss_sts_issued_saml_bearer_token_over_ssl_client_policy
oracle/wss11_sts_issued_saml_hok_with_message_protection_client_policy
oracle/wss11_sts_issued_saml_with_message_protection_client_policy
「オーバーライド可能なクライアント・ポリシーの添付」の説明に従って、両方のWebサービス・クライアント・ポリシーをWebサービス・クライアントに添付します。ポリシーは次の順序で添付する必要があります。
sts_trust_config_client_policy
発行済トークン・クライアント・ポリシー
oracle/sts_trust_config_client_policyの複数のインスタンスを添付する場合、生成されるエラーはありませんが、実行されるインスタンスは1つに限られ、それがどのインスタンスであるかを制御することはできません。
Fusion Middleware Controlを使用して選択した発行トークン・クライアント・ポリシーを編集します。
変更内容を保存します。
WS-TrustでのSAML送信者保証を設定するには、発行済トークン・ポリシーを使用しないでWebサービスを構成します。つまり、oracle/wss11_saml_token_with_message_protection_service_policyポリシーを使用します。
発行トークン・ポリシーでクライアントを構成します。oracle/wss11_sts_issued_saml_with_message_protection_client_policyを使用します。これは、SAML送信者保証用であり、STS構成ポリシーでもあります。
自動ポリシー構成機能(「STS用の自動ポリシー構成の設定」を参照)は、WebサービスWSDLではSTSに関する情報が含まれないため、SAML送信者保証では使用できません。
使用可能なWS-Trustポリシーは、表10-3にリストされています。
表10-3 使用可能なWS-Trustポリシー
| 名前 | 説明 |
|---|---|
|
oracle/sts_trust_config_service_policy |
このポリシーは、トークン交換のためのSTSの起動に使用するSTS構成情報を指定するために使用します。このポリシーはWebサービスと一緒に使用します。 |
|
oracle/sts_trust_config_client_policy |
このポリシーは、トークン交換のためのSTSの起動に使用するSTS構成情報を指定するために使用します。このポリシーは、自動ポリシー構成を使用しない場合にのみWebサービスと一緒に使用します。 |
|
oracle/wss_sts_issued_saml_bearer_token_over_ssl_client_policy |
このポリシーでは、信頼できるSTSが発行したSAML Bearerアサーションを挿入します。メッセージはSSLを使用して保護されます。 |
|
oracle/wss_sts_issued_saml_bearer_token_over_ssl_service_policy |
このポリシーは、WS-Security SOAPヘッダーの、確認方法がBearerのSAMLトークンに含まれる資格証明を使用してユーザーを認証します。SAMLトークンの資格証明は、SAMLログイン・モジュールに対して認証されます。このポリシーは、トランスポート・プロトコルによりSSLメッセージ保護が提供されることを検証します。このポリシーは、SOAPベースのエンドポイントで適用できます。 |
|
oracle/wss11_sts_issued_saml_hok_with_message_protection_client_policy |
このポリシーでは、信頼できるSTSが発行したSAML HOKアサーションを挿入します。メッセージはSTS提供の証明鍵構成要素を使用して保護されます。 |
|
oracle/wss11_sts_issued_saml_hok_with_message_protection_service_policy |
このポリシーでは、信頼できるSTSが発行したSAML HOKアサーションを認証します。メッセージは対称鍵テクノロジのWS-SecurityのBasic 128スイートを使用して保護されます。 |
|
oracle/wss11_sts_issued_saml_with_message_protection_client_policy |
このポリシーでは、信頼できるSTSが発行したSAML送信者保証アサーションを挿入します。メッセージはクライアントの秘密鍵を使用して保護されます。 |
表11-2に、プログラムによる構成のオーバーライドを利用して特定のポリシーに設定できるプロパティを示します。
表10-4に、プログラムによるSTSプロパティのオーバーライド方法を示す一連のサンプルのユース・ケースを説明します。
表10-4 STSプログラムによる構成のユース・ケース
| ユース・ケース | サンプル・コード |
|---|---|
|
トークン交換ユーザー名トークン – 対称証明鍵によるSAML |
|
|
トークン交換x509トークン – 対称証明鍵によるSAML |
|
|
トークン交換ユーザー名トークン – 非対称証明鍵によるSAML |
|
|
トークン交換x509トークン – 非対称証明鍵によるSAML |
|
|
On Behalf OfトークンのサブジェクトのOn Behalf Ofユーザー名、リクエスタ・トークンのユーザー名との交換 – 対称証明鍵によるSAML |
|
|
On Behalf OfトークンのOn Behalf Ofユーザー名、リクエスタ・トークンのユーザー名との交換 – 対称証明鍵によるSAML |
|
|
On Behalf OfトークンのOn Behalf Ofユーザー名、リクエスタ・トークンx509との交換 – 対称証明鍵によるSAML |
|
|
On Behalf OfトークンのサブジェクトのOn Behalf Ofユーザー名、リクエスタ・トークンのユーザー名との交換 – 非対称証明鍵によるSAML |
|
|
On Behalf OfトークンのOn Behalf Ofユーザー名、リクエスタ・トークンユーザー名との交換 – 非対称証明鍵によるSAML |
(
|
|
On Behalf OfトークンのOn Behalf Ofユーザー名、リクエスタ・トークンx509との交換 – 非対称証明鍵によるSAML |
|
Oracle WSMでは、標準WS-Trustクライアントを提供します。クライアントがOpenSSO STSサーバーと相互運用できることを確認します。OpenSSO STSサーバーを使用してサンプルのシナリオをステップごとに実行するには、「OpenSSO STSとWS-Trustの併用例」を参照してください。
次の項では、WS-TrustをOpen SSOセキュリティ・トークン・サービス(STS)サーバーと併用して、次のセキュリティ・シナリオを構成するエンドツーエンドの例を提供します。
次の手順では、この項で説明するサンプル・シナリオで使用できるようにOpenSSO STSを構成する上で必要な手順について説明します。
OpenSSO STSインスタンスにログインします。
「構成」→「グローバル」→セキュリティ・トークン・サービスに移動します。
「セキュリティ」→「セキュリティ・メカニズム」→STSサービスで受け入れるセキュリティ・トークンですべてのオプションを有効にします。
ユーザー・トークンの資格証明セクションで、必要に応じて名前とパスワードを設定したトークンの新しい資格証明を追加します。これをテスト/テストに設定します。
「On Behalf of Token」セクションで、「トークンの代理の認証チェーン」ドロップダウン・リストからldapServiceを選択します。
「署名」セクションで、次のオプションを有効にします。
- リクエスト署名を確認
- レスポンスの署名の有効化(「本文」および「タイムスタンプ」を選択)。
「暗号化」セクションで、次のオプションを有効にします。
- リクエストの署名の無効化(「本文」および「ヘッダー」を選択)。
- レスポンスを暗号化
「暗号化アルゴリズム」ドロップダウン・リストから「AES」を選択し、暗号化強度ドロップダウン・リストから128を選択します。
メッセージ保護リクエスタ・トークン付きWS-Security 1.1 Kerberosトークンをサポートするには、Kerberos Configurationセクションで次の値を構成します。
SSLをサポートするには、次の手順を実行します。
トークン発行属性セクションで、OpenSSOインスタンスに基づいてSSLエンドポイントを編集します。
「署名」で、トランスポートがSSLオプションによって保護されている場合は、署名検証の無効化を使用可能にします。
「暗号化」で、トランスポートがSSLオプションによって保護されている場合は、復号化の無効化を使用可能にします。
OpenSSO STSをホストするサーバーでSSLをサポートするには、次の手順を実行します。
OpenSSO STSをホストするWebLogic Serverで、SSLを構成するには、「SSLに関するキーストアの構成」で説明する手順を実行します。
Open SSO STSをホストするGlassfishサーバーで、次の手順を実行します。
次のコマンドを発行してアプリケーション・サーバーの新しい鍵のペアを生成します。
keytool -genkey -keyalg <algorithm for generating the key pair> -keystore keystore.jks -validity <days> -alias <alias_name>
たとえば、次のようにします。
keytool -genkey -keyalg RSA -keystore <glassfish_install_dir>/domains/<sts_deploy_domain>/config/keystore.jks -validity 365 -alias owsm
姓名を入力するように求められたら、証明書を生成するマシンのホスト名を入力します。また、その他のプロンプトが表示されたら、該当する詳細を入力します。
次のコマンドを発行して証明書署名リクエスト(CSR)を生成します。
keytool -certreq -alias owsm -file owsm.csr -keystore keystore.jks -storepass changeit
生成されowsm.csrファイルに書き込まれるリクエストを認証局に提出し、有効な証明書を取得する必要があります。たとえば、https://mahogany.red.iplanet.comにあるOpenSSO QAチームによって管理される証明書管理サーバーです。
https://mahogany.red.iplanet.comにある証明書管理サーバーにアクセスして、左ペインにあるSSLサーバーをクリックし、BEGIN CERTIFICATE REQUESTで始まりEND CERTIFICATE REQUESTで終わる.csrファイルの内容をPKCS # 10リクエストフィールドに貼り付けます。
その他のフィールドに適宜入力して、リクエストを送信します。リクエストが承認されると、同じページの取得タブから証明書を取得できます。
BEGIN CERTIFICATEからEND CERTIFICATEまでの証明書の内容(PKCS # 7形式)を拡張子が.certのファイルにコピーして、次のキーツール・コマンドを使用してサーバー証明書を<glassfish_install_dir>/domains/<sts_deploy_domain>/config/keystore.jksファイルにインポートします。
keytool -import -v -alias owsm -file owsm.cert -keystore keystore.jks -storepass changeit
証明書を信頼する場合はプロンプトが表示されたらYESと入力します。
認証局のSSL証明書にアクセスします。https://mahogany.red.iplanet.comに移動して、SSLサーバー→取得タブ→「リスト証明書」→「検索」に移動します。そのページの最初の「詳細」ボタンをクリックして、Base64でエンコードされた証明書を.certファイル(mahogany.certなど)にコピーします。
次のコマンドを使用して、<glassfish_install_dir>/domains/<sts_deploy_domain>/config/cacerts.jksファイルに「rootca」という別名でこの証明書をインポートします。
keytool -import -v -alias rootca -file mahogany.cert -keystore cacerts.jks -storepass changeit
前のステップをクライアント側のtruststore.jksファイルで繰り返す必要がある場合があります。そのファイルから既存のrootca別名がある場合は削除し、前述の新しい別名をインポートします(キーストア・ファイルの場所は変更)。
新しい証明書でGlassFishを構成するには、http://hostname:admin-port/にある「管理コンソール」にアクセスします。「構成」→「HTTPサービス」→http-listener2(デフォルトのSSL有効化ポート)→SSLに移動して、証明書のニックネームをs1as(自己署名cert)からowsmに変更します。
Glassfishを再起動します。
次の手順では、WS-TrustとOpenSSO STSを併用するメッセージ保護付きのSAML holder-of-keyの構成方法を説明します。この例では、WebLogic WebサービスとSOAコンポジット・クライアントを使用してシナリオを示します。
WS-TrustとOpenSSO STSを併用するメッセージ保護付きのSAML holder-of-keyを構成するには、次の手順を実行します。
「OpenSSO STSの構成」の説明に従って、OpenSSO STSを構成します。
自動ポリシー構成用のポリシーの構成で説明されている手順に従って、STSサービス・ポリシーを構成します。
oracle/sts_trust_config_service_policyのコピーを作成して、次の説明に従って、リクエスタ・トークン・タイプに基づいてポリシー構成を編集します。
メッセージ保護リクエスタ・トークン付きのWS-Security 1.0ユーザー名トークンをサポートするには、次の手順を実行します。
orasp:port-uri="http://<host>:<port>/openssosts/sts/wss10un"
orasp:wsdl-uri="http://<host>:<port>/openssosts/sts/wss10un?wsdl"(オプション)
メッセージ保護リクエスタ・トークン付きのWS-Security 1.0ユーザー名トークンをSSLを使用してサポートするには、次の手順を実行します。
orasp:port-uri="https://<host:ssl_port>/openssosts/sts/tlswss10un"
orasp:wsdl-uri="https://<host:ssl_port>/openssosts/sts/tlswss10un?wsdl"(オプション)
メッセージ保護リクエスタ・トークン付きのWS-Security 1.0 X509トークンをサポートするには、次の手順を実行します。
orasp:port-uri="http://<host>:<port>/openssosts/sts/wss10x509"
orasp:wsdl-uri="http://<host>:<port>/openssosts/sts/wss10x509?wsdl"(オプション)
メッセージ保護リクエスタ・トークン付きのWS-Security 1.1 Kerberosトークンをサポートするには、次の手順を実行します。
orasp:port-uri="http://<host>:<port>/openssosts/sts/wss11kerberos"
orasp:wsdl-uri="http://<host>:<port>/openssosts/sts/wss11kerberos?wsdl"(オプション)
「自動ポリシー構成用のWebサービスの構成」で説明されている手順に従って、Webサービス・ポリシーを構成します。
Webサービスにoracle/wss11_sts_issued_saml_hok_with_message_protection_service_policyが後に続くステップ2で作成したで作成したポリシーを添付します。詳細は、「単一のサブジェクトへのポリシーの添付」を参照してください。
|
注意: デフォルトでは、oracle/wss11_sts_issued_saml_hok_with_message_protection_service_policyポリシーをSAML 1.1のトークン・タイプで構成します。トークン・タイプをSAML 2.0に構成する場合、ポリシーのコピーを作成し、「既存のポリシーからのWebサービス・ポリシーの作成」の説明に従って、編集する必要があります(この値はクライアント・ポリシーに一致している必要があります)。 |
「自動ポリシー構成用のWebサービス・クライアントの構成」で説明されている手順に従って、Webサービス・クライアント・ポリシーを構成します。
SOAコンポジット・クライアントにoracle/wss11_sts_issued_saml_hok_with_message_protection_client_policyポリシーに添付し、リクエスタ・トークンの必要に応じて、表8-1に説明されているクライアント構成プロパティをオーバーライドします。
sts.auth.user.csf.keyをデフォルトのOpenSSO STS構成で使用できるユーザー資格証明に設定する必要があります。つまり、パスワード付きのユーザー名testをtestに設定します。ただし、X509リクエスタ・トークンに対して設定する必要はありません。
|
注意: クライアント構成プロパティのオーバーライドの詳細は、「Webサービス・クライントへのポリシーの添付」を参照してください。デフォルトでは、oracle/wss11_sts_issued_saml_hok_with_message_protection_client_policyポリシーをSAML 1.1のトークン・タイプで構成します。トークン・タイプをSAML 2.0に構成する場合、ポリシーのコピーを作成し、「既存のポリシーからのWebサービス・ポリシーの作成」の説明に従って、編集する必要があります(この値はサービス・ポリシーに一致している必要があります)。 |
次の手順では、WS-TrustとOpenSSO STSを併用するメッセージ保護付きのSAML送信者保証の構成方法を説明します。この例では、WebLogic WebサービスとSOAコンポジット・クライアントを使用してシナリオを示します。
WS-TrustとOpenSSO STSを併用するメッセージ保護付きのSAML送信者保証を構成するには、次の手順を実行します。
「OpenSSO STSの構成」の説明に従って、OpenSSO STSを構成します。
「Webサービス・クライアントからのSTS構成ポリシーの手動による構成: 主要手順」で説明されている手順に従ってクライアント側のSTSポリシーを構成します。
|
注意: 信頼はWebサービスおよびクライアント間のものであるため、SAML送信者保証確認用で自動ポリシー構成を使用することはできません。詳細は、「WS-Trustでの送信者保証の使用」を参照してください。 |
oracle/sts_trust_config_client_policyのコピーを作成して、リクエスタ・トークン・タイプに基づいてポリシー構成を編集します。
メッセージ保護リクエスタ・トークン付きのWS-Security 1.0ユーザー名トークンをサポートするには、次の手順を実行します。
orasp:policy-reference-uri="oracle/wss10_username_token_with_message_protection_client_policy"
orasp:port-endpoint="http://<host>:<port>/openfm/SecurityTokenService/#wsdl.endpoint(SecurityTokenService/ISecurityTokenService_Port_UN_WSS10_SOAP12):
orasp:port-uri="http://<host>:<port>/openssosts/sts/wss10un"
orasp:sts-keystore-recipient-alias="test"
メッセージ保護リクエスタ・トークン付きのWS-Security 1.0ユーザー名トークンをSSLを使用してサポートするには、次の手順を実行します。
orasp:policy-reference-uri="oracle/wss_username_token_over_ssl_client_policy"
orasp:port-endpoint="http://localhost:8080/openfm/SecurityTokenService/#wsdl.endpoint(SecurityTokenService/ISecurityTokenService_Port_TLS_UN_WSS10_SOAP12)"
orasp:port-uri="https://<host:ssl_port>/openssosts/sts/tlswss10un"
orasp:sts-keystore-recipient-alias="test"
メッセージ保護リクエスタ・トークン付きのWS-Security 1.0 X509トークンをサポートするには、次の手順を実行します。
orasp:policy-reference-uri="oracle/wss10_x509_token_with_message_protection_client_policy"
orasp:port-endpoint="http://localhost:8080/openfm/SecurityTokenService/#wsdl.endpoint(SecurityTokenService/ISecurityTokenService_Port_X509_WSS10_SOAP12)"
orasp:port-uri="http://<host>:<port>/openssosts/sts/wss10x509"
orasp:sts-keystore-recipient-alias="test"
メッセージ保護リクエスタ・トークン付きのWS-Security 1.1 Kerberosトークンをサポートするには、次の手順を実行します。
orasp:policy-reference-uri="wss11_kerberos_token_with_message_protection_basic128_client_policy" OR "wss11_kerberos_token_with_message_protection_client_policy"
orasp:port-endpoint="http://localhost:8080/openfm/SecurityTokenService/#wsdl.endpoint(SecurityTokenService/ISecurityTokenService_Port_KERBEROS_WSS11_SOAP12)"
orasp:port-uri="http://<host>:<port>/openssosts/sts/wss11kerberos"
orasp:sts-keystore-recipient-alias="test"
WebLogic Webサービスにoracle/wss11_saml_token_with_message_protection_service_policyポリシーを添付し(SAML送信者保証シナリオには対応する発行済トークン・ポリシーはない)、keystore.enc.csf.keyをオーバーライドして、サービス暗号化鍵の別名とパスワードを指定します。
|
注意: デフォルトでは、oracle/wss11_saml_hok_with_message_protection_service_policyポリシーをSAML 1.1のトークン・タイプで構成します。トークン・タイプをSAML 2.0に構成する場合、ポリシーのコピーを作成し、「既存のポリシーからのWebサービス・ポリシーの作成」の説明に従って、編集する必要があります。 |
oracle/ws11_sts_issued_saml_hok_with_message_protection_client_policyポリシーが後に続くステップ2で作成したポリシーをSOAコンポジット・クライアントに添付し、リクエスタ・トークンの必要に応じて、表8-1に説明するクライアント構成プロパティをオーバーライドします。
「On Behalf Of」ユース・ケースは、表8-1に示すsts.auth.on.behalf.of.csf.keyプロパティおよびon.behalf.ofプロパティに依存しています。詳細は、「On Behalf Ofユース・ケース」を参照してください。
on.behalf.ofプロパティをtrueに設定する必要があります。sts.auth.on.behalf.of.csf.keyを「on behalf of」ユース・ケースをサポートするデフォルトのOpenSSO STS構成で使用できるユーザー資格証明に設定する必要があります。つまり、パスワード付きのdemoをchangeitに設定します。
OpenSSO STS「on behalf of」ユーザーからトークンを要求するためにクライアント・アプリケーションに権限を付与するには、<MW_HOME>/user_projects/domains/base_domain/config/fmwconfig/system-jazn-data.xmlファイルを編集して、次のコードを組み込みます。
<grant>
<grantee>
<codesource>
<url>
file:${common.components.home}/modules/oracle.wsm.agent.common_11.1.1/wsm-agent-core.jar
</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.wsm.security.WSIdentityPermission</class>
<name>resource=<Client App. Name></name>
<actions>assert</actions>
</permission>
</permissions>
</grant>
次の手順では、WS-TrustとOpenSSO STSを併用するメッセージ保護付きのSAML Bearerの構成方法を説明します。この例では、WebLogic WebサービスとSOAコンポジット・クライアントを使用してシナリオを示します。
WS-TrustとOpenSSO STSを併用するメッセージ保護付きのSAML Bearerを構成するには、次の手順を実行します。
「OpenSSO STSの構成」の説明に従って、OpenSSO STSを構成します。
自動ポリシー構成用のポリシーの構成で説明されている手順に従って、STSポリシーを構成します。
oracle/sts_trust_config_service_policyのコピーを作成して、次の説明に従って、リクエスタ・トークン・タイプに基づいてポリシー構成を編集します。
メッセージ保護リクエスタ・トークン付きのWS-Security 1.0ユーザー名トークンをサポートするには、次の手順を実行します。
orasp:port-uri="http://<host>:<port>/openssosts/sts/wss10un"
orasp:wsdl-uri="http://<host>:<port>/openssosts/sts/wss10un?wsdl"(オプション)
メッセージ保護リクエスタ・トークン付きのWS-Security 1.0ユーザー名トークンをSSLを使用してサポートするには、次の手順を実行します。
orasp:port-uri="https://<host:ssl_port>/openssosts/sts/tlswss10un"
orasp:wsdl-uri="https://<host:ssl_port>/openssosts/sts/tlswss10un?wsdl"(オプション)
メッセージ保護リクエスタ・トークン付きのWS-Security 1.0 X509トークンをサポートするには、次の手順を実行します。
orasp:port-uri="http://<host>:<port>/openssosts/sts/wss10x509"
orasp:wsdl-uri="http://<host>:<port>/openssosts/sts/wss10x509?wsdl"(オプション)
メッセージ保護リクエスタ・トークン付きのWS-Security 1.1 Kerberosトークンをサポートするには、次の手順を実行します。
orasp:port-uri="http://<host>:<port>/openssosts/sts/wss11kerberos"
orasp:wsdl-uri="http://<host>:<port>/openssosts/sts/wss11kerberos?wsdl"(オプション)
「自動ポリシー構成用のWebサービスの構成」で説明されている手順に従って、Webサービス・ポリシーを構成します。
oracle/wss11_sts_issued_saml_bearer_token_over_ssl_service_policyが後に続くステップ2で作成したで作成したポリシーを添付します。詳細は、「単一のサブジェクトへのポリシーの添付」を参照してください。
「自動ポリシー構成用のWebサービス・クライアントの構成」で説明されている手順に従って、Webサービス・クライアント・ポリシーを構成します。
SOAコンポジット・クライアントにoracle/ws11_sts_issued_saml_bearer_token_over_ssl_client_policyポリシーに添付し、リクエスタ・トークンの必要に応じて、表8-1に説明されているクライアント構成プロパティをオーバーライドします。
sts.auth.user.csf.keyをデフォルトのOpenSSO STS構成で使用できるユーザー資格証明に設定する必要があります。つまり、パスワード付きのユーザー名testをtestに設定します。ただし、X509リクエスタ・トークンに対して設定する必要はありません。
