セキュリティ部会 （株）JIEC 工藤 奈緒美

Presentation on theme: "セキュリティ部会 （株）JIEC 工藤 奈緒美"— Presentation transcript:

1 セキュリティ部会 （株）JIEC 工藤 奈緒美
WS-Policy 仕様 皆さんお疲れ様です。JIEC工藤と申します。 本日は、セキュリティ部会の皆さんに教えて いただきながら、 WS-Policy 仕様について 調査した結果を発表したいと思います。 セキュリティ部会 （株）JIEC　工藤　奈緒美

2 目次 WS-Policy WSDL との関係 WS-Policy モデル WS-Policy フレームワーク ドメイン固有表明
WS-SecurityPolicy WSIT での実装 まとめ 本日お話する内容ですが、 まず WS-Policy について、WSDLとの関係を簡単に説明します。 それから WS-Policy モデルを紹介して、その表記仕様である WS-Policy フレームワークと、ドメイン固有表明のひとつである WS-SecurityPolicy について説明します。 次に、WS-Policy と WS-SecurityPolicy を利用した実装である WSIT について説明します。

3 WS-Policy WS-Policy 仕様とは、Web サービスの定義言語である WSDL で表現できない規則を表現する　XML を使用した記述ルール。 Ｗｅｂサービスの能力、要件（制約）を表現するもの。 WS-Policy WS-Policy 仕様とは、Web サービスの定義言語である WSDL で 表現できない規則を表現する　XML を使用した記述ルールで、 Ｗｅｂサービスの能力、要件（制約）を表現するものです。 WSDLで記述されたWebサービスに対して、メッセージ最適化、信頼性、 セキュリティという各領域で、サービスの能力や要件（制約）を表現するための 仕様が、WS-Policy です。 具体的には、ブートストラップは、クライアントがサービス・レジストリから URL を 取得し、ポリシーや WSDL などのメタデータを取得するための仕様、 メッセージ最適化は MTOM (SOAP Message Transmission Optimization Mechanism) という Webサービスでバイナリ・データを扱うための仕様、信頼性 ならばコネクション確立手順の仕様、セキュリティならば署名、暗号化などの 仕様です。 ここにはこの３つを挙げましたが、この他にも、例えばトランザクション処理に 関する記述など、様々な領域のルールがあり得ます。 メッセージ最適化 信頼性 セキュリティ WSDL1.1

4 wsdl1.1 で表現できること wsdl (http://schemas.xmlsoap.org/wsdl/) で表現できること 操作
電文形式 通信プロトコル テレフォンバンキング サービスインタフェース 口座情報 残高照会 支払先検索 支払先登録 テレフォンバンキング 通信プロトコルはSOAP WSDL で表現できない部分を記述するのが WS-Policy ですが、 では WSDL で表現できることは何か、ということを簡単に説明 します。こちらは、Eclipse の WTP プラグインの機能である WSDL Editor で、サンプルの WSDL を開いたところです。テレフォン バンキングというサービスインタフェースの中に、残高照会、 支払先検索、支払先登録、支払い、という４つの操作と、それぞれの 操作の入力／出力電文の定義があります。矢印の先が、電文形式の 定義です。例えば、残高照会操作の入力電文である口座情報は、 氏名と口座番号で構成されています。通信プロトコルは SOAP を 使用しています。 要するに、WSDLで表現できるのは、操作、電文形式、 通信プロトコルだけです。 支払 Eclipse SDK 3.2.1 WTP(Web Tools Platform)プラグイン WSDL Editor

5 WS-Policy 関連仕様 : ポリシー記述の枠組み WS-Policy Framework [W3Cで標準化中]
WS-PolicyAttachment [W3Cで標準化中] ドメイン固有表明(Assertions) WS-SecurityPolicy（セキュリティ関連） [OASIS で標準化中] WS-RM Policy（高信頼メッセージング関連） [OASIS で標準化中] WS-BA Policy（WS-BusinessActivity)（トランザクション関連） [OASIS で標準化中] AT Policy (WS-AtomicTransaction) （トランザクション関連） [OASIS で標準化中] WS-MTOMPolicy（メッセージ送信の最適化関連）[標準化団体未提出] ポリシー取得プロトコル WS-MetadataExchange（メタデータ取得関連）[標準化団体未提出] 　　　 : WSDL を拡張するための WS-Policy 関連仕様には、 W3C という国際標準化団体で標準化中の、 WS-Policy フレームワーク、WS-Policy アタッチメント があります。 WS-Policy フレームワークは、特定の業務分野固有の 表明の組み合わせルールを記述するための仕様です。 WS-Policy アタッチメントは、Webサービス本体の仕様 である WSDL と、ポリシーを紐付けるための仕様です。 特定業務分野固有のルールを記述する仕様としては、 セキュリティ関連の WS-SecurityPolicy 、信頼性関連の WS-RM Policy、トランザクション関連のWS-BA Policy、 AT Policy などがあり、いずれも標準化の途中です。 この他にも、WS-MTOMPolicy というメッセージ送信の最適化に 関する仕様や、WS-MetadataExchange という WSDL、ポリシー などのメタデータを取得するプロトコルの仕様がありますが、こちら は現在標準化団体に提出されていないという問題点があります。

6 WS-Policy モデル ポリシーは複数ポリシーを含むことができる。
複数ポリシーを AND または OR 条件で組み合わせることができる。 PolicyA 全体ポリシーとしては、条件１、２、３のうちのいずれか一つを満たせば良い(PolicyA)が、特定業務に限り、条件１、２、３の全てを満たさねばならない(PolicyB) ExactlyOne PolicyB 条件１ All では、WS-Policy モデルについて簡単に説明します。 基本的なルールは、 ・ポリシーは複数ポリシーを含むことができる。 ・複数ポリシーを AND または OR 条件で組み合わせることができる。 ということです。 図のポリシーＡが全体ポリシーで、ExactlyOne で囲まれているので 条件１，２，３のうちのいずれか一つを満たせば良いのですが、 部分的にポリシーＢを適用するところは、 All で囲まれているので 条件１，２，３の全てを満たさなければならないということになります。 条件２ 条件１ 条件３ 条件２ 条件３

7 DigestAlgorithm(SHA)
WS-Policy Framework 列挙された条件の全て(AND) Policy Policy choice All 列挙された条件のうちのどれかひとつ(OR) ExactlyOne name(URI) PolicyReference Id こちらが、WS-Policy フレームワークのスキーマ構造です。 ポリシーには URI や Id という属性があり、その中に All または ExactlyOne で囲まれた個別の条件を含めることもできますし、 ネストしたポリシー や、 URI などで表される別のポリシーへの 参照を含めることもできます。 URI Digest(base64Binary) DigestAlgorithm(SHA) any

8 WS-Policy のスキーマ （抜粋） ポリシー要素の型 繰り返し：０～∞ポリシー自体あってもなくても良い 何でも可能
こちらが、実際のスキーマファイルの一部です。 ポリシー要素の型は OperatorContentType 型の拡張型であり、 その子要素としては Policy, All, ExactlyOne, PolicyReference などから 選択することができますが、最後に any というタグがあるので、その他 にオリジナル・タグも使用して、拡張することが可能です。 スキーマを拡張する際の注意点としては、 ①ポリシーを作る側と使う側が合意した場合に限る ②WS-Policy の名前空間に要素を追加するのではなく、名前空間を変更して 追加する、などがあります。 何でも可能

9 WS-PolicyAttachment PolicyAttachment PolicyURIs WSDL へのポインタ AppliesTo Policy 次に、こちらが WS-PolicyAttachment の仕様です。 PolicyAttachment には、PolicyURIs という属性があり、 子要素として、 WSDL へのポインタである AppliesTo タグと ポリシーへのポインタである Policy タグまたは PolicyReference タグ のいずれかを持ちます。 ポリシーへのポインタ choice PolicyReference any

10 WS-PolicyAttachment のスキーマ（抜粋）
Webサービス本体(wsdl)への紐付け ① ② ポリシーへの紐付け ③ こちらが、実際の WS-PolicyAttachment のスキーマです。 PolicyAttachment 要素の子要素として WSDL への紐付け をする AppliesTo タグと、ポリシーへの紐付けをする Policy または PolicyReference タグがあります。 また、最後に any タグがあるので、他に必要なものを何でも 追加することができます。 ここまでが ポリシーの枠組み部分の仕様となります。 何でも追加可能

11 WS-SecurityPolicy Ｗｅｂサービスのセキュリティに関する仕様 メッセージ保護方法（署名、暗号化）の表明方法
Ｗｅｂサービスのセキュリティに関する仕様 メッセージ保護方法（署名、暗号化）の表明方法 セキュリティ・トークン（構成要素）の表明方法 ユーザ名/パスワード X.509証明書 Kerberosチケット SAMLアサーション RELライセンス WS-SecureConversationのセキュリティ・コンテキスト・トークン 署名、暗号化のアルゴリズムの表明方法 Basic256、３DES、SＨＡ、RSAなどを利用 鍵交換方式などの指定 次に、ドメイン固有表明のうちのひとつである WS-SecurityPolicy について 説明します。こちらは、Ｗｅｂサービスのセキュリティに関する仕様で、 署名、暗号化などのメッセージ保護方法の表明方法や、 ユーザー名、パスワード、X509証明書、ケルベロス・チケット、 SAMLアサーション, RELライセンス 、WS-SecureConversation のセキュリティ・コンテキスト・トークンといったセキュリティ・トークンの 表明方法や、Basic256、3DES、ＳＨＡ、ＲＳＡといった署名・暗号化 アルゴリズムや鍵交換方式の表明方法について決めた仕様です。 WS-Policy の ExactlyOne や All で囲まれた、個別の条件に当たる部分です。 セキュリティ・ポリシーのスキーマを使用したポリシーの１例が、ＷＳＩＴの チュートリアルとして SunMicroSystems から公開されています。

12 WSIT とは WSIT = Web Services Interoperability Technology
Ｊａｖａ プラットフォームと .NET プラットフォームの相互運用性促進を目的に、SunMicrosystems が各種Ｗｅｂサービス技術をまとめた実装 オープンソース WSIT のチュートリアル( で使用している設定ファイル WSDL と WS-Policy を WS-PolicyAttachment を使用して統合 WSITとは、Web Services Interoperability Technology の略で、 Ｊａｖａ プラットフォームと .NET プラットフォームの相互運用性促進を目的に、 Sun Microsystems が各種Ｗｅｂサービス技術をまとめた実装で、 すでにオープンソースで開発が進んでいるそうです。 このチュートリアルで使用している設定ファイルでは、WSDL と WS-Policy を WS-PolicyAttachment を使用して統合した形式になっています。

13 WSIT 設定ファイル① WSDL WS-Policy Eclipse SDK 3.2.1
WTP(Web Tools Platform)プラグイン XML Editor こちらが、WSITの設定ファイルを Eclipse SDK の XML Editor で開いたところです。 WSDL の外枠である definitions タグの直下に、message, portType, binding, service という WSDL のタグに続いて、WS-SecurityPolicy 仕様を含む WS-Policy フレームワークのPolicy タグが３つあることがわかります。 WSDL WS-Policy

14 WSIT 設定ファイル② １．計算機全体のポリシー Sun/WSIT 独自のもの １．１．共有鍵のポリシー １．２．Trust10のポリシー
このAll直下のポリシーを全て満たす必要がある アドレッシングを使用 プライベートキーを保存したファイルにアクセスする仕組み Java keystore を使用 Sun/WSIT 独自のもの 信頼性のある証明書を保存したファイルにアクセスする仕組み まず一つ目のポリシーを見てみると、Id が CalculatorWSPortBindingPolicy という 名前の、計算機全体のポリシーであることがわかります。そのポリシーの要素は、 All タグで囲まれているので、含まれる個別の表明またはポリシーは、全て満たす 必要があることがわかります。個別の表明としては、アドレッシングを使用することや、 また Sun/WSIT 独自のタグとなりますが、プライベートキーを保存したファイルに アクセスする仕組みや、信頼性のある証明書を保存したファイルにアクセスする 仕組みがあり、いずれも Java keystore を使用しています。 証明書にアクセスする仕組みは、さらにネストしたポリシーを含むといった構造に なっています。 １．１．共有鍵のポリシー ネストしたポリシー １．２．Trust10のポリシー １．３．署名に使用する要素のポリシー １．４．Wss11のポリシー

15 WSIT 設定ファイル③ １．１．共有鍵のポリシー こちらは、そのネストしたポリシーの中のひとつで、共有鍵のポリシーですが、
メッセージ保護のために、 X509証明書のトークンを使用し、導出鍵が 必須で、X509証明書のハッシュ値であるサムプリントが必須であることなど がわかります。 X509証明書のトークンを使用 導出鍵必須 　　　　　　指紋認証必須

16 WSIT 設定ファイル④ １．２．Trust10のポリシー １．３．署名に使用する要素のポリシー １．４．Wss11のポリシー
こちらが、ネストしたポリシーの2つ目以降です。 ２つめの、Trust10 のポリシーとしては、発行済の要素はサポート必須、 クライアントエントロピーとサーバーエントロピーも必須であることがわかります。 ３つめのポリシーからは、署名には X509証明書を使用し、 ４つめのポリシーからは、発行者通番による参照のサポートが必須であり、 サムプリント参照のサポートが必須であり、暗号化された鍵の参照のサポートが 必須であり、鍵識別子による参照のサポートが必須であることがわかります。 １．４．Wss11のポリシー 発行者通番による参照のサポート必須 サムプリント参照のサポート必須 暗号化された鍵の参照のサポート必須 鍵識別子による参照のサポート必須

17 WSIT 設定ファイル④ ２．計算機入力のポリシー このAll直下のポリシーを全て満たす必要がある
暗号化対象は SOAP の Body 部分 暗号化要素は特に指定なし 署名対象はSOAP の Body 部分と Header の一部 こちらが、トップレベルの2つ目のポリシーで、CalculatorWSPortBinding_addinput_Policy という名前の計算機入力のポリシーです。 暗号化と署名に関する表明が All で囲まれているので、これらを全て満たす必要があります。 暗号化対象は SOAP の BODY 部分で、暗号化要素を表す EncryptedElements というタグ がありますが、この例では設定されていません。 署名対象部分は SOAP の BODY 全体と、ヘッダー内の 宛先、送信者、 送信に失敗したときのメッセージ送付先、返信先、メッセージID、関連メッセージ、 アクションといった属性であることがわかります。署名要素を表す SignedElements というタグがありますが、この例では設定されていません。 トップレベル3つ目のポリシーは、計算機出力のポリシーで、計算機入力の ポリシーとほぼ同じなので、説明は省略します。 署名要素は特に指定なし

18 まとめ WS-Policy は、ＷSDL で表現される Web サービスを拡張するもの。
以上で、まとめに入ります。 WS-Policy は、ＷSDL で表現される Web サービスの能力、要件（制約）を 表現するもので、その他のドメイン固有ルールを組み合わせるルールです。 ドメイン固有ルールには、今のところメッセージ最適化、信頼性、セキュリティ などの領域があり、今後もその領域は拡張する見込みです。 そして、これらのポリシーを表す XML のタグは、自由に拡張することが 可能で、そのタグをどんな意味に解釈するかは、特に規定がない限り 実装する人に任されています。 ということで、WS-Policy を使ってみたい場合は、既存の製品に組み 込まれた機能を使うこともできますし、また製品の機能に飽き足らない というハイレベルな人は、自分で１から作ってみることも可能です。 さらに、このパッケージがオープンソース化された場合は既存のソース を読んで勉強することもできますし、機能の追加や修正も可能です。 それぞれの目的や用途に合った使い方を自分で選択することが 可能です。 メッセージ最適化 信頼性 セキュリティ WSDL1.1

19 （参考） XMLスキーマのデザインパターン ロシアン・ドール
WS-Policy とは直接関係ないのですが、 ご参考までに、XMLのパターンをご紹介します。 こちらは、ロシアン・ドールというパターンです。 入れ子人形で知られるマトリョーシカのように、全てのエレメントと複合型が 一つのエレメントの中に入れ子になった形で定義されているようなスキーマ です。エレメント、複合型がまとめて入れ子に定義されています。ぜんぶ 一まとめでわかりやすいのですが、再利用をしようとするときには全て使うか、 すべて使わないかのどちらかしか選べません。

20 （参考） XMLスキーマのデザインパターン ベネチアン・ブラインド
次に　ベネチアン・ブラインドというパターンです。 このパターンはマトリョーシカ・パターンの特徴を受け継いでいます。違いは 中に含まれているエレメントの型をグローバルに定義しているところです。

21 （参考） XMLスキーマのデザインパターン サラミ・スライス
次にサラミ・スライスというパターンです。 すべてのエレメントがグローバルに定義されているようなスキーマです。すべての エレメントが再利用しやすい形ですが、どこがルートなのかが分かりにくいという 欠点があります。

22 （参考） XMLスキーマのデザインパターン エデンの庭
最後に、エデンの庭というパターンです。 ベネチアン・ブラインドとサラミスライスの混合型です。 すべてのエレメントと型は別々に定義されます。 細かく再利用できそうですが、細かすぎてわかりにくいかもしれません。 以上、ロシアン・ドール、ベネチアン・ブラインド、サラミ・スライス、エデンの庭 という４つの典型的なパターンをご紹介しました。

23 お疲れ様でした 私からは以上です。お疲れ様でした。