Oracle® Fusion Middleware

Oracle WebLogic Server WebLogic Webサービスの保護

12c (12.1.2)

E48034-02(原本部品番号:E28143-02)

2014年2月

トランスポート・レベルおよびメッセージ・レベルのセキュリティの構成を含め、Oracle WebLogic ServerのWebLogic Webサービスを保護する方法について説明する、セキュリティ・ソフトウェア開発者向けドキュメント。

Oracle Fusion Middleware Oracle WebLogic Server WebLogic Webサービスの保護, 12c (12.1.2)

E48034-02

Copyright © 2007, 2014, Oracle and/or its affiliates. All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

このガイドでの新しい情報

- 12c (12.1.2)の新機能と変更された機能

1 Webサービス・セキュリティの概要

- Webサービス・セキュリティの概要

- どのタイプのセキュリティを構成すべきか

- スレッドの安全性

2 メッセージ・レベルのセキュリティの構成

- メッセージ・レベルのセキュリティの概要

- サポートされるWebサービス・セキュリティ標準

- Web Services TrustとWeb Services Secure Conversation

- Web Services SecurityPolicy 1.2

- メッセージ・レベルのセキュリティの主な使用例

- メッセージ・レベルのセキュリティ構成でのポリシー・ファイルの使用

- JAX-WSでのポリシー・ファイルの使用

- WS-Policyのネームスペース

- WS-SecurityPolicyのネームスペース

- バージョンに依存しないポリシーのサポート

- SHA-256セキュア・ハッシュ・アルゴリズムの使用

- 事前定義済のSHA-1ポリシーのSHA-256への更新

- 簡易なメッセージ・レベルのセキュリティの構成

- 簡易なメッセージ・レベルのセキュリティの構成: 主な手順

- WebLogic Serverでクライアントの証明書を検証できることの確認

- @Policyおよび@PoliciesアノテーションによるJWSファイルの更新

- uri属性の設定

- その他の属性の設定

- @Policyおよび@Policies JWSアノテーションの使用例

- CLASSPATHからのポリシーのロード

- 「すぐに使用できる」SSLペア以外のキー・ペアの使用

- メッセージ保護されたWebサービスを呼び出すためのクライアント・アプリケーションの更新

- WebLogic Serverインスタンスで実行中のクライアントからのWebサービスの呼出し

- JAX-WS Webサービスにセキュリティを追加する例

- カスタム・ポリシー・ファイルの作成と使用

- WS-Trustクライアントの構成

- サポートされるトークン・タイプ

- WS-Trustクライアント・プロパティの構成

- セキュア・トークン・サービスのURIの取得

- WS-SecureConversation用のSTS URIの構成: スタンドアロン・クライアント

- SAML用のSTS URIの構成: スタンドアロン・クライアント

- WLSTを使用したSTS URIの構成: サーバー側のクライアント

- コンソールを使用したSTS URIの構成: サーバー側のクライアント

- STSセキュリティ・ポリシーの構成: スタンドアロン・クライアント

- WLSTを使用したSTSセキュリティ・ポリシーの構成: サーバー側のクライアント

- コンソールを使用したSTSセキュリティ・ポリシーの構成

- STS SOAPおよびWS-Trustバージョンの構成: スタンドアロン・クライアント

- SAML STSサーバー証明書の構成: スタンドアロン・クライアント

- HTTPSを介するSAML 2.0 BearerトークンのサンプルWS-Trustクライアント

- WSS 1.1メッセージ保護でSAML 2.0 Bearerトークンを使用するサンプルWS-Trustクライアント

- セキュリティ・コンテキストおよび派生キーの構成と使用

- 仕様の後方互換性

- WS-SecureConversationとクラスタ

- セキュリティ・コンテキストのネゴシエーションを行うためのクライアント・アプリケーションの更新

- 管理コンソールを使用した実行時のポリシー・ファイルの関連付け

- Security Assertion Markup Language (SAML)トークンのアイデンティティとしての使用

- SAMLトークンの概要

- SAMLトークンのアイデンティティとしての使用: 主な手順

- SAML確認メソッドの指定

- SAML確認メソッドの指定(プロプライエタリのポリシーのみ)

- HTTPSを介するSAML 1.1 Bearerトークンのサンプル

- WebサービスのSAML属性の構成

- SAML属性の使用: 使用可能なインタフェースおよびクラス

- SAML属性の使用: 主な手順

- SAML属性の例

- Webサービスとデフォルト以外のセキュリティ構成との関連付け

- 資格証明プロバイダの有効なクラス名とトークン・タイプ

- システム・プロパティを使用したメッセージ・レベルのセキュリティのデバッグ

- クライアント側のセキュリティ・ポリシー・ファイルの使用

- ポリシー・ファイルとクライアント・アプリケーションの関連付け: 主な手順

- ポリシー・ファイルをロードするメソッドを生成するためのclientgenの更新

- ポリシー・ファイルをロードするためのクライアント・アプリケーションの更新(JAX-RPCのみ)

- WS-SecurityPolicy 1.2ポリシー・ファイルの使用

- トランスポート・レベルのポリシー

- 保護アサーション・ポリシー

- WS-Security 1.0のユーザー名およびX509トークン・ポリシー

- WS-Security 1.1のユーザー名およびX509トークン・ポリシー

- WS-SecureConversationポリシー

- SAML Token Profileポリシー

- ポリシーの選択

- サポートされないWS-SecurityPolicy 1.2アサーション

- Optionalポリシー・アサーションの使用

- 要素レベルのセキュリティの構成

- 要素レベルのカスタム・ポリシー・ファイルの定義と使用

- JWSファイルへのPolicyアノテーションの追加

- 実装に関する注意

- 適切なポリシーの選択

- ポリシー選択肢を含むセキュリティ・ポリシーの例

- 適切なポリシー選択の構成

- ポリシー・プリファレンスの決定の仕組み

- コンソールでの適切なポリシー選択の構成

- 適切なポリシーにおける本文の暗号化の理解

- スタンドアロン・クライアントの適切なポリシーの選択

- 複数のトランスポート・アサーション

- MTOM Webサービスにセキュリティを追加する例

- この例で使用されるファイル

- SecurityMtomService.java

- MtomClient.java

- configWss.pyスクリプト・ファイル

- build.xmlファイル

- サンプルのビルドおよび実行

- SecurityMtomServiceのデプロイ済WSDL

- 信頼性のあるメッセージングWebサービスにセキュリティを追加する例

- セキュアで信頼性のあるSOAPメッセージングの概要

- サンプルの概要

- サンプルにおけるセキュリティの設定

- この例で使用されるファイル

- 変更されたReliableEchoServiceImpl.java

- 変更されたconfigWss.py

- 変更されたconfigWss_Service.py

- サンプルのビルドおよび実行

- Webサービスの原子性トランザクションの保護

- プロプライエタリのWebサービス・セキュリティ・ポリシー・ファイル(JAX-RPCのみ)

- 抽象および具象ポリシー・ファイル

- Auth.xml

- Sign.xml

- Encrypt.xml

- Wssc-dk.xml

- Wssc-sct.xml

3 トランスポート・レベルのセキュリティの構成

- ポリシーによるトランスポート・レベルのセキュリティの構成

- 使用可能なトランスポート・レベルのポリシー

- 前提条件: SSLの構成

- SSLの構成: 主な手順

- クライアント・アプリケーションでの双方向SSLの構成

- ポリシーによるトランスポート・レベルのセキュリティの構成: 主な手順

- JAX-WSのトランスポート・セキュリティの構成例

- 一方向SSL (HTTPSおよびHTTP基本認証の例)

- SSLにおけるリクエストの状態の永続化(JAX-WSのみ)

- システム・プロパティからSSLSocketFactoryを取得する例

- UserDataConstraintによるトランスポート・レベルのセキュリティの構成: 主な手順(JAX-RPCのみ)

- 信頼性のあるメッセージングでのカスタムSSLアダプタの使用(JAX-RPCのみ)

4 アクセス制御セキュリティの構成(JAX-RPCのみ)

- アクセス制御セキュリティの構成: 主な手順

- セキュリティ関連アノテーションでのJWSファイルの更新

- @RunAsアノテーションでのJWSファイルの更新

- サービス・オブジェクト作成時のユーザー名とパスワードの設定

A Oracle Web Services Managerセキュリティ・ポリシーの使用

- OWSMセキュリティ・ポリシーの概要

- Java EE WebサービスでサポートされているOWSMポリシー

- OWSMセキュリティ・ポリシーを使用するケース

- WebLogic Webサービス・ポリシーおよびOWSMポリシーの相互運用性

- OWSMセキュリティ・ポリシーのJAX-WS Webサービスへのアタッチ

- 管理コンソールを使用したOWSMセキュリティ・ポリシーのアタッチ

- ポリシー・アタッチ後のキャッシュのリフレッシュ

- OWSMセキュリティ・ポリシーのJAX-WS Webサービス・クライアントへのアタッチ

- ポリシーの構成

- Webサービス・クライアントのポリシー構成のオーバーライド

- Webサービスのモニターおよびテスト

はじめに

ここでは、このガイド『Oracle WebLogic Server WebLogic Webサービスの保護』で使用されるドキュメントのアクセシビリティ機能および表記規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

Oracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害があるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このガイドでの新しい情報

次のトピックでは、WebLogic Webサービス・セキュリティの新機能と変更された機能を紹介し、詳細情報の参照先を提供します。

12c (12.1.2)の新機能と変更された機能

Oracle Fusion Middleware 12c (12.1.2)のこのドキュメントでは、次の新機能と変更された機能について説明します。

- SHA-256セキュア・ハッシュ・アルゴリズムのサポート。詳細は、「SHA-256セキュア・ハッシュ・アルゴリズムの使用」を参照してください。

- Oracle Webサービス・マネージャ(OWSM)のセキュリティ・ポリシーをアタッチするためのアノテーション・サポートは、WebLogic Webサービスのみでなく、WebLogic Webサービス・クライアントでも使用できるようになりました。サポートされるアノテーションには次のものがあります。

- OWSMポリシーをアタッチするときに構成プロパティをオーバーライドするweblogic.wsee.jws.jaxws.owsm.Propertyアノテーション。

- OWSMポリシーの配列をアタッチするweblogic.wsee.jws.jaxws.owsm.SecurityPoliciesアノテーション。

- OWSMポリシーをアタッチするweblogic.wsee.jws.jaxws.owsm.SecurityPolicyアノテーション。

詳細は、「OWSMセキュリティ・ポリシーのJAX-WS Webサービス・クライアントへのアタッチ」を参照してください。

1 Webサービス・セキュリティの概要

この章では、WebLogic Webサービスのセキュリティの構成方法について説明します。

この章の内容は次のとおりです:

- Webサービス・セキュリティの概要

- どのタイプのセキュリティを構成すべきか

- スレッドの安全性

Webサービス・セキュリティの概要

WebLogic Webサービスを保護するには、次の3種類のセキュリティを1つ以上構成します。

表1-1 Webサービスのセキュリティ

セキュリティのタイプ

説明

メッセージ・レベルのセキュリティ

SOAPメッセージのデータをデジタル署名または暗号化します。認証用のアイデンティティ・トークンを含めることもできます。第2章「メッセージ・レベルのセキュリティの構成」を参照してください。

トランスポート・レベルのセキュリティ

SSLを使用してクライアント・アプリケーションとWebサービスの間の接続を保護します。第3章「トランスポート・レベルのセキュリティの構成」を参照してください。

アクセス制御セキュリティ

Webサービスにアクセスできるロールを指定します。第4章「アクセス制御セキュリティの構成(JAX-RPCのみ)」を参照してください。

どのタイプのセキュリティを構成すべきか

メッセージ・レベルのセキュリティには、SSLのすべてのセキュリティの利点が含まれますが、追加の柔軟性と機能が伴います。メッセージ・レベルのセキュリティはエンド・ツーエンドです。つまり、トランザクションに複数の仲介機能が含まれる場合でもSOAPメッセージのセキュリティは保護されます。接続だけでなく、SOAPメッセージ自体がデジタル署名および暗号化されます。また、メッセージの個々の部分や要素のみを署名または暗号化したり、必須にするよう指定できます。これに対し、トランスポート・レベルのセキュリティでは接続そのものしか保護されません。つまり、クライアントとWebLogic Serverの間にルーターやメッセージ・キューなどの仲介機能がある場合、その仲介機能はSOAPメッセージをプレーン・テキストで取得します。仲介機能から次の送信先にメッセージが送信されたとき、その受信側では元々そのメッセージがどこから来たのかわかりません。また、SSLで使用される暗号化は「オール・オア・ナッシング」です。つまり、SOAPメッセージの全体が暗号化されるか、あるいはまったく暗号化されないかのいずれかになります。SOAPメッセージの選択部分のみを暗号化するように指定する方法はありません。メッセージ・レベルのセキュリティには認証用のIDトークンを含めることができます。

トランスポート・レベルのセキュリティでは、クライアント・アプリケーションとWebLogic Serverの間の接続がSecure Sockets Layer (SSL)で保護されます。SSLでは、ネットワーク接続している2つのアプリケーションが互いのアイデンティティを認証できるようにするとともに、アプリケーション間でやりとりされるデータを暗号化することでセキュアな接続が実現します。認証を使用すると、サーバー(および必要に応じてクライアント)はネットワーク接続の相手側アプリケーションのIDを検証できます。クライアント証明書(双方向SSL)を使用してユーザーを認証できます。

ネットワーク経由で送信されるデータは暗号化されるので、予定されている宛先以外には解釈できません。

トランスポート・レベルのセキュリティには、SSLだけでなくHTTP基本認証も含まれます。

アクセス制御のセキュリティは、「誰が何を実行できるか」という質問の回答となります。まず、Webサービスへのアクセスが許可されているセキュリティ・ロールを指定します。セキュリティ・ロールとは、特定の条件に基づいてユーザーまたはグループに付与される権限です。次に、クライアント・アプリケーションがWebサービス操作を呼び出そうとするときに、そのクライアントはWebLogic Serverに対して自身を認証し、権限がある場合はその呼出しを続行することができます。アクセス制御セキュリティは、WebLogic Serverのリソースのみを保護します。つまり、アクセス制御のセキュリティのみを構成した場合は、クライアント・アプリケーションとWebLogic Serverの接続が保護されず、SOAPメッセージはプレーン・テキストになります。

スレッドの安全性

JAX-RPCクライアントおよびJAX-WSクライアントはスレッド・セーフではありません。

生成されるJAX-RPCクライアント・スタブはデフォルトでスレッド・セーフです。ただし、SSLを有効にすると、クライアント・スタブはスレッド・セーフではなくなります。

JAX-WSのスレッドの安全性に関する詳細および回避策は、JAX-WSクライアント・プロキシのスレッド・セーフに関する項を参照してください。

2 メッセージ・レベルのセキュリティの構成

この章ではJava API for XML Web Services (JAX-WS)とJava API for XML-based RPC (JAX-RPC)を使用して、WebLogic Webサービスでメッセージ・レベルのセキュリティを構成する方法について説明します。

この章の内容は次のとおりです:

- メッセージ・レベルのセキュリティの概要

- メッセージ・レベルのセキュリティの主な使用例

- メッセージ・レベルのセキュリティ構成でのポリシー・ファイルの使用

- 簡易なメッセージ・レベルのセキュリティの構成

- メッセージ保護されたWebサービスを呼び出すためのクライアント・アプリケーションの更新

- JAX-WS Webサービスにセキュリティを追加する例

- カスタム・ポリシー・ファイルの作成と使用

- WS-Trustクライアントの構成

- セキュリティ・コンテキストおよび派生キーの構成と使用

- 管理コンソールを使用した実行時のポリシー・ファイルの関連付け

- Security Assertion Markup Language (SAML)トークンのアイデンティティとしての使用

- Webサービスとデフォルト以外のセキュリティ構成との関連付け

- 資格証明プロバイダの有効なクラス名とトークン・タイプ

- システム・プロパティを使用したメッセージ・レベルのセキュリティのデバッグ

- クライアント側のセキュリティ・ポリシー・ファイルの使用

- WS-SecurityPolicy 1.2ポリシー・ファイルの使用

- ポリシーの選択

- サポートされないWS-SecurityPolicy 1.2アサーション

- Optionalポリシー・アサーションの使用

- 要素レベルのセキュリティの構成

- 適切なポリシーの選択

- 複数のトランスポート・アサーション

- 信頼性のあるメッセージングWebサービスにセキュリティを追加する例

- Webサービスの原子性トランザクションの保護

- プロプライエタリのWebサービス・セキュリティ・ポリシー・ファイル(JAX-RPCのみ)

メッセージ・レベルのセキュリティの概要

メッセージ・レベルのセキュリティでは、クライアント・アプリケーションと、そのクライアントによって呼び出されるWebサービスとの間のSOAPメッセージに、デジタル署名または暗号化(あるいはその両方)を施すかどうかを指定します。複数のSOAPメッセージを交換するイベントにおいて、Webサービスとクライアントの間の共有セキュリティ・コンテキストを指定することもできます。メッセージ・レベルのセキュリティは次のことを実現します。

- メッセージ部分の暗号化による機密性

- デジタル署名による整合性

- ユーザー名トークン、X.509トークンまたはSAMLトークンを要求することによる認証

簡易なメッセージ・レベルのセキュリティを構成する場合に実行する基本的な手順については、「簡易なメッセージ・レベルのセキュリティの構成」を参照してください。この節では、Webサービス実行時環境のメッセージ・レベルのセキュリティの構成、特定のWebサービスに対するメッセージ・レベルのセキュリティの構成、およびそのサービスを呼び出すクライアント・アプリケーションのコーディング方法について説明します。

また、Webサービスをデプロイした後、実行時にWebサービスのメッセージ・レベルのセキュリティを構成することもできます。詳細は、「管理コンソールを使用した実行時のポリシー・ファイルの関連付け」を参照してください。

注意:

SOAP添付ファイルに対しては、デジタル署名も暗号化も行えません。

サポートされるWebサービス・セキュリティ標準

注意:

「WebLogic Webサービスでサポートされる標準」には、このリリースでサポートされるWebサービス標準が明確に記載されています。

WebLogic Webサービスは、次のOASIS Standard 1.1 Web Services Security (WS-Security 1.1 (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss)仕様(2006年2月1日付)を実装しています。

- WS-Security 1.0および1.1

- Username Token Profile 1.0および1.1

- X.509 Token Profile 1.0および1.1

- SAML Token Profile 1.0および1.1

これらの仕様は、セキュリティ・トークンの伝播、メッセージの整合性、およびメッセージの機密性を提供します。これらのメカニズムは、個別に使用する(たとえば、ユーザー認証のためにユーザー名トークンを渡す)か、または組み合せて使用する(たとえば、SOAPメッセージのデジタル署名と暗号化を行い、認証のためにユーザーがX.509証明書を使用すべきことを指定する)ことができます。

Web Services TrustとWeb Services Secure Conversation

WebLogic Webサービスは、Web Services Trust (WS-Trust 1.3)仕様とWeb Services Secure Conversation (WS-SecureConversation 1.3)仕様を実装しています。これらが連携して、Webサービスとそのクライアント(別のWebサービスやスタンドアロンのJavaクライアント・アプリケーション)との間のセキュアな通信を提供します。

WS-Trust仕様には、セキュリティ・トークンのリクエストと発行や信頼関係の仲介を行うためのフレームワークとなる拡張機能が定義されています。

WS-SecureConversation仕様には、複数のメッセージの交換を可能にする、セキュリティ・コンテキストの確立と共有のメカニズムや、セキュリティ・コンテキストからキーを派生するためのメカニズムが定義されています。セキュリティ・コンテキストと派生キーを併用すると、交換のパフォーマンスとセキュリティが全体的に向上します。

Web Services SecurityPolicy 1.2

WS-Policy仕様では、Webサービスの制約や要件を表現するためのフレームワークが定義されています。これらの制約や要件は、ポリシー・アサーションとして表現されます。

WS-SecurityPolicyでは、WS-Policyフレームワークで使用する一連のセキュリティ・ポリシー・アサーションが定義され、WSSのコンテキストでメッセージを保護する方法(SOAPメッセージ・セキュリティ、WS-TrustおよびWS-SecureConversation)が記述されています。

Webサービスに対してメッセージ・レベルのセキュリティを構成するには、WS-SecurityPolicy仕様に従って、セキュリティ・ポリシー文を格納した1つ以上のポリシー・ファイルをWebサービスにアタッチします。Webサービス実行時環境におけるセキュリティ・ポリシー・ファイルの使用方法の詳細は、「メッセージ・レベルのセキュリティ構成でのポリシー・ファイルの使用」を参照してください。

このリリースのWebLogic ServerでサポートされないWeb Services SecurityPolicy 1.2の要素については、「サポートされないWS-SecurityPolicy 1.2アサーション」を参照してください。

メッセージ・レベルのセキュリティの主な使用例

Web Services Security: SOAP Message Security仕様の実装では、次の使用例がサポートされます。

- SOAPメッセージの署名と暗号化にX.509証明書を使用します。SOAPメッセージは、メッセージ保護されたWebサービスを呼び出すクライアント・アプリケーションを起点に、WebサービスのホストであるWebLogic Serverインスタンスへ送られ、またクライアント・アプリケーションに戻ります。

- 署名または暗号化される、あるいは要求されるSOAPメッセージ・ターゲット(本文、特定のSOAPヘッダー、または特定の要素)を指定します。

- 認証のためにSOAPメッセージにトークン(ユーザー名、SAML、またはX.509)を含めます。

- Webサービスとそのクライアント(別のWebサービスやスタンドアロンのアプリケーション)が、WS-SecureConversation (WSSC)を使用して複数のメッセージを交換するときに、セキュリティ・コンテキストを確立して共有することを指定します。

- コンテキストが確立され、Webサービスとそのクライアントの間で共有された時点で、セキュリティ・コンテキストにおける各キー用途に応じてキーを派生します。つまり、個々のSOAPメッセージで2つの派生キー(署名用に1つ、暗号用に1つ)を使用し、各SOAPメッセージが他のSOAPメッセージとは別の派生キーのペアを使用することになります。各SOAPメッセージで派生キーの独自のペアを使用することから、クライアントとWebサービスの間のメッセージ交換はきわめてセキュアなものになります。

メッセージ・レベルのセキュリティ構成でのポリシー・ファイルの使用

1つ以上のセキュリティ・ポリシー・ファイルを使用して、WebLogic Webサービスに対するメッセージ・レベルのセキュリティの詳細を指定します。WS-SecurityPolicy仕様では、Webサービスのセキュリティ・ポリシーを記述して通信するための汎用的なモデルとXML構文が提供されています。

注意:

WS-SecurityPolicy仕様が規定される以前の旧リリースのWebLogic Serverでは、WS-Policy仕様に基づき、プロプライエタリのセキュリティ・ポリシー・スキーマを使用して記述されたセキュリティ・ポリシー・ファイルを使用していました。このプロプライエタリのセキュリティ・ポリシー・スキーマは非推奨となりましたので、WS-SecurityPolicy1.2形式を使用してください。

このリリースのWebLogic Serverでは、WS-SecurityPolicy 1.2仕様に準拠するセキュリティ・ポリシー・ファイル、またはWebサービス・セキュリティ・ポリシー・スキーマ(WebLogic Server 9で導入)に準拠するセキュリティ・ポリシー・ファイルのいずれかがサポートされますが、同じWebサービスで両方を使用することはできません。これらのフォーマットは互換性がありません。

事前定義済のWS-SecurityPolicy 1.2セキュリティ・ポリシー・ファイルについては、「WS-SecurityPolicy 1.2ポリシー・ファイルの使用」を参照してください。

メッセージ・レベルのセキュリティに使用されるセキュリティ・ポリシー・ファイルは、操作を呼び出した結果として生成されるSOAPメッセージに対してデジタル署名または暗号化を行うかどうかとその方法が記述されたXMLファイルです。この中では、クライアント・アプリケーションがユーザー名トークン、SAMLトークンまたはX.509トークンを使用して自身を認証することの指定もできます。

ポリシー・ファイルをWebサービスと関連付けるには、JWSファイル内で@Policyおよび@Policies JWSアノテーションを使用します。Webサービスに関連付けることのできるポリシー・ファイルの数に制限はありませんが、アサーションが互いに矛盾しないようにする必要があります。ポリシー・ファイルは、JWSファイルのクラス・レベルでも、メソッド・レベルでも指定できます。

注意:

Webサービスにトランスポート・レベルのセキュリティ・ポリシーを指定する場合、ポリシーの指定はクラス・レベルで行う必要があります。

また、トランスポート・レベルのセキュリティ・ポリシーは着信方向と発信方向の両方に適用する必要があります。つまり、着信にHTTPSを使用し、発信にHTTPを使用することはできません。

この項では、次のトピックについて説明します。

- JAX-WSでのポリシー・ファイルの使用

- WS-Policyのネームスペース

- WS-SecurityPolicyのネームスペース

- バージョンに依存しないポリシーのサポート

- SHA-256セキュア・ハッシュ・アルゴリズムの使用

JAX-WSでのポリシー・ファイルの使用

移植性を最大限に高めるため、JAX-WSではWS-Policy 1.2およびOASIS WS-SecurityPolicy 1.2を使用することをお薦めします。

WS-Policyのネームスペース

WebLogic Serverは、次のネームスペースを使用するWS-Policy 1.2をサポートしています。

http://schemas.xmlsoap.org/ws/2004/09/policy

注意:

WebLogic Serverは、ネームスペースhttp://www.w3.org/ns/ws-policyを使用するWS-Policy 1.5 (現在のW3C規格)もサポートしています。

WS-SecurityPolicyのネームスペース

次のOASIS WS-SX TC Web Services SecurityPolicyネームスペースがサポートされます。

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702

この新しいバージョンのネームスペースに加えて、WebLogic Serverは次のWeb Services SecurityPolicyネームスペースも引き続きサポートします。

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512

ほとんどの場合、ポリシー・アサーションはどちらのネームスペースでも同じですが、次の例外があります。

- Trust10およびTrust13のアサーション。Trust10とTrust13両方のアサーションがサポートされます。

- SC10SecurityContextTokenおよびSC13SecurityContextToken (「仕様の後方互換性」を参照)。

- 異なるWSSCバージョンを使用した派生キー(200502、1.3)。

バージョンに依存しないポリシーのサポート

このバージョンのWebLogic Serverでは、バージョンに依存しないポリシーがサポートされます。異なるバージョンのWS-Policy仕様に基づいたWS-SecurityPolicyやWS-ReliableMessagingポリシーなどのプロトコル固有のポリシーを組み合せることができます。実行時に、結合されたポリシー・ファイルには複数の異なるネームスペースが含まれます。

このリリースのWebLogic Serverでは、次の3つのバージョンのWS-SecurityPolicyが用意されています。

- (1) WS-SecurityPolicy 1.2 OASIS標準。

- (2) WS-SecurityPolicy 1.2 (WebLogic Server 10.0に含まれます)。

- (3) 独自形式のWebLogic Server 9.xスタイルのポリシー(非推奨)。

(1)、(2)、または(1)と(2)の組合せと任意のバージョンのWS-Policyを組み合せることができます。しかし、(1)または(2)や異なるバージョンのWS-Policyと(3)を組み合せることはできません。

考えられるバージョンの組合せを表2-1に示します。

表2-1 バージョンに依存しないポリシーの対応表

セキュリティ・ポリシーのバージョン

WS-Policy 1.5

WS-Policy 1.2

WS-Policy 1.5とWS-Policy 1.2

WS-SecurityPolicy 1.2 OASIS標準

可

可

可

WS-SecurityPolicy 1.2 (WebLogic Server 10.0)

可

可

可

WS-SecurityPolicy 1.2 OASIS標準とWS-SecurityPolicy 1.2 (WebLogic Server 10.0)

可

可

可

WebLogic Server 9.xスタイル

可

可

不可

WebLogic Server 9.xスタイルとWS-SecurityPolicy 1.2 OASIS標準またはWS-SecurityPolicy 1.2 (WebLogic Server 10.0)

不可

不可

不可

使用されているポリシーまたはセキュリティ・ポリシーのバージョンをクライアント・プログラムが認識する必要がある場合は、ネームスペースとバージョニングの情報を戻すバージョニングAPIを使用してください。

SHA-256セキュア・ハッシュ・アルゴリズムの使用

WebLogic Server Webサービス・セキュリティ・ポリシーでは、デジタル署名のハッシュのためにSHA-1およびより強固なSHA-2 (SHA-256)セキュア・ハッシュ・アルゴリズムの両方がサポートされています。

事前定義済のWebサービス・セキュリティ・ポリシーは、<sp:AlgorithmSuite>要素で使用する特定のアルゴリズムを選択します。

WebLogic Serverには、特にSHA-256セキュア・ハッシュ・アルゴリズムを使用するWssp1.2-2007-Wss1.1-X509-Basic256Sha256.xmlのようなポリシーが含まれています。表2-2を参照してください。

使用するポリシーのSHA-256バージョンが存在する場合、古いSHA-1バージョンよりもSHA-250のご使用をお薦めします。

注意:

セキュリティを最大限に強化するため、可能であればSHA-1のかわりにSHA-256を使用することをお薦めします。

古いSHA-1バージョンのポリシーを使用している場合、SHA-256を使用するようにWebサービスを更新することをお薦めします。

表2-2 SHA-256ポリシーの使用

このSHA-1ポリシーのかわりに

...このSHA-256ポリシーを使用します

Wssp1.2-2007-Https-UsernameToken-Plain.xml

Wssp1.2-2007-Https-UsernameToken-Plain-Basic256Sha256.xml

Wssp1.2-2007-Wss1.1-X509-Basic256.xml

Wssp1.2-2007-Wss1.1-X509-Basic256Sha256.xml

Wssp1.2-2007-Wss1.1-UsernameToken-Plain-X509-Basic256.xml

Wssp1.2-2007-Wss1.1-UsernameToken-Plain-X509-Basic256Sha256.xml

Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-UsernameToken-Plain-X509-Basic256.xml

Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-UsernameToken-Plain-X509-Basic256Sha256.xml

Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.1.xml

Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.1-Basic256Sha256.xml

Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1.xml

Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1-Basic256Sha256.xml

Wssp1.2-2007-Saml2.0-Bearer-Https.xml

Wssp1.2-2007-Saml2.0-Bearer-Https-Basic256Sha256.xml

事前定義済のSHA-1ポリシーのSHA-256への更新

この項にリストされている事前定義済のポリシーでは、デジタル署名にSHA-1が使用されます。『NIST Special Publication 800-131A』の「Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths」に記載されているように、このハッシュ・アルゴリズムでは、セキュリティに関するお客様の現在または将来の要求に応えられない可能性があります。

現在、このポリシーをひとつでも使用しているお客様には次のことをお薦めします。

1. 事前定義済のポリシーのテンプレートをもとに、カスタム・ポリシーを作成してください。カスタム・ポリシー・ファイルの作成の詳細は、「カスタム・ポリシー・ファイルの作成と使用」を参照してください。
ポリシー・ファイルは、WL_HOME/server/lib/weblogic-classes.jarにあります。weblogic-classes.jar内では、ポリシー・ファイルは/weblogic/wsee/policy/runtimeに位置しています。

2. カスタム・ポリシーを編集し、アルゴリズム・スイートをSHA-256に変更します。これを行うには、ポリシー内のアルゴリズム・スイートを変更します。
現在

<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>

変更後

<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256Sha256/>
</wsp:Policy>
</sp:AlgorithmSuite>

3. ご使用のWebサービスには、このカスタム・ポリシーを使用します。

4. クライアント側のポリシーも合わせて編集します。クライアントとWebサービスは同じハッシュ・アルゴリズムを使用していることが必要です。つまり、<AlgorithmSuite>が同じである必要があります。そうでない場合は、Webサービスはクライアントから送信されるリクエスト・メッセージを拒否します。

SAMLポリシー

次の事前定義済のポリシーでは、SHA-1アルゴリズムが使用されています。この項での説明に従って、SHA-256を使用するようにポリシーを編集します。

- Wssp1.2-2007-Saml1.1-Bearer-Wss1.1.xml

- Wssp1.2-2007-Saml1.1-HolderOfKey-Wss1.0.xml

- Wssp1.2-2007-Saml1.1-HolderOfKey-Wss1.1-Asymmetric.xml

- Wssp1.2-2007-Saml1.1-HolderOfKey-Wss1.1-IssuedToken.xml

- Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xml

- Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.1.xml

- Wssp1.2-2007-Saml2.0-Bearer-Wss1.1.xml

- Wssp1.2-2007-Saml2.0-HolderOfKey-Wss1.1-Asymmetric.xml

- Wssp1.2-2007-Saml2.0-HolderOfKey-Wss1.1-IssuedToken.xml

- Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1.xml

- Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1-Asymmetric.xml

Wss1.0ポリシー

次の事前定義済のポリシーでは、SHA-1アルゴリズムが使用されています。この項での説明に従って、SHA-256を使用するようにポリシーを編集します。

- Wssp1.2-2007-Wss1.0-UsernameToken-Digest-X509-Basic256.xml

- Wssp1.2-2007-Wss1.0-UsernameToken-Plain-X509-Basic256.xml

- Wssp1.2-2007-Wss1.0-X509-Basic256.xml

- Wssp1.2-Wss1.0-UsernameToken-Digest-X509-Basic256.xml

- Wssp1.2-Wss1.0-UsernameToken-Plain-X509-Basic256.xml

- Wssp1.2-Wss1.0-X509-Basic256.xml

- Wssp1.2-Wss1.0-X509-EncryptRequest-SignResponse.xml

- Wssp1.2-Wss1.0-X509-SignRequest-EncryptResponse.xml

Wss1.1ポリシー

次の事前定義済のポリシーでは、SHA-1アルゴリズムが使用されています。この項での説明に従って、SHA-256を使用するようにポリシーを編集します。

- Wssp1.2-2007-Wss1.1-DK-X509-SignedEndorsing.xml

- Wssp1.2-2007-Wss1.1-EncryptedKey-X509-SignedEndorsing.xml

- Wssp1.2-2007-Wss1.1-UsernameToken-Digest-DK.xml

- Wssp1.2-2007-Wss1.1-UsernameToken-Digest-EncryptedKey.xml

- Wssp1.2-2007-Wss1.1-UsernameToken-Digest-X509-Basic256.xml

- Wssp1.2-2007-Wss1.1-UsernameToken-Plain-DK.xml

- Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey.xml

- Wssp1.2-2007-Wss1.1-UsernameToken-Plain-X509-Basic256.xml

- Wssp1.2-2007-Wss1.1-X509-Basic256.xml

- Wssp1.2-Wss1.1-DK.xml

- Wssp1.2-Wss1.1-DK-X509-Endorsing.xml

- Wssp1.2-Wss1.1-EncryptedKey.xml

- Wssp1.2-Wss1.1-EncryptedKey-X509-SignedEndorsing.xml

- Wssp1.2-Wss1.1-UsernameToken-DK.xml

- Wssp1.2-Wss1.1-X509-Basic256.xml

- Wssp1.2-Wss1.1-X509-EncryptRequest-SignResponse.xml

- Wssp1.2-Wss1.1-X509-SignRequest-EncryptResponse.xml

セキュアな対話型ポリシー

次の事前定義済のポリシーでは、SHA-1アルゴリズムが使用されています。この項での説明に従って、SHA-256を使用するようにポリシーを編集します。

- Wssp1.2-2007-Wssc1.3-Bootstrap-Https.xml

- Wssp1.2-2007-Wssc1.3-Bootstrap-Https-BasicAuth.xml

- Wssp1.2-2007-Wssc1.3-Bootstrap-Https-ClientCertReq.xml

- Wssp1.2-2007-Wssc1.3-Bootstrap-Https-Saml1.1-Bearer.xml

- Wssp1.2-2007-Wssc1.3-Bootstrap-Https-UNT.xml

- Wssp1.2-2007-Wssc1.3-Bootstrap-Wss1.0.xml

- Wssp1.2-2007-Wssc1.3-Bootstrap-Wss1.1.xml

- Wssp1.2-2007-Wssc1.3-Bootstrap-Wss1.1-Saml1.1-Bearer.xml

- Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-Saml1.1-SenderVouches.xml

- Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-UsernameToken-Plain-X509-Basic256.xml

- Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.1-Saml1.1-SenderVouches.xml

- Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.1-Saml2.0-Bearer.xml

- Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.1-UsernameToken-Plain-EncryptedKey.xml

- Wssp1.2-Wssc200502-Bootstrap-Wss1.1.xml

簡易なメッセージ・レベルのセキュリティの構成

この項では、Webサービス・セキュリティ・ランタイム、特定のWebLogic Webサービス、およびWebサービスの操作を呼び出すクライアント・アプリケーションに、簡易なメッセージ・レベルのセキュリティを構成する手順について説明します。このドキュメントでは、簡易なメッセージ・レベルのセキュリティを次のように定義します。

- メッセージ保護されたWebサービスは、ユーザーが作成したWS-SecurityPolicyファイルではなく、事前定義済のWS-SecurityPolicyファイルを使用してセキュリティ要件を指定します。これらのファイルについては、「メッセージ・レベルのセキュリティ構成でのポリシー・ファイルの使用」で説明しています。

- Webサービスは、関連付けられたセキュリティ・ポリシー・ファイルを、公開されているデプロイ済WSDLにアタッチすることで公開できるようにします。

- Webサービス・ランタイムは、暗号化とデジタル署名に、固有のキー・ペアではなく、デフォルトのキーストアに用意されている秘密鍵とX.509証明書のペアを使用します。これらの「すぐに使用できる」ペアは、WebLogic Serverコア・セキュリティ・サブシステムでSSLにも使用されるもので、デモやテストの目的で提供されています。このため、本番では独自のキーストアおよびキー・ペアを使用することを強くお薦めします。「すぐに使用できる」ペア以外のキー・ペアを使用する場合は、「「すぐに使用できる」SSLペア以外のキー・ペアの使用」を参照してください。

注意:

それぞれのWebLogic Serverインスタンスが別々のコンピュータ上で実行されているクラスタにWebサービスをデプロイする場合は、テスト目的であっても、「すぐに使用できる」もの以外のキーストアおよびキー・ペアを使用する必要があります。これは、デフォルトのWebLogic ServerキーストアDemoIdentity.jks内のキー・ペアが、異なるマシン上で動作しているWebLogic Server間で同じになるという保証がないためです。

デフォルトのキーストアを使用する場合は、デプロイされているWebサービスのWSDLで、これらのキーストアの1つから公開鍵が指定されますが、実際にはサービスの呼出しは、別のコンピュータ上で実行されているサーバーによって処理される可能性があり、この場合、サーバーの秘密鍵は、公開されている公開鍵に一致せず、呼出しが失敗してしまいます。この問題は、クラスタ内でデフォルトのキーストアとキー・ペアを使用した場合に発生するものであり、独自のキーストアとキー・ペアを使用することで簡単に解決されます。

- Webサービスを呼び出すクライアントは、X.509トークンではなく、ユーザー名トークンを使用して自身を認証します。

- Webサービスを呼び出すクライアントは、WebLogic Serverで実行されているモジュールではなく、スタンドアロンのJavaアプリケーションです。

前述の一部シナリオの詳細と、簡易なメッセージ・レベルのセキュリティの使用例に基づいたWebサービス・セキュリティのその他の使用例については、後半の項で説明します。

次の手順では、WebLogic Webサービスを実装するJWSファイルがすでに作成済であることを前提として、SOAPメッセージにデジタル署名と暗号化を行うようにそのファイルを更新します。また、Antビルド・スクリプトを使用してWebサービスを反復的に開発することと、新しい情報で更新できる作業用のbuild.xmlファイルがあることも前提となっています。さらに、保護されていないWebサービスを呼び出すクライアント・アプリケーションも用意されているものとします。これらの前提条件が満たされていない場合は、次のドキュメントを参照してください。

- Oracle WebLogic Server JAX-WS Webサービスの開発

- Oracle WebLogic Server JAX-RPC Webサービスの開発

簡易なメッセージ・レベルのセキュリティの構成: 主な手順

WebLogic Webサービスに対して簡易なメッセージ・レベルのセキュリティを構成するには:

1. JWSファイルを更新します。WebLogic固有の@Policyおよび@Policies JWSアノテーションを追加して、Webサービス全体または特定の操作にアタッチされる事前定義済のポリシー・ファイルを指定します。
任意のポリシー・ファイルの指定方法について説明した「@Policyおよび@PoliciesアノテーションによるJWSファイルの更新」を参照してください。

2. 通常の反復的な開発プロセスの一部として、Webサービスを再コンパイルして再デプロイします。
『Oracle WebLogic Server JAX-WS Webサービスの開発』のWebLogic Webサービスの開発に関する項および『Oracle WebLogic Server JAX-RPC Webサービスの開発』のWebLogic Webサービスの開発に関する項を参照してください。

3. クライアント・アプリケーションが使用するキーストアを作成します。アプリケーション・ユーザーごとにクライアント・キーストアを1つ作成することをお薦めします。
Cert Genユーティリティやkeytoolユーティリティ(http://docs.oracle.com/javase/7/docs/technotes/tools/windows/keytool.html)を使用して、この手順を実行できます。開発が目的の場合は、keytoolユーティリティを使用すると簡単に開始できます。

『Oracle WebLogic Serverセキュリティの管理』の秘密鍵、デジタル署名および信頼性のある認証局の取得に関する項を参照してください。

4. 秘密鍵とデジタル証明書のペアを作成し、クライアント・キーストアにロードします。同じペアを使用して、クライアントのSOAPリクエストにデジタル署名を行い、WebLogic ServerからのSOAPレスポンスを暗号化します。
証明書のキーを使用することで暗号化とデジタル署名の両方が行えることを確認してください。また、WebLogic Serverでクライアントの証明書が有効であることを確認する方法については、「WebLogic Serverでクライアントの証明書を検証できることの確認」を参照してください。

注意:

キーの長さは1024ビット以上にする必要があります。

keytoolユーティリティ(http://docs.oracle.com/javase/7/docs/technotes/tools/windows/keytool.html)を使用して、この手順を実行できます。

『Oracle WebLogic Serverセキュリティの管理』の秘密鍵、デジタル署名および信頼性のある認証局の取得に関する項を参照してください。

5. 管理コンソールを使用して、セキュリティ・レルムに認証用のユーザーを作成します。
『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。

6. メッセージ保護されたWebサービスを呼び出すJavaコードを追加し、クライアント・アプリケーションを更新します。
「クライアント側のセキュリティ・ポリシー・ファイルの使用」を参照してください。

7. クライアント・アプリケーションを再コンパイルします。
全般的な情報については、『Oracle WebLogic Server JAX-WS Webサービスの開発』および『Oracle WebLogic Server JAX-RPC Webサービスの開発』を参照してください。

簡易なメッセージ・レベルのセキュリティの使用例に基づいたWebサービス・セキュリティのその他の使用例については、次の項を参照してください。

- 「すぐに使用できる」SSLペア以外のキー・ペアの使用

- カスタム・ポリシー・ファイルの作成と使用

- セキュリティ・コンテキストおよび派生キーの構成と使用

- 管理コンソールを使用した実行時のポリシー・ファイルの関連付け

- Security Assertion Markup Language (SAML)トークンのアイデンティティとしての使用

- WebLogic Serverインスタンスで実行中のクライアントからのWebサービスの呼出し

- Webサービスとデフォルト以外のセキュリティ構成との関連付け

メッセージ保護されたWebサービスの問題をデバッグする方法については、「システム・プロパティを使用したメッセージ・レベルのセキュリティのデバッグ」を参照してください。

WebLogic Serverでクライアントの証明書を検証できることの確認

クライアントがSOAPリクエストのデジタル署名に使用し、WebLogic ServerがクライアントへのSOAPレスポンスの暗号化に使用するX.509証明書をWebLogic Serverで検証できることを確認しておく必要があります。以下のいずれかを実行します。

- 信頼性のある認証局で発行されているためにWebLogic Serverが自動的に信頼するデジタル証明書をクライアント・アプリケーションが取得することを確認します。

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

詳細は、『Oracle WebLogic Serverセキュリティの管理』のSSL証明書の検証に関する項を参照してください。

@Policyおよび@PoliciesアノテーションによるJWSファイルの更新

JWSファイルで@Policyアノテーションおよび@Policiesアノテーションを使用して、Webサービスに1つ以上のポリシー・ファイルがアタッチされていることを指定できます。これらのアノテーションは、クラス・レベルまたはメソッド・レベルのいずれかで使用できます。

注意:

Webサービスにトランスポート・レベルのセキュリティ・ポリシーを指定する場合、ポリシーの指定はクラス・レベルで行う必要があります。

また、トランスポート・レベルのセキュリティ・ポリシーは着信方向と発信方向の両方に適用する必要があります。つまり、着信にHTTPSを使用し、発信にHTTPを使用することはできません。

追加のポリシー・オプションについては、「CLASSPATHからのポリシーのロード」を参照してください。

@Policiesアノテーションは、複数の@Policyアノテーションをグループ化するものです。複数のポリシー・ファイルをクラスまたはメソッドにアタッチする場合は、@Policiesアノテーションを使用してください。ポリシー・ファイルを1つのみアタッチする場合は、@Policyを単独で使用できます。

@Policyアノテーションでは、1つのポリシー・ファイル、その場所、ポリシーがSOAPのリクエスト・メッセージ、レスポンス・メッセージ、またはその両方のいずれに適用されるか、およびそのポリシー・ファイルをサービスの公開WSDLにアタッチするかどうかを指定します。

uri属性の設定

ポリシー・ファイルの場所は、uri属性を使用して次のように指定します。

- WebLogic Serverとともにインストールされる事前定義済のセキュリティ・ポリシー・ファイルを指定するには、次の例に示すように、policy:接頭辞とポリシー・ファイルの名前を使用します。

@Policy(uri="policy:Wssp1.2-2007-Https-BasicAuth.xml")

事前定義済のポリシー・ファイルを使用する場合は、自分でファイルを作成したり、アクセス可能な場所にファイルをパッケージ化したりする必要はありません。このため、できるだけ事前定義済のポリシー・ファイルを使用することをお薦めします。

事前定義済のポリシー・ファイルで提供されるメッセージ・レベルの各種セキュリティについては、「メッセージ・レベルのセキュリティ構成でのポリシー・ファイルの使用」を参照してください。

- ユーザーが作成したポリシー・ファイルを指定するには、次の例に示すように、JWSファイルの場所を基準とした相対パスと名前を指定します。

@Policy(uri="../policies/MyPolicy.xml")

この例では、MyPolicy.xmlファイルは、JWSファイルを格納するディレクトリのpolicies兄弟ディレクトリにあります。

- 共有Java EEライブラリにあるポリシー・ファイルも指定できます。この方法は、別々のJava EEアーカイブにパッケージ化された複数のWebサービス間でファイルを共有する場合に便利です。

注意:

この場合、ポリシー・ファイルが共有Java EEライブラリのMETA-INF/policiesディレクトリまたはWEB-INF/policiesディレクトリにあることを前提としています。ライブラリをパッケージ化する際には、必ずこのディレクトリにポリシー・ファイルを入れてください。

共有Java EEライブラリにあるポリシー・ファイルを指定するには、次の例に示すように、policy接頭辞とポリシー・ファイルの名前を使用します。

@Policy(uri="policy:MySharedPolicy.xml")

共有ライブラリの作成、およびWebサービスが共有のポリシー・ファイルを見つけられるようにするための環境設定については、『Oracle WebLogic Serverアプリケーションの開発』の共有Java EEライブラリおよびオプション・パッケージの作成に関する項を参照してください。

その他の属性の設定

@Policyアノテーションでは次の属性も設定できます。

- direction: ポリシー・ファイルがリクエスト(着信) SOAPメッセージ、レスポンス(発信) SOAPメッセージ、またはその両方のいずれに適用されるかを指定します。この属性を指定しない場合のデフォルト値は、bothです。direction属性には、以下の値を指定できます。

- Policy.Direction.both

- Policy.Direction.inbound

- Policy.Direction.outbound

- attachToWsdl: ポリシー・ファイルを、Webサービスのパブリック規約を記述したWSDLファイルにアタッチするかどうかを指定します。この属性のデフォルト値はfalseです。

@Policyおよび@Policies JWSアノテーションの使用例

次の例では、@Policyおよび@Policies JWSアノテーションの使用方法を示します(該当する個所は太字で示しています)。

例2-1 @Policyおよび@Policiesアノテーションの使用

package wssp12.wss10;

import weblogic.jws.WLHttpTransport;
import weblogic.jws.Policy;
import weblogic.jws.Policies;

import javax.jws.WebService;
import javax.jws.WebMethod;
import javax.jws.Oneway;

/**
* This Web service demonstrates how to use WS-SecurityPolicy 1.2
* to enable message-level security specified in WS-Security 1.0.
*
* The service authenticates the client with a username token.
* Both the request and response messages are signed and encrypted with X509
certificates.
*
*/
@WebService(name="Simple", targetNamespace="http://example.org")
@WLHttpTransport(contextPath="/wssp12/wss10",
serviceUri="UsernameTokenPlainX509SignAndEncrypt")
@Policy(uri="policy:Wssp1.2-2007-Wss1.0-UsernameToken-Plain-X509-Basic256.xml")
public class UsernameTokenPlainX509SignAndEncrypt {

@WebMethod
@Policies({
@Policy(uri="policy:Wssp1.2-2007-SignBody.xml"),
@Policy(uri="policy:Wssp1.2-2007-EncryptBody.xml")})
public String echo(String s) {

return s;
}

@WebMethod
@Policies({
@Policy(uri="policy:Wssp1.2-2007-SignBody.xml"),
@Policy(uri="policy:Wssp1.2-2007-Sign-Wsa-Headers.xml")})
public String echoWithWsa(String s) {
return s;
}

@WebMethod
@Policy(uri="policy:Wssp1.2-2007-SignBody.xml",
direction=Policy.Direction.inbound)
@Oneway
public void echoOneway(String s) {
System.out.println("s = " + s);
}

@WebMethod
@Policies({
@Policy(uri="policy:Wssp1.2-2007-Wss1.0-X509-Basic256.xml",
direction=Policy.Direction.inbound),
@Policy(uri="policy:Wssp1.2-2007-SignBody.xml",
direction=Policy.Direction.inbound)
})
@Oneway
public void echoOnewayX509(String s) {
System.out.println("X509SignEncrypt.echoOneway: " + s);
}
}

この例の次の部分は、Webサービスのバインディング・ポリシーであり、対象となるポリシーが指定されています。

@WebService(name="Simple", targetNamespace="http://example.org")
@WLHttpTransport(contextPath="/wssp12/wss10",
serviceUri="UsernameTokenPlainX509SignAndEncrypt")
@Policy(uri="policy:Wssp1.2-2007-Wss1.0-UsernameToken-Plain-X509-Basic256.xml")

サンプルでは、メソッド・レベルでWebサービスにセキュリティ・ポリシー・ファイルがアタッチされています。指定されたポリシー・ファイルは、WebLogic Serverで事前に定義されているファイルです。つまり、開発者が独自のファイルを作成したり、対応するアーカイブにファイルをパッケージ化したりする必要はありません。

Wssp1.2-2007-SignBody.xmlポリシー・ファイルは、SOAPのリクエスト・メッセージおよびレスポンス・メッセージの両方の本文とWebLogicシステム・ヘッダーにデジタル署名が行われることを指定しています。Wssp1.2-2007-EncryptBody.xmlポリシー・ファイルは、SOAPのリクエスト・メッセージおよびレスポンス・メッセージの両方の本文が暗号化されることを指定しています。

CLASSPATHからのポリシーのロード

このリリースのWebLogic Serverには、ポリシーをCLASSPATHからリソースとしてロードする機能があります。この機能を使用すると、ポリシー・ファイルをWebアプリケーションのルート・ディレクトリにコピーし、JWSファイルの@POLICYアノテーションから名前(mypolicy.xmlなど)で直接参照することができます。

この機能を有効にするには、-Dweblogic.wsee.policy.LoadFromClassPathEnabled=trueを指定してWebLogic Serverを起動します。

この機能を有効にした場合は、ポリシー・ファイルをWEB-INF/policiesディレクトリに移動すると、@POLICYアノテーションの同じmypolicy.xml参照が機能しなくなりますので注意してください。policy:mypolicy.xmlのように、@POLICYアノテーションにポリシー接頭辞を追加する必要が生じます。

「すぐに使用できる」SSLペア以外のキー・ペアの使用

「簡易なメッセージ・レベルのセキュリティの構成」で説明した、簡易なメッセージ・レベルの構成手順では、Webサービス・ランタイムがWebLogic Serverに用意されている秘密鍵とX.509証明書のペアを使用することが前提となっています。SSL用のコア・セキュリティ・サブシステムでも同じキー・ペアが使用されます。このキー・ペアは主にデモまたはテスト目的用に用意されています。本番環境では、Webサービス・ランタイムは通常、独自の秘密鍵とデジタル証明書のペアを2つ使用します。1つはSOAPメッセージの署名用、もう1つはSOAPメッセージの暗号化用です。

次の手順は、これらを使用できるようにするための追加のステップを説明したものです。

1. Webサービス・ランタイムで使用される秘密鍵とデジタル証明書のペアを2つ取得します。ペアの1つはSOAPメッセージのデジタル署名に使用され、もう1つはSOAPメッセージの暗号化に使用されます。
必須ではありませんが、WebLogic Webサービスのみが使用するペアを2つ取得することをお薦めします。両方の証明書のキーの用途が構成の目的と一致していることを確認してください。たとえば、証明書を暗号化に使用するように指定する場合は、証明書のキーの用途が暗号用として指定されているか、または用途が定義されていないことを確認します。そうしないと、Webサービス・セキュリティ・ランタイムによって証明書が拒否されます。

注意:

キーの長さは1024ビット以上にする必要があります。

Cert Genユーティリティやkeytoolユーティリティ(http://docs.oracle.com/javase/7/docs/technotes/tools/windows/keytool.html)を使用して、この手順を実行できます。開発が目的の場合は、keytoolユーティリティを使用すると簡単に開始できます。

『Oracle WebLogic Serverセキュリティの管理』の秘密鍵、デジタル署名および信頼性のある認証局の取得に関する項を参照してください。

2. この時点で存在していない場合は、WebLogic Serverのカスタム・アイデンティティ・キーストアを作成し、前の手順で取得した秘密鍵とデジタル証明書のペアをそのアイデンティティ・キーストアにロードします。
WebLogic ServerをSSL用に構成してある場合は、この手順で使用できるアイデンティティ・キーストアがすでに作成されています。

WebLogicのImportPrivateKeyユーティリティとkeytoolユーティリティ(http://docs.oracle.com/javase/7/docs/technotes/tools/windows/keytool.html)を使用して、この手順を実行できます。開発が目的の場合は、keytoolユーティリティを使用すると簡単に開始できます。

『Oracle WebLogic Serverセキュリティの管理』のキーストアの作成と秘密鍵および信頼性のある認証局のキーストアへのロードに関する項を参照してください。

3. 管理コンソールを使用して、前の手順で作成したキーストアを指定するようにWebLogic Serverを構成します。WebLogic Server用に構成したキーストアをすでに使用している場合、この手順を実行する必要はありません。
『Oracle WebLogic Serverセキュリティの管理』の本番用のキーストアの構成に関する項を参照してください。

4. 管理コンソールを使用して、default_wssと命名でデフォルトWebサービス・セキュリティ構成を作成してください。デフォルトのWebサービス・セキュリティ構成は、別の構成を使用するように明示的にプログラミングされていないかぎり、ドメイン内のすべてのWebサービスで使用されます。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのWebサービス・セキュリティ構成の作成に関する項を参照してください。

5. 秘密鍵とデジタル証明書のペアの一方をSOAPメッセージのデジタル署名に使用するように、前の手順で作成したデフォルトのWebサービス・セキュリティ構成を更新します。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSOAPメッセージの署名に使用されるキー・ペアの指定に関する項を参照してください。この手順では、キーストアとキー・ペアの識別に使用されるプロパティを作成するときに各プロパティの正確な値(IntegrityKeyStore、IntegrityKeyStorePasswordなど)を「名前」フィールドに入力します。ただし、独自に作成したキーストアとキー・ペアを識別する値は「値」フィールドに入力します。

6. 同様に、秘密鍵とデジタル証明書のペアのもう一方をSOAPメッセージの暗号化に使用するように、前の手順で作成したデフォルトのWebサービス・セキュリティ構成を更新します。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSOAPメッセージの暗号化に使用されるキー・ペアの指定に関する項を参照してください。この手順では、キーストアとキー・ペアの識別に使用されるプロパティを作成するときに、各プロパティの「名前」フィールドに正確な値(ConfidentialityKeyStore、ConfidentialityKeyStorePasswordなど)を入力します。ただし、独自に作成したキーストアとキー・ペアを識別する値は「値」フィールドに入力します。

メッセージ保護されたWebサービスを呼び出すためのクライアント・アプリケーションの更新

メッセージ保護されたWebサービスを呼び出すようにJavaコードを更新する場合には、クライアントのキーストアから秘密鍵とデジタル証明書のペアをロードし、その情報を、セキュリティ・ポリシーで必要とされている場合はユーザー認証用のユーザー名およびパスワードとともに、呼び出されるセキュアなWebLogic Webサービスに渡す必要があります。

Webサービスのセキュリティ・ポリシー・ファイルでSOAPリクエストを暗号化するように指定されている場合、Webサービス・クライアント・ランタイムはサービスのWSDLにアタッチされているセキュリティ・ポリシー・ファイルからサーバーの証明書を自動的に取得し、それを暗号化に使用します。ただし、ポリシー・ファイルがWSDLにアタッチされていない場合や、WSDL自体を使用できない場合には、クライアント・アプリケーションはポリシー・ファイルのクライアント・サイドのコピーを使用する必要があります。詳細については、「クライアント側のセキュリティ・ポリシー・ファイルの使用」を参照してください。

例2-2は、メッセージ保護されたWebLogic Webサービス(「セキュリティ関連アノテーションでのJWSファイルの更新」のJWSファイルを参照)を呼び出すJAX-RPCのJavaクライアント・アプリケーションを示しています。このクライアント・アプリケーションは、次の5つの引数を取ります。

- クライアント認証用のクライアント・ユーザー名

- クライアント認証用のクライアント・パスワード

- クライアントの秘密鍵ファイル

- クライアントのデジタル証明書

- デプロイされたWebサービスのWSDL

サンプル・クライアント・アプリケーションのセキュリティ固有のコードは太字で示し、サンプルの後で説明します。

例2-2 メッセージ保護されたWebサービスを呼び出す、JAX-RPCを使用したクライアント・アプリケーション

package examples.webservices.security_jws.client;
import weblogic.security.SSL.TrustManager;
import weblogic.xml.crypto.wss.provider.CredentialProvider;
import weblogic.xml.crypto.wss.WSSecurityContext;
import weblogic.wsee.security.bst.ClientBSTCredentialProvider;
import weblogic.wsee.security.unt.ClientUNTCredentialProvider;
import javax.xml.rpc.Stub;
import java.util.List;
import java.util.ArrayList;
import java.security.cert.X509Certificate;
/**
*  Copyright © 1996, 2008, Oracle and/or its affiliates.
*  All rights reserved.
*/
public class SecureHelloWorldClient {
public static void main(String[] args) throws Throwable {
//username or password for the UsernameToken
String username = args[0];
String password = args[1];
//client private key file
String keyFile = args[2];
//client certificate
String clientCertFile = args[3];
String wsdl = args[4];
SecureHelloWorldService service = new SecureHelloWorldService_Impl(wsdl + "?WSDL" );
SecureHelloWorldPortType port = service.getSecureHelloWorldServicePort();
//create credential provider and set it to the Stub
List credProviders = new ArrayList();
//client side BinarySecurityToken credential provider -- x509
CredentialProvider cp = new ClientBSTCredentialProvider(clientCertFile, keyFile);
credProviders.add(cp);
//client side UsernameToken credential provider
cp = new ClientUNTCredentialProvider(username, password);
credProviders.add(cp);
Stub stub = (Stub)port;
stub._setProperty(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders);
stub._setProperty(WSSecurityContext.TRUST_MANAGER,
new TrustManager(){
public boolean certificateCallback(X509Certificate[] chain, int validateErr){
return true;
}
} );
String response = port.sayHello("World");
System.out.println("response = " + response);
}
}

このコードで注目すべき主な点は次のとおりです。

- WebLogicセキュリティTrustManager APIをインポートします。

import weblogic.security.SSL.TrustManager;

- 次のWebLogic Webサービス・セキュリティAPIをインポートし、Webサービスに関連付けられたポリシー・ファイルで指定されているように、必要なクライアント側の資格証明プロバイダを作成します。

import weblogic.xml.crypto.wss.provider.CredentialProvider;
import weblogic.xml.crypto.wss.WSSecurityContext;
import weblogic.wsee.security.bst.ClientBSTCredentialProvider;
import weblogic.wsee.security.unt.ClientUNTCredentialProvider;

- ClientBSTCredentialProvider WebLogic APIを使用して、クライアントの証明書と秘密鍵からバイナリ・セキュリティ・トークン資格証明プロバイダを作成します。

CredentialProvider cp =
new ClientBSTCredentialProvider(clientCertFile, keyFile);

- ClientUNTCredentialProvider WebLogic APIを使用して、クライアントのユーザー名とパスワードからユーザー名トークンを作成します。ユーザー名とパスワードはWebLogic Serverによっても認識されます。

cp = new ClientUNTCredentialProvider(username, password);

- WSSecurityContext.CREDENTIAL_PROVIDER_LISTプロパティを使用して、バイナリ・セキュリティ・トークンおよびユーザー名トークンを含むListオブジェクトをJAX-RPCスタブに渡します。

stub._setProperty(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders)

JAX-WSの場合は、これを次のようにコーディングできます。

import javax.xml.ws.BindingProvider;
:
Map<String, Object> requestContext = ((BindingProvider) port).getRequestContext();
requestContext.put(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders);

- weblogic.security.SSL.TrustManager WebLogicセキュリティAPIを使用して、SOAPリクエストの暗号化に使用される証明書が有効かどうかを確認します。Webサービス・クライアント・ランタイムはWebサービスのデプロイされたWSDLからこの証明書を取得します。本番の状況では、この証明書は自動的には信頼されないので、クライアント・アプリケーションでは、その証明書を使用してSOAPリクエストを暗号化する前に、証明書が有効であることを確認する必要があります。

stub._setProperty(WSSecurityContext.TRUST_MANAGER,
new TrustManager(){
public boolean certificateCallback(X509Certificate[] chain, int validateErr){
return true;
}
} );

JAX-WSの場合は、これを次のようにコーディングできます。

requestContext.put(WSSecurityContext.TRUST_MANAGER,
new TrustManager() {
public boolean certificateCallback(X509Certificate[] chain,
int validateErr) {
return true;
}
});

この例は、クライアント側のTrustManager APIを示しています。Webサービス・アプリケーションには、セキュリティを確保するため、適切な検証コードを実装する必要があります。

例2-3は、メッセージ保護されたWebサービスを呼び出すJAX-WSのJavaクライアント・アプリケーションを示しています。このサンプル・クライアント・アプリケーションの中で、JAX-WS固有のコードは太字で表されています。

例2-3 メッセージ保護されたWebサービスを呼び出すJAX-WSのクライアント・アプリケーション

package examples.webservices.security_jaxws.client;
import weblogic.security.SSL.TrustManager;
import weblogic.xml.crypto.wss.provider.CredentialProvider;
import weblogic.xml.crypto.wss.WSSecurityContext;
import weblogic.wsee.security.bst.ClientBSTCredentialProvider;
import weblogic.wsee.security.unt.ClientUNTCredentialProvider;
import javax.xml.ws.BindingProvider;
import java.util.List;
import java.util.Map;
import java.util.ArrayList;
import java.security.cert.X509Certificate;/**
*  Copyright © 1996, 2010, Oracle and/or its affiliates.
*  All rights reserved.
*/
public class SecureHelloWorldJaxwsClient {
public static void main(String[] args) throws Throwable {
//username or password for the UsernameToken
String username = args[0];
String password = args[1];
//client private key file
String keyFile = args[2];
//client certificate
String clientCertFile = args[3];
String wsdl = args[4];
SecureHelloWorldService service = new SecureHelloWorldService_Impl(wsdl + "?WSDL" );
SecureHelloWorldPortType port = service.getSecureHelloWorldServicePort();
//create credential provider and set it to the request context
List credProviders = new ArrayList();
//client side BinarySecurityToken credential provider -- x509
CredentialProvider cp = new ClientBSTCredentialProvider(clientCertFile, keyFile);
credProviders.add(cp);
//client side UsernameToken credential provider
cp = new ClientUNTCredentialProvider(username, password);
credProviders.add(cp);
Map<String, Object> requestContext = ((BindingProvider) port).getRequestContext();
requestContext.put(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders);
requestContext.put(WSSecurityContext.TRUST_MANAGER, new TrustManager() {
public boolean certificateCallback(X509Certificate[] chain,
int validateErr) {
// need to validate if the server cert can be trusted
return true;
}
});
String response = port.sayHello("World");
System.out.println("response = " + response);
}
}

WebLogic Serverインスタンスで実行中のクライアントからのWebサービスの呼出し

「簡易なメッセージ・レベルのセキュリティの構成」で説明した、簡易なWebサービスの構成手順では、スタンドアロンのクライアント・アプリケーションがメッセージ保護されたWebサービスを呼び出すことが前提となっています。ただし、クライアント自体がEJB、サーブレット、または別のWebサービスの一部として、WebLogic Serverインスタンスで実行されている場合もあります。この場合には、WebLogic Serverコア・セキュリティ・フレームワークを使用して資格証明プロバイダと信頼マネージャを構成して、EJB、サーブレット、またはJWSコードには保護された操作の単純な呼出しのみが含まれ、他のセキュリティ関連のAPIの使用は含まれないようにできます。

次の手順は、この使用例でWebLogic Serverコア・セキュリティ・フレームワークを利用するためのステップを大まかに説明したものです。

1. EJB、サーブレットまたはJWSコードで、メッセージ・レベルのセキュリティが構成されていないものとしてWebサービスの操作を呼び出します。具体的には、ユーザー名トークンまたはX.509トークンを格納するCredentialProviderオブジェクトを作成せず、セキュアなWebサービスのホストであるWebLogic Serverの証明書を検証するためのTrustManagerコア・セキュリティAPIも使用しないようにします。クライアント・コードでこれらのAPIを使用しない理由は、Webサービス・ランタイムによってこの作業が実行されるためです。

2. 管理コンソールを使用して、クライアント・アプリケーションをホストするWebLogic Serverインスタンスのコア・セキュリティに必要な資格証明マッピング・プロバイダを構成します。必要な資格証明マッパー・プロバイダのリストは、呼び出すWebサービスにアタッチされるポリシー・ファイルによって異なります。通常は、ユーザー名/パスワードおよびX.509証明書用の資格証明マッパー・プロバイダを構成する必要があります。指定できる値については、「資格証明プロバイダの有効なクラス名とトークン・タイプ」を参照してください。

注意:

WebLogic Serverには、ユーザー名/パスワードおよびX.509用の資格証明マッピング・プロバイダがあります。ただし、デフォルトで構成されているのはユーザー名/パスワードのみです。

3. 管理コンソールを使用して、前の手順で構成した資格証明マッピング・プロバイダに実際の資格証明マッピングを作成します。サーバーで実行されているクライアントに関連付けられたユーザー・プリンシパルを、呼び出すWebサービスに対して有効な資格証明にマップする必要があります。『Oracle WebLogic Serverセキュリティの管理』のWebLogic資格証明マッピング・プロバイダの構成に関する項を参照してください。

4. 管理コンソールを使用して、呼び出されるWebサービスのX.509証明書を信頼するようにWebLogic Serverコア・セキュリティ・フレームワークを構成します。『Oracle WebLogic Serverセキュリティの管理』の証明書検索および検証フレームワークの構成に関する項を参照してください。

「すぐに使用できる」資格証明プロバイダと信頼マネージャをクライアント・アプリケーションで使用しない場合は、この手順で説明したようにWebLogic Serverコア・セキュリティ・フレームワークを構成する必要はありません。「クライアント側のセキュリティ・ポリシー・ファイルの使用」で説明されているスタンドアロンのJavaコードと同じAPIをEJB、サーブレットおよびJWSコードで使用することで、その構成をすべてオーバーライドできます。ただし、コア・セキュリティ・フレームワークを使用することで、WebLogic Serverの構成が標準化され、Webサービスを呼び出すクライアント・アプリケーションのJavaコードが簡略化されます。

JAX-WS Webサービスにセキュリティを追加する例

この項では、JAX-WS Webサービスにセキュリティを追加する単純な例を示します。例の中では、次の4つのポリシーをアタッチしています。

- Wssp1.2-2007-SignBody.xml

- Wssp1.2-2007-EncryptBody.xml

- Wss1.1-UsernameToken-Plain-EncryptedKey-Basic128.xml

- Wssp1.2-Wss1.0-UsernameToken-Plain-X509-Basic128.xml

例のコードには大量のインライン・コメントが含まれています。

例2-4は、Webサービス・コードを示しています。

注意:

このWebサービスはattachToWsdl=falseを実装します。そのため、Webサービス・クライアントは、例2-5に示すように、クライアント側バージョンのポリシーをロードする必要があります。

例2-4 WebサービスSignEncrypt.java

package signencrypt;

import java.io.File;

import weblogic.jws.Policies;
import weblogic.jws.Policy;
import weblogic.jws.security.WssConfiguration;

import javax.activation.DataHandler;
import javax.activation.FileDataSource;
import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.xml.ws.BindingType;
import javax.xml.ws.soap.MTOM;

import com.sun.xml.ws.developer.SchemaValidation;

/**
*
* Webservice which accepts a SOAP Message which is Signed And
*         Encrypted Uses the WS-Policy 1.2
*/

@WebService(name = "SignEncrypt", portName = "SignEncryptPort", serviceName =
"SignEncrypt", targetNamespace = "http://signencrypt")
@BindingType(value = "http://schemas.xmlsoap.org/wsdl/soap/http")
// Domain Level WebserviceSecurity Configuration
@WssConfiguration(value = "Basic-UNT")
@MTOM()
//@SchemaValidation

public class SignEncrypt {

@Policies( {
@Policy(uri = "policy:Wssp1.2-2007-SignBody.xml", attachToWsdl=false),
@Policy(uri = "policy:Wssp1.2-2007-EncryptBody.xml", attachToWsdl=false),
/*
* WSS 1.1 X509 with symmetric binding and authentication with plain-text
* Username Token which is encrypted and signed using the Symmetric key
*/
/* Use Basic-UNT WssConfiguration */
@Policy(uri = "policy:Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey-Basic128.xml",
attachToWsdl=false)
/*
* The client side public certificate and private key is not required in
* this scenario. Username token with plain text password is sent in the
* request for authentication, and signed and encrypted with the symmetric
* key. The symmetric key is encrypted by the server's public key. The client
* also signs and encrypts the request header elements and body with the
* symmetric key. The server signs and encrypts the response body with the
* symmetric key. Both request and response messages include the signed time
* stamps. The encryption method is Basic128.
*/
/* Use untx509webservicesecurity WssConfiguration */

/*
* @Policy(uri =
* "policy:Wssp1.2-Wss1.0-UsernameToken-Plain-X509-Basic128.xml")
*/})
@WebMethod()
public String echoString(String input) {
String result = "[SignEncrypt.echoString]: " + input;
System.out.println(result);
return result;
}

@WebMethod()
public String echoStringWithoutSecurity(String input) {
String result = "[SignEncrypt.echoString]: " + input;
System.out.println(result);
return result;
}

@WebMethod()
public byte[] echoStringAsByteArray(String data) {
System.out.println("echoByteArray data: " + data);
byte[] output = data.getBytes();
System.out.println("Output Length : " + output.length + " Output: " + output.toString());
return data.getBytes();
}

@Policies( {
@Policy(uri = "policy:Wssp1.2-2007-SignBody.xml", attachToWsdl=false),
@Policy(uri = "policy:Wssp1.2-2007-EncryptBody.xml", attachToWsdl=false),
/*
* WSS 1.1 X509 with symmetric binding and authentication with plain-text
* Username Token which is encrypted and signed using the Symmetric key
*/
/* Use Basic-UNT WssConfiguration */
@Policy(uri = "policy:Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey-Basic128.xml",
attachToWsdl=false)
/*
* The client side public certificate and private key is not required in
* this scenario. Username token with plain text password is sent in the
* request for authentication, and signed and encrypted with the symmetric
* key. The symmetric key is encrypted by the server's public key. The client
* also signs and encrypts the request header elements and body with the
* symmetric key. The server signs and encrypts the response body with the
* symmetric key. Both request and response messages include the signed time
* stamps. The encryption method is Basic128.
*/
/* Use untx509webservicesecurity WssConfiguration */

/*
* @Policy(uri =
* "policy:Wssp1.2-Wss1.0-UsernameToken-Plain-X509-Basic128.xml")
*/})
@WebMethod()
public byte[] echoByteArrayWithSecurity(byte[] inputData) {
System.out.println("echoByteArrayWithSecurity data: " + inputData.length + " bytes");
return inputData;
}

@WebMethod()
public byte[] echoByteArray(byte[] inputData) {
System.out.println("echoByteArray data: " + inputData);
return inputData;
}

@WebMethod()
public DataHandler getDataHandler(String fileName) {

DataHandler handler = null;
try {
File file = new File(fileName);
System.out.println("file: " + file.getCanonicalPath() + ", " +  file.getPath());

FileDataSource fileDataSource = new FileDataSource(file);
handler = new DataHandler(fileDataSource);

} catch(Exception e) {
System.out.println("Error Creating Data Handelr:  " + e.getMessage());
}

return handler;

}

@WebMethod()
@Policies( {
@Policy(uri = "policy:Wssp1.2-2007-SignBody.xml", attachToWsdl=false),
@Policy(uri = "policy:Wssp1.2-2007-EncryptBody.xml", attachToWsdl=false),
/*
* WSS 1.1 X509 with symmetric binding and authentication with plain-text
* Username Token which is encrypted and signed using the Symmetric key
*/
/* Use Basic-UNT WssConfiguration */
@Policy(uri = "policy:Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey-Basic128.xml", attachToWsdl=false)
/*
* The client side public certificate and private key is not required in
* this scenario. Username token with plain text password is sent in the
* request for authentication, and signed and encrypted with the symmetric
* key. The symmetric key is encrypted by the server's public key. The client
* also signs and encrypts the request header elements and body with the
* symmetric key. The server signs and encrypts the response body with the
* symmetric key. Both request and response messages include the signed time
* stamps. The encryption method is Basic128.
*/
/* Use untx509webservicesecurity WssConfiguration */
/*
* @Policy(uri =
* "policy:Wssp1.2-Wss1.0-UsernameToken-Plain-X509-Basic128.xml")
*/})
public DataHandler getDataHandlerWithSecurity(String fileName) {

DataHandler handler = null;
try {
File file = new File(fileName);
System.out.println("file: " + file.getCanonicalPath() + ", " +  file.getPath());

FileDataSource fileDataSource = new FileDataSource(file);
handler = new DataHandler(fileDataSource);

} catch(Exception e) {
System.out.println("Error Creating Data Handelr:  " + e.getMessage());
}

return handler;

}

}

前述のとおり、WebサービスでattachToWsdl=falseが実装されるため、Webサービス・クライアントではクライアント側バージョンのポリシーをロードする必要があります。例2-5に、weblogic.jws.jaxws.ClientPolicyFeatureクラスを使用してクライアント側のポリシーをロードする例を示します。

この例には大量のインライン・コメントが含まれています。

例2-5 SOAClient.java

package signencrypt.client;
import weblogic.jws.jaxws.ClientPolicyFeature;
import weblogic.jws.jaxws.policy.InputStreamPolicySource;
import weblogic.security.SSL.TrustManager;
import weblogic.wsee.policy.runtime.BuiltinPolicyFinder;
import weblogic.wsee.security.bst.ClientBSTCredentialProvider;
import weblogic.wsee.security.bst.StubPropertyBSTCredProv;
import weblogic.wsee.security.unt.ClientUNTCredentialProvider;
import weblogic.wsee.security.util.CertUtils;
import weblogic.xml.crypto.wss.WSSecurityContext;
import weblogic.xml.crypto.wss.provider.CredentialProvider;

import soa.client.Bpelprocess1ClientEp;
import soa.client.BPELProcess1;

import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.InputStream;
import java.io.OutputStream;
import java.net.URL;
import java.security.cert.X509Certificate;
import java.util.ArrayList;
import java.util.List;
import java.util.Map;

import javax.activation.DataHandler;
import javax.activation.FileDataSource;
import javax.xml.namespace.QName;
import javax.xml.ws.BindingProvider;
import javax.xml.ws.WebServiceFeature;
import javax.xml.ws.soap.MTOMFeature;

public class SOAClient {

private final static boolean debug = true;

private final static String endpointURL =
"http://....com:8001/soa-infra/services/default/soa/bpelprocess1_client_ep";
private final static String certsDir = "C:/webservices/server/keystores";

private final static String serverKeyStoreName = "default-keystore.jks";
private final static String serverKeyStorePass = "...";
private final static String serverCertAlias = "alice";
private final static String serverKeyPass = "...";

private final static String username = "weblogic";
private final static String password = "...";

private final static String fileName =
"C:/webservices/farallon/owsm-interop/mtom.JPG";

private final static String outputFileName =
"C:/webservices/farallon/owsm-interop/output.jpg";

private final static String[] clientPolicyFileNames =
{
"./policy/Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey-Basic128.xml",
"./policy/Wssp1.2-2007-SignBody.xml",
"./policy/Wssp1.2-2007-EncryptBody.xml" };

private BPELProcess1 port = null;

/**
* Create the Stub/Port and set the Stub/Port with Client Side Security Policy
* Feature and MTOM Feature.
* @throws Exception
*/

private void createStubWithClientPolicy() throws Exception {

URL url = new URL(endpointURL + "?WSDL");

QName serviceName =
new QName("http://xmlns.oracle.com/SOASecurity/soa/BPELProcess1",
"bpelprocess1_client_ep");

Bpelprocess1ClientEp service = new Bpelprocess1ClientEp(url, serviceName);

QName operationName =
new QName("http://xmlns.oracle.com/SOASecurity/soa/BPELProcess1", "process");

ClientPolicyFeature policyFeature = new ClientPolicyFeature();

// Set the Client Side Policy on the operation with QName <operationName>

policyFeature.setEffectivePolicyForOperation(operationName, new
InputStreamPolicySource(getPolicyInputStreamArray(clientPolicyFileNames)
));
MTOMFeature mtomFeature = new MTOMFeature();

WebServiceFeature[] features = { policyFeature, mtomFeature };
// WebServiceFeature[] features = { mtomFeature };
//WebServiceFeature[] features = {policyFeature};

port = service.getBPELProcess1Pt(features);
}

/**
* Setup the Client Port/Stub used to invoke the webservice with Security
*
* @throws Exception
*/
private void setUp() throws Exception {
createStubWithClientPolicy();
/**
* Get the Server Public Certificate to Encrypt the Symmetric Key or the
* SOAP Message
*/
/**
* Get the Server Public Certificate to Verify the Signature of the
* Symmetric Key or the SOAP Message
*/
X509Certificate serverCert =
(X509Certificate) CertUtils.getCertificate(
certsDir + "/" + serverKeyStoreName, serverKeyStorePass,
serverCertAlias, "JKS").get(0);
List<CredentialProvider> credProviders =
new ArrayList<CredentialProvider>();
/*
* Set up UserNameToken
*/
credProviders.add(new ClientUNTCredentialProvider(username.getBytes(),
password.getBytes()));
Map<String, Object> rc = ((BindingProvider) port).getRequestContext();
/*
* For Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey-Basic128.xml
* there is no need to specify the client side public certificate and
* private key as this is a symmetric key use case. serverCert is used to
* encrypt the Symmetric Key/Keys
*/
rc.put(StubPropertyBSTCredProv.SERVER_ENCRYPT_CERT, serverCert);
rc.put(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders);
rc.put(WSSecurityContext.TRUST_MANAGER, new TrustManager() {
public boolean certificateCallback(X509Certificate[] chain,
int validateErr) {
// need to validate if the server cert can be trusted
System.out.println("Validating Server Certificate");
return true;
}
});

}
/**
* Returns an array of InputStreams of the policy files
*
* @param policyNames
* @return array of InputStreams of Policy's
* @throws FileNotFoundException
*/
private InputStream[] getPolicyInputStreamArray(String[] policyNames)
throws FileNotFoundException {
InputStream[] inpStreams = new InputStream[policyNames.length];
for (int k = 0; k < policyNames.length; k++) {
System.out.println("policy name: " + policyNames[k]);
inpStreams[k] = getPolicyInputStream(policyNames[k]);
}
return inpStreams;
}
/**
* Returns an InputStream of the policy file
*
* @param myPolicyName
* @return
* @throws FileNotFoundException
*/
private InputStream getPolicyInputStream(String myPolicyName)
throws FileNotFoundException {
return new FileInputStream(myPolicyName);
}
/**
* Invoke the webservice at endpointURL
*
(http://....:9003/soa-infra/services/default/soa/bpelprocess1_client_ep)
*
* @throws Exception
*/
private void invokeProcess() throws Exception {
InputStream inputstream = null;
OutputStream outputstream = null;
try {

File file = new File(fileName);
File outputFile = new File(outputFileName);

inputstream = new BufferedInputStream(new FileInputStream(file));
int bytesAvailable = -1;
int counter = 0;
int bytesRead = 0;
int fileSize = (int) file.length();

byte[] fileInBytes = new byte[fileSize];

bytesRead = inputstream.read(fileInBytes);
System.out.println("bytesRead: " + bytesRead + ", fileSize: " + fileSize + "
fileInBytes: " + fileInBytes.length);

byte[] result = port.process(fileInBytes);
/*byte[] input = "Hello".getBytes();
System.out.println("input length : "+ input.length);

byte[] result = port.process(input);*/
if (!outputFile.exists()) {
outputFile.createNewFile();
}

outputstream = new BufferedOutputStream(new FileOutputStream(outputFile));

if (result != null) {
System.out.println("Result Length: " + result.length);
} else {
System.out.println("result is null");
}
outputstream.write(result);

// System.out.println(result);
} catch (Exception e) {
System.out.println("Error Creating Data Handler:  " + e.getMessage());
} finally {

if (inputstream != null) {
inputstream.close();
}

if (outputstream != null) {
outputstream.close();
}
}
}
public static void main(String[] args) {
try {
SOAClient client = new SOAClient();
client.setUp();
//client.createStubWithClientPolicy();
client.invokeProcess();
} catch (Exception e) {
System.out.println("Error calling SOA Webservice: " + e.getMessage());
if (debug) {
e.printStackTrace();
}
}
}
}

カスタム・ポリシー・ファイルの作成と使用

WebLogic Serverには、ほとんどのプログラマの通常のセキュリティ・ニーズを満たすため、事前定義済のWebサービス・セキュリティ・ポリシー・ファイルがいくつか用意されていますが、追加の構成が必要な場合は、独自のWS-SecurityPolicyファイルを作成して使用することもできます。セキュリティ・ポリシー・ファイルについての全般的な情報、およびメッセージ・レベルのセキュリティ構成でセキュリティ・ポリシー・ファイルを使用する方法については、「メッセージ・レベルのセキュリティ構成でのポリシー・ファイルの使用」を参照してください。

注意:

要素レベルのセキュリティを使用する場合は常に、1つ以上のカスタム・ポリシー・ファイルで、保護の対象となる特定の要素のパスと名前を指定する必要があります。

カスタム・ポリシー・ファイルを作成する場合には、事前定義済のファイルと同じように、3つの主なセキュリティ・カテゴリ(認証、暗号化および署名)を3つの別々のポリシー・ファイルに分割するか、3つのカテゴリすべてを含む1つのポリシー・ファイルを作成することができます。1つのカテゴリ(認証など)のみを変更したカスタム・ポリシー・ファイルを作成し、他のカテゴリについては事前定義済のファイル(Wssp1.2-2007-SignBody.xml、Wssp1.2-SignBody.xmlおよびWssp1.2-2007-EncryptBody、Wssp1.2-EncryptBody)を使用することもできます。つまり、Webサービスに関連付けるポリシー・ファイルの数および内容は、適宜組み合せることができます。ただしこの場合は、組み合せた複数のファイルが互いに矛盾していないことを常に確認する必要があります。

カスタム・ポリシー・ファイルは、WS-SecurityPolicy1.2で定義された標準の形式とアサーションに準拠している必要があります。ただし、このリリースのWebLogic ServerはWS-SecurityPolicy 1.2を完全に実装していませんので注意してください。詳細は、「サポートされないWS-SecurityPolicy 1.2アサーション」を参照してください。WS-SecurityPolicyファイルのルート要素は<Policy>とする必要があります。

このリリースでは、次のネームスペース宣言を使用してください。

<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
>
. . .
</wsp:Policy>

WLSは、セキュリティ・ポリシーの他のネームスペースもサポートしています。たとえば、次の2つのネームスペースもサポートされます。

<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512"
>
. . .
</wsp:Policy>

または

<wsp:Policy
xmlns:wsp="http://www.w3.org/ns/ws-policy"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
>
. . .
</wsp:Policy>

事前定義済のWS-SecurityPolicyファイルをテンプレートとして使用して、自分のカスタム・ファイルを作成することもできます。

WS-Trustクライアントの構成

WebLogic Serverでは、Webサービス・セキュリティで使用するためにセキュリティ・トークン・サービス(STS)からセキュリティ・トークンを取得するWS-Trustクライアントを実装しています。WS-Trustクライアントはクライアント側のWebLogic Server Webサービス・ランタイムによって内部的に使用されます。

WS-Trustクライアントは次のようにして構成できます:

- スタンドアロンのWebサービス・クライアントの場合は、Webサービス・クライアント・スタブのプロパティを通じて。

- サーバー上で実行されるWebサービス・クライアントの場合は、MBeanプロパティを通じて。

WebLogic Serverの10gリリース3 (10.3)より前のリリースでは、WS-Trustクライアントは、Webサービスと共存しており、かつWebLogic ServerにホストされているSTSのセキュリティ・トークンしか使用できませんでした。しかし、現在STSに求められるのはWS-Trustクライアントからアクセスできることのみで、共存の必要はなくなりました。

旧リリースのWS-Trustクライアントは、WS-SecureConversationトークンのみをサポートしていました。現在はSAMLトークンもサポートしています。

サポートされるトークン・タイプ

Web Service Secure Conversation Language (WS-SecureConversation)とSAMLのトークンがサポートされます。各トークンには次のネームスペースとURIがあります。

- WS-SecureConversation 1.3

http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512
http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/sct

- WS-SecureConversation 1.2

http://schemas.xmlsoap.org/ws/2005/02/sc
http://schemas.xmlsoap.org/ws/2005/02/sc/sct

- SAML 1.1

urn:oasis:names:tc:SAML:1.0:assertion

サポートされる確認メソッドは、Sender-Vouches、Holder-of-KeyおよびBearerです。対称型のHolder-of-Keyはサポートされません。

- SAML 2.0

urn:oasis:names:tc:SAML:2.0:assertion

サポートされる確認メソッドは、Sender-Vouches、Holder-of-KeyおよびBearerです。対称型のHolder-of-Keyはサポートされません。

WS-Trustクライアント・プロパティの構成

WS-Trustクライアントに固有の一部の構成プロパティを設定します。それ以外のプロパティについては、Webサービス・クライアントに通常存在する構成情報によって決定されます。たとえば、取得するトークンのタイプは、Webサービス・クライアントが呼び出しているWebサービスのセキュリティ・ポリシーによって決定されます。

明示的に設定できるプロパティと適用されるトークン・タイプは次のとおりです。

- STS URI (WS-SecureConversationおよびSAML)

- STSセキュリティ・ポリシー(SAML)

- STS SOAPバージョン(SAML)

- STS WS-Trustバージョン(SAML)

- STSサーバー証明書(SAML)

この項では、次のトピックについて説明します。

- 「セキュア・トークン・サービスのURIの取得」

- 「WS-SecureConversation用のSTS URIの構成: スタンドアロン・クライアント」

- 「SAML用のSTS URIの構成: スタンドアロン・クライアント」

- 「WLSTを使用したSTS URIの構成: サーバー側のクライアント」

- 「コンソールを使用したSTS URIの構成: サーバー側のクライアント」

- 「STSセキュリティ・ポリシーの構成: スタンドアロン・クライアント」

- 「WLSTを使用したSTSセキュリティ・ポリシーの構成: サーバー側のクライアント」

- 「コンソールを使用したSTSセキュリティ・ポリシーの構成」

- 「STS SOAPおよびWS-Trustバージョンの構成: スタンドアロン・クライアント」

- 「SAML STSサーバー証明書の構成: スタンドアロン・クライアント」

セキュア・トークン・サービスのURIの取得

WS-Trustクライアントがセキュア・トークン・サービス(STS)のURIを取得できるソースは3つあります。優先順位は次のとおりです。

- Webサービスのセキュリティ・ポリシーにおけるトークン・アサーションのsp:Issuer/wsa:Address要素で指定されたSTSのURI。

- 構成済のSTSのURI。

- 同じ場所にあるSTSのURI。他のソースがない場合はこれがデフォルトです(WS-SecureConversationのみ)。

注意:

Webサービスのセキュリティ・ポリシーにおけるトークン・アサーションのsp:IssuedToken/sp:Issuer/wsa:Address要素で指定されたSTSのURIは、このリリースでは、SAMLトークンを取得する目的でのみサポートされます。Secure Conversationトークンを取得する目的ではサポートされません。

たとえば、STS URIに対する次のアサーションは、Secure Conversationトークン(SCT)を取得する目的ではサポートされません。

<sp:IssuedToken
IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<sp:Issuer>
<a:Address>http://example.com/STS</a:Address>
</sp:Issuer>
. . .
</sp:IssuedToken>

WS-SecureConversation用のSTS URIの構成: スタンドアロン・クライアント

WS-SecureConversationの場合、STSがサービスと共存していれば、STS URIの構成は不要です。ただし、STSとサービスが同じポートを共有しないときは(サービスがHTTPポートを使用し、STSがHTTPsポートを使用する場合など)、STS URIを構成する必要があります。

次のコード例は、JAX-RPCでクライアント・スタブにSTS URIを設定する方法を示しています。この例では、STS URIの場所をクライアントがすでに認識していることを前提としています。

String wsdl = "http://myserver/wsscsecuredservice?wsdl";
WsscSecuredService service = new WsscSecuredService_Impl(wsdl);
WsscSecured port = service.getWsscSecuredSoapPort();
Stub stub = (Stub) port;
String sts = "https://myserver/wsscsecuredservice";
stub._setProperty(weblogic.wsee.jaxrpc.WLStub.WST_STS_ENDPOINT_ON_WSSC, sts);

次のコード例は、JAX-WSでクライアント・スタブにSTS URIを設定する方法を示しています。

String wsdl = "http://myserver/wsscsecuredservice?wsdl";
WsscSecuredService service = new WsscSecuredService_Impl(wsdl);
String sts = "https://myserver/wsscsecuredservice";
WsscSecured port = service.getWsscSecuredSoapPort();
BindingProvider provider = (BindingProvider) port;
Map context = provider.getRequestContext();
context.put(weblogic.wsee.jaxrpc.WLStub.WST_STS_ENDPOINT_ON_WSSC, sts)

SAML用のSTS URIの構成: スタンドアロン・クライアント

STSを使用してSAMLトークンを取得する場合、STSはサービスと共存しておらず、デフォルトのSTS URIはありません。この場合は、STS URIを構成する必要があります。

次のコード例は、JAX-RPCでクライアント・スタブにSAML用のSTS URIを設定する方法を示しています。この例では、STS URIの場所をクライアントがすでに認識していることを前提としています。

String wsdl = "http://myserver/wssecuredservice?wsdl";
WssecuredService service = new  WsSecuredService_Impl(wsdl);
WsSecured port = service.getWsSecuredSoapPort();
Stub stub = (Stub) port;
String sts = "https://stsserver/standaloneSTS/saml/STS";
stub._setProperty(weblogic.wsee.jaxrpc.WLStub.WST_STS_ENDPOINT_ON_SAML, sts);

次のコード例は、JAX-WSでクライアント・スタブにSAML用のSTS URIを設定する方法を示しています。

String wsdl = "http://myserver/wsssecuredservice?wsdl";
WsSecuredService service = new WsSecuredService_Impl(wsdl);
String sts = "https://stsserver/standaloneSTS/saml/STS";
WsscSecured port = service.getWsSecuredSoapPort();
BindingProvider provider = (BindingProvider) port;
Map context = provider.getRequestContext();
context.put(weblogic.wsee.jaxrpc.WLStub.WST_STS_ENDPOINT_ON_SAML, sts)

WLSTを使用したSTS URIの構成: サーバー側のクライアント

例2-6では、WebLogic Scripting Tool (WLST)を使用してWS-Trustクライアントの資格証明プロバイダを作成し、STS URIを構成する方法を太字で示しています。

プロバイダ・クラス名は次のいずれかです。

- weblogic.wsee.security.wssc.v200502.sct.ClientSCCredentialProvider

- weblogic.wsee.security.wssc.v13.sct.ClientSCCredentialProvider

- weblogic.wsee.security.saml.SAMLTrustCredentialProvider

例2-6 WLSTを使用したSTS URIの構成

userName = sys.argv[1]
passWord = sys.argv[2]
host = sys.argv[3]+":"+sys.argv[4]
sslhost = sys.argv[3]+":"+sys.argv[5]
url="t3://"+ host connect(userName, passWord, url)
edit()
startEdit()
defaultWss = cmo.lookupWebserviceSecurity('default_wss')
#Create credential provider for SCT Trust Client
wtm = defaultWss.createWebserviceCredentialProvider('trust_client_sct_cp')
wtm.setClassName('weblogic.wsee.security.wssc.v13.sct.ClientSCCredentialProvider')

wtm.setTokenType('sct_trust')
cpm = wtm.createConfigurationProperty('StsUri')
cpm.setValue("https://" + sslhost + "/standaloneSTS/wssc13/STS")
save()
activate(block="true")
disconnect()
exit()

コンソールを使用したSTS URIの構成: サーバー側のクライアント

WebLogic Server管理コンソールからSTS URIを構成すると、使用するURIをWebLogicサービスの開発段階ではなく実行時に決定できます。

管理コンソールからSTS URIを構成するには、次の手順に従います。

1. Oracle WebLogic Server管理コンソール・オンライン・ヘルプの説明に従って、Webサービスのセキュリティ構成を作成します。空の構成が作成されます。

2. Oracle WebLogic Server管理コンソール・オンライン・ヘルプの説明に従って、Webサービスのセキュリティ構成を編集し、資格証明プロバイダを作成します。

- 「資格証明プロバイダの作成」タブで、以下のように入力します。

- プロバイダ名(このMBeanインスタンスの名前)。

- プロバイダ・クラス名(次のいずれか)

weblogic.wsee.security.wssc.v200502.sct.ClientSCCredentialProvider

または

weblogic.wsee.security.wssc.v13.sct.ClientSCCredentialProvider

または

weblogic.wsee.security.saml.SAMLTrustCredentialProvider

- トークン・タイプ(トークンを識別する短い名前)。sctやsamlなどです。

3. 「次へ」を選択します。

4. STS URIの名前と値のペアを入力します。

5. 「終了」を選択します。

6. 「セキュリティ構成: 全般」タブで、「デフォルト資格証明プロバイダSTS URI」の値を設定します。
デフォルト資格証明プロバイダSTS URLは、このWebサービス・セキュリティ構成のすべてのWS-Trust対応資格証明プロバイダにおける、デフォルトのSTSエンドポイントURLです。

STSセキュリティ・ポリシーの構成: スタンドアロン・クライアント

次のコード例では、JAX-RPCでクライアント・スタブにSTSセキュリティ・ポリシーを設定する方法を太字で示しています。

import weblogic.wsee.message.WlMessageContext;
. . .
String wsdl = "http://myserver/samlsecuredservice?wsdl";
SamlSecuredService service = new SamlSecuredService_Impl(wsdl);
SamlSecured port = service.getSamlSecuredSoapPort();
Stub stub = (Stub) port;
InputStream policy = loadPolicy();
stub._setProperty(WlMessageContext.WST_BOOT_STRAP_POLICY, policy);

次のコード例では、JAX-WSでクライアント・スタブにSTSセキュリティ・ポリシーを設定する方法を太字で示しています。

import weblogic.wsee.message.WlMessageContext;
. . .
String wsdl = "http://myserver/wsssecuredservice?wsdl";
WsSecuredService service = new WsSecuredService_Impl(wsdl);
WsscSecured port = service.getWsSecuredSoapPort();
BindingProvider provider = (BindingProvider) port;
Map context = provider.getRequestContext();
InputStream policy = loadPolicy();
context._setProperty(WlMessageContext.WST_BOOT_STRAP_POLICY, policy);

WLSTを使用したSTSセキュリティ・ポリシーの構成: サーバー側のクライアント

例2-7では、WLSTを使用してデフォルトのWebサービス・セキュリティ構成の資格証明プロバイダを作成し、STSセキュリティ・ポリシーを構成する方法を太字で示しています。StsPolicyのプロパティの値は、WebLogic Serverに含まれるポリシー(「WS-SecurityPolicy 1.2ポリシー・ファイルの使用」を参照)、またはJava EEライブラリのカスタム・ポリシー・ファイル(「カスタム・ポリシー・ファイルの作成と使用」を参照)のどちらかである必要があります。

例2-7 WLSTを使用したSTSセキュリティ・ポリシーの構成

userName = sys.argv[1]
passWord = sys.argv[2]
host = sys.argv[3]+":"+sys.argv[4]
sslhost = sys.argv[3]+":"+sys.argv[5]
samlstsurl = sys.argv[6]
url="t3://"+ host
print "Connect to the running adminSever"
connect(userName, passWord, url)
edit()
startEdit()
defaultWss = cmo.lookupWebserviceSecurity('default_wss')

#Create credential provider for SAML Trust Client

wtm = defaultWss.createWebserviceCredentialProvider('trust_client_saml_cp')
wtm.setClassName('weblogic.wsee.security.saml.SAMLTrustCredentialProvider')
wtm.setTokenType('saml_trust')
cpm = wtm.createConfigurationProperty('StsUri')
cpm.setValue(samlstsurl)
cpm = wtm.createConfigurationProperty('StsPolicy')
cpm.setValue("Wssp1.2-2007-Https-UsernameToken-Plain")
save()
activate(block="true")
disconnect()
exit()

コンソールを使用したSTSセキュリティ・ポリシーの構成

コンソールを使用してSTSセキュリティ・ポリシーを構成するには、次の手順に従います。

1. Oracle WebLogic Server管理コンソール・オンライン・ヘルプの説明に従って、Webサービスのセキュリティ構成を作成します。空の構成が作成されます。

2. Oracle WebLogic Server管理コンソール・オンライン・ヘルプの説明に従って、Webサービスのセキュリティ構成を編集し、資格証明プロバイダを作成します。

- 「資格証明プロバイダの作成」タブで、以下のように入力します。

- プロバイダ名(このMBeanインスタンスの名前)。

- プロバイダ・クラス名(次のいずれか)

weblogic.wsee.security.wssc.v200502.sct.ClientSCCredentialProvider

または

weblogic.wsee.security.wssc.v13.sct.ClientSCCredentialProvider

または

weblogic.wsee.security.saml.SAMLTrustCredentialProvider

- トークン・タイプ(トークンを識別する短い名前)。sctやsamlなどです。

3. 「次へ」を選択します。

4. STSポリシーの名前と値のペアを入力します。

5. 「終了」を選択します。

STS SOAPおよびWS-Trustのバージョンの構成: スタンドアロン・クライアント

SAML STSでは、デフォルト(WS-Trust 1.3)でない場合にのみ、WS-Trustのバージョンを構成する必要があります。WSEESecurityConstants.TRUST_VERSIONでサポートされる値は次のとおりです。

- http://docs.oasis-open.org/ws-sx/ws-trust/200512 (WS-Trust 1.3)

- http://schemas.xmlsoap.org/ws/2005/02/trust

SOAPバージョンが、スタンドアロン・クライアントを生成したターゲットWebサービスのSOAPバージョンと異なる場合は、SOAPバージョンも構成する必要があります。(定数の定義については、インタフェースSOAPConstants(http://docs.oracle.com/javase/7/docs/api/javax/xml/soap/SOAPConstants.html)を参照してください。)WSEESecurityConstants.TRUST_SOAP_VERSIONでサポートされる値は次のとおりです。

- javax.xml.soap.SOAPConstants.URI_NS_SOAP_1_1_ENVELOPE (http://schemas.xmlsoap.org/soap/envelope/による)

- javax.xml.soap.SOAPConstants.URI_NS_SOAP_1_2_ENVELOPE (http://www.w3.org/2003/05/soap-envelopeによる)

例2-8は、WS-TrustとSOAPのバージョンを設定する例を示しています。

例2-8 WS-TrustおよびSOAPバージョンの設定

// set WS-Trust version
stub._setProperty(WSEESecurityConstants.TRUST_VERSION, "http://docs.oasis-open.org/ws-sx/ws-trust/200512");
// set SOAP version
stub._setProperty(WSEESecurityConstants.TRUST_SOAP_VERSION, SOAPConstants.URI_NS_SOAP_1_1_ENVELOPE);

SAML STSサーバー証明書の構成: スタンドアロン・クライアント

SAML STSの場合、メッセージ・レベルのポリシーを使用してSTSサーバーとWS-Trustクライアントの間のリクエストおよびレスポンスを保護するには、STSサーバーのX.509証明書を構成する必要があります。(トランスポート・レベルのポリシーを使用する場合は、STSサーバー証明書の構成は不要です。)

例2-9は、JAX-RPCでSTSサーバー証明書を設定する方法の例を示しています。この例では、STSサーバー証明書の場所がわかっていることを前提としています。

例2-9 JAX-RPCによるSTSサーバー証明書の設定

// import
import weblogic.wsee.security.util.CertUtils;
import java.security.cert.X509Certificate;
import weblogic.wsee.jaxrpc.WLStub;
. . .

// get X509 Certificate
String stsCertLocation = "../../cert/WssIP.cer";
X509Certificate stsCert = CertUtils.getCertificate(stsCertLocation);
// set STS Server Cert
stub._setProperty(WLStub.STS_ENCRYPT_CERT,stsCert);

例2-10は、JAX-WSでSTSサーバー証明書を設定する方法の例を示しています。この例の中で、JAX-WS固有のコードは太字で表されています。

例2-10 JAX-WSによるSTSサーバー証明書の設定

// import
import weblogic.wsee.security.util.CertUtils;
import java.security.cert.X509Certificate;
import weblogic.wsee.jaxrpc.WLStub;
. . .

// get X509 Certificate
String stsCertLocation = "../../cert/WssIP.cer";
X509Certificate stsCert = CertUtils.getCertificate(stsCertLocation);
// set STS Server Cert
context.put(WLStub.STS_ENCRYPT_CERT,stsCert);

HTTPSを介するSAML 2.0 BearerトークンのサンプルWS-Trustクライアント

WS-Trustを使用してSAML 2.0 BearerトークンをSTSから取得し、そのSAMLトークンをセキュアな会話でのブートストラップ・メッセージに対する認証に使用するよう、クライアント・アプリケーションを構成できます。

このシナリオでは、クライアントとSAML STSの間のWS-Trustメッセージ交換、およびセキュアな会話でのブートストラップ・メッセージには、トランスポート・レベルのメッセージ保護が使用されます。このスタンドアロン・クライアントには公開鍵と秘密鍵は不要です。

サービス側のポリシーは、事前定義済のWS-PolicyファイルWssp1.2-2007-Wssc1.3-Bootstrap-Https-UNT.xmlとほぼ同じです。ただし、次の<sp:SupportingTokens>がポリシーで使用されています。

<sp:SupportingTokens>
<wsp:Policy>
<sp:SamlToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssSamlV20Token11/>
</wsp:Policy>
</sp:SamlToken>
</wsp:Policy>
</sp:SupportingTokens>

WS-TrustクライアントとリモートSTSサーバーの間のWS-Trustメッセージの保護に使用されるポリシーは、パッケージ化されたセキュリティ・ポリシー・ファイルWssp1.2-2007-Https-UsernameToken-Plain.xmlのコピーです。このファイルでは、トランスポート・レベルのメッセージ保護における認証にユーザー名トークンが使用されます。

注意:

トランスポート・レベルのセキュリティ・ポリシーを使用してセキュアな会話のブートストラップ・メッセージを保護する場合、WS-TrustクライアントとリモートSTSの間で交換されるWS-Trustメッセージもトランスポート・レベルのセキュリティ・ポリシーを使用して保護する必要があります。

Webサービスをクライアントから呼び出すとき、そのサービスはメッセージ保護されたWebサービスを呼び出す標準的なクライアント・アプリケーションに似ています(「クライアント側のセキュリティ・ポリシー・ファイルの使用」を参照)。主な違いは、2つのSTSエンドポイントを構成する必要がある点です。1つは取得したSAMLトークンに使用され、もう1つは安全な通信のためのセキュリティ・コンテキスト・トークン(SCT)に使用されます。

例2-11は、クライアント・アプリケーションから、WS-Trust経由でSAMLトークンを取得するJAX-WSのWebサービスを呼び出す、単純な例を示しています。それは、HTTPSによるトランスポート・レベルの保護を使用してセキュアな会話を可能にするセキュリティ・ポリシーに関連付けられています。セキュリティ・コンテキストに関連する太字のセクションについては、例の後で説明します。

例2-11 WS-TrustとWS-SecureConversationをHTTPSとともに使用するクライアント・アプリケーション

package examples.webservices.samlwsschttps.client;

import weblogic.security.SSL.TrustManager;
import weblogic.wsee.message.WlMessageContext;
import weblogic.wsee.security.bst.ClientBSTCredentialProvider;
import weblogic.wsee.security.saml.SAMLTrustCredentialProvider;
import weblogic.wsee.security.unt.ClientUNTCredentialProvider;
import weblogic.xml.crypto.wss.WSSecurityContext;
import weblogic.xml.crypto.wss.provider.CredentialProvider;
import weblogic.wsee.jaxrpc.WLStub;
import weblogic.wsee.security.util.CertUtils;
import com.sun.xml.ws.developer.MemberSubmissionAddressingFeature;
import java.security.cert.X509Certificate;
import javax.xml.ws.*;
import javax.xml.namespace.*;
import javax.net.ssl.HttpsURLConnection;
import java.net.URL;
import java.io.File;
import java.io.IOException;
import java.io.InputStream;
import java.util.ArrayList;
import java.util.List;
import java.util.Map;

public class TravelAgencyClient {

public static final String STS_POLICY = "StsHttpsUntPolicy.xml";
static {
HttpsURLConnection.setDefaultHostnameVerifier(new MyHostnameVerifier());
try {
String defaultTrustStore = new File(TravelAgencyClient.class.getResource("/cacerts").getFile()).getCanonicalPath();
System.out.println("Default trustStore:\t" + defaultTrustStore);
System.setProperty("javax.net.ssl.trustStore", defaultTrustStore);
} catch (IOException e) {
System.out.printf("can't find default trusted keystore");
}
}

public static void main(String[] args) throws Exception {
TravelAgencyClient client  = new TravelAgencyClient();
String wsscStsURL = System.getProperty("wsscStsURL");
System.out.println("WSSC StS URL \t" + wsscStsURL);
String samlStsURL = System.getProperty("samlStsURL");
System.out.println("StS URL \t" + samlStsURL);
String hotelWsdlURL = System.getProperty("hotelWsdlURL");
System.out.println("Hotel Service WSDL URL \t" + hotelWsdlURL);

String hotelResult = client.callWsscHotelService("Travel Agency client to Hotel Service", wsscStsURL,hotelWsdlURL, samlStsURL);
System.out.println("Hotel Service return value: -->"+hotelResult);
}

public String callWsscHotelService(String hello,
String wsscStsURL,
String hotelWsdlURL,
String samlStsURL) throws Exception{

HotelService service = new HotelService(new URL(hotelWsdlURL),
new QName("http://wsinterop.org/samples", "HotelService"));

IHotelService port = service.getIHotelServicePort(new MemberSubmissionAddressingFeature());

BindingProvider provider = (BindingProvider)port;
this.configurePort(provider, wsscStsURL, samlStsURL);

try {
// for securie conversation, it can call twice
String s1 = port.getName(hello);
String s2 = port.getName(hello + " --- " + s1) ;
WSSCClientUtil.terminateWssc((BindingProvider)port);
return s2;
} catch (Exception ex) {
ex.printStackTrace();
throw new RuntimeException("fail to call the remote hotel service!", ex);
}
}

private void configurePort(BindingProvider provider, String wsscStsURL, String samlStsURL) throws Exception {

Map context = provider.getRequestContext();
InputStream policy = getPolicy(STS_POLICY);
context.put(WlMessageContext.WST_BOOT_STRAP_POLICY, policy);
if (null != wsscStsURL) {
context.put(WLStub.WST_STS_ENDPOINT_ON_WSSC, wsscStsURL);
}
context.put(WLStub.WST_STS_ENDPOINT_ON_SAML, samlStsURL);
context.put(WSSecurityContext.TRUST_MANAGER,
new TrustManager() {
public boolean certificateCallback(X509Certificate[] chain,
int validateErr) {
// need to validate if the server cert can be trusted
return true;
}
});
List credProviders = buildCredentialProviderList();
context.put(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders);

context.put(com.sun.xml.ws.developer.JAXWSProperties.HOSTNAME_VERIFIER, new MyHostnameVerifier());
}

private static List buildCredentialProviderList() throws Exception  {
List credProviders = new ArrayList();
credProviders.add(new SAMLTrustCredentialProvider());
credProviders.add(getClientUNTCredentialProvider());
return credProviders;
}
private static CredentialProvider getClientUNTCredentialProvider() throws Exception {
String username = System.getProperty("target.username", "Alice");
String password = System.getProperty("target.password", "Password1");
return new ClientUNTCredentialProvider(username.getBytes(),
password.getBytes());
}
private  InputStream getPolicy(String policyName) {
String resName = '/' + this.getClass().getPackage().getName().replace('.', '/') + '/' + policyName;
InputStream  stsPolicy = this.getClass().getResourceAsStream(resName);
if(stsPolicy == null)    {
throw new RuntimeException("STS policy is not correctly set!");
}
return stsPolicy;
}
public static class MyHostnameVerifier implements javax.net.ssl.HostnameVerifier {
public boolean verify(String hostname, javax.net.ssl.SSLSession session) {
return(true);
}
}
}

この例では、次の点に注意してください。

- リモートSTSとWS-Trustクライアントとの間のメッセージ保護のポリシーを構成します。
context.put(WlMessageContext.WST_BOOT_STRAP_POLICY, policy);

- ブートストラップはトランスポート・レベルのポリシーで保護されるため、セキュアな会話のためのSTSエンドポイント・アドレスを設定する必要があります。
context.put(WLStub.WST_STS_ENDPOINT_ON_WSSC, wsscStsURL);

- SAML STSのSTSエンドポイント・アドレスを設定します。
context.put(WLStub.WST_STS_ENDPOINT_ON_SAML, samlStsURL);

- トランスポート・レベルの保護のために、ホスト名検証を構成する必要があります。
context.put(com.sun.xml.ws.developer.JAXWSProperties.HOSTNAME_VERIFIER, new MyHostnameVerifier());

- SAMLトークンのリモート取得を処理するようにSAML信頼資格証明プロバイダを設定します。
credProviders.add(new SAMLTrustCredentialProvider());

- クライアントのユーザー名とパスワードを使用してWS-Trust呼出し経由でSAMLトークンを交換するように、クライアント・ユーザー名トークン・プロバイダを設定します。
credProviders.add(getClientUNTCredentialProvider());

WSS 1.1メッセージ保護でSAML 2.0 Bearerトークンを使用するサンプルWS-Trustクライアント

例2-11と同様に、WS-Trustを使用してSAML 2.0 BearerトークンをSTSから取得し、そのSAMLトークンをセキュアな会話でのブートストラップ・メッセージに対する認証に使用するよう、クライアント・アプリケーションを構成できます。ただし、HTTPSによるトランスポート・レベルのメッセージ保護ではなく、WS-Security 1.1によるメッセージ・レベルの保護を使用するため、HTTPSの構成は不要です。

このシナリオでは、クライアントとSAML STSの間のWS-Trustメッセージ交換の保護にはSTSサーバーのX.509証明書が使用され、セキュアな会話でのブートストラップ・メッセージの保護にはサーバーのX.509証明書が使用されます。このスタンドアロン・クライアントには公開鍵と秘密鍵は不要です。

サービス側のポリシーは、パッケージ化されたWS-PolicyファイルWssp1.2-2007-Wssc1.3-Bootstrap-Wss1.1.xmlに類似しています。ただし、Bootstrapメッセージにおける認証で、クライアントのX.509証明書のかわりにSAML 2.0トークンを使用する点が異なります。つまり、<sp:SignedEndorsingSupportingTokens>アサーションではなく、ポリシー内で<sp:SignedSupportingTokens>アサーションをSAMLトークンと共に使用します。

セキュアな会話のポリシー全体を次に示します。

<?xml version="1.0"?>
<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<sp:SymmetricBinding>
<wsp:Policy>
<sp:ProtectionToken>
<wsp:Policy>
<sp:SecureConversationToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:RequireDerivedKeys/>
<sp:BootstrapPolicy>
<wsp:Policy>
<sp:SignedParts>
<sp:Body/>
<sp:Header Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"/>
<sp:Header Namespace="http://www.w3.org/2005/08/addressing"/>
</sp:SignedParts>
<sp:EncryptedParts>
<sp:Body/>
</sp:EncryptedParts>
<sp:SymmetricBinding>
<wsp:Policy>
<sp:ProtectionToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">
<wsp:Policy>
<sp:RequireDerivedKeys/>
<sp:RequireThumbprintReference/>
<sp:WssX509V3Token11/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:ProtectionToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Lax/>
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp/>
<sp:OnlySignEntireHeadersAndBody/>
</wsp:Policy>
</sp:SymmetricBinding>
<sp:SignedSupportingTokens>
<wsp:Policy>
<sp:SamlToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/
IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssSamlV20Token11/>
</wsp:Policy>
</sp:SamlToken>
</wsp:Policy>
</sp:SignedSupportingTokens>
<sp:Wss11>
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier/>
<sp:MustSupportRefIssuerSerial/>
<sp:MustSupportRefThumbprint/>
<sp:MustSupportRefEncryptedKey/>
<sp:RequireSignatureConfirmation/>
</wsp:Policy>
</sp:Wss11>
</wsp:Policy>
</sp:BootstrapPolicy>
</wsp:Policy>
</sp:SecureConversationToken>
</wsp:Policy>
</sp:ProtectionToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Lax/>
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp/>
<sp:ProtectTokens/>
<sp:OnlySignEntireHeadersAndBody/>
</wsp:Policy>
</sp:SymmetricBinding>
<sp:Wss11>
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier/>
<sp:MustSupportRefIssuerSerial/>
<sp:MustSupportRefThumbprint/>
<sp:MustSupportRefEncryptedKey/>
<sp:RequireSignatureConfirmation/>
</wsp:Policy>
</sp:Wss11>
<sp:Trust13>
<wsp:Policy>
<sp:MustSupportIssuedTokens/>
<sp:RequireClientEntropy/>
<sp:RequireServerEntropy/>
</wsp:Policy>
</sp:Trust13>
</wsp:Policy>

WS-TrustクライアントとリモートSTSサーバーの間のWS-Trustメッセージの保護に使用されるポリシーは、パッケージ化されたセキュリティ・ポリシーWssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey.xmlのコピーです。このファイルでは、認証およびWS-Security 1.1によるメッセージ・レベルのセキュリティにユーザー名トークンが使用されます。

セキュリティ・ポリシー全体を次に示します。

<?xml version="1.0"?>
<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<sp:SymmetricBinding>
<wsp:Policy>
<sp:ProtectionToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">
<wsp:Policy>
<sp:RequireThumbprintReference/>
<sp:WssX509V3Token11/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:ProtectionToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Lax/>
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp/>
<sp:OnlySignEntireHeadersAndBody/>
</wsp:Policy>
</sp:SymmetricBinding>
<sp:SignedEncryptedSupportingTokens>
<wsp:Policy>
<sp:UsernameToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssUsernameToken10/>
</wsp:Policy>
</sp:UsernameToken>
</wsp:Policy>
</sp:SignedEncryptedSupportingTokens>
<sp:Wss11>
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier/>
<sp:MustSupportRefIssuerSerial/>
<sp:MustSupportRefThumbprint/>
<sp:MustSupportRefEncryptedKey/>
<sp:RequireSignatureConfirmation/>
</wsp:Policy>
</sp:Wss11>
<sp:SignedParts>
<sp:Header Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"/>
<sp:Header Namespace="http://www.w3.org/2005/08/addressing"/>
<sp:Body/>
</sp:SignedParts>
<sp:EncryptedParts>
<sp:Body/>
</sp:EncryptedParts>
</wsp:Policy>

注意:

メッセージ・レベルのセキュリティ・ポリシーを使用してセキュアな会話のブートストラップ・メッセージを保護する場合、WS-TrustクライアントとリモートSTSの間で交換されるWS-Trustメッセージもメッセージ・レベルのセキュリティ・ポリシーを使用して保護する必要があります。トランスポート・レベルのセキュリティ・ポリシーとメッセージ・レベルのセキュリティ・ポリシーを併用することはできません。

WS-TrustクライアントからWebサービスを呼び出す場合、構成は前の例とほぼ同じです。主な違いとしては、次の点があげられます。

- 暗号化証明書を2つ構成する必要があります。1つはSAMLトークンを取得するためのSTSの証明書、もう1つはサーバー用の証明書です。

- セキュアな会話のためのサービスSTSエンドポイント・アドレスを構成する必要はありません。ブートストラップ・メッセージがトランスポート・レベルのセキュリティで保護されていない場合、STSエンドポイント・アドレスはデフォルトで、セキュアな会話のサービス・エンドポイント・アドレスと同じです。

- SSLの構成は不要です。

例2-12は、クライアント・アプリケーションから、WS-Trust経由でSAMLトークンを取得するJAX-WSのWebサービスを呼び出す、単純な例を示しています。それは、WS-Security 1.1によるメッセージ・レベルのセキュリティを使用してセキュアな会話を可能にするセキュリティ・ポリシーに関連付けられています。セキュリティ・コンテキストに関連する太字のセクションについては、例の後で説明します。

例2-12 WS-TrustとWS-SecureConversationを使用し、HTTPSを使用しないクライアント・アプリケーション

package examples.webservices.samlwssc.client;

import weblogic.security.SSL.TrustManager;
import weblogic.wsee.message.WlMessageContext;
import weblogic.wsee.security.bst.ClientBSTCredentialProvider;
import weblogic.wsee.security.saml.SAMLTrustCredentialProvider;
import weblogic.wsee.security.unt.ClientUNTCredentialProvider;
import weblogic.xml.crypto.wss.WSSecurityContext;
import weblogic.xml.crypto.wss.provider.CredentialProvider;
import weblogic.wsee.jaxrpc.WLStub;
import weblogic.wsee.security.util.CertUtils;
import weblogic.wsee.security.wssc.utils.WSSCClientUtil;
import com.sun.xml.ws.developer.MemberSubmissionAddressingFeature;

. . .

public class TravelAgency1Client {

public static final String STS_POLICY = "StsWss11UntPolicy.xml";

public static void main(String[] args) throws Exception {
TravelAgencyClient client = new TravelAgencyClient();
String stsURL = System.getProperty("stsURL");
System.out.println("StS URL \t" + stsURL);

String hotelWsdlURL = System.getProperty("hotelWsdlURL");
System.out.println("Hotel Service WSDL URL \t" + hotelWsdlURL);
String hotelResult = client.callWsscHotelService("Travel Agency client to Hotel Service", stsURL, hotelWsdlURL);
System.out.println("Hotel Service return value: -->" + hotelResult);
}

public String callWsscHotelService(String hello,
String stsurl,
String hotelWsdlURL) throws Exception {

HotelService service = new HotelService(new URL(hotelWsdlURL),
new QName("http://wsinterop.org/samples", "HotelService"));

IHotelService port = service.getIHotelServicePort(new MemberSubmissionAddressingFeature());

BindingProvider provider = (BindingProvider) port;
this.configurePort(provider, stsurl);

try {
// for secure conversation, it can call twice
String s1 = port.getName(hello);
String s2 = port.getName(hello + " --- " + s1);
WSSCClientUtil.terminateWssc((BindingProvider)port);
return s2;
} catch (Exception ex) {
ex.printStackTrace();
throw new RuntimeException("fail to call the remote hotel service!", ex);
}
}

private void configurePort(BindingProvider provider, String stsurl) throws Exception {

Map context = provider.getRequestContext();
InputStream policy = getPolicy(STS_POLICY);
context.put(WlMessageContext.WST_BOOT_STRAP_POLICY, policy);
context.put(WLStub.WST_STS_ENDPOINT_ON_SAML, stsurl);
context.put(WLStub.STS_ENCRYPT_CERT, getStsCert());
context.put(WLStub.SERVER_ENCRYPT_CERT, getServerCert());
List credProviders = buildCredentialProviderList();
context.put(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders);
context.put(WLStub.POLICY_COMPATIBILITY_PREFERENCE, WLStub.POLICY_COMPATIBILITY_MSFT);
}

private static List buildCredentialProviderList() throws Exception {
List credProviders = new ArrayList();
credProviders.add(new SAMLTrustCredentialProvider());
credProviders.add(getClientUNTCredentialProvider());
return credProviders;
}

. . .

private static X509Certificate getServerCert() throws Exception {
String defaultServerCert = new File(
TravelAgency1Client.class.getResource("/Bob.cer").getFile()).getCanonicalPath();
String certName = System.getProperty("target.serverCert",
defaultServerCert);
X509Certificate cert = CertUtils.getCertificate(certName);
return cert;
}
}

この例では、次の点に注意してください。

- リモートSTSとWS-Trustクライアントとの間のメッセージ保護を目的としたSTSサーバー証明書を構成します。
context.put(WLStub.STS_ENCRYPT_CERT, getStsCert());

- セキュアな会話のブートストラップ・メッセージのメッセージ保護を目的としたSTSサーバー証明書を構成します。
context.put(WLStub.SERVER_ENCRYPT_CERT, getServerCert());

- (オプション)サービスがMicrosoft .NET WCFサービスの場合は、WLStub.POLICY_COMPATIBILITY_PREFERENCEフラグをWLStub.POLICY_COMPATIBILITY_MSFTに設定して相互運用性を確保します。
context.put(WLStub.POLICY_COMPATIBILITY_PREFERENCE, WLStub.POLICY_COMPATIBILITY_MSFT);

セキュリティ・コンテキストおよび派生キーの構成と使用

セキュリティ・コンテキストと派生キーを構成するために、次のような事前定義済のWS-SecurityPolicyファイルが提供されています。

- WS-SecureConversation 1.2 (2005/2)仕様

- Wssp1.2-Wssc200502-Bootstrap-Https.xml

- Wssp1.2-Wssc200502-Bootstrap-Wss1.0.xml

- Wssp1.2-Wssc200502-Bootstrap-Wss1.1.xml

- WS-SecureConversation 1.3バージョンのWS-SecureConversation 1.2 (2005/2)ポリシー・ファイル

- Wssp1.2-Wssc1.3-Bootstrap-Https.xml

- Wssp1.2-Wssc1.3-Bootstrap-Wss1.0.xml

- Wssp1.2-Wssc1.3-Bootstrap-Wss1.1.xml

- 追加のWS-SecureConversation 1.3ポリシー・ファイル

- Wssp1.2-Wssc1.3-Bootstrap-Https-BasicAuth.xml

- Wssp1.2-Wssc1.3-Bootstrap-Https-ClientCertReq.xml

- WS-SecureConversation 1.4ポリシー

- Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-UsernameToken-Plain-X509-Basic256.xml

- Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-UsernameToken-Plain-X509-Basic256Sha256.xml

- Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-Saml1.1-SenderVouches.xml

- Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.1-Saml1.1-SenderVouches.xml

- Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.1-Saml2.0-Bearer.xml

- Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.1-UsernameToken-Plain-EncryptedKey.xml

必要な機能と一般的なデフォルト値のほとんどが、これらのセキュリティ・ポリシー・ファイルで提供されるので、セキュリティ・コンテキストを構成する場合には、これらの事前定義済ファイルを使用することをお薦めします。これらのファイルの詳細は、「WS-SecureConversationポリシー」を参照してください。

注意:

クラスタに対して共有のセキュリティ・コンテキストを使用するWebサービスをデプロイする場合は、クラスタ間のセッション状態レプリケーションも構成する必要があります。詳細は、『Oracle WebLogic Serverクラスタの管理』のクラスタのフェイルオーバーとレプリケーションに関する項を参照してください。

ポリシー・アノテーション、アプリケーションのWSDLにアタッチされたポリシー、または実行時のポリシー構成を通じてポリシーを使用するように、アプリケーションをコーディングまたは構成します。

仕様の後方互換性

WebLogic Webサービスでは、Web Services Trust (WS-Trust 1.3)およびWeb Services Secure Conversation (WS-SecureConversation 1.3)仕様を実装しています。02/2005バージョンのWS-SecureConversationとは次の点で異なりますので注意してください。

- Web Services Secure Conversation (WS-SecureConversation 1.3)仕様では、トークン・サービスはwst:RequestSecurityTokenに応答して、開始側パーティにwst:RequestedSecurityTokenを戻す必要があります。1つのwst:RequestSecurityTokenResponseCollectionの中に1つ以上のwst:RequestSecurityTokenResponse要素が含まれています。
これは、トークン・サービスがwst:RequestSecurityTokenResponseを戻していた旧バージョンの仕様とは異なります。

次のようにサービス・ポリシーでSC10SecurityContextTokenが指定されている場合、トークン・サービスはwst:RequestSecurityTokenResponseを戻すことができます。

- WS-SecurityPolicy 1.2 Errataドキュメントには、SecureConversationToken Assertionに関する次の変更が記述されています:
<sp:SC10SecurityContextToken />

これを次のように変更します。

<sp:SC13SecurityContextToken />

sp:SC10SecurityContextTokenは、02/2005バージョンのWS-SecureConversationで使用する場合にのみ、引き続きサポートされます。

WS-SecureConversationとクラスタ

WS-SecureConversationは、クラスタ内の特定のWebLogic Serverインスタンスに固定されています。SecureConversationリクエストが間違ったサーバーに届くと、自動的に正しいサーバーに転送されます。WS-SecureConversationをホストするサーバー・インスタンスに障害が発生した場合は、そのサーバー・インスタンスが回復するまでSecureConversationを使用できなくなります。

セキュリティ・コンテキストのネゴシエーションを行うためのクライアント・アプリケーションの更新

Webサービスの呼出し時にセキュリティ・コンテキストのネゴシエーションを行うクライアント・アプリケーションは、メッセージ保護されたWebサービスを呼び出す標準的なクライアント・アプリケーションに似ています(「クライアント側のセキュリティ・ポリシー・ファイルの使用」を参照)。本質的には、セキュアなコンテキスト・トークンを明示的に取り消すために、weblogic.wsee.security.wssc.utils.WSSCClientUtil APIを使用できるという点のみが異なっています。

SCT存続期間プロパティを設定して、SCT有効期限値を構成できます。このSCT有効期限値は、SCTのタイムアウト処理に使用されます。タイムアウトに達すると、クライアント側のWebサービス・ランタイムによって、SCTが自動的に更新されます。未使用のセキュアなコンテキスト・トークンは、タイムアウトに達すると自動的に取り消されます。

注意:

WebLogic Serverには、ユーザーの利便性だけを目的としてWSSCCLientUtil APIが用意されています。このWebサービス・ランタイムでは、構成されたタイムアウトに到達するとセキュアなコンテキスト・トークンが自動的に取消されます。このAPIは、トークンを取消す時期をより厳密に制御する必要がある場合にのみ使用します。

例2-13は、クライアント・アプリケーションから、セキュアな会話を可能にする事前定義済のセキュリティ・ポリシー・ファイルに関連付けられたJAX-RPCのWebサービスを呼び出す、単純な例を示しています。セキュリティ・コンテキストに関連する太字のセクションについては、例の後で説明します。

例2-13 WS-SecureConversationを使用するクライアント・アプリケーション

package examples.webservices.wssc.client;
import weblogic.security.SSL.TrustManager;
import weblogic.xml.crypto.wss.provider.CredentialProvider;
import weblogic.xml.crypto.wss.WSSecurityContext;
import weblogic.wsee.security.bst.ClientBSTCredentialProvider;
import weblogic.wsee.security.bst.StubPropertyBSTCredProv;
import weblogic.wsee.security.wssc.utils.WSSCClientUtil;
import weblogic.wsee.security.util.CertUtils;
import javax.xml.rpc.Stub;
import java.util.List;
import java.util.ArrayList;
import java.security.cert.X509Certificate;

/**
* Copyright © 1996, 2008, Oracle and/or its affiliates.
* All rights reserved.
*/
public class WSSecureConvClient {
public static void main(String[] args) throws Throwable {

String clientKeyStore = args[0];
String clientKeyStorePass = args[1];
String clientKeyAlias = args[2];
String clientKeyPass = args[3];
String serverCert = args[4];
String wsdl = args[5];

WSSecureConvService service = new WSSecureConvService_Impl(wsdl);
WSSecureConvPortType port = service.getWSSecureConvServicePort();

//create credential provider and set it to the Stub
List credProviders = new ArrayList();

//use x509 to secure wssc handshake
credProviders.add(new ClientBSTCredentialProvider(clientKeyStore,
clientKeyStorePass, clientKeyAlias, clientKeyPass));

Stub stub = (Stub)port;

stub._setProperty(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders);
stub._setProperty(StubPropertyBSTCredProv.SERVER_ENCRYPT_CERT, CertUtils.getCertificate(serverCert));
stub._setProperty(WlMessageContext.SCT_LIFETIME_PROPERTY, new Long( 2 * 60 * 60 * 1000L));
// set to 2 hrs (Default is 30 minutes.)

stub._setProperty(WSSecurityContext.TRUST_MANAGER,
new TrustManager(){
public boolean certificateCallback(X509Certificate[] chain, int validateErr){
//need to validate if the server cert can be trusted
return true;
}
}
);

System.out.println (port.sayHelloWithWSSC("Hello World, once"));
System.out.println (port.sayHelloWithWSSC("Hello World, twice"));
System.out.println (port.sayHelloWithWSSC("Hello World, thrice"));

//cancel SecureContextToken after done with invocation
WSSCClientUtil.terminateWssc(stub);
System.out.println("WSSC terminated!");

}
}

この例で注目すべき点は次のとおりです。

- セキュアなコンテキスト・トークンを明示的に終了するために使用されるWebLogic APIをインポートします。

import weblogic.wsee.security.wssc.utils.WSSCClientUtil;

- JAX-RPCスタブに次のプロパティを設定します。このプロパティは、クライアント・アプリケーションが指定のWebLogic Server公開鍵でWebLogic Serverへのリクエストを暗号化する必要があることを示しています。

stub._setProperty(StubPropertyBSTCredProv.SERVER_ENCRYPT_CERT, CertUtils.getCertificate(serverCert));

- JAX-RPCスタブに次のプロパティを設定します。このプロパティは、セキュリティ・コンテキスト・トークン(SCT)のタイムアウト値を示しています。

stub._setProperty(WlMessageContext.SCT_LIFETIME_PROPERTY, new Long( 2 * 60 * 60 * 1000L));

注意:

SCT存続期間値の設定はオプションです。デフォルト値は30分に設定されています。SCT存続期間値を短くするとセキュリティは向上しますが、SCTを頻繁に更新する必要が生じます。SCT存続期間値を長くすると、SCT更新の頻度が低くなるので、明示的に終了しないかぎり、SCTはメモリー内に長期間保持されます。

- WSSClientUtilクラスのterminateWssc()メソッドを使用して、セキュアなコンテキスト・トークンを終了します。

WSSCClientUtil.terminateWssc(stub);

管理コンソールを使用した実行時のポリシー・ファイルの関連付け

簡易なメッセージ・レベルの構成手順(「簡易なメッセージ・レベルのセキュリティの構成」を参照)では、Webサービスを実装するJWSファイルで@Policyおよび@Policies JWSアノテーションを使用して、サービスに関連付けられた1つ以上のポリシー・ファイルを指定する方法について説明しています。つまり、Webサービスのプログラミング時には、Webサービスとその操作に関連付けるポリシー・ファイルをあらかじめ認識しておく必要がありますが、それが常に可能であるとはかぎりません。このため、Webサービスをデプロイした後、管理コンソールを使用して実行時にポリシー・ファイルを関連付けることも可能です。

JWSファイルで@Policyおよび@Policies JWSアノテーションを使用せず、管理コンソールを使用して実行時にポリシー・ファイルを関連付けるか、あるいはアノテーションを使用して一部のポリシー・ファイルを指定しておき、実行時に追加のポリシー・ファイルを関連付けることができます。

実行時、管理コンソールでは、ファイル内のポリシー・アサーションが互いに矛盾している場合や、JWSアノテーションに関連付けられたポリシー・ファイルのアサーションと矛盾している場合でも、必要な数のポリシー・ファイルをWebサービスとその操作に関連付けることができます。ただし、関連付けられた複数のポリシー・ファイルが連携して機能するかどうかは、ユーザー次第です。なんらかの矛盾がある場合、クライアント・アプリケーションがWebサービスの操作を呼び出すときに、WebLogic Serverから実行時エラーが返されます。

コンソールを使用して1つ以上のWS-PolicyファイルをWebサービスに関連付けるには、EJB JARファイル(EJB実装のWebサービスの場合)、またはWARファイル(Javaクラス実装のWebサービスの場合)のMETA-INF/policiesまたはWEB-INF/policiesディレクトリにWS-Policy XMLファイルを格納する必要があります。

管理コンソールを使用してポリシー・ファイルを実行時に関連付ける詳しい手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのWS-PolicyファイルのWebサービスへのアタッチに関する項を参照してください。

Security Assertion Markup Language (SAML)トークンのアイデンティティとしての使用

この項では、アイデンティティとしてのSAMLトークンの使用について説明します。次の内容で構成されています。

- SAMLトークンの概要

- SAMLトークンのアイデンティティとしての使用: 主な手順

- SAML確認メソッドの指定

- HTTPSを介するSAML 1.1 Bearerトークンのサンプル

- WebサービスのSAML属性の構成

SAMLトークンの概要

SAML Token Profile 1.1 (http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SAMLTokenProfile.pdf)はWS-Security標準のコア・セットの一部であり、Webサービス・セキュリティにSAMLアサーションをどのように使用するかを指定します。WebLogic Serverでは、SAML 2.0およびSAML 1.1アサーションのサポートを含めて、SAML Token Profile 1.1をサポートしています。SAML Token Profile 1.1はSAML Token Profile 1.0と後方互換性があります。

注意:

SAML Token Profile 1.1はWS-SecurityPolicyを通じてのみサポートされます。

WS-SecurityPolicy仕様が規定される以前の旧リリースのWebLogic Serverでは、WS-Policy仕様に基づき、プロプライエタリのセキュリティ・ポリシー・スキーマを使用して記述されたセキュリティ・ポリシー・ファイルを使用していました。これらの初期のセキュリティ・ポリシー・ファイルはSAML Token Profile 1.0とSAML 1.1のみをサポートします。

「簡易なメッセージ・レベルのセキュリティの構成」に記載された簡易なWebサービスの構成手順では、ユーザーがユーザー名トークンを使用して自身を認証することが前提となっています。WebLogic ServerにはWebサービス・セキュリティ仕様のSAML Token Profile 1.1(http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SAMLTokenProfile.pdf)が実装されているので、この項で説明するように、ユーザーはWebサービス操作の呼出しの際にSOAPメッセージでSAMLトークンを使用して自身を認証できます。

SAMLトークンの使用はサーバー間で機能します。つまり、あるWebLogic Serverインスタンスで実行されているクライアント・アプリケーションが、SAMLをアイデンティティとして使用して別のWebLogic Serverインスタンスで実行されているWebサービスを呼び出します。クライアント・アプリケーション自体がWebサービスであるため、Webサービス・セキュリティ・ランタイムによってすべてのSAML処理が行われます。

このサーバー間での使用に加えて、「WS-Trustクライアントの構成」で説明するように、WS-Trustを通じてスタンドアロン・クライアントからSAMLトークンを使用することもできます。

注意:

この項では、読者がSAMLの基礎、およびWebLogic Serverのコア・セキュリティとSAMLとの関連について理解していることを前提としています。一般情報については、『Oracle WebLogic Serverセキュリティの理解』のSecurity Assertion Markup Language (SAML)に関する項を参照してください。

また、次の手順では、「簡易なメッセージ・レベルのセキュリティの構成」の手順がすでに実行されていることを前提として、ユーザー名トークンではなく、SAMLトークンをアイデンティティとして使用できるようにします。

SAMLトークンのアイデンティティとしての使用: 主な手順

1. 必要なSAMLプロバイダが構成されていることを確認し、適切なパートナ・エントリを追加します。この手順により、WebLogic Serverコア・セキュリティ・サブシステムが構成されます。詳細は、『Oracle WebLogic Serverセキュリティの管理』の次の各項を参照してください。

- SAMLアイデンティティ・アサーション・プロバイダの構成

- SAML資格証明マッピング・プロバイダの構成

注意:

SAMLトークン・プロファイルで両方のバージョンのSAMLを使用する場合は、SAML 1.1とSAML 2.0の両方のセキュリティ・プロバイダを構成する必要があります。

SAML 2.0パートナ・エントリを構成する場合、WSSIdPPartnerエントリとWSSSPPartnerエントリの両方について、ターゲットWebサービスのエンドポイントURLをパートナの名前として使用する必要があります。SSLを使用する場合は、URLをHTTPSとして指定します。

2. SAML Holder-of-KeyポリシーのようなSAMLアサーションに関連した署名を呼び出すポリシー(アサーションによって参照されているキーを使用してメッセージが署名されます)、またはSender-Vouchesポリシー(送信側のキーを使用してメッセージが署名されます)を使用する場合は、署名および検証用のキーと証明書を構成する必要があります。
Holder-of-Keyシナリオの場合、クライアント証明書の署名は、SAMLトークンの参照する秘密鍵をクライアントが持っていることを証明します。Sender Vouchesシナリオの場合、クライアント証明書の署名は、SAMLトークンを含むメッセージが送信側で生成されることを保証します。

注意:

これらのキーと証明書は、アサーション自体には署名の作成または認証として使用されることはありません。アサーションに対する署名の作成と検証には、SAMLセキュリティ・プロバイダで構成されているキーと証明書が使用されます。

SAML Bearerポリシーを使用する場合は、保護はSSLによって提供され、PKI資格証明マッピング・プロバイダは必要ありません。

WS-TRUSTを介してスタンドアロン・クライアントのSAMLトークンを使用する場合、トークンはPKI資格証明マッピング・プロバイダではなくWebサービス・クライアント・スタブを通じて渡されます。

1. 送信側でPKI資格証明マッピング・プロバイダを構成し、署名に使用される鍵と証明書を設定します。setKeypairCredentialはprincipalName、resourceid、資格証明アクション、キーストア別名、対応するパスワードの間の鍵ペア・マッピングを作成します。

pkiCM.setKeypairCredential(
type=<remote>, protocol=http,
remoteHost=hostname, remotePort=portnumber, path=/ContextPath/ServicePath,
username, Boolean('true'), None,
alias, passphrase)

最初の(String)パラメータを使用して、ターゲットWebサービスのエンドポイントを表すリソース・オブジェクトが作成されます。userNameパラメータは、署名済Webサービス・メッセージを生成する際のユーザーです。aliasおよびpassphraseパラメータは、PKI資格証明マッピング・プロバイダで構成されているキーストアから鍵と証明書を取得するときに使用される別名とパスフレーズです。KeypairCredentialを作成する前に、実際の鍵と証明書をキーストアにロードしておく必要があります。

2. Webサービス・セキュリティ・ランタイムが検証できるように、同じ証明書を受信側の証明書レジストリに追加します。

reg.registerCertificate(certalias, certfile)

SAML確認メソッドの指定

WS-SecurityPolicyでは、SAMLアサーションに対する確認メソッドは明示的に規定されていませんが、暗黙的に定義されています。次の一般的なガイドラインを考慮してください。

- WSS1.0非対称バインディングにおいて、SamlTokenアサーションが<sp:AsymmerticBinding>アサーションの内部にある場合は、Holder of Key確認メソッドを使用します。
WSS1.1対称バインディングにおいて、SamlTokenアサーションが<sp:EndorsingSupportingTokens>アサーションの内部にある場合は、Holder of Key確認メソッドを使用します。

Holder of Key確認を使用する事前定義済ポリシーの例については、表2-11を参照してください。

- WSS1.0非対称バインディングにおいて、SamlTokenアサーションが<sp:SignedSupportingTokens>の内部にある場合は、Sender Vouches確認メソッドを使用します。
WSS1.1対称バインディングにおいて、SamlTokenアサーションが<sp:SignedSupportingTokens>アサーションの内部にあり、<sp:X509Token>が<sp:EndorsingSupportingTokens>アサーション内で使用されている場合は、Sender Vouches確認メソッドを使用します。

トランスポート・バインディングにおいて、Sender Vouches確認メソッドを使用するには、クライアント認証による双方向SSLが必要です。この場合、第3章「トランスポート・レベルのセキュリティの構成」の説明に従って、トランスポート・レベルのセキュリティを使用してください。

Sender Vouches確認を使用する事前定義済ポリシーの例については、表2-11を参照してください。

- トランスポート・レベルのセキュリティにおいて、SamlTokenアサーションが<sp:SupportingTokens>の内部にある場合は、Bearer確認メソッドを使用します。この場合、第3章「トランスポート・レベルのセキュリティの構成」の説明に従って、トランスポート・レベルのセキュリティを使用してください。
WSS1.1対称バインディングにおいて、SamlTokenアサーションが<sp:SignedSupportingTokens>アサーションの内部にあり、<sp:EndorsingSupportingTokens>アサーションが存在しない場合は、Bearer確認メソッドを使用します。

Bearer確認を使用する事前定義済ポリシーの例については、表2-11を参照してください。

SAML確認メソッドの指定(プロプライエタリのポリシーのみ)

この項では、プロプライエタリのセキュリティ・ポリシー・スキーマを使用するポリシー・ファイル内にSAML確認メソッドを指定する方法について説明します。

注意:

SAML V1.1とSAML V2.0のアサーションでは、それぞれ<saml: SubjectConfirmation>要素と<saml2: SubjectConfimation>要素を使用して確認メソッドを指定します。確認メソッドはポリシー・ファイルに直接指定しません。

アイデンティティとしてSAMLトークンを要求するようにWebサービスを構成する場合には、次のいずれかの確認メソッドを指定できます。

- sender-vouches

- holder-of-key

- bearer

これらの確認メソッドの詳細は、「SAML WebLogic WebサービスでのSAMLトークン・プロファイルのサポート」およびWeb Services Security: SAML Token Profile (http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SAMLTokenProfile.pdf)仕様を参照してください。

1. アイデンティティとしてSAMLを使用することを指定したセキュリティ・ポリシー・ファイルを使用します。正確な構文は、構成する確認メソッドのタイプ(sender-vouches、holder-of-key)によって異なります。
sender-vouches確認メソッドを指定するには、次の手順に従います。

1. <Identity><SupportedTokens>要素の<SecurityToken>子要素を作成し、TokenType属性をSAMLトークンの使用を示す値に設定します。

2. <SecurityToken>要素の<Claims><Confirmationmethod>子要素を追加し、sender-vouchesを指定します。
次に例を示します。

<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
>
<wssp:Identity>
<wssp:SupportedTokens>
<wssp:SecurityToken
TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-2004-01-saml-token-profile-1.0#SAMLAssertionID">
<wssp:Claims>
<wssp:ConfirmationMethod>sender-vouches</wssp:ConfirmationMethod>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Identity>
</wsp:Policy>

holder-of-key確認メソッドを指定するには、次の手順に従います。

1. <Integrity><SupportedTokens>要素の<SecurityToken>子要素を作成し、TokenType属性をSAMLトークンの使用を示す値に設定します。
holder-of-key確認メソッドの<Integrity>アサーションにSAMLトークンを含めるのは、Webサービス・ランタイムがメッセージの整合性を証明する必要があるためです。sender-vouchesの場合、メッセージの整合性を証明する必要はありません。

2. <SecurityToken>要素の<Claims><Confirmationmethod>子要素を追加し、holder-of-keyを指定します。
次に例を示します。

<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part">
<wssp:Integrity>
<wssp:SignatureAlgorithm
URI="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<wssp:CanonicalizationAlgorithm
URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<wssp:Target>
<wssp:DigestAlgorithm
URI="http://www.w3.org/2000/09/xmldsig#sha1" />
<wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
<wssp:SupportedTokens>
<wssp:SecurityToken
IncludeInMessage="true"
TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-2004-01-saml-token-profile-1.0#SAMLAssertionID">
<wssp:Claims>
<wssp:ConfirmationMethod>holder-of-key</wssp:ConfirmationMethod>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Integrity>
</wsp:Policy>

3. デフォルトでは、WebLogic Webサービス・ランタイムは常に、関連付けられたすべてのWS-Policyファイルの<KeyInfoアサーションで指定されているX.509証明書を検証します。SAML holder-of-keyアサーションの使用時にこの検証を無効化するには、SAMLトークン・ハンドラにプロパティを設定することで、Webサービスと関連付けられたWebサービス・セキュリティを構成する必要があります。この構成を管理コンソールで行う方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML holder_of_keyアサーション使用時のX.509証明書の検証の無効化に関する項を参照してください。
固有のセキュリティ・ポリシー・ファイルの作成の詳細は、「カスタム・ポリシー・ファイルの作成と使用」を参照してください。アサーションのリファレンス情報は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のWebサービス・セキュリティ・ポリシー・アサーションのリファレンスの項を参照してください。

2. Webサービスを実装するJWSファイルの該当する@Policyアノテーションを更新して、前の手順で作成したセキュリティ・ポリシー・ファイルを指定します。たとえば、Webサービスのすべての操作の呼出しでSAMLをアイデンティティとして使用する場合は、@Policyアノテーションをクラス・レベルで指定します。
Webサービスに関連付けるポリシー・ファイルは、互いに矛盾しないかぎり、適宜組み合せることができます。ただし、OASIS WS-SecurityPolicy 1.2ファイルと、Oracleのセキュリティ・ポリシー・スキーマに従って記述されたセキュリティ・ポリシー・ファイルを組み合せることはできません。

たとえば、<アイデンティティ>・セキュリティ・アサーションのみが含まれるシンプルなMyAuth.xmlファイルを作成し、アイデンティティにSAMLの使用を指定してから、これを事前定義済のWssp1.2-2007-EncryptBody.xmlおよびWssp1.2-2007-SignBody.xmlファイルと共にWebサービスに関連付けます。ただし、関連付けられた複数のポリシー・ファイルが互いに矛盾しないようにする必要があります。なんらかの矛盾がある場合は、実行時エラーが発生するか、またはWebサービスが想定どおりに動作しなくなるおそれがあります。

3. 通常の反復的な開発プロセスの一部として、Webサービスを再コンパイルして再デプロイします。
『Oracle WebLogic Server JAX-RPC Webサービスの開発』のWebLogic Webサービスの開発に関する項を参照してください。

4. SAMLをアイデンティティとして使用してメインWebサービスを呼び出すように、WebLogic Serverインスタンスで実行されるクライアント・アプリケーションを作成します。詳細は、「WebLogic Serverインスタンスで実行中のクライアントからのWebサービスの呼出し」を参照してください。

HTTPSを介するSAML 1.1 Bearerトークンのサンプル

このリリースのWebLogic Serverには、スタンドアロン・クライアントによるSAML 1.1 Bearerの例が含まれています。この例は、WebLogic ServerインストールのWLS_HOME\samples\server\examples\src\examples\webservices\saml\bearer11sslにあります。

これはスタンドアロン・クライアントによるSAML 1.1 Bearerの例です。WS-TrustによるSAMLアサーションを使用したWebサービス・アプリケーションの認証に必要な最小限の構成および設定を示しています。この例には2つのWebLogic Serverインスタンスが含まれ、それらは、FlightService Webサービスのホストと、セキュリティ・トークン・サービス(STS)として使用するSTSHttpsUNT.javaのホストです。

TravelAgencyClientは公開鍵/秘密鍵の組合せを保持せず、トランスポート・レベルのメッセージ保護を使用して、STSからSAMLトークンを取得して認証を行います。

WebサービスのSAML属性の構成

SAMLアサーションは、サブジェクトに対する認証動作の実行、サブジェクトの属性に関する情報、または特定のリソースに関する認可データのサブジェクトへの適用について、SAML権限が作成するデータです。

SAMLの仕様(http://www.oasis-open.orgを参照)では、特定のサブジェクトに関する不特定の追加情報をSAMLパートナ間でアサーション内の属性文としてやり取りすることが許可されています。したがって、SAML属性アサーションは、サブジェクトの属性に関してサイトで決定される情報を伝達する、特定のタイプのSAMLアサーションです。

属性のデータ型はStringです。

属性は、多くの場合、名前/値の組合せであり(たとえば、name=position, value=team lead)、複数の値を指定できます。ただし、必ずしもこのモデルに従う必要はありません。

SAML属性はターゲット・パートナ・サービスで確認でき、認証または認可の際の追加情報として使用できます。

SAML属性の使用はサーバー間で機能します。つまり、あるWebLogic Serverインスタンスで、属性を提供するクライアント・アプリケーションが実行されています。このアプリケーションは、同じまたは別のWebLogic Serverインスタンスで実行されているWebサービスを呼び出して属性を使用します。クライアント・アプリケーション自体がWebサービスであるため、Webサービス・セキュリティ・ランタイムによってすべてのSAML処理が行われます。

SAML属性の使用: 使用可能なインタフェースおよびクラス

表2-3に示すクラスおよびインタフェースを使用してSAMLの属性を実装できます。詳細は、Oracle WebLogic Server Java APIリファレンスを参照してください。

表2-3 SAML属性のクラスおよびインタフェース

インタフェースまたはクラス

説明

weblogic.wsee.security.saml.SAML2CredentialProvider

SAML 2.0アサーションの資格証明プロバイダ。

weblogic.wsee.security.saml.SAMLCredentialProvider

SAML 1.1アサーションの資格証明プロバイダ。

weblogic.wsee.security.saml.SAMLAttributeStatementData

このインタフェースは、1つの属性文中の属性を表します。SAML 1.1および2.0に対応しています。

weblogic.wsee.security.saml.SAMLAttributeStatementDataImpl()

このクラスは、1つの属性文中の属性を表します。SAML 1.1および2.0に対応しています。

weblogic.wsee.security.saml.SAMLAttributeData

SAML 1.1またはSAML 2.0属性のいずれかのSAML属性情報インタフェース。

weblogic.wsee.security.saml.SAMLAttributeDataImpl()

weblogic.wsee.security.saml.SAMLAttributeDataを実装するクラス。

weblogic.wsee.security.saml.SAMLAttributeStatementDataHelper

SAMLAttributeStatementDataオブジェクトを取得するヘルパー関数

表2-3に記載されたクラスとインタフェースの中で、SAMLAttributeDataインタフェースについて追加の説明を行います。SAMLAttributeDataインタフェースは、SAML 1.1およびSAML 2.0の属性をサポートします。表2-4に示すメソッドがあります。

表2-4 SAMLAttributeDataのメソッド

メソッド

説明

getAttributeName()

属性名を取得します。

getAttributeNameFormat()

属性名の書式を取得します(SAML 2.0専用)。

getAttributeFriendlyName()

属性のわかりやすい名前を取得します。

getAttributeValues()

属性値の集合を取得します。

isSAML20()

SAML 2.0の属性かどうかをチェックします。SAML 2.0属性の場合はtrue、それ以外の場合はfalseを返します

setAttributeName(String attributeName)

属性名を設定します。

setAttributeNameFormat(String attributeNameFormat)

属性名の書式を設定します。

setAttributeFriendlyName(String attributeFriendlyName)

わかりやすい属性名を設定します。

setAttributeValues(Collection<String> attributeValues)

属性値の集合を設定します。

addAttributeValue(String attributeValue)

属性値を1つ追加します。

getAttributeNameSpace()

属性のネームスペースを取得します。SAML 1.1専用です。

setAttributeNameSpace(String attributeNameSpace)

属性のネームスペースを設定します。SAML 1.1専用です。

getSAML2AttributeInfo()

このオブジェクトからSAML 2.0属性情報オブジェクトを取得します。

getSAMLAttributeInfo()

このオブジェクトからSAML 1.1属性情報オブジェクトを取得します。

isEmpty()

この属性データ要素の値がないかどうかをチェックします。

SAML属性の使用: 主な手順

SAML2CredentialProviderクラスおよびSAMLCredentialProviderクラスは、Webサービス・コンテキストを介してSAMLアサーションに属性を追加するメカニズムを提供します。

SAMLパートナで、SAMLAttributeStatementDataHelper.getSAMLAttributeStatementDataメソッドを使用して、Webサービス・コンテキストに基づいて受信SAMLアサーションから属性をマップします。

次の手順に従います。

- SAML2CredentialProviderまたはSAMLCredentialProvider (SAMLアイデンティティ・プロバイダ・サイト)によって、使用する属性およびパッケージの方法が決定されます。
属性をパッケージするには、SAMLAttributeStatementDataインタフェースおよびSAMLAttributeDataインタフェースを実装します。

- SAMLパートナは、WebServiceContextを使用して属性を取得し、属性に対する処理を決定します。
SAMLAttributeStatementDataHelperクラスを使用してSAMLAttributeStatementDataオブジェクトを取得し、このオブジェクトからSAMLAttributeDataオブジェクトを取得します。

SAML属性の例

この項では、SAML 2.0のSAML属性を実装する単純なアプリケーションについて説明します。この例は、WebLogic ServerインストールのWLS_HOME\samples\server\examples\src\examples\webservices\saml\saml20svにあります。

例2-14に、WebLogic Serverインスタンスで実行されているWebサービス(クライアント)の例を示します。

このWebサービスは、WebServiceContextに4つの属性を追加します。最初の属性は値を保持せず、2番目の属性は静的値を使用します。3番目および4番目の属性の値は、サブジェクトの認証に基づいて計算されます。

例2-14 WebServiceContextに属性を追加するWebサービス

@WebService(serviceName = "ProxyService", name = "IProxy", targetNamespace = "http://www.oracle.com/2008/12/interop")
public class ProxyService{

@WebMethod(operationName = "Echo")
@WebResult(name = "EchoResponse")
public String echo(@WebParam(name = "EchoRequest")String hello,
@WebParam(name = "partenerWsdlURL") String partenerWsdlURL){
try{
PartnerService service =
new PartnerService(new URL(partenerWsdlURL),
new QName("http://www.oracle.com/2008/12/interop", "PartnerService"));

IPartner port = service.getIPartnerPort();
BindingProvider provider = (BindingProvider) port;
Map context = provider.getRequestContext();
context.put(WLStub.SAML_ATTRIBUTE_ONLY, "True");

List credProviders = buildCredentialProviderList();
context.put(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders);

String result = port.echo(hello);
return result+" I'm ProxyService Echo!\n";

} catch(Exception ex ){
throw new RuntimeException(ex);
}
}

private static List buildCredentialProviderList() throws Exception  {
List credProviders = new ArrayList();
credProviders.add(new MySAMLCredentialProvider1());

return credProviders;
}

/**
* This Credential Provider is for SAML 2.0 Sender Vouches
*/

private static class MySAMLCredentialProvider1 extends SAML2CredentialProvider {

public SAMLAttributeStatementData getSAMLAttributeData(Subject subject) {

System.out.println(" Providing SAML Attributes from MySAMLCredentialProvider1 for Subject =" + subject);
// There are four types of attributes in this test

SAMLAttributeStatementData attributes = new SAMLAttributeStatementDataImpl();

String xmlns = "www.oracle.com/webservices/saml/test";
// 1. The attribute without value

SAMLAttributeData attribute1 = new SAMLAttributeDataImpl();
attribute1.setAttributeName("test.no.value.attribute");
// Friendly name is optional. It is set in this example.
attribute1.setAttributeFriendlyName("Type 1 - No Value");
attribute1.setAttributeNameSpace(xmlns);
attributes.addAttributeInfo(attribute1);

// 2. Static attribute that has static value

SAMLAttributeData attribute2 = new SAMLAttributeDataImpl();
attribute2.setAttributeName("test.static.attribute");
attribute2.setAttributeFriendlyName("Type 2 - Static Attribute");
attribute2.setAttributeNameSpace(xmlns);
attribute2.addAttributeValue("static.attribute.value");
attributes.addAttributeInfo(attribute2);

// 3. Subjust dependent attributes

SAMLAttributeData attribute3 = new SAMLAttributeDataImpl();
attribute3.setAttributeName("test.subject.dependent.attribute");
attribute3.setAttributeFriendlyName("Type 3 - Subject Dependent Attribute");
attribute3.setAttributeNameSpace(xmlns);
if (hasUser("Alice", subject)) {
attribute3.addAttributeValue("Alice A");
}  else if (hasUser("Bob", subject)) {
attribute3.addAttributeValue("Bob B");
}   else {
attribute3.addAttributeValue("Hacker X");
}
attributes.addAttributeInfo(attribute3);

// 4. Multiple value attributes

SAMLAttributeData attribute4 = new SAMLAttributeDataImpl();
attribute4.setAttributeName("test.multi.value.attribute");
attribute4.setAttributeFriendlyName("Type 4 - Multi-Value Attribute");
attribute4.setAttributeNameSpace(xmlns);
if (hasUser("Alice", subject)) {
attribute4.addAttributeValue("Team Lead");
attribute4.addAttributeValue("Programmer");
}  else if (hasUser("Bob", subject)) {
attribute4.addAttributeValue("System Admin");
attribute4.addAttributeValue("QA");
}   else {
attribute4.addAttributeValue("Hacker");
attribute4.addAttributeValue("meber of unkown");
}
attributes.addAttributeInfo(attribute4);
return attributes;
}

private static boolean hasUser(String user, Subject subject) {
if (null == user || null == subject) {
return false;
}
Set principals = subject.getPrincipals();
if (null == principals || principals.isEmpty()) {
return false;
}
for (Iterator it = principals.iterator(); it.hasNext(); )  {
Object obj = it.next();
if (obj instanceof Principal) {
Principal  p = (Principal) obj;
//         System.out.println("principal =[" + p + "]");
if (user.equals(p.getName())) {
return true;
}
}   else if (obj instanceof WLSPrincipal)  {
WLSPrincipal principal = (WLSPrincipal) obj;
//         System.out.println("principal =[" + principal + "]");
if (user.equals(principal.getName())) {
return true;
}
}
}
return false;
}

}

}

この例では、SAMLAttributeStatementDataImpl()クラスを呼び出してSAMLAttributeStatementDataオブジェクトを取得し、SAMLAttributeDataImpl()を呼び出してSAML2AttributeStatementInfoオブジェクトを取得します。

SAMLAttributeDataクラスはSAML 2.0および1.1をサポートし、この例ではSAML 2.0を使用します。例2-15に、SAMLAttributeDataImpl()を示します。

例2-15 SAMLAttributeDataImplの実装

package weblogic.wsee.security.saml;

import com.bea.security.saml2.providers.SAML2AttributeInfo;
import weblogic.security.providers.saml.SAMLAttributeInfo;

import java.util.Collection;
import java.util.ArrayList;
import java.util.List;
import java.util.Iterator;

/**
*
*/
public class SAMLAttributeDataImpl implements SAMLAttributeData {
public static final String SAML_2_0_ATTRNAME_FORMAT_BASIC = SAML2AttributeInfo.ATTR_NAME_FORMAT_BASIC;

/**
* the name of the attribute
*/
private String attributeName;

private String attributeNameSpace;
/**
* the name format of the attribute for SAML 2.0. Defaults to basic.
*/
private String attributeNameFormat = SAML_2_0_ATTRNAME_FORMAT_BASIC;
/**
* the friendly name of the attribute, this is for SAML 2.0 only.
*/
private String attributeFriendlyName;
/**
* the values of the attribute.
*/
private Collection<String> attributeValues;
/**
* is a SAML 2.0 attribute info
*/
private boolean isSAML20;

public SAMLAttributeDataImpl() {

}

public SAMLAttributeDataImpl(String attributeName, Collection<String> attributeValues) {
this.attributeName = attributeName;
this.attributeValues = attributeValues;
}

public SAMLAttributeDataImpl(String attributeName, String
attributeNameFormat, String attributeFriendlyName, String namespace,
Collection<String> attributeValues) {
this.attributeName = attributeName;
this.attributeNameFormat = attributeNameFormat;
this.attributeFriendlyName = attributeFriendlyName;
this.attributeValues = attributeValues;
this.attributeNameSpace = namespace;
}

public SAMLAttributeDataImpl(SAML2AttributeInfo saml2AttributeInfo)  {
if (null == saml2AttributeInfo) {
throw new IllegalArgumentException("Null SAML2AttributeInfo found ");
}
this.attributeName = saml2AttributeInfo.getAttributeName();
this.attributeNameFormat = saml2AttributeInfo.getAttributeNameFormat();
this.attributeFriendlyName = saml2AttributeInfo.getAttributeFriendlyName();
this.attributeValues = saml2AttributeInfo.getAttributeValues();
this.isSAML20 = true;
}

public SAMLAttributeDataImpl(SAMLAttributeInfo samlAttributeInfo)  {
if (null == samlAttributeInfo) {
throw new IllegalArgumentException("Null SAMLAttributeInfo found ");
}
this.attributeName = samlAttributeInfo.getAttributeName();
this.attributeNameSpace = samlAttributeInfo.getAttributeNamespace();
this.attributeValues = samlAttributeInfo.getAttributeValues();
this.isSAML20 = false;
}

/**
* get the attribute name
*
* @return string of the attribute name
*/
public String getAttributeName() {
return attributeName;
}

/**
* set the attribute name
*
* @param attributeName string of the attribute name
*/
public void setAttributeName(String attributeName) {
if (null == attributeName) {
throw new IllegalArgumentException("attributeName cannot be null");
}
this.attributeName = attributeName;
}

/**
* get the attribute name format for SAML 2.0 only
*
* @return String of the attribute name format,
default is SAML_2_0_ATTRNAME_FORMAT_BASIC for SAML 2.0. Null for SAML 1.1.
*/
public String getAttributeNameFormat() {
return attributeNameFormat;
}
/**
* set et the attribute name format
*
* @param attributeNameFormat String of the attribute name format
*/
public void setAttributeNameFormat(String attributeNameFormat) {
this.attributeNameFormat = attributeNameFormat;
}
/**
* get the Attribute Friendly Name
*
* @return String of the Attribute Friendly Name
*/
public String getAttributeFriendlyName() {
return attributeFriendlyName;
}
/**
* set the Attribute Friendly Name
*
* @param attributeFriendlyName the Attribute Friendly Name
*/
public void setAttributeFriendlyName(String attributeFriendlyName) {
this.attributeFriendlyName = attributeFriendlyName;
}
/**
* get the Attribute Value
*
* @return collection of attribute values
*/
public Collection<String> getAttributeValues() {
return attributeValues;
}
/**
* set collection of attribute values
*
* @param attributeValues collection of attribute values to be set
*/
public void setAttributeValues(Collection<String> attributeValues) {
this.attributeValues = attributeValues;
}
/**
* add one attribute value
*
* @param attributeValue String of attribute value to be added
*/
public void addAttributeValue(String attributeValue) {
if (this.attributeValues == null) {
this.attributeValues = new ArrayList();
}
if (null == attributeValue) {
this.attributeValues.add("");
} else {
this.attributeValues.add(attributeValue);
}
}
/**
* add  attribute values
*
* @param newAttributeValues collection of attribute values to be added
*/
public void addAttributeValues(Collection<String> newAttributeValues) {
if (this.attributeValues == null || this.attributeValues.isEmpty()) {
this.setAttributeValues(newAttributeValues);
return;
}
if (null == newAttributeValues || newAttributeValues.isEmpty()) {
this.attributeValues.add("");
return;
}
Iterator iter = newAttributeValues.iterator();
while (iter.hasNext()) {
this.attributeValues.add((String) iter.next());
}
}
/**
* get the namespace of the Attribute. This is for SAML 1.1 only.
*
* @return string of attribute namespace
*/
public String getAttributeNameSpace() {
return attributeNameSpace;
}
/**
* set attributeNameSpace. This is for SAML 1.1 only.
*
* @param attributeNameSpace attributeNameSpace to be set
*/
public void setAttributeNameSpace(String attributeNameSpace) {
this.attributeNameSpace = attributeNameSpace;
}
/**
* set this data object to SAML 2.0 attribute object
* @param saml20 true if it is a SAML 2.0 attribute data
*/
public void setSAML20(boolean saml20) {
this.isSAML20 = saml20;
}
/**
* check if this is a SAML 2.0 Attributes
*
* @return true if it is a SAML 2.0 attribute, false otherwise
*/
public boolean isSAML20() {
return isSAML20;
}
/**
* get a SAML2AttributeInfo object from this object
*
* @return SAML2AttributeInfo for SAML 2.0
*/
public SAML2AttributeInfo getSAML2AttributeInfo() {
SAML2AttributeInfo sai = new SAML2AttributeInfo();
sai.setAttributeFriendlyName(this.attributeFriendlyName);
sai.setAttributeName(this.attributeName);
if (null == this.attributeNameFormat || this.attributeNameFormat.length() ==0 ) {
sai.setAttributeNameFormat(SAML_2_0_ATTRNAME_FORMAT_BASIC);
} else {
sai.setAttributeNameFormat(this.attributeNameFormat);
}
sai.addAttributeValues(this.attributeValues);
return sai;
}
/**
* get a SAMLAttributeInfo object from this object
*
* @return SAMLAttributeInfo for SAML 1.1
*/
public SAMLAttributeInfo getSAMLAttributeInfo() {
SAMLAttributeInfo sai = new SAMLAttributeInfo();
if (null == this.attributeNameSpace) {
sai.setAttributeName(this.attributeName, "");
} else {
sai.setAttributeName(this.attributeName, this.attributeNameSpace);
}
sai.setAttributeValues(this.attributeValues);
return sai;
}
/**
* This method will add all attribute values into the first SAMLAttributeData
object, and return a single SAMLAttributeData object.
* Please note that the attribute name will not be verified in this method.
*
* @param attributeList  SAMLAttributeData objects to be merged
* @return  a single SAMLAttributeData object
*/
static public SAMLAttributeData consolation(List<SAMLAttributeData>
attributeList) {
if (null == attributeList || attributeList.size() == 0 ) {
return null;
}
if (attributeList.size() == 1) {
attributeList.get(0);
}
SAMLAttributeData data = attributeList.get(0);
for (int i=1; i < attributeList.size(); i++ ) {
data.addAttributeValues(attributeList.get(i).getAttributeValues());
}
return data;
}
/**
* Check if this attribute data element does not have vlaues
* @return true if the data is empty, no values; false otherwise
*/
public boolean isEmpty() {
if ((null == this.attributeValues) || (this.attributeValues.isEmpty())) {
return true;
}
if (this.attributeValues.size() == 1)  {
Object a[] = this.attributeValues.toArray();
if ("".equals(a[0]))  {
return true;
}
}
return false;
}
/**
* Return a String for the array of value String, concatenated with "; "
* @return a string for all values
*/
public String valuesToString(String existing) {
if ((null == this.attributeValues) || (this.attributeValues.isEmpty())) {
return existing;
}
Object a[] = this.attributeValues.toArray();
if (this.attributeValues.size() == 1) {
if (a[0] == null)  {
return existing;
}
if (existing == null)  {
return (String) a[0];
} else {
return existing + "; " + (String) a[0];
}
}
StringBuffer sb = new StringBuffer();
if (existing != null) {
sb.append(existing);
}
for (int i=0; i < a.length; i++) {
sb.append("; ");
if (a[i] != null) {
sb.append((String) a[i]);
}
}
return sb.toString();
}
public String toString() {
StringBuffer sb = new StringBuffer();
sb.append("Name=" + this.attributeName);
if (isSAML20()) {
if (null != this.attributeFriendlyName) {
sb.append(" FriendlyName=" + this.attributeFriendlyName);
}
} else {
if (null != this.attributeNameSpace) {
sb.append(" Namespace=" + this.attributeNameSpace);
}
}
String value = this.valuesToString(null);
if (null != value)   {
sb.append(" Value=" + value);
}
return sb.toString();
}
}

例2-16に示すPartnerServiceコードは、Webサービス・コンテキストの属性の有無を判定し、それらを取得します。この例は、例2-17に示すSAMLAttributeStatementDataHelperクラスに依存します。

この例で使用される事前定義済のポリシーのWssp1.2-2007-Saml2.0-SenderVouches-Wss1.1.xmlについては、表2-11で説明します。

例2-16 WebServiceContextから属性を取得するWebサービス

package jaxws.interop.saml;

import weblogic.jws.Policies;
import weblogic.jws.Policy;
import weblogic.wsee.util.AccessException;
import weblogic.wsee.security.saml.SAMLAttributeStatementData;
import weblogic.wsee.security.saml.SAMLAttributeStatementDataHelper;
import weblogic.wsee.security.saml.SAMLAttributeData;

import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebResult;
import javax.jws.WebService;
import javax.annotation.Resource;
import javax.xml.ws.WebServiceContext;

/**
*  ID Propagation using SAML 2.0 token [sender-vouches] with message protection (WSS 11)  .
*
* This example will work for canned policy like:
*    - Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1.xml
*/

@Policies(
{
@Policy(uri = "policy:Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1.xml"),
@Policy(uri = "policy:Wssp1.2-2007-SignBody.xml"),
@Policy(uri = "policy:Wssp1.2-2007-EncryptBody.xml")
}
)
@WebService(serviceName = "PartnerService", name = "IPartner", targetNamespace = "http://www.oracle.com/2008/12/interop")
public class PartnerService{
@Resource
WebServiceContext ctx;

@WebMethod(operationName = "Echo")
@WebResult(name = "EchoResponse")
public String echo(@WebParam(name = "EchoRequest")String hello){
try {
this.checkSamlAttributesFromRequestMesasge();
return hello+"! I'm PartnerService for SAML 2.0 SenderVouches WSS1.1!\n";
}catch(Exception ex ){
throw new RuntimeException(ex);
}
}

private void checkSamlAttributesFromRequestMesasge() throws AccessException {

SAMLAttributeStatementData attributes  = SAMLAttributeStatementDataHelper.getSAMLAttributeStatementData(ctx);
if (null == attributes)  {
throw new AccessException("No SAML Attributes Data found");
}

SAMLAttributeData testData =  attributes.getAttributeInfo("test.no.value.attribute");
if (null == testData) {
throw new AccessException("Missing SAML Attribute Data of \"test.no.value.attribute\"");
}
if (!attributes.hasAttributeInfo("test.no.value.attribute")) {
throw new AccessException("Missing SAML Attribute Data of \"test.no.value.attribute\"");
}
if (!attributes.hasAttributeInfo("test.static.attribute")) {
throw new AccessException("Missing SAML Attribute Data of \"test.static.attribute\"");
}
if (!attributes.hasAttributeValue("test.static.attribute","static.attribute.value")) {
throw new AccessException("Missing or wrong SAML Attribute Value of \"static.attribute.value\" for attribute \"test.static.attribute\" ");
}
if (!attributes.hasAttributeValue("test.subject.dependent.attribute","Alice A")) {
throw new AccessException("Missing or wrong SAML Attribute Value of \"Alice A\" for attribute - \"test.multi.value.attribute\" ");
}
if (!attributes.hasAttributeValue("test.multi.value.attribute","Programmer")) {
throw new AccessException("Missing or wrong SAML Attribute Value on \"Programmer\" for attribute \"test.multi.value.attribute\" ");
}
if (!attributes.hasAttributeValue("test.multi.value.attribute","Team Lead")) {
throw new AccessException("Missing or wrong SAML Attribute Value on \"Team Lead\"  for attribute \"test.multi.value.attribute\" ");
}
}
}

例2-17に、SAMLAttributeStatementDataHelperクラスを示します。これはSAMLAttributeStatementDataオブジェクトを取得するヘルパー関数です。

例2-17 SAMLAttributeStatementDataHelperヘルパー関数

package weblogic.wsee.security.saml;

import weblogic.wsee.jaxws.framework.jaxrpc.SOAPMessageContext;
import weblogic.wsee.jaxrpc.WLStub;
import weblogic.wsee.jws.JwsContext;
import weblogic.xml.crypto.wss.WSSecurityContext;
import com.sun.xml.ws.api.message.Message;
import com.sun.xml.ws.api.message.Packet;
import com.sun.xml.ws.api.server.WSWebServiceContext;

import javax.xml.ws.WebServiceContext;
import javax.xml.rpc.handler.MessageContext;

/**
*  Helper function to get the SAMLAttributeStatementData object
*/
public class SAMLAttributeStatementDataHelper {

public static SAMLAttributeStatementData getSAMLAttributeStatementData(WebServiceContext context) {

final Packet request = ((WSWebServiceContext) context).getRequestPacket();

WSSecurityContext securityCtx = (WSSecurityContext) request.invocationProperties
.get(WSSecurityContext.WS_SECURITY_CONTEXT);
SAMLAttributeStatementData samlAttributes = null;
if ((securityCtx != null) && (securityCtx.getMessageContext() != null)) {
samlAttributes = (SAMLAttributeStatementData) securityCtx.getMessageContext().getProperty(WLStub.SAML_ATTRIBUTES);
}
return samlAttributes;
}

public static SAMLAttributeStatementData getSAMLAttributeStatementData(JwsContext context) {

MessageContext msgCtx = context.getMessageContext();     // this is for JAX-RPC
SAMLAttributeStatementData attributes =  (SAMLAttributeStatementData)  msgCtx.getProperty(WLStub.SAML_ATTRIBUTES);

return attributes;
}

}

Webサービスとデフォルト以外のセキュリティ構成との関連付け

これまでに説明した多くの使用例では、管理コンソールを使用してデフォルトのWebサービス・セキュリティ構成(default_wss)を作成する必要があります。この構成の作成後は、@weblogic.jws.security.WssConfiguration JWSアノテーションを使用しなくても、属性のない状態でこのアノテーションを指定しても、すべてのWebサービスにこの構成が適用されます。

ただし、指定するタイムスタンプ値をサービス間で変える場合など、Webサービスをデフォルト以外のセキュリティ構成に関連付ける必要が生じる場合もあります。

Webサービスをデフォルト以外のセキュリティ構成に関連付けるには:

1. default_wss以外の名前でWebサービス・セキュリティ構成を作成します(Oracle WebLogic Server管理コンソール・オンライン・ヘルプのWebサービス・セキュリティ構成の作成に関する項を参照)。

2. JWSファイルを更新します。@WssConfigurationアノテーションを追加して、このセキュリティ構成の名前を指定します。詳細とサンプルについては、『Oracle WebLogic Server Webサービス・リファレンス』のweblogic.jws.security.WssConfigurationに関する項を参照してください。

注意:

同じWebアプリケーションのWebサービスをさらにパッケージ化するときに、そのWebサービスも@WssConfigurationアノテーションを使用している場合は、各Webサービスに同じセキュリティ構成を指定する必要があります。詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のweblogic.jws.security.WssConfigurationに関する項を参照してください。

3. 通常の反復的な開発プロセスの一部として、Webサービスを再コンパイルして再デプロイします。
『Oracle WebLogic Server JAX-WS Webサービスの開発』のWebLogic Webサービスの呼出しに関する項および『Oracle WebLogic Server JAX-RPC Webサービスの開発』のWebLogic Webサービスの開発に関する項を参照してください。

注意:

すべてのWebサービス・セキュリティ構成で、同じパスワード・ダイジェストの使用を指定する必要があります。使用するパスワード・ダイジェストがWebサービス・セキュリティ構成間で異なると、実行時エラーが発生します。

資格証明プロバイダの有効なクラス名とトークン・タイプ

セキュリティ構成を作成するときに、その構成の資格証明プロバイダのクラス名を指定する必要があります。使用できる有効なクラス名とトークン・タイプは以下のとおりです。

- weblogic.wsee.security.bst.ClientBSTCredentialProvider。トークン・タイプはx509です。

- weblogic.wsee.security.unt.ClientUNTCredentialProvider。トークン・タイプはutです。

- weblogic.wsee.security.wssc.v13.sct.ClientSCCredentialProvider。トークン・タイプはsctです。

- weblogic.wsee.security.wssc.v200502.sct.ClientSCCredentialProvider。トークン・タイプはsctです。

- weblogic.wsee.security.saml.SAMLTrustCredentialProvider。トークン・タイプはsamlです。

システム・プロパティを使用したメッセージ・レベルのセキュリティのデバッグ

次の表に、メッセージ保護されたWebサービスの問題をデバッグするために設定できるシステム・プロパティをまとめます。

表2-5 メッセージ・レベルのセキュリティをデバッグするためのシステム・プロパティ

システム・プロパティ

データ型

説明

weblogic.xml.crypto.dsig.verbose

ブール

デジタル署名の処理に関する情報を出力します。

weblogic.xml.crypto.encrypt.verbose

ブール

暗号化処理に関する情報を出力します。

weblogic.xml.crypto.keyinfo.verbose

ブール

キーの解決処理に関する情報を出力します。

weblogic.xml.crypto.wss.verbose

ブール

Webサービス・セキュリティ・トークンおよびトークンの参照処理に関する情報を出力します。

クライアント側のセキュリティ・ポリシー・ファイルの使用

「メッセージ・レベルのセキュリティ構成でのポリシー・ファイルの使用」では、Webサービスのメッセージ・レベルのセキュリティを記述する1つまたは複数のセキュリティ・ポリシー・ファイルに、WebLogic Webサービスを関連付ける方法について説明しています。これらのポリシー・ファイルは、SOAPメッセージのデジタル署名やデジタル暗号化の方法と、Webサービスを呼び出すクライアントで必要になるユーザー認証の種類を記述するXMLファイルです。通常、Webサービスに関連付けられたポリシー・ファイルはそのWSDLにアタッチされます。Webサービス・クライアント・ランタイムはこれを読取り、クライアント・アプリケーションから呼び出された操作からのSOAPメッセージ・リクエストのデジタル署名やデジタル暗号化を行うかどうかを判別したり、行う場合はその方法を判別したりします。

しかし、Webサービスがデプロイ済のWSDLにポリシー・ファイルをアタッチしない場合や、WebサービスがWSDLをまったく公開しないように構成されている場合もあります。これらの場合、Webサービス・クライアント・ランタイムは、SOAPメッセージ・リクエストのために有効にする必要のあるセキュリティをサービス自体から判別できません。かわりに、ポリシー・ファイルのクライアント側のコピーをロードする必要があります。この項では、クライアント・アプリケーションを更新して、ポリシー・ファイルのローカル・コピーがロードされるようにする方法について説明します。

例2-5は、JAX-WS Webサービスのクライアント側ポリシー・ファイルを使用する例を示しています。

通常、クライアント側のポリシー・ファイルは、デプロイ済のWebサービスに関連付けられているポリシー・ファイルとまったく同じものです。これら2つのファイルが異なり、ファイルに含まれるセキュリティ・アサーションに競合がある場合は、Webサービスの操作を呼び出すとエラーが返されます。

クライアント側のポリシー・ファイルは、SOAPメッセージのリクエストまたはレスポンス、あるいはその両方に関連付けることができます。また、ポリシー・ファイルをWebサービス全体と関連付けるか、Webサービスの操作の1つのみと関連付けるかを指定できます。

ポリシー・ファイルとクライアント・アプリケーションの関連付け: 主な手順

次の手順は、Webサービスの操作を呼び出すクライアント・アプリケーションにセキュリティ・ポリシー・ファイルを関連付けるためのステップを大まかに説明したものです。

デプロイ済のWebサービスを呼び出すクライアント・アプリケーションを作成してあり、クライアント側のポリシー・ファイルを関連付けることでそのクライアント・アプリケーションを更新するものとします。また、Antベースの開発環境を設定済であり、かつclientgen Antタスクを実行するためのターゲットを含む、作業用のbuild.xmlファイルがあることが前提となっています。

『Oracle WebLogic Server JAX-WS Webサービスの開発』のWebサービスの呼出しに関する項および『Oracle WebLogic Server JAX-RPC Webサービスの開発』のスタンドアロン・クライアントからのWebサービスの呼出し: 主な手順に関する項を参照してください。

1. クライアント側のセキュリティ・ポリシー・ファイルを作成し、クライアント・アプリケーションからアクセスできる場所に保存します。通常、このセキュリティ・ポリシー・ファイルは、呼び出そうとしているWebサービス用に構成されたものと同じですが、サーバー側のファイルはクライアント・ランタイムに対して公開されないため、クライアント・アプリケーションはそれ自身のローカル・コピーをロードする必要があります。
セキュリティ・ポリシー・ファイルの作成の詳細は、「カスタム・ポリシー・ファイルの作成と使用」を参照してください。

2. クライアント・アプリケーションのビルドに使用するbuild.xmlファイルを更新します。

3. Javaクライアント・アプリケーションを更新して、クライアント側ポリシー・ファイルをロードします

4. 適切なタスクを実行して、クライアント・アプリケーションを再ビルドします。次に例を示します。

prompt> ant build-client

次回クライアント・アプリケーションを実行するときには、ポリシー・ファイルのローカル・コピーがロードされ、Webサービス・クライアント・ランタイムはこれを使用してSOAPリクエスト・メッセージのセキュリティを有効にします。

注意:

すでにセキュリティ・ポリシーが設定されているWebサービスの操作(たとえば、サーバー・ポリシーからクライアントを生成する際に格納されたWSDLファイル内で設定されたWebサービス操作)が存在する場合、この手順に従ってクライアント側のセキュリティ・ポリシーをプログラムで設定すると、それ以前に存在していたポリシーはすべて削除されます。

ポリシー・ファイルをロードするメソッドを生成するためのclientgenの更新

JAX-RPCの場合は、clientgen AntタスクのgeneratePolicyMethods属性をtrueに設定して、Antタスクが追加のgetXXX()メソッドをJAX-RPC Serviceインタフェースの実装内に生成するように指定し、ポートの取得時にポリシー・ファイルのクライアント側コピーがロードされるようにします。例:

<clientgen
wsdl="http://ariel:7001/policy/ClientPolicyService?WSDL"
destDir="${clientclass-dir}"
generatePolicyMethods="true"
packageName="examples.webservices.client_policy.client"/>

追加で生成されるメソッドとそれらをクライアント・アプリケーションで使用する方法の説明は、「ポリシー・ファイルをロードするためのクライアント・アプリケーションの更新(JAX-RPCのみ)」を参照してください。

JAX-WSの使用

JAX-WSの場合は、weblogic.jws.jaxws.ClientPolicyFeatureクラスを使用して、サービスに定義されている有効なポリシーをオーバーライドします。weblogic.jws.jaxws.ClientPolicyFeatureはjavax.xml.ws.WebServiceFeatureを拡張したものです。

ポリシー・ファイルをロードするためのクライアント・アプリケーションの更新(JAX-RPCのみ)

clientgenでgeneratePolicyMethods="true"と設定すると、Antタスクはポリシー・ファイルのロードに使用できるJAX-RPC Serviceインタフェースの実装内に追加メソッドを生成します。XXXはWebサービスの名前です。

ポリシー・ファイルの配列または集合を、Webサービスへの複数ファイルの関連付けに使用できます。単一のポリシー・ファイルのみを関連付ける場合は、単一メンバーの配列または集合を作成します。

- getXXXPort(String operationName, java.util.Set<java.io.InputStream> inbound, java.util.Set<java.io.InputStream> outbound)
クライアント側のポリシー・ファイルの別個の2つの集合を、InputStreamsからロードし、1つ目の集合をSOAPリクエストに関連付け、2つ目をSOAPレスポンスに関連付けます。最初のパラメータで指定されているように、特定の操作に適用されます。

- getXXXPort(String operationName, java.io.InputStream[] inbound, java.io.InputStream[] outbound)
クライアント側のポリシー・ファイルの別個の2つの配列を、InputStreamsからロードし、1つ目の配列をSOAPリクエストに関連付け、2つ目をSOAPレスポンスに関連付けます。最初のパラメータで指定されているように、特定の操作に適用されます。

- getXXXPort(java.util.Set<java.io.InputStream> inbound, java.util.Set<java.io.InputStream> outbound)
クライアント側のポリシー・ファイルの別個の2つの集合を、InputStreamsからロードし、1つ目の集合をSOAPリクエストに関連付け、2つ目をSOAPレスポンスに関連付けます。Webサービスのすべての操作に適用されます。

- getXXXPort(java.io.InputStream[] inbound, java.io.InputStream[] outbound)
クライアント側のポリシー・ファイルの別個の2つの配列を、InputStreamsからロードし、1つ目の配列をSOAPリクエストに関連付け、2つ目をSOAPレスポンスに関連付けます。Webサービスのすべての操作に適用されます。

Webサービスのポートを取得すると同時に、そのポートを使用するすべての操作または指定された操作の呼出しに対してポリシー・ファイルが関連付けられるようにするには、パラメータのない通常のgetXXXPort()メソッドではなく、これらのメソッドを使用します。

注意:

前のリリースのWebLogic Serverからの以下のメソッドは、非推奨となっています。単一のクライアント側ポリシー・ファイルの関連付けを行う場合は、単一メンバーの配列または集合を指定し、上述の対応するメソッドを使用します。

- getXXXPort(java.io.InputStream policyInputStream);
単一のクライアント側ポリシー・ファイルをInputStreamからロードし、SOAPリクエスト(着信)メッセージおよびSOAPレスポンス(発信)メッセージの両方に追加します。

- getXXXPort(java.io.InputStream policyInputStream, boolean inbound, boolean outbound);
単一のクライアント側ポリシー・ファイルをInputStreamからロードし、2番目および3番目のパラメータのブール値に応じて、SOAPリクエスト・メッセージまたはSOAPレスポンス・メッセージのどちらかに適用します。

例2-18に、これらのポリシー・メソッドの簡易なクライアント・アプリケーションでの使用例を示します。太字で示されたコードは、例の後に説明します。

例2-18 クライアント・アプリケーションでのポリシーのロード

package examples.webservices.client_policy.client;
import java.rmi.RemoteException;
import javax.xml.rpc.ServiceException;
import javax.xml.rpc.Stub;
import java.io.FileInputStream;
import java.io.IOException;
/**
* This is a simple standalone client application that invokes the
* the <code>sayHello</code> operation of the ClientPolicyService Web service.
*
* @author Copyright © 1996, 2008, Oracle and/or its affiliates.
* All rights reserved.
*/
public class Main {
public static void main(String[] args)
throws ServiceException, RemoteException, IOException {
FileInputStream [] inbound_policy_array = new FileInputStream[2];
inbound_policy_array[0] = new FileInputStream(args[1]);
inbound_policy_array[1] = new FileInputStream(args[2]);
FileInputStream [] outbound_policy_array = new FileInputStream[2];
outbound_policy_array[0] = new FileInputStream(args[1]);
outbound_policy_array[1] = new FileInputStream(args[2]);
ClientPolicyService service = new ClientPolicyService_Impl(args[0] + "?WSDL");
// standard way to get the Web service port
ClientPolicyPortType normal_port = service.getClientPolicyPort();
// specify an array of policy files for the request and response
// of a particular operation
ClientPolicyPortType array_of_policy_port = service.getClientPolicyPort("sayHello",
inbound_policy_array, outbound_policy_array);
try {
String result = null;
result = normal_port.sayHello("Hi there!");
result = array_of_policy_port.sayHello("Hi there!");
System.out.println( "Got result: " + result );
} catch (RemoteException e) {
throw e;
}
}
}

クライアント・アプリケーションに対する2つ目と3つ目の引数は、アプリケーションがFileInputStreamsの配列(inbound_policy_arrayおよびoutbound_policy_array)を作成する元となる2つのポリシー・ファイルです。normal_portはポートの取得にパラメータのない標準的なメソッドを使用します。一方、array_of_policy_portはポリシー・メソッドの1つを使用します。このポリシー・メソッドで、ポートを使用するsayHello操作の呼出しでは複数のポリシー・ファイル(FileInputStreamの配列で指定)が、着信および発信のSOAPリクエストおよびレスポンスと関連付けられていることを指定します。

ClientPolicyPortType array_of_policy_port =
service.getClientPolicyPort("sayHello", inbound_policy_array, outbound_policy_array);

WS-SecurityPolicy 1.2ポリシー・ファイルの使用

WebLogic Serverには、ほとんどのWebサービス・アプリケーションで使用できるWS-SecurityPolicyファイルがいくつか用意されています。ポリシー・ファイルは、WL_HOME/server/lib/weblogic-classes.jarにあります。weblogic-classes.jar内では、ポリシー・ファイルは/weblogic/wsee/policy/runtimeに位置しています。

これらのポリシーは2つのグループに分けられます。ほとんどの場合、実行する機能はどちらも同じですが、使用するネームスペースが異なります。

1つ目のグループは、Wssp1.2-2007-という接頭辞が付いています。これらのセキュリティ・ポリシー・ファイルは、OASIS WS-SecurityPolicy 1.2仕様に準拠しており、次のネームスペースを備えています。

<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
>

2番目のグループは、WebLogic Serverバージョン10.0から引き継いだもので、接頭辞Wssp1.2-が付いています。

<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512"
>

OASIS標準の公式のネームスペースであり、他のベンダーと相互運用するときに適しているため、新しいポリシー・ネームスペースを使用することをお薦めします。「Wssp1.2」の接頭辞を持っている古いポリシーは、主に、ポリシーのこのバージョンをすでに使用している既存のアプリケーションと相互運用したいユーザー用です。

次の項では、使用可能なWS-SecurityPolicy 1.2ポリシー・ファイルについて説明します。

- トランスポート・レベルのポリシー

- 保護アサーション・ポリシー

- WS-Security 1.0のユーザー名およびX509トークン・ポリシー

- WS-Security 1.1のユーザー名およびX509トークン・ポリシー

- WS-SecureConversationポリシー

- SAML Token Profileポリシー

さらに、Webサービス実装に最も適したセキュリティ・ポリシー・アプローチの選択方法と、このリリースのWebLogic ServerでサポートされていないWS-SecurityPolicy 1.2の要素については、「ポリシーの選択」および「適切なポリシー選択の構成」を参照してください。

トランスポート・レベルのポリシー

これらのポリシーでは、WSDLへのアクセスおよびWebサービス操作の呼出しに、httpsプロトコルを使用する必要があります。

注意:

Webサービスにトランスポート・レベルのセキュリティ・ポリシーを指定する場合、ポリシーの指定はクラス・レベルで行う必要があります。

また、トランスポート・レベルのセキュリティ・ポリシーは着信方向と発信方向の両方に適用する必要があります。つまり、着信にHTTPSを使用し、発信にHTTPを使用することはできません。

表2-6 トランスポート・レベルのポリシー

ポリシー・ファイル

説明

Wssp1.2-2007-Https.xml

一方向SSL。

Wssp1.2-2007-Https-BasicAuth.xml

基本認証による一方向SSL。リクエストに認可ヘッダーが含まれていない場合は401チャレンジが発生します。

Wssp1.2-2007-Https-UsernameToken-Digest.xml

ダイジェスト・ユーザー名トークンによる一方向SSL。

Wssp1.2-2007-Https-UsernameToken-Plain.xml

プレーン・テキスト・ユーザー名トークンによる一方向SSL。

Wssp1.2-2007-Https-UsernameToken-Plain-Basic256Sha256.xml

Wssp1.2-2007-Https-UsernameToken-Plain.xmlと同じですが、Sha-256のより強力なハッシュ・アルゴリズムを使用します。

Wssp1.2-Https.xml

一方向SSL。

Wssp1.2-Https-BasicAuth.xml

基本認証による一方向SSL。リクエストに認可ヘッダーが含まれていない場合は401チャレンジが発生します。

Wssp1.2-Https-UsernameToken-Digest.xml

ダイジェスト・ユーザー名トークンによる一方向SSL。

Wssp1.2-Https-UsernameToken-Plain.xml

プレーン・テキスト・ユーザー名トークンによる一方向SSL。

Wssp1.2-Https-ClientCertReq.xml

双方向SSL。受信側で、発信元のパブリック証明書をチェックします。認証にクライアント証明書を使用することも可能です。

保護アサーション・ポリシー

保護アサーションは、保護の対象とレベルを特定するために使用します。保護アサーション・ポリシーは単独では使用できず、X.509トークン・ポリシーと組み合せることによってのみ使用できます。たとえば、Wssp1.2-2007-Wss1.1-X509-Basic256.xmlとWssp1.2-2007-SignBody.xmlを組み合せて使用します。以下のポリシー・ファイルは、署名および暗号化によって、メッセージ部分の保護を提供します。

表2-7 保護アサーション・ポリシー

ポリシー・ファイル

説明

Wssp1.2-2007-SignBody.xml

すべてのメッセージ本文部分が署名されます。

Wssp1.2-2007-EncryptBody.xml

すべてのメッセージ本文部分が暗号化されます。

Wssp1.2-2007-Sign-Wsa-Headers.xml

WS-Addressingヘッダーが署名されます。

Wssp1.2-SignBody.xml

すべてのメッセージ本文部分が署名されます。

Wssp1.2-EncryptBody.xml

すべてのメッセージ本文部分が暗号化されます。

Wssp1.2-Sign-Wsa-Headers.xml

WS-Addressingヘッダーが署名されます。

Wssp1.2-2007-SignAndEncryptWSATHeaders.xml

WS-AtomicTransactionヘッダーが署名および暗号化されます。

Wssp1.2-2007-Wsp1.5-SignAndEncryptWSATHeaders.xml

WS-AtomicTransactionヘッダーが署名および暗号化されます。Web Services Policy 1.5が使用されます。

WS-Security 1.0のユーザー名およびX509トークン・ポリシー

次のポリシーは、WS-Security 1.0のユーザー名トークン仕様またはX.509トークン仕様をサポートしています。

表2-8 WS-Security 1.0ポリシー

ポリシー・ファイル

説明

Wssp1.2-2007-Wss1.0-X509-Basic256.xml

X.509証明書による相互認証。メッセージは、リクエスト側とレスポンス側の両方で署名および暗号化されます。アルゴリズムとしては、両側でBasic256を使用する必要があります。

Wssp1.2-2007-Wss1.0-UsernameToken-Digest-X509-Basic256.xml

認証のリクエストでは、ユーザー名トークンとパスワード・ダイジェストが送信されます。暗号化方式はBasic256です。

Wssp1.2-2007-Wss1.0-UsernameToken-Plain-X509-Basic256.xml

認証のリクエストでは、ユーザー名トークンとプレーン・テキスト・パスワードが送信されます。これらは、クライアントの秘密鍵で署名され、サーバーの公開鍵で暗号化されます。クライアントは、リクエストの本文にも署名し、メッセージ内の署名によって保護されたパブリック証明書を含めます。サーバーは、その秘密鍵でレスポンスの本文に署名し、そのパブリック証明書をメッセージの一部として送信します。リクエスト・メッセージとレスポンス・メッセージの両方に、署名されたタイム・スタンプが含まれます。暗号化方式はBasic256です。

Wssp1.2-Wss1.0-UsernameToken-Plain-X509-Basic256.xml

認証のリクエストでは、ユーザー名トークンとプレーン・テキスト・パスワードが送信されます。これらは、クライアントの秘密鍵で署名され、サーバーの公開鍵で暗号化されます。クライアントは、リクエストの本文にも署名し、メッセージ内の署名によって保護されたパブリック証明書を含めます。サーバーは、その秘密鍵でレスポンスの本文に署名し、そのパブリック証明書をメッセージの一部として送信します。リクエスト・メッセージとレスポンス・メッセージの両方に、署名されたタイム・スタンプが含まれます。暗号化方式はBasic256です。

Wssp1.2-Wss1.0-UsernameToken-Plain-X509-TripleDesRsa15.xml

認証のリクエストでは、ユーザー名トークンとプレーン・テキスト・パスワードが送信されます。これらは、クライアントの秘密鍵で署名され、サーバーの公開鍵で暗号化されます。クライアントは、リクエストの本文にも署名し、メッセージ内の署名によって保護されたパブリック証明書を含めます。サーバーは、その秘密鍵でレスポンスの本文に署名し、そのパブリック証明書をメッセージの一部として送信します。リクエスト・メッセージとレスポンス・メッセージの両方に、署名されたタイム・スタンプが含まれます。暗号化方式はTripleDesです。

Wssp1.2-Wss1.0-UsernameToken-Digest-X509-Basic256.xml

認証のリクエストでは、ユーザー名トークンとパスワード・ダイジェストが送信されます。暗号化方式はBasic256です。

Wssp1.2-Wss1.0-UsernameToken-Digest-X509-TripleDesRsa15.xml

認証のリクエストでは、ユーザー名トークンとパスワード・ダイジェストが送信されます。暗号化方式はTripleDesです。

Wssp1.2-Wss1.0-X509-Basic256.xml

X.509証明書による相互認証。メッセージは、リクエスト側とレスポンス側の両方で署名および暗号化されます。アルゴリズムとしては、両側でBasic256を使用する必要があります。

Wssp1.2-Wss1.0-X509-TripleDesRsa15.xml

X.509証明書による相互認証。メッセージは、リクエスト側とレスポンス側の両方で署名および暗号化されます。アルゴリズムとしては、両側でTripleDesを使用する必要があります

Wssp1.2-Wss1.0-X509-EncryptRequest-SignResponse.xml

このポリシーは、X.509v3証明書(および公開鍵/秘密鍵の組合せ)を保持するサーバーでのみ使用します。リクエストが暗号化され、レスポンスが署名されます。

WS-Security 1.1のユーザー名およびX509トークン・ポリシー

次のポリシーは、WS-Security 1.1のユーザー名トークン仕様またはX.509トークン仕様をサポートしています。

表2-9 WS-Security 1.1のユーザー名およびX509トークン・ポリシー

ポリシー・ファイル

説明

Wssp1.2-2007-Wss1.1-X509-Basic256.xml

非対称バインディングによるWSS 1.1 X509。

Wssp1.2-2007-Wss1.1-X509-Basic256Sha256.xml

Wssp1.2-2007-Wss1.1-X509-Basic256.xmlと同じですが、Sha-256の強力ハッシュ・アルゴリズムを使用します。

Wssp1.2-2007-Wss1.1-UsernameToken-Digest-X509-Basic256.xml

非対称バインディングによるWSS 1.1 X509、およびダイジェスト・ユーザー名トークンによる認証。

Wssp1.2-2007-Wss1.1-UsernameToken-Plain-X509-Basic256.xml

非対称バインディングによるWSS 1.1 X509、およびプレーン・テキスト・ユーザー名トークンによる認証。

Wssp1.2-2007-Wss1.1-UsernameToken-Plain-X509-Basic256Sha256.xml

Wssp1.2-2007-Wss1.1-UsernameToken-Plain-X509-Basic256.xmlと同じですが、Sha-256の強力ハッシュ・アルゴリズムを使用します。

Wssp1.2-2007-Wss1.1-EncryptedKey-X509-SignedEndorsing.xml

対称バインディングによるWSS 1.1 X509。トークンをサポートする署名付き承認によって保護されます。

Wssp1.2-2007-Wss1.1-UsernameToken-Digest-EncryptedKey.xml

対称バインディングによるWSS 1.1 X509、およびダイジェスト・ユーザー名トークンによる認証。

Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey.xml

対称バインディングによるWSS 1.1 X509、およびプレーン・テキスト・ユーザー名トークンによる認証。

Wssp1.2-2007-Wss1.1-DK-X509-SignedEndorsing.xml

派生キー対称バインディングによるWSS 1.1 X509。トークンをサポートする署名付き承認によって保護されます。

Wssp1.2-2007-Wss1.1-UsernameToken-Digest-DK.xml

派生キー対称バインディングによるWSS 1.1 X509、およびダイジェスト・ユーザー名トークンによる認証。

Wssp1.2-2007-Wss1.1-UsernameToken-Plain-DK.xml

派生キー対称バインディングによるWSS 1.1 X509、およびプレーン・テキスト・ユーザー名トークンによる認証。

Wssp1.2-Wss1.1-X509-Basic256.xml

このポリシーは、署名確認、指紋キー参照といったWS-Security 1.1の追加機能を使用する点以外はWssp1.2-Wss1.0-X509-Basic256.xmlポリシーと同様です。

Wssp1.2-Wss1.1-EncryptedKey.xml

署名と暗号化の両方でWS-Security 1.1の暗号化キー機能を使用する対称バインディング・ポリシー。署名確認、指紋キー参照などのWS-Security 1.1機能も使用します。

Wssp1.2-Wss1.1-UsernameToken-DK.xml

派生キー対称バインディングによるWSS 1.1 X509、およびプレーン・テキスト・ユーザー名トークンによる認証。

Wssp1.2-Wss1.1-EncryptedKey-X509-SignedEndorsing.xml

このポリシーは、Wssp1.2-Wss1.1-EncryptedKey.xmlポリシーで定義されているすべての機能を備えるだけでなく、送信側のキーを使用してメッセージ署名を承認します。承認キーも、メッセージ署名で署名されます。

Wssp1.2-Wss1.1-DK.xml

このポリシーは、Wssp1.2-Wss1.1-EncryptedKey.xmlポリシーで定義されているすべての機能を備えているが、暗号化キーは使用しません。代わりに、リクエストをDerivedKeyToken1で署名し、DerivedKeyToken2で暗号化します。また、レスポンスをDerivedKeyToken3で署名し、DerivedKeyToken4で暗号化します。

Wssp1.2-Wss1.1-DK-X509-Endorsing.xml

このポリシーは、Wssp1.2-Wss1.1-DK.xmlポリシーで定義されているすべての機能を備えるだけでなく、送信側のキーを使用してメッセージ署名を承認します。

Wssp1.2-Wss1.1-X509-EncryptRequest-SignResponse.xml

このポリシーは、署名確認、指紋キー参照といったWSS 1.1の追加機能を使用する点以外はWssp1.2-Wss1.0-X509-EncryptRequest-SignResponse.xmlポリシーと同様です。

Wssp1.2-Wss1.1-X509-SignRequest-EncryptResponse.xml

このポリシーは、Wssp1.2-Wss1.1-X509-EncryptRequest-SignResponse.xmlポリシーの反対で、リクエストが署名され、レスポンスが暗号化されます。

Wssp1.2-wss11_x509_token_with_message_protection_owsm_policy.xml

このポリシーでは、送信側のX509証明書によって承認が行われ、メッセージの署名は保護されます。Basic256アルゴリズム・スイート(暗号化にはAES256)ではなく、Basic128アルゴリズム・スイート(AES128)を使用する必要があります。

WS-SecureConversationポリシー

表2-10に示すポリシーは、WS-SecureConversation 1.3、1.4およびWS-SecureConversation 2005/2を実装しています。

注意:

『Oracle WebLogic Server JAX-WS Webサービスの開発』に記載されているように、テンプレートを使用してドメインを構成する場合には、WS-SecureConversationを使用するJAX-WS WebサービスでJAX-WS拡張テンプレート(wls_webservice_jaxws)が必要になります。

WebサービスにWS-SecureConversationポリシーを指定する場合、ポリシーの指定はクラス・レベルで行う必要があります。

表2-10 WS-SecureConversationポリシー

ポリシー・ファイル

説明

Wssp1.2-2007-Wssc1.3-Bootstrap-Https-BasicAuth.xml

基本認証による一方向SSL。タイムスタンプが含まれます。アルゴリズム・スイートはBasic256です。署名は暗号化されます。

Wssp1.2-2007-Wssc1.3-Bootstrap-Https-ClientCertReq.xml

双方向SSL。受信側で、発信元のパブリック証明書をチェックします。認証にクライアント証明書を使用することも可能です。

Wssp1.2-2007-Wssc1.3-Bootstrap-Https-UNT.xml

SSLユーザー名トークン認証。

Wssp1.2-2007-Wssc1.3-Bootstrap-Https.xml

WS-SecureConversationハンドシェイク(RequestSecurityTokenおよびRequestSecurityTokenResponseCollectionメッセージ)がhttpsトランスポートで発生します。アプリケーション・メッセージは、DerivedKeyで署名および暗号化されます。署名も暗号化されます。

Wssp1.2-2007-Wssc1.3-Bootstrap-Wss1.0.xml

WS-SecureConversationハンドシェイクがWS-Security 1.0によって保護されます。アプリケーション・メッセージは、DerivedKeyで署名および暗号化されます。RequestSecurityTokenおよびRequestSecurityTokenResponseCollectionメッセージのsoap:Bodyは署名および暗号化されます。WS-Addressingヘッダーは署名されます。タイムスタンプは、格納されて署名されます。署名は暗号化されます。アルゴリズム・スイートはBasic256です。

Wssp1.2-2007-Wssc1.3-Bootstrap-Wss1.1.xml

WS-SecureConversationハンドシェイクがWS-Security 1.1によって保護されます。アプリケーション・メッセージは、DerivedKeyで署名および暗号化されます。RequestSecurityTokenおよびRequestSecurityTokenResponseCollectionメッセージのsoap:Bodyは署名および暗号化されます。WS-Addressingヘッダーは署名されます。署名と暗号化には、暗号化キーからの派生キーが使用されます。

Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-UsernameToken-Plain-X509-Basic256.xml

Wssp1.2-2007-Wss1.0-UsernameToken-Plain-X509-Basic256.xm.ポリシーと同様に、WS-SecureConversationハンドシェイクは非対称バインディングのWS-Security 1.0 X509とプレーン・テキスト・ユーザー名トークンによる認証によって保護されます

ハンドシェイクのRequestSecurityTokenメッセージおよびRequestSecurityTokenResponseCollectionメッセージのSOAP本文は署名および暗号化されます。アプリケーション・メッセージは、セキュアな会話トークン暗号化キーから導出されたキーで署名および暗号化されます。WS-Addressingヘッダーは署名されます。ポリシーでは、WS-Policy 1.5ネームスペース「http://www.w3.org/ns/ws-policy」が使用されます。

Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-UsernameToken-Plain-X509-Basic256Sha256.xml

Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-UsernameToken-Plain-X509-Basic256.xmlと同じですが、Sha-256の強力ハッシュ・アルゴリズムを使用します。

Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-Saml1.1-SenderVouches.xml

Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xmlポリシーと同様に、WS-SecureConversationハンドシェイクは非対称バインディングのWS-Security 1.0 X509とSAML 1.1 Sender Vouchesトークンによる認証によって保護されます。

ハンドシェイクのRequestSecurityTokenメッセージおよびRequestSecurityTokenResponseCollectionメッセージのSOAP本文は署名および暗号化されます。アプリケーション・メッセージは、セキュアな会話トークン暗号化キーから導出されたキーで署名および暗号化されます。WS-Addressingヘッダーは署名されます。ポリシーでは、WS-Policy 1.5ネームスペース「http://www.w3.org/ns/ws-policy」が使用されます。

Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.1-Saml1.1-SenderVouches.xml

Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.1.xmlポリシーと同様に、WS-SecureConversationハンドシェイクは非対称バインディングのWS-Security 1.1 X509とSAML 1.1 Sender Vouchesトークンによる認証によって保護されます。

ハンドシェイクのRequestSecurityTokenメッセージおよびRequestSecurityTokenResponseCollectionメッセージのSOAP本文は署名および暗号化されます。アプリケーション・メッセージは、セキュアな会話トークン暗号化キーから導出されたキーで署名および暗号化されます。WS-Addressingヘッダーは署名されます。ポリシーでは、WS-Policy 1.5ネームスペース「http://www.w3.org/ns/ws-policy」が使用されます。

Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.1-Saml2.0-Bearer.xml

WS-SecureConversationハンドシェイクは非対称バインディングのWS-Security 1.1 X509とSAML 2.0 Bearerトークンによる認証によって保護されます。

ハンドシェイクのRequestSecurityTokenメッセージおよびRequestSecurityTokenResponseCollectionメッセージのSOAP本文は署名および暗号化されます。アプリケーション・メッセージは、セキュアな会話トークン暗号化キーから導出されたキーで署名および暗号化されます。WS-Addressingヘッダーは署名されます。ポリシーでは、WS-Policy 1.5ネームスペース「http://www.w3.org/ns/ws-policy」が使用されます。

Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.1-UsernameToken-Plain-EncryptedKey.xml

Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey.xmlポリシーと同様に、WS-SecureConversationハンドシェイクは非対称バインディングのWS-Security 1.1 X509とプレーン・テキスト・ユーザー名トークンによる認証によって保護されます。

ハンドシェイクのRequestSecurityTokenメッセージおよびRequestSecurityTokenResponseCollectionメッセージのSOAP本文は署名および暗号化されます。アプリケーション・メッセージは、セキュアな会話トークン暗号化キーから導出されたキーで署名および暗号化されます。WS-Addressingヘッダーは署名されます。ポリシーでは、WS-Policy 1.5ネームスペース「http://www.w3.org/ns/ws-policy」が使用されます。

Wssp1.2-Wssc1.3-Bootstrap-Https-BasicAuth.xml

基本認証による一方向SSL。タイムスタンプが含まれます。アルゴリズム・スイートはBasic256です。署名は暗号化されます。

Wssp1.2-Wssc1.3-Bootstrap-Https-ClientCertReq.xml

双方向SSL。受信側で、発信元のパブリック証明書をチェックします。認証にクライアント証明書を使用することも可能です。

Wssp1.2-Wssc1.3-Bootstrap-Https.xml

WS-SecureConversationハンドシェイク(RequestSecurityTokenおよびRequestSecurityTokenResponseCollectionメッセージ)がhttpsトランスポートで発生します。アプリケーション・メッセージは、DerivedKeyで署名および暗号化されます。署名も暗号化されます。

Wssp1.2-Wssc1.3-Bootstrap-Wss1.0.xml

WS-SecureConversationハンドシェイクがWS-Security 1.0によって保護されます。アプリケーション・メッセージは、DerivedKeyで署名および暗号化されます。RequestSecurityTokenおよびRequestSecurityTokenResponseCollectionメッセージのsoap:Bodyは署名および暗号化されます。WS-Addressingヘッダーは署名されます。タイムスタンプは、格納されて署名されます。署名は暗号化されます。アルゴリズム・スイートはBasic256です。

Wssp1.2-Wssc1.3-Bootstrap-Wss1.1.xml

WS-SecureConversationハンドシェイクがWS-Security 1.1によって保護されます。アプリケーション・メッセージは、DerivedKeyで署名および暗号化されます。RequestSecurityTokenおよびRequestSecurityTokenResponseCollectionメッセージのsoap:Bodyは署名および暗号化されます。WS-Addressingヘッダーは署名されます。署名と暗号化には、暗号化キーからの派生キーが使用されます。

Wssp1.2-Wssc200502-Bootstrap-Https.xml

WS-SecureConversationハンドシェイク(RequestSecurityTokenおよびRequestSecurityTokenResponseメッセージ)がhttpsトランスポートで発生します。アプリケーション・メッセージは、DerivedKeyで署名および暗号化されます。

Wssp1.2-Wssc200502-Bootstrap-Wss1.0.xml

WS-SecureConversationハンドシェイクがWS-Security 1.0によって保護されます。アプリケーション・メッセージは、DerivedKeyで署名および暗号化されます。RequestSecurityTokenおよびRequestSecurityTokenResponseメッセージのsoap:Bodyは署名および暗号化されます。WS-Addressingヘッダーは署名されます。タイムスタンプは、格納されて署名されます。アルゴリズム・スイートはBasic128です。

Wssp1.2-Wssc200502-Bootstrap-Wss1.1.xml

WS-SecureConversationハンドシェイクがWS-Security 1.1によって保護されます。アプリケーション・メッセージは、DerivedKeyで署名および暗号化されます。RequestSecurityTokenおよびRequestSecurityTokenResponseメッセージのsoap:Bodyは署名および暗号化されます。WS-Addressingヘッダーは署名されます。署名と暗号化には、暗号化キーからの派生キーが使用されます。

SAML Token Profileポリシー

表2-1に示すポリシーは、WS-Security SAML Token Profile 1.0および1.1を実装しています。

注意:

WebLogic Serverバージョン10.3は受信リクエストに対してのみSAML Holder of keyをサポートしていました。WebLogic Serverバージョン10.3MP1以降現在、リクエストとレスポンス・メッセージの両方が保護されます。

表2-11 WS-Security SAML Token Profileポリシー

ポリシー・ファイル

説明

Wssp1.2-2007-Saml1.1-Bearer-Https.xml

一方向SSLでは、SAML 1.1トークンを使用し、Bearer確認メソッドによって認証を行います。

WebLogic Serverは、Wssp1.2-2007-Saml2.0-Bearer-Https.xmlを使用して、トランスポート・レベルでのSAML 1.1 Bearer確認メソッドをサポートします。

Webサービスにトランスポート・レベルのセキュリティ・ポリシーを指定する場合、ポリシーの指定はクラス・レベルで行う必要があります。また、トランスポート・レベルのセキュリティ・ポリシーは着信方向と発信方向の両方に適用する必要があります。つまり、着信にHTTPSを使用し、発信にHTTPを使用することはできません。

Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xml

メッセージは、WSS1.0非対称バインディングによりリクエスト側とレスポンス側の両方で署名および暗号化されます。SAML 1.1トークンはSender Vouches確認メソッドによる認証用にリクエスト内で送信され、X509トークンにより署名されます。

Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.1.xml

メッセージは、WSS1.1 X509対称バインディングによりリクエスト側とレスポンス側の両方で署名および暗号化されます。SAML 1.1トークンはSender Vouches確認メソッドによる認証用にリクエスト内で送信され、X509トークンにより署名されます。

Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.1-Basic256Sha256.xml

Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.1.xmlと同じですが、Sha-256の強力ハッシュ・アルゴリズムを使用します。

Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1.xml

メッセージは、WSS1.1 X509対称バインディングによりリクエスト側とレスポンス側の両方で署名および暗号化されます。SAML 2.0トークンはSender Vouches確認メソッドによる認証用にリクエスト内で送信され、X509トークンにより署名されます。

Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1-Basic256Sha256.xml

Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1.xmlと同じですが、Sha-256の強力ハッシュ・アルゴリズムを使用します。

Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1-Asymmetric.xml

メッセージは、WSS1.1非対称バインディングによりリクエスト側とレスポンス側の両方で署名および暗号化されます。署名確認、指紋キー参照などの追加のWS-Security 1.1機能も使用します。SAML 2.0トークンはSender Vouches確認メソッドによる認証用にリクエスト内で送信され、X509トークンにより署名されます。

Wssp1.2-2007-Saml1.1-HolderOfKey-Wss1.0.xml

メッセージは、WSS1.0非対称バインディングによりリクエスト側とレスポンス側の両方で署名および暗号化されます。SAML 1.1トークンはHolder of Key確認メソッドによる認証用にリクエスト内で送信されます。SAMLトークン内のキーが署名に使用されます。

Wssp1.2-2007-Saml1.1-HolderOfKey-Wss1.1-Asymmetric.xml

メッセージは、WSS1.1非対称バインディングによりリクエスト側とレスポンス側の両方で署名および暗号化されます。署名確認、指紋キー参照などの追加のWS-Security 1.1機能も使用します。SAML 1.1トークンはHolder of Key確認メソッドによる認証用にリクエスト内で送信されます。SAMLトークン内のキーが署名に使用されます。

Wssp1.2-2007-Saml2.0-HolderOfKey-Wss1.1-Asymmetric.xml

メッセージは、WSS1.1非対称バインディングによりリクエスト側とレスポンス側の両方で署名および暗号化されます。署名確認、指紋キー参照などの追加のWS-Security 1.1機能も使用します。SAML 2.0トークンはHolder of Key確認メソッドによる認証用にリクエスト内で送信されます。SAMLトークン内のキーが署名に使用されます。

Wssp1.2-2007-Saml2.0-Bearer-Https.xml

一方向SSLは、認証用にBearer確認メソッドがあるSAML 2.0トークンを使用します。

WebLogic Serverは、Wssp1.2-2007-Saml2.0-Bearer-Https.xmlを使用して、トランスポート・レベルでSAML 2.0 Bearer確認メソッドをサポートします。

SAML 2.0をサポートしない他の製品と相互運用するために、SAML-over-HTTPSシナリオについてはsender-vouches確認メソッドの使用をお薦めします。

SAML1.1 Bearerを使用するかわりに Wssp1.2-2007-Saml1.1-SenderVouches-Https.xmlポリシーを使用してください。

Webサービスにトランスポート・レベルのセキュリティ・ポリシーを指定する場合、ポリシーの指定はクラス・レベルで行う必要があります。また、トランスポート・レベルのセキュリティ・ポリシーは着信方向と発信方向の両方に適用する必要があります。つまり、着信にHTTPSを使用し、発信にHTTPを使用することはできません。

Wssp1.2-2007-Saml2.0-Bearer-Https-Basic256Sha256.xml

Wssp1.2-2007-Saml2.0-Bearer-Https.xmlと同じですが、Sha-256のより強力なハッシュ・アルゴリズムを使用します。

Wssp1.2-wss11_saml_token_with_message_protection_owsm_policy.xml

このポリシーでは、送信側のX509証明書によって承認が行われ、メッセージの署名は保護されます。Basic256アルゴリズム・スイート(暗号化にはAES256)ではなく、Basic128アルゴリズム・スイート(AES128)を使用する必要があります。

ポリシーの選択

WebLogic Serverは、WS-SecurityPolicy 1.2を実装したことで、セキュリティ・ポリシーの幅広い選択肢を提供できるようになりました。Webサービスのセキュリティ・ポリシーを選択する際は、次の面での要件を考慮する必要があります。

- パフォーマンス

- セキュリティ

- 相互運用性

- 資格証明可用性(X.509証明書、ユーザー名トークン、クリア・パスワードまたはダイジェスト・パスワード)

可能なかぎり、次のガイドラインに従ってください。

- カスタム・ポリシーを作成せず、WebLogic Serverにパッケージ化されたポリシーを使用します。

- WS-SecurityPolicy 1.2ポリシーでまだサポートされていない機能が必要な場合を除き、WebLogic Server 9.xスタイルのポリシーではなくWS-SecurityPolicy 1.2ポリシーを使用します。

- トランスポート・レベルのポリシー(Wssp1.2-2007-Https-*.xml)は、メッセージ・レベルのセキュリティが必要ない場所にのみ使用します。

- 仕様との相互運用性を確保する必要がある場合はWS-Security 1.0ポリシーを使用します。認証要件および資格証明可用性に応じて、以下のいずれかを使用してください。

- Wssp1.2-2007-Wss1.0-UsernameToken-Plain-X509-Basic256.xml

- Wssp1.2-2007-Wss1.0-UsernameToken-Digest-X509-Basic256.xml

- Wssp1.2-2007-Wss1.0-X509-Basic256.xml

- 強固なセキュリティの要件を満たす必要がある場合はWS-Security 1.1ポリシーを使用します。以下のいずれかを使用してください。

- Wssp1.2-2007-Wss1.1-EncryptedKey-X509-SignedEndorsing.xml

- Wssp1.2-2007-Wss1.1-DK-X509-SignedEndorsing.xml

- Wssp1.2-Wss1.1-EncryptedKey-X509-SignedEndorsing.xml

- Wssp1.2-Wss1.1-DK-X509-Endorsing.xml

- WS-ReliableMessagingに加えてセキュリティが必要な場合はWS-SecureConversationポリシーを使用します。

- Wssp1.2-2007-Wssc1.3-Bootstrap-Wss1.0.xml

- Wssp1.2-2007-Wssc1.3-Bootstrap-Wss1.1.xml

- Wssp1.2-Wssc1.3-Bootstrap-Wss1.0.xml

- Wssp1.2-Wssc1.3-Bootstrap-Wss1.1.xml

- Wssp1.2-Wssc200502-Bootstrap-Wss1.0.xml

- Wssp1.2-Wssc200502-Bootstrap-Wss1.1.xml

サポートされないWS-SecurityPolicy 1.2アサーション

表2-1でのWS-SecurityPolicy 1.2アサーションはWebLogic Serverのこのリリースではサポートされません。

注意:

新しいWS-SecurityPolicy1.3アサーションもこのリリースではサポートされません。

表2-12 サポートされないWeb Services SecurityPolicy 1.2アサーション

仕様

アサーション

備考

5.1.1

TokenInclusion

includeTokenPolicy=Onceはサポートされません。

5.4.1

UsernameToken

このリリースでは<sp:UsernameToken11>とパスワード派生キーのみがサポートされていません。その他のユーザー名トークン・アサーションはサポートされます。

5.4.2

IssuedToken

WS-Trustポリシー・アサーションはこのリリースではサポートされません。

5.4.4

KerberosToken

このリリースではサポートされません。

5.4.5

SpnegoContextToken

このリリースではサポートされません。

5.4.9

RelToken

このリリースではサポートされません。

5.4.11

KeyValueToken

このリリースではサポートされません。

6.5

トークン保護

includeTokenPolicy="Never"の場合や、メッセージにトークンが含まれていない場合、このリリースではトークン保護はサポートされません。

7.1

AlgorithmSuite

このリリースでは/sp:AlgorithmSuite/wsp:Policy/sp:XPathFilter20アサーション、/sp:AlgorithmSuite/wsp:Policy/sp:XPath10アサーション、および/sp:AlgorithmSuite/wsp:Policy/sp:SoapNormalization10はサポートされません。

8.1

SupportingTokens

このリリースでは以下はサポートされません。

../sp:SignedPartsアサーション、../sp:SignedElementsアサーション、../sp:EncryptedPartsアサーション、../sp:EncryptedElementsアサーション

8.2

8.3

8.4

8.5

SignedSupportingTokens

EndorsingSupportingTokens

SignedEndorsingSupportingTokens

SignedEncryptedSupportingTokens

このリリースでは以下はサポートされません。

../sp:SignedPartsアサーション

../sp:SignedElementsアサーション

../sp:EncryptedPartsアサーション

../sp:EncryptedElementsアサーション

../sp:SignedEncryptedSupportingTokensアサーション

メッセージにトークンが含まれていない場合(たとえば、includeTokenPolicy=Never/Onceの場合)、ランタイムはサポートするトークンを承認できません。

8.6

EncryptedSupportingTokens

このリリースでサポートされるEncryptionSupportingTokensはUserNameトークンのみです。

その他のタイプのトークンはサポートされません。

8.7

EndorsingEncryptedSupportingTokens

このリリースではサポートされません。

8.8

SignedEndorsingEncryptedSupportingTokens

このリリースではサポートされません。

9.1

WSS10アサーション

<sp:MustSupportRefExternalURI>および<sp:MustSupportRefEmbeddedToken>はこのリリースではサポートされません。

9.2

WSS11アサーション

<sp:MustSupportRefExternalURI>および<sp:MustSupportRefEmbeddedToken>はこのリリースではサポートされません。

10.1

Trust13アサーション

MustSupportClientChallengeおよびMustSupportServerChallengeはこのリリースではサポートされません。このアサーションはWS-SecureConversationポリシーでのみサポートされます。

Optionalポリシー・アサーションの使用

WebLogic Serverは、Optional WS-Policyアサーションをサポートします。次の例でOptionalがどのように使用されているか考えてみましょう。

<sp:SignedEncryptedSupportingTokens>
<wsp:Policy>
<sp:UsernameToken
sp:IncludeToken="…/IncludeToken/AlwaysToRecipient" wsp:Optional="true" >
<wsp:Policy>
<sp:WssUsernameToken10/>
</wsp:Policy>
</sp:UsernameToken>
</wsp:Policy>
</sp:SignedEncryptedSupportingTokens>

この例では、認可を行うためのユーザー名トークンの指定はオプションです。ユーザーが匿名である、またはセキュリティ・コンテキストがないという理由でユーザー名トークンを生成できない場合でも、クライアントは処理を続行できます。

セキュリティ・ポリシーの適用プロセスにおいて、欠落した要素にwsp:Optional="true"属性を持つポリシー・アサーションが指定されていれば、メッセージは拒否されません。

現在、次のセキュリティ・ポリシー・アサーションがOptionalポリシー・アサーションでサポートされています。

- ユーザー名トークン

- SAMLトークン

- 署名部分または署名要素

- 暗号化部分または暗号化要素

- 派生キー・トークン

要素レベルのセキュリティの構成

WebLogic Serverでは、WS-SecurityPolicy 1.2で定義される要素レベルのアサーションがサポートされます。これらのアサーションを使用すると、SOAPリクエストまたはレスポンス・メッセージ内の選択した要素に署名または暗号化を適用することができます。また、セキュリティが必要なメッセージ内の特定のデータのみを対象にできるため、計算要件が緩和されます。

また、RequiredElementsアサーションを使用すると、メッセージに特定のヘッダー要素が必ず含まれるようになります。

次の要素レベルのアサーションを使用できます。

- EncryptedElements (http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826516)

- ContentEncryptedElements (http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826517)

- SignedElements (http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826513)

- RequiredElements (http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826518)

要素レベルのアサーションを指定するには、適用するリクエスト要素またはレスポンス要素を特定する必要があります。

これらの要素を特定するには、XPathバージョン1.0 (http://www.w3.org/TR/xpath)またはXPath Filterバージョン2.0 (http://www.w3.org/TR/xmldsig-filter2/)の構文を使用して、ポリシー・ファイルでXPath式を使用します。この項のサンプルでは、デフォルト構文のXPathバージョン1.0を使用しています。

これらの各アサーションではWebサービス・メッセージ内の1つまたは複数の要素を特定するため、すべての要素レベルのセキュリティ・アサーションに対するカスタム・セキュリティ・ポリシー・ファイルを使用する必要があります。通常、これらのカスタム・ポリシー・ファイルは、事前定義済のセキュリティ・ポリシー・ファイルと併用されます。事前定義済のファイルでは署名や暗号化の実行方法が定義され、カスタム・ポリシー・ファイルでは署名や暗号化の対象となる特定の要素が指定されます。

要素レベルのカスタム・ポリシー・ファイルの定義と使用

最初に、ターゲット要素を特定するXPath式を決定します。そのためには、Webサービスで使用されているSOAPメッセージの形式を、直接調べるかサービスのWSDLとXMLスキーマを分析することで理解する必要があります。

SOAPメッセージの形式を確認して必要なXPath式を決定する方法は、使用しているツールに大きく依存するため、このドキュメントの対象外です。たとえば、次のようなことを行います:

1. 要素レベルのセキュリティのないWebサービスを実行します。

2. SOAPのトレースを有効にします。

3. ログ内のSOAPメッセージを調べます。

4. そのSOAPメッセージをもとにXPath式を作成します。

または、特定のWSDLに対するサンプルSOAPリクエストを生成できるソフトウェア・ツールがある場合は、そのツールを使用してXPath式を生成します。

WebサービスのsubmitOrderRequest操作が例2-19に示す形式のSOAPリクエストを受け取る例について考えてみましょう。

太字の部分は後で要素レベルのカスタム・ポリシーを作成するときに使用されます。

例2-19 submitOrderRequest SOAPリクエスト

<env:Envelope
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header/>
<env:Body>
<ns1:submitOrderRequest
xmlns:ns1="http://www.oracle.com/OrderService">
<ns1:OrderRequest>
<ns1:orderNumber>4815162342</ns1:orderNumber>
<ns1:creditCard>
<ns1:cctype>MasterCard</ns1:cctype>
<ns1:expires>12-01-2020</ns1:expires>
<ns1:ccn>1234-567890-4444</ns1:ccn>
</ns1:creditCard>
</ns1:OrderRequest>
</ns1:submitOrderRequest>
</env:Body>
</env:Envelope>

<ns1:creditCard>要素とその子要素を暗号化する必要があると仮定します。そのためには、例2-19の太字の箇所から得られた情報を使用して、カスタム・セキュリティ・ポリシー・ファイル(EncryptCreditCard.xmlなど)を作成します。

例2-20に示す例について考えてみましょう。

例2-20 EncryptCreditCard.xmlカスタム・ポリシー・ファイル

<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512">
<sp:EncryptedElements xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<sp:XPath xmlns:myns="http://www.oracle.com/OrderService">
/soapenv:Envelope/soapenv:Body/myns:submitOrderRequest/myns:OrderRequest/myns:creditCard
</sp:XPath>
</sp:EncryptedElements>
</wsp:Policy>

WS-SecurityPolicy1.2仕様(http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826516)に記載されているように、/sp:EncryptedElements/sp:XPath要素にはXPath式を指定する文字列があり、この文字列によって機密性の保護の対象となるノードを特定します。XPath式はメッセージのS:Envelope要素ノードに対して評価されます。このアサーションには、この要素の複数のインスタンスが出現する可能性もありますが、それぞれを異なる参照として扱う必要があります。

次の点に注意してください。

- ルート要素は接頭辞(この場合はwsp)の付いた<wsp:Policy>にし、WS-Policyの完全なネームスペースにマッピングする必要があります。

- アサーション(この場合はEncryptedElements)は、spという接頭辞を付けて、WS-SecurityPolicy 1.2の完全なネームスペースで修飾する必要があります。

- SOAPメッセージのcreditCard要素はネームスペースで修飾され(ns1接頭辞を使用)、親要素OrderRequest、submitOrderRequest、Body、およびEnvelopeがあります。これらの各要素もネームスペースで修飾されています。
(/soapenv:Envelope…で始まる) XPath問合せはcreditCard要素の場所を一致させます。

/soapenv:Envelope/soapenv:Body/myns:submitOrderRequest/myns:OrderRequest/myns:creditCard

- SOAPメッセージのネームスペース接頭辞とカスタム・セキュリティ・ポリシー・ファイルの接頭辞が一致している必要はありません。重要なのは、接頭辞のマップ先の完全なネームスペースがメッセージとポリシー・アサーションで同一であることのみです。

- WebLogic ServerはSOAP 1.1とSOAP 1.2のネームスペース、WS-Addressing 2004/08とWS-Addressing 1.0のネームスペースのマッピングを処理します。

JWSファイルへのPolicyアノテーションの追加

カスタム・ポリシーを作成した後、ポリシー・アノテーションをJWSファイルに追加して、ElementEncryptionポリシーがsubmitOrder Webサービス・リクエストに対して使用されるようにします(例2-21を参照)。

例2-21 カスタム・ポリシー・ファイルへのポリシー・アノテーションの追加

@WebMethod
@Policies({
@Policy(uri="policy:Wssp1.2-2007-Wss1.1-UsernameToken-Plan-X509-Basic256.xml"),
@Policy(uri="../policies/EncryptCreditCard.xml",
direction=Policy.Direction.inbound)})

public String submitOrderRequest (OrderRequest orderRequest) {
return orderService.processOrder(orderRequest);
}

creditCard要素がレスポンスではなく、SOAPリクエストに存在しているので、コードの抜粋は単に「着信」の方向によるEncryptedElementsカスタム・ポリシーを構成します。

ユーザーが作成したポリシー・ファイルを指定するには、次の例に示すように、JWSファイルの場所を基準とした相対パスと名前を指定します。

@Policy(uri="../policies/MyPolicy.xml")

この例では、MyPolicy.xmlファイルは、JWSファイルを格納するディレクトリのpolicies兄弟ディレクトリにあります。

共有Java EEライブラリにあるポリシー・ファイルも指定できます。この方法は、別々のJava EEアーカイブにパッケージ化された複数のWebサービス間でファイルを共有する場合に便利です。

注意:

この場合、ポリシー・ファイルが共有Java EEライブラリのMETA-INF/policiesディレクトリまたはWEB-INF/policiesディレクトリにあることを前提としています。ライブラリをパッケージ化する際には、必ずこのディレクトリにポリシー・ファイルを入れてください。

共有Java EEライブラリにあるポリシー・ファイルを指定するには、次の例に示すように、policy接頭辞とポリシー・ファイルの名前を使用します。

@Policy(uri="policy:MySharedPolicy.xml")

共有ライブラリの作成、およびWebサービスが共有のポリシー・ファイルを見つけられるようにするための環境設定については、『Oracle WebLogic Serverアプリケーションの開発』の共有Java EEライブラリおよびオプション・パッケージの作成に関する項を参照してください。

実装に関する注意

要素レベルのセキュリティを実装するときは次の点に注意してください。

- 1つのポリシーの中に複数の要素レベルのアサーションを含めることができます。すべてのアサーションが実行されます。

- 1つのアサーションの中に複数の<sp:XPath>式を含めることができます。すべてのアサーションが実行されます。

- EncryptedElementsアサーションでは、特定された要素とその子要素がすべて暗号化されます。

- ContentEncryptedElementsアサーションでは、特定された要素は暗号化されないが、その子要素はすべて暗号化されます。

- RequiredElementsアサーションを使用すると、SOAPヘッダーの最上位要素の存在をテストできます。その要素が見つからない場合はSOAP Faultが生成されます。
RequiredElementsアサーションはSOAP本文内の要素のテストには使用できません。

適切なポリシーの選択

特定のWebサービスに対して複数のポリシー選択肢を用意することができます。これにより、サービスの柔軟性が大幅に向上します。

Webサービスで次のいずれかをサポートするかどうか検討してください。

- 様々なバージョンの標準。たとえば、1つのWebサービスでWSRM 1.0とWSRM 1.1、WSS1.0とWSS 1.1、WSSC 1.1とWWSSC 1.2、SAML 1.1またはSAML 2.0に対応可能です。

- 認証用の様々な資格証明。たとえば、Webサービスで認証用にユーザー名トークン、X509、またはSAMLトークンの使用を許可します。

- 内部のクライアントと外部のクライアントで異なるセキュリティ要件。たとえば、外部の認証にはSAMLトークンを要求し、内部の従業員の認証にはユーザー名トークンのみを要求することができます。

Webサービス・クライアントでも複数のポリシー選択肢に対応できます。同じクライアントが多様なポリシーやポリシー選択肢を持つ複数のサービスとやり取りできます。

たとえば、同じクライアントが、SAML 1.1 Token Profile 1.0による認証が必要なサービスとやり取りする一方で、SAML 2.0 Token Profile 1.1による認証が必要な別のサービスともやり取りできます。

ポリシー選択肢を含むセキュリティ・ポリシーの例

例2-22は、WS-Security 1.0とWS-Security 1.1の両方をサポートするセキュリティ・ポリシーの例です。

注意:

<wsp:ExactlyOne>要素の中で、各ポリシー選択肢が<wsp:All>要素内にカプセル化されています。

例2-22 複数の選択肢を定義するポリシー

<?xml version="1.0"?>
<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512">
<wsp:ExactlyOne>
<wsp:All>
<sp:AsymmetricBinding>
<wsp:Policy>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:InitiatorToken>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Never">
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Lax/>
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp/>
<sp:ProtectTokens/>
<sp:OnlySignEntireHeadersAndBody/>
</wsp:Policy>
</sp:AsymmetricBinding>
<sp:SignedParts>
<sp:Body/>
</sp:SignedParts>
<sp:Wss10>
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier/>
<sp:MustSupportRefIssuerSerial/>
</wsp:Policy>
</sp:Wss10>
</wsp:All>
<wsp:All>
<sp:AsymmetricBinding>
<wsp:Policy>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:RequireThumbprintReference/>
<sp:WssX509V3Token11/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:InitiatorToken>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Never">
<wsp:Policy>
<sp:RequireThumbprintReference/>
<sp:WssX509V3Token11/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Lax/>
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp/>
<sp:ProtectTokens/>
<sp:OnlySignEntireHeadersAndBody/>
</wsp:Policy>
</sp:AsymmetricBinding>
<sp:SignedParts>
<sp:Body/>
</sp:SignedParts>
<sp:Wss11>
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier/>
<sp:MustSupportRefIssuerSerial/>
<sp:MustSupportRefThumbprint/>
<sp:MustSupportRefEncryptedKey/>
<sp:RequireSignatureConfirmation/>
</wsp:Policy>
</sp:Wss11>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>

適切なポリシー選択の構成

例2-22に示すように、カスタム・ポリシーの作成により、1つのWebサービスに対して複数のポリシー選択肢を構成できます。また、ポリシー選択プリファレンスを決定するためにWebサービス・クライアントを構成します。

このリリースのWebLogic Serverでは、WebLogic Server管理コンソールでスタブを使用して、Webサービス・クライアントに対するポリシー選択プリファレンスを構成できます。

次のプリファレンスがサポートされています。

- セキュリティ

- パフォーマンス

- 互換性

ポリシー・プリファレンスの決定の仕組み

Webサービス・ランタイムでは、ポリシー選択プリファレンスを使用してポリシー選択肢を調べ、最適なものを選択します。

複数のポリシー選択肢がある場合は、構成済のプリファレンス・リスト、使用可能な資格証明、オプション機能の設定を使用して、最適なポリシーが選択されます。

1つのクライアントに対して複数のポリシー選択肢が存在する場合は、次の選択ルールが使用されます。

- プリファレンスが設定されていない場合は、ポリシー選択肢がwsp:optional=trueと定義されている場合を除いて、最初のポリシー選択肢が選択されます。

- プリファレンスがセキュリティ優先に設定されている場合は、最大のセキュリティ機能を持つポリシーが選択されます。

- プリファレンスが互換性/相互運用性優先に設定されている場合は、バージョンが最小のポリシーが選択されます。

- プリファレンスがパフォーマンス優先に設定されている場合は、最小のセキュリティ機能を持つポリシーが選択されます。

オプションのポリシー・アサーションでは、次の選択ルールが使用されます。

- デフォルトのポリシー選択プリファレンスが設定されている場合は、アサーションのオプション属性は無視されます。

- プリファレンスが互換性またはパフォーマンスに設定されている場合は、オプション属性を持つアサーションは無視されるため、そのアサーションは無視されます。

- セキュリティ・ポリシーの選択プリファレンスが設定されている場合、オプションのアサーションが含まれ、選択肢のアサーションは生成されません。

コンソールでの適切なポリシー選択の構成

管理コンソールで適切なポリシー選択を構成するには、次の手順に従います。

1. 機能するWebサービス・セキュリティ構成がまだない場合は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの説明に従って、Webサービス・セキュリティ構成を作成します。

2. Webサービス・セキュリティ構成を編集します。「全般」タブでポリシー選択プリファレンスを設定します。次の値がサポートされています。

- 「なし」 (デフォルト)

- セキュリティ、互換性、パフォーマンスの順 (SCP)

- セキュリティ、パフォーマンス、互換性の順 (SPC)

- 互換性、セキュリティ、パフォーマンスの順 (CSP)

- 互換性、パフォーマンス、セキュリティの順 (CPS)

- パフォーマンス、互換性、セキュリティの順 (PCS)

- パフォーマンス、セキュリティ、互換性の順 (PSC)

3. 変更を保存してアクティブ化します。

適切なポリシーにおける本文の暗号化の理解

適切なポリシー選択のシナリオにおいて、本文が暗号化される(<sp:EncryptedParts> <sp:Body /></sp:EncryptedParts>など)かどうかは、ポリシー選択プリファレンスのルールによって次のように異なります。

- デフォルト -- 最初のポリシー選択肢が決定に使用されます。最初のポリシー選択肢に本文暗号化のアサーションが含まれている場合、本文は暗号化されます。最初のポリシー選択肢に本文暗号化のアサーションが含まれていない場合、本文は暗号化されません。

- SCP、SPC -- 暗号化されます

- PCS、PSC -- 暗号化されません

- CPS -- 暗号化されません

- CSP -- 暗号化されます

次の2つの例について考えます。例2-23では、最初のポリシー選択肢に本文暗号化のアサーションが含まれています。したがって、デフォルトのプリファレンスの場合、本文は暗号化されます。デフォルト以外のポリシー選択プリファレンスの場合は、他のプリファレンス・ルールが適用されます。

例2-23 最初のポリシー選択肢に含まれる本文のアサーション

<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
>
<wsp:ExactlyOne>
<sp:EncryptedParts>
<sp:Body/>
</sp:EncryptedParts>
<sp:EncryptedParts/>
</wsp:ExactlyOne>
</wsp:Policy>

一方、例2-24では、最初のポリシー選択肢に本文暗号化のアサーションが含まれていません。したがって、デフォルトのプリファレンスの場合、本文は暗号化されません。デフォルト以外のポリシー選択プリファレンスの場合は、他のプリファレンス・ルールが適用されます。

例2-24 最初のポリシー選択肢に含まれない本文のアサーション

<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
>
<wsp:ExactlyOne>
<sp:EncryptedParts/>
<sp:EncryptedParts>
<sp:Body/>
</sp:EncryptedParts>
</wsp:ExactlyOne>
</wsp:Policy>

スタンドアロン・クライアントの適切なポリシーの選択

スタブ・プロパティを通じてポリシー選択プリファレンスを設定できます。

次の例では、JAX-RPCのスタブ・プロパティに「セキュリティ、互換性、パフォーマンスの順」の優先順位を設定しています。

stub._setProperty(WLStub.POLICY_SELECTION_PREFERENCE,

WLStub.PREFERENCE_SECURITY_COMPATIBILITY_PERFORMANCE);

JAX-WSで次の例を考えてみます。

BindingProvider bindingProvider = (BindingProvider) port;
Map<String,Object> rc =
(Map<String,Object>)bindingProvider.getRequestContext();
rc.put(WLStub.POLICY_SELECTION_PREFERENCE,
WLStub.PREFERENCE_COMPATIBILITY_PERFORMANCE_SECURITY);

ポリシー選択プリファレンスが設定されていない場合は、デフォルトのプリファレンス(なし)が使用されます。

複数のトランスポート・アサーション

セキュリティ・ポリシー内に使用可能なトランスポート・レベルのアサーションが複数ある場合、WebLogic Serverではhttpsを必要とするポリシーが使用されます。2つ以上のポリシー選択肢がhttpsを必要とする場合は、そのいずれかがランダムに選択されます。したがって、トランスポート・レベルのポリシー・アサーションが混在する複数のポリシー選択肢を使用するのは避けてください。

MTOM Webサービスにセキュリティを追加する例

注意:

この例は、JAX-RPC Webサービスにセキュリティを追加する方法を示しています。このリリースでは、WS-SecurityによるMTOMはJAX-WSとJAX-RPCの両方に対してサポートされます。

MTOM/XOPを使用したバイナリ・データ転送の最適化に関する項で説明されているように、SOAP Message Transmission Optimization Mechanism/XML-binary Optimized Packaging (MTOM/XOP)では、SOAPメッセージにおけるxs:base64Binary型またはxs:hexBinary型のXMLデータの転送を最適化するための方法が定義されています。

この項では、WebLogic Serverにオプションで含まれている2つのサンプルの組合せについて説明します。

- EXAMPLES_HOME\wl_server\examples\src\examples\webservices\wss1.1

- EXAMPLES_HOME\wl_server\examples\src\examples\webservices\mtom

これらの既存のサンプルには、実際に機能するコードと、その使用方法や役割、ビルド方法などを説明した詳細なinstructions.htmlファイルが含まれています。この項では、その説明を繰り返すのではなく、これらのサンプルに加える変更と変更の理由に焦点を当てています。WebLogic Serverのコード例の詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

この例で使用されるファイル

この例では表2-1に示したファイルを使用しています。ソース・ファイルの内容はこの後の項で示します。

表2-13 MTOM/セキュリティの例で使用されるファイル

ファイル

説明

build.xml

サンプルをビルドおよび実行するためのターゲットが含まれたビルド・ファイル。

configWss.py

Webサービス・セキュリティ構成を構成するWLSTスクリプト。このファイルはEXAMPLES_HOME\wl_server\examples\src\examples\webservices\wss1.1から変更なしでコピーされます。

MtomClient.java

MTOM Webサービスを呼び出すスタンドアロンのクライアント・アプリケーション。このファイルでは、WebサービスのWSDLに基づいてclientgenによって生成されたJAX-RPCスタブを使用します。

SecurityMtomService.java

MTOM Webサービスを実装するJWSファイル。このJWSファイルでは、@Policyアノテーションを使用して、Webサービスに関連付けられたWS-Policyファイルを指定します。

clientkeyStore.jks

クライアント側のキーストア。クライアント側のBinarySecurityToken資格証明プロバイダの作成に使用されます。

このファイルはEXAMPLES_HOME\wl_server\examples\src\examples\webservices\wss1.1\certsから変更なしでコピーされます。

serverkeyStore.jks

サーバー側のキーストア。サーバー側のBinarySecurityToken資格証明プロバイダの作成に使用されます。

このファイルはEXAMPLES_HOME\wl_server\examples\src\examples\webservices\wss1.1\certsから変更なしでコピーされます。

testServerCertTempCert.der

サーバー側の証明書。サーバー側のBinarySecurityToken資格証明プロバイダの作成に使用されます。

このファイルはEXAMPLES_HOME\wl_server\examples\src\examples\webservices\wss1.1\certsから変更なしでコピーされます。

SecurityMtomService.java

SecurityMtomService.java JWSファイルは、EXAMPLES_HOME\wl_server\examples\src\examples\webservices\mtom\MtomService.javaのJWSファイルと同じものです(追加のポリシー・アノテーションは太字で示されています)。

例2-25 SecurityMtomService.java

package examples.webservices.security_mtom;
import weblogic.jws.Binding;
import weblogic.jws.Policy;
import weblogic.jws.Policies;
import weblogic.jws.Context;
import weblogic.jws.WLDeployment;
import weblogic.wsee.jws.JwsContext;
import weblogic.wsee.mtom.api.MtomPolicyInfo;
import weblogic.wsee.mtom.api.MtomPolicyInfoFactory;
import weblogic.wsee.policy.framework.PolicyException;

import javax.jws.WebService;
import javax.jws.WebMethod;
import java.rmi.RemoteException;

/**
* Sample to MTOM with JAX-RPC
*
* @author Copyright © 1996, 2008, Oracle and/or its affiliates.
* All rights reserved.
*/
@WebService
@Binding(Binding.Type.SOAP12)
//enable WSS + MTOM for this web service by adding the following canned policy files
@Policies({
@Policy(uri = "policy:Mtom.xml"),
@Policy(uri = "policy:Wssp1.2-2007-SignBody.xml"),
@Policy(uri = "policy:Wssp1.2-2007-EncryptBody.xml"),
@Policy(uri = "policy:Wssp1.2-Wss1.1-EncryptedKey.xml")
})
public class SecurityMtomService {

public SecurityMtomService() {

}

/**
* Input is sent as XOP'ed binary octet stream
*
* @param bytes input bytes
* @return A simple String
*/
@WebMethod
public String echoBinaryAsString(byte[] bytes) {
return new String(bytes);
}

/**
* Output is sent as as XOP'ed binary octet stream
*
* @param s a simple String
* @return byte[]
*/
@WebMethod
public byte[] echoStringAsBinary(String s) {
return s.getBytes();
}

/**
* input byte[] is sent as as XOP'ed binary octet stream
*
* @param array input byte[] array
* @return String[]
*/
@WebMethod
public String[] echoBinaryArrayAsStringArray(byte[] array) {
String[] strings = new String[1];
strings[0] = new String(array);
return strings;
}
}

@Policyアノテーションはクラス・レベルでもメソッド・レベルでも指定できます。このサンプルでは、アノテーションをクラス・レベルで使用して、事前定義済のWS-Policyファイルを指定しています。つまり、Webサービスのすべてのパブリック操作は指定されたWS-Policyファイルに関連付けられます。

複数の@Policyアノテーションをグループ化するには、@Policiesアノテーションを使用します。このアノテーションはクラス・レベルでもメソッド・レベルでも指定できます。この例では、アノテーションをクラス・レベルで使用して、事前定義済のWS-Policyファイルを指定する4つの@Policyアノテーションをグループ化しています。

- 事前定義済のWS-PolicyファイルMtom.xmlでは、MTOMエンコーディングを有効にします。

- 保護アサーション・ポリシーで説明しているように、Wssp1.2-2007-SignBody.xmlポリシー・ファイルは、リクエストとレスポンスSOAPメッセージの両方の本文とWebLogicシステム・ヘッダーがデジタル署名されるよう指定します。

- Wssp1.2-2007-EncryptBody.xmlポリシー・ファイルは、SOAPのリクエスト・メッセージおよびレスポンス・メッセージの両方の本文が暗号化されることを指定しています。

- Wssp1.2-Wss1.1-EncryptedKey.xml対称バインディング・ポリシーは、WS-Security 1.1 Encrypted Key機能を使用します。Webサービスを呼び出すクライアント・アプリケーションは暗号化キーを使用して暗号化と署名を行い、サーバーは署名確認を送信する必要があります。

MtomClient.java

MtomClient.javaは、SecurityMtomService Webサービスを呼び出すスタンドアロン・クライアント・アプリケーションです。WebサービスのWSDLに基づいてclientgenによって生成されたJAX-RPCスタブを使用します。MtomClientコードは例2-26に示されています。

例2-26 MtomClient.java

package examples.webservices.security_mtom.client;

import java.rmi.RemoteException;

import java.security.cert.X509Certificate;
import java.util.ArrayList;
import java.util.List;
import javax.xml.rpc.Stub;

import weblogic.security.SSL.TrustManager;

// Import classes to create the Binary and Username tokens
import weblogic.wsee.security.bst.ClientBSTCredentialProvider;
import weblogic.wsee.security.unt.ClientUNTCredentialProvider;

// Import classes for creating the client-side credential provider
import weblogic.xml.crypto.wss.WSSecurityContext;
import weblogic.xml.crypto.wss.provider.CredentialProvider;
import weblogic.wsee.security.util.CertUtils;

/**
* @author Copyright © 1996, 2008, Oracle and/or its affiliates.
* All rights reserved.
*/
public class MtomClient {
private static final String FOO = "FOO";
private static SecurityMtomService port;

public MtomClient(String args[]) throws Exception {
//client keystore file
String clientKeyStore = args[0];
String clientKeyStorePass = args[1];
String clientKeyAlias = args[2];
String clientKeyPass = args[3];

//server certificate
String serverCertFile = args[4];
String wsdl = args[5];

SecurityMtomServiceService service = new SecurityMtomServiceService_Impl(wsdl);
port = service.getSecurityMtomServiceSoapPort();

X509Certificate serverCert = (X509Certificate) CertUtils.getCertificate(serverCertFile);

//create emtpy list of credential providers
List credProviders = new ArrayList();

//Create client-side BinarySecurityToken credential provider that uses
// X.509 for identity, based on certificate and keys parameters
CredentialProvider cp = new ClientBSTCredentialProvider(clientKeyStore,
clientKeyStorePass, clientKeyAlias, clientKeyPass, "JKS", serverCert);
credProviders.add(cp);

Stub stub = (Stub) port;

// Set stub property to point to list of credential providers
stub._setProperty(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders);

// setup the TrustManager.
stub._setProperty(WSSecurityContext.TRUST_MANAGER,
new TrustManager() {
public boolean certificateCallback(X509Certificate[] chain, int validateErr) {
//Typically in a real-life application, Java code that actually
//verifies the certificate goes here; for sake of simplicity, this
//example assumes the certificate is valid and simply returns true.

return true;
}
});
}

public static void main(String[] args) throws Exception {
MtomClient client = new MtomClient(args);
client.invokeEchoBinaryAsString();
client.invokeEchoStringAsBinary();
client.invokeEchoBinaryArrayAsStringArray();
}

public void invokeEchoBinaryArrayAsStringArray() throws RemoteException {
System.out.println("sending a String '" + FOO + "' as a byte array.");
String result = port.echoBinaryArrayAsStringArray(FOO.getBytes()).getJavaLangstring()[0];
System.out.println("echoing '" + result + "' as a String array.");
}

public void invokeEchoStringAsBinary() throws RemoteException {
System.out.println("sending a String '" + FOO + "'");
String result = new String(port.echoStringAsBinary(FOO));
System.out.println("echoing '" + result + "' as a byte array.");
}

public void invokeEchoBinaryAsString() throws RemoteException {
System.out.println("sending a String '" + FOO + "' as a byte array.");
String result = port.echoBinaryAsString(FOO.getBytes());
System.out.println("echoing '" + result + "' as a String.");
}
}

クライアント・アプリケーションは、次の6つの引数を取ります。

- クライアント・キーストア

- クライアント・キーストア・パスワード

- クライアント・キー別名

- クライアント・キー・パスワード

- サーバー証明書ファイル

- デプロイされたWebサービスのWSDL

クライアント・アプリケーションは、次のWebLogic Webサービス・セキュリティAPIを使用し、Webサービスに関連付けられているWS-Policyファイルでの指定に従って、必要なクライアント側の資格証明プロバイダを作成します。

- weblogic.wsee.security.bst.ClientBSTCredentialProvider - 証明書と秘密鍵を使用してバイナリ・セキュリティ・トークン資格証明プロバイダを作成します。

- weblogic.xml.crypto.wss.WSSecurityContext - JAX-RPCスタブに資格証明プロバイダのリストを指定します。

- weblogic.xml.crypto.wss.provider.CredentialProvider - メインの資格証明プロバイダ・クラス。

このクライアント・アプリケーションを記述するときは、Webサービスに関連付けられているWS-Policyファイルを調べて、JAX-RPCスタブに設定する必要のある資格証明プロバイダのタイプと数を決定する必要があります。通常、WS-PolicyファイルでアイデンティティにX.509を使用してSOAPメッセージを署名または暗号化することが指定されている場合は、ClientBSTCredentialProviderを作成する必要があります。(ユーザーがアイデンティティとしてユーザー名トークンを提示することが指定されている場合は、アプリケーションはClientUNTCredentialProviderを作成する必要があります。)

この例では、指定されたキーストア、証明書別名およびサーバー証明書に対応するクライアントBST資格証明プロバイダを作成します。パラメータserverCertで渡された証明書は、メッセージ本文の内容の暗号化と受信した署名の検証に使用されます。受信した署名の一部として受け取ったKeyInfo (証明書の指紋など)は、同じサーバー証明書を正しく識別するものであることが必要です。

また、Webサービス・クライアント・ランタイムは、操作が呼び出されると、SOAPリクエストのセキュリティ・ヘッダーを正しく作成するために、このWSDLを確認します。

最後に、クライアント・アプリケーションはweblogic.security.SSL.TrustManager WebLogicセキュリティAPIを使用して、SOAPリクエストの暗号化に使用される証明書が有効かどうかを確認する必要があります。クライアント・ランタイムが現実の状況では自動的には信頼できないWebサービスによりデプロイされているWSDLからこの証明書(例のserverCert)を得るので、クライアント・アプリケーションはSOAPリクエストの暗号化に使用する前に万全であることを確認する必要があります。

注意:

この例で使用されるクライアント側の証明書と秘密鍵は単純なテスト目的で作成されているため、WebLogic Serverから常に信頼されます。このため、この例を実行するためにサーバー側のセキュリティ構成を追加する必要はありません。しかし実際には、クライアント・アプリケーションはVerisignなどの実在の認証局が発行した証明書を使用します。その場合、管理者はWebLogic 管理コンソールを使用して、WebLogic Serverから信頼されるリストにこの証明書を追加する必要があります。

configWss.pyスクリプト・ファイル

SecurityMtomService Webサービスは、関連付けられたポリシー・ファイルで課せられている要件に対応するためにWebLogic Server APIを明示的に呼び出すことはありません。また、どのセキュリティ・プロバイダ、トークン、その他のメカニズムが使用されるかを認識する必要もありません。

スクリプト・ファイルconfigWss.pyでは、WLSTを使用して、アクティブなセキュリティ・レルムのデフォルトのWebサービス・セキュリティ構成default_wssを作成および構成します。(デフォルトのWebサービス・セキュリティ構成は、別の構成を使用するように明示的にプログラミングされていないかぎり、ドメイン内のすべてのWebサービスで使用されます。)さらに、このスクリプトではx509トークンがサポートされるようにし、必要なセキュリティ・プロバイダなどを作成します。

例2-27は、configWss.pyファイルを示しています。build.xmlファイルがコマンド入力を提供します。注目すべき部分は太字で表されています。

注意:

このスクリプト内の長い行は、見やすいように書式を整えてあります。

例2-27 configWss.py

userName = sys.argv[1]
passWord = sys.argv[2]
url="t3://"+sys.argv[3]+":"+sys.argv[4]

print "Connect to the running adminSever"

connect(userName, passWord, url)

edit()
startEdit()

#Enable assert x509 in SecurityConfiguration
rlm = cmo.getSecurityConfiguration().getDefaultRealm()
ia = rlm.lookupAuthenticationProvider("DefaultIdentityAsserter")
activeTypesValue = list(ia.getActiveTypes())
existed = "X.509" in activeTypesValue
if existed == 1:
print 'assert x509 is aleady enabled'
else:
activeTypesValue.append("X.509")
ia.setActiveTypes(array(activeTypesValue,java.lang.String))
ia.setDefaultUserNameMapperAttributeType('CN');
ia.setUseDefaultUserNameMapper(Boolean('true'));

#Create default WebServcieSecurity
securityName='default_wss'
defaultWss=cmo.lookupWebserviceSecurity(securityName)
if defaultWss == None:
print 'creating new webservice security bean for: ' + securityName
defaultWss = cmo.createWebserviceSecurity(securityName)
else:
print 'found exsiting bean for: ' + securityName

#Create credential provider for DK
cpName='default_dk_cp'
wtm=defaultWss.lookupWebserviceCredentialProvider(cpName)
if wtm == None:
wtm = defaultWss.createWebserviceCredentialProvider(cpName)
wtm.setClassName('weblogic.wsee.security.wssc.v200502.dk.
DKCredentialProvider')
wtm.setTokenType('dk')
cpm = wtm.createConfigurationProperty('Label')
cpm.setValue('WS-SecureConversationWS-SecureConversation')
cpm = wtm.createConfigurationProperty('Length')
cpm.setValue('16')
else:
print 'found exsiting bean for: DK ' + cpName

#Create credential provider for x.509
cpName='default_x509_cp'
wtm=defaultWss.lookupWebserviceCredentialProvider(cpName)
if wtm == None:
wtm = defaultWss.createWebserviceCredentialProvider(cpName)
wtm.setClassName('weblogic.wsee.security.bst.
ServerBSTCredentialProvider')
wtm.setTokenType('x509')
else:
print 'found exsiting bean for: x.509 ' + cpName

#Custom keystore for xml encryption
cpName='ConfidentialityKeyStore'
cpm=wtm.lookupConfigurationProperty(cpName)
if cpm == None:
cpm = wtm.createConfigurationProperty(cpName)
keyStoreName=sys.argv[5]
cpm.setValue(keyStoreName)

cpName='ConfidentialityKeyStorePassword'
cpm=wtm.lookupConfigurationProperty(cpName)
if cpm == None:
cpm = wtm.createConfigurationProperty(cpName)
cpm.setEncryptValueRequired(Boolean('true'))
KeyStorePasswd=sys.argv[6]
cpm.setEncryptedValue(KeyStorePasswd)

cpName='ConfidentialityKeyAlias'
cpm=wtm.lookupConfigurationProperty(cpName)
if cpm == None:
cpm = wtm.createConfigurationProperty(cpName)
keyAlias=sys.argv[7]
cpm.setValue(keyAlias)

cpName='ConfidentialityKeyPassword'
cpm=wtm.lookupConfigurationProperty(cpName)
if cpm == None:
cpm = wtm.createConfigurationProperty('ConfidentialityKeyPassword')
cpm.setEncryptValueRequired(Boolean('true'))
keyPass=sys.argv[8]
cpm.setEncryptedValue(keyPass)

#Custom keystore for xml digital signature
cpName='IntegrityKeyStore'
cpm=wtm.lookupConfigurationProperty(cpName)
if cpm == None:
cpm = wtm.createConfigurationProperty(cpName)
keyStoreName=sys.argv[5]
cpm.setValue(keyStoreName)

cpName='IntegrityKeyStorePassword'
cpm=wtm.lookupConfigurationProperty(cpName)
if cpm == None:
cpm = wtm.createConfigurationProperty(cpName)
cpm.setEncryptValueRequired(Boolean('true'))
KeyStorePasswd=sys.argv[6]
cpm.setEncryptedValue(KeyStorePasswd)

cpName='IntegrityKeyAlias'
cpm=wtm.lookupConfigurationProperty(cpName)
if cpm == None:
cpm = wtm.createConfigurationProperty(cpName)
keyAlias=sys.argv[7]
cpm.setValue(keyAlias)

cpName='IntegrityKeyPassword'
cpm=wtm.lookupConfigurationProperty(cpName)
if cpm == None:
cpm = wtm.createConfigurationProperty(cpName)
cpm.setEncryptValueRequired(Boolean('true'))
keyPass=sys.argv[8]
cpm.setEncryptedValue(keyPass)

#Create token handler for x509 token
#cpName='default_x509_handler'
th=defaultWss.lookupWebserviceTokenHandler(cpName)
if th == None:
th = defaultWss.createWebserviceTokenHandler(cpName)
th.setClassName('weblogic.xml.crypto.wss.BinarySecurityTokenHandler')
th.setTokenType('x509')
cpm = th.createConfigurationProperty('UseX509ForIdentity')
cpm.setValue('true')

save()
activate(block="true")
disconnect()
exit()

Build.xmlファイル

build.xmlファイルには、表2-1に示したターゲットがあります。

表2-14 build.xmlのターゲット

ターゲット

説明

client

セキュリティMTOM Webサービス・クライアントをビルドするターゲット。

config.server.security

Webサービス・セキュリティを構成するターゲット。

deploy

Webサービスをデプロイするターゲット。

server

セキュリティMTOM Webサービスをビルドするターゲット。

clean

一時ディレクトリを削除します。

build

server、client、およびcleanに依存します。

run

セキュリティMTOM Webサービス・クライアントを実行するターゲット。

all

デフォルト・ターゲット。build、deployに依存します。

完全なbuild.xmlファイルを例2-28に示します。

例2-28 build.xmlファイル

<?xml version="1.0" encoding="ISO-8859-1"?>
<project name="webservices.security_mtom" default="all" basedir=".">

<!-- set global properties for this build -->
<property file="../../../examples.properties"/>

<property name="client.dir" value="${client.classes.dir}/webservicesSecurityMtom_Client" />
<property name="package.dir" value="examples/webservices/security_mtom"/>
<property name="package" value="examples.webservices.security_mtom"/>
<property name="ws.file" value="SecurityMtomService" />
<property name="ear.dir" value="${examples.build.dir}/webservicesSecurityMtomEar" />
<property name="cert.dir" value="${basedir}/certs" />
<property name="certs.dir" value="${basedir}/certs" />

<!--client keystore-->
<property name="client-keystore-name" value="clientKeyStore.jks"/>
<property name="client-keystore-pass" value="keystorepw"/>
<property name="client-cert" value="ClientCert"/>
<property name="client-key" value="ClientKey"/>
<property name="client-key-pass" value="ClientKeyPass"/>
<property name="client-cert-alias" value="testClientCert"/>

<!--server keystore-->
<property name="server-keystore-name" value="serverKeyStore.jks"/>
<property name="server-keystore-pass" value="keystorepw"/>
<property name="server-cert" value="ServerCert"/>
<property name="server-key" value="ServerKey"/>
<property name="server-key-pass" value="ServerKeyPass"/>
<property name="server-cert-alias" value="testServerCert"/>

<path id="client.class.path">
<pathelement path="${client.dir}"/>
<pathelement path="${java.class.path}"/>
</path>

<!-- Web Service WLS Ant task definitions -->
<taskdef name="jwsc"
classname="weblogic.wsee.tools.anttasks.JwscTask" />
<taskdef name="clientgen"
classname="weblogic.wsee.tools.anttasks.ClientGenTask" />

<target name="all" depends="build, deploy"/>

<target name="build" depends="clean,server,client"/>

<target name="clean">
<delete dir="${ear.dir}"/>
<delete dir="${client.dir}"/>
</target>

<!-- Target that builds the MTOM Web Service -->
<target name="server" description="Target that builds the MTOM Web Service">
<jwsc
srcdir="${examples.src.dir}/${package.dir}"
sourcepath="${examples.src.dir}"
destdir="${ear.dir}"
classpath="${java.class.path}"
fork="true"
keepGenerated="true"
deprecation="${deprecation}"
debug="${debug}">
<jws file="SecurityMtomService.java" explode="true"/>
</jwsc>
</target>

<!-- Target that builds the MTOM Web Service client -->
<target name="client" description="Target that builds the source Web Service">
<mkdir dir="${client.dir}/${package.dir}/client/"/>
<clientgen
wsdl="${ear.dir}/${ws.file}/WEB-INF/${ws.file}Service.wsdl"
destDir="${client.dir}"
classpath="${java.class.path}"
packageName="${package}.client"/>
<copy file="MtomClient.java" todir="${client.dir}/${package.dir}/client/"/>
<javac
srcdir="${client.dir}" destdir="${client.dir}"
classpath="${java.class.path}"
includes="${package.dir}/client/**/*.java"/>
</target>

<!-- Target that deploys the MTOM Web Service -->
<target name="deploy" description="Target that deploys the reliable destination Web Service">
<wldeploy
action="deploy"
source="${ear.dir}"
user="${wls.username}"
password="${wls.password}"
verbose="true"
adminurl="t3://${wls.hostname}:${wls.port}"
targets="${wls.server.name}"
failonerror="${failondeploy}"/>
</target>

<!-- Target that runs the MTOM Web Service client -->
<target name="run" >
<java fork="true"
classname="examples.webservices.security_mtom.client.MtomClient"
failonerror="true" >
<jvmarg line="-Dweblogic.wsee.verbose=*"/>
<classpath refid="client.class.path"/>
<arg line="
${basedir}/certs/${client-keystore-name}
${client-keystore-pass}
${client-cert-alias}
${client-key-pass}
${basedir}/certs/testServerCertTempCert.der
http://${wls.hostname}:${wls.port}/SecurityMtomService/SecurityMtomService?WSDL" />
</java>
</target>

<!-- Target the configure the web service security -->
<target name="config.server.security" description="Target the configure the web service security">
<copy todir="${examples.domain.dir}" overwrite="true">
<fileset dir="${certs.dir}" includes="${server-keystore-name}"/>
</copy>

<java classname="weblogic.WLST" fork="true" failonerror="true">
<arg line="configWss.py ${wls.username} ${wls.password} ${wls.hostname} ${wls.port}
${server-keystore-name} ${server-keystore-pass} ${server-cert-alias} ${server-key-pass}" />
</java>

</target>

</project>

サンプルのビルドおよび実行

次の手順に従って、サンプルをビルドおよび実行します。

1. サンプル・サーバーを起動します。

2. EXAMPLES_HOME\wl_server\examples\src\examples\examples.html指示ファイルの説明に従って、環境を設定します。EXAMPLES_HOMEは、WebLogic Serverのサンプル・コードが構成されるディレクトリを示します。WebLogic Serverのコード例の詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。
ORACLE_HOME\user_projects\domains\wl_server>setExamplesEnv.cmd

3. EXAMPLES_HOME\wl_server\examples\src\examples\webservicesディレクトリに変更して新しいサブディレクトリsecurity_mtomを作成します。

4. build.xml、configWss.py、MtomClient.java、SecurityMtomService.javaの各セクションの内容をコピーして、EXAMPLES_HOME\wl_server\examples\src\examples\webservices\security_mtomディレクトリの同じファイル名のファイルにペーストします。

5. すべてのファイル(clientKeyStore.jks、serverKeyStore.jksおよびtestServerCertTempCert.der)を次からコピーします
EXAMPLES_HOME\wl_server\examples\src\examples\webservices\wss1.1\certs

宛先: 新しいcertsサブディレクトリ

EXAMPLES_HOME\wl_server\examples\src\examples\webservices\security_mtom\certs

6. EXAMPLES_HOME\wl_server\examples\src\examples\webservices\security_mtomディレクトリに変更します。

7. 次のコマンドを実行します。
prompt> ant config.server.security

8. Weblogic Serverを再起動します。

9. サンプルをビルド、デプロイ、および実行します。
prompt> ant build deploy run

SecurityMtomServiceのデプロイ済WSDL

SecurityMtomService Webサービスのデプロイ済WSDLは、次のURLにあります。

http://host:port/SecurityMtomService/SecurityMtomService?WSDL

完全なWSDLを例2-29に示します。

例2-29 SecurityMtomServiceのデプロイ済WSDL

<?xml version="1.0" encoding="UTF-8" ?>
<s1:definitions name="SecurityMtomServiceServiceDefinitions"
targetNamespace="http://examples/webservices/security_mtom" xmlns=""
xmlns:s0="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:s1="http://schemas.xmlsoap.org/wsdl/"
xmlns:s2="http://examples/webservices/security_mtom"
xmlns:s3="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsp:UsingPolicy s1:Required="true" />
<wsp:Policy s0:Id="Mtom.xml">
<wsoma:OptimizedMimeSerialization
xmlns:wsoma="http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization" />
</wsp:Policy>
<wsp:Policy s0:Id="Wssp1.2-Wss1.1-EncryptedKey.xml">
<sp:SymmetricBinding xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512">
<wsp:Policy>
<sp:ProtectionToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Never">
<wsp:Policy>
<sp:RequireThumbprintReference />
<sp:WssX509V3Token11 />
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:ProtectionToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Lax />
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp />
<sp:OnlySignEntireHeadersAndBody />
</wsp:Policy>
</sp:SymmetricBinding>
<sp:Wss11 xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512">
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier />
<sp:MustSupportRefIssuerSerial />
<sp:MustSupportRefThumbprint />
<sp:MustSupportRefEncryptedKey />
<sp:RequireSignatureConfirmation />
</wsp:Policy>
</sp:Wss11>
</wsp:Policy>
<wsp:Policy s0:Id="Wssp1.2-2007-EncryptBody.xml">
<sp:EncryptedParts xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<sp:Body />
</sp:EncryptedParts>
</wsp:Policy>
<wsp:Policy s0:Id="Wssp1.2-2007-SignBody.xml">
<sp:SignedParts xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<sp:Body />
</sp:SignedParts>
</wsp:Policy>
<s1:types>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified"
targetNamespace="java:examples.webservices.security_mtom"
xmlns:s0="http://schemas.xmlsoap.org/wsdl/"
xmlns:s1="http://examples/webservices/security_mtom"
xmlns:s2="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:complexType name="ArrayOfJavaLangstring_literal">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0" name="JavaLangstring" nillable="true" type="xs:string" />
</xs:sequence>
</xs:complexType>
<xs:element name="ArrayOfJavaLangstring_literal" type="java:ArrayOfJavaLangstring_literal" xmlns:java="java:examples.webservices.security_mtom" />
<xs:element name="base64Binary_literal" type="xs:base64Binary" />
</xs:schema>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified"
targetNamespace="http://examples/webservices/security_mtom"
xmlns:s0="http://schemas.xmlsoap.org/wsdl/"
xmlns:s1="http://examples/webservices/security_mtom"
xmlns:s2="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import namespace="java:examples.webservices.security_mtom" />
<xs:element name="echoBinaryAsString">
<xs:complexType>
<xs:sequence>
<xs:element name="bytes" type="xs:base64Binary" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="echoBinaryAsStringResponse">
<xs:complexType>
<xs:sequence>
<xs:element name="return" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="echoBinaryArrayAsStringArray">
<xs:complexType>
<xs:sequence>
<xs:element name="array" type="xs:base64Binary" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="echoBinaryArrayAsStringArrayResponse">
<xs:complexType>
<xs:sequence>
<xs:element name="return" type="java:ArrayOfJavaLangstring_literal" xmlns:java="java:examples.webservices.security_mtom" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="echoStringAsBinary">
<xs:complexType>
<xs:sequence>
<xs:element name="s" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="echoStringAsBinaryResponse">
<xs:complexType>
<xs:sequence>
<xs:element name="return" type="xs:base64Binary" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
</s1:types>
<s1:message name="echoBinaryAsString">
<s1:part element="s2:echoBinaryAsString" name="parameters" />
</s1:message>
<s1:message name="echoBinaryAsStringResponse">
<s1:part element="s2:echoBinaryAsStringResponse" name="parameters" />
</s1:message>
<s1:message name="echoBinaryArrayAsStringArray">
<s1:part element="s2:echoBinaryArrayAsStringArray" name="parameters" />
</s1:message>
<s1:message name="echoBinaryArrayAsStringArrayResponse">
<s1:part element="s2:echoBinaryArrayAsStringArrayResponse" name="parameters" />
</s1:message>
<s1:message name="echoStringAsBinary">
<s1:part element="s2:echoStringAsBinary" name="parameters" />
</s1:message>
<s1:message name="echoStringAsBinaryResponse">
<s1:part element="s2:echoStringAsBinaryResponse" name="parameters" />
</s1:message>
<s1:portType name="SecurityMtomService" wsp:PolicyURIs="#Wssp1.2-2007-SignBody.xml #Wssp1.2-2007-EncryptBody.xml
#Wssp1.2-Wss1.1-EncryptedKey.xml">
<s1:operation name="echoBinaryAsString" parameterOrder="parameters">
<s1:input message="s2:echoBinaryAsString" />
<s1:output message="s2:echoBinaryAsStringResponse" />
</s1:operation>
<s1:operation name="echoBinaryArrayAsStringArray" parameterOrder="parameters">
<s1:input message="s2:echoBinaryArrayAsStringArray" />
<s1:output message="s2:echoBinaryArrayAsStringArrayResponse" />
</s1:operation>
<s1:operation name="echoStringAsBinary" parameterOrder="parameters">
<s1:input message="s2:echoStringAsBinary" />
<s1:output message="s2:echoStringAsBinaryResponse" />
</s1:operation>
</s1:portType>
<s1:binding name="SecurityMtomServiceServiceSoapBinding" type="s2:SecurityMtomService">
<s3:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />
<wsp:Policy>
<wsp:PolicyReference URI="#Mtom.xml" />
</wsp:Policy>
<s1:operation name="echoBinaryAsString">
<s3:operation style="document" />
<s1:input>
<s3:body parts="parameters" use="literal" />
</s1:input>
<s1:output>
<s3:body parts="parameters" use="literal" />
</s1:output>
</s1:operation>
<s1:operation name="echoBinaryArrayAsStringArray">
<s3:operation style="document" />
<s1:input>
<s3:body parts="parameters" use="literal" />
</s1:input>
<s1:output>
<s3:body parts="parameters" use="literal" />
</s1:output>
</s1:operation>
<s1:operation name="echoStringAsBinary">
<s3:operation style="document" />
<s1:input>
<s3:body parts="parameters" use="literal" />
</s1:input>
<s1:output>
<s3:body parts="parameters" use="literal" />
</s1:output>
</s1:operation>
</s1:binding>
<s1:service name="SecurityMtomServiceService">
<s1:port binding="s2:SecurityMtomServiceServiceSoapBinding" name="SecurityMtomServiceSoapPort">
<s3:address location="http://localhost:7001/SecurityMtomService/SecurityMtomService" />
</s1:port>
</s1:service>
</s1:definitions>

信頼性のあるメッセージングWebサービスにセキュリティを追加する例

この項では、WebLogic Serverにオプションで含まれているサンプルの更新方法について説明します。

- EXAMPLES_HOME\wl_server\examples\src\examples\webservices\wsrm_security

この節では、最新バージョンのポリシー・ファイルを使用するようにサンプルを更新する方法を示します。。変更されたサンプルに示すように、新しいポリシー・ネームスペースを使用することをお薦めします。OASIS標準の公式のネームスペースであり、他のベンダーと相互運用するときに適しているためです。

セキュアで信頼性のあるSOAPメッセージングの概要

信頼性のあるSOAPメッセージングとは、あるWebLogic Serverインスタンスで実行されているアプリケーションが別のWebLogic Serverインスタンスで実行されているWebサービスを確実に呼び出せるようにするフレームワークです。信頼性は、2つのWebサービス間のメッセージ配信を保証する能力として定義されます。

WebLogic Webサービスは、異なるWebLogic Serverアプリケーション・サーバーで動作する2つのWebサービスが、ソフトウェア・コンポーネント、システムまたはネットワークで障害が発生した場合に確実に通信する方法を規定した、WS-ReliableMessaging 1.1仕様に準拠しています。具体的には、ソース・エンドポイント(クライアントWebサービス)から宛先エンドポイント(操作を確実に呼び出せるWebサービス)へ送信されるメッセージが、1つ以上の配信保証に基づいて確実に配信され、そうでなければ必ずエラーが発生する、相互運用性を備えたプロトコルについて記述されています。WS-ReliableMessaging仕様では、WS-ReliableMessagingにWS-SecureConversationを組み合せて、信頼性のあるシーケンスとセキュアなセッションを関連付けることにより、相互運用可能なセキュリティの提供方法を定義しています。シーケンスの作成時に、送信側は、シーケンスの所有者の識別に使用されるセキュリティ・コンテキスト・トークンを指すセキュリティ・トークン参照を提示する必要があります。以降の両方向のすべてのシーケンス・メッセージとプロトコル・メッセージは、参照されたキーの所有証明を提示する必要があります。

WebLogicの信頼性のあるSOAPメッセージングは、2つのWebサービス間でのみ機能します。つまり、WebLogic Webサービスは別のWebサービスからのみ確実に呼び出すことが可能で、スタンドアロン・クライアント・アプリケーションからは機能しません。この例では、両方のタイプ(ソースと宛先)のWebサービスの作成方法を示します。WsrmSecurityClient.javaクラスは、ソースWebサービスを呼び出すスタンドアロンのJavaアプリケーションです。

サンプルの概要

既存のサンプルでは、次の2つのWebLogic Webサービスを作成することで、Webサービス・メッセージングの信頼性に加えてセキュリティ機能を提供する方法を示しています。

- 信頼性のあるセキュアなSOAPメッセージングを使用して操作を呼び出せるWebサービス(宛先エンドポイント)。宛先ReliableEchoService Webサービスには、信頼性のあるセキュアな方法で呼び出せる2つの操作echoおよびechoOnewayがあります。

- 1番目のWebサービスの操作を信頼性のあるセキュアな方法で呼び出すクライアントWebサービス(ソース・エンドポイント)。ソースReliableEchoClientService Webサービスには、ReliableEchoService WebサービスのechoおよびechoOneway操作を、1つの会話の中で信頼性のあるセキュアな方法で呼び出すための1つの操作echoがあります。

既存のサンプルには、実際に機能するコードと、その使用方法や役割、ビルド方法などを説明した詳細なinstructions.htmlファイルが含まれています。この項では、その説明を繰り返すのではなく、サンプルに加える変更と変更の理由に焦点を当てています。

サンプルにおけるセキュリティの設定

configWSS.py WLSTスクリプトはソースおよび宛先WebサービスをホストするWebLogic Serverインスタンスのセキュリティを設定します。セキュリティ要件は、宛先Webサービスに関連付けられたWS-SecurityPolicyファイルによって規定されます。

Wssp1.2-2007-Wssc1.3-Bootstrap-Wss1.0.xmlポリシーは次の要件を課しています。

- WS-SecureConversationハンドシェイクがWS-Security 1.0によって保護されます。

- アプリケーション・メッセージは、DerivedKeyで署名および暗号化されます。

- (WS-SecureConversationハンドシェイクの一部の) RequestSecurityTokenおよびRequestSecurityTokenResponseCollectionメッセージのsoap:Bodyは署名および暗号化されます。

- WS-Addressingヘッダーは署名されます。

- タイムスタンプは、格納されて署名されます。

- 署名は暗号化されます。

- アルゴリズム・スイートはBasic256です。

これを受けて、configWSS.py WLSTスクリプトは次の機能を実行します。

- デフォルト・セキュリティ・レルム内のデフォルトIdentityAsserterでX.509トークンを有効にします。

- デフォルトのWebサービス・セキュリティ構成を作成します。

- セキュリティ・コンテキスト・トークンの資格証明プロバイダを構成します。

- 派生キーの資格証明プロバイダを構成します。

- X.509トークンのBinarySecurityTokenHandlerトークンを構成します。

- X.509トークンのServerBSTCredentialProvider資格証明プロバイダを構成します。

- 機密性と整合性を確保するためにキーストアを構成します。

- PKI資格証明マッパーを構成します。これは、イニシエータとターゲット・リソースをキー・ペアまたはパブリック証明書にマップします

さらに、configWSSRuntime.py WLSTスクリプトは次の機能を実行します。

- 宛先Webサービスを呼び出すように、(configWSS.pyで構成された)PKI資格証明マッパーを設定します。

この例で使用されるファイル

この例では表2-1に示したファイルを使用しています。変更されたソース・ファイルの内容はこの後の項で示します。

表2-15 WSRM/セキュリティの例で使用されるファイル

ファイル

説明

build.xml

サンプルをビルドおよび実行するためのターゲットが含まれたビルド・ファイル。

ReliableEchoClientServiceImpl.java

ReliableEchoService WebサービスのechoOneWayおよびecho操作をセキュアな方法で確実に呼び出すソースWebサービスを実装するJWSファイル。このJWSファイルでは、@ServiceClientアノテーションを使用して、確実に呼び出すWebサービスを指定しています。

ReliableEchoServiceImpl.java

信頼性のある宛先Webサービスを実装するJWSファイル。このJWSファイルでは、@Policyアノテーションを使用して、信頼性のあるSOAPメッセージング・アサーションを含むWS-Policyファイルを指定しています。

ws_rm_configuration.py

信頼性のあるSOAPメッセージングに必要なSAFエージェント、ファイル・ストア、JMSサーバー、およびJMSキューを構成するWLSTスクリプト。このスクリプトは、信頼性のある宛先WebサービスをホストするWebLogic Serverインスタンスに対して実行します。「すぐに使用できる」サンプル・サーバーでは、操作を確実に呼び出すソースWebサービスがすでに構成されています。

configWss.py

セキュアなSOAPメッセージングに必要な、セキュリティ・コンテキスト・トークンの資格証明プロバイダ、派生キーの資格証明プロバイダ、X.509の資格証明プロバイダ、機密性と整合性のためのキーストア、PKI資格証明マッパーなどを構成するWLSTスクリプト。このスクリプトは、ソースおよび宛先WebサービスをホストするWebLogic Serverインスタンスに対して実行します。このスクリプトを実行した後はWebLogic Serverを必ず再起動してください

configWss_Service.py

宛先WebサービスをホストするサーバーでセキュアなSOAPメッセージングのために必要となる、セキュリティ・コンテキスト・トークンの資格証明プロバイダ、派生キーの資格証明プロバイダ、X.509の資格証明プロバイダ、機密性と整合性のためのキーストアなどを構成するWLSTスクリプト。このスクリプトは、ソースおよび宛先Webサービスが2つのサーバーでホストされている場合に、宛先WebサービスをホストするWebLogic Serverインスタンスに対して実行します。このスクリプトを実行した後はWebLogic Serverを必ず再起動してください。

configWssRuntime.py

宛先Webサービスを呼び出すための鍵ペア資格証明を構成するWLSTスクリプト。

certs/testServerCertTempCert.der

サーバー側の証明書。サーバー側のBinarySecurityToken資格証明プロバイダの作成に使用されます。

certs/clientKeyStore.jks

クライアント側のキーストア。クライアント側のBinarySecurityToken資格証明プロバイダの作成に使用されます。

certs/serverKeyStore.jks

サーバー側のキーストア。サーバー側のBinarySecurityToken資格証明プロバイダの作成に使用されます。

WsrmSecurityClient.java

信頼性のあるセキュアな方法で、ソースWebLogic Webサービスを呼び出してからReliableEchoService Webサービスの操作を呼び出す、スタンドアロンのJavaクライアント・アプリケーション。

変更されたReliableEchoServiceImpl.java

ReliableEchoServiceImpl.java JWSファイルは、EXAMPLES_HOME\wl_server\examples\src\examples\webservices\wsrm_security\ReliableEchoServiceImpl.javaのJWSファイルと同じものです(変更されたポリシー・アノテーションは太字で示されています)。

例2-30 ReliableEchoServiceImpl.java

@WebService(name = "ReliableEchoPort",
serviceName = "ReliableEchoService")
@WLHttpTransport(contextPath = "WsrmSecurity", serviceUri = "ReliableEchoService")
@Policies({
@Policy(uri="policy:Wssp1.2-2007-Wssc1.3-Bootstrap-Wss1.0.xml"),
@Policy(uri="policy:Reliability1.1_SequenceSTR")}
)

@Policyアノテーションはクラス・レベルでもメソッド・レベルでも指定できます。このサンプルでは、アノテーションをクラス・レベルで使用して、事前定義済のWS-Policyファイルを指定しています。つまり、Webサービスのすべてのパブリック操作は指定されたWS-Policyファイルに関連付けられます。

変更されたconfigWss.py

ReliableEchoServiceImpl Webサービスは、関連付けられたポリシー・ファイルで課せられている要件に対応するためにWebLogic Server APIを明示的に呼び出すことはありません。また、どのセキュリティ・プロバイダ、トークン、その他のメカニズムが使用されるかを認識する必要もありません。

スクリプト・ファイルconfigWss.pyでは、WLSTを使用して、アクティブなセキュリティ・レルムのデフォルトのWebサービス・セキュリティ構成default_wssを作成および構成します。(デフォルトのWebサービス・セキュリティ構成は、別の構成を使用するように明示的にプログラミングされていないかぎり、ドメイン内のすべてのWebサービスで使用されます。)さらに、このスクリプトではx509トークンがサポートされるようにし、必要なセキュリティ・プロバイダなどを作成します。

configWss.pyファイルは、EXAMPLES_HOME\wl_server\examples\src\examples\webservices\wsrm_security\configWss.pyのファイルと同じものです(変更点は太字で示されています)。build.xmlファイルがコマンド入力を提供します。

注意:

このスクリプト内の長い行は、見やすいように書式を整えてあります。

例2-31 configWss.py

:
#Create credential provider for SCT
cpName='default_sct_cp'
wtm=defaultWss.lookupWebserviceCredentialProvider(cpName)
if wtm == None:
print 'creating new webservice credential provider : ' + cpName
wtm = defaultWss.createWebserviceCredentialProvider(cpName)
wtm.setClassName('weblogic.wsee.security.wssc.v13.sct.
ServerSCCredentialProvider')
wtm.setTokenType('sct')
cpm = wtm.createConfigurationProperty('TokenLifeTime')
cpm.setValue('43200000')
else:
print 'found exsiting bean for: ' + cpName

#Create credential provider for DK
cpName='default_dk_cp'
wtm=defaultWss.lookupWebserviceCredentialProvider(cpName)
if wtm == None:
wtm = defaultWss.createWebserviceCredentialProvider(cpName)
wtm.setClassName('weblogic.wsee.security.wssc.v13.
dk.DKCredentialProvider')
wtm.setTokenType('dk')
cpm = wtm.createConfigurationProperty('Label')
cpm.setValue('WS-SecureConversationWS-SecureConversation')
cpm = wtm.createConfigurationProperty('Length')
cpm.setValue('16')
else:
print 'found exsiting bean for: DK ' + cpName
:

変更されたconfigWss_Service.py

configWss_Service.pyスクリプトはconfigWss.pyと似ていますが、ソースと宛先のWebサービスが2つのサーバーでホストされている場合にのみ使用されます。

configWss_Service.pyファイルは、EXAMPLES_HOME\wl_server\examples\src\examples\webservices\wsrm_security\configWss_Service.pyのファイルと同じものです(変更点は太字で示されています)。build.xmlファイルがコマンド入力を提供します。

注意:

このスクリプト内の長い行は、見やすいように書式を整えてあります。

例2-32 configWss_Service.py

:
#Create credential provider for SCT
cpName='default_sct_cp'
wtm=defaultWss.lookupWebserviceCredentialProvider(cpName)
if wtm == None:
print 'creating new webservice credential provider : ' + cpName
wtm = defaultWss.createWebserviceCredentialProvider(cpName)
wtm.setClassName('weblogic.wsee.security.wssc.
v13.sct.ServerSCCredentialProvider')
wtm.setTokenType('sct')
cpm = wtm.createConfigurationProperty('TokenLifeTime')
cpm.setValue('43200000')
else:
print 'found exsiting bean for: ' + cpName

#Create credential provider for DK
cpName='default_dk_cp'
wtm=defaultWss.lookupWebserviceCredentialProvider(cpName)
if wtm == None:
wtm = defaultWss.createWebserviceCredentialProvider(cpName)
wtm.setClassName('weblogic.wsee.security.wssc.v13.dk.
DKCredentialProvider')
wtm.setTokenType('dk')
cpm = wtm.createConfigurationProperty('Label')
cpm.setValue('WS-SecureConversationWS-SecureConversation')
cpm = wtm.createConfigurationProperty('Length')
cpm.setValue('16')
else:
print 'found existing bean for: DK ' + cpName
:

サンプルのビルドおよび実行

新しいポリシー・ネームスペースを使用するようサンプルを変更した後、EXAMPLES_HOME\wl_server\examples\src\examples\webservices\wsrm_security\instructions.htmlファイルの手順に従って、サンプルをビルドおよび実行します。

この手順の変更は不要です。

Webサービス原子性トランザクションの保護

Webサービスの原子性トランザクションを使用する際には(『Oracle WebLogic Server JAX-WS Webサービスの開発』のWebサービスの原子性トランザクションの使用に関する項を参照)、次のいずれかの事前定義済ポリシーを使用して、コーディネーション・コンテキストとIssuedTokensを含むアプリケーション・メッセージ・ヘッダーを保護してください。

- Wssp1.2-2007-SignAndEncryptWSATHeaders.xml: WS-AtomicTransactionヘッダーが署名および暗号化されることを指定します。

- Wssp1.2-2007-Wsp1.5-SignAndEncryptWSATHeaders.xml: WS-AtomicTransactionヘッダーが署名および暗号化されることを指定します。Web Services Policy 1.5が使用されます。

注意:

ヘッダーの暗号化はWS-Security 1.1標準の一部として提供されているため、アプリケーション・リクエスト・メッセージを保護する際には、前述のポリシーとともにWS-Security 1.1のバインディング・ポリシーのみを使用することを強くお薦めします。WS-Security 1.1のバインディング・ポリシーでは、ポリシーに<sp:Wss11>アサーションが含まれ、事前定義済のポリシー名に-Wss1.1が含まれています。WS-Security 1.0のポリシーを使用すると、ヘッダーがWS-Security 1.0の規格外の形式に暗号化されます。

次のいずれかの方法でポリシーをアタッチします。

- 設計時には、@Policyおよび@Policiesアノテーションを使用します(「JAX-WS Webサービスにセキュリティを追加する例」を参照)。

- デプロイメント時には、WebLogic Server管理コンソールを使用します(「管理コンソールを使用した実行時のポリシー・ファイルの関連付け」を参照)。

次の例は、@Policyおよび@Policiesアノテーションを使用して、Webサービスの原子性トランザクションをプログラム的に保護する方法を示しています。関連するコードは太字で示されています。

package jaxws.interop.rsp;
...
import javax.jws.WebService;
import javax.xml.ws.BindingType;
import weblogic.wsee.wstx.wsat.Transactional;
import weblogic.wsee.wstx.wsat.Transactional.TransactionalFlowType;
import weblogic.wsee.wstx.wsat.Transactional.Version;
import weblogic.jws.Policy;
import weblogic.jws.Policies;
...
@WebService(
portName = "FlightServiceBindings_Basic",
serviceName = "FlightService",
targetNamespace = "http://wsinterop.org/samples",
wsdlLocation = "/wsdls/FlightService.wsdl",
endpointInterface = "jaxws.interop.rsp.IFlightService"
)
@BindingType("http://schemas.xmlsoap.org/wsdl/soap/http")
@javax.xml.ws.soap.Addressing
public class FlightServiceImpl implements IFlightService {
...
@Transactional(value = Transactional.TransactionFlowType.SUPPORTS,
version = Transactional.Version.WSAT12)
@Policies({
@Policy(uri="policy:Wssp1.2-2007-EncryptBody.xml"
@Policy(uri="policy:Wssp1.2-2007-SignAndEncryptWSATHeaders.xml"
@Policy(uri="policy:Wssp1.2-2007-SignBody.xml"
@Policy(uri="policy:Wssp1.2-2007-Wss1.1-X509-Basic256.xml"
})
public FlightReservationResponse reserveFlight(FlightReservationRequest request) {
//replace with your impl here
FlightReserverationEnitity entity = new FlightReserverationEnitity();
entity.setAirlineID(request.getAirlineID());
entity.setFlightNumber(request.getFlightNumber());
entity.setFlightType(request.getFlightType());
boolean successful = saveRequest(entity);
FlightReservationResponse response = new FlightReservationResponse();
if (!successful) {
response.setConfirmationNumber("OF" +  CONF_NUMBER++ + "-" + request.getAirlineID() +
String.valueOf(entity.getId()));
} else if (request.getFlightNumber() == null ||
request.getFlightNumber().trim().endsWith("LAS"))   {
successful = false;
response.setConfirmationNumber("OF" + "- No flight available for " +
request.getAirlineID());
} else {
response.setConfirmationNumber("OF" +  CONF_NUMBER++ + "-" + request.getAirlineID() +
String.valueOf(entity.getId()));
}
response.setSuccess(successful);
return response;
}

プロプライエタリのWebサービス・セキュリティ・ポリシー・ファイル(JAX-RPCのみ)

WS-SecurityPolicy仕様が規定される以前の旧リリースのWebLogic Serverでは、WS-Policy仕様に基づき、プロプライエタリのセキュリティ・ポリシー・スキーマを使用して記述されたセキュリティ・ポリシー・ファイルを使用していました。

注意:

Webサービス・セキュリティ・ポリシー・スキーマに基づいて記述されたセキュリティ・ポリシー・ファイルは、このリリースで非推奨になりました。

WS-SecurityPolicy 1.2ポリシー・ファイルとプロプライエタリのWebサービス・セキュリティ・ポリシー・スキーマ・ファイルには、相互の互換性はありません。したがって、1つのWebサービスに、両方のタイプのポリシー・ファイルを定義することはできません。WS-Security 1.1機能を使用する場合は、WS-SecurityPolicy 1.2ポリシー・ファイル形式を使用する必要があります。

この項では、WebLogic Serverに事前定義済のWebサービス・セキュリティ・ポリシー・スキーマ・ファイルについて説明します。これらは、すべて抽象ポリシー・ファイルです。詳細については、「抽象および具象ポリシー・ファイル」を参照してください。

WebLogic Webサービスのメッセージ・レベルのセキュリティを構成するために、これらのセキュリティ・ポリシー・ファイルで使用されるポリシー・アサーションは、Web Services Security Policy Language (WS-SecurityPolicy)仕様(2002年12月18日付)に記述されているアサーションに基づいています。つまり、WebLogic Serverのアサーションの正確な構文と使用方法は、この仕様で説明されているアサーションとは異なっていますが、意味上の違いはありません。これらのアサーションには、これ以降の仕様の更新は反映されていません。

事前定義済のWebサービス・セキュリティ・ポリシーには次のものがあります。

- Auth.xml: クライアントが自身を認証する必要があることを指定します。単独で使用することも、Sign.xmlやEncrypt.xmlと併用することもできます。

- Sign.xml: SOAPメッセージがデジタル署名されることを指定します。単独で使用することも、Auth.xmlやEncrypt.xmlと併用することもできます。

- Encrypt.xml: SOAPメッセージが暗号化されることを指定します。単独で使用することも、Auth.xmlやSign.xmlと併用することもできます。

- Wssc-dk.xml: WS-SecureConversation仕様に従って、複数のメッセージを交換する際にクライアントとサービスがセキュリティ・コンテキストを共有すること、および派生キーが暗号化とデジタル署名に使用されることを指定します。

注意:

この事前定義済のポリシー・ファイルはAuth.xml、Sign.xml、Encrypt.xml、またはWssc-sct.xmlで使用されるのではなく、そのファイル自体で使用されます。また、Oracleは、クライアントとサービスにセキュリティ・コンテキストを共有するためにWssc-sct.xml ( Wssc-sct.xml)よりむしろ高いレベルのセキュリティのためこのポリシー・ファイルを使用することを薦めます。

- Wssc-sct.xml: WS-SecureConversation仕様に従って、複数のメッセージを交換する際にクライアントとサービスがセキュリティ・コンテキストを共有することを指定します。

注意:

この事前定義済のポリシー・ファイルはAuth.xml、Sign.xml、Encrypt.xml、またはWssc-dk.xmlで使用されるのではなく、そのファイル自体で使用されます。また、Oracleは、 WS-SecureConversation仕様に関するさまざまなユース・ケースをサポートするためにこのポリシー・ファイルを提供します。 ただし、高いレベルのセキュリティでクライアントとサービスにセキュリティ・コンテキストを共有するためにWssc-sct.xml ( Wssc-sct.xml),よりむしろWssc-dk.xml ( Wssc-dk.xml)ポリシー・ファイルを使用することを薦めます。

抽象および具象ポリシー・ファイル

WebLogic Webサービス実行時環境では、抽象と具象という若干異なる2種類のセキュリティ・ポリシー・ファイルが認識されます。

抽象ポリシー・ファイルでは、認証、暗号化、およびデジタル署名に使用されるセキュリティ・トークンが明示的に指定されません。Webサービス実行時環境がWebサービスがデプロイされるときにセキュリティ・トークンを決定します。つまり具体的には、ポリシー・ファイルの<Identity>および<Integrity>要素(またはアサーション)には<SupportedTokens><SecurityToken>子要素が含まれず、ポリシー・ファイルの<Confidentiality>要素には<KeyInfo><SecurityToken>子要素が含まれません。

Webサービスが事前定義済のポリシー・ファイルのみに関連付けられている場合は、クライアント認証でユーザー名トークンが必要になります。Webサービスでは、暗号化とデジタル署名用のトークン・タイプは1つしかサポートされていません(X.509)。つまり、<Integrity>要素および<Confidentiality>要素が使用される場合でも、抽象ポリシー・ファイルと具象ポリシー・ファイルは結果として本質的には同じになります。

Webサービスが抽象ポリシー・ファイルに関連付けられ、そのファイルがWSDLの添付ファイルとして公開される場合(デフォルトの動作)、Webサービスのアーカイブ・ファイル(JARまたはWAR)にパッケージ化される静的WSDLファイルは、デプロイされたWebサービスの動的WSDLファイルとは若干異なります。つまり、抽象的な静的WSDLには特定の<SecurityToken>要素が含まれていないのに対し、動的WSDLにはこうした要素が含まれています。これは、サービスがデプロイされるときにWebサービス・ランタイムによってこれらの要素が自動的に設定されるためです。このためクライアント・アプリケーションでJAX-RPCスタブを作成するコードでは、操作を呼び出そうとするとき、ダイナミックなWSDLを確実に指定してください。そうでないとランタイム・エラーが発生します:HelloService service = new HelloService(Dynamic_WSDL);

この場合、clientgen Antタスクには静的WSDLと動的WSDLのどちらでも指定できます。デプロイされたWebサービスの動的WSDLの参照については、『Oracle WebLogic Server JAX-RPC Webサービスの開発』のWebサービスのWSDLの参照に関する項を参照してください。

具象ポリシー・ファイルでは、Webサービスのプログラミング時にセキュリティ・トークンの詳細を明示的に指定します。サービスのプログラミング時に、認証のタイプの詳細(x509トークンまたはSAMLトークンの使用など)や、キーストアの複数の秘密鍵と証明書のペアが暗号化とデジタル署名に使用されるかどうかなどがわかっている場合は、具象セキュリティ・ポリシー・ファイルを作成します。

Auth.xml

次に示すWebLogic Server Auth.xmlファイルでは、Webサービスを呼び出すクライアント・アプリケーションが、認証をサポートしているトークンのいずれか(ユーザー名またはX.509)を使用して自身を認証する必要があることを指定します。

事前定義済のWebサービス・セキュリティ・ポリシー・スキーマ・ファイルは抽象ファイルです。そのため、開発時にはAuth.xmlファイルに特定のユーザー名やX.509トークンのアサーションはありません。ユーザーがWebLogic Serverに対してどのようにセキュリティを構成したかによって、ユーザー名トークン、X.509トークン、またはその両方が、Webサービスに関連付けられた実際の実行時バージョンのAuth.xmlポリシー・ファイルに示されます。さらに、実行時バージョンのポリシー・ファイルにあるX.509トークンがクライアントの呼出しに適用される場合は、SOAPメッセージの本文全体が署名されます。

アイデンティティとしてX.509のみを使用する(ユーザー名トークンは使用しない)ことを指定する場合、またはアイデンティティとしてX.509を使用しているときにSOAPメッセージの特定の部分のみに署名することを指定する場合は、カスタム・セキュリティ・ポリシー・ファイルを作成する必要があります。

例2-33 Auth.xml

<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
>
<wssp:Identity/>
</wsp:Policy>

Sign.xml

WebLogic ServerのSign.xmlファイルでは、SOAPメッセージの本文およびWebLogic固有のシステム・ヘッダーにデジタル署名することを指定します。また、デジタル署名されたタイムスタンプをSOAPメッセージに含めること、および署名に使用するトークンにもデジタル署名することを指定します。署名に使用するトークンはSOAPメッセージに含まれます。

次のヘッダーは、Sign.xmlセキュリティ・ポリシー・ファイルの使用時に署名されます。

- SequenceAcknowledgement

- AckRequested

- Sequence

- Action

- FaultTo

- From

- MessageID

- RelatesTo

- ReplyTo

- To

- SetCookie

- Timestamp

WebLogic ServerのSign.xmlファイルを次に示します。

例2-34 Sign.xml

<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
>
<wssp:Integrity>
<wssp:SignatureAlgorithm URI="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<wssp:CanonicalizationAlgorithm
URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1" />
<wssp:MessageParts
Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SystemHeaders()
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1" />
<wssp:MessageParts
Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SecurityHeader(wsu:Timestamp)
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1" />
<wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
</wssp:Integrity>
<wssp:MessageAge/>
</wsp:Policy>

Encrypt.xml

WebLogic ServerのEncrypt.xmlファイルでは、SOAPメッセージの本文全体を暗号化することを指定します。デフォルトでは、暗号化トークンはSOAPメッセージに含まれません。

例2-35 Encrypt.xml

<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
>
<wssp:Confidentiality>
<wssp:KeyWrappingAlgorithm URI="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<wssp:Target>
<wssp:EncryptionAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
<wssp:KeyInfo/>
</wssp:Confidentiality>
</wsp:Policy>

Wssc-dk.xml

WS-SecureConversation仕様のとおりに、クライアントとWebサービスでセキュリティ・コンテキストを共有すること、および派生キー・トークンを使用することを指定します。これにより、最も高度なセキュリティを確保できます。

このポリシー・ファイルでは以下の構成が提供されます。

- 派生キー・トークンを使用して、すべてのシステムSOAPヘッダー、タイムスタンプ・セキュリティSOAPヘッダー、およびSOAP本文を署名します。

- 派生キー・トークンを使用して、SOAPメッセージの本文を暗号化します。これは、署名に使用されるものとは別のトークンです。

- 各SOAPメッセージで派生キーの固有のペアを使用します。

- デジタル署名と暗号化の両方において、キー長をデフォルトの32ではなく16とします。

- セキュリティ・コンテキストの存続期間を12時間とします。

デフォルトのセキュリティ・コンテキストと派生キーの動作を変更する場合は、後の項で説明するカスタム・セキュリティ・ポリシー・ファイルを作成する必要があります。

注意:

この事前定義済セキュリティ・ポリシー・ファイルを指定する場合、他の事前定義済セキュリティ・ポリシー・ファイルは指定しないでください。

例2-36 Wssc-dk.xml

<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
>
<wssp:Integrity SupportTrust10="true">
<wssp:SignatureAlgorithm URI="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
<wssp:CanonicalizationAlgorithm URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SystemHeaders()
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SecurityHeader(wsu:Timestamp)
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
<wssp:SupportedTokens>
<wssp:SecurityToken IncludeInMessage="true"
TokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/dk"
DerivedFromTokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct">
<wssp:Claims>
<wssp:Label>WS-SecureConversationWS-SecureConversation</wssp:Label>
<wssp:Length>16</wssp:Length>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Integrity>
<wssp:Confidentiality SupportTrust10="true">
<wssp:Target>
<wssp:EncryptionAlgorithm URI="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()</wssp:MessageParts>
</wssp:Target>
<wssp:KeyInfo>
<wssp:SecurityToken IncludeInMessage="true"
TokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/dk"
DerivedFromTokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct">
<wssp:Claims>
<wssp:Label>WS-SecureConversationWS-SecureConversation</wssp:Label>
<wssp:Length>16</wssp:Length>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:KeyInfo>
</wssp:Confidentiality>
<wssp:MessageAge/>
</wsp:Policy>

Wssc-sct.xml

WS-SecureConversation仕様のとおりに、クライアントとWebサービスでセキュリティ・コンテキストを共有することを指定します。この場合、セキュリティ文脈トークンは、SOAPメッセージを暗号化して、署名するのに使用されます(派生している主要なトークンが使用されているWssc-dk.xml ( Wssc-dk.xml)と異なっています)。最大のセキュリティのために、Wssc-sct.xmlポリシー・ファイルは仕様に関するすべての使用例がサポートするために提供します。 しかし、Oracleは、より高いレベルのセキュリティのため共有されたセキュリティ文脈を指定するとき、いつもWssc-dk.xml ( Wssc-dk.xml)を使用することを薦めます。

このセキュリティ・ポリシー・ファイルでは以下の構成が提供されます。

- セキュリティ・コンテキスト・トークンを使用して、すべてのシステムSOAPヘッダー、タイムスタンプ・セキュリティSOAPヘッダー、およびSOAP本文を署名します。

- セキュリティ・コンテキスト・トークンを使用して、SOAPメッセージの本文を暗号化します。

- セキュリティ・コンテキストの存続期間を12時間とします。

デフォルトのセキュリティ・コンテキストと派生キーの動作を変更する場合は、後の項で説明するカスタム・セキュリティ・ポリシー・ファイルを作成する必要があります。

注意:

この事前定義済セキュリティ・ポリシー・ファイルを指定する場合、他の事前定義済セキュリティ・ポリシー・ファイルは指定しないでください。

例2-37 Wssc-sct.xml

<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
>
<wssp:Integrity SupportTrust10="true">
<wssp:SignatureAlgorithm URI="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
<wssp:CanonicalizationAlgorithm URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SystemHeaders()
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SecurityHeader(wsu:Timestamp)
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
<wssp:SupportedTokens>
<wssp:SecurityToken IncludeInMessage="true"
TokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct">
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Integrity>
<wssp:Confidentiality SupportTrust10="true">
<wssp:Target>
<wssp:EncryptionAlgorithm URI="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()</wssp:MessageParts>
</wssp:Target>
<wssp:KeyInfo>
<wssp:SecurityToken IncludeInMessage="true"
TokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct">
</wssp:SecurityToken>
</wssp:KeyInfo>
</wssp:Confidentiality>
<wssp:MessageAge />
</wsp:Policy>

3 トランスポート・レベルのセキュリティの構成

この章ではJava API for XML Web Services (JAX-WS)とJava API for XML-based RPC (JAX-RPC)を使用して、WebLogic Webサービスでトランスポート・レベルのセキュリティを構成する方法について説明します。

トランスポート・レベルのセキュリティとは、クライアント・アプリケーションとWebサービスとの間の接続をSecure Sockets Layer (SSL)で保護することです。

SSLでは、ネットワーク接続している2つのアプリケーションが互いのアイデンティティを認証できるようにするとともに、アプリケーション間でやりとりされるデータを暗号化することでセキュアな接続が実現します。認証を使用すると、サーバー(および必要に応じてクライアント)はネットワーク接続の相手側アプリケーションのIDを検証できます。クライアント証明書(双方向SSL)を使用してユーザーを認証できます。

SSLの一般情報とWebLogic Serverに含まれる実装については、『Oracle WebLogic Serverセキュリティの理解』のSecure Sockets Layer (SSL)に関する項を参照してください。

トランスポート・レベルのセキュリティには、SSLだけでなくHTTP基本認証も含まれます。

この章の内容は次のとおりです:

- ポリシーによるトランスポート・レベルのセキュリティの構成

- 使用可能なトランスポート・レベルのポリシー

- 前提条件: SSLの構成

- ポリシーによるトランスポート・レベルのセキュリティの構成: 主な手順

- JAX-WSのトランスポート・セキュリティの構成例

- SSLにおけるリクエストの状態の永続化(JAX-WSのみ)

- UserDataConstraintによるトランスポート・レベルのセキュリティの構成: 主な手順(JAX-RPCのみ)

- 信頼性のあるメッセージングでのカスタムSSLアダプタの使用(JAX-RPCのみ)

ポリシーによるトランスポート・レベルのセキュリティの構成

WebLogic Serverにはトランスポート・レベルの事前定義済ポリシー・ファイルが含まれています。このファイルは「使用可能なトランスポート・レベルのポリシー」で説明されています。これは一般的に、大半のプログラマとユース・ケースのセキュリティ・ニーズを満たします。

追加の構成が必要な場合、「カスタム・ポリシー・ファイルの作成と使用」に記載されているように、独自のWS-SecurityPolicyファイルを作成して使用することもできます。これを行う必要がある場合、事前定義済のWS-SecurityPolicyファイルをテンプレートとして使用して、独自のカスタム・ファイルを作成できます。.xmlポリシー・ファイルは、WL_HOME/server/lib/weblogic.jarにあります。weblogic.jar内で、ポリシー・ファイルは/weblogic/wsee/policy/runtimeに位置しています。

たとえば、Oracle提供のWssp1.2-2007-Saml2.0-Bearer-Https.xmlポリシー・ファイルには、ポリシーで一方向SSLが必要なことを示す次のアサーションが含まれています(例3-1を参照)。

例3-1 ポリシーでのSSLの指定

<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken/>
</wsp:Policy>
</sp:TransportToken>

かわりに双方向SSLを使用する必要がある場合、例3-2に示されているようにRequireClientCertificateアサーションを追加するカスタム・ポリシーを作成できます。

例3-2 ポリシーでの双方向SSLの指定

<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken >
<wsp:Policy>
<sp:RequireClientCertificate/>
</wsp:Policy>
</sp:HttpsToken>
</wsp:Policy>
</sp:TransportToken>

Wssp1.2-2007-Https-BasicAuth.xmlポリシー・ファイルでは、例3-3に示すように、SSLとHTTP基本認証の両方が必要です。

例3-3 ポリシーでのSSLおよびHTTP基本認証

<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken>
<wsp:Policy>
<sp:HttpBasicAuthentication/>
</wsp:Policy>
</sp:HttpsToken>
</wsp:Policy>
</sp:TransportToken>

使用可能なトランスポート・レベルのポリシー

これらのポリシーでは、WSDLへのアクセスおよびWebサービス操作の呼出しに、httpsプロトコルを使用する必要があります。

表3-1 トランスポート・レベルのポリシー

ポリシー・ファイル

説明

Wssp1.2-2007-Saml2.0-Bearer-Https.xml

一方向SSLは、認証用にBearer確認メソッドがあるSAML 2.0トークンを使用します。

Wssp1.2-2007-Saml2.0-Bearer-Https-Basic256Sha256.xml

Wssp1.2-2007-Saml2.0-Bearer-Https.xmlと同じですが、Sha-256のより強力なハッシュ・アルゴリズムを使用します。

Wssp1.2-2007-Saml1.1-Bearer-Https.xml

一方向SSLでは、SAML 1.1トークンを使用し、Bearer確認メソッドによって認証を行います。

Wssp1.2-2007-Saml1.1-Bearer-Https-Basic256Sha256.xml

Wssp1.2-2007-Saml1.1-Bearer-Https.xmlと同じですが、Sha-256の強力ハッシュ・アルゴリズムを使用します。

Wssp1.2-2007-Https.xml

一方向SSL。

Wssp1.2-2007-Https-BasicAuth.xml

基本認証による一方向SSL。リクエストに認可ヘッダーが含まれていない場合は401チャレンジが発生します。

Wssp1.2-2007-Https-ClientCertReq.xml

双方向SSL。受信側で、発信元のパブリック証明書をチェックします。認証にクライアント証明書を使用することも可能です。

相互クライアント証明書の動作を「クライアント証明書をリクエスト(強制しない)」に設定します。設定方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの双方向SSLの構成に関する項を参照してください。

Wssp1.2-2007-Https-UsernameToken-Digest.xml

ダイジェスト・ユーザー名トークンによる一方向SSL。

Wssp1.2-2007-Https-UsernameToken-Plain.xml

プレーン・テキスト・ユーザー名トークンによる一方向SSL。

Wssp1.2-2007-Https-UsernameToken-Plain-Basic256Sha256.xml

Wssp1.2-2007-Https-UsernameToken-Plain.xmlと同じですが、Sha-256のより強力なハッシュ・アルゴリズムを使用します。

Wssp1.2-Https.xml

一方向SSL。

Wssp1.2-Https-BasicAuth.xml

基本認証による一方向SSL。リクエストに認可ヘッダーが含まれていない場合は401チャレンジが発生します。

Wssp1.2-Https-UsernameToken-Digest.xml

ダイジェスト・ユーザー名トークンによる一方向SSL。

Wssp1.2-Https-UsernameToken-Plain.xml

プレーン・テキスト・ユーザー名トークンによる一方向SSL。

Wssp1.2-Https-ClientCertReq.xml

双方向SSL。受信側で、発信元のパブリック証明書をチェックします。認証にクライアント証明書を使用することも可能です。

前提条件: SSLの構成

トランスポート・レベルのポリシーを使用してWebサービスを保護するには、WebLogic Serverのコア・セキュリティ・サブシステムでSSLを構成しておく必要があります。

すぐに使用できる秘密鍵とX.509証明書のペアは、デモやテストの目的で提供されています。このため、本番では独自のキーストアおよびキー・ペアを使用することを強くお薦めします。

一方向のSSL (WebLogic Serverがクライアント・アプリケーションに証明書を提示する必要がある)、または双方向のSSL (クライアント・アプリケーションとWebLogic Serverが両方とも互いに証明書を提示する必要がある)のいずれかを構成できます。

WebLogic Serverのコア・セキュリティ・サブシステムに対して双方向または一方向のSSLを構成する場合は、『Oracle WebLogic Serverセキュリティの管理』のSSLの構成に関する項を参照してください。

WebLogic Serverで双方向SSLを構成する場合、「クライアント・アプリケーションでの双方向SSLの構成」に記載されているように、クライアント・アプリケーションでもSSLを構成する必要があります。

SSLの構成: 主な手順

この項では、「SSLの設定: 主な手順」に記載されている手順をまとめます。便宜上、ここに手順を記載します。詳細は、「SSLの設定: 主な手順」を参照してください。

SSLを設定するには:

1. アイデンティティと信頼を構成します(「アイデンティティと信頼の構成」を参照)。

注意:

OPSSキーストア・サービスはサポートされません。

1. CertGenユーティリティ、keytoolユーティリティ、またはEntrustやVerisignなどの信頼できるベンダーから、デジタル証明書、秘密鍵および信頼性のあるCA証明書を取得します。WebLogic Serverのキットに用意されているデジタル証明書、秘密鍵、および信頼性のあるCA証明書を使用することもできます。デモ用のデジタル証明書、秘密鍵、および信頼性のあるCA証明書は、開発環境でのみ使用してください。

2. 秘密鍵、デジタル証明書、および信頼性のあるCA証明書を格納します。秘密鍵と信頼性のあるCA証明書は、キーストアに格納します。

3. WebLogic Server管理コンソールで、WebLogic ServerのIDキーストアと信頼キーストアを構成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのキーストアの構成に関する項を参照してください。

2. WebLogic管理コンソールで、秘密鍵の別名とパスワードに関するSSL構成オプションを設定します。
必要な場合、クライアント証明書の提示を必須とする構成オプションを設定します(双方向SSLの場合)。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの双方向SSLの構成に関する項を参照してください。

クライアント・アプリケーションでの双方向SSLの構成

注意:

非同期の、または信頼性のあるメッセージングを使用するWebサービスでは、非同期のレスポンスや確認応答を送信する目的で(受信側サービスから送信側サービスに向けて)新しい接続を確立するときに、サーバーのSSL証明書を自動的に使用します。

WebLogic Serverで双方向SSLを構成した場合は、一方向SSLで必要とされるようにWebLogic Serverがクライアント・アプリケーションに証明書を提示するだけでなく、クライアント・アプリケーションがWebLogic Serverに証明書を提示する必要があります。さらに、次の要件も満たす必要があります:

- クライアントの秘密鍵とX.509証明書のペアが格納されたクライアント側キーストアを作成します。
Java SEのSSLパッケージでは、クライアントの秘密鍵のパスワードはクライアントのキーストアのパスワードと同じでなければなりません。そのため、クライアント・キーストアには秘密鍵とX.509証明書のペアを1つしか格納できません。

- WebLogic Serverのコア・セキュリティ・サブシステムを構成して、クライアント・キーストア内のクライアントのX.509証明書をユーザーにマップします。『Oracle WebLogic Serverセキュリティの管理』のユーザー名マッパーの構成に関する項を参照してください。

- クライアントが信頼する証明書を格納する信頼ストアを作成します。クライアント・アプリケーションはこの信頼ストアを使用して、WebLogic Serverから受け取った証明書を検証します。前の項目で説明したJava SEのパスワード要件のため、この信頼ストアは、クライアントがサーバーに提示するキー・ペアを格納するキーストアとは異なっている必要があります。
Cert Genユーティリティやkeytoolユーティリティ(http://docs.oracle.com/javase/7/docs/technotes/tools/windows/keytool.html)を使用して、この手順を実行できます。開発が目的の場合は、keytoolユーティリティを使用すると簡単に開始できます。

『Oracle WebLogic Serverセキュリティの管理』の秘密鍵、デジタル証明書および信頼性のある認証局の取得に関する項を参照してください。

- 相互クライアント証明書の動作を「クライアント証明書をリクエスト(強制しない)」に設定します。設定方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの双方向SSLの構成に関する項を参照してください。

- Webサービスを呼び出すクライアント・アプリケーションを実行するときに、次のプロパティを指定します。

- -Djavax.net.ssl.trustStore=trustStore

- -Djavax.net.ssl.trustStorePassword=trustStorePassword
trustStoreには、信頼性のある証明書のリスト(必ずサーバーの証明書を1つ含む)を格納するクライアント側の信頼ストアの名前を指定し、trustStorePasswordには、信頼ストアのパスワードを指定します。

上記のプロパティは、クライアント側キーストアを指定するために設定する必要のある標準的なプロパティに追加されるものです。

- -Djavax.net.ssl.keyStore=keyStore

- -Djavax.net.ssl.keyStorePassword=keyStorePassword

ポリシーによるトランスポート・レベルのセキュリティの構成: 主な手順

1つまたは複数のポリシー・ファイルを使用してトランスポート・レベルのWebサービス・セキュリティを構成するには:

1. 「前提条件: SSLの構成」に記載されているように、WebLogic Serverコア・セキュリティ・サブシステムに対してSSLを構成します。
一方向のSSL (WebLogic Serverがクライアント・アプリケーションに証明書を提示する必要がある)、または双方向のSSL (クライアント・アプリケーションとWebLogic Serverが両方とも互いに証明書を提示する必要がある)のいずれかを構成できます。

WebLogic Serverのコア・セキュリティ・サブシステムに対して双方向または一方向のSSLを構成する場合は、『Oracle WebLogic Serverセキュリティの管理』のSSLの構成に関する項を参照してください。

2. JWSファイルで@Policyまたは@Policies JWSアノテーションを使用するか、管理コンソールを使用して実行時にポリシー・ファイルを関連付けます。あるいは、アノテーションを使用して一部のポリシー・ファイルを指定し、実行時に追加のポリシー・ファイルを関連付けます。
使用可能なトランスポート・レベルのポリシーの詳細は、表3-1を参照してください。

注意:

Webサービスにトランスポート・レベルのセキュリティ・ポリシーを指定する場合、ポリシーの指定はクラス・レベルで行う必要があります。

また、トランスポート・レベルのセキュリティ・ポリシーは着信方向と発信方向の両方に適用する必要があります。つまり、着信にHTTPSを使用し、発信にHTTPを使用することはできません。

次の例では、ポリシーをクラス・レベルでアタッチしています。

@Policy(uri="policy:Wssp1.2-2007-Saml2.0-Bearer-Https.xml")
public class EchoService {
....

3. JWSファイルに@Policyまたは@Policies JWSアノテーションを追加した場合は、通常の反復的開発プロセスの一環として、Webサービスをコンパイルして再デプロイします。

4. Webサービスを呼び出すクライアント・アプリケーションを実行するときは、アプリケーションで使用するSSL実装を示す特定のプロパティを指定します。特に、次の場合です。

- SunのSSL実装を指定するには、次のプロパティを使用します。

-Djavax.net.ssl.trustStore=trustStore

trustStoreには、信頼性のある証明書のリスト(必ずサーバーの証明書を1つ含む)を格納するクライアント側の信頼ストアの名前を指定します。ホスト名検証を無効にするには、次のプロパティも指定します。

-Dweblogic.wsee.client.ssl.stricthostchecking=false

双方向SSLの詳細は、「クライアント・アプリケーションでの双方向SSLの構成」を参照してください。

JAX-WSのトランスポート・セキュリティの構成例

この項では、スタンドアロンの一方向SSLクライアントからトランスポート・セキュリティを使用したJAX-WSを構成するための単純な例について説明します。

その他の前提条件については、次のドキュメントを参照してください。

- 『Oracle WebLogic Serverセキュリティの管理』のSSLの構成に関する項

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSSLの構成に関する項

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのキーストアの構成に関する項

一方向SSL (HTTPSおよびHTTP基本認証の例)

WebサービスのJavaソースを例3-4に示します。

注意:

Webサービスにトランスポート・レベルのセキュリティ・ポリシーを指定する場合、ポリシーの指定はクラス・レベルで行う必要があります。

また、トランスポート・レベルのセキュリティ・ポリシーは着信方向と発信方向の両方に適用する必要があります。つまり、着信にHTTPSを使用し、発信にHTTPを使用することはできません。

例3-4 Webサービスの一方向SSLの例

package httpbasicauth
import javax.jws.WebMethod;
import javax.jws.WebService;

import weblogic.jws.Policy;

@WebService(name="HttpsBasicAuth", portName="HttpsBasicAuthSoapPort"
targetNamespace="https://httpsbasicauth")

// Security Policy for Https and Http Basic Authentication
@Policy(uri = "policy:Wssp1.2-2007-Https-BasicAuth.xml)

public class HttpsBasicAuth {

public HttpsBasicAuth() {}

WebMethod()
public String echoString(String input) {

return("[HttpsBasicAuth.echoString]: " + input);

}

}

weblogic.netをJavaプロトコル・ハンドラとして使用するスタンドアロンのJava Webサービス・クライアントのコードを例3-5に示します。

例3-5 weblogic.netを使用するWebサービス・クライアントの一方向SSLの例

package httpbasicauth.client

import java.net.URL;
import java.security.cert.X509Certificate;
import java.util.Map;

import javax.xml.namespace.QName;

import javax.xml.ws.BindingProvider;

import httpsbasicauth.client.HttpsBasicAuthService;
import httpsbasicauth.client.HttpsBasicAuth;

public class HttpsBasicAuthClient

private final static String ENDPOINT = .....;
private final static String TARGET_NAMESPACE = "https://httpsbasicauth
private final static String USERNAME = ....;
private final static String PASSWORD = ....;
private final static String TRUST_STORE_LOCATION = .....;
private final static String TARGET_NAMESPACE = ....;

private HttpsBasicAuthService service;
private HttpsBasicAuth stub;

public HttpsBasicAuthClient() {

try {
// This ignores the host name verifcation for the Public Certificate used by the Server
System.setProperty("weblogic.security.SSL.ignoreHostnameVerification","true");

System.setProperty("java.protocol.handler.pkgs", "weblogic.net");
System.setProperty("weblogic.security.TrustKeyStore","CustomTrust");
System.setProperty("weblogic.security.CustomTrustKeyStoreFileName", "TRUST_STORE_LOCATION");
System.setProperty("weblogic.security.CustomTrustKeyStorePassPhrase","TRUST_STORE_PASSWORD");
System.setProperty("weblogic.security.CustomTrustKeyStoreType","JKS");

URL url = new URL(endpoint+"?WSDL");
QName serviceName = new QName(TARGET_NAMESPACE, "HttpsBasicAuthService");

service = new HttpsBasicAuthService();

stub = service.getHttpsBasicAuthSoapPort();

BindingProvider bp = (BindingProvider) stub;

Map<String,Object> context = bp.getRequestContext();

context.put(BindingProvider.USERNAME_PROPERTY, USERNAME)
context.put(BindingProvider.PASSWORD_PROPERTY, PASSWORD);
context.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, ENDPOINT);

} catch (Exception e) {
System.out.println("Error in creating the stub : " + e.getMessage());
if (verbose) e.printStackTrace();
}
}

public void invokeEchoString() throws Exception {

String output = stub.echoString(ENDPOINT);

System.out.println("[HttpsBasicAuthClient.invokeGEchoString]: " + output);

}

public static void main(String[] argv) throws Exception {

HttpsBasicAuthClient client = new HttpsBasicAuthClient();

System.setProperty("weblogic.wsee.verbose","*");

System.out.println("----------------------");
System.out.println("            Invoking echoString            ");
client.invokeEchoString();

}

}

デフォルトのJavaプロトコル・ハンドラを使用するスタンドアロンのJava Webサービス・クライアントのコードを例3-6に示します。

例3-6 java.netを使用するWebサービス・クライアントの一方向SSLの例

package httpbasicauth.client

import java.net.URL;
import java.security.cert.X509Certificate;
import java.util.Map;

import javax.xml.namespace.QName;

import javax.xml.ws.BindingProvider;

import httpsbasicauth.client.HttpsBasicAuthService;
import httpsbasicauth.client.HttpsBasicAuth;

public class HttpsBasicAuthClient

private final static String ENDPOINT = .....;
private final static String TARGET_NAMESPACE = "https://httpsbasicauth
private final static String USERNAME = ....;
private final static String PASSWORD = ....;
private final static String TRUST_STORE_LOCATION = .....;
private final static String TARGET_NAMESPACE = ....;

private HttpsBasicAuthService service;
private HttpsBasicAuth stub;

public HttpsBasicAuthClient() {

try {

System.setProperty("java.protocol.handler.pkgs", "java.net");
System.setProperty("javax.net.ssl.trustStore", TRUST_STORE_LOCATION);
System.setProperty("javax.net.ssl.trustStorePassword", TRUST_STORE_PASSWORD);

URL url = new URL(ENDPOINT+"?WSDL");
QName serviceName = new QName(TARGET_NAMESPACE, "HttpsBasicAuthService");

service = new HttpsBasicAuthService();

stub = service.getHttpsBasicAuthSoapPort();

BindingProvider bp = (BindingProvider) stub;

Map<String,Object> context = bp.getRequestContext();

context.put(BindingProvider.USERNAME_PROPERTY, USERNAME)
context.put(BindingProvider.PASSWORD_PROPERTY, PASSWORD);
context.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, ENDPOINT);

} catch (Exception e) {
System.out.println("Error in creating the stub : " + e.getMessage());
if (verbose) e.printStackTrace();
}

}

public void invokeEchoString() throws Exception {

String output = stub.echoString(ENDPOINT);

System.out.println("[HttpsBasicAuthClient.invokeGEchoString]: " + output);

}

public static void main(String[] argv) throws Exception {

HttpsBasicAuthClient client = new HttpsBasicAuthClient();

System.setProperty("weblogic.wsee.verbose","*");

System.out.println("----------------------");
System.out.println("            Invoking echoString            ");
client.invokeEchoString();

}

}

Antビルド・ファイルの関連部分を例3-7に示します。

例3-7 Antビルド・ファイル

<property name="output.dir" value="../../build/httpsbasicauth" />
<property name="service.dir" value="${output.dir}/httpsbasicauthApp" />
<property name="output.dir.client" value="${output.dir}/client" />
<property name="clientclasses.dir" value="${output.dir}/client" />
<property name="service.name" value="HttpsBasicAuth" />
<property name="wsdl.name" value="HttpsBasicAuthService" />
<property name="packageName" value="httpsbasicauth.client" />

<path id="client.class.path">
<pathelement path="${java.class.path}" />
<pathelement path="${clientclasses.dir}" />
</path>

<taskdef name="clientgen"
classname="weblogic.wsee.tools.anttasks.ClientGenTask" />
<taskdef name="jwsc" classname="weblogic.wsee.tools.anttasks.JwscTask"/>

<target name="jwsc">

<jwsc srcdir="." destdir="${output.dir.server}" sourcepath="../" debug="true" keepGenerated="true">

<module name="HttpsBasicAuth" contextPath="httpsbasicauth">

<jws file="HttpsBasicAuth.java" type="JAXWS" generateWsdl="true">
<WLHttpTransport contextPath="httpsbasicauth" serviceUri="httpsbasicauth"/>
</jws>

</jwsc>

</target>

<target name="client">

<clientgen wsdl="jar:file:${service.dir}/${service.name}.war!/WEB-INF/${wsdl.name}.wsdl"
type="JAXWS"
destDir="${clientclasses.dir}"
packageName="${packageName}">

</clientgen>

<javac srcdir="${clientclasses.dir}"
destdir="${clientclasses.dir}"
includes="**/*.java"
classpathref="client.class.path" />

<javac srcdir="./"
destdir="${clientclasses.dir}"
includes="HttpsBasicAuthClient.java"
classpathref="client.class.path" />

</target>

<target name="run">

<java classname="httpsbasicauth.client.HttpsBasicAuthClient"
classpathref="client.class.path"
fork="true" />
</target>

SSLにおけるリクエストの状態の永続化(JAX-WSのみ)

JAX-RPCクライアントはSSL接続でのリクエストの状態を永続化するために、「信頼性のあるメッセージングでのカスタムSSLアダプタの使用(JAX-RPCのみ)」で説明されたSSLAdapterメカニズムを使用できます。その際に、接続の確立に使用されたカスタムSSLAdapterのインスタンスを永続化します。

Oracle WebLogic Serverには、システム・プロパティまたは新しいweblogic.wsee.jaxws.sslclient.PersistentSSLInfo classからSSLSocketFactoryを構成するために使用するJAX-WSのための双方向SSLクライアントAPIが用意されています。このAPIは、信頼性のあるメッセージング、コールバックなどのSSL情報を永続化することができ、次のよく知られたシステム・プロパティをサポートします。

- weblogic.wsee.client.ssl.relaxedtrustmanager

- weblogic.security.SSL.ignoreHostnameVerification

次の新しいクラスが使用できます。詳しい説明は、Javadocを参照してください。

- weblogic.wsee.jaxws.sslclient.SSLClientUtil。このクラスには、次のメソッドがあります。

- public static SSLSocketFactory getSSLSocketFactory(KeyManager[] kms, TrustManager[] tms)

- public static SSLSocketFactory getSSLSocketFactory(PersistentSSLInfo sslInfo)

- public static SSLSocketFactory getSSLSocketFactoryFromSysProperties()

- weblogic.wsee.jaxws.sslclient.PersistentSSLInfo (SSL情報を設定するためのJavabean)。

- weblogic.wsee.jaxws.JAXWSProperties (CLIENT_PERSISTENT_SSL_INFOプロパティを含む)。

システム・プロパティからSSLSocketFactoryを取得する例

例3-8は、システム・プロパティからSSLSocketFactoryを取得してリクエスト・コンテキストで使用する例を示しています。

注意:

clientKeyStoreとclientKeyStorePasswdには、Java SEのSSLパッケージを使用する場合に、クライアントの秘密鍵のパスワードとクライアントのキーストアのパスワードが同一であることが求められるという制約があります。そのため、クライアント・キーストアには秘密鍵とX.509証明書のペアを1つしか格納できません。

例3-8 システム・プロパティからのSSLSocketFactoryの取得

String clientKeyStore = ...;
String clientKeyStorePasswd = ...;
String trustKeystore = ...;
String trustKeystorePasswd = ...;

System.setProperty("javax.net.ssl.keyStore", clientKeyStore);
System.setProperty("javax.net.ssl.keyStorePassword", clientKeyStorePasswd);
System.setProperty("javax.net.ssl.trustStore", trustKeystore);
System.setProperty("javax.net.ssl.trustStorePasswd", trustKeystorePasswd);

((BindingProvider) port).getRequestContext().put(
JAXWSProperties.SSL_SOCKET_FACTORY,
SSLClientUtil.getSSLSocketFactoryFromSysProperties());

例3-9は、永続情報(PersistentSSLInfo)からSSLSocketFactoryを取得し、永続性が不要な場合はSSLSocketFactoryを直接設定する例を示しています。

例3-9 PersistentSSLInfoからのSSLSocketFactoryの取得

String clientKeyStore = ...;
String clientKeyStorePasswd = ...;
String clientKeyAlias = ...;
String clientKeyPass = ...;
String trustKeystore = ...;
String trustKeystorePasswd = ...;

PersistentSSLInfo sslInfo = new PersistentSSLInfo();
sslInfo.setKeystore(clientKeyStore);
sslInfo.setKeystorePassword(clientKeyStorePasswd);
sslInfo.setKeyAlias(clientKeyAlias);
sslInfo.setKeyPassword(clientKeyPass);
sslInfo.setTrustKeystore(trustKeystore);

//user can print out the sslInfo for debug
System.out.print(sslInfo.toString());

//Put sslInfo into requestContext for persistence, it might be required by JAX-WS
advance features, such as, RM, Callback
((BindingProvider) port).getRequestContext().put(
JAXWSProperties.CLIENT_PERSISTENT_SSL_INFO, sslInfo);

//Alternatively, you can directly set a SSLSocketFactory if persistence is
not necessary. Note: The following line should be omitted if sslInfo is set with
above line.
((BindingProvider) port).getRequestContext().put(
JAXWSProperties.SSL_SOCKET_FACTORY,
SSLClientUtil.getSSLSocketFactory(sslInfo));

sslInfoでは、クライアント・キーストアに複数のキーがある場合にキーストア内のキーを(SSLのクライアント側キーとして)示す、キー別名(clientKeyAlias)を設定できます。

UserDataConstraintによるトランスポート・レベルのセキュリティの構成: 主な手順(JAX-RPCのみ)

UserDataConstraintアノテーションを指定すると、HTTPSトランスポートを使用してWebサービスを呼び出すことが必要となります。

JWSファイルでUserDataConstraintアノテーションを使用してトランスポート・レベルのWebサービス・セキュリティを構成するには:

1. WebLogic Serverコア・セキュリティ・サブシステムに対してSSLを構成します。
一方向のSSL (WebLogic Serverがクライアント・アプリケーションに証明書を提示する必要がある)、または双方向のSSL (クライアント・アプリケーションとWebLogic Serverが両方とも互いに証明書を提示する必要がある)のいずれかを構成できます。

WebLogic Serverのコア・セキュリティ・サブシステムに対して双方向または一方向のSSLを構成する場合は、『Oracle WebLogic Serverセキュリティの管理』のSSLの構成に関する項を参照してください。

2. Webサービスを実装するJWSファイル内に@weblogic.jws.security.UserDataConstraintアノテーションを追加し、Webサービスの呼出しにHTTPSトランスポートの使用が必要となるようにします。
詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のweblogic.jws.security.UserDataConstraintに関する項を参照してください。

3. 通常の反復的な開発プロセスの一部として、Webサービスを再コンパイルして再デプロイします。
『Oracle WebLogic Server JAX-RPC Webサービスの開発』のWebLogic Webサービスの開発に関する項を参照してください。

4. clientgen Antタスクを呼び出すbuild.xmlファイルを更新して、WebサービスのJAX-RPCスタブの生成に、デプロイされているサービスの動的WSDLではなく、静的WSDLを使用するようにします。
この場合に、clientgenが動的WSDLからスタブを生成できない理由は、@UserDataConstraintアノテーションを指定する際に、すべてのクライアント・アプリケーションで、clientgenを含む信頼ストアを指定することが必要であるためです。ただし現在、clientgenで信頼ストアを指定する方法はありません。したがって、Antタスクは、動的WSDLと同じ方法でWebサービスを記述する静的なWSDLからクライアント・コンポーネントを生成しなければなりません。

5. Webサービスを呼び出すクライアント・アプリケーションを実行するときは、アプリケーションで使用するSSL実装を示す特定のプロパティを指定します。特に、次の場合です。

- SunのSSL実装を指定するには、次のプロパティを使用します。

-Djavax.net.ssl.trustStore=trustStore

trustStoreには、信頼性のある証明書のリスト(必ずサーバーの証明書を1つ含む)を格納するクライアント側の信頼ストアの名前を指定します。ホスト名検証を無効にするには、次のプロパティも指定します。

-Dweblogic.wsee.client.ssl.stricthostchecking=false

双方向SSLの詳細は、「クライアント・アプリケーションでの双方向SSLの構成」を参照してください。

信頼性のあるメッセージングでのカスタムSSLアダプタの使用(JAX-RPCのみ)

注意:

StubおよびMessageContextプロパティに格納されるすべてのオブジェクトは、シリアライズ可能かつ外部化可能であること、およびサーバーのシステムCLASSPATHにその実装が指定されていることが必要です。この項では、カスタムSSLAdapterを実装する場合について説明します。

カスタムSSLAdapter実装を使用すると、信頼性のあるメッセージングまたはバッファリングを使用する場合に、クライアントとサーバーの間のSSL接続を確立するために必要なクライアント証明書とその他のサービスを提供できます。信頼性のあるメッセージングおよびバッファリングのサブシステムは、SSL接続の間、リクエストの状態を永続化します。その際に、接続の確立に使用されたカスタムSSLAdapterのインスタンスを永続化します。

リクエストを永続化から復元する際に、リクエストとともに保存されていたカスタムSSLAdapterオブジェクトを正しく復元するには、永続化機能がカスタムSSLAdapterクラスにアクセスできることが必要です。これを可能にするには、(サーバーにデプロイされたアプリケーションの内部ではなく)サーバーのシステムCLASSPATHを通じて、カスタムSSLAdapterクラスを提供する必要があります。

カスタムSSLAdapterは、SSLAdapterを拡張したものであることが必要であり、次の手順でインストールおよび有効化します。

1. weblogic.wsee.connection.transport.https.HttpsTransportInfoのインスタンスを作成します。

2. HttpsTransportInfo.setSSLAdapter(SSLAdapter adapter)を呼び出して、そのトランスポート情報にカスタムSSLアダプタを設定します。

3. 次を呼び出して、Webサービス・スタブ・インスタンス(javax.xml.rpc.Stub型のスタブ)にトランスポート情報を設定します

stub._setProperty(weblogic.wsee.connection.soap.SoapClientConnection.TRANSPORT_INFO_PROPERTY,ti);

stubはWebサービス・スタブ、tiは構成したHttpsTransportInfoです。

この手順に従ってカスタムSSLAdapterクラスをシステムCLASSPATHに指定しないと、ClassNotFoundException例外が生成されます。

java.io.IOException: java.lang.ClassNotFoundException:
examples.webservices.client.ServiceBase$TestSSLAdapter

4 アクセス制御セキュリティの構成(JAX-RPCのみ)

この章では、Java API for XML-based RPC (JAX-RPC)を使用してWebLogic Webサービスのアクセス制御セキュリティを構成する方法について説明します。

この章の内容は次のとおりです:

- アクセス制御セキュリティの構成: 主な手順

- セキュリティ関連アノテーションでのJWSファイルの更新

- @RunAsアノテーションでのJWSファイルの更新

- サービス・オブジェクト作成時のユーザー名とパスワードの設定

アクセス制御セキュリティの構成: 主な手順

アクセス制御セキュリティとは、アクセスできるユーザーを制御するようにWebサービスを構成し、クライアントが操作の1つを呼び出したときにWebサービスに対してHTTP/Sまたはユーザー名トークンを使用して自身を認証するようにクライアント・アプリケーションをコーディングすることです。

Webサービスのアクセス制御セキュリティを指定するには、JWSファイル内で、次のアノテーションを1つ以上使用します。

- weblogic.jws.security.RolesAllowed

- weblogic.jws.security.SecurityRole

- weblogic.jws.security.RolesReferenced

- weblogic.jws.security.SecurityRoleRef

- weblogic.jws.security.RunAs

注意:

@weblogicの.security.jws.SecurityRolesと@weblogic.security.jws.SecurityIdentity JWSアノテーションは、WebLogic Server 9.1から非推奨となっています。

次の手順は、これらのアノテーションを使用してアクセス制御セキュリティを有効化するためのステップを大まかに説明したものです。各ステップの詳細は、この章の後半の項で説明します。

注意:

次の手順では、WebLogic Webサービスを実装するJWSファイルがすでに作成されており、そのファイルをアクセス制御セキュリティの設定で更新することを前提としています。

また、Antビルド・スクリプトを使用してWebサービスを反復的に開発することと、新しい情報で更新できる作業用のbuild.xmlファイルがあることも前提となっています。

さらに、保護されていないWebサービスを呼び出すクライアント・アプリケーションも用意されているものとします。これらの前提条件が満たされていない場合は、『Oracle WebLogic Server JAX-RPC Webサービスの開発』を参照してください。

1. 必要に応じて、適切なレベル(クラスまたは操作)で@weblogic.jws.security.RolesAllowed、@weblogic.jws.security.SecurityRole、@weblogic.jws.security.RolesReferenced、@weblogic.jws.security.SecurityRoleRefの各アノテーションを追加し、JWSファイルを更新します。
「セキュリティ関連アノテーションでのJWSファイルの更新」を参照してください。

2. 必要に応じて@weblogic.jws.security.RunAs JWSアノテーションを追加することで、WebLogic Serverが実際にWebサービスを呼び出すユーザーに割り当てられているロールではなく、特定のロールを使用してWebサービスを内部で実行することを指定します。
「@RunAsアノテーションでのJWSファイルの更新」を参照してください。

3. 必要に応じて@weblogic.jws.security.UserDataConstraint JWSアノテーションを追加することで、WebサービスがHTTPSを使用して呼出し可能であること、または呼び出される必要があることを指定します。
詳細は、「UserDataConstraintによるトランスポート・レベルのセキュリティの構成: 主な手順(JAX-RPCのみ)」を参照してください。この項ではまた、SSLを使用するようにクライアント・アプリケーションを更新する方法についても説明しています。

4. 通常の反復的な開発プロセスの一部として、Webサービスを再コンパイルして再デプロイします。
『Oracle WebLogic Server JAX-RPC Webサービスの開発』のWebLogic Webサービスの開発に関する項を参照してください。

5. 有効なWebLogic Serverユーザーが存在しない場合には、管理コンソールを使用して作成します。ユーザーのロールへのマッピングが外部で行われている場合は、さらに管理コンソールを使用して@SecurityRoleアノテーションで指定されているロールを作成し、ユーザーをロールにマッピングします。

注意:

JWSファイルに@SecurityRoleアノテーションのmapToPrincipals属性を指定して、Webサービスの呼出しが可能なユーザーをすべてリストしないと、ユーザーからロールへのマッピングは外部的に定義されます。

『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。

6. HttpTransportInfo WebLogic APIを使用し、Serviceオブジェクトの作成時に適切なユーザーおよびパスワードを指定するよう、クライアント・アプリケーションを更新します。
「サービス・オブジェクト作成時のユーザー名とパスワードの設定」を参照してください。

7. build.xmlファイル内のclientgen Antタスクを更新して、有効なWebLogicユーザーのユーザー名およびパスワード(Webサービスで@RolesAllowedアノテーションを使用する場合)と、WebLogic Serverのものも含めて信頼性のある証明書のリストが格納された信頼ストア(@UserDataConstraintを指定する場合)を指定します。
これを行うには、次の例に示すように、ネストされた標準のAnt要素である<sysproperty>をclientgen Antタスクに追加し、必要なJavaプロパティにkey属性を設定します。

注意:

この例ではユーザー名とパスワードをハード・コードしており、両方の入力を要求することでセキュリティを高めています。SSLを使用する場合は、@RolesAllowedに対するユーザー名とパスワード、および信頼ストアが必要です。

<clientgen
wsdl="http://example.com/myapp/myservice.wsdl"
destDir="/output/clientclasses"
packageName="myapp.myservice.client"
serviceName="StockQuoteService" >
<sysproperty key="javax.net.ssl.trustStore"
value="/keystores/DemoTrust.jks"/>
<sysproperty key="weblogic.wsee.client.ssl.stricthostchecking"
value="false"/>
<sysproperty key="javax.xml.rpc.security.auth.username"
value="juliet"/>
<sysproperty key="javax.xml.rpc.security.auth.password"
value="secret"/>
</clientgen>

8. クライアント側のコンポーネントを再生成して、Javaコードを通常どおりに再コンパイルします。

セキュリティ関連アノテーションでのJWSファイルの更新

JWSファイルでWebLogic固有の@weblogic.jws.security.RolesAllowedアノテーションを使用し、Webサービスの呼出しが許可されているロールをリストする@weblogic.jws.security.SecurityRolesアノテーションの配列を指定します。これら2つのアノテーションは、クラス・レベルまたはメソッド・レベルのいずれでも指定できます。クラス・レベルで設定した場合、ロールはすべてのパブリック操作に適用されます。このアノテーションをメソッド・レベルで指定することで、特定の操作にロールを追加できます。

@SecurityRoleアノテーションには、次の2つの属性があります。

- roleは、Webサービスを呼び出すことができるロールの名前です。

- mapToPrincipalsは、ロールにマップするユーザーのリストです。この属性で1人以上のユーザーを指定した場合、ユーザーとロールの間のマッピングを外部で(通常は管理コンソールを使用して)作成する必要はありません。ただし、この属性で指定されたマッピングは、Webサービスのコンテキスト内にのみ適用されます。

@RolesAllowedアノテーションは、属性を持ちません。

また、@weblogic.jws.security.RolesReferencedアノテーションを使用して、既存のロールへの参照をリストする@weblogic.jws.security.SecurityRoleRefアノテーションの配列を指定することもできます。たとえば、ロールmanagerがすでにWebサービスの呼出しを許可されている場合、mgrロールからmanagerロールへのリンクを指定すれば、mgrにマップされるユーザーもWebサービスを呼び出せるようになります。これら2つのアノテーションは、クラス・レベルのみで指定できます。

@SecurityRoleRefアノテーションには、次の2つの属性があります。

- roleは、ロール参照の名前です。

- linkは、Webサービスを呼び出すことができる、すでに指定されたロールの名前です。この属性の値は、同じJWSファイルで指定されている@SecurityRole annotationのrole属性の値に対応します。

@RolesReferencedアノテーションは、属性を持ちません。

次の例では、この項で説明したアノテーションのJWSファイルでの使用方法を示します(該当する個所は太字で示しています)。

package examples.webservices.security_roles;
import javax.jws.WebMethod;
import javax.jws.WebService;
// WebLogic JWS annotations
import weblogic.jws.WLHttpTransport;
import weblogic.jws.security.RolesAllowed;
import weblogic.jws.security.RolesReferenced;
import weblogic.jws.security.SecurityRole;
import weblogic.jws.security.SecurityRoleRef;
@WebService(name="SecurityRolesPortType",
serviceName="SecurityRolesService",
targetNamespace="http://example.org")
@WLHttpTransport(contextPath="security",
serviceUri="SecurityRolesService",
portName="SecurityRolesPort")
@RolesAllowed (  {
@SecurityRole (role="manager",
mapToPrincipals={ "juliet","amanda" }),
@SecurityRole (role="vp")
} )
@RolesReferenced (
@SecurityRoleRef (role="mgr", link="manager")
)
/**
* This JWS file forms the basis of simple Java-class implemented WebLogic
* Web Service with a single operation: sayHello
*
*/
public class SecurityRolesImpl {
@WebMethod()
public String sayHello(String message) {
System.out.println("sayHello:" + message);
return "Here is the message: '" + message + "'";
}
}

この例では、manager、vp、およびmgrロールのみが、Webサービスの呼出しを許可されることを指定する方法を示しています。mgrロールは、実際にはmanagerロールへの参照です。Webサービスのコンテキスト内で、ユーザーjulietおよびamandaはmanagerロールにマップされます。vpロールにマップされるユーザーがないので、WebLogic Serverセキュリティ・レルムを更新するためには、通常管理コンソールを使用して、外部でマッピングが行われることが前提です。

これらのアノテーションに関するリファレンス情報は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のJWSアノテーション・リファレンスに関する項を参照してください。

@RunAsアノテーションでのJWSファイルの更新

Webサービスが常に特定のロールとして実行されることを指定するには、JWSファイル内でWebLogic固有の@weblogic.jws.security.RunAsアノテーションを使用します。これはつまり、Webサービスを最初に呼び出すユーザーが誰であろうと、またそのユーザーがどのロールにマップされていようと、サービスは指定されたロールとして内部で実行されるということです。

@RunAsアノテーションは、クラス・レベルでのみ設定できます。このアノテーションには次の属性があります。

- roleは、Webサービスを実行する際のロールです。

- mapToPrincipalは、ロールにマップするプリンシパル・ユーザーです。

次の例では、@RunAsアノテーションのJWSファイルでの使用方法を示します(該当する個所は太字で示しています)。

package examples.webservices.security_roles;
import javax.jws.WebMethod;
import javax.jws.WebService;
// WebLogic JWS annotations
import weblogic.jws.WLHttpTransport;
import weblogic.jws.security.RunAs;
@WebService(name="SecurityRunAsPortType",
serviceName="SecurityRunAsService",
targetNamespace="http://example.org")
@WLHttpTransport(contextPath="security_runas",
serviceUri="SecurityRunAsService",
portName="SecurityRunAsPort")
@RunAs (role="manager", mapToPrincipal="juliet")
/**
* This JWS file forms the basis of simple WebLogic
* Web Service with a single operation: sayHello
*
*/
public class SecurityRunAsImpl {
@WebMethod()
public String sayHello(String message) {
System.out.println("sayHello:" + message);
return "Here is the message: '" + message + "'";
}
}

サービス・オブジェクト作成時のユーザー名とパスワードの設定

Webサービスの保護に@RolesAllowed JWSアノテーションを使用する場合、指定したロールのみがWebサービス操作の呼出しを許可されます。つまり、保護されているWebサービスを呼び出すクライアント・アプリケーションでServiceオブジェクトを作成する際には、ロールにマップするユーザーのユーザー名およびパスワードを指定する必要があります。

WebLogic Serverでは、ユーザー名およびパスワードを設定してServiceコンストラクタに渡すためのHttpTransportInfoクラスが用意されています。次の例は、スタンドアロンJavaクライアントからWebサービスを呼び出す標準的な方法(『Oracle WebLogic Server JAX-RPC Webサービスの開発』のWebサービスの呼出しに関する項を参照)に基づいていますが、同時に、HttpTransportInfoクラスを使用してユーザー名およびパスワードを設定する方法も示しています。太字の箇所については、例の後で説明します。

package examples.webservices.sec_wsdl.client;
import weblogic.wsee.connection.transport.http.HttpTransportInfo;
import java.rmi.RemoteException;
import javax.xml.rpc.ServiceException;
import javax.xml.rpc.Stub;
/**
* This is a simple standalone client application that invokes the
* the <code>sayHello</code> operation of the SecWsdlService Web service.
*
* @author Copyright © 1996, 2008, Oracle and/or its affiliates.
* All rights reserved.
*/
public class Main {
public static void main(String[] args)
throws ServiceException, RemoteException{
HttpTransportInfo info = new HttpTransportInfo();
info.setUsername("juliet".getBytes());
info.setPassword("secret".getBytes());
SecWsdlService service = new SecWsdlService_Impl(args[0] + "?WSDL", info);
SecWsdlPortType port = service.getSecWsdlPort();
try {
String result = null;
result = port.sayHello("Hi there!");
System.out.println( "Got result: " + result );
} catch (RemoteException e) {
throw e;
}
}
}

上記の例で注目すべき主な点は次のとおりです。

- クライアント・アプリケーションにHttpTransportInfoクラスをインポートします。

import weblogic.wsee.connection.transport.http.HttpTransportInfo;

- HttpTransportInfoクラスのsetXXX()メソッドを使用して、ユーザー名およびパスワードを設定します。

HttpTransportInfo info = new HttpTransportInfo();
info.setUsername("juliet".getBytes());
info.setPassword("secret".getBytes());

この例では、パスワードがsecretであるユーザーjulietが、有効なWebLogic Serverユーザーであり、Webサービスの@RolesAllowed JWSアノテーションで指定されたロールにマップ済であることを前提としています。

プロキシを使用してWebサービスにアクセスしている場合、Javaコードは次のようになります。

HttpTransportInfo info = new HttpTransportInfo();
Proxy p = new Proxy(Proxy.Type.HTTP, new  InetSocketAddress(proxyHost, Integer.parseInt(proxyPort)));
info.setProxy(p);
info.setProxyUsername(user.getBytes());
info.setProxyPassword(pass.getBytes());

- 標準的なWSDLの1番目の引数に加えて、ユーザー名およびパスワードが含まれているinfoオブジェクトを2番目の引数としてServiceコンストラクタに渡します。

SecWsdlService service = new SecWsdlService_Impl(args[0] + "?WSDL", info);

保護されていないWebサービスの呼出しに関する一般情報については、『Oracle WebLogic Server JAX-RPC Webサービスの開発』のWebサービスの呼出しに関する項を参照してください。

A Oracle Web Services Managerセキュリティ・ポリシーの使用

この付録では、WebLogic JAX-WS WebサービスでOracle Web Services Manager WS-Security (OWSMセキュリティ)ポリシーを使用する方法について説明します。

この付録の内容は次のとおりです。

- OWSMセキュリティ・ポリシーの概要

- OWSMセキュリティ・ポリシーのJAX-WS Webサービスへのアタッチ

- OWSMセキュリティ・ポリシーのJAX-WS Webサービス・クライアントへのアタッチ

- ポリシーの構成

- Webサービス・クライアントのポリシー構成のオーバーライド

- Webサービスのモニターおよびテスト

OWSMセキュリティ・ポリシーの概要

Oracle Fusion Middlewareでは、WebLogic Serverに加え、OWSMセキュリティ・ポリシーをWebLogic Server環境に統合するポータビリティ層がインストールされます。このポータビリティ層は、WebLogic JAX-WS Webサービスとクライアントを保護するために使用できるOWSMセキュリティ・ポリシーを提供します。

OWSMセキュリティ・ポリシーは、Webサービスのセキュリティを実施するWebLogic WS-Securityポリシーに代わる手段として使用できます。また、カスタムOWSMセキュリティ・ポリシーを作成して、WebLogic Webサービスとともに使用することもできます。

次の各項では、使用可能なOWSMポリシーの詳細およびポリシーを使用する状況について説明します。

- Java EE WebサービスでサポートされているOWSMポリシー

- OWSMセキュリティ・ポリシーを使用するケース

- WebLogic Webサービス・ポリシーおよびOWSMポリシーの相互運用性

Java EE WebサービスでサポートされているOWSMポリシー

Java EE WebサービスでサポートされているのはOWSMポリシーの一部のみです。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のJava EE WebサービスでサポートされているOWSMポリシーに関する項を参照してください。

OWSMセキュリティ・ポリシーを使用するケース

環境内の他の場所ですでにSOA、ADF、WebCenterなどのアプリケーションを使用しており、一貫したセキュリティ環境を構築する必要がある場合は、OWSMセキュリティ・ポリシーを使用してJAX-WS Webサービスを保護できます。

WebLogic JAX-WS WebサービスをOracle Fusion Middlewareアプリケーションと併用する場合は、これらのWebサービスをOWSMセキュリティ・ポリシーで保護し、一貫性と相互運用性を備えたWebサービス・セキュリティを確立する必要があります。

つまり、スタンドアロンのWebLogic Server Webサービス・アプリケーションではなく、Oracle Fusion Middlewareアプリケーションと相互作用するアプリケーションで使用するWebLogic JAX-WS Webサービスは、OWSMセキュリティ・ポリシーで保護する必要があります。

次のシナリオを参考にしてください。

- SOAコンポジット・サービス、ADFコンポーネント、WebCenterサービスなどと相互作用するWebLogic JAX-WS Webサービスまたはクライアントを開発する場合、OWSMセキュリティ・ポリシーを使用する必要があります。

- WebLogicネイティブのJava JAX-WS Webサービスのみを開発する場合、WebLogic WS-Securityポリシーを使用する必要があります。

表A-1は、OWSMポリシーを使用する際のポリシー選択のガイドラインをまとめたものです。この表では、次のルールが適用されます。

- weblogic.jws.PolicyアノテーションはWebLogic Webサービス・ポリシーに適用されます

- weblogic.wsee.jws.jaxws.owsm.SecurityPolicyアノテーションはOWSMポリシーに適用されます

表A-1 ポリシー選択のガイドライン

@Policy

@SecurityPolicy

実装する機能

使用するポリシー

はい

いいえ

複数あるWSS 1.0は、キー参照メソッドをサポートする必要があります

Wssp1.2-2007-Wss1.0-UsernameToken-Plain-X509-Basic256.xml

Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xml

はい

いいえ

ユーザー名トークン・ダイジェスト認証

Wssp1.2-2007-Https-UsernameToken-Digest.xml

Wssp1.2-2007-Wss1.0-UsernameToken-Digest-X509-Basic256.xml

Wssp1.2-2007-Wss1.1-UsernameToken-Digest-X509-Basic256.xml

いいえ

はい

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_with_message_protection_basic128_client_policy

oracle/wss11_kerberos_token_with_message_protection_basic128_service_policy

はい

いいえ

WSS 1.1派生キー

Wssp1.2-2007-Wss1.1-DK-X509-SignedEndorsing.xml

Wssp1.2-2007-Wss1.1-UsernameToken-Plain-DK.xml

はい

いいえ

すべてのSAML 2.0シナリオ

oracle/http_saml20_token_bearer_client_policy

oracle/http_saml20_token_bearer_service_policy

oracle/http_saml20_token_bearer_over_ssl_client_policy

oracle/http_saml20_token_bearer_over_ssl_service_policy

oracle/wss_saml20_token_bearer_over_ssl_client_policy

oracle/wss_saml20_token_bearer_over_ssl_service_policy

oracle/wss_saml20_token_over_ssl_client_policy

oracle/wss_saml20_token_over_ssl_service_policy

oracle/wss10_saml20_token_client_policy

oracle/wss10_saml20_token_service_policy

oracle/wss10_saml20_token_with_message_protection_client_policy

oracle/wss10_saml20_token_with_message_protection_service_policy

oracle/wss11_saml20_token_with_message_protection_client_policy

oracle/wss11_saml20_token_with_message_protection_service_policy

はい

いいえ

署名する前に暗号化

WSS10、WSS11両方の対称バインディングまたは非対称バインディングにおける、次のようなポリシー・アサーション<sp:EncryptBeforeSigning/>。

<wsp:Policy xmlns:wsp="..." >
<sp:SymmetricBinding>
<wsp:Policy>
.. .
<sp:EncryptBeforeSigning/>
. . .
</wsp:Policy>
</sp:SymmetricBinding>
. . .
</wsp:Policy>

はい

いいえ

複数のポリシー選択肢

次のようなポリシー・アサーション。

<wsp:Policy xmlns:wsp="..." >
<wsp:ExactlyOne>
<wsp:All>
... ALternative 1 ...
</wsp:All>
<wsp:All>
... ALternative 2 ...
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>

WS-RMおよびMTOMなどの非セキュリティ機能には、WebLogic Webサービス・ポリシーを使用します。

特定のポリシー・インスタンスでは、Webサービス・クライアントまたはサービスにOWSMポリシーをアタッチし、WebLogic Java EE WebサービスまたはクライアントにWebLogic Webサービス・ポリシーをアタッチして、2種類のポリシーを相互運用できます。特定の相互運用性シナリオについては、『Oracle Web Services Manager相互運用性ソリューション・ガイド』のOracle WebLogic Server 11g Webサービス・セキュリティ環境との相互運用性に関する項を参照してください。

これらの相互運用性シナリオについては、次の点を考慮した上でOWSMポリシーとWebLogic Webサービス・ポリシーのいずれかを使用してください。

- OWSMポリシーでその他の非標準のポリシー・アサーションが構成で必要とされる場合は、@SecurityPolicyアノテーションを使用します。
このような非標準のアサーションの例としては、次のものがあります。

<oralgp:Logging xmlns:oralgp="http://schemas.oracle.com/ws/2006/01/loggingpolicy"  . . .
orawsp:category="security/logging">
. . .
</oralgp:Logging>

または

<orawsp:Config xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy" . . .>
<orawsp:PropertySet  . . .>
. . .
</orawsp:PropertySet>
</orawsp:Config>

- アプリケーションが、既存のWebLogic WebサービスまたはMicrosoft Windows Communication Foundation (WCF)/.NET 3.5 Frameworkサービスとの相互運用に使用され、前述した非標準のポリシー・アサーションが必要でない場合、WebLogic Webサービス・ポリシーを持つ@Policyアノテーションを使用します。

WebLogic Webサービス・ポリシーおよびOWSMポリシーの相互運用性

WebLogic Webサービス・ポリシーのサブセットは、OWSMポリシーと相互運用できます。

つまり、特定のポリシー・インスタンスでは、Webサービス・クライアントまたはサービスにOWSMポリシーをアタッチし、WebLogic Java EE WebサービスまたはクライアントにWebLogic Webサービス・ポリシーをアタッチして、2種類のポリシーを相互運用できます。

特定の相互運用性シナリオについては、『Oracle Web Services Manager相互運用性ソリューション・ガイド』のOracle WebLogic Server 11g Webサービス・セキュリティ環境との相互運用性に関する項を参照してください。

WebLogic Serverには、OWSMとの相互運用性のためのポリシー(表A-2を参照)が用意されています。

表A-2 相互運用性WebLogic WS-Securityポリシー

ポリシー名

説明

Wssp1.2-2007-Saml1.1-HolderOfKey-Wss1.0-Basic128.xml

このポリシーは、holder-of-key確認メソッド(SAMLトークン内の鍵が署名に使用される)による認証のためのSAMLトークンを含む、Wssp1.2-2007-Saml1.1-HolderOfKey-Wss1.0.xmlと同様のセキュリティ機能を提供します。Basic256アルゴリズム・スイート(AES256)ではなく、Basic128アルゴリズム・スイート(暗号化にはAES128)の使用が必要になります。

Wssp1.2-wss11_saml_token_with_message_protection_owsm_policy.xml

このポリシーは、sender-vouches確認メソッドによる認証のためのSAMLトークン(リクエストとレスポンスの両方でWSS1.1 X509の対称バインディングにより署名および暗号化される)を含む、Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.1.xmlと同様のセキュリティ機能を提供します。

送信側のX509証明書によって承認が行われ、メッセージの署名は保護されます。Basic256アルゴリズム・スイート(暗号化にはAES256)ではなく、Basic128アルゴリズム・スイート(AES128)を使用する必要があります。

Wssp1.2-wss10_saml_token_with_message_protection_owsm_policy.xml

このポリシーは、sender-vouches確認メソッドによる認証のためのSAMLトークン(クライアントの秘密鍵で署名される)を含む、Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xmlと同様のセキュリティ機能を提供します。Basic256アルゴリズム・スイート(AES256)ではなく、Basic128アルゴリズム・スイート(暗号化にはAES128)の使用が必要になります。また、公開証明書を含む直接キー参照が使用されます。

Wssp1.2-2007-Saml1.1-SenderVouches-Https.xml

sender-vouches確認メソッドによって認証を行うSAML 1.1トークンを使用する、双方向SSL。クライアント証明書が必要であり、受信側で発信元の公開証明書の有無をチェックします。

Wssp1.2-wss10_x509_token_with_message_protection_owsm_policy.xml

このポリシーは、X.509証明書による相互認証用に、Wssp1.2-2007-Wss1.0-X509-Basic256.xmlと同様のセキュリティ機能を提供します。Basic256アルゴリズム・スイート(AES256)ではなく、Basic128アルゴリズム・スイート(暗号化にはAES128)の使用が必要になります。また、公開証明書を含む直接キー参照が使用されます。

Wssp1.2-2007-Wss1.1-EncryptedKey-Basic128.xml

このポリシーは、Wssp1.2-Wss1.1-EncryptedKey.xmlと同様のセキュリティ機能を提供します。このポリシーでは、メッセージがクライアント側からのX509証明書なしに暗号化および署名される必要があります。これは、匿名認証に使用されます。

Wssp1.2-wss11_x509_token_with_message_protection_owsm_policy.xml

このポリシーは、Wssp1.2-Wss1.1-EncryptedKey-X509-SignedEndorsing.xmlと同様のセキュリティ機能を提供します。これは、送信者のX509証明書で保証されており、メッセージ署名は保護されます。Basic256アルゴリズム・スイート(暗号化にはAES256)ではなく、Basic128アルゴリズム・スイート(AES128)を使用する必要があります。

Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey-Basic128.xml

このポリシーは、非対称バインディングを備えたWSS 1.1 X509とプレーン・テキスト・ユーザー名トークンを備えた認証があるWssp1.2-Wss1.1-UsernameToken-Plain-X509-Basic256.xmlと同様のセキュリティ機能を提供します。Basic256アルゴリズム・スイート(AES256)ではなく、Basic128アルゴリズム・スイート(暗号化にはAES128)の使用が必要になります。

Wssp1.2-wss10_username_token_with_message_protection_owsm_policy.xml

このポリシーは、クライアントの秘密鍵で署名された、認証用の暗号化されたプレーン・テキスト・パスワードを含む、Wssp1.2-Wss1.0-UsernameToken-Plain-X509-Basic256.xmlと同様のセキュリティ機能を提供します。Basic256アルゴリズム・スイート(AES256)ではなく、Basic128アルゴリズム・スイート(暗号化にはAES128)の使用が必要になります。また、公開証明書を含む直接キー参照が使用されます。

Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.1-Basic128.xml

このポリシーは、Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.1.xmlと同様のセキュリティ機能を提供します。

Wssp1.2-2007-Wss1.1-EncryptedKey-X509-Endorsing-Basic128.xml

このポリシーは、Wssp1.2-Wss1.1-EncryptedKey-X509-SignedEndorsing.xmlと同様のセキュリティ機能を提供します。

Wssp1.2-2007-Wss1.1-X509-Basic128.xml

このポリシーは、Wssp1.2-2007-Wss1.0-X509-Basic256.xmlと同様のセキュリティ機能を提供します。

Wssp1.2-wss11_saml20_token_with_message_protection_owsm_policy.xml

このポリシーは、Wssp1.2-wss11_saml_token_with_message_protection_owsm_policy.xmlと同様のセキュリティ機能を提供します。

OWSMセキュリティ・ポリシーのJAX-WS Webサービスへのアタッチ

OWSM WS-Securityポリシーのアタッチモデルは、WebLogic Webサービス・ポリシーのものと同様です。次のいずれかの方法でOWSMポリシーをWebLogic JAX-WS Webサービスにアタッチできます。

- 設計時のポリシー・アノテーション(『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のアノテーションを使用したJava EE Webサービスおよびクライアントへのポリシーのアタッチに関する項を参照)。

- 実行時の管理コンソール(「管理コンソールを使用したOWSMセキュリティ・ポリシーのアタッチ」を参照)。

- 実行時のFusion Middleware ControlまたはWLST(『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』を参照)。

Webサービスにアタッチできるセキュリティ・ポリシーは、WebLogic Webサービス・セキュリティ・ポリシーまたはOWSMポリシーのどちらか1つのみです。アノテーション・メカニズム、管理コンソール、Fusion Middleware Controlのいずれか、あるいはこの3つの組合せを使用しても、WebLogic Webサービス・ポリシーおよびOWSMポリシーの両方を同じWebサービスにアタッチすることはできません。

OWSMセキュリティ・ポリシーはJAX-WS Webサービスにのみアタッチできます。このタイプのポリシーはJAX-RPC Webサービスにはアタッチできません。

次の各項では、管理コンソールを使用してOWSMセキュリティ・ポリシーをJAX-WS Webサービスにアタッチする方法について説明します。

- 管理コンソールを使用したOWSMセキュリティ・ポリシーのアタッチ

- ポリシー・アタッチ後のキャッシュのリフレッシュ

管理コンソールを使用したOWSMセキュリティ・ポリシーのアタッチ

管理コンソールを使用して実行時にデプロイ済WebサービスにOWSMポリシーをアタッチする方法は、第2章「メッセージ・レベルのセキュリティの構成」で説明しているように、WebLogic Webサービス・ポリシーをアタッチする方法と似ています。

JWSファイルで@SecurityPolicyアノテーションも@SecurityPoliciesアノテーションも使用せず、管理コンソールを使用して実行時のみにポリシーをアタッチできます。または、アノテーションを使用してポリシーの一部をアタッチし、その他のポリシーを実行時にアタッチできます。JWSアノテーションを使用してポリシー・ファイルをアタッチする場合、管理コンソールを使用して実行時にこのポリシーを削除できます。

実行時、管理コンソールでは、ポリシー内のアサーションが互いに矛盾している場合や、JWSアノテーションを使用して設計時にアタッチしたポリシー内でアサーションが矛盾している場合でも、必要な数のポリシーをWebサービスとその操作にアタッチできます。アタッチした複数のポリシーが連動するかどうかは、アタッチしたユーザーが確認します。なんらかの矛盾がある場合、クライアント・アプリケーションがWebサービスの操作を呼び出すときに、WebLogic Serverから実行時エラーが返されます。

ポリシーの検証は行われません。次の組合せが有効です。

- 1つのポリシー・サブジェクトには、1つの管理ポリシーをアタッチできます。

- 1つのサブジェクトには、サブタイプの認証を行う1つのセキュリティ・ポリシーをアタッチできます。

- 1つのサブジェクトには、サブタイプのメッセージ保護を行う1つのセキュリティ・ポリシーをアタッチできます。

- 1つのサブジェクトには、サブタイプの認可を行う1つのセキュリティ・ポリシーをアタッチできます。

注意:

1つのポリシー・サブジェクトに1つまたは2つのセキュリティ・ポリシーがアタッチされていることがあります。セキュリティ・ポリシーには、認証とメッセージ保護のいずれかのサブタイプ・カテゴリに属するアサーション、または両方のサブタイプ・カテゴリに属するアサーションを含めることができます。2つ目のセキュリティ・ポリシーには、認可サブタイプに属するアサーションが含まれています。

- 認証ポリシーと認可ポリシーを両方ともポリシー・サブジェクトにアタッチする場合は、認証ポリシーを認可ポリシーより前に置く必要があります。

管理コンソールでOWSMセキュリティ・ポリシーをアタッチするには、次の手順を実行します。

1. 管理コンソールを使用して、default_wssと命名でデフォルトWebサービス・セキュリティ構成を作成してください。デフォルトのWebサービス・セキュリティ構成は、別の構成を使用するように明示的にプログラミングされていないかぎり、ドメイン内のすべてのWebサービスで使用されます。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのWebサービス・セキュリティ構成の作成に関する項を参照してください。

2. 「デプロイメントのサマリー」ページから、Webサービスを保護するアプリケーションを選択します。

3. プラス記号(+)をクリックしてアプリケーションを展開します。保護するWebサービスを選択します。

4. 「構成」ページを選択します。

5. 「WS-Policy」ページを選択します。

6. 図A-1に示すように、Webサービス・エンドポイントを選択してください。OWSMセキュリティ・ポリシーは、クラス/ポート・レベルでのみアタッチできます。

図A-1 Webサービスのためのサービス・エンドポイント

7. 図A-2に示すように、OWSMを選択します。

図A-2 OWSMセキュリティ・ポリシー・タイプの選択

8. 図A-3に示すように、誤って特定のWebサービス操作を選択した場合、ポリシー選択画面は表示されません。最初からやり直すには、「取消」をクリックします。

図A-3 WebLogic Serverポリシー・ページ

9. このWebサービスにアタッチするOWSMセキュリティ・ポリシーを選択し、図A-4に示すように、コントロールを使用して、それらを「選択されたエンドポイント・ポリシー」ボックスに移動します。完了したら、「終了」をクリックします。

図A-4 使用可能なOWSMセキュリティ・ポリシーからの選択

10. デプロイメント・プランを保存します。

11. WebLogic Server変更メッセージで示されたとおりに変更が自動的にアクティブにならない場合は、デプロイ済のアプリケーションを再起動して、新しいデプロイメント・プランを反映させます。

ポリシー・アタッチ後のキャッシュのリフレッシュ

WebLogic Serverでは、デプロイ済リソースのデータがキャッシュされ、1つのセッションにつき1つのキャッシュがあります。Webサービスにアタッチされたポリシーを表示するには、キャッシュのクリアが必要な場合があります。

通常の管理コンソールの使用では、ユーザーが操作した最後のデプロイ済リソースがキャッシュされます。外部ツールまたはAPI (Fusion Middleware Control、WLST、JMX APIなど)によるキャッシュ済デプロイメントへの変更は、キャッシュ済デプロイメントには反映されません。

次のシナリオについて考えます。

1. WebLogic ServerにWebサービスをデプロイした後、管理コンソールでそのWebサービスの構成ページに移動したとします。現在、キャッシュには、このデプロイ済リソースの情報が存在します。

2. Fusion Middleware Controlを使用して、このWebサービスにOWSMセキュリティ・ポリシーをアタッチした場合、ページをリフレッシュしても変更内容は管理コンソールに反映されません。

ポリシーのアタッチを確認するには、キャッシュをクリアする必要があります。これは、次の2つの方法で実行できます。

- 別のデプロイメントに移動した後(これにより、そのデータがキャッシュされます)、元のページに戻ります。

- 管理コンソールからログアウトし、再度ログインします。

OWSMセキュリティ・ポリシーのJAX-WS Webサービス・クライアントへのアタッチ

ここでは、設計時にOWSMセキュリティ・ポリシーをWebサービス・クライアント・アプリケーションにアタッチする高度な手順について説明します。Webサービス・クライアントの開発の詳細は、『Oracle WebLogic Server JAX-WS Webサービスの開発』の基本的なJAX-WS Webサービス・クライアントの開発に関する項を参照してください。

注意:

デプロイ済のWebサービスを呼び出すクライアント・アプリケーションを作成してあり、クライアント側のポリシー・ファイルをアタッチすることでそのクライアント・アプリケーションを更新するものとします。また、Antベースの開発環境を設定済であり、かつclientgen Antタスクを実行するためのターゲットを含む、作業用のbuild.xmlファイルがあることが前提となっています。

1. クライアントにアタッチするOWSMセキュリティ・ポリシーを確認します。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のJava EE WebサービスでサポートされているOWSMポリシーに関する項を参照してください。

2. Javaクライアント・アプリケーションを更新して、OWSMセキュリティ・ポリシーをアタッチします。
『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の次の項では、OWSMセキュリティ・ポリシーをWebサービス・クライアントにアタッチするために使用できる方法について説明しています。

- 機能クラスを使用したOWSMセキュリティ・ポリシーのクライアントへのアタッチに関する項

- アノテーションを使用したポリシーのJava EE Webサービスおよびクライアントへのアタッチに関する項

機能クラスを使用したOWSMポリシーのアタッチはアノテーションよりも優先されます。

3. クライアント・アプリケーションのビルドに使用するbuild.xmlファイルを更新します。

4. 適切なタスクを実行して、クライアント・アプリケーションを再ビルドします。次に例を示します。

prompt> ant build-client

クライアント・アプリケーションを実行するとポリシー・ファイルがロードされ、Webサービス・クライアント・ランタイムは、これを使用してSOAPリクエスト・メッセージのセキュリティを有効にします。

ポリシーの構成

Webサービスを構成する必要があります(『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のWebサービスの保護に関する項を参照)。

Webサービス・クライアントのポリシー構成のオーバーライド

次のいずれかの方法を使用して、OWSMセキュリティ・ポリシーのデフォルトの構成プロパティを設計時にプログラムでオーバーライドできます。

- JAX-WS RequestContext(『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の設計時のクライアント・ポリシー構成プロパティのオーバーライドに関する項を参照)。

- @SecurityPolicyアノテーションを使用してOWSMセキュリティ・ポリシーをアタッチする際の@Propertyアノテーション(『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のアノテーションを使用したポリシーのJava EE Webサービスおよびクライアントへのアタッチに関する項を参照)。

Webサービスのモニターおよびテスト

管理コンソールまたはFusion Middleware Controlを使用して、OWSMセキュリティ・ポリシーで保護されるWebLogic JAX-WS Webサービスをモニターおよびテストできます。

管理コンソールからWebサービスをモニターしてテストするには、次の手順を実行します。

1. 「デプロイメントのサマリー」ページで、Webサービスをモニターまたはテストする対象のアプリケーションを選択します。

2. Webサービスをモニターするには、「設定」ページで「監視」タブを選択します。
Webサービスのモニターの詳細は、『Oracle WebLogic Server JAX-WS Webサービスの開発』のWebサービスのモニタリングに関する項を参照してください。

3. Webサービスをテストするには、「設定」ページで「テスト」タブを選択します。
Webサービスのテストの詳細は、『Oracle WebLogic Server JAX-WS Webサービスの開発』のWebサービスのテストに関する項を参照してください。

Fusion Middleware Controlを使用してWebサービスをモニターしてテストするには、『Webサービスの管理』のWebサービスのモニターと監査に関する項およびWebサービスのテストに関する項を参照してください。

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2014, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。