ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護のユース・ケース
12c (12.1.3)
E59408-02
  目次へ移動
目次

前
 
次
 

2 SAMLメッセージ保護を使用したインバウンドSOAPリクエストの保護

この章では、SAMLメッセージ保護を使用したインバウンドSOAPリクエストの保護方法について説明します。

実行サマリー

ユース・ケース 次の目的のためにインバウンドSOAPリクエストを保護します。
  • メッセージ・レベルの保護(つまり、メッセージの整合性とメッセージの機密性)を実行します。

  • WS-Security 1.1標準に従ったインバウンドSOAPリクエストのSAMLベース認証を提供します。

解決策 WS-Security 1.1に準拠しているOracle Web Services Manager (OWSM) SAMLポリシーをWebサービスおよびクライアントにアタッチして、必要なキーおよびキーストアを構成します。
コンポーネント
  • Oracle Fusion Middleware
  • Oracle Web Services Manager(OWSM)

  • 保護するWebサービスおよびクライアント・アプリケーション

必須ドキュメント このユース・ケースを完了するには、次のドキュメント・リソースを参照してください。
  • Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理

  • Oracle Web Services Managerの理解

  • http://download.oracle.com/javase/6/docs/technotes/tools/windows/keytool.htmlkeytool Javadoc


この章の構成は、次のとおりです。

2.1 ユース・ケースの概要

このユース・ケースは、次の操作に必要な手順を示します。

  • インバウンドSOAPリクエストのSAMLベース認証を使用したメッセージ・レベルの保護を実行するため、適切なOWSMセキュリティ・ポリシーをアタッチします。

    特に、次のポリシーをクライアントおよびサービスにそれぞれアタッチします。

    • wss11_saml_token_with_message_protection_client_policy

    • wss11_saml_token_with_message_protection_service_policy

  • 必要なキーおよびキーストアを構成します。

    メッセージは、WS-Securityの対称鍵テクノロジのBasic 128スイートを使用して保護されます。具体的には、RSA鍵メカニズム(メッセージの機密性)、SHA-1ハッシュ・アルゴリズム(メッセージの整合性)、およびAES-128ビットの暗号化が使用されます。そのため、keytool(またはその他のツール)を使用してこのポリシーに必要な署名や暗号化鍵を作成する場合は、必ずRSA鍵メカニズム、SHA-1アルゴリズム、そしてAES-128ビット暗号化を使用して、キーのポリシー要件を満たす必要があります。サポートされているアルゴリズム・スイートの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のサポートされているアルゴリズム・スイートに関する項を参照してください。

次の項では、SAMLメッセージ保護のユース・ケースの追加のバックグラウンドについて説明します。

詳細は、「Oracle Web Services Managerの理解」の鍵と証明書の理解に関する項とwss11に関する項を参照してください。

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

このユース・ケースのSAMLセキュリティ・ポリシーは、対称鍵テクノロジを使用します。対称鍵暗号は、次のような単一の共有の秘密鍵に依存します。

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

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

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

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

リクエストを作成するため、OWSMエージェントは次の手順を実行します。

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

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

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

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

Webサービスがリクエストを受け取った場合、次の手順を実行します。

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

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

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

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

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

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

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

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

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

2.1.2 キーストアに必要なキー

このユース・ケースの場合、クライアントとWebサービスが、同じキーストアにアクセスする同じドメインにあります。結果として、同じ秘密/公開鍵ペアを共有できます。

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

2.1.3 マルチドメインのユース・ケース(キーストアの強化)

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

表2-1に示すように、複数ドメインのユース・ケースで要件について考慮します。

表2-1 複数ドメインのユース・ケース要件

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

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

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

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

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

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

実行時の対称鍵の生成

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


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

  • Webサービス・クライアントが使用できるように、Webサービスのbase64エンコード形式の公開証明書がWSDLで発行されます。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のサービス・アイデンティティ証明書拡張の使用に関する項を参照してください。この使用方法では、Webサービスの公開鍵はクライアントのキーストアになくても構いません。

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

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

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

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

ポリシーで別のSAML認証局(発行者)を使用する場合は、その発行者名をクライアントで構成し、SAMLログイン・モジュール内の使用可能な発行者のリストに含める必要があります。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のSAMLアサーション発行者名の追加に関する項を参照してください。

2.2 ユース・ケースの実装

このユース・ケースは、SAMLメッセージの保護を実装する次のタスクについて説明します。

2.2.1 タスク1: 前提条件

このユース・ケースを実装する前に、次のことを確認してください

2.2.2 タスク2: WebLogic Serverユーザーの作成

SAMLトークンのユーザーがWebLogic Serverアイデンティティ・ストアに存在することを確認する必要があります。存在しない場合は作成する必要があります。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのユーザーの作成に関する項の説明に従って、WebLogic Server管理コンソールを使用してユーザーをアイデンティティ・ストアに追加します。

Webサービスのランタイムは、WS-SecurityヘッダーからSAMLトークンを抽出し、SAMLトークン内の名前を使用してWebLogic Serverアイデンティティ・ストアに対してユーザーを検証します。特に、SAMLログイン・モジュールは、Webサービスに代わってSAMLトークンを検証します。次に、SAMLログイン・モジュールは認証を完了するために、検証されたトークンからユーザー名を抽出し、Oracle Platform Security Services (OPSS)に(間接的に)渡します。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の「Fusion Middleware Controlを使用したSAMLおよびSAML2ログイン・モジュールの構成」を参照してください。

デフォルトの認証プロバイダなど、構成済のWebLogic Server認証プロバイダをここで呼び出すことができます。

2.2.3 タスク3: Javaキーストアの作成

キーストアを作成し、秘密鍵および信頼できるCA証明書をロードします。

次の手順では、keytoolユーティリティを使用してJavaキーストアを作成および管理します。このユース・ケースでは、JKSキーストアを使用します。完全な手順は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の秘密鍵の生成とJavaキーストアの作成に関する項を参照してください。


注意:

次のタスクのいずれかを実行する場合、別名を指定します。
  • -genkeyコマンドを使用してエンティティをキーストアに追加し、鍵ペアを生成します(公開鍵と秘密鍵)。

  • -importコマンドを使用して、証明書または証明書チェーンを信頼できる証明書のリストに追加します。

これ以後、keytoolコマンドでエンティティを参照する場合は、このときに指定した別名を使用する必要があります。


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

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

    次のコマンドは、default-keystore.jksキーストアに署名アルゴリズムとしてRSA-SHA1、別名orakeyを使用したRSA鍵を生成します。別名を指定できます。別名をorakeyに設定する必要はありません。

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

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

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

    リクエストの生成には、-certreqコマンドを使用します。CAは証明書または証明書チェーンを戻します。

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

    keytool -certreq -alias orakey -sigalg "SHA1withRSA" -file certreq_file -storetype jks -keystore default-keystore.jks
    
  3. 自己署名証明書を信頼できるCA証明書で置き換えます(インポートします)。

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

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

2.2.4 タスク4: OWSMキーストアの構成

OWSMキーストアを構成します。完全な手順は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のOWSMキーストアの構成に関するを参照してください。

2.2.5 タスク5: 復号化キーのパスワードを資格証明ストアに格納

復号化キーのパスワードを資格証明ストアに格納します。キー名としてkeystore.enc.csf.keyを使用します。完全な手順は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の資格証明ストアへの鍵およびユーザー資格証明の追加に関する項を参照してください。

2.2.6 タスク6: Webサービスへのポリシーのアタッチ

wss11_saml_token_with_message_protection_service_policyをWebサービスにアタッチして、メッセージ署名およびメッセージ暗号化に対してポリシー・アサーションを構成します。完全な手順は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のポリシーのアタッチに関する項を参照してください。

デフォルトでは、ポリシーによってリクエストおよびレスポンスの本体全体が署名および暗号化されます。署名および暗号化する個々の本体要素を指定するオプションがあります。また、署名および暗号化するヘッダー要素を指定できます。必要に応じてメッセージの署名および暗号化を構成できます。ただし、クライアント・ポリシー設定と一致する必要があります。

ポリシーの構成の詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のoracle/wss11_saml_token_with_message_protection_service_policyに関する項を参照してください。

2.2.7 タスク7: ポリシーをWebサービス・クライアントにアタッチ

wss11_saml_token_with_message_protection_client_policyをWebサービス・クライアントにアタッチし、メッセージの署名、メッセージの暗号化あるいはその両方のポリシー・アサーションを構成します。完全な手順は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のポリシーのアタッチに関する項を参照してください。

デフォルトでは、ポリシーによってリクエストおよびレスポンスの本体全体が署名および暗号化されます。署名および暗号化する個々の本体要素を指定するオプションがあります。また、署名および暗号化するヘッダー要素を指定できます。必要に応じてメッセージの署名および暗号化を構成できます。ただし、サービス・ポリシー設定と一致する必要があります。

クライアント・ポリシーのsaml.issuer.nameプロパティは、SAMLトークンの発行者を特定し、そのデフォルトはwww.oracle.comという値です。このユース・ケースでは、www.oracle.comデフォルトを使用します。saml.issuser.nameプロパティのオーバーライドの詳細は、SAML発行者をオーバーライドするタイミングに関する項を参照してください。

ポリシーの構成の詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のoracle/wss11_saml_token_with_message_protection_client_policyに関する項を参照してください。