マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

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サイト上の処理を中心に説明する。

  1. OpenIDログイン・フォームにClaimed IdentifierのURLが入力される。
  2. Consumerは、"openid.server"と"openid.delegate"を参照する。
  3. 通常、smart modeを選択し、Claimed Identifierの認証手続きを行う。
  4. ConsumerはEnd UserのUser-AgentにIdPに対する問い合わせを示指する(2通りの方式がある)。
    1. ユーザにリダイレクト要求(302リダイレクト)を返し、IdPにリクエストさせる。
      これにより、IdPの認証手続きページに画面遷移しログインや情報開示可否を選択できる。
    2. Ajaxスタイルの非同期通信による問い合わせ方式
  5. ConsumerはEnd UserのUser-AgentがIdPから受け取った紹介状をリダイレクトで受け取る。
  6. 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つ余計に処理が増える。
  • id_res
    • ???

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モード
      ・・・
  • id_resモード
    IdPから返される紹介状

セキュリティ上の脅威

  • フィッシング(悪意のある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
    • 認証方式

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を指定

これまで

  1. Claimed Identifierを入力
  2. RPがClaimed Identifierにあるlink要素を解決
    • openid.server
    • 必要であればopenid.delegate、
  3. RPはエンドユーザーをOPにリダイレクト

変更点

IdentifierがXRDS文書を指している場合、
XRDS文書によってOPが決定される。

  • OpenID 2.0ベースでのdelegate設定サンプル
    <head>
      <link rel="openid.server"  href="OpenID 1.1のIdPが提供するサーバのエンドポイントURL" />
      <link rel="openid.delegate"  href="OpenID 1.1のClaimed Identifierとして使用するURL" />
      <link rel="openid2.local_id" href="OpenID 2.0のOP-Local Identifier URL" />
      <link rel="openid2.provider" href="OpenID 2.0のOPのエンドポイントURL" />
      <meta http-equiv="x-xrds-location" content="XRDS文書のURL" />

OP-Local Identifier:OP上でのユーザID

参考

参考


Tags: :IT国際標準, :認証基盤, :クレームベース認証


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-10-09 (火) 22:16:05 (9d)