100121 Scis2010 Itoh

2,433 views

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,433
On SlideShare
0
From Embeds
0
Number of Embeds
32
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

100121 Scis2010 Itoh

  1. 1. 認証連携方式と認可取得方式の 統合方式の一提案 伊藤 宏樹† 横澤 成彦† † 日本電信電話株式会社 © 2010 NTT Information Sharing Platform Laboratories
  2. 2. 本発表の流れ 1. はじめに 1. 連携アイデンティティ管理 2. 認証連携と認可取得 2. 課題とアプローチ 1. 認証連携と認可取得の連携 2. SAML、OAuth 3. 連携方式提案の考え方 3. 連携方式の提案 1. 組み合わせ方式 2. シーケンスの重畳例 3. メッセージの重畳例 4. まとめ JR高松駅 2 © 2010 NTT Information Sharing Platform Laboratories
  3. 3. 1.1. 連携アイデンティティ管理  アイデンティティの3要素 – 識別子 (Identifiers) • アイデンティティ(ある組織や個人など)を識別するための情報 – 属性 (Attributes) • アイデンティティを特徴づける情報 – クレデンシャル (Credentials) • 識別子、属性の伝達時に、内容の正当性を示すための情報  連携アイデンティティ管理とは – 「アイデンティティ」 をサービス間で連携して利用すること 属性情報の記述 認証連携 (Liberty ID-SIS、OpenID AX等) (SAML、OpenID等)  個人プロフィール、従業員プロフィール  位置情報、カレンダーサービス 等 ユーザ合意 属性情報へのアクセス の取得  シングルサインオン (XACML、Liberty ID-WSF、OAuth等)  シングルログアウト  ユーザ属性の管理者の探索方式  アカウント連携 等  属性情報のアクセス権限取得方式  属性情報のサービス間の共有方式 等 3 © 2010 NTT Information Sharing Platform Laboratories
  4. 4. 1.2. 認証連携と認可取得  認証連携 (Single Sign-On) 認証要求 – あるウェブ上のサービスで 認証実施者 認証要求者 行ったユーザ認証結果を他 のサービスに提供すること 認証応答 – 例: SAML、OpenID ユーザID ユーザ  認可取得 権限委譲 – あるウェブ上のサービスで 属性管理者 属性要求者 必要となるユーザの認可(ア クセス権限)を、他のサービ 属性要求・提供 スに委譲すること ユーザ属性 – 例: XACML、Liberty ID- ユーザ WSF、OAuth 4 © 2010 NTT Information Sharing Platform Laboratories
  5. 5. 本発表の流れ 1. はじめに 1. 連携アイデンティティ管理 2. 認証連携と認可取得 2. 課題とアプローチ 1. 認証連携と認可取得の連携 2. SAML、OAuth 3. 連携方式提案の考え方 3. 連携方式の提案 1. 組み合わせ方式 2. シーケンスの重畳例 3. メッセージの重畳例 4. まとめ 高松城跡 5 © 2010 NTT Information Sharing Platform Laboratories
  6. 6. 課題 認可取得に必要なユーザ認証の簡素化 サービス間のアクセス権限委譲(認可取得)に際し、 属性要求者、属性管理者が、対象となるユーザを識別 する必要がある Aさんの情報に限り アクセスを許可します (3) 権限委譲 属性要求者 属性管理者 (4) 属性要求・提供 (1) ユーザ認証 Aさん (5) サービス提供 Aさん (2) ユーザ認証に 基づくアクセス許可 ユーザ サービス間の認可取得におけるユーザ操作の簡素化には、 ユーザ認証と統合したワンストップ化が有効 6 © 2010 NTT Information Sharing Platform Laboratories
  7. 7. 2.2. SAML と OAuth  SAML – 認証連携方式の一種、OASIS SSTC* にて規定 – ユーザの認証結果をウェブ上のサービス間で共有する、サービス間の認 証要求、応答メッセージ、 プロトコルを規定 • 認証トークン、要求、応答メッセージ: XML文書 • プロトコル: HTTP、SOAP 等 – 主な事例: Google Apps、SalesForce.com、NTTドコモ  OAuth – 認可取得方式の一種、IETF** にて規定 – ユーザ個々の制限された情報をウェブ上のサービス間で共有するために 必要な、ユーザの許可(認可)情報をサービス間で共有する • 認証トークン、要求、応答メッセージ: HTTPパラメータ • プロトコル: HTTP、REST – 主な事例: Twitter、Yahoo!、mixi、goo (OpenSocial の一部機能としての 採用も含む) * http://www.oasis-open.org/committees/security/ ** http://tools.ietf.org/wg/oauth/ 7 © 2010 NTT Information Sharing Platform Laboratories
  8. 8. SAML の基本シーケンス ブラウザ SAML IdP SAML SP (認証実施者) (認証要求者) 1. サービス要求 2. SAML 認証要求 (HTTP Redirect もしくは HTTP POST を用いた要求メッセージ送信) 3. ユーザ認証 4. SAML 認証応答 (HTTP POST を用いた応答メッセージ送信) 5. ユーザ属性に基づくサービス提供 規定外 SAML 8 © 2010 NTT Information Sharing Platform Laboratories
  9. 9. OAuth の基本シーケンス ブラウザ OAuth SP Consumer (属性管理者) (属性要求者) 1. サービス要求 (本稿では以下、省略) 2. コールバックURLの要求 3. OAuth 「未認可」リクエストトークン取得 4. OAuth 「認可済」リクエストトークン要求 5. ユーザ同意 6. OAuth 「認可済」リクエストトークン送信 7. アクセストークン取得 8. アクセストークンをもとにユーザの属性を要求,取得 規定外 9. ユーザ属性に基づくサービス提供 OAuth 9 © 2010 NTT Information Sharing Platform Laboratories
  10. 10. 2.3. 連携方式提案の考え方  コンコーディア – 本検討を含む、ID管理技術間の相互運用方式は、 ID管理に 関する標準化団体カンターラ・イニシアティブ* の一分科会、 コンコーディア** で議論されている – コンコーディアでは実サービスをイメージしたユースケースに 基づき、ID管理技術間の相互運用方式、複数ID管理技術の 重畳方式を提案している 本検討も2方式の統合方式をユースケースに基づき提案する  その他の事例 – OpenID と OAuth との連携方式 (OpenID OAuth Extension) が D. Balfanz らにより提案*** されている * http://kantarainitiative.org/ ** http://kantarainitiative.org/confluence/display/concordia/ *** http://step2.googlecode.com/svn/spec/openid_oauth_extension/ 10 © 2010 NTT Information Sharing Platform Laboratories
  11. 11. 本発表の流れ 1. はじめに 1. 連携アイデンティティ管理 2. 認証連携と認可取得 2. 課題とアプローチ 1. 認証連携と認可取得の連携 2. SAML、OAuth 3. 連携方式提案の考え方 3. 連携方式の提案 1. 組み合わせ方式 2. シーケンスの重畳例 3. メッセージの重畳例 4. まとめ 第八十五番札所 八栗寺 11 © 2010 NTT Information Sharing Platform Laboratories
  12. 12. 3.1. 認証連携方式と認可取得方式との組み合わせ  認証連携  認可取得 認証要求 権限委譲 SAML SP Consumer SAML IdP OAuth SP 認証応答 属性要求・提供 方式 SAML IdP が持つ機能 SAML SP が持つ機能 1 OAuth SP Consumer 2 Consumer OAuth SP OAuth SP (サービス1) 3 (なし) Consumer (サービス2) OAuth SP (サービス1) (なし) Consumer (サービス2) 12 © 2010 NTT Information Sharing Platform Laboratories
  13. 13. 方式1 「通販サイトでポータルサイトの属性を利用」 ポータルサイト 通販サイト 1. 要求 認証実施者 認証要求者 2. 応答 属性管理者 属性要求者 1. 通販サイトはポータルサイトにサービス提供に必要なユーザ 認証およびユーザ属性(ユーザの住所、氏名等)を同時に要 求する (ユーザはポータルサイトで認証および属性提供を承認) 2. ポータルサイトは通販サイトにユーザ認証結果、ユーザ属性 取得用認可トークンを同時に通知する (ユーザは通販サイトにてユーザ属性に基づくサービスを受ける) 13 © 2010 NTT Information Sharing Platform Laboratories
  14. 14. 方式2: 「ポータルサイトでプロフ管理サイトの属性を利用」 ポータルサイト プロフ管理サイト 1. 認証要求 認証実施者 認証要求者 2. 認証応答 + 属性要求 属性要求者 3. 属性応答 属性応答者 1. プロフ管理サイトはポータルサイトにユーザ認証を要求する 2. ポータルサイトはプロフ管理サイトに認証結果を通知すると同 時に、ユーザ属性を要求する (ユーザはプロフ管理サイトでユーザ属性提供を承認) 3. プロフ管理サイトは通販サイトにユーザ属性取得用認可トーク ンを通知する (ユーザはポータルにてユーザ属性に基づくサービスを受ける) 14 © 2010 NTT Information Sharing Platform Laboratories
  15. 15. 方式3: 「通販サイトでプロフ管理サイトの属性を利用」 ポータルサイト 認証実施者 1. 認証要求 2. 認証応答 認証要求者 認証要求者 3. 属性要求 属性要求者 4. 属性応答 属性応答者 通販サイト プロフ管理サイト 15 © 2010 NTT Information Sharing Platform Laboratories
  16. 16. 方式3: 「通販サイトでプロフ管理サイトの属性を利用」(続) ポータルサイト 1. 2. 1. 通販サイト 3. プロフ管理サイト 1. 通販サイトは、ポータルサイトにユーザ認証、ポータルサイトを 介してプロフ管理サイトにユーザ属性を要求する (ユーザはポータルサイトにて認証に必要な手続きを実施) 2. ポータルサイトはプロフ管理サイトに認証結果を通知すると同 時に、ユーザ属性を要求する (ユーザはプロフ管理サイトでユーザ属性提供を承認) 3. プロフ管理サイトは通販サイトにユーザ属性取得用認可トーク ンを通知する (ユーザは通販サイトにてユーザ属性に基づくサービスを受ける) 16 © 2010 NTT Information Sharing Platform Laboratories
  17. 17. 3.2. シーケンスの重畳 (方式1のケース) ポータル 通販事業者 枠内は SAML のメッセージに OAuth ブラウザ SAML IdP SAML SP のメッセージが重畳される OAuth SP OAuth Consumer 1. サービス要求 2. SAML 認証要求 + OAuth リクエストトークン要求 3. ユーザ認証および属性提供にかかるユーザ同意 4. SAML 認証応答,OAuth リクエストトークン送信 5. アクセストークン取得 シングルサインオンと認可取得が同時に 実施されることでユーザ操作はポータル 6. アクセストークンをもとにユーザの属性を要求,取得 サイトにおける 3. に集約可能 7. ユーザ属性に基づくサービス提供 規定外 SAML OAuth 17 © 2010 NTT Information Sharing Platform Laboratories
  18. 18. 3.3. メッセージの重畳例 (方式1のケース) [1/2]  SAML 認証要求 + OAuth リクエストトークン要求 <samlp2:AuthnRequest Destination=“https://idp.example.jp:8443/samlidp/sso_redirect” ForceAuthn=“false” ID=“IDLREQnx0WrENJomAE2lXJe68Wxsmecltk” ConsumerKey は AttributeConsumingServiceIndex IsPassive=“false” IssueInstant=“2010-02-21T10:35:00Z” を利用してメタデータで指定する ProviderName=“SAML SP” Version=“2.0” AttributeConsumingServiseIndex=“0" xmlns:saml2=“urn:oasis:names:tc:SAML:2.0:assertion” xmlns:samlp2=“urn:oasis:names:tc:SAML:2.0:protocol”> <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"> https://demo.liberty.ntt:8443/samlsp/provider </saml2:Issuer> <samlp2:NameIDPolicy Scopeの指定はExtensionsを利用する AllowCreate="false" (ConsumerKeyに対してScopeを固定して、メタデータに記述してもよい) Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/> <samlp2:Extensions> <ext:OAuth xmlns:ext=“http://www.ntt.co.jp/saml20/ext”> <ext:scope>http://oauthsp.example1.jp/</ext:scope> </ext:OAuth> </samlp2:Extensions> </samlp2:AuthnRequest> 18 © 2010 NTT Information Sharing Platform Laboratories
  19. 19. 3.3. メッセージの重畳例 (方式1のケース) [2/2]  SAML 認証応答 + OAuth リクエストトークン発行 <samlp2:Response> Assertion中のAttributeStatementに <samlp2:Status> .... </samlp2:Status> <saml2:Assertion> ・RequestToken <saml2:Issuer> .... </saml2:Issuer> ・TokenVerifier <saml2:Subject> .... </saml2:Subject> ・Scope <saml2:Conditions> .... </saml2:Conditions> を設定して返却 <saml2:AuthnStatement> .... </saml2:AuthnContext> </saml2:AuthnStatement> <saml2:AttributeStatement> RequestToken <saml2:Attribute Name=“OAuthRequestToken"> <saml2:AttributeValue> 1/F62n8QnroCQ-Vmkee4S8tGATiaQZnWPB51nTvo8n9Sw </saml2:AttributeValue> </saml2:Attribute> TokenVerifier <saml2:Attribute Name=“OAuthRequestTokenVerifier"> <saml2:AttributeValue>hdhd0244k9j7ao03</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute Name=“OAuthScope"> <saml2:AttributeValue>http://oauthsp.example1.jp/</saml2:AttributeValue> </saml2:Attribute> </saml2:AttributeStatement> Scope </saml2:Assertion> </samlp2:Response> 19 © 2010 NTT Information Sharing Platform Laboratories
  20. 20. 本発表の流れ 1. はじめに 1. 連携アイデンティティ管理 2. 認証連携と認可取得 2. 課題とアプローチ 1. 認証連携と認可取得の連携 2. SAML、OAuth 3. 連携方式提案の考え方 3. 連携方式の提案 1. 組み合わせ方式 2. シーケンスの重畳例 3. メッセージの重畳例 4. まとめ 次に進む 20 © 2010 NTT Information Sharing Platform Laboratories
  21. 21. まとめ  課題 – サービス間の認可取得におけるユーザ操作の簡素化のために、ユー ザ認証と認可取得とを統合する方式が必要  アプローチ – 認証連携方式の1つである SAML 方式と、認可取得方式の1つである OAuth 方式との統合方式を提案する  提案内容 – 認証連携方式と、認可取得方式の各機能の配置から、3通りの統合方 式(ユースケース、シーケンス、メッセージ)を提案した。 1. SAML IdP が OAuth SP を兼ねる 2. SAML IdP が OAuth Consumer を兼ねる 3. 2つの SAML SP がそれぞれ、OAuth SP、OAuth Consumer を兼ねる  今後の課題 – プロトタイプ化によるフィージビリティ検証 21 © 2010 NTT Information Sharing Platform Laboratories
  22. 22. ご清聴ありがとうございました
  23. 23. 皆様の参加をお待ちしております http://kantarainitiative.org/
  24. 24. (参考資料) © 2010 NTT Information Sharing Platform Laboratories
  25. 25. 方式1 「通販サイトでポータルサイトの属性を利用」 2. SAML 認証要求 ポータルサイト + OAuth リクエストトークン要求 通販事業者 4. SAML 認証応答 + OAuth リクエストトークン送信 SAML IdP SAML SP 5. OAuth アクセストークン取得 OAuth OAuth SP Consumer 6. OAuth ユーザ属性要求,取得 1. サービス要求 3. ユーザ認証および属 性提供にかかるユー ブラウザ 7. ユーザ属性に基づく ザ同意 サービス提供 25 © 2010 NTT Information Sharing Platform Laboratories
  26. 26. 方式2: 「ポータルサイトでプロフ管理サイトの属性を利用」 2. SAML 認証応答 + OAuth リクエストトークン要求 プロフィール ポータルサイト 管理サイト 4. OAuth リクエストトークン送信 SAML IdP SAML SP 5. OAuth アクセストークン取得 OAuth OAuth SP Consumer 6. OAuth ユーザ属性要求、取得 1. サービス要求, ユーザ認証 7. ユーザ属性に基づく ブラウザ 3. 属性提供にかかる サービス提供 ユーザ同意 26 © 2010 NTT Information Sharing Platform Laboratories
  27. 27. 方式3: 「通販サイトでプロフ管理サイトの属性を利用」 2. SAML 認証要求 + プロフ管理サイトへの遷移要求 + OAuth リクエストトークン要求 6. OAuth リクエストトークン送信 プロフィール ポータルサイト 通販事業者 7. OAuth アクセス 管理サイト SAML トークン取得 SAML SP1 SP2 SAML IdP 8. OAuth ユーザ OAuth 属性要求,取得 OAuth SP Consumer 4. SAML 応答 1. サービス要求 + OAuth リクエストトークン要求 9. サービス提供 3. ユーザ認証 ブラウザ 5. 属性提供にかかるユーザ 同意 27 © 2010 NTT Information Sharing Platform Laboratories
  28. 28. シーケンス: 方式1 ポータル 通販事業者 ブラウザ SAML IdP SAML SP OAuth SP OAuth Consumer 1. サービス要求 2. SAML 認証要求 + OAuth リクエストトークン要求 3. ユーザ認証 (optional) および属性提供にかかるユーザ同意 4. SAML 認証応答,OAuth リクエストトークン送信 5. アクセストークン取得 6. アクセストークンをもとにユーザの属性を要求,取得 7. ユーザ属性に基づくサービス提供 規定外 SAML OAuth 28 © 2010 NTT Information Sharing Platform Laboratories
  29. 29. シーケンス: 方式2 ポータル 通販事業者 ブラウザ SAML IdP SAML SP OAuth Consumer OAuth SP 1-1. サービス要求 1-2. ユーザ認証 (optional) 2. SAML 認証応答 + OAuth リクエストトークン要求 3. 属性提供にかかるユーザ同意 4. リクエストトークン送信 5. アクセストークン取得 6. アクセストークンをもとにユーザの属性を要求,取得 7. ユーザ属性に基づくサービス提供 規定外 SAML OAuth 29 © 2010 NTT Information Sharing Platform Laboratories
  30. 30. シーケンス: 方式3 ポータル プロフィール ブラウザ 通販事業者 サイト 管理サイト 1. サービス要求 2. SAML プロフ管理サイトへの遷移要求 + OAuth リクエストトークン要求 3. ユーザ認証 (optional) 4. SAML 認証応答 + OAuth リクエストトークン要求 5. 属性提供にかかるユーザ同意 6. リクエストトークン送信 7. アクセストークン取得 8. アクセストークンをもとにユーザの属性を要求,取得 9. ユーザ属性に基づくサービス提供 規定外 SAML OAuth 30 © 2010 NTT Information Sharing Platform Laboratories

×