PDSを実現するにあたっての技術動向の紹介 (OAuth, OpenID Connect, UMAなど)

5,126 views
4,994 views

Published on

Prepared for JEITA コンテンツサービス技術分科会

0 Comments
19 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,126
On SlideShare
0
From Embeds
0
Number of Embeds
47
Actions
Shares
0
Downloads
144
Comments
0
Likes
19
Embeds 0
No embeds

No notes for slide

PDSを実現するにあたっての技術動向の紹介 (OAuth, OpenID Connect, UMAなど)

  1. 1. PDSを実現するにあたっての技術動向の紹介(OAuth, OpenID Connect, UMAなど) 2012年9月11日 工藤達雄 株式会社野村総合研究所 IT基盤インテグレーション事業本部 DIソリューション事業部
  2. 2. OpenIDとOAuthID 情報(認証結果と属性情 あるサービスの API アクセ 報)を安全にサービス間でや スの許可を、別のサービス りとりするための API 仕様 に安全に与えるための方法 OpenID OAuth (オープンアイディー) (オーオース) Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 1
  3. 3. OpenID 2
  4. 4. 「OpenID 2.0」ふたつのWebサイト間における、Webブラウザを用いたアイデン ティティ情報(エンドユーザの認証結果と属性情報)の要求・提供 を行うためのプロトコル2007年12月に策定仕様群 OpenID Authentication 2.0: 認証結果の要求・取得 拡張仕様 ▪ Attribute Exchange (AX) Extension 1.0: 属性情報の要求・取得 ▪ Provider Authentication Policy Extension (PAPE) 1.0: 認証ポリシーの公告・要 求・表明 ▪ OpenID OAuth Extension (Draft): OpenID Authenticationの認証結果と同時に OAuth 1.0 トークンを要求・取得 ▪ OpenID User Interface Extension 1.0 (Draft): ユーザー認証・同意ページのユー ザー・インタフェースの指定 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 3
  5. 5. OpenID の概念と登場人物 ユーザがアイデンティティ (ID) 情報の提供サイトを選択(ただし実際にはホワ イトリストによる運用が一般的) OpenID プロバイダ (OP): ID 情報 (認証結果や属性情報) を RP に提供するサイト OpenID リライング・パーティ (RP): OP から提供された ID 情報を受け入れるサイト RP:ID情報の受入側OP:ID情報の提供側 RP (無料日記OP(ポータル サービス) サイト) 「誰でも気軽にコメ誰でも即時アカ ID / パスワード ID情報の提供 ントしてほしい」ウント取得可能 でログイン OP(航空券 RP(ホテル予約予約サービス) ID / 画像認証 ID情報の提供 サービス)クレジットカード でログイン 「確かな属性情報が ほしい」番号等を管理 ID情報の提供OP(高度認証 ICカードの証 明書でログイン クレデンシャル情報(ID/PW等)の入力 RP (医療情報 サービス) 登録時に厳密な によるユーザの特定はOP側で行うため、 管理サービス)本人確認を行ない、 RP側にクレデンシャル情報を流通させ 「本人以外には決し多要素認証を実施 る必要がない て公開しない」 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 4
  6. 6. OP と RP 間のやりとりの仕組み ユーザ RP OP GETエージェント(ブラウザ) エンドユーザーの https://www.google.com/accounts/o8/ 要求リクエストのプ ID/パスワード ud ロトコルバージョン &openid.ns=http://specs.openid.net/a OpenID入力 ①ディスカバリ を付与 uth/2.0 OpenID(URL) ↑プロトコルバージョン にアクセス &openid.assoc_handle=AMlY****A9 OP の通信先 ↑②で交換した共有秘密鍵への参照キー 秘密鍵への参照 (EndPoint URL)等を返却 &openid.mode=checkid_setup キーによる、メッセー ↑モード(認証要求) ジの改ざん対策 ②アソシエーション &・・・・ 共有秘密鍵の交換 GET https://iknow.jp/open_ids &openid.ns=http://specs.openid.net/a OP で認証された ③認証要求 uth/2.0 OpenID の返却 リダイレクトによる OP への認証要求 &openid.assoc_handle=AMlY****A9 &openid.mode=id_res (ユーザと OP 間の認証処理と ID 情報提供への同意) ↑モード(認証応答) &openid.claimed_id=https://www.goo gle.com/accounts/o8/id?id=AItO****aw ④認証応答 リダイレクトによる ID 情報返却 m 改ざん検知用のメッ ↑OP が認証した識別子(OpenID) セージ署名 サービス提供 &openid.sig=5aDmb****ExYmdwqaU ↑パラメータの共有秘密鍵による署名 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 5
  7. 7. OpenID 2.0の普及動向多数のユーザを抱えるWebサイトが、他社WebサイトにID情 報を提供するための API(Application Programming Interface)としてOpenIDを採用 インターネットサービス事業者(例: Yahoo!、Google、ミクシィ) 携帯通信事業者(例: NTTドコモ、KDDI、ソフトバンク) ネット決済事業者(例: 楽天(楽天あんしん支払いサービス)、 PayPal)米国において、民間のIdP (Identity Provider:たとえばポー タル事業者や決済事業者など、市民に対してID を発行・運用 する組織)と、連邦政府機関の市民向けWeb サイトとのID連 携プロトコルの一つとして採用 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 6
  8. 8. OAuth 7
  9. 9. これまでの API アクセス制御API アクセス制御とは? エンド API API  認証: サービス(API)にアクセスしてきたユーザを特定する ユーザー クライアント プロバイダ  認可: そのユーザが要求する機能やデータを提供しても エンドユーザーの よいかどうかコントロールする ID/パスワード従来の API アクセス管理のパターン サービスにアクセス  IP アドレスによる認証・認可 ID/パスワードが ▪ API クライアントの IP アドレスを事前に登録し、API アクセスを管理 「APIプロバイダーの 外部のサービスに 流出してしまう  「API キー」による認証・認可 ID/パスワードを入力 してください」 ▪ API クライアントに「API キー」(API リクエストに付加する符号)を配 APIプロバイダのID/ 布し、API アクセスを管理 パスワードを入力問題点  いずれの方式も、クライアント単位でのアクセス管理であり、 APIプロバイダのID/ ユーザー単位ではない エンドユーザーの パスワードを リクエストに付加し、 ID/パスワードを APIを呼び出し  ユーザーの ID/パスワードをクライアントが預かる場合には、 用いて何でも さらに別の課題が生ずる リクエストできて ID/パスワードを検証し、 ▪ クライアントが増える度に ID/パスワードの保管場所が増すことにな しまう リクエストを受け付け、 処理結果を返却 り、セキュリティ・リスクが上昇 ▪ API クライアントがエンドユーザーのすべてのアクセス権限を持つこと サービスを提供 になり、アクセス権乱用・誤用のリスクが上昇  →この問題は OpenID では解決できない Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 8
  10. 10. OAuth の登場「トークンによる API アクセス制御」のフ エンド API API レームワーク ユーザー クライアント プロバイダ トークン: ユーザーに成り代わってアクセスす エンドユーザーの ID/パスワード ることを示す符号 サービスにアクセス アクセス範囲を限広く使われているのは「API プロバイダー APIプロバイダーに「特定の 定したトークンを要 がエンドユーザを直接認証するフロー」 サービスにアクセスするための トークン」を要求 求することができる APIクライアントが介在しないため、そこからの 「ID/パスワードの流出」がなくなる ID/パスワードが ▪ API クライアントが管理するのはID/パスワードで APIクライアントに 「APIプロバイダーの 漏えいしない はなくトークン ID/パスワードを入力 してください」 API 提供側はユーザー単位でのアクセス管理 APIプロバイダのID/ が可能 パスワードを入力 ▪ トークンはエンドユーザとひもづいている トークンを APIクライアントに返却まもなくOAuth 2.0がRFC標準となる見 込み トークンを リクエストに付加し、 APIを呼出/応答 現行のOAuth 1.0はobsoleteに サービスを提供 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 9
  11. 11. OAuth におけるサービス間のやりとりの仕組み GET エンド API API https://www.facebook.com/dialog/o プロプライエタリにユーザー クライアント プロバイダ auth 交換されたクライア エンドユーザーの ID/パスワード &client_id=*23***43 ント識別用 ID サービスにアクセス ↑予め払い出されたAPIクライアントID &response_type=token signed_request 認可要求 ↑認可応答形式 API に要求する参 APIプロバイダーに「特定のサービスに アクセスするためのトークン」を要求 &scope=publish_stream 照権限範囲(スコー manage_pages user_birthday ↑APIに対する参照権限範囲 プ)の指定 認証・同意 &・・・ 認可応答 GET https://s- 認可の結果提供さ static.ak.fbcdn.net/connect/xd_prox トークンをAPIクライアントに返却 れたトークン y.php &signed_request=d6wfBx*****ei9 &access_token=AAA****UGOQc トークンによる ↑アクセストークン API呼出/応答 &expires_in=4629 ↑アクセストークンの有効期限 サービスを提供 &・・・ Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 10
  12. 12. OpenIDとOAuthの組み合わせOpenID は意外と実装が難しい 鍵交換や署名の付与・検証を自力で実装することは比較的難易度が高い これらの処理を行うライブラリは多数あるが、環境によっては組み込みが 難しいOAuth は単純には認証に使えない トークンはAPIアクセスのためであり、認証結果としては利用できない API の権限設定が粗いと、トークンが必要以上の権限を持つ 悪意のあるユーザ、サイトによって、権限の乱用や他人に成り済ましたトー クン利用が可能となるOpenID と OAuth を組み合わせる仕様 (OpenID/OAuth Hybrid) も考案されているが… 仕様がドラフトのままアップデートされていない ▪ OAuth は1.0プロトコルベース 両プロトコルをそれぞれ実装する手間がかかる Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 11
  13. 13. OpenID Connect 12
  14. 14. OpenID Connectとはhttp://openid.net/connectOpenIDの次期バージョンOAuth 2.0 仕様をベースに拡張 「シンプルな認証結果と属性情報の取得」 (後述) の範囲であれば、 一般的なOAuth 2.0認可 + API アクセスのフローとほぼ同様メッセージ形式にJSONを採用加えてJWT (JSON Web Token) を活用することにより、署 名と暗号化をサポート仕様のモジュラー化 かんたんなことをシンプルにする一方、複雑なことも実現可能に Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 13
  15. 15. OpenID Connectの系図 Source: http://civics.com/openid-connect-webinar/ Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 14
  16. 16. OpenID 2.0OpenIDプロバイダ(OP) OpenIDリライング・パーティ(RP)RPのリクエストに基づきユーザー認証を行い OPに認証結果や属性情報をリクエストしその認証結果と属性情報を提供 その情報をもとにユーザーにサービスを提供 2. OPの場所を特定し、リクエスト/ レスポンスに用いる署名鍵を交換 5. 認証レスポンス 3. 認証リクエスト (ブラウザを (ブラウザを リダイレクト) リダイレクト) 4. ユーザー認証の実施と 認証結果と属性情報の 1. 「OPの 6. アクセスを 提供可否の確認 IDで 許可し ログイン」 サービスを 提供 PCのWebブラウザ ユーザー RPへのアクセスを試みる過程においてOPから RPへの認証結果と属性情報の提供を許可 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 15
  17. 17. OpenID 2.0の課題 (≒ OpenID Connectの注力分野) 「OP/RP間の設定をもっとかんたんに、OpenIDプロバイダ(OP) もしくは省略したい」 OpenIDリライング・パーティ(RP)RPのリクエストに基づきユーザー認証を行い OPに認証結果や属性情報をリクエストしその認証結果と属性情報を提供 その情報をもとにユーザーにサービスを提供 2. OPの場所を特定し、リクエスト/ レスポンスに用いる署名鍵を交換 Web API (ID情報、lセッション管理、 「認証リクエスト/ ソーシャル、決済、 レスポンスに対して、 アクティビティ、…) 公開鍵を用いて 暗号化・署名したい」 5. 認証レスポンス 3. 認証リクエスト「OPの提供する (ブラウザを (ブラウザを 他のAPIと リダイレクト) リダイレクト) かんたんに組み合わせたい」 4. ユーザー認証の実施と 1. 「OPの 6. アクセスを 認証結果と属性情報の 提供可否の確認 IDで 許可し ログイン」 サービスを 提供 PCのWebブラウザ 「携帯電話のWebブラウザや、 Webブラウザ以外の ユーザー・エージェント (ネイティブ・アプリケーションや JavaScriptクライアントなど) ユーザー にも対応したい」 RPへのアクセスを試みる過程においてOPから RPへの認証結果と属性情報の提供を許可 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 16
  18. 18. OpenID Connectの特徴 エンド API API ユーザー クライアント プロバイダー エンドユーザーの OAuth2.0 ベースによる、トークンを利用 ID/パスワード した全体的なフロー サービスにアクセス ・OAuth2.0 に対応済みであれば、一部 認可要求 の拡張で OpenID Connect に対応可能 APIプロバイダーに「特定のサービスに アクセスするためのトークン」を要求 認証・同意 OAuth の認証では不十分だった、認 証コンテキスト(いつ、誰が、誰を認証 認可応答 したのか等)を「ID トークン」として提供 認可コードをAPIクライアントに返却 アクセストークン要求・応答 (認可コードとアクセストークンを 引換え/IDトークンの返却) 属性提供を行う UserInfoAPI が規定さ れ、API アクセスの標準ルールが策定 UserInfo要求・応答 アクセストークンによる API呼出/応答 サービスを提供 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 17
  19. 19. OpenID Connectのフロー(概要) 7.(オプション): ユーザー属性 7 8. (オプショクレーム クレーム ソース 提供要求 ン): ユーザープロバイダ 8 属性提供 5. ユーザー属性 提供要求 5 6 . ユーザー 属性提供OpenID ユーザー UserInfo 6 クライアントプロバイダ 情報 エンドポイント 2. トークン 2 (クレーム) 取得要求 (ブラウザの 4 リダイレクト) 4. アクセス・ トークンとID エンドユーザー トークンを返却 認可 (ブラウザの エンドポイント リダイレクト) 認可 サーバー 1. サービスに 9 . サービス アクセス 提供 1 9 3 3. ユーザー 認証・認可 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 18
  20. 20. OpenID Connect Protocol Suite「公式マップ」 …が、以下のほうが実態に近 http://openid.net/connect い気がする Bindings •Basic Client Profile •Implicit Client Profile •Standard •Other Vendor Proprietary / Community Specific Bindings Endpoints and Optional Functionality •Discovery associated message •Dynamic Client Registration formats •Session Management •Other Vendor Proprietary / •Messages Community Specific Functionality Underpinnings Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 19
  21. 21. OpenID Connect のユースケース1. シンプルな認証結果と属性情報の取得OpenID Connectフローの処理の結果、クライアントは認可サーバーから id_tokenとアクセス・トークンを得る認証結果: id_tokenから抽出 id_token ▪ JWT(JSON Web Token)形式 ▪ JWS (JSON Web Signature)により署名 ▪ 発行者(iss)、エンドユーザーの識別子(user_id)、トークンのオーディエンス(aud)、有効期間 (exp)、発行時間(iat)などが含まれている 検証方法 ▪ 取得したクライアント自身がid_tokenを検証属性情報: アクセス・トークンを用いて取得 クライアントはフロー開始時(認可リクエスト)のscopeに、取得したい「クレーム」を指定 ▪ 指定可能なクレームはprofile (一般的なユーザー属性(address, emailを除く)), address (住所), email (メールアドレス) 、phoneの4種類(複数同時に指定可能) 取得したアクセス・トークンを用いてUserInfoエンドポイントにアクセスし、属性を取得 ▪ JSON形式 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 20
  22. 22. OpenID Connect のユースケース2. 仕様に規定されている以外の属性の取得認可リクエストのscopeに独自 例: もし「edupersonクレーム」 の「クレーム」を指定 を作る場合さらに認可リクエストに「リクエ scopeにedupersonを指定 スト・オブジェクト」を付加し、要 リクエスト・オブジェクトとして以下 求する属性を指定 の内容を指定 {リクエスト・オブジェクト "user_id": null, "urn:mace:dir:attribute-def:cn" : {"optional": true}, "urn:mace:dir:attribute-def:sn" : {"optional": true}, 認可サーバーへのリクエスト・パ "urn:mace:dir:attribute-def:givenName" : {"optional": true}, "urn:mace:dir:attribute-def:mail" : null ラメータをJWT化したもの } 認可リクエストへの付加方法 UserInfoにアクセスすることによ ▪ requestパラメータの値としてリクエ り、以下の属性を取得 スト・オブジェクトを指定 { "user_id": "248289761001", ▪ request_uriパラメータの値として、 "urn:mace:dir:attribute-def:cn" : "John Bradley", "urn:mace:dir:attribute-def:sn" : "Bradley", リクエスト・オブジェクトの場所を指 "urn:mace:dir:attribute-def:givenName" : "John", 定 "urn:mace:dir:attribute-def:mail" "ve7jtb@ve7jtb.com" } Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 21
  23. 23. OpenID Connect のユースケース3. ユーザー認証の保証レベルの指定認可リクエストに付加する 例 「リクエスト・オブジェクト」に、 リクエスト・オブジェクトとして 要求する保証レベルを指定 以下の内容を指定 "id_token": ユーザー認証後得られた { "claims": { id_tokenに、保証レベルが "auth_time": null, “acr": { "values":["2"] } }, 含まれる } "max_age": 86400, ユーザー認証後取得した id_tokenに以下の内容が含ま れる “acr": {"values":["3","2"]} Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 22
  24. 24. OpenID Connect のユースケース4. UserInfoエンドポイントの外部にあるクレームの取得UserInfoから提供する外部のクレームとして、「集約 (aggregated)クレーム」と「分散(distributed)クレーム」を規 定集約(aggregated)クレーム UserInfoエンドポイントから提供されるクレームの中に、外部クレー ムの「実体」が含まれる ▪ その「実体」はJWT形式に変換して含まれることにより、他のクレームと区別さ れる分散(distributed)クレーム UserInfoエンドポイントから提供されるクレームの中に、外部クレー ムを取得するための情報が含まれる ▪ 場合によっては、取得するための情報としてアクセス・トークンが指定されてい る Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 23
  25. 25. OpenID Connect のユースケース5. クライアントによるOpenIDプロバイダのディスカバリOpenID Connect Discovery エンドユーザーが指定した識別子をもとに、OpenIDリライング・パー ティがOpenIDプロバイダを発見する仕組みを定義 ▪ OpenID 2.0にて実現されていた機能と同様 識別子は以下のどちらかであるべきである (SHOULD) ▪ メールアドレス or URL 識別子を元にOpenIDリライング・パーティは、SWD (Simple Web Discovery) により、OpenIDプロバイダを発見する GET /.well-known/simple-web-discovery?principal=joe%40example.com&service=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1 Host: example.com HTTP/1.1 200 OK Content-Type: application/json { "locations":["https://server.example.com"] } Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 24
  26. 26. OpenID Connect のユースケース6. クライアント情報の動的な登録OpenID Connect Dynamic Client Registration OpenIDプロバイダとOpenIDリライング・パーティとが、動的に信頼 関係を確立する仕組みを定義 ▪ OpenID 2.0にて実現されていた機能と同様 OpenIDリライング・パーティがOpenIDプロバイダの「クライアント登 録エンドポイント」に、自身を登録するようリクエスト ▪ 成功した場合、レスポンスとしてclient_id/client_secretが返却される POST /connect/register HTTP/1.1 HTTP/1.1 200 OK Accept: application/x-www-form-urlencoded Content-Type: application/json Host: server.example.com Cache-Control: no-store Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ... fQ.8Gj_-sj ... _X { type=client_associate "client_id":"s6BhdRkqt3", &redirect_uris=https://client.example.org/callback %20https://client.examp "client_secret": le.org/callback2 &logo_url=https://client.example.org/logo.png "cf136dc3c1fd9153029bb9c6cc9ecead918bad9887fce6c93f31185e58858 &user_id_type=pairwise &sector_identifier_url= 05d", https://othercompany.com/file_of_redirect_uris_for_our_sites.js "expires_at":2893276800 &token_endpoint_auth_type=client_secret_basic } &jwk_url=https://client.example.org/my_rsa_public_key.jwk &userinfo_encrypted_response_alg=RSA1_5 &userinfo_encrypted_response_enc=A128CBC &userinfo_encrypted_response_int=HS256 All Rights Reserved. Copyright © 2012 Nomura Research Institute, Ltd. 25
  27. 27. OpenID Connect のユースケース7. セッション管理OpenID Connect Session Management OpenIDプロバイダ(認可サーバー)におけるユーザーのログイン/ロ グアウトの状況を、OpenIDリライング・パーティ(サードパーティ)が 継続的にモニターする仕組みを定義 OP/RPの通信にiframeを利用 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 26
  28. 28. OpenID Connectの今後のロードマップ現在Implementer’s Draftが公開中今後最終仕様にOpenID Connectをサポートする製品・サービスベンダー (予定含む) Gluu、IBM、Layer7、Microsoft、野村総合研究所、Ping Identity、 Vordel、… AOL、Google、日本経済新聞社、PayPal、楽天、Salesforce.com、 Yahoo! JAPAN、… Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 27
  29. 29. UMA (User Managed Access) 28
  30. 30. User Managed Access (UMA)http://kantarainitiative.org/confluence/display/uma/Homeデータ共有とサービス・アクセスに関する認可をユーザがコ ントロールできるようにするためのWebプロトコルカンターラ・イニシアチブのワーク・グループとして活動現在、仕様のドラフトを策定中IETFにて標準化を予定OAuth 2.0 ベース Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 29
  31. 31. リソースごとに行われている認可管理 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 30
  32. 32. UMA: Authorization Managerに認可管理を集約 Host / Requester / Authorization Manager Protected Resource Requesting Party リソースへの アクセスを許可 ユーザが利用してい るホスト/リソースを、 同じく利用している 管理サービスに登録 Authorizing Party 利用者の同意に基づく リソースの活用 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 31
  33. 33. OAuth 2.0とUMAの比較UMAプロトコルはOAuth 2.0をベースに以下を拡張  だれにデータを共有するか(クライアント上の自分 vs. 任意の誰か)  リソースと認可サービスとの関係(サービスが規定 vs. ユーザが指定)  発行するトークンをどのように決定するか(ユーザ認証結果に基づく vs. ユーザのポリシーとリク エスタのクレームに基づく)  データの提供者と利用者との関係(事前登録 vs. 動的登録)OAuth 2.0 UMA Source: http://kantarainitiative.org/confluence/download/attachments/37751312/IIW10-UMA-May2010.pdf Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved.
  34. 34. Authorization ManagerにおいてポリシーUMAの登場人物 を設定する。ポリシーによって、Host上の Protected ResourceにRequesterがアクセ スを試みたときにどうするかが決定されるHostは自身の管理するProtected Resourceへのアクセスを、AuthoriziationManagerの決定に従い管理する (policy enforcement) Authorizing Userのポリシーを適用 し、Protected Resourceへのアクセ スを統制する (policy decision) リクエストを行う主体はAuthorizing User本人、またはユーザ個人や企 業・団体。これらRequesting Partyが、 Requesterを用いて、Protected Resourceへのアクセスを試みる Source: http://kantarainitiative.org/pipermail/wg-uma/2012-August/001956.html Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 33
  35. 35. UMAのユースケース例Person-to-self sharing Authorizing PartyとRequesting Partyが同一の人物であるケースPerson-to-person sharing Authorizing Partyが別の人物であるRequesting Partyにアクセス認可を 与えるケースMediated person-to-organization sharing Authorizing Partyが別の組織に属する人物であるRequesting Partyにア クセス認可を与えるケースAutonomous person-to-organization sharing Authorizing Partyが公開した「パーソナルRFP(提案依頼)」に対し、別の 組織がRequesting Partyとなって提案するようなケース ▪ Requesting Party側では、人が介在しない Source: Binding Obligations on User-Managed Access (UMA) Participants 1.1. Sample Use Cases for Sharing Access to Resources http://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor1 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 34
  36. 36. UMAのステップ 2c: アクセス・トークンを要求。場合によりクレームを提示 1b: メタデータ取得 2b: アクセス試行 3b: トークンの検証 (オプション) Step 3: Requesterが Resourceにアクセス 1d: ポリシー 1a: UserがAMの 2a: Userが を定義 場所を指示 Resourceの ありかを提示 1c: HostがAMを信頼することを認可 Step 1: UserがAMにHostを紹介 Step 2: Requesterがアクセス・トークンを取得Authorizing User (ブラウザもしくは他のユーザ・エージェントを利用するユーザ) Source: http://kantarainitiative.org/confluence/download/attachments/37751312/IIW10-UMA-May2010.pdf Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 35
  37. 37. UMAを採用している/採用を検討しているサービス Source: UMA Implementations - WG - User Managed Access - Kantara Initiative http://kantarainitiative.org/confluence/display/uma/UMA+Implementations Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 36

×