1. User Managed Access
@ritou
2012/06/22
#idcon Vol.13

2. 参考URL
• kantara INITIATIVE UMA WG
– http://kantarainitiative.org/confluence/display/u
ma/Home
• 情報セキュリティ技術動向調査（2010 年上
期） by @tkudos
– http://www.ipa.go.jp/security/fy22/reports/tech1
-tg/a_05.html

3. Agenda
• OAuth & UMA

4. Roles
• Resource owner
• Resource server
• Client
• Authorization server

5. Roles
• Resource owner : イトウ氏
• Resource server : mixi
• Client : openidconnect.info
• Authorization server : mixi

6. Roles
• Resource owner : イトウ氏
• Resource server : mixi
• Client : openidconnect.info
• Authorization server : mixi
これらは一意に紐づいている

7. 分散する認可管理
• User
• Resource Server
/AuthZ Server
• Client Web Mobile ...
App App

8. Client & Resource Owner
• ClientはResource Ownerの代わりにリ
ソースアクセスを行う

9. Client & Resource Owner
• ClientはResource Ownerの代わりにリ
ソースアクセスを行う
自分が所有するデータにアクセスさせ
るためのしくみ

10. Client & Resource Owner
• ClientはResource Ownerの代わりにリ
ソースアクセスを行う
自分が所有するデータにアクセスさせ
るためのしくみ
第3者に共有するしくみではない
（Clientが共有する機能を持つかも）

11. OAuth
• Resource ServerとAuthorization Serverの
組み合わせが一意に決められる
– 認可の管理が各AutnZ Serverに分散
• Clientがアクセスできるのは自らのリソー
スのみ

12. UMA
• Resource ServerとAuthorization Serverを
分離
– 好みのAuthorization Serverを利用可能
• 第3者へのリソース共有も可能
– person-to-self
– person-to-person
– person-to-organization
• ポリシーはユーザーが決定

13. Agenda
• OAuth & UMA
• UMA Flow

14. Roles
• Resource owner → Authorizing User
• Resource server → Host
• Client → Requester
• Authorization server
→ Authorization Manager（AM）
• Requesting Party
– リソースアクセスするユーザーや組織

16. ここに
画像を
保存してる
画像を
共有
したい！

17. Flow
1. Protecting a Resource
2. Getting Authorization
3. Accessing a Resource

18. 1. Protecting a Resource
• Hostが持つリソースの認可管理を行う
AMを設定

19. Resource
Owner
AuthZ Server
Client
この3者間でOAuthの処理が行われる

20. Authorization Userはリソースを管理し
てもらうAMを選択/指定

21. HostがAMと連携していない場合は
Discovery + Dynamic Registration

22. AM上でAuthorization UserはHostのリ
ソースをAMで保護することに同意する
(AM：このHostのリソースを管理します
よ？)

23. HostはAMからリソース保護用のアクセ
ストークンを取得
（Protection API Token）

24. Hostはリソースを登録
（Resource Set Registration API）

25. HostはAMからポリシー設定用URLを取
得

26. AMにリダイレクトされたAuthorizing
Userはポリシーを設定する

27. 1. Protecting a Resource
1. HostはAMからリソース登録のためのトーク
ンを取得する(Protection API Token)
2. HostはリソースセットをAMに登録
3. Authorizing Userはポリシーを設定

28. 2. Getting Authorization
RequesterはHost上のリソースにアクセス
するための認可を得る

29. Resource
Server AuthZ Server
Client

30. Authorizing Userは
Requesting Partyに
リソースのURLを通知

31. Requesterはリソース
にアクセス

32. HostはRequesterがアクセスに必要な
permissionを得るためのTicketを要求
resource_set_id,
scope

33. AMはTicketを返す
ticket

34. HostはRequesterにAMのURIを返し、必要な
permissionを得るように促す
AM_URI
permission_ticket

35. ここで一旦、AM, Requester, Requesting Partyに
よるOAuthの処理が入る
AuthZ Server
Client

36. RequesterはRequesting Partyに対し許可を求める
• AMと連携してClaimsを渡す
• Permissionの有無を問い合わせる

37. AMはRequesting Partyが同意したことを示すトーク
ンを渡す(authorization API Token)
AAT

38. Resource
Server AuthZ Server
Client

39. RequesterはAATを用いて, Hostが持つResourceにア
クセスするために必要なTokenを要求
AAT

40. AMはPermissionのついていないRPTを返す
RPT

41. RequesterはAMに”RPTへのPermission追加”を要求
RPT,
ticket

42. AMはPermissionがセットされたRPTを返す
RPT

43. 2. Getting Authorization
• Requester-AM-Requesting Party間の
Authorization取得
• Host-AM-Requester間のPermission付与

44. 3. Accessing a Resource
RequesterはRPTを用いてHostにアクセス
する

45. RequesterはRPTを用いてHost上にあるリ
ソースにアクセス
RPT

46. HostはAMにRPTを送り, Statusを要求
RPT

47. AMはRPTのStatusを返す
status

48. RPTが有効だったときにHostはリソース
を返す
Protected
Resource

49. 3. Accessing a Resource
• HostはAMにRPTを送信してStatusを
チェックする
• RPTが有効ならばリソースを返す

50. Agenda
• OAuth & UMA
• UMA Flow
• UMA × OpenID Connect

51. Claims-based Access Control
• Requesting Partyの属性情報によるアク
セスコントロール
– 企業
– クレジットスコア
– 年齢
– Email アドレス

52. OpenID Connect Integration
• RP : AM
• OP : Requester or others
• User : Requesting Party

53. OpenID Connect Integration
1. AliceはAM上でbob@email.comに写真を
共有するというポリシーを設定
2. AliceはBobに画像URLを連絡
3. Bobがクライアントを用いてURLにアクセス
→AMへ
4. AMはBobにOpenID ConnectのRPとして
Emailを要求
5. Emailがマッチしたら画像を共有

54. OpenID Connect Integration
1. AliceはAM上でbob@email.comに写真を
共有するというポリシーを設定
2. AliceはBobに画像URLを連絡
3. Bobがクライアントを用いてURLにアクセス
→AMへ
4. AMはBobにOpenID ConnectのRPとして
Emailを要求
5. Emailがマッチしたら画像を共有
信頼できる属性情報流通のしくみが必要

55. UMA × SITF?
• SITF = Student Identity Trust Framework
• “信頼できる”学生ですよフラグ+αを流通
させるしくみ
• UMA×SITFで資料を○○大学の学生の
みに共有が可能

56. 2012Q2
• Interopのサポート
• 新しいユースケースの収集
• Trust Model Documentの精査
–http://docs.kantarainitiative.org/uma/
draft-uma-trust.html

57. 蛇足：僕はこう思ったッス
• OAuthのResource Server/Authorization Server
分離の部分という点は可能性を感じる
– コンテンツが強いところは認可管理のコストを抑
えられる
– スタートアップが安全にリソースアクセスを提供
– グループ企業内のAPI連携など
• 誰か一緒に実装してみませんか？

58. 続きはブログか何かで！
• Blog : http://d.hatena.ne.jp/ritou
– デマはよくない！