ID (アイデンティティ) フェデレーションに関する技術動向と今後の方向性

8,433 views

Published on

IT サービスが個々に管理しているユーザーの ID (アイデンティティ) 情報をひもづけることによって、サービス間のデータや機能をユーザーを中心に連携する「ID (アイデンティティ) フェデレーション」について、その概念や、SAML (Security Assertion Markup Language), OpenID, OAuth, OpenID Connect などの関連技術仕様の動向、ならびに今後の方向性について概説します。

2 Comments
24 Likes
Statistics
Notes
No Downloads
Views
Total views
8,433
On SlideShare
0
From Embeds
0
Number of Embeds
69
Actions
Shares
0
Downloads
239
Comments
2
Likes
24
Embeds 0
No embeds

No notes for slide

ID (アイデンティティ) フェデレーションに関する技術動向と今後の方向性

  1. 1. ID (アイデンティティ) フェデレーションに関する 技術動向と今後の方向性 2012年9月19日 工藤達雄 株式会社野村総合研究所 IT基盤インテグレーション事業本部 DIソリューション事業部
  2. 2. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 概要 IT サービスが個々に管理しているユーザーの ID (アイデン ティティ) 情報をひもづけることによって、サービス間のデータ や機能をユーザーを中心に連携する「ID (アイデンティティ) フェデレーション」について、その概念や、SAML (Security Assertion Markup Language), OpenID, OAuth, OpenID Connect などの関連技術仕様の動向、ならびに今後の方向 性について概説します。 1
  3. 3. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 「ID統合」と「ID連携」は何が違うのか? ID統合 複数サービスのID関連情報を一ヶ所に集 約し、一元管理することが目的 ユーザーベースがサービス間で共通である 場合に向いている ▪ 組織内導入など ID連携 複数サービスのID関連情報を相互にひも づけ、サービス連携を行うことが目的 ユーザーベースがサービス毎に異なる場 合に向いている ▪ 企業間の協業や他社サービス利用など ▪ 組織内であってもサービス間に技術的・政治的 な壁がある場合など サービス サービス サービス サービス 各サービス固有のID情報を一ヶ所に集約 サービス (ユーザー認証のみ 外部化したい) サービス (一部の属性情報 管理を外部化したい) サービス ひもづけ情報を交換 既存の ID情報 DBを 廃止 複数の サービスが 共用する ID情報DBを 構築 既存の ID情報 DBは そのまま 維持 サービス間の ひもづけ情報 を管理するDB を構築 サービス (ひもづけに基づく API連携を行いたい) ユ ー ザ ー 認 証 属 性 提 供 業 務 API ひもづけに 基づいて ID情報や 業務機能 を提供 2
  4. 4. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. ID連携の例 コンシューマー向けサイトに他サービスのIDでログイン 3 ネットスーパーに ポータルサイトのIDでログイン デジタルコンテンツ販売サイトに ECサイトのIDでログイン Source: https://kids.showtime.jp/users/login Source: https://www.iy-net.jp/
  5. 5. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. ID連携の例 社内IDを用いて社外システムにログインし、サービスを連携 4 ID情報 (部門、役職、 内線、…) 1 2 3 4 8 5 6 7 企業 2. ユーザのID情報を要求 (認証リクエスト) 4. ユーザのID情報を返却 (認証レスポンス) 同時に「トークン」(API アクセス権の情報)を返却 5. 「トークン」を用いて、ユーザー に成り代わってWebサービスの APIを呼び出し 会社A ID連携システム 会社Aユーザ 会社A Webサービス Webアプリケーション 6. 「トークン」の有効 性・真正性を確認 7. 処理結果(業務データ など)を返却 8. 企業を またがって マッシュアップした コンテンツを提供 全社共有情報 ・インフルエンザ ・CSR活動参加 ・海外渡航注意喚起 ・セミナー連絡 などなど 部門向け情報個人向け情報 ・賞与 ・保険加入 ・人間ドック ・申請状況一覧 ・○○部組合員情報 など プロジェクト 向け情報 3. 社内のIDで ユーザ認証 会社A 共通IDシステム 会社AのIDで ログイン 1. 社外のアプリケー ションにアクセス 業務データ WebAPI
  6. 6. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. ID連携の例 通信事業者のIDを使ってネット決済 5 My SoftBank認証 auかんたん決済 Source: https://id.auone.jp/payment/pc/guide/idm/index.html Source: http://mb.softbank.jp/mb/support/procedure/service_terminal/mysb_auth/, http://mb.softbank.jp/mb/support/procedure/service_terminal/mysb_auth/payment/
  7. 7. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. ID連携の例 電子書籍サイトのコンテンツをパーソナル・クラウドに保存 6 1. 電子書籍サイトから パーソナル・クラウドの IDとのひもづけを開始 2. パーソナル・クラウドでユーザー認証を 行い、電子書籍サイトからの接続を許可 3. 電子書籍サイトにて「同期」を実行 4. ローカルにダウンロードするのではなく、 パーソナル・クラウドに保存完了 Source: https://members.oreilly.com/cs/members/edit
  8. 8. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. ID連携の例 ネット証券の機能をパートナーサイトに提供 自社の株式取引サービスをAPI化 ユーザーがネット証券サイトに管理しているポートフォリオへのアク セスや、ユーザーの代理で売買注文を行う機能を提供 パートナーサイトはID連携によってユーザーの同意を確認 ▪ パートナーサイトの例: ロボット売買、売買シグナルなど 7 WebAPIの提供 サービスの提供 Source: https://us.etrade.com/e/t/invest/apihome
  9. 9. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. ID連携技術の利用形態 8 サービス利用側 サービス提供側 ID情報 管理機能 ID情報 提供機能 (Identity Provider; IdP) ID情報 受入機能 (Relying Party; RP) サービス ID情報(認証結果、 属性情報など)の要求 ID情報の参照 ID情報の提供 ユーザ認証 ID情報の伝播 サービスへ アクセス ID情報 管理機能 ID情報の紐付け ID連携技術の 適用領域
  10. 10. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. ID連携に関連する仕様 SAML(Security Assertion Markup Language: サムル) サービス間でのアイデンティティ情報(セキュリティ・アサーション)および流 通方法を定義した汎用的な仕様 OpenID(オープンアイディー) Webサイト間でのWebブラウザを介したアイデンティティ情報(認証結果と 属性情報)の要求・提供プロトコルを定義した仕様 OAuth(オーオース) サービス間でのAPI (Application Programming Interface) のアクセス認 可情報(アクセス・トークン)の要求・提供・利用を定義した仕様 OpenID Connect(オープンアイディー・コネクト) OAuth(バージョン2.0)をベースに、APIアクセス認可とアイデンティティ情 報の要求・提供を統合した仕様 9
  11. 11. SAML 10
  12. 12. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. SAMLとは 標準化団体OASIS Openにて仕様化されたアイデンティティ情 報を安全に流通させるためのXML形式、及び通信仕様 11 出典:第一回Liberty Alliance技術セミナー資料 Single Sign On(SSO)を実現 IdPからSPに対して、SAMLアサー ションを流通させる 一般的なブラウザが対応するHTTP プロトコル上でSSO セキュアな情報交換 SSOだけでなく、IdP-SP間で安全に 情報交換を行うサーバ間通信につい ても規定 Circle of Trustモデル 事前に情報交換を行う相手と強固な 信頼関係を結ぶ(PKI鍵交換を含む)
  13. 13. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. SAMLとは ID連携を実現する主要 要素を4つに分解し、 サービス連携のための 包括的な仕様を構成 アサーション プロトコル バインディング プロファイル SAMLのコアは 「アサーション」 XML形式 12 Profile 特定のユースケース(SSOなど)を実現するうえでの、アサー ション、プロトコル、バインディングの組み合わせを規定。 Binding リクエストおよびレスポンスの手続きを、実際にIdPとRP の間でどのように実施するか規定。直接通信(SOAP)や、 ユーザエージェントを介在させるHTTPリダイレクト通信な どが存在。 Protocol アサーションの送受信を実施するためのリクエストお よびレスポンスの手続き。 Assertion ユーザのID名や認証方法およびそのユーザの 属性や権限に関する表明。
  14. 14. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. SAML仕様構成要素 13 ユーザに関するアイデンティティ情報を 以下のとおり表明します: ユーザID: taro 認証方法: パスワード 氏名: 山田太郎 メールアドレス: … アサーション プロトコル バインディング プロファイル アイデン ティティ・ プロバイダ (IdP) サービス プロバイダ (SP) (RP) リクエスト レスポンス アサーション アイデン ティティ・ プロバイダ (IdP) サービス プロバイダ (SP) (RP) ユーザ・ エージェント レスポンス アサーション ブラウザをリダイ レクトさせてレス ポンスを伝達 アイデン ティティ・ プロバイダ (IdP) サービス プロバイダ (SP) (RP) ユーザ・ エージェント レスポンス アサーション 1. SPからIdPにアサー ションをリクエスト 3. アサーション を提供 リクエスト 2.ログインを要求
  15. 15. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 仕様要素の組み合わせで多様なユースケースを実現 SAMLで最も代表的なユースケース(Web SSO) ブラウザ(Client)を介して、IdPからSP(RP)に対してアサーションを受け渡し 14 Client SP(RP) IdP  Binding:HTTP Redirect, POST  Protocol:Authentication Request, Response  Binding:Artifact, SOAP  Protocol:Authentication Request, Response, Artifact Resolve Client SP(RP) IdP HTTP Redirect, POST User Authentication HTTP POST Artifact Artifact Artifact Resolve( + SOAP) Authenticati onRequest Response Assertion Authenticati onRequest Assertion サービス提供 Response Artifact ArtifactResolve Artifact ArtifactResponse Assertion User Authentication サービス利用開始 サービス利用開始 サービス提供
  16. 16. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. SAMLプロトコル 15 # 名称 概要 1 Authentication Request IdPに対してSPがユーザの認証を要求するために利用するSAMLメッセージを規定するプロトコル。 2 Response SPからの要求に対してアサーションを返却するために利用するSAMLメッセージを規定するプロト コル。 3 Artifact Resolve SPがArtifact(SAMLメッセージへの参照)をIdPに対して送信し、参照先であるSAMLメッセージ本 体を取得するためのSAMLメッセージを規定するプロトコル。 ブラウザを介したSAMLメッセージの送受信経路の回線帯域が小さい場合や、ブラウザ送受信でき るデータサイズの最大値がSAMLメッセージの送受信に必要な要件を満たさない場合に利用され る。 4 Single Logout 同一のIdPから取得した認証アサーションによってログインが完了している全てのSPからログアウト するためのSAMLメッセージを規定するプロトコル。SOAPやHTTP Redirectバインディングと組み 合わせて利用できる。 5 Assertion Query and Request 認証済みユーザの認証アサーション、属性アサーション、認可決定アサーションを要求するための SAMLメッセージを規定するプロトコル。 6 Manage NameID SPとIdPの間でユーザを特定するための紐付け用名前識別子(NameID)の洗い替え・削除を行う ためのSAMLメッセージを規定するプロトコル。 7 NameID Mapping ユーザの名前識別子(NameID)のフォーマットを変換する、または別のSPで同じユーザを指す名前 識別子に変換するために利用するSAMLメッセージを規定するプロトコル。
  17. 17. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. SAMLバインディング 16 # 名称 概要 1 HTTP Redirect (GET)Binding 一般的にブラウザリダイレクト(HTTPステータスコード302)を用いて、アクセスするサーバのURI にSAMLメッセージを付与する(GETメソッドを利用する)方式。ブラウザ実装によっては、GETメ ソッドで扱えるURI長に制限がある。 2 HTTP POST Binding POSTメソッドを用いて、SAMLメッセージを送受信する方式。HTTP Redirect Bindingと比較して、 多くの場合大きなサイズのSAMLメッセージを流通させることができる。 3 HTTP Artifact Binding HTTP Redirect/POST Bindingのようなブラウザを介した間接通信を行う経路が、ネットワーク帯 域的に制限されていたり、ブラウザ自体が取り扱えるデータ長に制限がある場合に、サイズの小 さなArtifact(SAMLメッセージ本体への参照)を間接通信路で交換し、サイズの大きなSAMLア サーション本体はSPとIdPの直接通信で交換する方式。 4 SOAP Binding SAMLのメッセージをSOAPメッセージ上に載せる方式。 5 Reverse SOAP Binding サーバ(SPおよびIdP)とクライアント(ブラウザ)の関係を逆転させ、HTTP応答にSAML要求メッ セージを含むSOAPメッセージを載せ、HTTP要求にSAML応答メッセージを含むSOAPメッセー ジを載せる方式。クライアントがSOAPおよびSAMLメッセージを処理できること(ECP: Enhanced Client or Proxy)が前提となる。 6 SAML URI Binding URI形式のアクセスにより、アサーションを直接取得するための方式。
  18. 18. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. SAMLプロファイル 17 # 名称 概要 1 Web Single Sign- on & Federation IdPとSPとの間で名前識別子(NameID)を連携、IdPからSPに対してSAML認証アサーションを受 け渡すことで、同一のCircle of Trustに所属するSPに対してシングルサインオンを行うための手 順を規定する。 2 Artifact Resolution IdPとSPとの間で受渡されたArtifactと引き換えに、SAMLメッセージ本体を取得する手順を規定 する。 3 Single Logout 同一のIdPから取得した認証アサーションによってログインが完了している全てのSPからログア ウトするための手順を規定する。 4 Identity Provider Discovery ユーザが現在利用中のIdPを、Cookieを介して、SPとIdPが発見する、および発見できるようにす るための手順を規定する。 5 Manage NameID IdPとSPの間でユーザを特定するために共有されている名前識別子(NameID)を、変更・削除す るための手順を規定する。 6 NameID Mapping SPが、あるユーザのことを指す名前識別子(NameID)を入手したり、フォーマットの異なる名前 識別子に変換したり暗号化する手順を規定する。
  19. 19. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. SAMLの普及動向 Google AppsやSalesforce.comなどのSaaS提供事業者 が、利用企業との間のID連携のベースとして採用 SaaS契約企業の社員が、社内SSO(シングル・サインオン)でユー ザー認証を受け、社外のSaaSにログイン その他、B2B(業務目的での企業間連携)や、高等教育機関 でのフェデレーション・ネットワークのベースとして採用  cf. Global Trust Framework Survey - DG - Business Cases for Trusted Federations - Kantara Initiative http://kantarainitiative.org/confluence/display/bctf/Global+Trust+Framework+Survey ただし、フェデレーション要件に応じてSAML仕様をどう使う か取り決める(プロファイリング)必要があるため、フェデレー ション・ネットワーク間の相互運用性は低い 18
  20. 20. OpenID 19
  21. 21. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 「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): ユーザー認証・同意ページのユー ザー・インタフェースの指定 20
  22. 22. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. OpenID の概念と登場人物 ユーザがアイデンティティ (ID) 情報の提供サイトを選択(ただし実際にはホワ イトリストによる運用が一般的) OpenID プロバイダ (OP): ID 情報 (認証結果や属性情報) を RP に提供するサイト OpenID リライング・パーティ (RP): OP から提供された ID 情報を受け入れるサイト 21 RP (医療情報 管理サービス) 「本人以外には決し て公開しない」 RP (無料日記 サービス) 「誰でも気軽にコメ ントしてほしい」 RP(ホテル予約 サービス) 「確かな属性情報が ほしい」 OP(ポータル サイト) 誰でも即時アカ ウント取得可能 OP(航空券 予約サービス) クレジットカード 番号等を管理 OP(高度認証 サービス) 登録時に厳密な 本人確認を行ない、 多要素認証を実施 ID / パスワード でログイン ID情報の提供 ID / 画像認証 でログイン ICカードの証 明書でログイン ID情報の提供 ID情報の提供 クレデンシャル情報(ID/PW等)の入力 によるユーザの特定はOP側で行うため、 RP側にクレデンシャル情報を流通させ る必要がない OP:ID情報の提供側 RP:ID情報の受入側
  23. 23. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. OP と RP 間のやりとりの仕組み 22 ユーザ エージェント (ブラウザ) RP OP エンドユーザーの ID/パスワード OpenID入力 ①ディスカバリ OpenID(URL) にアクセス OP の通信先 (EndPoint URL)等を返却 ②アソシエーション 共有秘密鍵の交換 ③認証要求 リダイレクトによる OP への認証要求 (ユーザと OP 間の認証処理と ID 情報提供への同意) ④認証応答 リダイレクトによる ID 情報返却 サービス提供 GET https://www.google.com/accounts/o8/ ud &openid.ns=http://specs.openid.net/a uth/2.0 ↑プロトコルバージョン &openid.assoc_handle=AMlY****A9 ↑②で交換した共有秘密鍵への参照キー &openid.mode=checkid_setup ↑モード(認証要求) &・・・・ GET https://iknow.jp/open_ids &openid.ns=http://specs.openid.net/a uth/2.0 &openid.assoc_handle=AMlY****A9 &openid.mode=id_res ↑モード(認証応答) &openid.claimed_id=https://www.goo gle.com/accounts/o8/id?id=AItO****aw m ↑OP が認証した識別子(OpenID) &openid.sig=5aDmb****ExYmdwqaU ↑パラメータの共有秘密鍵による署名 要求リクエストのプ ロトコルバージョン を付与 秘密鍵への参照 キーによる、メッセー ジの改ざん対策 OP で認証された OpenID の返却 改ざん検知用のメッ セージ署名
  24. 24. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. OpenID 2.0の普及動向 多数のユーザを抱えるWebサイトが、他社WebサイトにID情 報を提供するための API(Application Programming Interface)としてOpenIDを採用 インターネットサービス事業者(例: Yahoo!、Google、ミクシィ) 携帯通信事業者(例: NTTドコモ、KDDI、ソフトバンク) ネット決済事業者(例: 楽天(楽天あんしん支払いサービス)、 PayPal) 米国において、民間のIdP (Identity Provider:たとえばポー タル事業者や決済事業者など、市民に対してID を発行・運用 する組織)と、連邦政府機関の市民向けWeb サイトとのID連 携プロトコルの一つとして採用 23
  25. 25. OAuth 24
  26. 26. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. Web API: 自社以外のチャネルへ浸透するためのしくみ コンテンツ/ 機能 PC/携帯電話向け Webサイト スマートフォン向け Webサイト/アプリ エンドユーザー サービス事業者 外部パートナー企業 / 開発者 Webサイト アプリ 実店舗 PC、携帯端末 以外の デバイス 25 サービス事業者の IDでログイン サービス事業者の IDでログイン 外部向けAPI (Web API)
  27. 27. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. Web API? API (Application Programming Interface) あるコンピューター・プログラムが自身のサービスを外部の コンピューター・プログラムに提供する際の、サービスの機能や アクセス方法の定義のこと APIを利用することにより、異なるプログラム同士の連携が 容易となり、開発の手間を省くことができる Web API Webサービスが、外部のWebサイトやアプリケーションに対し、 インターネットを介して公開するAPI 26
  28. 28. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. Web APIの例 Yahoo! JAPAN Google 楽天 ミクシィ Facebook Twitter … 27
  29. 29. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. Webブラウザのトラフィック << Web APIのトラフィック 28 Source: “Open, Mobile, Social”, Cloud Identity Summit 2011 Proceedings http://bit.ly/pBXcgM Force.com の API / Web トラフィック比較 Source: Migrating Netflix from Datacenter Oracle to Global Cassandra http://www.slideshare.net/adrianco/migrating-netflix-from-oracle-to-global-cassandra Source: Developing for @twitterapi (Techcrunch Disrupt Hackathon) http://www.slideshare.net/raffikrikorian/developing-for-twitterapi-techcrunch-disrupt-hackathon 21億リクエスト/月 4,000億リクエスト/月 20億リクエスト/月 北米のインターネットトラ フィックの20~30%
  30. 30. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. Web APIを外部に公開するサービスは急激に増加 29 2010年12月の段階で 2,000超のWeb APIが 存在 2012年9月には 7,144種類 にまで増大 Source: Open API Ecosystem Overview: December 2010 <http://slidesha.re/g8irEO> Source: ProgrammableWeb http://www.programmableweb.com Source: Open APIs and the Semantic Web 2011 http://www.slideshare.net/jmusser/j-musser-semtechjun2011
  31. 31. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. そして、Web APIのトレンドは民間企業だけではない 2012年5月、オバマ政権はデジタル政 府戦略の一つとして、主要な連邦政府 機関に対し、今後Web APIを公開する よう命令  “Digital Government: Building a 21st Century Platform to Better Serve the American People” http://www.whitehouse.gov/sites/default/files/omb/egov/digital- government/digital-government-strategy.pdf 各機関は、12ヶ月以内に「Web API 化」を実行しなくてはならない 最低2つの主要システムのWeb API化 Web APIを利用する開発者向けに “agency.gov/developer” ページの公開 30 Source“Digital Government: Building a 21st Century Platform to Better Serve the American People” http://www.whitehouse.gov/sites/default/files/omb/egov/digital- government/digital-government-strategy.pdf
  32. 32. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. ただし、Web APIだけでは… コンテンツ/ 機能 PC/携帯電話向け Webサイト スマートフォン向け Webサイト/アプリ エンドユーザー サービス事業者 外部パートナー企業 / 開発者 Webサイト アプリ 実店舗 PC、携帯端末 以外の デバイス 31 サービス事業者の IDでログイン サービス事業者の IDでログイン 外部向けAPI (Web API) パートナーID でアクセス パートナーID でアクセス パートナーID でアクセス パートナーサイトやアプリケーション単位 でのAPIアクセスとなるため、その先にい るどのユーザーがサービスを利用しよう としているかわからない
  33. 33. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. Web APIによってチャネルを広げつつ、エンドユーザーとの 接点を確保するためのしくみが「ID連携」 コンテンツ/ 機能 PC/携帯電話向け Webサイト スマートフォン向け Webサイト/アプリ エンドユーザー サービス事業者 外部向けAPI (Web API) 外部パートナー企業 / 開発者 Webサイト アプリ 実店舗 PC、携帯端末 以外の デバイス 32 サービス事業者 のIDでの代理 アクセスを許可 サービス事業者 のIDでの代理 アクセスを許可 サービス事業者 のIDでの代理 アクセスを許可 サービス 事業者のIDで 代理アクセス サービス 事業者のIDで 代理アクセス サービス 事業者のIDで 代理アクセス サービス事業者の IDでログイン サービス事業者の IDでログイン ID連携によってパートナーサイト/アプリ ケーションとサービス事業者のIDをひも づけ、どのエンドユーザーがWeb APIに アクセスしているかを把握する
  34. 34. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 利用イメージ 33 会員情報の登録 を登録お客さまの 1. パートナーサイトの 会員情報に、自分の 「ECサイトのID」を登録 「ECサイトID」 パートナーサイト 会員情報の登録 ECサイトID: taro@example.jp 4. 登録完了 パートナーサイト 2. ECサイトにログイン ログイン キャンセル ID: パスワード: taro@example.jp ******** ECサイト あなたへのおすすめ商品があります Powered by 「ECサイト」 •… •… •… パートナーサイトから出ることなく、ECサイトの 商品情報とショッピングカートにアクセス ECサイト内での行動履歴を元に パートナー提携ショップでの体験を最適化 パートナーが開発した個別デバイス 向けアプリケーションに情報を提供 ECサイトに登録してあるID情報を用いたパーソナライズや、 ECサイトのカート機能をパートナーに提供 カートに入れる カートに入れる カートに入れる パートナーサイト 3. ECサイト上のサービスへ のアクセスを許可 パートナーが提供するサービス経由 でECサイトの「ほしい物リスト」 「クチコミ投稿」「カート機能」を 利用できるようにします OK キャンセル ECサイト
  35. 35. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. OAuth の登場 「トークンによる API アクセス制御」の フレームワーク トークン: ユーザーに成り代わってアクセス することを示す符号 広く使われているのは「API プロバイダー がエンドユーザを直接認証するフロー」 APIクライアントが介在しないため、そこからの 「ID/パスワードの流出」がなくなる ▪ API クライアントが管理するのはID/パスワードで はなくトークン API 提供側はユーザー単位でのアクセス管理 が可能 ▪ トークンはエンドユーザとひもづいている まもなくOAuth 2.0がRFC標準となる 見込み 現行のOAuth 1.0はobsoleteに 34 エンド ユーザー API クライアント API プロバイダ エンドユーザーの ID/パスワード APIプロバイダのID/ パスワードを入力 トークンを リクエストに付加し、 APIを呼出/応答 サービスを提供 サービスにアクセス APIプロバイダーに「特定の サービスにアクセスするための トークン」を要求 「APIプロバイダーの ID/パスワードを入力 してください」 トークンを APIクライアントに返却 アクセス範囲を限 定したトークンを要 求することができる ID/パスワードが APIクライアントに 漏えいしない
  36. 36. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. OAuthの普及動向 APIアクセス認可の事実上の標準フレームワークとして広く 普及 ソーシャル・ネットワーク: Facebook, Twitter, mixi, Google+, GREE, Ameba, Windows Live, LinkedIn, … エンタープライズ: Google Apps, Microsoft Office 365, Salesforce.com, … EC/決済/ポイント: 楽天、Yahoo!、PayPal、… 銀行/証券: AXA Banque, E*TRADE, … その他多数 35
  37. 37. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. OpenIDとOAuthの組み合わせ OpenID は意外と実装が難しい 鍵交換や署名の付与・検証を自力で実装することは比較的難易度が高い これらの処理を行うライブラリは多数あるが、環境によっては組み込みが 難しい OAuth は単純には認証に使えない トークンはAPIアクセスのためであり、認証結果としては利用できない API の権限設定が粗いと、トークンが必要以上の権限を持つ 悪意のあるユーザ、サイトによって、権限の乱用や他人に成り済ましたトー クン利用が可能となる OpenID と OAuth を組み合わせる仕様 (OpenID/OAuth Hybrid) も考案されているが… 仕様がドラフトのままアップデートされていない ▪ OAuth は1.0プロトコルベース 両プロトコルをそれぞれ実装する手間がかかる 36
  38. 38. OpenID Connect 37
  39. 39. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. OpenID Connectとは http://openid.net/connect OpenIDの次期バージョン OAuth 2.0 仕様をベースに拡張 「シンプルな認証結果と属性情報の取得」 (後述) の範囲であれば、 一般的なOAuth 2.0認可 + API アクセスのフローとほぼ同様 メッセージ形式にJSONを採用 加えてJWT (JSON Web Token) を活用することにより、 署名と暗号化をサポート 仕様のモジュラー化 かんたんなことをシンプルにする一方、複雑なことも実現可能に 38
  40. 40. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. OpenID Connectの系図 39 Source: http://civics.com/openid-connect-webinar/
  41. 41. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. OpenID 2.0 40 OpenIDプロバイダ(OP) RPのリクエストに基づきユーザー認証を行い その認証結果と属性情報を提供 OpenIDリライング・パーティ(RP) OPに認証結果や属性情報をリクエストし その情報をもとにユーザーにサービスを提供 ユーザー RPへのアクセスを試みる過程においてOPから RPへの認証結果と属性情報の提供を許可 PCのWebブラウザ 1. 「OPの IDで ログイン」 2. OPの場所を特定し、リクエスト/ レスポンスに用いる署名鍵を交換 4. ユーザー認証の実施と 認証結果と属性情報の 提供可否の確認 6. アクセスを 許可し サービスを 提供 3. 認証リクエスト (ブラウザを リダイレクト) 5. 認証レスポンス (ブラウザを リダイレクト)
  42. 42. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. OpenIDプロバイダ(OP) RPのリクエストに基づきユーザー認証を行い その認証結果と属性情報を提供 Web API (ID情報、lセッション管理、 ソーシャル、決済、 アクティビティ、…) OpenID 2.0の課題 (≒ OpenID Connectの注力分野) 41 OpenIDリライング・パーティ(RP) OPに認証結果や属性情報をリクエストし その情報をもとにユーザーにサービスを提供 ユーザー RPへのアクセスを試みる過程においてOPから RPへの認証結果と属性情報の提供を許可 PCのWebブラウザ 1. 「OPの IDで ログイン」 2. OPの場所を特定し、リクエスト/ レスポンスに用いる署名鍵を交換 3. 認証リクエスト (ブラウザを リダイレクト) 4. ユーザー認証の実施と 認証結果と属性情報の 提供可否の確認 5. 認証レスポンス (ブラウザを リダイレクト) 6. アクセスを 許可し サービスを 提供 「携帯電話のWebブラウザや、 Webブラウザ以外の ユーザー・エージェント (ネイティブ・アプリケーションや JavaScriptクライアントなど) にも対応したい」 「認証リクエスト/ レスポンスに対して、 公開鍵を用いて 暗号化・署名したい」 「OP/RP間の設定をもっとかんたんに、 もしくは省略したい」 「OPの提供する 他のAPIと かんたんに 組み合わせたい」
  43. 43. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. OpenID Connectの特徴 42 エンド ユーザー API クライアント API プロバイダー エンドユーザーの ID/パスワード アクセストークンによる API呼出/応答 サービスを提供 サービスにアクセス 認証・同意 認可要求 APIプロバイダーに「特定のサービスに アクセスするためのトークン」を要求 認可応答 認可コードをAPIクライアントに返却 アクセストークン要求・応答 UserInfo要求・応答 OAuth の認証では不十分だった、認 証コンテキスト(いつ、誰が、誰を認証 したのか等)を「ID トークン」として提供 属性提供を行う UserInfo API が規定さ れ、API アクセスの標準ルールが策定 (認可コードとアクセストークンを 引換え/IDトークンの返却) OAuth2.0 ベースによる、トークンを利用 した全体的なフロー ・OAuth2.0 に対応済みであれば、一部 の拡張で OpenID Connect に対応可能
  44. 44. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. OpenID Connectのフロー(概要) 43 認可 サーバー ユーザー 情報 (クレーム) 3. ユーザー 認証・認可 クライアント 5. ユーザー属性 提供要求 クレーム プロバイダ クレーム ソース UserInfo エンドポイント エンドユーザー 認可 エンドポイント 1. サービスに アクセス OpenID プロバイダ 3 1 2 4 2. トークン 取得要求 (ブラウザの リダイレクト) 4. アクセス・ トークンとID トークンを返却 (ブラウザの リダイレクト) 5 6 6 . ユーザー 属性提供 7.(オプション): ユーザー属性 提供要求 7 8 8. (オプショ ン): ユーザー 属性提供 9 . サービス 提供 9
  45. 45. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. OpenID Connect Protocol Suite 「公式マップ」 http://openid.net/connect …が、以下のほうが実態に近 い気がする 44 Bindings •Basic Client Profile •Implicit Client Profile •Standard •Other Vendor Proprietary / Community Specific Bindings Endpoints and associated message formats •Messages Optional Functionality •Discovery •Dynamic Client Registration •Session Management •Other Vendor Proprietary / Community Specific Functionality Underpinnings
  46. 46. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 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形式 45
  47. 47. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. OpenID Connect のユースケース 2. 仕様に規定されている以外の属性の取得 認可リクエストのscopeに独自 の「クレーム」を指定 さらに認可リクエストに 「リクエスト・オブジェクト」を 付加し、要求する属性を指定 リクエスト・オブジェクト 認可サーバーへのリクエスト・ パラメータをJWT化したもの 認可リクエストへの付加方法 ▪ requestパラメータの値として リクエスト・オブジェクトを指定 ▪ request_uriパラメータの値として、 リクエスト・オブジェクトの場所を 指定 例: もし「edupersonクレーム」 を作る場合 scopeにedupersonを指定 リクエスト・オブジェクトとして 以下の内容を指定 UserInfoにアクセスすることに より、以下の属性を取得 46 { "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 } { "user_id": "248289761001", "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" }
  48. 48. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. OpenID Connect のユースケース 3. ユーザー認証の保証レベルの指定 認可リクエストに付加する 「リクエスト・オブジェクト」に、 要求する保証レベルを指定  ユーザー認証後得られた id_tokenに、保証レベルが 含まれる 例 リクエスト・オブジェクトとして 以下の内容を指定 ユーザー認証後取得した id_tokenに以下の内容が 含まれる 47 "id_token": { "claims": { "auth_time": null, “acr": { "values":["2"] } }, "max_age": 86400, } “acr": {"values":["3","2"]}
  49. 49. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. OpenID Connect のユースケース 4. UserInfoエンドポイントの外部にあるクレームの取得 UserInfoから提供する外部のクレームとして、「集約 (aggregated)クレーム」と「分散(distributed)クレーム」を 規定 集約(aggregated)クレーム UserInfoエンドポイントから提供されるクレームの中に、外部 クレームの「実体」が含まれる ▪ その「実体」はJWT形式に変換して含まれることにより、他のクレームと 区別される 分散(distributed)クレーム UserInfoエンドポイントから提供されるクレームの中に、外部 クレームを取得するための情報が含まれる ▪ 場合によっては、取得するための情報としてアクセス・トークンが指定 されている 48
  50. 50. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. OpenID Connect のユースケース 5. クライアントによるOpenIDプロバイダのディスカバリ OpenID Connect Discovery エンドユーザーが指定した識別子をもとに、OpenIDリライング・ パーティがOpenIDプロバイダを発見する仕組みを定義 ▪ OpenID 2.0にて実現されていた機能と同様 識別子は以下のどちらかであるべきである (SHOULD) ▪ メールアドレス or URL 識別子を元にOpenIDリライング・パーティは、SWD (Simple Web Discovery) により、OpenIDプロバイダを発見する 49 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"] }
  51. 51. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. OpenID Connect のユースケース 6. クライアント情報の動的な登録 OpenID Connect Dynamic Client Registration OpenIDプロバイダとOpenIDリライング・パーティとが、動的に信頼 関係を確立する仕組みを定義 ▪ OpenID 2.0にて実現されていた機能と同様 OpenIDリライング・パーティがOpenIDプロバイダの「クライアント登 録エンドポイント」に、自身を登録するようリクエスト ▪ 成功した場合、レスポンスとしてclient_id/client_secretが返却される 50 POST /connect/register HTTP/1.1 Accept: application/x-www-form-urlencoded Host: server.example.com Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ... fQ.8Gj_-sj ... _X type=client_associate &redirect_uris=https://client.example.org/callback %20https://client.examp le.org/callback2 &logo_url=https://client.example.org/logo.png &user_id_type=pairwise &sector_identifier_url= https://othercompany.com/file_of_redirect_uris_for_our_sites.js &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 HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "client_id":"s6BhdRkqt3", "client_secret": "cf136dc3c1fd9153029bb9c6cc9ecead918bad9887fce6c93f31185e58858 05d", "expires_at":2893276800 }
  52. 52. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. OpenID Connect のユースケース 7. セッション管理 OpenID Connect Session Management OpenIDプロバイダ(認可サーバー)におけるユーザーのログイン/ロ グアウトの状況を、OpenIDリライング・パーティ(サードパーティ)が 継続的にモニターする仕組みを定義 OP/RPの通信にiframeを利用 51
  53. 53. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. OpenID Connectの今後のロードマップ 現在Implementer’s Draftが公開中 今後最終仕様に OpenID Connectをサポートする製品・サービスベンダー (予定含む) Gluu、IBM、Layer7、Microsoft、野村総合研究所、Ping Identity、 Vordel、… AOL、Google、日本経済新聞社、PayPal、楽天、Salesforce.com、 Yahoo! JAPAN、… 52
  54. 54. Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. まとめ IDフェデレーションを活用したサービス は、コンシューマー/エンタープライズ/ 公共/文教を問わず、多方面に普及 しつつある これまでID連携はSSO/属性流通の ためという側面が強かったが、近年、 APIアクセス認可の基盤としての活用 が増えている SAML、OpenID、OAuthを統一する 仕様としてOpenID Connectが注目 されている 53 http://flic.kr/p/5iJp6M

×