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

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

この章に示されているユース・ケースを参照して、SAMLメッセージ保護を使用してインバウンドSOAPリクエストを保護する方法を理解できます。SAMLメッセージ保護を実装するには、WebLogic Serverユーザーの作成、Javaキーストアの作成などの一連のタスクを実行する必要があります。

2.1 ユース・ケース: 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.htmlのkeytool Javadoc

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

インバウンド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サービスの保護とポリシーの管理』のサポートされているアルゴリズム・スイートに関する項を参照してください。

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

Webサービスを構成する前に、必要な秘密キーおよび証明書のタイプ、キーおよびキーストアの名前を決定する必要があります。それから、それらに従って環境を設定できます。

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

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

2.2.1 対称キーによるメッセージ保護

対称キー暗号は、単一の共有秘密キーに依存します。クライアントは、対称キーを作成し、それを使用して署名してメッセージを暗号化し、Webサービスの証明書を使用して対象キーを暗号化し、それをリクエスト・メッセージでWebサービスと共有します。Webサービスはリクエスト・メッセージ内の対称キーを使用して、リクエスト・メッセージの署名を検証してそれを復号化し、それからレスポンス・メッセージに署名して暗号化します。

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

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

共有の対称キーを生成し、それを使用してリクエスト・メッセージの署名と暗号化の両方を行います。
その独自の秘密キーを使用して、リクエスト・メッセージの署名を裏書きします。
Webサービスの公開キーを使用して、対称キーを暗号化します。
対称キーをリクエストとともにWebサービスに送信します。クライアントはリクエストで公開キーを送信して、Webサービスがその署名を検証できるようにします。

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

秘密キーを使用して対称キーを復号化します。
対称キーを使用して署名を検証するためにリクエスト・メッセージを復号化します。
リクエスト・メッセージ内のクライアントの公開キーを使用して、その裏書署名を検証します。

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

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

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

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

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

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

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

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

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

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

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

Webサービス・クライアント	Webサービス
クライアントのキーストアに独自の秘密/公開キー・ペアが必要です。	サービス・キーストアに独自の秘密/公開キー・ペアが必要です。
Webサービスの公開キーが必要です。	クライアントのキーストア内の公開キーに対応する中間証明書とルート証明書が必要です。これらの証明書を使用して、信頼される証明チェーンを生成して署名を検証します。
実行時の対称キーの生成	対称キーが必要ですが、これはリクエスト・メッセージで送信されます。

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

Webサービス

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

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

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

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

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

実行時の対称キーの生成

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

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

Webサービス・クライアントが使用できるように、Webサービスのbase64エンコード形式の公開証明書がWSDLで発行されます。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のサービス・アイデンティティ証明書拡張の使用に関する項を参照してください。この使用方法では、Webサービスの公開キーはクライアントのキーストアになくても構いません。
証明書がWSDLでパブリッシュされていない場合、「構成」ページでkeystore.recipient.aliasの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。キーストア受信者の別名は、アウトバウンドSOAPメッセージの暗号化用のキーを取得するときにキーストア内の公開キーを検索するために使用される別名を指定します。この方法では、Webサービスの公開キーはクライアントのキーストアにある必要があります。

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

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

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

2.3 SAMLメッセージ保護の実装

SAMLメッセージ保護を実装するには、WebLogic Serverユーザーの作成、Javaキーストアの作成、OWSMキーストアの構成、復号化キーのパスワードの資格証明ストアへの格納、ポリシーのWebサービスおよびWebサービス・クライアントへの添付という一連のタスクを実行する必要があります。

2.3.1 SAMLメッセージ保護の実装 - 前提条件

SAMLメッセージ保護を実装する前に、製品コンポーネントをダウンロードしてインストールし、WebLogicドメインを構成し、管理サーバーを起動し、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールへのアクセス権を取得します。

開始する前に、次のタスクが実行されていることを確認してください。

次の製品コンポーネントをダウンロードおよびインストールします。
- Oracle Fusion Middleware - OWSMを含む
  
  詳細は、Oracle Fusion MiddlewareのインストールのプランニングのOracle Fusion Middlewareインストールの準備に関する項を参照してください。
- Oracle JDeveloper
  
  これは、このドキュメントのユース・ケースのサブセットにのみ必要です。
  
  Oracle Fusion Middlewareソフトウェアの入手先とダウンロードの詳細は、OTNでOracle Fusion Middlewareダウンロード、インストール、構成のReadmeファイルを参照してください。
WebLogicドメインを構成します。

完全な手順は、『構成ウィザードによるWebLogicドメインの作成』のWebLogicドメインの作成に関する項を参照してください。
ドメインの管理サーバーを起動します。

完全な手順は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止に関する項を参照してください。
次の管理ツールにアクセスできることを確認します。
- Oracle Enterprise Manager Fusion Middleware Control。:
```
http://localhost:7001/em
```
- Oracle WebLogic Server管理コンソール
```
http://localhost:7001/console
```

2.3.2 WebLogic Serverユーザーの作成

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

詳細は、Oracle 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.3.3 Javaキーストアの作成

キーストアを作成し、秘密キーおよび信頼できるCA証明書をロードします。keytoolユーティリティを使用してJavaキーストアを作成および管理できます。

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

注意:

次のタスクのいずれかを実行する場合、別名を指定します。

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

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

新しいキー・ペアと自己署名証明書を作成します。
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ユーティリティから必要なキーとキーストアのパスワードを要求するプロンプトが表示されます。これらのパスワードは後で必要になります。
認証局(CA)への証明書リクエストを生成します。
リクエストの生成には、-certreqコマンドを使用します。CAは証明書または証明書チェーンを戻します。

次のコマンドでは、orakey別名の証明書リクエストが生成されます。
```
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
```

2.3.4 Webサービス保護のためのOWSMキーストアの構成

OWSMでは、KSS、JKS、HSMおよびPKCS11キーストアがサポートされます。キーストアを作成した後、OWSMを構成してキーストアにアクセスおよび使用できるようにする必要があります。configureWSMKeystoreコマンドを使用して、OWSMキーストアを構成できます。

JKSキーストアを使用するようにOWSMを構成すると、資格証明マップoracle.wsm.securityおよび定義するすべてのキーについて、資格証明ストア内にエントリが作成されます。

ドメインごとに単一のOWSMキーストアが存在し、ドメイン内で実行するすべてのWebサービスおよびクライアントによってそのキーストアが共有されることに注意してください。

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

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

復号化キーのパスワードを資格証明ストアに格納します。キー名としてkeystore.enc.csf.keyを使用します。

完全な手順は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の資格証明ストアへのキーおよびユーザー資格証明の追加に関する項を参照してください。

2.3.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.3.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に関する項を参照してください。