Open棟梁Project - マイクロソフト系技術情報 Wiki
目次  †
概要  †
OpenID対応について。
OpenID 1.1  †
End Userは自分のClaimed Identifierを認証するIdPを明示。  †
End Userは自分のClaimed Identifierを認証してくれるIdPを明示する。
Claimed IdentifierとIdPのエンドポイントURLが同一ホストにある場合  †
head要素の中にlink要素として、下記のように記載。
<link rel="openid.server"  href="IdPが提供するサーバのエンドポイントURL" />
e.g. : http://profile.hatena.ne.jp/h1romas4/
Claimed IdentifierとIdPのエンドポイントURLが同一ホストにない場合  †
head要素の中にlink要素として、下記のように記載。
これにより、Claimed Identifierの認証を外部のIdPサーバに委ねる事ができる。
<link rel="openid.server"  href="IdPが提供するサーバのエンドポイントURL" />
<link rel="openid.delegate"  href="Claimed Identifierとして使用するURL" />
e.g. : http://openid.maple4ever.net/hiromasa/
ConsumerサイトのOpenIDログイン・フォーム  †
Enter your OpenID URLなので、Claimed IdentifierのURLを入力する。
HTML  †
ブラウザのオートコンプリートを利用するため、 
OpenID URLのテキスト・フィールドはname属性値に
openid_urlと統一した名前を付けることが推奨されている。
<form id="openid_form"  action="./login.cgi" method="post">
  <fieldset>
    <legend>Enter your OpenID URL</legend>
    <input type="text" id="openid_url" ≪name="openid_url"≫ value="" />
    <input type="submit" id="openid_url_submit"  name="openid_url_submit" value="LOGIN" />
  </fieldset>
</form>
CSS  †
OpenIDのロゴを表示する。
input#openid_url {
   text-indent: 18px;
  background-image:  url("http://sample.openid-idp.com/img/openid_logo.png");
   background-repeat: no-repeat;
   background-position: left center;
}
処理シーケンス  †
処理シーケンスを、Consumerサイト上の処理を中心に説明する。
- OpenIDログイン・フォームにClaimed IdentifierのURLが入力される。
 
- Consumerは、"openid.server"と"openid.delegate"を参照する。
 
- 通常、smart modeを選択し、Claimed Identifierの認証手続きを行う。
 
- ConsumerはEnd UserのUser-AgentにIdPに対する問い合わせを示指する(2通りの方式がある)。
- ユーザにリダイレクト要求(302リダイレクト)を返し、IdPにリクエストさせる。
これにより、IdPの認証手続きページに画面遷移しログインや情報開示可否を選択できる。 
- Ajaxスタイルの非同期通信による問い合わせ方式
 
 
- ConsumerはEnd UserのUser-AgentがIdPから受け取った紹介状をリダイレクトで受け取る。
 
- dumb modeの場合、Consumerは紹介状の妥当性を直接IdPに問い合わせる。
 
openid.mode  †
- associateモード
- ConsumerとIdPの間で、共通鍵の共有を行う。
 
- smart modeを処理する場合に必要。
associateモードが失敗した場合は、dumb modeに移行する。 
- Consumer <---(POST)---> IdP
 
 
- check_authenticationモード
- 紹介状が正しいかどうか、IdPへ問い合わせる。
 
- dumb modeで必要になる。
 
- Consumer <---(GET)---> IdP
 
 
- checkid_immediateモード
- Claimed IdentifierがVerified IdentifierであるかIdPへ問い合わせる。
 
- Consumer <---(302 redirect)---> User-Agent <---(GET)---> IdP
 
 
- checkid_setupモード
- 属性情報の通知方法を設定可能なIdpの画面が提供される。
 
- Consumer <---(302 redirect)---> User-Agent <---(GET)---> IdP
 
 
smart modeとdumb mode  †
OpenID認証における、大まかな動作指針
- smart mode
事前にConsumerとIdPの間で共通鍵を共有し、信頼関係を成立させておくモード。 
- dumb mode
- 事前に共通鍵を共有することなく、Claimed Identifierの認証手続きを行う。
 
- smart modeと比べて一連の手続きの最後に1つ余計に処理が増える。
 
 
OpenID Simple Registration Extension 1.0  †
OpenID 1.1 の拡張機能で、End Userの登録情報を照会する機能。
機能概要  †
- IdPのエンドポイントURLにリダイレクトさせる際に所定のクエリーパラメータを追加する。
 
- 紹介状をリダイレクトで受け取る際のURLに含まれるクエリパラメータの一部として返ってくる。
 
- このリダイレクトURLのクエリパラメータに含める事ができる値
- ニックネーム
 
- メールアドレス
 
- フルネーム
 
- 誕生日
 
- 性別
 
- 郵便番号
 
- 国
 
- 言語
 
- タイムゾーン
 
 
- Consumerは照会したい項目を選択できる。
 
- End Userは照会要求を拒否できる。
 
セキュリティ  †
難しい。
以下の3つがある。
- 通信経路のセキュリティ
 
- セキュリティ上の脅威
 
- 評価
 
通信経路のセキュリティ  †
- smart modeで、Consumer <---> IdP間で共通鍵を共有する。
- Diffie-Hellman鍵共有(または鍵交換)プロトコルを使用する。
 
- 以降、HMAC-SHA1(ハッシュ関数と秘密鍵)の署名でメッセージ改ざんを防止。
 
 
- メッセージ署名
- checkid_setup/checkid_immediateモード
・・・ 
 
セキュリティ上の脅威  †
- フィッシング(悪意のあるConsumerサイトからニセのIdpに誘導)
 
- OpenID Realm Spoofing(より、狡猾なフィッシング)
 
- Google検索などを用いてアカウント名の収集が可能。
 
- 紹介状の送信に対するリプレイ攻撃が可能。
Consumer側で、nonceワンタイムな値を追加する。 
IdPの評価  †
- IdPを運営してきた実績
 
- 認証フォームに対するヘルプ機能
 
- httpsへの対応
 
- アカウントのリカバリ機能の充実
 
- プライバシーポリシーの内容
 
- スパム、セキュリティ対策
 
- Attribute Exchange(AX)への対応
 
- Provider Authentication Policy Extension(PAPE)への対応
 
- アカウント登録手続きの内容
 
AOLは許可するIdPをホワイトリスト形式で指定している。
参考  †
OpenID 2.0  †
Identifierの記述形式  †
- URLのほかに、XRIというURIを拡張した形式で記述できる。
 
- XRIは従来のURLと比べて短い文字列を使用できる。
 
- XRIはドメインのように取得する必要がある。
 
- XRI:// ---> http://xri.net/ と変更すると、
xri.netのXRI Proxy ResolverがXRI文字列を解釈して適切なリソースを返す。 
User-Supplied Identifier  †
これまでどおり
- RPはエンドユーザーにログインフォームを表示する。
 
- Claimed IdentifierをRPのログインフォームに入力して認証する。
 
変更点  †
- 1.1の場合ではClaimed Identifierを入力。
 
- 2.0ではUser-Supplied Identifierを入力。
- 従来どおりにClaimed IdentifierをRPのログインフォームに入力して認証
 
- OPで使用したいIdentifierを選択しOP Identifierを入力して認証
ユーザーは自分の長いClaimed Identifierを覚える必要がなくなる。
- OPでOP Identifierを入力して認証を済ませる。
 
- OP Identifierを選択して、認証結果をRPに返す。
 
 
 
- User-Supplied Identifierとは
- End UserによってRPに対して提示されるIdentifier
 
- Claimed IdentifierまたはOP Identifierの総称
 
 
XRDSベースのdiscovery  †
XRDSというXMLのフォーマットは以下が可能。
- サービスに対応している認証サービス(OP)の詳細を指定
- サービス(RP?OP?)の優先順位を指定
 
- サービス(RP?OP?)のエンドポイントURLを指定
 
 
これまで  †
- Claimed Identifierを入力
 
- RPがClaimed Identifierにあるlink要素を解決
- openid.server
 
- 必要であればopenid.delegate、
 
 
- RPはエンドユーザーをOPにリダイレクト
 
変更点  †
IdentifierがXRDS文書を指している場合、
XRDS文書によってOPが決定される。
OP-Local Identifier:OP上でのユーザID
参考  †
- OpenIDの仕様と技術(5):OpenID Authentication 2.0時代の幕開け (2-3/3) - @IT