| Oracle® Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理 12c (12.1.2) E47994-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理 12c (12.1.2) E47994-03 |
|
前 |
次 |
このユースケースは、SAMLポリシーをWebサービスおよびクライアントに追加する手順を示します。このユースケースでは、WebLogic Serverユーザーの作成、Javaキーストアの作成と構成、パスワードの格納およびWebサービスとサービス・クライアントへのSAMLポリシーのアタッチを行います。
この章の構成は、次のとおりです。
Webサービス・クライアントをメッセージ保護付きSAMLトークン・クライアント・ポリシー(wss11_saml_token_with_message_protection_client_policy)で保護し、対応するWebサービスをメッセージ保護付きSAMLトークン・サービス・ポリシー(wss11_saml_token_with_message_protection_service_policy)で保護すると仮定します。
この項では、この2つのポリシーを使用して手順を説明します。
この項の項目は次のとおりです。
この項では、このSAMLメッセージ保護のユースケースを構成するための必知事項について説明します。この項の項目は次のとおりです。
メッセージ保護付き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サービスはリクエスト・メッセージ内の対称鍵を使用して、リクエスト・メッセージの署名を検証してそれを復号化し、それからレスポンス・メッセージに署名して暗号化します。
次のプロセス・フローを考慮します。
リクエストを作成するために、OWSMエージェントは次のことを行います。
共有の対称鍵を生成し、それを使用してリクエスト・メッセージの署名と暗号化の両方を行います。
その独自の秘密鍵を使用して、リクエスト・メッセージの署名を裏書きします。
Webサービスの公開鍵を使用して、対称鍵を暗号化します。
対称鍵をリクエストとともにWebサービスに送信します。クライアントはリクエストで公開鍵を送信して、Webサービスがその署名を検証できるようにします。
Webサービスがリクエストを受け取ると、次のことを行います。
秘密鍵を使用して、対称鍵を復号化します。
対称鍵を使用して、リクエスト・メッセージを復号化し、その署名を検証します。
リクエスト・メッセージ内のクライアントの公開鍵を使用して、その裏書署名を検証します。
クライアントにレスポンスを送信するために、Webサービスは次のことを行います。
リクエストとともに送信されたクライアントが生成した同じ対称鍵を使用して、レスポンス・メッセージに署名します。
クライアントが生成した同じ対称鍵を使用して、レスポンス・メッセージを暗号化します。
OWSMエージェントはレスポンス・メッセージを受け取ると、次のことを行います。
最初に生成した対称鍵を使用して、レスポンス・メッセージを復号化します。
最初に生成した対称鍵を使用して、レスポンス・メッセージの署名を検証します。
クライアントとWebサーバーが、同じキーストアにアクセスする同じドメインにある場合は、同じ秘密/公開鍵のペアを共有できます。
つまり、クライアントが秘密鍵"orakey"を使用してリクエスト・メッセージの署名を裏書きし、公開鍵"orakey"を使用して対称鍵を暗号化できます。次に、Webサービスが公開鍵"orakey"を使用して裏書きを検証し、秘密鍵"orakey"を使用して対称鍵を復号化します。
デモの目的で、このユースケースでは1つの鍵ペアを作成します。
クライアントとWebサーバーが同じドメインになく、同じキーストアにアクセスしない場合は、クライアントとWebサービスは各自が秘密/公開鍵のペアを持つ必要があります。
表13-1に示すように、マルチドメインのユースケースで次の要件について考慮します。
表13-1 マルチドメインのユースケース要件
| Webサービス・クライアント | Webサービス |
|---|---|
|
クライアントのキーストアに独自の秘密/公開鍵のペアが必要です。 |
サービス・キーストアに独自の秘密/公開鍵のペアが必要です。 |
|
Webサービスの公開鍵が必要です。 |
クライアントのキーストア内の公開鍵に対応する中間証明書とルート証明書が必要です。 これらの証明書を使用して、信頼される証明チェーンを生成して署名を検証します。 |
|
実行時の対称鍵の生成 |
対称鍵が必要ですが、これはリクエスト・メッセージで送信されます。 |
クライアントが対称鍵を暗号化するために使用する公開鍵、つまりWebサービスの公開鍵については、次の2つのアプローチがあります。
「サービス・アイデンティティ証明拡張の使用」で説明されているように、Webサービスのbase64エンコードされた公開証明書は、Webサービス・クライアントが使用するためにWSDLでパブリッシュされます。そのため、この使用方法では、Webサービスの公開鍵はクライアントのキーストアになくても構いません。
証明書がWSDLでパブリッシュされていない場合、「構成」ページで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ログイン・モジュール(「Fusion Middleware Controlを使用したSAMLおよびSAML2ログイン・モジュールの構成」を参照)では、WebサービスのかわりにSAMLトークンが検証されます。次に、SAMLログイン・モジュールは認証を完了するために、検証されたトークンからユーザー名を抽出し、Oracle Platform Security Services (OPSS)に(間接的に)渡します。
デフォルトの認証プロバイダなど、構成済のWebLogic Server認証プロバイダをここで呼び出すことができます。
ユーザーの作成
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの説明に従って、WebLogic Server管理コンソールを使用して、ユーザーをアイデンティティ・ストアに追加します。
便宜のために、ここにも手順を掲載します。
WebLogic Server管理コンソールでユーザーを作成する手順
左側のペインで、「セキュリティ・レルム」を選択します。
「セキュリティ・レルム」ページの「サマリー」で、レルムの名前を選択します(たとえば、myrealm)。
「レルム名」ページの「設定」で、「ユーザーとグループ」→「ユーザー」を選択します。
「ユーザー」表に、管理プロバイダで定義されているすべてのユーザーの名前が表示されます。
「新規」をクリックします。
「新規ユーザーの作成」ページの「名前」フィールドに、ユーザーの名前を入力します。
ユーザー名は大文字と小文字が区別され、一意である必要があります。カンマ、タブ、および次の「、」で区切ったリストの文字は使用しないでください。<>、#、|、&、?、( )、{ }
(オプション)「説明」フィールドに説明を入力します。説明は、ユーザーの完全な名前にします。
「プロバイダ」ドロップダウン・リストで、ユーザーの認証プロバイダを選択します。
セキュリティ・レルムに複数のWebLogic認証プロバイダが構成されている場合は、それらがリストに表示されます。新規ユーザーの情報を格納するWebLogic認証プロバイダのデータベースを選択します。
「パスワード」フィールドに、ユーザーのパスワードを入力します。
WebLogic認証プロバイダで定義されるユーザーの最小パスワード長は8文字です。
「パスワードの確認」フィールドにユーザーのパスワードを再入力します。
「OK」をクリックして、変更を保存します。
ユーザー名が「ユーザー」表に表示されます。
デモの目的で、このユースケースではJKSキーストアを使用します。
この項では、keytoolユーティリィティによるJavaキーストアの作成および管理のアウトラインを示します。また、キーストアを作成し、秘密鍵および信頼できるCA証明書をロードする方法について説明します。
keytoolユーティリティのコマンドや引数の詳細は、Webサイト(http://download.oracle.com/javase/7/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 certreq_file -keystore default-keystore.jks
キーストアを作成した後で、JKSキーストアを使用するようにドメイン・レベルでOWSMを構成する必要があります。これはFusion Middleware ControlまたはWLSTコマンドを使用して行うことができます。
詳細は、次の項を参照してください。
このユースケースでは、orakeyは署名と暗号化鍵の両方の別名です。このユースケース・キーストアの名前はdefault-keystore.jksです。
「資格証明ストアへの鍵およびユーザー資格証明の追加」で説明されているように、復号化キーのパスワードは資格証明ストアに格納する必要があります。キー名としてkeystore.enc.csf.keyを使用します。
「Fusion Middleware Controlを使用した単一サブジェクトへのポリシーを直接アタッチする」の説明に従って、wss11_saml_token_with_message_protection_service_policyのコピーをWebサービスにアタッチします。
ポリシー・アサーションを、メッセージの署名およびメッセージの暗号化に構成します。
デフォルトでは、リクエストおよびレスポンスの本体全体を署名および暗号化します。そのかわりに、特定の本体要素を指定して署名および暗号化する方法もあります。署名および暗号化するヘッダー要素を追加で指定することもできます。ここで設定したものは、クライアント・ポリシー設定と一致している必要があります。
|
注意: 「ポリシー構成のオーバーライドの概要」の説明に従って、keystore.sig.csf.key and keystore.enc.csf.keyをオーバーライドできます。 これらの値をオーバーライドする場合は、新しい値のキーがキーストアにあることが必要です。つまり、値をオーバーライドしても、これらのキーをキーストアに構成する必要がなくなるわけではありません。 |
「Fusion Middleware Controlを使用した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の値を指定できます。または、ポリシーをアタッチするときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。
