• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
ID (アイデンティティ) フェデレーションに関する技術動向と今後の方向性
 

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

on

  • 6,258 views

IT サービスが個々に管理しているユーザーの ID (アイデンティティ) ...

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

Statistics

Views

Total Views
6,258
Views on SlideShare
6,252
Embed Views
6

Actions

Likes
20
Downloads
172
Comments
2

3 Embeds 6

http://s.deeeki.com 2
http://www.linkedin.com 2
https://www.chatwork.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

12 of 2 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • ID (アイデンティティ) フェデレーションに関する技術動向と今後の方向性 2012年9月19日 工藤達雄 株式会社野村総合研究所 IT基盤インテグレーション事業本部 DIソリューション事業部
    • 概要IT サービスが個々に管理しているユーザーの ID (アイデン ティティ) 情報をひもづけることによって、サービス間のデータ や機能をユーザーを中心に連携する「ID (アイデンティティ) フェデレーション」について、その概念や、SAML (Security Assertion Markup Language), OpenID, OAuth, OpenID Connect などの関連技術仕様の動向、ならびに今後の方向 性について概説します。 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 1
    • 「ID統合」と「ID連携」は何が違うのか? ID統合 ID連携  複数サービスのID関連情報を一ヶ所に集  複数サービスのID関連情報を相互にひも 約し、一元管理することが目的 づけ、サービス連携を行うことが目的  ユーザーベースがサービス間で共通である  ユーザーベースがサービス毎に異なる場 場合に向いている 合に向いている ▪ 組織内導入など ▪ 企業間の協業や他社サービス利用など ▪ 組織内であってもサービス間に技術的・政治的 な壁がある場合など サービス サービス サービス サービス サービス サービス (ユーザー認証のみ (一部の属性情報 (ひもづけに基づく 外部化したい) 管理を外部化したい) API連携を行いたい)既存のID情報 既存のDBを ID情報廃止 DBは 各サービス固有のID情報を一ヶ所に集約 そのまま 維持 ひもづけに ひもづけ情報を交換 基づいて 認ユ 属 業 ID情報や 複数の 証ー 性 務 ザ 業務機能 サービス間の 提 API サービスが ー 供 を提供 共用する ひもづけ情報 ID情報DBを を管理するDB 構築 を構築 サービス サービス Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 2
    • ID連携の例コンシューマー向けサイトに他サービスのIDでログイン ネットスーパーに ポータルサイトのIDでログイン デジタルコンテンツ販売サイトに Source: https://www.iy-net.jp/ ECサイトのIDでログイン Source: https://kids.showtime.jp/users/login Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 3
    • ID連携の例社内IDを用いて社外システムにログインし、サービスを連携 2. ユーザのID情報を要求 4. ユーザのID情報を返却 (認証リクエスト) (認証レスポンス) 同時に「トークン」(API 企業 アクセス権の情報)を返却 会社A ID連携システム 23. 社内のIDで 5. 「トークン」を用いて、ユーザー 4 ユーザ認証 ID情報 6. 「トークン」の有効 に成り代わってWebサービスの (部門、役職、 APIを呼び出し 内線、…) 6 性・真正性を確認 会社A 会社A 共通IDシステム Webサービス 5 Webアプリケーション 3 Web API 7 業務データ 7. 処理結果(業務データ など)を返却 1 会社Aユーザ 8 8. 企業を 全社共有情報 ・インフルエンザ ・CSR活動参加 またがって ・海外渡航注意喚起 ・セミナー連絡 1. 社外のアプリケー などなど ションにアクセス 会社AのIDで ログイン マッシュアップした 個人向け情報 ・賞与 ・保険加入 ・人間ドック 部門向け情報 プロジェクト 向け情報 コンテンツを提供 ・申請状況一覧 ・○○部組合員情報 など Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 4
    • ID連携の例通信事業者のIDを使ってネット決済 auかんたん決済 My SoftBank認証 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/ Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 5
    • ID連携の例電子書籍サイトのコンテンツをパーソナル・クラウドに保存 1. 電子書籍サイトから 2. パーソナル・クラウドでユーザー認証を パーソナル・クラウドの 行い、電子書籍サイトからの接続を許可 IDとのひもづけを開始 Source: https://members.oreilly.com/cs/members/edit 4. ローカルにダウンロードするのではなく、 パーソナル・クラウドに保存完了 3. 電子書籍サイトにて「同期」を実行 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 6
    • ID連携の例ネット証券の機能をパートナーサイトに提供自社の株式取引サービスをAPI化 ユーザーがネット証券サイトに管理しているポートフォリオへのアク セスや、ユーザーの代理で売買注文を行う機能を提供 パートナーサイトはID連携によってユーザーの同意を確認 ▪ パートナーサイトの例: ロボット売買、売買シグナルなど サービスの提供 WebAPIの提供 Source: https://us.etrade.com/e/t/invest/apihome Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 7
    • ID連携技術の利用形態 ID連携技術の 適用領域 ID情報(認証結果、 サービス利用側 属性情報など)の要求 サービス提供側 ID情報 ID情報ID情報の参照 提供機能 受入機能 ID情報 (Identity (Relying 管理機能 Provider; IdP) Party; RP) ID情報の紐付け ID情報の提供 ID情報 ID情報の伝播管理機能 サービス ユーザ認証 サービスへ アクセス Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 8
    • ID連携に関連する仕様SAML(Security Assertion Markup Language: サムル) サービス間でのアイデンティティ情報(セキュリティ・アサーション)および流 通方法を定義した汎用的な仕様OpenID(オープンアイディー) Webサイト間でのWebブラウザを介したアイデンティティ情報(認証結果と 属性情報)の要求・提供プロトコルを定義した仕様OAuth(オーオース) サービス間でのAPI (Application Programming Interface) のアクセス認 可情報(アクセス・トークン)の要求・提供・利用を定義した仕様OpenID Connect(オープンアイディー・コネクト) OAuth(バージョン2.0)をベースに、APIアクセス認可とアイデンティティ情 報の要求・提供を統合した仕様 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 9
    • SAML 10
    • SAMLとは標準化団体OASIS Openにて仕様化されたアイデンティティ情報を安全に流通させるためのXML形式、及び通信仕様Single Sign On(SSO)を実現 IdPからSPに対して、SAMLアサー ションを流通させる 一般的なブラウザが対応するHTTP プロトコル上でSSOセキュアな情報交換 SSOだけでなく、IdP-SP間で安全に 情報交換を行うサーバ間通信につい ても規定Circle of Trustモデル 事前に情報交換を行う相手と強固な 出典:第一回Liberty Alliance技術セミナー資料 信頼関係を結ぶ(PKI鍵交換を含む) Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 11
    • SAMLとはID連携を実現する主要 Profile 特定のユースケース(SSOなど)を実現するうえでの、アサー 要素を4つに分解し、 ション、プロトコル、バインディングの組み合わせを規定。 サービス連携のための Binding 包括的な仕様を構成 リクエストおよびレスポンスの手続きを、実際にIdPとRP の間でどのように実施するか規定。直接通信(SOAP)や、 アサーション ユーザエージェントを介在させるHTTPリダイレクト通信な どが存在。 プロトコル Protocol バインディング アサーションの送受信を実施するためのリクエストお よびレスポンスの手続き。 プロファイル AssertionSAMLのコアは ユーザのID名や認証方法およびそのユーザの 属性や権限に関する表明。 「アサーション」 XML形式 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 12
    • SAML仕様構成要素 アサーション プロトコル リクエスト ユーザに関するアイデンティティ情報を 以下のとおり表明します: アイデン サービス ユーザID: taro ティティ・ プロバイダ 認証方法: パスワード プロバイダ レスポンス (SP) (RP) 氏名: 山田太郎 (IdP) メールアドレス: … アサーションバインディング プロファイル アイデン アイデン サービス サービス ティティ・ ティティ・ 1. SPからIdPにアサー プロバイダ プロバイダ プロバイダ プロバイダ ションをリクエスト (SP) (RP) (SP) (RP) (IdP) (IdP) リクエスト レスポンス アサーション レスポンス ブラウザをリダイ 3. アサーション アサーション レクトさせてレス を提供 ユーザ・ ユーザ・ ポンスを伝達 エージェント エージェント 2.ログインを要求 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 13
    • 仕様要素の組み合わせで多様なユースケースを実現SAMLで最も代表的なユースケース(Web SSO) ブラウザ(Client)を介して、IdPからSP(RP)に対してアサーションを受け渡し  Binding:Artifact, SOAP Binding:HTTP Redirect, POST  Protocol:Authentication Request, Response, Protocol:Authentication Request, Response Artifact Resolve Client SP(RP) IdP Client SP(RP) IdP サービス利用開始 サービス利用開始 HTTP Redirect, POST Artifact Authenticati Authenticati onRequest onRequest User Authentication User Authentication Response Response Artifact HTTP POST Assertion Artifact ArtifactResolve Assertion Artifact サービス提供 Artifact Resolve( + SOAP) サービス提供 ArtifactResponse Assertion Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 14
    • SAMLプロトコル# 名称 概要1 Authentication IdPに対してSPがユーザの認証を要求するために利用するSAMLメッセージを規定するプロトコル。 Request2 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メッセージを規定するプロトコル。 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 15
    • SAMLバインディング# 名称 概要1 HTTP Redirect 一般的にブラウザリダイレクト(HTTPステータスコード302)を用いて、アクセスするサーバのURI (GET)Binding にSAMLメッセージを付与する(GETメソッドを利用する)方式。ブラウザ実装によっては、GETメ ソッドで扱えるURI長に制限がある。2 HTTP POST POSTメソッドを用いて、SAMLメッセージを送受信する方式。HTTP Redirect Bindingと比較して、 Binding 多くの場合大きなサイズのSAMLメッセージを流通させることができる。3 HTTP Artifact HTTP Redirect/POST Bindingのようなブラウザを介した間接通信を行う経路が、ネットワーク帯 Binding 域的に制限されていたり、ブラウザ自体が取り扱えるデータ長に制限がある場合に、サイズの小 さなArtifact(SAMLメッセージ本体への参照)を間接通信路で交換し、サイズの大きなSAMLア サーション本体はSPとIdPの直接通信で交換する方式。4 SOAP Binding SAMLのメッセージをSOAPメッセージ上に載せる方式。5 Reverse SOAP サーバ(SPおよびIdP)とクライアント(ブラウザ)の関係を逆転させ、HTTP応答にSAML要求メッ Binding セージを含むSOAPメッセージを載せ、HTTP要求にSAML応答メッセージを含むSOAPメッセー ジを載せる方式。クライアントがSOAPおよびSAMLメッセージを処理できること(ECP: Enhanced Client or Proxy)が前提となる。6 SAML URI Binding URI形式のアクセスにより、アサーションを直接取得するための方式。 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 16
    • SAMLプロファイル# 名称 概要1 Web Single Sign- IdPとSPとの間で名前識別子(NameID)を連携、IdPからSPに対してSAML認証アサーションを受 on & Federation け渡すことで、同一のCircle of Trustに所属するSPに対してシングルサインオンを行うための手 順を規定する。2 Artifact Resolution IdPとSPとの間で受渡されたArtifactと引き換えに、SAMLメッセージ本体を取得する手順を規定 する。3 Single Logout 同一のIdPから取得した認証アサーションによってログインが完了している全てのSPからログア ウトするための手順を規定する。4 Identity Provider ユーザが現在利用中のIdPを、Cookieを介して、SPとIdPが発見する、および発見できるようにす Discovery るための手順を規定する。5 Manage NameID IdPとSPの間でユーザを特定するために共有されている名前識別子(NameID)を、変更・削除す るための手順を規定する。6 NameID Mapping SPが、あるユーザのことを指す名前識別子(NameID)を入手したり、フォーマットの異なる名前 識別子に変換したり暗号化する手順を規定する。 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 17
    • 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仕様をどう使う か取り決める(プロファイリング)必要があるため、フェデレー ション・ネットワーク間の相互運用性は低い Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 18
    • OpenID 19
    • 「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. 20
    • 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. 21
    • 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. 22
    • 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. 23
    • OAuth 24
    • Web API: 自社以外のチャネルへ浸透するためのしくみ サービス事業者 サービス事業者の PC/携帯電話向け IDでログイン Webサイト サービス事業者の IDでログイン スマートフォン向け Webサイト/アプリ 外部パートナー企業 / コンテンツ/ 開発者 機能 外部向けAPIエンドユーザー Webサイト (Web API) アプリ 実店舗 PC、携帯端末 以外の デバイス Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 25
    • Web API?API (Application Programming Interface) あるコンピューター・プログラムが自身のサービスを外部の コンピューター・プログラムに提供する際の、サービスの機能や アクセス方法の定義のこと APIを利用することにより、異なるプログラム同士の連携が 容易となり、開発の手間を省くことができるWeb API Webサービスが、外部のWebサイトやアプリケーションに対し、 インターネットを介して公開するAPI Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 26
    • Web APIの例Yahoo! JAPANGoogle楽天ミクシィFacebookTwitter… Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 27
    • Webブラウザのトラフィック << Web APIのトラフィック 20億リクエスト/月 Force.com の API / Web トラフィック比較 北米のインターネットトラ 21億リクエスト/月 フィックの20~30% Source: “Open, Mobile, Social”, Cloud Identity Summit 2011 Proceedings http://bit.ly/pBXcgM Source: Migrating Netflix from Datacenter Oracle to Global Cassandra http://www.slideshare.net/adrianco/migrating-netflix-from-oracle-to-global-cassandra 4,000億リクエスト/月 Source: Developing for @twitterapi (Techcrunch Disrupt Hackathon) http://www.slideshare.net/raffikrikorian/developing-for-twitterapi-techcrunch-disrupt-hackathon Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 28
    • Web APIを外部に公開するサービスは急激に増加2010年12月の段階で 2,000超のWeb APIが 存在 Source: Open API Ecosystem Overview: December 2010 <http://slidesha.re/g8irEO>2012年9月には 7,144種類 にまで増大 Source: ProgrammableWeb Source: Open APIs and the Semantic Web 2011 http://www.programmableweb.com http://www.slideshare.net/jmusser/j-musser-semtechjun2011 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 29
    • そして、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を利用する開発者向けに Source“Digital Government: Building a 21st Century Platform to Better Serve the American People” “agency.gov/developer” ページの公開 http://www.whitehouse.gov/sites/default/files/omb/egov/digital- government/digital-government-strategy.pdf Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 30
    • ただし、Web APIだけでは… サービス事業者 サービス事業者の PC/携帯電話向け IDでログイン Webサイト サービス事業者の IDでログイン スマートフォン向け Webサイト/アプリ 外部パートナー企業 / コンテンツ/ 開発者 機能 パートナーID 外部向けAPIエンドユーザー Webサイト でアクセス (Web API) アプリ パートナーID でアクセス 実店舗 パートナーID でアクセス PC、携帯端末 パートナーサイトやアプリケーション単位 以外の でのAPIアクセスとなるため、その先にい デバイス るどのユーザーがサービスを利用しよう としているかわからない Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 31
    • Web APIによってチャネルを広げつつ、エンドユーザーとの接点を確保するためのしくみが「ID連携」 サービス事業者 サービス事業者の PC/携帯電話向け IDでログイン Webサイト サービス事業者の IDでログイン スマートフォン向け Webサイト/アプリ 外部パートナー企業 / コンテンツ/ 開発者 機能 サービス 外部向けAPIエンドユーザー サービス事業者 Webサイト 事業者のIDで のIDでの代理 代理アクセス (Web API) アクセスを許可 アプリ サービス 事業者のIDで サービス事業者 代理アクセス のIDでの代理 アクセスを許可 実店舗 サービス 事業者のIDで サービス事業者 PC、携帯端末 代理アクセス ID連携によってパートナーサイト/アプリ のIDでの代理 以外の ケーションとサービス事業者のIDをひも アクセスを許可 デバイス づけ、どのエンドユーザーがWeb APIに アクセスしているかを把握する Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 32
    • 利用イメージ 1. パートナーサイトの 会員情報に、自分の 3. ECサイト上のサービスへ 「ECサイトのID」を登録 2. ECサイトにログイン 4. 登録完了 のアクセスを許可パートナーサイト ECサイト ECサイト パートナーサイト ID: taro@example.jp パートナーが提供するサービス経由会員情報の登録 でECサイトの「ほしい物リスト」 会員情報の登録 パスワード: ******** 「クチコミ投稿」「カート機能」をお客さまの 「ECサイトID」 を登録 利用できるようにします ECサイトID: ログイン キャンセル taro@example.jp OK キャンセル ECサイトに登録してあるID情報を用いたパーソナライズや、 ECサイトのカート機能をパートナーに提供 パートナーサイト あなたへのおすすめ商品があります Powered by 「ECサイト」 •… カートに入れる •… カートに入れる •… カートに入れる パートナーサイトから出ることなく、ECサイトの ECサイト内での行動履歴を元に パートナーが開発した個別デバイス 商品情報とショッピングカートにアクセス パートナー提携ショップでの体験を最適化 向けアプリケーションに情報を提供 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 33
    • 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. 34
    • 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, … その他多数 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 35
    • OpenIDとOAuthの組み合わせOpenID は意外と実装が難しい 鍵交換や署名の付与・検証を自力で実装することは比較的難易度が高い これらの処理を行うライブラリは多数あるが、環境によっては組み込みが 難しいOAuth は単純には認証に使えない トークンはAPIアクセスのためであり、認証結果としては利用できない API の権限設定が粗いと、トークンが必要以上の権限を持つ 悪意のあるユーザ、サイトによって、権限の乱用や他人に成り済ましたトー クン利用が可能となるOpenID と OAuth を組み合わせる仕様 (OpenID/OAuth Hybrid) も考案されているが… 仕様がドラフトのままアップデートされていない ▪ OAuth は1.0プロトコルベース 両プロトコルをそれぞれ実装する手間がかかる Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 36
    • OpenID Connect 37
    • 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. 38
    • OpenID Connectの系図 Source: http://civics.com/openid-connect-webinar/ Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 39
    • 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. 40
    • 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. 41
    • OpenID Connectの特徴 エンド API API ユーザー クライアント プロバイダー エンドユーザーの OAuth2.0 ベースによる、トークンを利用 ID/パスワード した全体的なフロー サービスにアクセス ・OAuth2.0 に対応済みであれば、一部 認可要求 の拡張で OpenID Connect に対応可能 APIプロバイダーに「特定のサービスに アクセスするためのトークン」を要求 認証・同意 OAuth の認証では不十分だった、認 証コンテキスト(いつ、誰が、誰を認証 認可応答 したのか等)を「ID トークン」として提供 認可コードをAPIクライアントに返却 アクセストークン要求・応答 (認可コードとアクセストークンを 引換え/IDトークンの返却) 属性提供を行う UserInfo API が規定さ れ、API アクセスの標準ルールが策定 UserInfo要求・応答 アクセストークンによる API呼出/応答 サービスを提供 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 42
    • 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. 43
    • 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. 44
    • 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. 45
    • 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. 46
    • 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. 47
    • OpenID Connect のユースケース4. UserInfoエンドポイントの外部にあるクレームの取得UserInfoから提供する外部のクレームとして、「集約 (aggregated)クレーム」と「分散(distributed)クレーム」を 規定集約(aggregated)クレーム UserInfoエンドポイントから提供されるクレームの中に、外部 クレームの「実体」が含まれる ▪ その「実体」はJWT形式に変換して含まれることにより、他のクレームと 区別される分散(distributed)クレーム UserInfoエンドポイントから提供されるクレームの中に、外部 クレームを取得するための情報が含まれる ▪ 場合によっては、取得するための情報としてアクセス・トークンが指定 されている Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 48
    • 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. 49
    • 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. 50
    • OpenID Connect のユースケース7. セッション管理OpenID Connect Session Management OpenIDプロバイダ(認可サーバー)におけるユーザーのログイン/ロ グアウトの状況を、OpenIDリライング・パーティ(サードパーティ)が 継続的にモニターする仕組みを定義 OP/RPの通信にiframeを利用 Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 51
    • 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. 52
    • まとめIDフェデレーションを活用したサービス は、コンシューマー/エンタープライズ/ 公共/文教を問わず、多方面に普及 しつつあるこれまでID連携はSSO/属性流通の ためという側面が強かったが、近年、 APIアクセス認可の基盤としての活用 が増えているSAML、OpenID、OAuthを統一する 仕様としてOpenID Connectが注目 されている http://flic.kr/p/5iJp6M Copyright © 2012 Nomura Research Institute, Ltd. All Rights Reserved. 53