2009年11月27日金曜日

Rampart 1.4 サンプルの観察 (policy編)

前ポストでは、Rampart サンプルのうち basic フォルダ下にあるものを眺めてみた。今回は、policy フォルダにあるものを見てみる。

basic サンプルには client.axis2.xml があって、これがクライアントの挙動を定義していたけど、policy サンプルでは 同じような事を WS-Policy の形式で policy.xml に記述している。service.xml の方にも、この形式でサービスの挙動が書かれている。

また、policy.xml と service.xml への記述以外にも、http://localhost:8080/axis2/services/sample0{1~6}?wsdl を見ると、WSDL にも含まれているのがわかる。更に、sample 06 では、サービスのメタデータとしてもやり取りされているのが観察できる。

policy サンプルを動かすやり方は、基本的に basic サンプルと同様。ただし、sample 05 を動かすために以下の追加作業が必要。
  • backport-util-concurrent.jar (バージョン3.1) が無いので、どこかから落としてきて(ググればすぐ見つかる)%AXIS2_HOME%\lib に置く
  • OpenSAML をここ(→URL)から落として取り替える。
また、sample 05, 06 では echo 以外の複数のサービスを立てているので、TCPMon で観察するには、build.xml の他に Java コードや *.xml に含まれているポート番号も書き換える必要がある。(見ればすぐ分かる)

ちなみにsample 05, 06 では他サンプルと共通の echo サービスのほかに、SAML セキュリティートークンを発行するための sts サービスがあり、さらにsample 06 ではセキュリティポリシーを表示するための mex サービスもある。(この複数サービス間のセキュリティ連携の辺りの観察が、特に面白い。)

以下、サンプルで使われている主な Webサービス/XML仕様。
仕様の名前サンプル番号
WS-Addressing (wsa)01~06
WS-Security (wsse)01~06
WS-Security (wsu)01~06
WS-Security (wsse11)04~06
XML-Signatures (ds)02~06
XML-Encryption (xenc)03~06
前ポスト参照
WS-Policy (wsp)01~06
どんなセキュリティトークンを使うかだとか、サービスのポリシーを定義するフレームワーク。WS-SecurityPolicyや、その他の Web サービス仕様による記述を<wsp:Policy>要素の中に含める形で、組み合わせて使う。この<wsp:Policy>要素は、WSDL、policy.xml、service.xml、また<mex:GetMetadata>リクエストへのレスポンスなどに含まれる事になる。
WS-SecurityPolicy (sp)01~06
WS-Policy フレームワークに組み込まれる形で、ポリシーのセキュリティ関連部分を表現する。
WS-Trust (t/wst)05, 06
このサンプルでは SAML セキュリティトークンのやり取りに使っている。
<wst:RequestSecurityToken>で SAML セキュリティトークンをリクエストすると、 SAML Assertion が乗っかったレスポンスが返ってくる。
WS-SecureConversation (wsc)04
複数のメッセージのやり取りが、トークンが付与されたコンテキストの中で行われるようにして、セキュアな「会話」を実現する仕組み。sample 04 では、3対の echo リクエスト/レスポンスとキャンセル要求を交換している。
SAML1.0 protocol (samlp)05, 06
SAML1.0 assertion (saml)05, 06
SAML の セキュリティトークン。サンプルでは STSサービスから<Assetion> を取得して、これを以降のリクエストに含める形で使用している。
WS-MetadataExchange (mex)06
<mex:GetMetadata> を使って、mex サービスからサービスのポリシー(WS-Policy)を取得する。このポリシーに従って、STS サービスからセキュリティトークン(SAML Assertion)を取得する。
Exclusive XML Canonicalization (ec) 05, 06
<ec:InclusiveNamespaces>を使って名前空間指定の一貫性を守って、XML-Signatures の署名対象が改ざんされたとみなされてしまう事を防止する。

0 件のコメント:

コメントを投稿