Upgrade to Pro — share decks privately, control downloads, hide ads and more …

OpenID 2.0 Specification (OpenID TechNight Vol.3資料)

OpenID 2.0 Specification (OpenID TechNight Vol.3資料)

OpenID 2.0 Specificationについて2008年開催のOpenID TechNight Vol.1-3あたりで利用していた資料です。OpenID Foundation Japanも無事に10周年を迎えたとのことで、OIDFJ設立準備室として黎明期に活動していた際に作成し、OpenID Technight Vol.1-3にて利用していた資料を改めて掘り起こして掲載しました。ID/フェデレーション/認証技術のプロフェッショナルと知り合うきっかけにもなった思い出深い資料です。

More Decks by 勝原達也(Tatsuya Katsuhara)

Other Decks in Technology

Transcript

  1. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page0
    OpenID Tech Night Vol.3
    OpenID Authentication 2.0
    ~Specification Overview~
    OpenIDファウンデーション・ジャパン準備事務局
    日付 2008/08/01(Fri)
    時間 18:30~19:30
    場所 ソフトバンクBB株式会社 東京汐留ビルディング9F
    研修会場(キャンパス) クラスルーム9

    View Slide

  2. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page1
    デジタル・アイデンティティ
    OpenID概要
    OpenID技術解説
    見落としがちな仕様
    将来へ向けての活動

    View Slide

  3. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page2
    ディジタル・アイデンティティの現状
    同じような
    認証プログラムをいくつも開発
    高度認証の実施は
    コスト大
    毎度同じような
    データ交換処理
    サービスを連携させ
    るのが非常に大変
    保有情報が正確ではない
    ユーザが登録してくれない
    ユーザに連絡がとれない
    →猛烈に費用がかかる!
    パスワードが多すぎて忘れてしまう
    提供されるサービスは私の
    ニーズに合わない
    カードが多すぎる
    セキュリティトークンが多すぎる
    どこに情報があるか分からない
    自分の状況が
    分からない
    フィッシングが心配
    私の情報なのに私が見られない
    今のネットの世界は、「ベンダーセントリック」
     「私」は一人なのに、サービスごと切り取られた無数の「私」がいる
     切り取られた「私」の情報は、「私」が許可しても決して見ることが出来ない
     「私」の情報を利用したサービスを受けるため、仕方なく様々なID/PWを使う
    公的個人認証局


    データ
    交換
    免許証の番号は
    0123456です


    データ
    交換
    ○○省
    本籍は沖縄です。
    金融


    データ
    交換
    残高は100万円です。
    カード番号はXXXで、
    期限はYY/ZZです。
    物販会社


    データ
    交換
    住所は、東京都港区
    東新橋1-9-1です
    SNS
    ○○大学卒業です。
    洋楽に興味があります。
    携帯は090-xxxx-xxxx


    データ
    交換

    View Slide

  4. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page3
    ベンダーセントリックから、ユーザーセントリックへ
    ネット上の「私」を取り戻すためのパラダイムシフト
    ベンダーセントリックからユーザーセントリックへ
    SNS 公的個人認証局
    金融
    物販会社
    ○○省
    これからは「ユーザーセントリック」
     「私」の情報は、「私」のもの
     「私」の情報は、「私」が管理する
     「私」の情報は、いつ、誰に、何の目的で、どの内容を提供したか常に把握する
    情報提供・変更の指示
    統合表示・履歴管理
    提供
    要求
    提供
    要求
    提供
    「私」情報ハブ
    要求
    属性情報
    集約
    属性情報
    提供
    高度認証
    サーバー
    ○○大学卒業です。
    洋楽に興味があります。
    携帯は090-xxxx-xxxxです。
    免許証の番号は0123456です。
    本籍は沖縄です。
    住所は、東京都港区東新橋1-9-1です。
    預金残高は100万円です。
    カード番号はXXXで、期限はYY/ZZです。

    View Slide

  5. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page4
    デジタル・アイデンティティ
    OpenID概要
    OpenID技術解説
    見落としがちな仕様
    将来へ向けての活動

    View Slide

  6. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page5
    ユーザーセントリックを実現する有力技術
    インターネットでSSO(Single Sign On)を実現するための規格
    「普段自分が使うID」で、複数のウェブサービスにログインできるようにする
    中央集権的なIDサーバは存在せず、自分で「私」の情報を管理するOPを選ぶ
    RPは自身の発行するIDの利用を強制せず、OpenIDを受け入れる
    Relying Party(RP)
    OpenID対応サイト
    へログイン
    コミュニティサイトもRP
    ECサイトもRP
    ブログもRP
    OpenID Identity Provider(OP)
    OpenID認証提供サイト
    企業サイトもRP
    OpenID

    View Slide

  7. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page6
    OpenIDを利用したログインの流れ
    必要な時に、必要なだけ、ユーザーの許諾に基づいた、属性情報(名前、
    住所、TEL etc…)を、RPへ提供することができる
    複数IDを覚える必要や、新たな個人情報の登録など、面倒な手続きを省
    くことができる
    いつ、誰に、どの属性情報を提供したかをOPにて確認することができる
    認証+パーミッションベースの属性情報提供
    ○○さん こんにちは
    ****
    Password
    OpenID =katsu
    サイト:http://www.xxx.jpからの
    認証リクエストです。
    認証 キャンセル はい いいえ
    サイト:http://www.xxx.jpが
    以下の情報を求めています
    ・ 住所、氏名
    ・ 使用期間 20XX/12/31
    情報提供を許可しますか?
    今回のみ
    RPサイトへ
    アクセス
    OP認証画面
    を表示
    属性提供の
    承諾画面を表示
    RPサイトに
    ログイン完了
    ログイン完了
    認証依存サイトに情報を
    提供するなら「はい」
    本人のOpenIDを入力 パスワードの入力
    OpenID
    RP OP RP

    View Slide

  8. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page7
    古典的な認証・属性情報管理との相違点
    Webサイトは、常に同じような認証を行い、個人情報を登録・管理
     セキュリティーの脅威
     必要以上の個人情報を保持
    認証+属性情報の目的の本質は、サービスを提供するユーザーを特定し、
    適切なサービスを提供すること
     高い信頼性のおけるサイトによる認証代行
     サービスに必要最低限の(新鮮な)情報の都度提供
    OpenIDに対応
    していないサイト
    サイト毎に別々の
    ID/PWを入力
    サイト数だけの
    個人情報
    住所・氏名
    メールアドレス
    ID・パスワード
    カード番号
    認証依頼
    認証結果
    パスワード入力
    OP
    RP
    認証依頼
    認証結果
    RP
    住所・氏名
    メールアドレス
    「私」のID・パスワード
    カード番号
    メールアドレス
    「私」のID
    住所・氏名
    メールアドレス
    「私」のID
    カード番号
    メールアドレス
    「私」のID
    住所・氏名
    カード番号
    メールアドレス
    「私」のID
    「私」のIDを入力

    View Slide

  9. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page8
    OpenIDの歩み
    2000年代初頭から、ウェブ上のID・パスワード管理への問題意識はあった
    米Microsoftが、PassportにIDを中央集権的に統合する仕組みを提示
    Sunらが分散型の認証連携のための Liberty Allianceを立ち上げ、SAML規格を
    生む
    2005年頃、米SixApart社のDavid RecordonらによってOpenIDが提唱
    OpenID Foundationの設立
     2007/6に、規格の制定・知財の管理団体(米国非営利法人)として誕生
     理事企業: Google, IBM, Microsoft, SixApart, Verisign
    爆発的な普及
     2008/1に米Yahoo!がOpenIDを提供開始。OpenIDユーザは3億7000万へ
     2008/7に米MySpaceがOpenIDを提供開始。OpenIDユーザは5億を突破!
    OpenID ファウンデーション・ジャパン(仮称)設立活動
    2008/2 にOpenID Foundationの日本支部の立ち上げを目指した活動を開始
    発起人 シックス・アパート株式会社、日本ベリサイン株式会社、株式会社野村総合研究所
    参加表明企業 株式会社アセントネットワークス、株式会社イーコンテクスト、インフォテリア株式会社、
    株式会社テクノラティジャパン、ニフティ株式会社、株式会社ミクシィ、ヤフー株式会社、
    株式会社ライブドアなど約25社 (五十音順、2008年2月27日時点)

    View Slide

  10. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page9
    デジタル・アイデンティティ
    OpenID概要
    OpenID技術解説
    見落としがちな仕様
    将来へ向けての活動

    View Slide

  11. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page10
    OpenIDの特徴
    HTTP/HTTPS上で実現される、Simple&Light weightな認証
    プロトコル
    OpenIDは、入力されたIdentifierから認証サーバの場所を知る
     RPは入力IDの認証を、どのOPが行うかを動的に解決する
    事前信頼関係を必要としない、オープンな認証アーキテクチャ
     世の中の全てのRPとOPが連携可能
    Sun, NTT, Intel, Oracle
    AOL, BT, France Telecom

    View Slide

  12. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page11
    認証フローの概要
    ------
    Password
    OpenID =katsu
    認証 キャンセル
    この画像は表示できません。
    OP
    ユーザーの認証要求
    (ブラウザリダイレクト
    でOPへ)
    認証結果を署名してRPへ
    (ブラウザリダイレクト)
    1
    4
    7
    6
    3
    9
    ユーザー認証
    (OpenIDの規格外)
    RPへアクセスして
    ID(XRI/URL)を入力
    Discovery情報
    提供サイト(URL)
    2
    5
    XRI Authority(XRI)
    8
    署名鍵を交換
    (キャッシュ可能)
    RPのRealmに
    Discovery行い、
    正当性を検証
    OPに署名の代理
    検証を依頼
    (特定ケース)
    OP Endpoint
    URLを得るため
    Discovery実施
    不足情報を補うため
    Discovery実施
    (特定ケース)
    ① ユーザーはRPでOpenIDを入力する
    ② RPは入力IDを元にDiscoveryを行い、OP の
    を取得する
    ③ RP/OP間で署名用の鍵交換を実施する
    (キャッシュされていれば省略)
    ④ ユーザーのブラウザをOPの認証画面へリダ
    イレクトする
    ⑤ RPの正当性を確かめるため、OPはRPの
    Realmに対してDiscoveryを行う
    ⑥ ユーザーはOPでパスワードを入力し、認証を
    受ける
    ⑦ 認証提供サイトはブラウザリダイレクトを利
    用して署名した認証結果を認証依存サイト
    へ送る
    ⑧ 結果検証のために不足している情報があれ
    ば、Discoveryを行う(特定ケースのみ)
    ⑨ RPが署名検証に失敗した場合、OPに対し
    て代理検証を依頼する(特定ケースのみ)
    ユーザー操作
    間接通信
    直接通信
    Discovery
    RP

    View Slide

  13. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page12
    ① OpenID入力
    ② Discovery
    ③ アソシエーション確立
    ④ 認証要求をOPへ送信
    ⑥ パスワード入力
    ⑤ Discovery on the RP
    ⑧ Discovery
    ⑨ 署名の検証
    ⑦ 認証応答をRPへ送信
    ログイン完了
    あなた RP OP
    シーケンス図

    View Slide

  14. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page13
    OpenIDのID体系
    OpenID 2.0のID体系
     XRI (eXtensible Resource Identifier)
     XML関連の国際標準化団体OASIS Openにより策定
     空間的に一意(reassignable)なi-nameと、時間的に一意
    (persistence)なi-numberのマッピング
    例) xri://=nat、=katsu、@nri/employee/id7777 etc…
     URI
     通常のOpenID(OPの場所+ユーザー情報)
    http://alice.pip.verisignlabs.com, myopenid.com/bob
     OP Identifier(Directed Identity)
    http://yahoo.co.jp/, livedoor.com

    View Slide

  15. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page14
    OpenIDのID体系
    入力Identifierから認証サーバの場所を知る(Discovery)
     入力されたIDに応じて、3種類の方法がある
    1. XRI  XRI Resolution
     入力XRIから動的に認証プロバイダを特定する、DNSライクな名前解決
     認証に必要な情報が記述されたXRDS(XML)を得る
     XRDSからOP位置・対応サービスなどの情報を取得する
    2. URI  Yadis Protocol
     IDがURIの場合、そのURIからXRDS位置または本体の取得を試みる
     URIが指し示すHTMLに含まれるMETA情報からXRDS位置を得ることもで
    きる
    3. URI  HTML based
     URIが指し示すHTMLに含まれるLINK情報からOPの場所を特定

    View Slide

  16. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page15
    Yadis
    Discovery
    ② Discoveryイメージ
    RP
    XRDS提供サーバ
    Top Level XRI Authority
    XRI Proxyリゾルバ
    Level-2 XRI Authority
    Level-n XRI Authority
    XRDS位置提供サーバ
    HTTP
    X-XRDS-Location
    HTML
    META情報
    XRDS
    XRDS
    Level2の
    XRI Authorityの場所
    XRDS
    Level3の
    XRI Authorityの場所
    XRDS
    XRDS
    XRI Resolution
    ※HTTPバインディングに加え、
    HTTPS/SAMLバインディングの
    Secure Resolutionもある
    XRDS
    Level2の
    XRI Authorityの場所
    XRDS
    Level3の
    XRI Authorityの場所
    XRDS
    HTML-based
    Discovery
    Discover情報提供ページ
    HTML


    View Slide

  17. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page16
    Claimed Identifier(≒User-supplied Identifier)
     これを認証することがプロトコルの大きな目的
     http://openidenabled.com/ruby-openid/trunk/examples/user/alice
    OP Endpoint URL
     全てのOpenID認証サービスを受け付けるURL
     複数Endpoint URLを記述し、負荷分散やサービスセレクショ
    ンも可能
    Supported Services
     OP Endpoint URLが対応するサービス
     http://specs.openid.net/auth/2.0/signon
     http://openid.net/signon/1.0
     http://openid.net/sreg/1.0 etc...
    ② Discoveryで得る情報

    View Slide

  18. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page17
    ② Discovery(例)
    http://example.com
    http://openidenabled.com
    Discovery情報
    提供サイト
    (OPと同じでも良い)
    RP
    あなた
    Content-Type: application/xrds+xml




    http://specs.openid.net/auth/2.0/signon
    http://openid.net/signon/1.0
    http://openid.net/sreg/1.0
    http://openidenabled.com/ruby-openid/trunk/examples/server



    GET http://openidenabled.com/ruby-openid/trunk/examples/user/alice
    ①OpenIDの入力
    ②Discovery
    OP Endpoint URL
    対応するOpenIDバージョン
    XRDS文書

    View Slide

  19. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page18
    ③ アソシエーションの確立
    署名用の鍵を交換するためのフェーズ(キャッシュ可)
     Association handleが署名鍵に紐付くキーに
    Diffie-Hellmanアルゴリズムに基づく鍵交換
     DHセッション鍵にて署名鍵を暗号化して交換
     HMAC-SHA1用の160ビット鍵
     HMAC-SHA256用の256ビット鍵
     強衝突性が突破されているSHA1は、将来的にSHA-256移行が
    推奨
    アソシエーションは、適切な時間で再構成するのが望
    ましい
     常に同じアソシエーションだと、ハッシュが破られ署名鍵が
    判明するかもしれない
    pubdh=2 mod p
    s

    View Slide

  20. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page19
    POST http://openidenabled.com/ruby-openid/trunk/examples/server
    openid.assoc_type : HMAC-SHA1
    openid.dh_consumer_public : AKKgaoVMR+…C0SfzNEV7
    openid.mode : associate
    openid.ns : http://specs.openid.net/auth/2.0
    openid.session_type : DH-SHA1
    RP
    http://example.com
    OP
    http://openidenabled.com
    ③アソシエーション確立要求と応答
    assoc_handle : {HMAC-SHA1}{480c4fb1}{8T4/PQ==}
    assoc_type : HMAC-SHA1
    dh_server_public : dFCaxM5Baq...VeLwSgQ8=
    enc_mac_key : jfVVSOLHm1MtyJTzZzL07oybK6g=
    expires_in : 1209600
    ns : http://specs.openid.net/auth/2.0
    session_type : DH-SHA1
    ※鍵がキャッシュされていれば、実施しない
    ③ アソシエーションの確立例
    OP Endpoint
    OpenID動作モード
    セッション鍵で暗号化された署
    名検証の共有鍵
    共有鍵の識別子
    直接通信は
    常にPOST
    有効期限

    View Slide

  21. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page20
    ④認証要求と⑦認証応答
    ブラウザリダイレクトで、認証メッセージを送受信
     HTTP Redirectでも、Form Redirectionでも好きな方を
     要求・応答で同じメソッドを利用する
     Ajaxと組み合わせた非同期認証 (checkid_immediate
    モード)
    OPが払い出したnonceで再生攻撃防止
     RPは応答中のnonceを適切な期間保持、再生攻撃を防ぐ
     nonceを変更しただけのメッセージは署名検証で弾かれる
     RPからの署名検証要求に備え、OPは払い出したnonceを
    適切な期間重複しないように管理しなければならない
    応答メッセージはアソシエーションの共有鍵で署名済

    View Slide

  22. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page21
    RP
    http://example.com
    OP
    http://openidenabled.com
    ④認証要求
    ⑦認証応答
    HTTP/1.1 302 Found  GET http://example.com/consumer/complete
    openid.mode=id_res
    openid.ns=http://specs.openid.net/auth/2.0
    openid.assoc_handle={HMAC-SHA1}{480c4fb1}{8T4/PQ==}
    openid.claimed_id=http://openidenabled.com/ruby-openid/trunk/examples/user/alice
    openid.identity=http://openidenabled.com/ruby-openid/trunk/examples/user/alice
    openid.op_endpoint=http://openidenabled.com/ruby-openid/trunk/examples/server
    openid.response_nonce=2008-04-21T08:26:33ZqRenZa
    openid.return_to=http://example.com/consumer/complete
    openid.sig=VM+4kf9l8SGF/nbdWzL47rt4yA0=
    openid.signed=assoc_handle,claimed_id,identity,mode,ns,op_endpoint,response_nonce,return_to,signed
    HTTP/1.1 302 Found  POST http://openidenabled.com/ruby-openid/trunk/examples/server
    openid.mode : checkid_setup
    openid.ns : http://specs.openid.net/auth/2.0
    openid.assoc_handle : {HMAC-SHA1}{480c4fb1}{8T4/PQ==}
    openid.claimed_id : http://openidenabled.com/ruby-openid/trunk/examples/user/alice
    openid.identity : http://openidenabled.com/ruby-openid/trunk/examples/user/alice
    openid.realm : http://example.com/consumer
    openid.return_to : http://example.com/consumer/complete
    ④認証要求と⑦認証応答
    HTTP Redirect
    Form Redirection
    ⑤Discovery
    on the RP
    ⑥パスワードの入力
    OPが認証するID
    Claimed Identifier
    認証応答の戻り先
    対応OpenIDバージョン
    認証失敗時は、cancelまたはsetup_neededの場合もある
    要求時と同じメソッド
    checkid_immediateを利用した非同期認証も可能
    リプレイアタック対策
    署名構成フィールド
    OPが認証したID
    (Verified)Claimed Identifier

    View Slide

  23. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page22
    ⑤ Discovery on the RP
    認証要求で指定されるRealmに対してYadisプロトコルで
    Discoveryを行う(XRDS文書の取得)
    認証メッセージの応答先である”return_to” URLが、OpenIDの
    認証結果を返すEndpointとして妥当であることを確認
     同時に、SSL状態(自己署名かEV-SSLか等)を確認できる(かも)
     任意のURLへ認証結果や属性情報を送られることを防ぐ
    Authentication 2.0 Finalで追加された仕様で、利用している
    OPは少ない
     うまく使うと、RPの信頼性についてユーザーへ警告を出すことができる
     RPがXRDSを返却する機能が必要になる
     動的に戻りURLが変化する場合はさらに作り込みが必要

    View Slide

  24. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page23
    ⑤ Discovery on the RP(例)
    RP Discovery失敗は
    出現のトリガらしい
    ※RPのIP、EV-SSL対応、
    ドメインなど複数の挙動に
    従って警告を出すような実装は可能

    View Slide

  25. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page24
    RP
    http://example.com
    OP
    http://openidenabled.com
    ④認証要求
    ⑦認証応答
    HTTP/1.1 302 Found  POST http://openidenabled.com/ruby-openid/trunk/examples/server
    openid.mode : checkid_setup
    openid.realm : http://example.com/consumer
    openid.return_to : http://example.com/consumer/complete
    ⑤ Discovery on the RP(例)
    (⑤Discovery on the RP)
    ⑥パスワードの入力
    GET http://example.com/consumer
    Content-Type: application/xrds+xml




    http://specs.openid.net/auth/2.0/return_to
    http://example.com/consumer/complete



    2値を突きあわせて正しさを検証

    View Slide

  26. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page25
    ⑧ 認証結果の検証
    署名検証内容の一覧
    検証項目 RPにとって既知の情報 OPからの認証応答 検証法
    Claimed Identifier claimed_id claimed_id(verified) 単純比較(フラグメント除く)
    OP-Local Identifier identity Identity(verified) 単純比較
    OP Endpoint URL メッセージ送信先 op_endpoint 単純比較
    Protocol Version ns ns 単純比較
    Return to URL return_to return_to 認証応答を実際に処理しているURLと
    OP値を比較(query込み)
    Nonce Check 過去Nonce値ストア response_nonce Nonceの重複チェック
    Association &
    Signature
    assoc_handleと紐づく署名
    key
    assoc_handle
    sig
    signed
    認証応答のassoc_handleが紐づく署
    名keyで、signed値のフィールドを連結
    した文字列から署名を作成する
    結果sig値と比較する
    OPからの認証応答を検証する必要がある
    検証が成功してはじめて、RPは認証成功と解釈する

    View Slide

  27. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page26
    ⑧ 認証結果検証時のDiscovery
    認証要求と応答で”claimed_id”値が異なると動作
     Claimed Identifierに対応するユーザーを検証するための
    情報を、RPがまだ十分に保有していない状態
     (Verified)Claimed Identifierに対してDiscovery
     OP Identifierを利用した場合(Directed Identity)
     認証要求と応答で”claimed_id”値が異なる
    要求:http ://specs.openid.net/auth/2.0/identifier_select
    応答:ユーザーを特定する形式のOpenID
     一方的にOPから認証結果が送られてきた場合

    View Slide

  28. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page27
    ⑦認証応答
    openid.mode=id_res
    openid.claimed_id=http://sample-op.com/bob/
    openid.identity=http://sample-op.com/bob/
    GET/POST http://sample-op.com/openid/endpoint
    openid.mode=checkid_setup
    openid.claimed_id=http://specs.openid.net/auth/2.0/identifier_select
    openid.identity=http://specs.openid.net/auth/2.0/identifier_select
    ⑧ 結果検証時のDiscovery(例)
    ④認証要求
    RP
    http://example.com
    OP
    http://sample-op.com
    認証応答に含まれる”(verified)claimed_id”をDiscovery
    した結果を踏まえて、認証結果の検証を実施する
    HTTP 302(Redirect)
    JavaScript自動POST
    ⑥パスワードの入力
    Discovery情報
    提供サイト(URL)
    RPにとって既知でない
    (verified)claimed_idが返る
    ⑧Discovery
    on the claimed_id
    ⑤Discovery
    on the RP

    View Slide

  29. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page28
    ⑨ OPによる署名の直接検証
    アソシエーション再確立による整合性の維持(参考)
    ケース 整合性を取るためのフロー
    RPがアソシエーションを喪
    失した
    1. 通常通りアソシエーション確立要求を実施する
    2. OPは確立応答を返し、同時に当該RPとのアソシエーションを更新する
    OPがアソシエーションを破
    損・喪失した、もしくはRP
    のアソシエーションが破損
    した
    1. OPにとって、認証リクエスト中の”assoc_handle”は不正な値に見えるので、テンポ
    ラリの”assoc_handle”値を払い出す
    2. テンポラリの”assoc_handle”値に紐付く鍵は存在しないので、RPでの署名検証は
    失敗し、直接通信で署名検証が行われる
    3. RPは検証応答中の”invalid_handle”に紐付くアソシエーションを破棄(する実装)
    4. RPは次回に通常のアソシエーション確立を行い、RP-OP間で整合性のとれた状態
    となる
    アソシエーションに不整合が生じている場合、RPは署名検証
    に失敗するので、OPに直接検証を依頼する
     透過的にアソシエーションの整合性を取る仕組みを備える必要がある
    「不正な”assoc_handle”」=「OPが知らない”assoc_handle”」

    View Slide

  30. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page29
    POST http://openidenabled.com/ruby-openid/trunk/examples/server
    openid.mode=check_authentication
    openid.ns=http://specs.openid.net/auth/2.0
    openid.assoc_handle={HMAC-SHA1}{480c50f2}{iqK58w==}
    openid.claimed_id=http://openidenabled.com/ruby-openid/trunk/examples/user/me
    openid.identity=http://openidenabled.com/ruby-openid/trunk/examples/user/me
    openid.invalidate_handle={HMAC-SHA1}{59ad50c2}{9T5/PQ==}
    openid.op_endpoint=http://openidenabled.com/ruby-openid/trunk/examples/server
    openid.response_nonce=2008-0421T08:31:46ZDZbNaH
    openid.return_to=http://example.com/consumer/complete
    openid.sig=ASYAWxoGTTuNbwhrhttEkdC9HjQ=
    openid.signed=assoc_handle,claimed_id,identity,invalidate_handle,mode,ns,op_endpoint,response_nonce,return_to,signed
    RP
    http://example.com
    OP
    http://openidenabled.com
    (⑨署名の検証)
    invalidate_handle:{HMAC-SHA1}{59ad50c2}{9T5/PQ==}
    is_valid:true
    ns:http://specs.openid.net/auth/2.0
    ※不正なassoc_handleで認証要求すると、OPはテンポラリassoc_handleを払い出す
    テンポラリassoc_handleを知らないRPは署名検証できず、OPに検証を要求する
    ⑨ OPによる署名の代理検証(例)
    テンポラリで払い出したassoc_handle
    認証要求に含まれた
    不正なassoc_handle
    OPが署名を直接
    検証し、成功した

    View Slide

  31. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page30
    デジタル・アイデンティティ
    OpenID概要
    OpenID技術解説
    見落としがちな仕様
    将来へ向けての活動

    View Slide

  32. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page31
    1/3. OpenID再利用問題
    OpenIDは再利用される可能性がある
    ~ユーザーがフォームに入力するOpenIDのリサイクル~
     過去ユーザーに対応するRPアカウントに、別人がログインできてしまう!
     前ユーザーが退会して、別ユーザーに再割り当てされる場合
     ドメインが別の所有者に再割り当てされた場合
    OPは、OpenIDユーザーの変遷を管理しなければならない
     フラグメントで識別できる管理をする
     http://example.com/alice#0002
     ユーザーが入力するOpenIDは同じでも、(Verified)Claimed Identifier
    としてはフラグメント付きのものを返却する
     ある時点での“alice → alice#0002”というマッピングはOPだけが把握
     RPは(Verified)Claimed Identifierを記憶してアカウント管理をする

    View Slide

  33. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page32
    1/3. OpenID再利用問題
    “http://hoge.com/alice”を入力 “http://hoge.com/alice”を入力
    過去のユーザー 現在のユーザー
    alice#0001へサービス提供 alice#0002へサービス提供
    RP
    OP
    サービスを受けるユーザーは
    別でも、同じOpenID
    を利用できるようになる
    alice#0002
    alice#0001
    “alice#0001”のパスワードを入力 “alice#0002”のパスワードを入力
    (Verified)Claimed Identifier

    View Slide

  34. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page33
    1/3. OpenID再利用問題
    再利用問題はIDの一意性の欠如から生じる
     IDの一意性とは?
     空間的一意性(reassignable)
     URI(ドメインに基づく)
     i-name(XRI)
     時間的一意性(persistence)
     i-number(XRI)
    URIは空間的に一意なもの
     フラグメント利用による、時間的一意性の獲得
     ドメイン自体がreassignableであることに起因する問題の解決が必要
     ドメインの有効期限切れには注意する
     フラグメント値の複雑さで衝突を回避する(UUIDやハッシュ)
    XRIは時間的にも一意
     その時点では一意なi-nameを、時間軸を通して一意なi-numberにマッピング
     RPはClaimed Identifierとしてi-numberを記憶して、常にユーザーを一意に特定
    時間
    =!ABCD.1234
    Mapping
    http://hoge.com/alice#01
    http://hoge.com/alice#02
    http://hoge.com/alice
    =nat =sakimura

    View Slide

  35. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page34
    2/3. OpenIDではOP→RPの属性提供しかできない?
    「属性提供 on 応答メッセージ」方式ばかりが注目されるが・・・
     認証応答に、OP提供の属性をのせて返却
    拡張定義により、RP→OPも可能
     送りつけるだけなら、return_toを指定しなければ良い
     認証不要なら、claimed_id/identityすら省略できる
     使い道は十分に検討し尽くされていない
     RPからOPへのデータ更新
    他…
    RP OP
    リクエスト
    レスポンス+属性情報/任意パラメタ
    認証結果が欲しい
    データが送りたい
    レスポンス必要/不要
    「認証結果」や「受理結果」など
    リクエスト+属性情報/任意パラメタ
    レスポンス+属性情報/任意パラメタ 認証OK
    メッセージ受理
    レスポンスは必要?
    RP OP

    View Slide

  36. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page35
    3/3. Unsolicited positive assertionとは
    OPから一方的にRPへ送りつけられるpositive
    assertionのこと
    試しに、正常な認証アサーション応答を、RPへ一方
    的に送付(デモ)
    RP OP
    Positive Assertion
    リクエストしていないのに
    いきなりメッセージが来た!
    正しい認証結果を
    返却
    openid.mode=id_res
    openid.ns=http://specs.openid.net/auth/2.0
    openid.claimed_id=(Verified)Claimed Identifier
    ・・・

    View Slide

  37. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page36
    3/3. Unsolicited positive assertionとは
    使い道は?
     ポータル(OP)からの、各種RPへの一発ログイン
     OpenIDではできないと思われていたシングル・ログアウト
     Ajaxと組み合わせ など...
    広義のUnsolicitedメッセージの可能性!
     ユーザーインタラクションを必要としない、RP-OP間の各種通信
     RP属性が変化したことを通知するPing
     OPログアウトを合図に一斉に裏でSingle Log-Outを投げる など...
    ログイン完了!
    Ping
    Single Log-Out
    情報更新! 一斉にログオフ!
    Direct
    Direct
    RP OP
    RP OP
    RP
    OP
    RP

    View Slide

  38. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page37
    デジタル・アイデンティティ
    OpenID概要
    OpenID技術解説
    見落としがちな仕様
    将来へ向けての活動

    View Slide

  39. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page38
    仕様拡張
    Trusted Data Exchange
     既存の属性提供仕様AX、SREGの問題点
     属性情報の暗号化をHTTPSに依存
     極めて単純な提供要求とユーザー許可のもとの実施(非否認性がない)
     TXのコンセプト
     契約ベースの属性提供(非否認性がある)
     XML Encryption/XML Signatureによる暗号化・署名
     非同期な属性提供(非否認性を持った契約ベース)
     OIDF仕様ML&http://wiki.openid.net/Trusted_Data_Exchangeに提案済
    Reputation Service
     OPやRPの信頼性評価・提供基盤
     公開鍵を動的に配布するインフラストラクチャ
     ホワイトリスト方式を置き換え
    Provider Assertion Policy Extension
     認証強度をメッセージに載せるためのプロトコル
     各国の情報セキュリティ関連法に従うための拡張が必要
     バイオメトリクスやHWトークンといった高度認証との組合せ実証

    View Slide

  40. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page39
    ⑦認証応答
    ④認証要求
    RP
    http://example.com
    OP
    http://sample-op.com
    ⑥パスワードの入力
    Discovery情報
    提供サイト(URL)
    ⑤Discovery
    on the RP
    PAPEの概要と追加案
    PAPEメッセージ抜粋
    openid.ns.pape=http://specs.openid.net/extensions/pape/1.0
    openid.pape.max_auth_age=3600
    openid.pape.preferred_auth_policies=http://schemas.openid.net/pape/policies/2007/06/multi-factor
    PAPEメッセージ抜粋
    openid.ns.pape:http://specs.openid.net/extensions/pape/1.0
    openid.pape.auth_policies:
    http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical
    http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical
    openid.pape.auth_level.fisc:2
    openid.pape.auth_level.ns.fisc: http://www.fisc.or.jp/ex/authnlevel
    XRDS文書抜粋(OP Endpointのサービスタイプ)

    http://specs.openid.net/auth/2.0/signon
    http://openid.net/signon/1.0
    http://openid.net/sreg/1.0
    http://openid.net/pape/1.0
    http://schemas.openid.net/pape/policies/
    2007/06/phishing-resistant
    http://schemas.openid.net/pape/policies/
    2007/06/multi-factor
    http://schemas.openid.net/pape/policies/
    2007/06/multi-factor-physical
    http://example.com/server

    日本のFISCの認証レベルにマッピング
    該当ポリシでの認証の有効期間
    要求認証ポリシ
    複数の認証ポリシで認証可能

    View Slide

  41. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page40
    OpenID Tech Night Vol.3
    OpenID周辺
    最近のセキュリティ・トピックス
    第2部

    View Slide

  42. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page41
    最近のセキュリティ・トピックスといえば・・・
    DNS Cache Poisoning
    ×

    View Slide

  43. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page42
    OpenID Protocol
    RP
    GOOD
    OP
    User
    BAD
    OP
    XRDS

    View Slide

  44. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page43
    DNS Cache Poisoning @ RP
    GOOD
    OP
    User
    BAD
    OP
    XRDS
    RP

    View Slide

  45. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page44
    Can even attack the resolution
    GOOD
    OP
    User
    BAD
    OP
    XRDS
    RP

    View Slide

  46. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page45
    If it were https OpenID (or XRI)
    GOOD
    OP
    User
    BAD
    OP
    XRDS
    アソシエーション
    証明書チェック
    失敗
    RP

    View Slide

  47. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page46
    If it were https OpenID (or XRI)
    GOOD
    OP
    User
    BAD
    OP
    XRDS
    RP
    シグネチャ
    チェック
    失敗

    View Slide

  48. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page47
    DNS Cache Poisoning @ Client
    GOOD
    OP
    User
    BAD
    OP
    XRDS
    RP

    View Slide

  49. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page48
    If it were https OpenID (or XRI)
    GOOD
    OP
    User
    BAD
    OP
    XRDS
    RP
    証明書
    チェック
    失敗

    View Slide

  50. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page49
    安全なサービス提供のためにRPができること
    https URI ないしは、XRIのみを使う
    XRIはTrusted Resolutionを使う
    https binding でも SAML binding でも良い
    OPの証明書ルートチェックは必ず行う
    信頼できるルート以外は使わない

    View Slide

  51. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page50
    OpenID仕様に関するセキュリティトピックス
    OpenID PAPE 1.0 Draft 3
    ×

    View Slide

  52. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page51
    PAPEとは?
    エンドユーザの認証方法について、
    RPがOPにリクエストをする方法を提供
    Phishing-Resistant Authentication
    Multi-Factor Authentication
    Physical Multi-Factor Authentication
    Auth_Level
    OPがRPに対して、一方的に認証アサーション
    の品質について通知する方法も提供

    View Slide

  53. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page52
    PAPE 1.0 Draft 2 との差異
    auth_level に ns を導入
    openid.pape.nist_auth_level
    openid.pape.auth_level.ns.nist
    openid.pape.auth_level.nist
    表記法
    「pape」というのは、変数なのだが、誤解する人が
    多いので、変数は、のような表現に変更

    View Slide

  54. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page53
    おわりに
    今後ともOpenIDを宜しくお願いいたします

    View Slide

  55. Copyright(C) 2008 Nomura Research Institute, Ltd. All rights reserved.
    Page54

    View Slide