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

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

Page1
デジタル・アイデンティティ
OpenID概要
OpenID技術解説
見落としがちな仕様
将来へ向けての活動

View Slide

Page2
ディジタル・アイデンティティの現状
同じような
認証プログラムをいくつも開発
高度認証の実施は
コスト大
毎度同じような
データ交換処理
サービスを連携させ
るのが非常に大変
保有情報が正確ではない
ユーザが登録してくれない
ユーザに連絡がとれない
→猛烈に費用がかかる！
パスワードが多すぎて忘れてしまう
提供されるサービスは私の
ニーズに合わない
カードが多すぎる
セキュリティトークンが多すぎる
どこに情報があるか分からない
自分の状況が
分からない
フィッシングが心配
私の情報なのに私が見られない
今のネットの世界は、「ベンダーセントリック」
 「私」は一人なのに、サービスごと切り取られた無数の「私」がいる
 切り取られた「私」の情報は、「私」が許可しても決して見ることが出来ない
 「私」の情報を利用したサービスを受けるため、仕方なく様々なID/PWを使う
公的個人認証局
認
証
データ
交換
免許証の番号は
0123456です
認
証
データ
交換
○○省
本籍は沖縄です。
金融
認
証
データ
交換
残高は100万円です。
カード番号はXXXで、
期限はYY/ZZです。
物販会社
認
証
データ
交換
住所は、東京都港区
東新橋1-9-1です
SNS
○○大学卒業です。
洋楽に興味があります。
携帯は090-xxxx-xxxx
認
証
データ
交換

View Slide

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

View Slide

Page4
OpenID概要
OpenID技術解説

View Slide

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

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

View Slide

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

View Slide

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

Page9
OpenID概要
OpenID技術解説

View Slide

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

View Slide

Page11
認証フローの概要
------
Password
OpenID =katsu
認証キャンセル
この画像は表示できません。
ＯＰ
ユーザーの認証要求
(ブラウザリダイレクト
で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
ＲＰ

View Slide

Page12
① OpenID入力
② Discovery
③ アソシエーション確立
④ 認証要求をOPへ送信
⑥ パスワード入力
⑤ Discovery on the RP
⑧ Discovery
⑨ 署名の検証
⑦ 認証応答をRPへ送信
ログイン完了
あなた RP OP
シーケンス図

View Slide

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

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

Page15
Yadis
Discovery
② Discoveryイメージ
ＲＰ
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の
XRDS
XRDS
XRI Resolution
※HTTPバインディングに加え、
HTTPS/SAMLバインディングの
Secure Resolutionもある
XRDS
Level2の
XRDS
Level3の
XRDS
HTML-based
Discovery
Discover情報提供ページ
HTML

View Slide

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

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

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

View Slide

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
③アソシエーション確立要求と応答
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

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

View Slide

Page21
RP
http://example.com
OP
④認証要求
⑦認証応答
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

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

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

View Slide

Page24
RP
http://example.com
OP
④認証要求
⑦認証応答
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

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

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

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情報
RPにとって既知でない
(verified)claimed_idが返る
⑧Discovery
on the claimed_id
⑤Discovery
on the RP

View Slide

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

Page29
POST http://openidenabled.com/ruby-openid/trunk/examples/server
openid.mode=check_authentication
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
（⑨署名の検証）
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

Page30
OpenID概要
OpenID技術解説

View Slide

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

Page32
“http://hoge.com/alice”を入力 “http://hoge.com/alice”を入力
過去のユーザー現在のユーザー
alice#0001へサービス提供 alice#0002へサービス提供
ＲＰ
ＯＰ
サービスを受けるユーザーは
別でも、同じOpenID
を利用できるようになる
alice#0002
alice#0001
“alice#0001”のパスワードを入力 “alice#0002”のパスワードを入力
(Verified)Claimed Identifier

View Slide

Page33
再利用問題は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

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

View Slide

Page35
3/3. Unsolicited positive assertionとは
OPから一方的にRPへ送りつけられるpositive
assertionのこと
試しに、正常な認証アサーション応答を、RPへ一方
的に送付(デモ)
ＲＰＯＰ
Positive Assertion
リクエストしていないのに
いきなりメッセージが来た!
正しい認証結果を
返却
openid.mode=id_res
openid.claimed_id=(Verified)Claimed Identifier
・・・

View Slide

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
ＲＰＯＰ
ＲＰＯＰ
ＲＰ
ＯＰ
ＲＰ

View Slide

Page37
OpenID概要
OpenID技術解説

View Slide

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

Page39
⑦認証応答
④認証要求
RP
http://example.com
OP
http://sample-op.com
Discovery情報
⑤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
2007/06/multi-factor
2007/06/multi-factor-physical
http://example.com/server

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

View Slide

Page40
OpenID Tech Night Vol.3
OpenID周辺
最近のセキュリティ・トピックス
第2部

View Slide

Page41
最近のセキュリティ・トピックスといえば・・・
DNS Cache Poisoning
×

View Slide

Page42
OpenID Protocol
RP
GOOD
OP
User
BAD
OP
XRDS

View Slide

Page43
DNS Cache Poisoning @ RP
GOOD
OP
User
BAD
OP
XRDS
RP

View Slide

Page44
Can even attack the resolution
GOOD
OP
User
BAD
OP
XRDS
RP

View Slide

Page45
If it were https OpenID (or XRI)
GOOD
OP
User
BAD
OP
XRDS
アソシエーション
証明書チェック
失敗
RP

View Slide

Page46
GOOD
OP
User
BAD
OP
XRDS
RP
シグネチャ
チェック
失敗

View Slide

Page47
DNS Cache Poisoning @ Client
GOOD
OP
User
BAD
OP
XRDS
RP

View Slide

Page48
GOOD
OP
User
BAD
OP
XRDS
RP
証明書
チェック
失敗

View Slide

Page49
安全なサービス提供のためにRPができること
https URI ないしは、XRIのみを使う
XRIはTrusted Resolutionを使う
https binding でも SAML binding でも良い
OPの証明書ルートチェックは必ず行う
信頼できるルート以外は使わない

View Slide

Page50
OpenID仕様に関するセキュリティトピックス
OpenID PAPE 1.0 Draft 3
×

View Slide

Page51
PAPEとは？
エンドユーザの認証方法について、
RPがOPにリクエストをする方法を提供
Phishing-Resistant Authentication
Multi-Factor Authentication
Physical Multi-Factor Authentication
Auth_Level
OPがRPに対して、一方的に認証アサーション
の品質について通知する方法も提供

View Slide

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

Page53
おわりに
今後ともOpenIDを宜しくお願いいたします

View Slide

Page54

View Slide

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

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

勝原達也(Tatsuya Katsuhara)

More Decks by 勝原達也(Tatsuya Katsuhara)

Other Decks in Technology

Featured

Transcript