Oracle® Fusion Middleware Oracle WebLogic Server Web サービスのセキュリティ 11g リリース 1 (10.3.1) B55522-01 |
|
戻る |
次へ |
このリリースの WebLogic Server では、JAX-RPC と JAX-WS の両方のスタックでメッセージレベルのセキュリティ機能がサポートされます。
この章では、Web サービス セキュリティをコンフィグレーションする方法について説明します。
メッセージレベルのセキュリティでは、クライアント アプリケーションと、そのクライアントによって呼び出される Web サービスとの間の SOAP メッセージに、デジタル署名または暗号化 (あるいはその両方) を施すかどうかを指定します。複数の SOAP メッセージを交換するイベントにおいて、Web サービスとクライアント間の共有セキュリティ コンテキストを指定することもできます。メッセージレベルのセキュリティは以下を実現します。
メッセージ部分の暗号化による機密性
デジタル署名による整合性
ユーザ名トークン、X.509 トークン、または SAML トークンを要求することによる認証
簡単なメッセージレベルのセキュリティをコンフィグレーションする場合に実行する基本的な手順については、「簡単なメッセージレベルのセキュリティのコンフィグレーション : 主な手順」を参照してください。この節では、Web サービス実行時環境に対するメッセージレベルのセキュリティのコンフィグレーション、特定の Web サービスに対するメッセージレベルのセキュリティのコンフィグレーション、およびそのサービスを呼び出すクライアント アプリケーションのコーディング方法について説明します。
また、Web サービスをデプロイした後、実行時に Web サービスのメッセージレベルのセキュリティをコンフィグレーションすることもできます。詳細については、「Administration Console を使用した実行時のポリシー ファイルの関連付け」を参照してください。
注意 : SOAP 添付ファイルに対しては、デジタル署名も暗号化も行えません。 |
WebLogic Web サービスが以下の OASIS Standard 1.1Web サービス Security を実装する、(WS-セキュリティ 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 証明書の使用の指定) したりできます。
WebLogic Web サービスは Web Services Trust (WS-Trust 1.3) 仕様と Web Services Secure Conversation (WS-SecureConversation 1.3) 仕様を実装しています。これらが連携して Web サービスとそのクライアント (別の Web サービスやスタンドアロンの Java クライアント アプリケーション) との間のセキュアな通信を提供します。
WS-Trust 仕様には、セキュリティ トークンの要求と発行や信頼関係の仲介を行うためのフレームワークとなる拡張機能が定義されています。
WS-SecureConversation 仕様には、複数のメッセージを交換できるように、セキュリティ コンテキストの確立と共有のメカニズムや、セキュリティ コンテキストからキーを派生するためのメカニズムが定義されています。セキュリティ コンテキストと派生キーを併用すると、交換の全体的なパフォーマンスやセキュリティの向上につながります。
WS-Policy 仕様では、Web サービスの制約や要件を表現するためのフレームワークが定義されています。これらの制約や要件は、ポリシー アサーションとして表現します。
WS-SecurityPolicy では、WS-Policy で使用するセキュリティ ポリシー アサーションのセットが定義され、WSS: SOAP Message Security、WS-Trust、および WS-SecureConversation のコンテキストにおいてメッセージをどのように保護するかについて記述されています。
Web サービスにメッセージレベルのセキュリティをコンフィグレーションするには、WS-SecurityPolicy 仕様に従って、セキュリティ ポリシー文を格納した 1 つまたは複数のポリシー ファイルを Web サービスにアタッチします。Web サービス実行時環境でのセキュリティ ポリシー ファイルの使用方法については、「メッセージレベルのセキュリティ コンフィグレーションでのポリシー ファイルの使用」を参照してください。
WebLogic Server のこのリリースでサポートされない Web サービス SecurityPolicy 1.2 の要素の情報については、「サポートされない WS-SecurityPolicy 1.2 アサーション」を参照してください。
Web Services Security: SOAP Message Security 仕様の実装では、以下の使い方がサポートされます。
メッセージ保護された Web サービスを呼び出すクライアント アプリケーションを起点に、Web サービスのホストである WebLogic Server インスタンス、そしてクライアント アプリケーションへまた戻る SOAP メッセージの署名と暗号化に X.509 証明書を使用する。
署名または暗号化される、あるいは必須の 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-SecurityPolicy1.2 セキュリティ Policy ファイル情報に関しては、「WS-SecurityPolicy 1.2 ポリシー ファイルの使用」を参照してください。 |
メッセージレベルのセキュリティに使用されるセキュリティ ポリシー ファイルは、オペレーションを呼び出した結果として発生する SOAP メッセージに対してデジタル署名または暗号化を行うかどうかの明記とその方法が記述された XML ファイルです。また、クライアント アプリケーションがユーザ名、SAML、または X.509 の各トークンを使用して自身を認証することの指定もできます。
ポリシー ファイルを Web サービスと関連付けるには、JWS ファイル内で @Policy
および @Policies
JWS アノテーションを使用します。Web サービスに関連付けることのできるポリシー ファイルの数に制限はありません。ただし、アサーションが互いに矛盾しないように管理者が確認する必要があります。ポリシー ファイルは、JWS ファイルのクラスレベルでも、メソッド レベルでも指定できます。
移植性を最大限に高めるため、JAX-WS では WS-Policy 1.2 および OASIS WS-SecurityPolicy 1.2 を使用することをお勧めします。
WebLogic Server は以下のネームスペースを使用して WS-Policy 1.2 をサポートします。
http://schemas.xmlsoap.org/ws/2004/09/policy
注意 : WebLogic Server は以下のネームスペースで WS-Policy 1.5 (現在の W3C 規格) をサポートします。http://www.w3.org/ns/ws-policy |
以下の OASIS WS-SX TC Web サービス SecurityPolicy ネームスペースは支持されます。
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702
新しいバージョンのネームスペースに加えて、以下の Web サービス 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 つのバージョンがあります。
(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 を使用してください。
以下では、Web サービス セキュリティ ランタイム、特定の WebLogic Web サービス、および Web サービスのオペレーションを呼び出すクライアント アプリケーションに、簡単なメッセージレベルのセキュリティをコンフィグレーションする手順について説明します。このマニュアルでは、簡単なメッセージレベルのセキュリティを次のように定義します。
メッセージ保護された Web サービスは、ユーザが作成した WS-SecurityPolicy ファイルではなく、あらかじめパッケージ化されている WS-SecurityPolicy ファイルを使用してセキュリティ要件を指定する。これらのファイルについては、「メッセージレベルのセキュリティ コンフィグレーションでのポリシー ファイルの使用」で説明しています。
Web サービスは、関連付けられたセキュリティ ポリシー ファイルを、公開されているデプロイされた WSDL にアタッチすることで公開できるようにする。
Web サービス ランタイムは、暗号化とデジタル署名に、独自のキー ペアではなく、デフォルトのキーストアに格納された用意されているプライベート キーと X.509 証明書のペアを使用する。これらの用意されているペアは、SSL 用の WebLogic Server コア セキュリティ サブシステムでも使用され、デモまたはテスト目的用に用意されています。このため、プロダクション中は、独自のキーストアおよびキー ペアを使用することを強くお勧めします。用意されているペア以外のキー ペアを使用するには、「用意されている 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 Fusion Middleware JAX-WS を使用した Oracle WebLogic Server Web サービス入門』
『Oracle Fusion Middleware Oracle WebLogic Server JAX-RPC を使用した Web サービス入門』
WebLogic Web サービスに対して簡単なメッセージレベルのセキュリティをコンフィグレーションするには、次の手順に従います。
JWS ファイルを更新します。WebLogic 固有の @Policy
および @Policies
JWS アノテーションを追加して、Web サービス全体または特定のオペレーションにアタッチされるあらかじめパッケージ化されたポリシー ファイルを指定します。
どんな Policy ファイルの指定方法については、@Policy および @Policies アノテーションによる JWS ファイルの更新を参照してください。
通常の反復的な開発プロセスの一部として、Web サービスを再コンパイルして再デプロイします。
『Oracle Fusion Middleware Oracle WebLogic Server JAX-RPC を使用した Web サービス入門』の 「WebLogic Web サービスの開発」および 『Oracle Fusion Middleware Oracle WebLogic Server JAX-RPC を使用した Web サービス入門 』の「WebLogic Web サービスの開発」を参照してください。
クライアント アプリケーションが使用するキーストアを作成します。アプリケーション ユーザごとにクライアント キーストアを 1 つ作成することをお勧めします。
このステップを実行するのに Sun microsystem のキーツール (http://java.sun.com/javase/6/docs/tooldocs/solaris/keytool.html
) ユーティリティを使用できます。開発目的のため、keytool ユーティリティは最も簡単な開始方法です。
『Oracle Fusion Middleware Oracle Weblogic server のセキュリティ』の 「プライベート キー、デジタル証明書、および信頼できる認証局の取得」を参照してください。
プライベート キーとデジタル証明書のペアを作成し、クライアント キーストアにロードします。同じペアを使用して、クライアントの SOAP リクエストにデジタル署名を行い、WebLogic Server からの SOAP 応答を暗号化します。
証明書のキーを使用することで、暗号化とデジタル署名の双方ができるようになっていることを確認してください。WebLogic Server でクライアントの証明書が有効であることを確認する方法については、「WebLogic Server でクライアントの証明書を検証できることの確認」も参照してください。
注意 : キーの長さは 1024 ビット以上にする必要があります。 |
このステップを実行するのに Sun microsystem のキーツール (http://java.sun.com/javase/6/docs/tooldocs/solaris/keytool.html
) ユーティリティを使用できます。
『Oracle Fusion Middleware Oracle Weblogic server のセキュリティ』の 「プライベート キー、デジタル証明書、および信頼できる認証局の取得」を参照してください。
Administration Console を使用して、セキュリティ レルムに認証用のユーザを作成します。
『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』を参照してください。
メッセージ保護された Web サービスを呼び出す Java コードを追加し、クライアント アプリケーションを更新します。
「クライアントサイドのセキュリティ ポリシー ファイルの使用」を参照してください。
クライアント アプリケーションを再コンパイルします。
全般的情報については、『Oracle Fusion Middleware Oracle WebLogic Server JAX-RPC を使用した Web サービス入門』および 『Oracle Fusion Middleware Oracle WebLogic Server JAX-RPC を使用した Web サービス入門』を参照してください。
簡単なメッセージレベルのセキュリティの使用例に基づいて Web サービス セキュリティを追加する使用例については、以下の節を参照してください。
メッセージ保護された Web サービスの問題をデバッグする方法については、「システム プロパティを使用したメッセージレベルのセキュリティのデバッグ」を参照してください。
クライアントが SOAP リクエストのデジタル署名に使用し、WebLogic Server がクライアントへの SOAP 応答の暗号化に使用する X.509 証明書を WebLogic Server で検証できることを確認しておく必要があります。以下のいずれか 1 つを実行します。
信頼性のある認証局で発行されているために WebLogic Server が自動的に信頼するデジタル証明書をクライアント アプリケーションが取得することを確認する。
WebLogic Server によって信頼される個々の証明書をすべて登録する証明書レジストリを作成し、クライアントがそれらの登録された証明書のいずれかを使用することを確認する。
詳細については、WebLogic Server のセキュリティの「SSL 証明書検証」を参照してください。
JWS ファイルで @Policy
アノテーションおよび @Policies
アノテーションを使用して、Web サービスに 1 つまたは複数のポリシー ファイルがアタッチされていることを指定できます。これらのアノテーションは、クラス レベルまたはメソッド レベルのいずれかで使用できます。
追加のポリシー オプションについては、「CLASSPATH からのポリシーのロード」を参照してください。
このリリースは、Oracle Web サービス セキュリティ ポリシーの使用"で説明されるように、Oracle の Web サービスマネージャ(WSM)WS-セキュリティ ポリシーを WebLogic Server 環境と統合するのに使用される@SecurityPolicy アノテーションをサポートします。
@Policies
アノテーションは、複数の @Policy
アノテーションをグループ化するものです。複数のポリシー ファイルをクラスまたはメソッドにアタッチする場合は、@Policies
アノテーションを使用してください。ポリシー ファイルを 1 つだけアタッチする場合は、そのファイル自体に対して @Policy
を使用します。
@Policy
アノテーションでは、1 つのポリシー ファイル、その場所、ポリシーが SOAP のリクエスト メッセージ、応答メッセージ、またはその両方のいずれに適用されるか、およびそのポリシー ファイルをサービスの公開 WSDL にアタッチするかどうかを指定します。
注意 : すべての JWS のアノテーションにあてはまることですが、@Policyアノテーションは実行時にはオーバーライドできません。つまり、開発時にアノテーションを使用して指定した Policy ファイルが、常に Web サービスに関連付けられることになります。したがって、たとえば、関連付けられているポリシー ファイルは実行時に Administration Console で確認できますが、削除 (関連付けを解除) することはできません。ただし、「Administration Console を使用した実行時のポリシー ファイルの関連付け」で説明されているように、追加のポリシー ファイルを関連付けることは可能です。 |
uri
属性を使用して、ポリシー ファイルの場所を以下のように指定します。
WebLogic Server にあらかじめパッケージ化されているセキュリティ ポリシー ファイルを指定するには、次の例に示すように、policy:
プレフィックスとポリシー ファイルの名前を使用する。
@Policy(uri="policy:Wssp1.2-2007-Https-BasicAuth.xml")
あらかじめパッケージ化されているポリシー ファイルを使用する場合は、独自のファイルを作成したり、アクセス可能な場所にファイルをパッケージ化したりする必要はありません。このため、できる限り、あらかじめパッケージ化されているポリシー ファイルを使用することをお勧めします。
あらかじめパッケージ化されているポリシー ファイルで提供される、各種のメッセージレベルのセキュリティについては、「メッセージレベルのセキュリティ コンフィグレーションでのポリシー ファイルの使用」を参照してください。
ユーザが作成したポリシー ファイルを指定するには、次の例に示すように、JWS ファイルの場所を基準とした相対パスと名前を指定する。
@Policy(uri="../policies/MyPolicy.xml")
この例では、MyPolicy.xml
ファイルは、JWS ファイルを格納するディレクトリの policies
兄弟ディレクトリにあります。
共有 J2EE ライブラリにあるポリシー ファイルを指定することもできる (共有 J2EE ライブラリは、別々の J2EE アーカイブにパッケージ化された複数の Web サービス間でファイルを共有する場合に使用すると便利)。
注意 : この場合、ポリシー ファイルが共有された J2EE ライブラリの META-INF/policies または WEB-INF/policies ディレクトリにあると思われます。ライブラリをパッケージ化する際には、このディレクトリにポリシー ファイルを入れるようにしてください。 |
共有 J2EE ライブラリにあるポリシー ファイルを指定するには、次の例に示すように、policy:
プレフィックスとポリシー ファイルの名前を使用します。
@Policy(uri="policy:MySharedPolicy.xml")
Web サービスが共有されたポリシー ファイルを見つけられるように共有ライブラリを作成して環境をセットアップする方法については、『Oracle Fusion Middleware 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 アノテーションの使い方を示します。該当する個所は太字で表示しています。
コード リスト 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; /** * この Web サービスはどう WS-SecurityPolicy1.2 を使用するかを示します。 *メッセージ レベル セキュリティを可能にするのは WS-セキュリティ 1.0 で指定しました * * サービスはユーザ名トークンをもっているクライアントを認証します。 * リクエスト メッセージおよび応答メッセージの両方が、X509証明書で署名と暗号化されます。 * */ @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 のリクエスト メッセージおよび応答メッセージの両方の本文が暗号化されることを指定しています。
このリリースの WebLogic Server には、「ポリシーを CLASSPATH からリソースとしてロードする」機能があります。この機能を使用すると、ポリシー ファイルを Web アプリケーションのルート ディレクトリにコピーし、JWS ファイルの @POLICY アノテーションから名前 (mypolicy.xml など) により直接参照することができます。
この機能を有効にするには、-Dweblogic.wsee.policy.LoadFromClassPathEnabled=true
から WebLogic Server を始動してください。
この機能を有効にした場合は次の点に注意してください。ポリシー ファイルを WEB-INF/policies ディレクトリに移動すると、@POLICY アノテーションの同じ「mypolicy.xml」参照が機能しなくなります。@POLICY アノテーションにポリシー プレフィックス (policy:mypolicy.xml など) を追加する必要があります。
「簡単なメッセージレベルのセキュリティのコンフィグレーション : 主な手順」で説明した、簡単なメッセージレベルのコンフィグレーション手順では、Web サービス ランタイムが WebLogic Server に用意されているプライベート キーと X.509 証明書のペアを使用することが前提となっています。SSL 用のコア セキュリティ サブシステムでも同じキー ペアが使用されます。このキー ペアは主にデモまたはテスト目的用に用意されています。プロダクション環境では、Web サービス ランタイムは通常、独自のプライベート キーとデジタル証明書のペアを 2 つ使用します。1 つは SOAP メッセージの署名用、もう 1 つは SOAP メッセージの暗号化用です。
以下では、これらを使用できるようにするための追加の手順について説明します。
Web サービス ランタイムで使用されるプライベート キーとデジタル証明書のペアを 2 つ取得します。ペアの 1 つは SOAP メッセージのデジタル署名に使用され、もう 1 つは SOAP メッセージの暗号化に使用されます。
必須ではありませんが、WebLogic Web サービスのみが使用するペアを 2 つ取得することをお勧めします。両方の証明書のキーの用途がコンフィグレーションの目的と一致していることを確認してください。たとえば、証明書を暗号化に使用するように指定する場合は、証明書のキーの用途が暗号用として指定されているか、または用途が定義されていないことを確認します。そうでない場合、Web サービス セキュリティ ランタイムによって証明書が拒否されます。
注意 : キーの長さは 1024 ビット以上にする必要があります。 |
このステップを実行するのに Sun microsystem のキーツール (http://java.sun.com/javase/6/docs/tooldocs/solaris/keytool.html
) ユーティリティを使用できます。開発が目的の場合は、keytool
ユーティリティを使用すると簡単に開始できます。
『Oracle Fusion Middleware Oracle Weblogic server のセキュリティ』の 「プライベート キー、デジタル証明書、および信頼できる認証局の取得」を参照してください。
この時点で存在していない場合は、WebLogic Server のカスタム ID キーストアを作成し、前の手順で取得したプライベート キーとデジタル証明書のペアをその ID キーストアにロードします。
SSL 用に WebLogic Server をすでにコンフィグレーションしてある場合は、この手順で使用できる ID キーストアがすでに作成されています。
このステップを実行するのに Sun Microsystem のキーツール (http://java.sun.com/javase/6/docs/tooldocs/solaris/keytool.html
http://java.sun.com/javase/6/docs/tooldocs/solaris/keytool.html
) ユーティリティを使用できます。開発が目的の場合は、keytool
ユーティリティを使用すると簡単に開始できます。
『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の「キーストアの作成およびプライベート キーと信頼性のある認証局のキーストアへのロード」を参照してください。
Administration Console を使用して、前の手順で作成したキーストアを指定するように WebLogic Server をコンフィグレーションします。WebLogic Server 用にコンフィグレーションしたキーストアをすでに使用している場合、この手順を実行する必要はありません。
『Oracle Fusion Middleware Oracle Weblogic server のセキュリティ』の「プロダクション用のキーストアのコンフィグレーション」を参照してください。
Administration Console を使用して、デフォルトの Web サービス セキュリティ コンフィグレーションを作成します。このコンフィグレーションの名前は default_wss
にする必要があります。デフォルトの Web サービス セキュリティ コンフィグレーションは、別のコンフィグレーションを使用するように明示的にプログラミングされていない限り、ドメイン内のすべての Web サービスで使用されます。
「Web サービス セキュリティ コンフィグレーションの作成」の『Oracle Fusion Middleware Oracle WebLogic Server Administration Console ヘルプ』を参照してください。
プライベート キーとデジタル証明書のペアの一方を SOAP メッセージのデジタル署名に使用するように、前の手順で作成したデフォルトの Web サービス セキュリティ コンフィグレーションを更新します。
「SOAP メッセージに署名する際に使用されるキー ペアの指定」の『Oracle Fusion Middleware Oracle WebLogic Server Administration Console ヘルプ』を参照してください。この手順では、キーストアとキー ペアの識別に使用されるプロパティを作成するときに各プロパティの正確な値 (IntegrityKeyStore
、IntegrityKeyStorePassword
など) を [名前] フィールドに入力します。ただし、独自に作成したキーストアとキー ペアを識別する値は [値] フィールドに入力します。
同様に、プライベート キーとデジタル証明書のペアのもう一方を SOAP メッセージの暗号化に使用するように、前の手順で作成したデフォルトの Web サービス セキュリティ コンフィグレーションを更新します。
「SAOP メッセージの暗号化に使用されるキー ペアの指定」の『Oracle Fusion Middleware Oracle WebLogic Server Administration Console ヘルプ』を参照してください。この手順では、キーストアとキー ペアの識別に使用されるプロパティを作成するときに、各プロパティの正確な値 (ConfidentialityKeyStore
、ConfidentialityKeyStorePassword
など) を [名前] フィールドに入力します。ただし、独自に作成したキーストアとキー ペアを識別する値は [値] フィールドに入力します。
メッセージ保護された Web サービスを呼び出すように Java コードを更新する場合には、クライアントのキーストアからプライベート キーとデジタル証明書のペアをロードし、その情報を、セキュリティ ポリシーで必要とされている場合はユーザ認証用のユーザ名およびパスワードとともに、呼び出されるセキュアな WebLogic Web サービスに渡す必要があります。
Web サービスのセキュリティ ポリシー ファイルで SOAP リクエストを暗号化するように指定されている場合、Web サービス クライアント ランタイムはサービスの WSDL にアタッチされているセキュリティ ポリシー ファイルからサーバの証明書を自動的に取得し、それを暗号化に使用します。ただし、ポリシー ファイルが WSDL にアタッチされていない場合や、WSDL 自体を使用できない場合には、クライアント アプリケーションはポリシー ファイルのクライアントサイドのコピーを使用する必要があります。詳細については、「クライアントサイドのセキュリティ ポリシー ファイルの使用」を参照してください。
コード リスト 2-2 はセキュリティ関連アノテーションでの JWS ファイルの更新で JWS ファイルによって説明されたメッセージで機密保護している WebLogic Web サービスを呼び出す Java クライアントアプリケーションを示しています。クライアント アプリケーションは、以下の 5 つの引数を取ります。
クライアント認証用のクライアント ユーザ名
クライアント認証用のクライアント パスワード
クライアントのプライベート キー ファイル
クライアントのデジタル証明書
デプロイされた Web サービスの WSDL
サンプル クライアント アプリケーションのセキュリティ固有のコードは太字で表示し、サンプルの後で説明します。
コード リスト 2-2 メッセージ保護された Web サービスを呼び出すクライアント アプリケーション
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 { //ユーザ名トークンのユーザ名またはパスワード String username = args[0]; String password = args[1]; //クライアントのプライベート キー ファイル String keyFile = args[2]; //クライアントの証明書 String clientCertFile = args[3]; String wsdl = args[4]; SecureHelloWorldService service = new SecureHelloWorldService_Impl(wsdl + "?WSDL" ); SecureHelloWorldPortType port = service.getSecureHelloWorldServicePort(); //資格プロバイダを作成し、それをスタブに設定する List credProviders = new ArrayList(); //クライアントサイドの BinarySecurityToken 資格プロバイダ -- x509 CredentialProvider cp = new ClientBSTCredentialProvider(clientCertFile, keyFile); credProviders.add(cp); //クライアントサイドのユーザ名トークン資格プロバイダ 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> rc = ((BindingProvider) port).getRequestContext(); rc.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 の場合は、これを次のようにコーディングできます。
rc.put(WSSecurityContext.TRUST_MANAGER, new TrustManager() { public boolean certificateCallback(X509Certificate[] chain, int validateErr) { return true; } });
このサンプルでは、クライアントサイドの TrustManager API が示されています。Web サービス アプリケーションには、セキュリティを確保するため、適切な検証コードを実装する必要があります。
簡単なメッセージレベルのセキュリティのコンフィグレーション : 主な手順で説明した、簡単な Web サービスのコンフィグレーション手順では、スタンドアロンのクライアント アプリケーションがメッセージ保護された Web サービスを呼び出すことが前提となっています。ただし、クライアント自体が EJB、サーブレット、または別の Web サービスの一部として、WebLogic Server インスタンスで実行されている場合もあります。この場合には、WebLogic Server コア セキュリティ フレームワークを使用して資格プロバイダとトラスト マネージャをコンフィグレーションして、EJB、サーブレット、または JWS コードには保護されたオペレーションの簡単な呼び出しのみが含まれ、他のセキュリティ関連の API の使用は含まれないようにできます。
以下では、この場合に WebLogic Server コア セキュリティ フレームワークを使用するための高度な手順について説明します。
EJB、サーブレット、または JWS コードで、メッセージレベルのセキュリティがコンフィグレーションされていないものとして Web サービスのオペレーションを呼び出します。具体的には、ユーザ名トークンまたは X.509 トークンを格納する CredentialProvider
オブジェクトを作成せず、セキュアな Web サービスのホストである WebLogic Server からの証明書を検証するための TrustManager
コア セキュリティ API も使用しないようにします。クライアント コードでこれらの API を使用しない理由は、Web サービス ランタイムによってこの作業が実行されるためです。
Administration Console を使用して、クライアント アプリケーションをホストする WebLogic Server インスタンスのコア セキュリティに必要な資格マッピング プロバイダをコンフィグレーションします。必要な資格マッピング プロバイダのリストは、呼び出す Web サービスにアタッチされるポリシー ファイルによって異なります。通常は、ユーザ名/パスワードおよび X.509 証明書用の資格マッピング プロバイダをコンフィグレーションする必要があります。指定できる値については、「資格プロバイダの有効なクラス名とトークン タイプ」を参照してください。
注意 : WebLogic Server には、ユーザ名/パスワードおよび X.509 用の資格マッピング プロバイダがあります。ただし、デフォルトでコンフィグレーションされているのはユーザ名/パスワードのみです。 |
Administration Console を使用して、前の手順でコンフィグレーションした資格マッピング プロバイダに実際の資格マッピングを作成します。サーバで実行されているクライアントに関連付けられたユーザ プリンシパルを、呼び出す Web サービスに対して有効な資格にマップする必要があります。『Oracle Fusion Middleware Oracle Weblogic server のセキュリティ』の「WebLogic 資格マッピング プロバイダのコンフィグレーション」を参照してください。
Administration Console を使用して、呼び出される Web サービスの X.509 証明書を信頼するように WebLogic Server コア セキュリティ フレームワークをコンフィグレーションします。『Oracle Fusion Middleware Oracle Weblogic server のセキュリティ』の「証明書検索および検証フレームワークのコンフィグレーション」を参照してください。
用意されている資格プロバイダとトラスト マネージャをクライアント アプリケーションで使用しない場合は、この手順で説明したように WebLogic Server コア セキュリティ フレームワークをコンフィグレーションする必要はありません。「クライアントサイドのセキュリティ ポリシー ファイルの使用」で説明されているスタンドアロンの Java コードと同じ API を EJB、サーブレット、および JWS コードで使用することで、そのコンフィグレーションをすべてオーバーライドできます。ただし、コア セキュリティ フレームワークを使用することで、WebLogic Server のコンフィグレーションが標準化され、Web サービスを呼び出すクライアント アプリケーションの Java コードが簡略化されます。
このセクションは付加セキュリティに関する分かりやすい例を 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-3 Web サービス コードを示します。
この Web サービスがattachToWsdl=falseを実装することに注意してください。したがって、コード リスト 2-4に示されているように、Web サービスクライアントが、ポリシーのクライアントサイドバージョンをロードする必要があります。
コード リスト 2-3 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; /** * * WS-Policy 1.2に署名や暗号化WS-Policyである * SOAP メッセージを受け入れるWeb サービス */ @WebService(name = "SignEncrypt", portName = "SignEncryptPort", serviceName = "SignEncrypt", targetNamespace = "http://signencrypt") @BindingType(value = "http://schemas.xmlsoap.org/wsdl/soap/http") // ドメイン レベル WebserviceSecurity コンフィグレーション @WssConfiguration(value = "Basic-UNT") @MTOM() //@スキーマ検証 public class SignEncrypt { @Policies( { @Policy(uri = "policy:Wssp1.2-2007-SignBody.xml", attachToWsdl=false), @Policy(uri = "policy:Wssp1.2-2007-EncryptBody.xml", attachToWsdl=false), /* *対称キーを使用することで、暗号化されて、署名されるプレーンテキスト * ユーザ名トークンとの対称の結合と認証があるWSS1.1X509 */ /* 基本-UNT WssConfiguration を使用する */ @Policy(uri = "policy:Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey-Basic128.xml", attachToWsdl=false) /* * プレーンテキストパスワードがあるユーザ名トークンは、認証を求める要求で送られて * クライアントのプライベート キーを契約されて、 * サーバの公開鍵で暗号化されます。クライアントは、リクエストの本文にも署名し、メッセージ内の署名によって保護された * パブリック証明書を含める。*サーバは、そのプライベート キーで応答の本文に署名し、そのパブリック * 証明書をメッセージの一部として送信する。リクエスト メッセージと応答メッセージの両方に、 * 署名されたタイム スタンプが含まれる。The encryption method is Basic256 */ /* untx509webservicesecurity WssConfiguration の使用 */ /* * @Policy(uri = * "ポリシー: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), /* * 対称キーを使用することで、暗号化されて、署名されるプレーンテキスト * ユーザ名トークンとの対称の結合と認証があるWSS1.1X509 */ /* 基本-UNT WssConfiguration を使用する */ @Policy(uri = "policy:Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey-Basic128.xml", attachToWsdl=false) /* * プレーンテキストパスワードがあるユーザ名トークンは、認証を求める要求で送られて * クライアントのプライベート キーを契約されて、 * サーバの公開鍵で暗号化されます。クライアントは、リクエストの本文にも署名し、メッセージ内の署名によって保護された * パブリック証明書を含める。サーバは、そのプライベート キーで応答の本文に署名し、 * そのパブリック証明書をメッセージの一部として送信する。リクエスト メッセージと応答メッセージの両方に、 * 署名されたタイム スタンプが含まれる。暗号化の方法は Basic256。 */ /* untx509webservicesecurity WssConfiguration の使用*/ /* * @Policy(uri = * "ポリシー: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), /* * 対称キーを使用することで、暗号化されて、署名されるプレーンテキスト * ユーザ名トークンとの対称の結合と認証があるWSS1.1X509 */ /* 基本-UNT WssConfiguration を使用する*/ @Policy(uri = "policy:Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey-Basic128.xml", attachToWsdl=false) /* * プレーンテキストパスワードがあるユーザ名トークンは、認証を求める要求で送られて、 * クライアントのプライベート キーを契約されて、 * サーバの公開鍵で暗号化されます。クライアントは、リクエストの本文にも署名し、メッセージ内の署名によって保護された * パブリック証明書を含める。*サーバは、そのプライベート キーで応答の本文に署名し、そのパブリック * 証明書をメッセージの一部として送信する。リクエスト メッセージと応答メッセージの両方に、 * 署名されたタイム スタンプが含まれる。暗号化の方法は Basic256。 */ /* 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; } }
コード リスト 2-4 はクライアントサイドポリシーをロードするのに weblogic.jws.jaxws.ClientPolicyFeature クラスを使用することの例を示しています。
例は大規模なインラインコメントを含んでいます。
コード リスト 2-4 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; /** * スタブ/ポートを作成してください、そして、クライアントサイドセキュリティ ポリシーと共にスタブ/ポートを設定してください。 * 特徴と MTOM 特徴 * @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(); // 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); } /** * セキュリティで webservice を呼び出すために使用するクライアント ポート/スタブを設定する * * @throws Exception */ private void setUp() throws Exception { createStubWithClientPolicy(); /** * 対称鍵または SOAP メッセージを暗号化するためにサーバ公開証明書を取得する * */ /** * 対称鍵または SOAP メッセージの署名を検証するにはサーバ公開証明書 * を取得する */ X509Certificate serverCert = (X509Certificate) CertUtils.getCertificate( certsDir + "/" + serverKeyStoreName, serverKeyStorePass, serverCertAlias, "JKS").get(0); List<CredentialProvider> credProviders = new ArrayList<CredentialProvider>(); /* * UserNameToken の設定 */ credProviders.add(new ClientUNTCredentialProvider(username.getBytes(), password.getBytes())); Map<String, Object> rc = ((BindingProvider) port).getRequestContext(); /* * Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey-Basic128.xml の場合、 * 対称鍵使用例であるため、クライアント側の公開証明書およびプライベート キーを * 指定する必要ではない。 serverCert は、対称鍵を * 暗号化するために使用します。 */ 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) { // サーバの証明書を信頼できるかどうかの検証に必要 System.out.println("Validating Server Certificate"); return true; } }); } /** * ポリシーファイルの InputStreams の配列を返します。 * * @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; } /** * ポリシー ファイルの InputStream を返す。 * * @param myPolicyName * @return * @throws FileNotFoundException */ private InputStream getPolicyInputStream(String myPolicyName) throws FileNotFoundException { return new FileInputStream(myPolicyName); } /** * endpointURL で webservice を呼び出す。 * (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
and 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-SecurityPolicy 1.2 ポリシー ファイルの使用」を参照してください。
注意 : このリリースでは、JAX-RPC の場合にのみ WS-Trust がサポートされます。 |
WebLogic Server では、Web サービス セキュリティで使用するためにセキュリティ トークン サービス (STS) からセキュリティ トークンを取得する WS-Trust クライアントを実装しています。WS-Trust クライアントはクライアント サイドの WebLogic Server Web サービス ランタイムによって内部的に使用されます。
WS-Trust クライアントは以下の方法でコンフィグレーションできます。
スタンドアロンの Web サービス クライアントの場合は、Web サービス クライアント スタブのプロパティを使用。
サーバ上で実行される Web サービス クライアントの場合は、MBean プロパティを使用。
WebLogic Server の 10g Release3(10.3) 以前のリリースでは、WS-Trust クライアントは、Web サービスで共存して WebLogic Server にホストされた STS からセキュリティトークンしか使用できませんでした。しかし、WS-Trust クライアントにとって、STS は現在、アクセスしやすさのみを求められ、共存する必要はありません。しかし、WS-Trust クライアントにとって、STS は現在、アクセスしやすさのみを求められ、共存する必要はありません。
以前のリリースの 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 Supported confirmation method is sender-vouches.
SAML 2.0
urn:oasis:names:tc:SAML:2.0:assertion Supported confirmation methods are sender-vouches and bearer.
WS-Trust クライアントに固有の一部のコンフィグレーション プロパティを設定します。それ以外のプロパティについては、Web サービス クライアントに通常存在するコンフィグレーション情報によって決定されます。たとえば、取得するトークンのタイプは、Web サービス クライアントが呼び出している Web サービスのセキュリティ ポリシーによって決定されます。
明示的に設定できるプロパティと適用されるトークン タイプは以下のとおりです。以降の節では、これらのプロパティの設定方法を示します。
STS URI (WS-SecureConversation および SAML)
STS セキュリティ ポリシー (SAML)
STS SOAP バージョン (SAML)
STS WS-Trust バージョン (SAML)
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 は、このリリースではサポートされません。たとえば、以下の STS URI のためのアサーションはサポートされません。<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> . . . :IssuedToken> |
以下のサンプル コードは、クライアント スタブでの 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://stsserver/standaloneSTS/wssc13/STS"; stub._setProperty("weblogic.wsee.wst.sts_endpoint_uri", sts);
コード リスト 2-5 は、WS-Trust クライアントの資格証明プロバイダを作成するために WebLogic Scripting Tool(WLST) を使用することと、太字で示されるように STS URI をコンフィグレーションすることを示します。
プロバイダ クラス名は以下のいずれかです。
weblogic.wsee.security.wssc.v200502.sct.ClientSCCredentialProvider
weblogic.wsee.security.wssc.v13.sct.ClientSCCredentialProvider
weblogic.wsee.security.saml.SAMLTrustCredentialProvider
コード リスト 2-5 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') #SCT トラスト クライアントの資格プロバイダを作成する。 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()
WebLogic Server Administration Console から STS URI をコンフィグレーションすると、使用する URI を WebLogic Server の開発段階ではなく実行時に決定できます。
Administration Console から STS URI をコンフィグレーションするには、次の手順に従います。
『Oracle Fusion Middleware Oracle WebLogic Server Administration Console ヘルプ』で説明されるように、Web サービスのセキュリティ コンフィグレーションを作成してください。空のコンフィグレーションが作成されます。
『Oracle Fusion Middleware Oracle WebLogic Server Administration Console ヘルプ』で説明されるように、Web サービスのセキュリティ コンフィグレーションを編集して、資格証明プロバイダーを作成してください。
[資格プロバイダの作成] タブで、以下のように入力します。
プロバイダ名。この MBean インスタンスの名前です。
プロバイダ クラス名は以下のいずれかです。
weblogic.wsee.security.wssc.v200502.sct.ClientSCCredentialProvider
または
weblogic.wsee.security.wssc.v13.sct.ClientSCCredentialProvider
または
weblogic.wsee.security.saml.SAMLTrustCredentialProvider
トークン タイプ。トークンを識別する短い名前です。sct や saml など。
[次へ] を選択します。
STS URI の名前と値のペアを入力します。
[完了] を選択します。
[Web サービス セキュリティ : 全般] タブで、[デフォルト資格プロバイダ STS URI] の値を設定します。
[デフォルト資格プロバイダ STS URI] は、この Web サービス セキュリティ コンフィグレーションのすべての WS-Trust 対応資格プロバイダにおける、デフォルトの STS エンドポイント URL です。
以下のサンプル コードでは、クライアント スタブでの STS セキュリティ ポリシーの設定方法を太字で示しています。
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("weblogic.wsee.security.wst_bootstrap_policy", policy);
コード リスト 2-6 は、デフォルト Web サービスセキュリティ設定の資格証明プロバイダを作成ためにWLST を使用することと、太字で示されるように STS セキュリティ ポリシーをコンフィグレーションすることを示します。StsPolicy
のプロパティの値は、WebLogic Server に含まれたポリシー(「WS-SecurityPolicy 1.2 ポリシー ファイルの使用」を参照) または、J2EE ライブラリのカスタム ポリシー ファイル (「カスタム ポリシー ファイルの作成と使用」を参照)のどちらかである必要があります。
コード リスト 2-6 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') #SAML トラスト クライアントの資格プロバイダを作成する。 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()
Console を使用して STS セキュリティ ポリシーをコンフィグレーションするには、次の手順に従います。
『Oracle Fusion Middleware Oracle WebLogic Server Administration Console ヘルプ』で説明されるように、Web サービスのセキュリティ コンフィグレーションを作成してください。空のコンフィグレーションが作成されます。
『Oracle Fusion Middleware Oracle WebLogic Server Administration Console ヘルプ』で説明されるように、Web サービスのセキュリティ コンフィグレーションを編集して、資格証明プロバイダーを作成してください。
[資格プロバイダの作成] タブで、以下のように入力します。
プロバイダ名。この MBean インスタンスの名前です。
プロバイダ クラス名は以下のいずれかです。
weblogic.wsee.security.wssc.v200502.sct.ClientSCCredentialProvider
または
weblogic.wsee.security.wssc.v13.sct.ClientSCCredentialProvider
または
weblogic.wsee.security.saml.SAMLTrustCredentialProvider
トークン タイプ。トークンを識別する短い名前です。sct や saml など。
[次へ] を選択します。
STS ポリシーの名前と値のペアを入力します。
[完了] を選択します。
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)
また、スタンドアロン クライアントを生成した対象の Web サービスの SOAP バージョンと異なる場合は、SOAP バージョンをコンフィグレーションする必要があります (定数の定義に関して、 (http://java.sun.com/javaee/5/docs/api/javax/xml/soap/SOAPConstants.html
)インタフェース SOAPConstantsを参照してください。)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-7 は WS-Trust と SOAP バージョンを設定することの例を示しています。
セキュリティ コンテキストと派生キーをコンフィグレーションするために、以下のあらかじめパッケージ化されている 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 ポリシー」を参照してください。
注意 : クラスタに対して共有のセキュリティ コンテキストを使用する Web サービスをデプロイしている場合、クラスタ間のセッション ステート レプリケーションもコンフィグレーションする必要があります。詳細については、「クラスタのフェイルオーバとレプリケーション」の『Oracle Fusion Middleware 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:RequestSecurityToken を返す必要がある。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 は、クラスタ内の特定の WebLogic Server インスタンスに固定されています。SecureConversation リクエストが間違ったサーバに届くと、自動的に正しいサーバに転送されます。WS-SecureConversation をホストするサーバ インスタンスに障害が発生した場合は、そのサーバ インスタンスが回復するまで SecureConversation を使用できなくなります。
Web サービスの呼び出し時にセキュリティ コンテキストのネゴシエーションを行うクライアント アプリケーションは、メッセージ保護された Web サービスを呼び出す標準的なクライアント アプリケーションに似ています。詳細については、「 クライアントサイドのセキュリティ ポリシー ファイルの使用」を参照してください。本質的には、セキュアなコンテキスト トークンを明示的にキャンセルするために、weblogic.wsee.security.wssc.utils.WSSCClientUtil API を使用できるという点だけが異なっています。
注意 : WebLogic Server には、ユーザの利便性だけを目的として WSSCCLientUtil API が用意されています。この Web サービス ランタイムでは、コンフィグレーションされたタイムアウトに到達するとセキュアなコンテキスト トークンが自動的にキャンセルされます。この API は、トークンをキャンセルする時期をより厳密に制御する必要がある場合にのみ使用します。 |
コード リスト 2-8 は、クライアントアプリケーションがセキュアな会話を可能にするパッケージ化されたセキュリティ ポリシー ファイルに関連する Web サービスを呼び出す、分かりやすい例を示しています。太字の、セキュリティ文脈に関連するセクションについては、例の後で議論します。
コード リスト 2-8 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(); //資格プロバイダを作成し、それをスタブに設定する List credProviders = new ArrayList(); //x509 を使用して wssc ハンドシェークを保護する 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(WSSecurityContext.TRUST_MANAGER, new TrustManager(){ public boolean certificateCallback(X509Certificate[] chain, int validateErr){ //サーバの証明書を信頼できるかどうかの検証に必要 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")); //呼び出しの終了後に SecureContextToken をキャンセルする 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));
WSSClientUtil
クラスの terminateWssc()
メソッドを使用して、セキュアなコンテキスト トークンを終了する。
WSSCClientUtil.terminateWssc(stub);
「簡単なメッセージレベルのセキュリティのコンフィグレーション : 主な手順」で説明した、簡単なメッセージレベルのコンフィグレーション手順では、Web サービスを実装する JWS ファイルで @Policy
および @Policies
JWS アノテーションを使用して、サービスに関連付けられている 1 つまたは複数のポリシー ファイルを指定する方法について説明しています。つまり、これは Web サービスのプログラミング時には Web サービスとそのオペレーションに関連付けるポリシー ファイルをあらかじめ認識しておく必要があることを示します。しかし、常にあらかじめポリシー ファイルを認識できるとは限りません。そのため、Web サービスをデプロイした後で Administration Console を使用して実行時にポリシー ファイルを関連付けることもできます。
JWS ファイルで @Policy
JWS アノテーションも @Policies
JWS アノテーションも使用せずに、Administration Console を使用して実行時にポリシー ファイルを関連付けることもでき、これらのアノテーションを使用して一部のポリシー ファイルを指定し、追加の WS-Policy ファイルを実行時に関連付けることもできます。ただし、いったん JWS アノテーションを使用してポリシー ファイルを関連付けると、その関連付けは実行時に Administration Console を使用して変更することはできません。
Administration Console では、ファイル内のポリシー アサーションが互いに矛盾していても、JWS アノテーションに関連付けられているポリシー ファイル内のアサーションと矛盾していても、実行時にポリシー ファイルを Web サービスやそのオペレーションにいくつでも関連付けることができます。ただし、関連付けられた複数のポリシー ファイルが連携できるように、管理者が確認する必要があります。何らかの矛盾がある場合は、クライアント アプリケーションが Web サービスのオペレーションを呼び出すときに、WebLogic Server から実行時エラーが返されます。
Administration Console を使用して 1 つまたは複数の WS-Policy ファイルを Web サービスに関連付けるには、EJB JAR ファイルの META-INF/policies ディレクトリ (EJB 実装の Web サービスの場合) または WAR ファイルの WEB-INF/policies ディレクトリ (Java 実装の Web サービスの場合) に WS-Policy XML ファイルを格納する必要があります。
Administration Console を使用して、ポリシー ファイルをランタイムのときに関連づけるの詳細については、「WS-Policy ファイルと Web サービスとの関連付け」 の『Oracle Fusion Middleware Oracle WebLogic Server Administration Console ヘルプ』を参照してください。
SAML Token Profile1.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 Profile1.1x (http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SAMLTokenProfile.pdf
)を実装するので、このセクションで説明されるように、ユーザはWeb サービス操作を呼び出すとき自分たちを認証するために SOAP メッセージの SAML トークンを使用できます。
SAML トークンの使用はサーバ間で機能します。つまり、ある WebLogic Server インスタンスで実行されているクライアント アプリケーションが、ID として SAML を使用して別の WebLogic Server インスタンスで実行されている Web サービスを呼び出します。クライアント アプリケーション自体が Web サービスであるため、Web サービス セキュリティ ランタイムによってすべての SAML プロセスが処理されます。
このサーバ間での使用に加えて、「WS-Trust クライアントのコンフィグレーション」で説明するように、WS-Trust を通じてスタンドアロン クライアントから SAML トークンを使用することもできます。
注意 : この節では、読者が SAML の基礎と、SAML を WebLogic Server のコア セキュリティに関連付ける方法を理解していることを前提としています。全般的情報については、『Oracle Fusion Middleware Oracle WebLogic Server Security の紹介』のSecurity Assertion Markup Language (SAML)を参照してください。以下では、あなたによって簡単なメッセージレベルのセキュリティのコンフィグレーション : 主な手順でステップに従って、今追加を可能にしたくなる手順が、アイデンティティのためにユーザ名トークンよりむしろ SAML トークンを使用するケースを使用すると思われます。 |
必要な SAML プロバイダがコンフィグレーションされていることを確認し、適切なパートナ エントリを追加します。この手順により、WebLogic Server コア セキュリティ サブシステムがコンフィグレーションされます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』:に以下のセクションを参照してください。
注意 : SAML トークン プロファイルで両方のバージョンの SAML を使用する場合は、SAML 1.1 と SAML 2.0 の両方のセキュリティ プロバイダをコンフィグレーションする必要があります。SAML 2.0 パートナーエントリのコンフィグレーションする場合、WSSIdPPartnerとWSSSPPartner エントリーの両方にパートナーの名前として目標 Web サービスのエンドポイント UR Lを使用する必要があります。SSL を使用する場合は、URL を HTTPS として指定します。 |
SAML Holder-of-Key ポリシーのような SAML アサーションに関連した署名を呼び出すポリシー (アサーションによって参照されているキーを使用してメッセージが署名される)、または Sender-Vouches ポリシー (送信側のキーを使用してメッセージが署名される) を使用する場合は、署名および検証用のキーと証明書をコンフィグレーションする必要があります。
Holder-of-Key シナリオに対して、クライアント証明書からの署名は、クライアントが SAML トークンが参照というプライベート キーを持っていることをが保障されます。Sender Vouches シナリオに対するクライアント証明書からの署名は、SAML トークンがあるメッセージが送信者によって生成されたことっを保障します。
注意 : これらのキーと証明書は、アサーション自体には署名の作成または認証として使用されることはありません。アサーションに対する署名の作成と検証には、SAML セキュリティ プロバイダでコンフィグレーションされているキーと証明書が使用されます。SAML Bearer ポリシーを使用する場合は、保護は SSL によって提供され、PKI 資格マッピング プロバイダは必要ありません。 WS-TRUST を介してスタンドアロン クライアントからの SAML トークンを使用する場合、トークンは PKI 資格マッピング プロバイダではなく Web サービス クライアント スタブを通じて渡されます。 |
送信側で 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
を作成する前に、実際のキーと証明書をキーストアにロードしておく必要があります。
Web サービス セキュリティ ランタイムが検証できるように、同じ証明書を受信側の証明書レジストリに追加します。
reg.registerCertificate(certalias, certfile)
WS-SecurityPolicy では SAML アサーションに対する確認メソッドが明示的ではなく暗黙的に指定されています。以下の全般的なガイドラインを検討してください。
SamlToken アサーションが <sp:AsymerticBinding>
または <sp:SymerticBinding>
の内部にある場合は、Holder of Key 確認メソッドを使用する。
Holder of Key 確認を使用するポリシーの例については表 2-1 を参照してください。
SamlToken アサーションが <sp:SignedSupportingTokens>
の内部にある場合は、Sender Vouches 確認メソッドを使用する。
Sender Vouches 確認を使用するポリシーの例のために、表 2-1を参照してください。
SamlToken アサーションが <sp:SupportingTokens>
の内部にある場合は、Bearer 確認メソッドを使用する。この場合「転送レベルのセキュリティのコンフィグレーションで説明されているように、移送レベルセキュリティを使用してください。
Bearer 確認を使用するポリシーの例のために、表 2-1 を参照してください。
この節では、セキュリティ ポリシーとして独自のスキーマを使用するポリシー ファイル内に SAML 確認メソッドを指定する方法について説明します。
注意 : SAML V1.1 と V2.0 アサーションは、確認方法を指定するのにそれぞれ <saml: SubjectConfirmation> と <saml2: SubjectConfimation>要素を使用します。確認メソッドはポリシー ファイルで直接指定されません。 |
ID として SAML トークンを要求するように Web サービスをコンフィグレーションする場合には、以下のいずれかの確認メソッドを指定できます。
sender-vouches
holder-of-key
これらの確認メソッドに関する詳細については、「SAML WebLogic Web サービスでの SAML トークン プロファイルのサポート」および Web サービス セキュリティ:SAML トークン プロファイル (http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SAMLTokenProfile.pdf
) 仕様自体を参照してください。
ID として SAML を使用することを指定するセキュリティ ポリシー ファイルを使用します。正確な構文はあなたが構成したい確認メソッドのタイプに頼っています。 (sender-vouches
, holder-of-key
)
sender-vouches 確認メソッドを指定するには、次の作業を行います。
<Identity><SupportedTokens>
要素の <SecurityToken>
子要素を作成し、TokenType
属性を SAML トークンの使用を示す値に設定する。
<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 確認メソッドを指定するには、次の作業を行います。
<Integrity><SupportedTokens>
要素の <SecurityToken>
子要素を作成し、TokenType
属性を SAML トークンの使用を示す値に設定する。
holder-of-key
確認メソッドのための <Integrity>
アサーションに SAML トークンを含めるのは、Web サービス ランタイムで sender-vouches
では必要でないメッセージの整合性の証明が必要なためです。
<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>
デフォルトでは、WebLogic Web サービス ランタイムは常に、関連付けられたすべての WS-Policy ファイルの <KeyInfo>
アサーションで指定されている X.509 証明書を検証する。SAML holder-of-key アサーション使用時にこの検証を無効化するには、SAML トークン ハンドラ上にプロパティを設定することで、Web サービスと関連付けられた Web サービス セキュリティ コンフィグレーションを指定する必要があります。Administration Console を使用することでどうこれをするかの情報については、『Oracle Fusion Middleware Oracle WebLogic Server Administration Console ヘルプ』の 「SAML holder_of_key アサーション使用時の X.509 証明書の検証の無効化」 を参照してください。
自身のセキュリティ ポリシー ファイルを作成することに関する追加情報に関しては、カスタム ポリシー ファイルの作成と使用 を参照してください。アサーションに関する参考情報については、『Oracle Fusion Middleware Oracle WebLogic Server Web サービス リファレンス』の「Web サービス セキュリティ ポリシー アサーションのリファレンス」を参照してください。
Web サービスを実装する JWS ファイルの該当する @Policy
アノテーションを更新して、前の手順で作成したセキュリティ ポリシー ファイルを指定します。たとえば、Web サービスのすべてのオペレーションの呼び出しで SAML を ID として使用する場合は、@Policy
アノテーションをクラスレベルで指定します。
Web サービスに関連付けるポリシー ファイルは、互いに矛盾しない限り、適宜組み合わせることができます。ただし、OASIS WS-SecurityPolicy 1.2 ファイルと、Oracle のセキュリティ ポリシー スキーマに従って記述されたセキュリティ ポリシー ファイルを組み合わせることはできません。
たとえば、SAML の ID としての使用を指定する <Identity>
セキュリティ アサーションのみを含む、簡単な MyAuth.xml
ファイルを作成し、あらかじめパッケージ化されている Wssp1.2-2007-EncryptBody.xml
ファイルおよび Wssp1.2-2007-SignBody.xml
ファイルとともにそのファイルを Web サービスに関連付けることができます。ただし、関連付けられた複数のポリシー ファイルが互いに矛盾しないように、管理者が確認する必要があります。何らかの矛盾がある場合は、実行時エラーが発生するか、または Web サービスが想定どおりに動作しなくなるおそれがあります。
通常の反復的な開発プロセスの一部として、Web サービスを再コンパイルして再デプロイします。
『Oracle Fusion Middleware Oracle WebLogic Server JAX-RPC を使用した Web サービス入門』の「WebLogic Web サービスの開発」を参照してください。
SAML を ID として使用してメイン Web サービスを呼び出すように、WebLogic Server インスタンスで実行されるクライアント アプリケーションを作成します。詳細については、WebLogic Server インスタンスで実行中のクライアントからの Web サービスの呼び出しを参照してください。
前述の使用例の多くでは、Administration Console を使用した、デフォルトの Web サービス セキュリティ コンフィグレーションの作成 (名前は default_wss
) が必要になります。このコンフィグレーションの作成後は、@weblogic.jws.security.WssConfiguration
JWS アノテーションを使用しなくても、属性のない状態でこのアノテーションを指定しても、すべての Web サービスにこのコンフィグレーションが適用されます。
ただし、指定するタイムスタンプ値をサービス間で変える場合など、Web サービスをデフォルト以外のセキュリティ コンフィグレーションに関連付ける必要が生じる場合もあります。
Web サービスをデフォルト以外のセキュリティ コンフィグレーションに関連付けるには、次の手順に従います。
default_wss
でない名前で『Oracle Fusion Middleware Oracle WebLogic Server Administration Console ヘルプ』の「Web サービス セキュリティ コンフィグレーションの作成」。
JWS ファイルを更新します。@WssConfiguration
アノテーションを追加して、このセキュリティ コンフィグレーションの名前を指定します。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Web サービス リファレンス』の「weblogic.jws.security.WssConfiguration」を参照してください。
注意 : 同じウェブアプリケーションにおける追加 Web サービスをパッケージして、また、これらの Web サービスが @WssConfiguration アノテーションを使用する場合、各 Web サービスに同じセキュリティ設定を指定する必要があります。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Web サービス リファレンス』の「weblogic.jws.security.WssConfiguration」を参照してください。 |
通常の反復的な開発プロセスの一部として、Web サービスを再コンパイルして再デプロイします。
『Oracle Fusion Middleware Oracle WebLogic Server JAX-WS を使用した Web サービス入門』の 「Invoking Web Services」および 『Oracle Fusion Middleware 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-2 メッセージレベルのセキュリティをデバッグするためのシステム プロパティ
システム プロパティ | データ型 | 説明 |
---|---|---|
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-4 はJAX-WS Web サービスからクライアントサイドポリシー ファイルを使用することの例を示します。
通常、クライアントサイドのポリシー ファイルは、デプロイ済みの Web サービスに関連付けられているポリシー ファイルとまったく同じものです。これら 2 つのファイルが異なり、ファイルに含まれるセキュリティ アサーションに矛盾がある場合は、Web サービス オペレーションを呼び出すとエラーが返されます。
クライアントサイドのポリシー ファイルは、SOAP メッセージのリクエスト、応答、またはその両方に関連付けることができます。また、ポリシー ファイルを Web サービス全体と関連付けるのか、Web サービスのオペレーションのうちの 1 つだけと関連付けるのかを指定できます。
次の手順では、Web サービス オペレーションを呼び出すクライアント アプリケーションにセキュリティ ポリシー ファイルを関連付ける高度な手順を説明します。
デプロイされた Web サービスを呼び出すクライアント アプリケーションを作成済みであり、クライアントサイドのポリシー ファイルを関連付けることでクライアント アプリケーションを更新することを想定しています。また、Ant ベースの開発環境を設定済みであり、かつ clientgen
Ant タスクを実行するためのターゲットを含む、作業用の build.xml
ファイルがあることが前提となっています。
『Oracle Fusion Middlewar Oracle WebLogic Server JAX-WS を使用した Web サービス入門 』の「Web サービスの呼び出し」および『Oracle Fusion Middleware Oracle WebLogic Server JAX-RPC を使用した Web サービス入門 』の 「スタンドアロン クライアントからの Web サービスの呼び出し : 主な手順」を参照してください。
クライアントサイドのセキュリティ ポリシー ファイルを作成し、クライアント アプリケーションからアクセスできる場所に保存します。通常、このセキュリティ ポリシー ファイルは、呼び出そうとしている Web サービス用にコンフィグレーションされた WS-Policy ファイルと同じものですが、サーバサイドのファイルはクライアント ランタイムに対しては公開されないため、クライアント アプリケーションは独自のローカル コピーをロードしなければなりません。
セキュリティ ポリシー ファイルの作成の詳細については、「カスタム ポリシー ファイルの作成と使用」を参照してください。
クライアントアプリケーションをビルドに使用するbuild.xml
ファイルをアップデートしてください。
Java クライアントアプリケーションをアップデートして、クライアントサイドポリシーファイルをロードしてください。
適切なタスクを実行して、クライアント アプリケーションを再ビルドします。次に例を示します。
prompt> ant build-client
次回クライアント アプリケーションを実行したときには、ポリシー ファイルのローカル コピーがロードされ、Web サービス クライアント ランタイムはこれを使用して SOAP リクエスト メッセージのセキュリティを有効にします。
注意 : すでにセキュリティ ポリシーが設定されている Web サービス オペレーション (たとえば、サーバ ポリシーからクライアントを生成する際に格納された WSDL ファイル内で設定された Web サービス オペレーション) が存在する場合、この手順に従ってクライアントサイドのセキュリティ ポリシーをプログラム的に設定すると、それ以前に存在していたポリシーはすべて削除されます。 |
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 Only)を参照してください。
JAX-WS の使用
JAX-WS の場合は、weblogic.jws.jaxws.ClientPolicyFeature
クラスを使用して、サービスで定義されている有効なポリシーをオーバーライドします。weblogic.jws.jaxws.ClientPolicyFeature
は javax.xml.ws.WebServiceFeature
を拡張しています。
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-9 は簡単なクライアントアプリケーションでこれらのポリシー メソッドを使用することの例を示しています。大胆さのコードは例の後に説明されます。
コード リスト 2-9 クライアントアプリケーションにおけるポリシーをロード
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; /** * ClientPolicyService Web サービスの <code>sayHello</code> オペレーションを呼び出す * 単純なスタンドアロンのクライアント アプリケーション。 * * @author Copyright © 1996, 2008, Oracle およびその関連会社。 * 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"); // Web サービスのポートを取得する標準的な方法 ClientPolicyPortType normal_port = service.getClientPolicyPort(); // 特定のオペレーションのリクエストと応答のための WS-Policy ファイル // の配列を指定する 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);
WebLogic Server には、ほとんどの Web サービス アプリケーションで使用できる WS-SecurityPolicy ファイルがいくつか用意されています。ポリシー ファイルはMW_HOME/WL_HOME
/server/lib/weblogic.jar
に位置しています。weblogic.jar
内で、ポリシー ファイルは /weblogic/wsee/policy/runtime
に位置しています。
これらのポリシーには 2 つのセットがあります。ほとんどの場合に同じ機能を実行しますが、ポリシーは異なるネームスペースを使用しています。
第一セットには「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 ポリシー ファイルについて説明します。
加えて、Web サービス実現のために最も良いセキュリティ ポリシー アプローチを選ぶかの情報に関しては、と このWebLogic Server のリリースで支えられない WS-SecurityPolicy 1.2 の要素については、ポリシーの選択 および適切なポリシーの選択のコンフィグレーション を参照してください。
転送レベルのポリシーでは、WSDL へのアクセスおよび Web サービス オペレーションの呼び出しに、https
プロトコルを使用する必要があります。
表 2-3 転送レベルのポリシー
ポリシー ファイル | 説明 |
---|---|
Wssp1.2-2007-Https.xml |
一方向 SSL。 |
Wssp1.2-2007-Https-BasicAuth.xml |
BASIC 認証による一方向 SSL。リクエストに認可ヘッダが含まれていない場合は 401 チャレンジが発生する。 |
Wssp1.2-2007-Https-ClientCertReq.xml |
双方向 SSL。受信側で、発信元のパブリック証明書をチェックする。認証にクライアント証明書を使用することも可能。 |
Wssp1.2-2007-Https-UsernameToken-Digest.xml |
ダイジェスト ユーザ名トークンによる一方向 SSL。 |
Wssp1.2-2007-Https-UsernameToken-Plain.xml |
プレーン テキスト ユーザ名トークンによる一方向 SSL。 |
Wssp1.2-Https.xml |
一方向 SSL。 |
Wssp1.2-Https-BasicAuth.xml |
BASIC 認証による一方向 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-4 保護アサーション ポリシー
ポリシー ファイル | 説明 |
---|---|
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 ヘッダが署名される。 |
以下のポリシーでは、WS-Security 1.0 のユーザ名トークン仕様および X509 トークン仕様がサポートされます。
表 2-5 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 トークン仕様がサポートされます。
表 2-6 WS-Security 1.1 のユーザ名および X509 トークン ポリシー
ポリシー ファイル | 説明 |
---|---|
Wssp1.2-2007-Wss1.1-X509-Basic256.xml |
非対称バインディングによる WSS 1.1 X509。 |
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-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 |
このポリシーは、署名確認、指紋キー参照といった WS-Security 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 ポリシーの反対で、リクエストが署名され、応答が暗号化される。 |
以下のポリシーでは、WS-SecureConversation 1.3 および WS-SecureConversation 2005/2 を実装しています。
表 2-7 WS-SecureConversation ポリシー
ポリシー ファイル | 説明 |
---|---|
Wssp1.2-2007-Wssc1.3-Bootstrap-Https-BasicAuth.xml |
BASIC 認証による一方向 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-Wssc1.3-Bootstrap-Https-BasicAuth.xml |
BASIC 認証による一方向 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 ヘッダは署名される。署名と暗号化には、暗号化キーからの派生キーが使用される。 |
表 2-1 に示されていたポリシーは、WS-セキュリティ SAML Token Profile1.0 と 1.1 を実行します。
注意 : WebLogic Server バージョン 10.3 は受信要求に対してのみSAML Holder of key をサポートしていました。WebLogic Server バージョン 10.3MP1 以降現在、要求と応答メッセージの両方が保護されます。 |
表 2-8 WS-Security SAML Token Profile ポリシー
ポリシー ファイル | 説明 |
---|---|
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-Saml2.0-SenderVouches-Wss1.1.xml |
メッセージは、WSS1.1 X509 対称バインディングにより要求側と応答側の両方で署名および暗号化される。SAML 2.0 トークンは Sender Vouches 確認メソッドによる認証用にリクエスト内で送信され、X509 トークンにより署名される。 |
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 トークンを使用します。 Wssp1.2-2007-Saml2.0-Bearer-Https.xmlを使用して、WebLogic Server は、移送レベルで SAML 2.0 Bearer が確認メソッドであることについてサポートします。 SAML1.1 Bearer はサポート対象外です。 SAML 2.0 をサポートしない他の製品で共同利用するために、SAML-over-HTTPS シナリオについて、sender vouchesの確認方法をお勧めします。 SAML1.1 Bearer を使用する代わりに Wssp1.2-2007-Saml1.1-SenderVouches-Https.xmlポリシーを使用してください。 |
WebLogic Server は、WS-SecurityPolicy 1.2 を実装したことで、セキュリティ ポリシーの幅広い選択肢を提供できるようになりました。Web サービスのセキュリティ ポリシーを選択する際は、以下の面での要件を考慮する必要があります。
パフォーマンス
セキュリティ
相互運用性
資格可用性 (X.509 証明書、ユーザ名トークン、クリア パスワードまたはダイジェスト パスワード)
Oracle では、可能な限り以下の指針に従うことを推奨します。
カスタム ポリシーを作成せず、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
表 2-1 での WS-SecurityPolicy1.2 アサーションは WebLogic Server のこのリリースではサポートされない。
注意 : 新しい WS-SecurityPolicy1.3 アサーションもこのリリースではサポート対象ではありません。 |
表 2-9 サポートされない WS-SecurityPolicy 1.2 アサーション
仕様 | アサーション | 備考 |
---|---|---|
5.1.1 |
TokenInclusion |
includeTokenPolicy=Once はサポートされない。 |
5.4.1 |
UsernameToken |
このリリースでは <sp:UsernameToken11> とパスワード派生キーのみがサポートされていない。その他のユーザ名トークン アサーションはサポートされる。 |
5.4.2 |
IssuedToken |
WS-Trust ポリシー アサーションはこのリリースではサポートされない。 |
5.4.3 |
X509Token |
すべてのトークンタイプをサポート。 |
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 SignedEncrtptedSupportingTokens |
このリリースでは以下はサポートされない。 ../sp:SignedParts アサーション、../sp:SignedElements アサーション、../sp:EncryptedParts アサーション、../sp:EncryptedElements アサーション メッセージにトークンが含まれていない場合 (たとえば、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 ポリシーでのみサポートされる。 |
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>
この例では、認可に対するユーザ名トークンの指定は省略可能 (Optional) です。ユーザが匿名かセキュリティ コンテキストがないためにユーザ名トークンを生成できない場合でも、クライアントは続行することができます。
セキュリティ ポリシーの適用プロセス中、欠落した要素に 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 バージョン 1.0 を使用しています。
これらの各アサーションでは Web サービス メッセージ内の 1 つまたは複数の要素を特定するため、すべての要素レベルのセキュリティ アサーションに対するカスタム セキュリティ ポリシー ファイルを使用する必要があります。通常、これらのカスタム ポリシー ファイルは、あらかじめパッケージ化されたセキュリティ ポリシー ファイルと併用されます。あらかじめパッケージ化されたファイルでは署名や暗号化の実行方法が定義され、カスタム ポリシー ファイルでは署名や暗号化の対象となる特定の要素が指定されます。
最初の手順は、対象の要素を特定する XPath 式を決定することです。それには、直接調べるかサービスの WSDL と XML スキーマを分析して、Web サービスで使用されている SOAP メッセージのフォーマットを理解する必要があります。
SOAP メッセージのフォーマットを確認し、必要な XPath 式を決定する方法は、使用しているツールによって大きく異なるため、このドキュメントでは扱いません。たとえば、次のような手順が考えられます。
要素レベルのセキュリティのない Web サービスを実行します。
SOAP のトレースを有効にします。
ログ内の SOAP メッセージを調べます。
その SOAP メッセージをもとに XPath 式を作成します。
または、特定の WSDL に対するサンプル SOAP リクエストを生成できるソフトウェア ツールがある場合は、そのツールを使用して XPath 式を生成します。
コード リスト 2-10に示した形式の SOAP リクエストを受け取る 「submitOrderRequest」 操作を持っている Web サービスの例を考慮してください。
太字の部分は後で要素レベルのカスタム ポリシーを作成するときに使用されます。
コード リスト 2-10 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> 要素とその子要素を暗号化する必要があると仮定します。これをするために、おそらくEncryptCreditCard.xml
と呼ばれる、カスタム セキュリティ ポリシー ファイルを作成するために太字の箇所のコード リスト 2-10から得られた情報を使用します。
コード リスト 2-11に示されていた例を考えてください。
コード リスト 2-11 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 のネームスペースのマッピングを処理する。
カスタムポリシーを作成した後に、ElementEncryption
ポリシーがsubmitOrder
Web サービス要求に使用されるように、コード リスト 2-12に示されているように、Policy アノテーションを JWS ファイルに追加してください。
コード リスト 2-12 カスタム ポリシー ファイルへの Policy アノテーションの追加
@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
カスタムポリシーを構成します。
要素レベルのセキュリティを実装するときは以下の点に注意してください。
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-13 は WS-セキュリティ 1.0 とWS-セキュリティ 1.1 の両方をサポートするセキュリティ ポリシーの例を示します。
注意 : <wsp:ExactlyOne> 要素の中で、各ポリシー選択肢が <wsp:All> 要素内にカプセル化されています。 |
コード リスト 2-13 複数の方法を定義するポリシー
<?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-13に示されているように、カスタムポリシーを作成することによって、ただ一つの Web サービスに関する複数のポリシー代替案を構成できます。また、ポリシー選択の優先順位を決定するように、Web サービス クライアントをコンフィグレーションします。
WebLogic Server のこのリリースでは、Web サービス クライアントのために WebLogic Server Administration Console を使用することで、またスタブを通してポリシー選択プリファレンスを構成できます。
以下の優先順位がサポートされています。
セキュリティ
パフォーマンス
互換性
Web サービス ランタイムではポリシー選択の優先順位を使用してポリシー選択肢を調べ、最適なものを選択します。
複数のポリシー選択肢がある場合は、コンフィグレーション済みの優先順位リスト、使用可能な資格、オプション機能の設定を活用して最適なポリシーが選択されます。
1 つのクライアントについて複数のポリシー選択肢が存在する場合は、以下の選択ルールが使用されます。
プリファレンス設定がされない場合、ポリシー代替wsp:optional=true
が定義されている場合を除いて、最初のポリシー代替手段が選択されます。
優先順位がセキュリティ優先に設定されている場合は、最大のセキュリティ機能を持つポリシーが選択される。
優先順位が互換性/相互運用性優先に設定されている場合は、最小のバージョンを持つポリシーが選択される。
優先順位がパフォーマンス優先に設定されている場合は、最小のセキュリティ機能を持つポリシーが選択される。
オプションのポリシー アサーションでは、以下の選択ルールが使用されます。
ポリシー選択のデフォルトの優先順位が設定されている場合は、アサーションのオプション属性は無視される。
優先順位が互換性またはパフォーマンスに設定されている場合は、オプション属性を持つアサーションは無視される。したがって、そのアサーションは無視される。
優先順位がセキュリティに設定されている場合は、オプションのアサーションは含まれ、選択肢のアサーションは生成されない。
Administration Console で適切なポリシー選択をコンフィグレーションするには、次の手順に従います。
機能的な Web サービス セキュリティ設定が既にない場合、『Oracle Fusion Middleware Oracle WebLogic Server Administration Console ヘルプ』で説明されるように、Web サービスセ キュリティ設定を作成してください。
Web サービス セキュリティ コンフィグレーションを編集します。[全般] タブで [ポリシー選択プリファレンス] を設定します。以下の値がサポートされています。
[なし] (デフォルト)
[セキュリティ、互換性、パフォーマンスの順] (SCP)
[セキュリティ、パフォーマンス、互換性の順] (SPC)
[互換性、セキュリティ、パフォーマンスの順] (CSP)
[互換性、パフォーマンス、セキュリティの順] (CPS)
[パフォーマンス、互換性、セキュリティの順] (PCS)
[パフォーマンス、セキュリティ、互換性の順] (PSC)
変更を保存してアクティブ化します。
適切なポリシー選択のシナリオにおいて、本文 (Body) が暗号化されるかどうかは (<sp:EncryptedParts> <sp:Body /></sp:EncryptedParts>
など)、ポリシー選択の優先順位ルールによって以下のように異なります。
デフォルト -- 最初のポリシー選択肢が決定に使用される。最初のポリシー選択肢に本文暗号化のアサーションが含まれている場合、本文は暗号化されます。最初のポリシー選択肢に本文暗号化のアサーションが含まれていない場合、本文は暗号化されません。
SCP、SPC -- 暗号化される
PCS、PSC -- 暗号化されない
CPS -- 暗号化されない
CSP -- 暗号化される
以下の 2 つのサンプルを検討します。コード リスト 2-14,では、コード化されたボディーアサーションは最初のポリシー代替にあります。したがって、デフォルトの優先順位の場合、本文は暗号化されます。デフォルト以外のポリシー選択の優先順位の場合は、他の優先順位ルールが適用されます。
コード リスト 2-14 最初のポリシー代替におけるボディアサーション
<?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-15では、コード化されたボディーアサーションは最初のポリシー代替にはありません。したがって、デフォルトの優先順位の場合、本文は暗号化されません。デフォルト以外のポリシー選択の優先順位の場合は、他の優先順位ルールが適用されます。
コード リスト 2-15 最初のポリシー代替にはないボディーアサーション
<?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>
WebLogic Server では、セキュリティ ポリシー内に使用できる転送レベルのアサーションが複数ある場合は、https を必要とするポリシーが使用されます。2 つ以上のポリシー選択肢が https を必要とする場合は、そのいずれかがランダムに選択されます。したがって、転送レベルのポリシー アサーションが混在する複数のポリシー選択肢を使用しないようにする必要があります。
注意 : 例は、JAX-RPC Web サービスにセキュリティを加えることを示します。このリリースでは、WS-セキュリティによる MTOM は JAX-WS とJAX-RPC の両方に対してサポート対象とされます。 |
Optimizing Binary Data Transmission Using MTOM/XOPで説明したように、 SOAP Message Transmission Optimization Mechanism/XML-バイナリーOptimized Packaging(MTOM/XOP)は SOAP メッセージにおける、xs:base64Binary
または xs:hexBinary
に関する XML データの伝達を最適化するためのメソッドを定義します。
この節では、WebLogic Server にすでに含まれている 2 つのサンプルの組み合わせについて説明します。
WL_HOME
\samples\server\examples\src\examples\webservices\wss1.1
WL_HOME
\samples\server\examples\src\examples\webservices\mtom
これらの既存のサンプルには、機能的なコードと、使用方法や機能、ビルド方法などを説明した多数の instructions.html
ファイルが含まれています。この節ではその説明を繰り返すのではなく、これらのサンプルに加える変更やその理由に焦点を当てています。
例は表 2-1に示されたファイルを使用します。ソースファイルの内容はその後のセクションで示されています。
表 2-10 MTOM/セキュリティ サンプルで使用されるファイル
ファイル | 説明 |
---|---|
build.xml |
サンプルをビルドおよび実行するためのターゲットが含まれたビルド ファイル。 |
configWss.py |
Web サービス セキュリティ コンフィグレーションをコンフィグレーションする WLST スクリプト。このファイルは |
MtomClient.java |
MTOM Web サービスを呼び出すスタンドアロンのクライアント アプリケーション。このファイルでは、Web サービスの WSDL に基づいて clientgen によって生成された JAX-RPC スタブを使用する。 |
SecurityMtomService.java |
MTOM Web サービスを実装する JWS ファイル。この JWS ファイルでは @Policy アノテーションを使用して、Web サービスに関連付けられた WS-Policy ファイルを指定する。 |
clientkeyStore.jks |
クライアントサイドのキー ストア。クライアントサイドの BinarySecurityToken 資格プロバイダの作成に使用される。 このファイルは |
serverkeyStore.jks |
サーバサイドのキー ストア。サーバサイドの BinarySecurityToken 資格プロバイダの作成に使用される。 このファイルは |
testServerCertTempCert.der |
サーバサイドの証明書。サーバサイドの BinarySecurityToken 資格プロバイダの作成に使用される。 このファイルは |
SecurityMtomService.java
JWS ファイルは太字に示されていた追加 ポリシー アノテーション で WL_HOME
\samples\server\examples\src\examples\webservices\mtom\MtomService.java
のそれと同じです。
コード リスト 2-16 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; /** * JAX-RPCとMTOMへのサンプル * * @author Copyright © 1996, 2008, Oracle and/or its affiliates. * All rights reserved. */ @WebService @Binding(Binding.Type.SOAP12) //この Web サービスの WSS + MTOM を有効にするには以下の既定のポリシー ファイルを追加する。 @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() { } /** * XOP のバイナリ オクテット ストリームとして入力を送信する * * @param bytes input bytes * @return A simple String */ @WebMethod public String echoBinaryAsString(byte[] bytes) { return new String(bytes); } /** * XOP のバイナリ オクテット ストリームとして出力を送信する * * @param s a simple String * @return byte[] */ @WebMethod public byte[] echoStringAsBinary(String s) { return s.getBytes(); } /** * XOP のバイナリ オクテット ストリームとして input byte[] を送信する * * @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-セキュリティ 1.1Encrypted Key 機能を使用します。Web サービスを呼び出すクライアント アプリケーションは暗号化キーを使用して暗号化と署名を行い、サーバは署名確認を送信する必要があります。
MtomClient.java
は、SecurityMtomService
Web サービスを呼び出すスタンドアロンクライアントアプリケーションです。Web サービスの WSDL に基づいて clientgen によって生成された JAX-RPC スタブを使用します。MtomClient コードはコード リスト 2-17に示されています。
コード リスト 2-17 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 weblogic.wsee.security.bst.ClientBSTCredentialProvider; import weblogic.wsee.security.unt.ClientUNTCredentialProvider; // クライアントサイドの資格プロバイダを作成するためのインポート クラス 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 { //クライアント キーストア ファイル String clientKeyStore = args[0]; String clientKeyStorePass = args[1]; String clientKeyAlias = args[2]; String clientKeyPass = args[3]; //サーバ証明書 String serverCertFile = args[4]; String wsdl = args[5]; SecurityMtomServiceService service = new SecurityMtomServiceService_Impl(wsdl); port = service.getSecurityMtomServiceSoapPort(); X509Certificate serverCert = (X509Certificate) CertUtils.getCertificate(serverCertFile); //資格証明プロバイダーのemtpyリストを作成する。 List credProviders = new ArrayList(); //証明書と重要パラメタに基づいてアイデンティティにX.509を使用するクライアントサイドの // BinarySecurityTokenの資格証明プロバイダーを作成する。 CredentialProvider cp = new ClientBSTCredentialProvider(clientKeyStore, clientKeyStorePass, clientKeyAlias, clientKeyPass, "JKS", serverCert); credProviders.add(cp); Stub stub = (Stub) port; // スタッブの特性に資格証明プロバイダーのリストを示すように設定する。 stub._setProperty(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders); //TrustManager を設定する。 stub._setProperty(WSSecurityContext.TRUST_MANAGER, new TrustManager() { public boolean certificateCallback(X509Certificate[] chain, int validateErr) { //通常、現実のアプリケーションでは、実際に証明書について確かめるJavaコードが、 //ここに行きます。 //単純化のために、この例は、証明書が有効であると仮定して、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 ファイルで ID に X.509 を使用して SOAP メッセージを署名または暗号化することが指定されている場合は、ClientBSTCredentialProvider を作成する必要があります (ユーザが ID としてユーザ名トークンを提示することが指定されている場合は、アプリケーションは ClientUNTCredentialProvider を作成する必要があります)。
この例は示された keystore、証明書別名、およびサーバ証明書に対してクライアントの BSTの 資格証明プロバイダーを作成します。パラメータ serverCert
で渡された証明書を使用して、メッセージ本文の内容が暗号化され、受信した署名が検証されます。着信する署名の一部として受信した KeyInfo (証明書の指紋など) では、同じサーバ証明書を正しく識別する必要があります。
また、Web サービス クライアント ラインタイムは、オペレーションが呼び出されると、SOAP リクエストのセキュリティ ヘッダを正しく作成するために、この WSDL を確認します。
最後に、クライアント アプリケーションは weblogic.security.SSL.TrustManager WebLogic セキュリティ API を使用して、SOAP リクエストの暗号化に使用される証明書が有効かどうかを確認する必要があります。クライアントランタイムが現実の状況では自動的には信頼できないWebサービスにより配布されているWSDLからこの証明書(例のserverCert
)を得るので、クライアントアプリケーションは確実にSOAP 要求を暗号化するために使用する前に確認する必要があります。
注意 : このサンプルで使用されるクライアントサイドの証明書とプライベート キーは簡単なテスト目的で作成されているため、WebLogic Server から常に信頼されます。このため、このサンプルを実行するためにサーバサイドのセキュリティ コンフィグレーションを追加する必要ありません。しかし実際には、クライアント アプリケーションは Verisign などの実在の認証局が発行した証明書を使用します。その場合、管理者は WebLogic Administration Console を使用して、WebLogic Server から信頼されるリストにこの証明書を追加する必要があります。 |
SecurityMtomService Web サービスは関連付けられたポリシー ファイルで課せられている要件に対応するために WebLogic Server API を明示的に呼び出すことはありません。また、どのセキュリティ プロバイダ、トークン、または他のメカニズムが呼び出されるかを Web サービスが認識する必要もありません。
スクリプト ファイル configWss.py
では WLST を使用して、アクティブなセキュリティ レルムのデフォルトの Web サービス セキュリティ コンフィグレーション default_wss
を作成およびコンフィグレーションします (デフォルトの Web サービス セキュリティ コンフィグレーションは、別のコンフィグレーションを使用するように明示的にプログラミングされていない限り、ドメイン内のすべての Web サービスで使用されます)。さらに、このスクリプトでは x509 トークンがサポートされるようにし、必要なセキュリティ プロバイダなどを作成します。
コード リスト 2-18 は、configWss.py
ファイルを示します。build.xml
ファイルがコマンド入力を提供します。注目すべき部分は太字で示されています。
コード リスト 2-18 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() #SecurityConfiguration でのアサート x509 の有効化。 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')); #デフォルトの 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 #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 #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 #xml 暗号化のカスタム キーストア。 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) #xml デジタル署名のカスタム キーストア。 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) #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 ファイルには、表 2-1に示されたターゲットがあります。
表 2-11 build.xml のターゲット
ターゲット | 説明 |
---|---|
client |
セキュリティ MTOM Web サービス クライアントをビルドするターゲット。 |
config.server.security |
Web サービス セキュリティをコンフィグレーションするターゲット。 |
deploy |
Web サービスをデプロイするターゲット。 |
server |
セキュリティ MTOM Web サービスをビルドするターゲット。 |
clean |
一時ディレクトリを削除する。 |
build |
server、client、および clean に依存する。 |
run |
セキュリティ MTOM Web サービス クライアントを実行するターゲット。 |
すべて |
デフォルト ターゲット。build、deploy に依存する。 |
完全なbuild.xml
ファイルはコード リスト 2-19 に示します。
コード リスト 2-19 build.xml File
<?xml version="1.0" encoding="ISO-8859-1"?> <project name="webservices.security_mtom" default="all" basedir="."> <!-- このビルドのグローバル プロパティを設定する --> <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" /> <!--クライアント キーストア--> <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 キーストア--> <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 サービス WLS Ant タスクの定義 --> <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> <!-- MTOM Web サービスを構築するターゲット --> <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> <!-- MTOM Web サービス クライアントを構築するターゲット --> <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> <!-- MTOM Web サービスをデプロイするターゲット --> <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> <!-- MTOM Web サービス クライアントを実行するターゲット --> <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> <!-- Web サービスのセキュリティをコンフィグレーションするターゲット --> <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>
次の手順に従って、サンプルをビルドおよび実行します。
Examples サーバを起動します。
MW_HOME
\WL_HOME\samples\server\examples\src\examples\examples.html
指示ファイルで説明されるように、環境をセットアップしてください。
MW_HOME\WL_HOME
\samples\domains\wl_server>setExamplesEnv.cmd
MW_HOME\WL_HOME
\samples\server\examples\src\examples\webservices
ディレクトリを変更して新しいサブディレクトリ security_mtom
を作成します。
build.xml
, configWss.py
, MtomClient.java
, およびSecurityMtomService.java
節の内容をコピーして、MW_HOME\WL_HOME
\samples\server\examples\src\examples\webservices\security_mtom
ディレクトリに同じファイル名にペーストします。
(clientKeyStore.jks
, serverKeyStore.jks
, および testServerCertTempCert.der
) の全てのファイルを
MW_HOME\WL_HOME
\samples\server\examples\src\examples\webservices\wss1.1\certs
から
新しいサブディレクトリ certs
にコピーします。
MW_HOME\WL_HOME
\samples\server\examples\src\examples\webservices\security_mtom\certs
MW_HOME\WL_HOME
\samples\server\examples\src\examples\webservices\security_mtom
ディレクトリ に変更します。
以下のコマンドを実行します。
prompt>
ant config.server.security
Weblogic Server を再起動します。
サンプルをビルド、デプロイ、および実行します。
prompt> ant build deploy run
SecurityMtomService Web サービスに対して配布している WSDLについて以下の URL で利用可能です
http://host:port/SecurityMtomService/SecurityMtomService?WSDL
完全なWSDLはコード リスト 2-20 に示します。
コード リスト 2-20 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>
この節では、WebLogic Server にすでに含まれているサンプルの更新方法について説明します。
WL_HOME
\samples\server\examples\src\examples\webservices\wsrm_security
この節では、最新バージョンのポリシー ファイルを使用するようにサンプルを更新する方法を示します。変更されたサンプルに示すように、新しいポリシー ネームスペースを使用することをお勧めします。OASIS 標準の公式のネームスペースであり、他のベンダと相互運用するときに適しているためです。
信頼性のある SOAP メッセージングとは、ある WebLogic Server インスタンスで実行されているアプリケーションが別の WebLogic Server インスタンスで実行されている Web サービスを確実に呼び出せるようにするフレームワークです。信頼性は、2 つの Web サービス間のメッセージ配信を保証する能力として定義されます。
WebLogic Webサービスは「WS-ReliableMessaging 1.1」仕様に従います。それは、異なった WebLogic Server アプリケーション・サーバーで動く 2 Web サービスが、ソフトウェアコンポーネント、システム、またはネットワークエラーの場合に信頼性を持って通信する方法について説明します。 具体的には、ソース エンドポイント (クライアント Web サービス) から送り先エンドポイント (オペレーションを確実に呼び出せる Web サービス) へ送信されるメッセージが、1 つまたは複数の配信保証に基づいて確実に配信されるか、そうでなければ必ずエラーが送出される、相互運用性を備えたプロトコルについて記述されています。WS-ReliableMessaging 仕様では、WS-ReliableMessaging に WS-SecureConversation を組み合わせて、信頼性のあるシーケンスとセキュアなセッションを関連付けることにより、相互運用可能なセキュリティの提供方法を定義しています。シーケンスの作成時に、送信側は、シーケンスの所有者の識別に使用されるセキュリティ コンテキスト トークンを指すセキュリティ トークン参照を提示する必要があります。以降の両方向のすべてのシーケンス メッセージとプロトコル メッセージは、参照されたキーの所有証明を提示する必要があります。
WebLogic の信頼性のある SOAP メッセージングは 2 つの Web サービス間でのみ機能します。つまり、WebLogic Web サービスは別の Web サービスからのみ確実に呼び出すことが可能で、スタンドアロン クライアント アプリケーションからは機能しません。このサンプルでは、両方のタイプ (ソースと送り先) の Web サービスの作成方法を示します。WsrmSecurityClient.java
クラスはソース Web サービスを呼び出すスタンドアロンの Java アプリケーションです。
既存のサンプルでは、次の 2 つの 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-12 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 インスタンスに対してこのスクリプトを実行する。用意されている Examples サーバでは、オペレーションを確実に呼び出すソース 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
JWS ファイルは太字で示されている改訂されたポリシー アノテーションでのWL_HOME
\samples\server\examples\src\examples\webservices\wsrm_security\ReliableEchoServiceImpl.java
と同じです。
コード リスト 2-21 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 ファイルに関連付けられます。
ReliableEchoServiceImpl Web サービスは関連付けられたポリシー ファイルで課せられている要件に対応するために WebLogic Server API を明示的に呼び出すことはありません。また、どのセキュリティ プロバイダ、トークン、または他のメカニズムが呼び出されるかを Web サービスが認識する必要もありません。
スクリプト ファイル configWss.py
では WLST を使用して、アクティブなセキュリティ レルムのデフォルトの Web サービス セキュリティ コンフィグレーション default_wss
を作成およびコンフィグレーションします (デフォルトの Web サービス セキュリティ コンフィグレーションは、別のコンフィグレーションを使用するように明示的にプログラミングされていない限り、ドメイン内のすべての Web サービスで使用されます)。さらに、このスクリプトでは x509 トークンがサポートされるようにし、必要なセキュリティ プロバイダなどを作成します。
configWss.py
ファイルは、WL_HOME
\samples\server\examples\src\examples\webservices\wsrm_security\configWss.py
のファイルと同じで、変更は太字で示されています。 build.xml
ファイルがコマンド入力を提供します。
コード リスト 2-22 configWss.py
: #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 #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.py
と似ていますが、ソースと送り先の Web サービスが 2 つのサーバにホストされている場合にのみ使用されます。
configWss_Service.py
ファイルは、 WL_HOME
\samples\server\examples\src\examples\webservices\wsrm_security\configWss_Service.py
のファイルと同じで、変更は太字で示されています。 build.xml
ファイルがコマンド入力を提供します。
コード リスト 2-23 configWss_Service.py
: #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 #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 :
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 Fusion Middleware JAX-RPC を使用した Oracle WebLogic Server Web サービス入門のWeb サービスの WSDL の参照を参照してください。
具象ポリシー ファイルでは、Web サービスのプログラミング時にセキュリティ トークンの詳細が明示的に指定されます。サービスのプログラミング時に、認証のタイプの詳細 (x509
トークンまたは SAML
トークンの使用など) や、キーストアの複数のプライベート キーと証明書のペアが暗号化とデジタル署名に使用されるかどうかなどが分かっている場合に、具象セキュリティ ポリシー ファイルを作成します。
下記の WebLogic Server Auth.xml
ファイルでは、Web サービスを呼び出すクライアント アプリケーションが、認証をサポートしているトークン (ユーザ名または X.509) のいずれかを使用して自身を認証する必要があることを指定します。
あらかじめパッケージ化されている Web サービス セキュリティ ポリシー スキーマ ファイルは抽象ファイルです。そのため、開発時には Auth.xml
ファイルに特定のユーザ名や X.509 トークンのアサーションはありません。ユーザが WebLogic Server に対してどのようにセキュリティをコンフィグレーションしたかによって、ユーザ名トークン、X.509 トークン、またはその両方が、Web サービスに関連付けられた実際の実行時バージョンの Auth.xml
ポリシー ファイルに示されます。さらに、実行時バージョンのポリシー ファイルにある X.509 トークンがクライアントの呼び出しに適用される場合は、SOAP メッセージの本文全体が署名されます。
ID として X.509 のみを使用し、ユーザ名トークンは使用しないように指定する場合、また ID として X.509 を使用していて SOAP メッセージの特定の部分だけを署名するように指定する場合は、カスタム セキュリティ ポリシー ファイルを作成する必要があります。
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-25 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>
WebLogic Server の Encrypt.xml
ファイルでは、SOAP メッセージの本文全体を暗号化することを指定します。デフォルトでは、暗号化トークンは SOAP メッセージに含まれません。
コード リスト 2-26 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>
WS-SecureConversation 仕様のとおりにクライアントと Web サービスでセキュリティ コンテキストを共有すること、および派生キー トークンを使用することを指定します。このファイルは、もっとも高度なセキュリティを確保できます。
このポリシー ファイルでは以下のコンフィグレーションが提供されます。
派生キー トークンを使用して、すべてのシステム SOAP ヘッダ、タイムスタンプ セキュリティ SOAP ヘッダ、および SOAP 本文を署名する。
派生キー トークンを使用して、SOAP メッセージの本文を暗号化する。これは、署名に使用されるものとは別のトークンです。
各 SOAP メッセージで派生キーの独自のペアを使用する。
デジタル署名と暗号化の両方において、キー長をデフォルトの 32 ではなく 16 とする。
セキュリティ コンテキストの有効期間を 12 時間とする。
デフォルトのセキュリティ コンテキストと派生キーの動作を変更する場合は、以降の節で説明するカスタム セキュリティ ポリシー ファイルを作成する必要があります。
注意 : このあらかじめパッケージ化されたセキュリティ ポリシー ファイルを指定する場合、他のあらかじめパッケージ化されたセキュリティ ポリシー ファイルは指定しないでください。 |
コード リスト 2-27 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>
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-28 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>