Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

UserManagedAccess_idcon13

1,484 views

Published on

Published in: Technology
  • Be the first to comment

UserManagedAccess_idcon13

  1. 1. User Managed Access @ritou 2012/06/22 #idcon Vol.13
  2. 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. 3. Agenda• OAuth & UMA
  4. 4. Roles• Resource owner• Resource server• Client• Authorization server
  5. 5. Roles• Resource owner : イトウ氏• Resource server : mixi• Client : openidconnect.info• Authorization server : mixi
  6. 6. Roles• Resource owner : イトウ氏• Resource server : mixi• Client : openidconnect.info• Authorization server : mixiこれらは一意に紐づいている
  7. 7. 分散する認可管理• User• Resource Server /AuthZ Server• Client Web Mobile ... App App
  8. 8. Client & Resource Owner• ClientはResource Ownerの代わりにリ ソースアクセスを行う
  9. 9. Client & Resource Owner• ClientはResource Ownerの代わりにリ ソースアクセスを行う自分が所有するデータにアクセスさせるためのしくみ
  10. 10. Client & Resource Owner• ClientはResource Ownerの代わりにリ ソースアクセスを行う自分が所有するデータにアクセスさせるためのしくみ第3者に共有するしくみではない(Clientが共有する機能を持つかも)
  11. 11. OAuth• Resource ServerとAuthorization Serverの 組み合わせが一意に決められる – 認可の管理が各AutnZ Serverに分散• Clientがアクセスできるのは自らのリソー スのみ
  12. 12. UMA• Resource ServerとAuthorization Serverを 分離 – 好みのAuthorization Serverを利用可能• 第3者へのリソース共有も可能 – person-to-self – person-to-person – person-to-organization• ポリシーはユーザーが決定
  13. 13. Agenda• OAuth & UMA• UMA Flow
  14. 14. Roles• Resource owner → Authorizing User• Resource server → Host• Client → Requester• Authorization server → Authorization Manager(AM)• Requesting Party – リソースアクセスするユーザーや組織
  15. 15. ここに 画像を保存してる 画像を 共有 したい!
  16. 16. Flow1. Protecting a Resource2. Getting Authorization3. Accessing a Resource
  17. 17. 1. Protecting a Resource• Hostが持つリソースの認可管理を行う AMを設定
  18. 18. Resource Owner AuthZ ServerClientこの3者間でOAuthの処理が行われる
  19. 19. Authorization Userはリソースを管理してもらうAMを選択/指定
  20. 20. HostがAMと連携していない場合はDiscovery + Dynamic Registration
  21. 21. AM上でAuthorization UserはHostのリソースをAMで保護することに同意する(AM:このHostのリソースを管理しますよ?)
  22. 22. HostはAMからリソース保護用のアクセストークンを取得(Protection API Token)
  23. 23. Hostはリソースを登録(Resource Set Registration API)
  24. 24. HostはAMからポリシー設定用URLを取得
  25. 25. AMにリダイレクトされたAuthorizingUserはポリシーを設定する
  26. 26. 1. Protecting a Resource1. HostはAMからリソース登録のためのトーク ンを取得する(Protection API Token)2. HostはリソースセットをAMに登録3. Authorizing Userはポリシーを設定
  27. 27. 2. Getting AuthorizationRequesterはHost上のリソースにアクセスするための認可を得る
  28. 28. Resource Server AuthZ Server Client
  29. 29. Authorizing UserはRequesting PartyにリソースのURLを通知
  30. 30. Requesterはリソースにアクセス
  31. 31. HostはRequesterがアクセスに必要なpermissionを得るためのTicketを要求 resource_set_id, scope
  32. 32. AMはTicketを返す ticket
  33. 33. HostはRequesterにAMのURIを返し、必要なpermissionを得るように促す AM_URIpermission_ticket
  34. 34. ここで一旦、AM, Requester, Requesting PartyによるOAuthの処理が入る AuthZ Server Client
  35. 35. RequesterはRequesting Partyに対し許可を求める• AMと連携してClaimsを渡す• Permissionの有無を問い合わせる
  36. 36. AMはRequesting Partyが同意したことを示すトークンを渡す(authorization API Token) AAT
  37. 37. Resource Server AuthZ Server Client
  38. 38. RequesterはAATを用いて, Hostが持つResourceにアクセスするために必要なTokenを要求 AAT
  39. 39. AMはPermissionのついていないRPTを返す RPT
  40. 40. RequesterはAMに”RPTへのPermission追加”を要求 RPT, ticket
  41. 41. AMはPermissionがセットされたRPTを返す RPT
  42. 42. 2. Getting Authorization• Requester-AM-Requesting Party間の Authorization取得• Host-AM-Requester間のPermission付与
  43. 43. 3. Accessing a ResourceRequesterはRPTを用いてHostにアクセスする
  44. 44. RequesterはRPTを用いてHost上にあるリソースにアクセス RPT
  45. 45. HostはAMにRPTを送り, Statusを要求 RPT
  46. 46. AMはRPTのStatusを返す status
  47. 47. RPTが有効だったときにHostはリソースを返すProtectedResource
  48. 48. 3. Accessing a Resource• HostはAMにRPTを送信してStatusを チェックする• RPTが有効ならばリソースを返す
  49. 49. Agenda• OAuth & UMA• UMA Flow• UMA × OpenID Connect
  50. 50. Claims-based Access Control• Requesting Partyの属性情報によるアク セスコントロール – 企業 – クレジットスコア – 年齢 – Email アドレス
  51. 51. OpenID Connect Integration• RP : AM• OP : Requester or others• User : Requesting Party
  52. 52. OpenID Connect Integration1. AliceはAM上でbob@email.comに写真を 共有するというポリシーを設定2. AliceはBobに画像URLを連絡3. Bobがクライアントを用いてURLにアクセス →AMへ4. AMはBobにOpenID ConnectのRPとして Emailを要求5. Emailがマッチしたら画像を共有
  53. 53. OpenID Connect Integration1. AliceはAM上でbob@email.comに写真を 共有するというポリシーを設定2. AliceはBobに画像URLを連絡3. Bobがクライアントを用いてURLにアクセス →AMへ4. AMはBobにOpenID ConnectのRPとして Emailを要求5. Emailがマッチしたら画像を共有信頼できる属性情報流通のしくみが必要
  54. 54. UMA × SITF?• SITF = Student Identity Trust Framework• “信頼できる”学生ですよフラグ+αを流通 させるしくみ• UMA×SITFで資料を○○大学の学生の みに共有が可能
  55. 55. 2012Q2• Interopのサポート• 新しいユースケースの収集• Trust Model Documentの精査 –http://docs.kantarainitiative.org/uma/ draft-uma-trust.html
  56. 56. 蛇足:僕はこう思ったッス• OAuthのResource Server/Authorization Server 分離の部分という点は可能性を感じる – コンテンツが強いところは認可管理のコストを抑 えられる – スタートアップが安全にリソースアクセスを提供 – グループ企業内のAPI連携など• 誰か一緒に実装してみませんか?
  57. 57. 続きはブログか何かで!• Blog : http://d.hatena.ne.jp/ritou – デマはよくない!

×