20051026_WS-Trust

XMLコンソーシアムセキュリティ部会勉強会資料
2005年10月26日
Web Services Trust Language
(WS-Trust) 概要
2005年10月26日
富士通株式会社
西村利浩
1
Copyright © 2005 FUJITSU LIMITED All rights reserved.
XMLコンソーシアムセキュリティ部会勉強会資料
2005年10月26日
WS-Trustとは



10月17日 OASIS Web Services Secure Exchange
(WS-SX) TC設立とメンバー募集の案内
→このTCで標準化されるベースとなる仕様の1つ
一言で言うと
「セキュリティ・トークン・サービスからセキュリティ・トークンを
取得するためのプロトコル」
仕様書の言葉を借りると
「 WS-Trustの目標は、アプリケーションが信頼された
[SOAP]メッセージ交換を構築することを可能にすることであ
る。この信頼は、セキュリティ・トークンの交換と仲介を通して
表される。この仕様では、これらのセキュリティ・トークンの発
行、更新、検証のためのプロトコル不可知の方法を提供す
る。」(1.1 Goals and Non-Goalsの文を翻訳)
注)本資料はWS-Trustの2005年2月版をベースにしている。
http://specs.xmlsoap.org/ws/2005/02/trust/WS-Trust.pdf
Copyright © 2005 FUJITSU LIMITED All rights reserved.
2
XMLコンソーシアムセキュリティ部会勉強会資料
2005年10月26日
背景（Webサービスの信頼モデル）


Webサービスは、メッセージを受け取る際に、クレーム(名前、
鍵、許可など)の証明を要求できる
クレームはセキュリティ・トークンで表される
Copyright © 2005 FUJITSU LIMITED All rights reserved.
3
XMLコンソーシアムセキュリティ部会勉強会資料
2005年10月26日
プロトコル

一度の要求/応答だけでなく、複数のメッセージ交換
も視野
RequestSecurityToken (RST)
Security Token
Service
Requestor
RequestSecurityTokenResponse (RSTR)
RST
Requestor
RSTR
RSTR
RSTR
Copyright © 2005 FUJITSU LIMITED All rights reserved.
Security Token
Service
4
XMLコンソーシアムセキュリティ部会勉強会資料
2005年10月26日
基本形
(5. Security Token Service Framework)

要求メッセージ
<wst:RequestSecurityToken Context="...">
<wst:TokenType>...</wst:TokenType>
<wst:RequestType>...</wst:RequestType>
...
</wst:RequestSecurityToken>

応答メッセージ
<wst:RequestSecurityTokenResponse Context="...">
<wst:TokenType>...</wst:TokenType>
<wst:RequestedSecurityToken>...</wst:RequestedSecurityToken>
...
</wst:RequestSecurityTokenResponse>
Copyright © 2005 FUJITSU LIMITED All rights reserved.
5
XMLコンソーシアムセキュリティ部会勉強会資料
2005年10月26日
基本的なバインディング
発行 (6. Issuance Binding)
 更新 (7. Renewal Binding)
 取り消し (8. Cancel Binding)
 検証 (9. Validation Binding)

Copyright © 2005 FUJITSU LIMITED All rights reserved.
6
XMLコンソーシアムセキュリティ部会勉強会資料
2005年10月26日
トークンの発行(要求)

Issue – 要求において提供/証明されたクレデン
シャルに基づいて、(場合によっては新しい証明情
報とともに) 新しいトークンが発行される
<wst:RequestSecurityToken>
<wst:TokenType>...</wst:TokenType>
<wst:RequestType>...</wst:RequestType>
...
<wsp:AppliesTo>...</wsp:AppliesTo>
<wst:Claims Dialect="...">...</wst:Claims>
<wst:Entropy>
<wst:BinarySecret>...</wst:BinarySecret>
</wst:Entropy>
<wst:Lifetime>
<wsu:Created>...</wsu:Created>
<wsu:Expires>...</wsu:Expires>
</wst:Lifetime>
</wst:RequestSecurityToken>
Copyright © 2005 FUJITSU LIMITED All rights reserved.
Issueを指定
トークンの有効範囲を指定
トークンに含まれるべきク
レームを指定
鍵生成用のエントロピーを指定
トークンの有効期限を指定
7
XMLコンソーシアムセキュリティ部会勉強会資料
2005年10月26日
トークンの発行(応答)
<wst:RequestSecurityTokenResponse>
<wst:TokenType>...</wst:TokenType>
<wst:RequestedSecurityToken>...</wst:RequestedSecurityToken>
...
<wsp:AppliesTo>...</wsp:AppliesTo>
<wst:RequestedAttachedReference>
...
トークンの参照方法を指定
</wst:RequestedAttachedReference>
<wst:RequestedUnattachedReference>
...
</wst:RequestedUnattachedReference>
<wst:RequestedProofToken>...</wst:RequestedProofToken>
<wst:Entropy>
<wst:BinarySecret>...</wst:BinarySecret>
要求されたトークンに関係
</wst:Entropy>
する所有証明トークンを返
<wst:Lifetime>...</wst:Lifetime>
す
</wst:RequestSecurityTokenResponse>
Copyright © 2005 FUJITSU LIMITED All rights reserved.
8
XMLコンソーシアムセキュリティ部会勉強会資料
2005年10月26日
トークンの更新

Renew – 以前発行された有効期限付きのトークンが提示さ
れ (そして、おそらく証明され) 新しい期限で同じトークンが
返される。
<wst:RequestSecurityToken>
<wst:TokenType>...</wst:TokenType>
<wst:RequestType>...</wst:RequestType>
...
<wst:RenewTarget>...</wst:RenewTarget>
<wst:AllowPostdating/>
<wst:Renewing Allow=... OK=.../>
</wst:RequestSecurityToken>
更新可能なトークンかどうかを指定
Renewを指定
更新するトークンを指定
すぐには有効ではないトークン
を許すことを指定
期限後も更新可能かどうかを
指定
応答はIssueの場合と同じ
Copyright © 2005 FUJITSU LIMITED All rights reserved.
9
XMLコンソーシアムセキュリティ部会勉強会資料
2005年10月26日
トークンの取り消し

Cancel – 以前発行されたトークンが必要なくなったとき、
Cancelバインディングを使ってトークンをキャンセルし、その
利用を終了することができる。
<wst:RequestSecurityToken>
<wst:RequestType>...</wst:RequestType>
...
<wst:CancelTarget>...</wst:CancelTarget>
</wst:RequestSecurityToken>
<wst:RequestSecurityTokenResponse>
<wst:RequestedTokenCancelled/>
</wst:RequestSecurityTokenResponse>
Copyright © 2005 FUJITSU LIMITED All rights reserved.
Cancelを指定
失敗した場合はFault
10
XMLコンソーシアムセキュリティ部会勉強会資料
2005年10月26日
トークンの検証

Validate – 指定されたセキュリティトークンの有効性が評価
され、その結果が返される。結果は、状態、新しいトークン、
その両方の場合がある。
<wst:RequestSecurityToken>
<wst:TokenType>...</wst:TokenType>
<wst:RequestType>...</wst:RequestType>
...
</wst:RequestSecurityToken>
Validateを指定
<wst:RequestSecurityTokenResponse>
<wst:TokenType>...</wst:TokenType>
<wst:RequestedSecurityToken>...</wst:RequestedSecurityToken>
...
<wst:Status>
<wst:Code>...</wst:Code>
valid/invalidなどを返す
<wst:Reason>...</wst:Reason>
</wst:Status>
<wst:RequestSecurityTokenResponse>
Copyright © 2005 FUJITSU LIMITED All rights reserved.
11
XMLコンソーシアムセキュリティ部会勉強会資料
2005年10月26日
交渉とチャレンジの拡張
(10. Negotiation and Challenge Extensions)
最初だけRequestSecurityTokenで、その後は
RequestSecurityTokenResponseでメッセージ
をやりとり
 署名によるチャレンジ(10.2 Signature
Challenges)
 既存のバイナリ・フォーマットを利用したメッセージ交
換、交渉(10.3 Binary Exchanges and
Negotiations)
 鍵交換トークン(10.4 Key Exchange Tokens)
 その他拡張(10.5 Custom Exchanges)

Copyright © 2005 FUJITSU LIMITED All rights reserved.
12
XMLコンソーシアムセキュリティ部会勉強会資料
2005年10月26日
鍵やトークンのパラメータに関する拡張
(11. Key and Token Parameter Extensions)





誰か他人の代わりにトークンを要求していることを示して、
トークンを要求(11.1 On-Behalf-Of Parameters)
鍵や暗号化の詳細を指定してトークンを要求(11.2 Key
and Encryption Requirements)
誰かに委任することを指定、もしくは転送/委任可能であるこ
とを指定してトークンを要求(11.3 Delegation and
Forwarding Requirements)
ポリシー(WS-Policy)を指定してトークンを要求(11.4
Policies)
リクエスタ以外に返却されるトークンを利用することが許され
るParticipantsを指定して、トークンを要求(11.5
Authorized Token Participants)
Copyright © 2005 FUJITSU LIMITED All rights reserved.
13
XMLコンソーシアムセキュリティ部会勉強会資料
2005年10月26日
鍵交換トークンのバインディング
(12. Key Exchange Token Binding)


鍵交換トークン(KET)を要求するためのバインディング
要求者は、受信者向けに鍵マテリアルを暗号化するために
利用できるトークンを欲する。
<wst:RequestSecurityToken Context="...">
<wst:TokenType>...</wst:TokenType>
<wst:RequestType>...</wst:RequestType>
...
</wst:RequestSecurityToken>
KETを指定
<wst:RequestSecurityTokenResponse Context="...">
<wst:TokenType>...</wst:TokenType>
<wst:RequestedSecurityToken>...</wst:RequestedSecurityToken>
...
</wst:RequestSecurityTokenResponse>
Copyright © 2005 FUJITSU LIMITED All rights reserved.
14
XMLコンソーシアムセキュリティ部会勉強会資料
2005年10月26日
所有証明 (Proof-of-Possession)トーク
ンを返す例

I.5.2 Brokered Key Distributionにある例


BはS向けに (BとSが知っている秘密鍵、または、Sの公
開鍵で)暗号化したものをTokenとして
R向けに暗号化されたセッション鍵をproof-ofpossession tokenとして返す
B
Broker
Third-party STS
R
requestor
S
Target service

RはSにセッション鍵を使って暗号化してTokenとメッセー
ジを提示
Copyright © 2005 FUJITSU LIMITED All rights reserved.
15
XMLコンソーシアムセキュリティ部会勉強会資料
2005年10月26日
WS-Trust使用例：InfoCard

Windows Vista搭載予定のアイデンティティ管
理ソリューション









InfoCardシステムは利用者ごとにカードを管理
カードには利用者が取得可能なトークンに関するメ
タデータが記述
BobがFabrikam Corpからワインを購入したい
Fabrikam Corpは21歳以上であることを確認す
る必要があり、例えば、SAMLで年齢を証明する
トークンの提示が必要(WS-SecurityPolicyで記
述)
InfoCardはWS-MetadataExchangeを使って
Fabrikam Corpのポリシーを取得
InfoCardはポリシーに合うSTSをカードから探し
接続。
BobがSTSに対して認証、Fabrikamのポリシーを
提示。
STSはポリシーに適合するトークンを返す。
Bob承認の元、InfoCardからFabrikamにトーク
ンが提出される。
Copyright © 2005 FUJITSU LIMITED All rights reserved.
Security
Token
Service
Target
service
InfoCard
利用者
16

Download Report