openid.realm の値が例えば、

• *.org
• *.co.jp

みたいなケース。これだと大多数のドメインを許可する事になってしまうので、これを避けたいと言う話。

その前にワイルド過ぎる realm の定義を決めてみる (ドメイン縛りで)

ワイルドカードを指定する事によって所有者の異なるドメインまで指定できてしまうようなケースを指す事にします。

どうすれば良いか

ではサンプルとして、openid.example.co.jp を取り上げて考えて見ましょう。

ドメイン部ですけど、カンマ区切りで右端にある物を TLD (top level domain) と言います。例えば .jp だとか .org だとか。

no title によれば、主要なTLDとして

• generic (gTLD)
• sponsored (sTLD)
• country code (ccTLD)
• reserved
• pseudo

と言った物が挙げられます。*1

でちょっと脇道にそれてしまったけども、まずドメインの右端が TLD にマッチする事が必須条件。ここでは .jp がそれに当たるので残りは openid.example.co となります。

ここで次の右端である .co ですが SLD (second level domain) と言います。www.example.org ならば example がそれに当たります。

SLD までで、特定の所有者に紐づくのかそうでないかでワイルドな realm なのか、そうでないのかを判断して良いかと思います。なので、

• *.co.jp は複数の所有者が考えられるので NG
• *.example.org は特定の所有者だと考えられるので OK

って事になります。SLD でも ccTLD に紐づく SLD の事を ccSLD (country code SLD) と言うようです。

さて、wikipedia (en) の当該ページにあるリンクには Mozilla の Wiki へのリンクがあります。

• TLD List - MozillaWiki

ただこれはどの程度、メンテナンスされてる情報かがイマイチ分からないのですよねぇ。とか思ってググってたら Mozilla がちゃんとメンテナンスしている事が分かりました。

• Gecko:Effective TLD List - MozillaWiki
• Gecko:Effective TLD Service - MozillaWiki
• Public Suffix List
• effective_tld_names.dat

nsIEffectiveTLDService ってのがあるらしく、元データは effective_tld_names.dat と言うファイルに集約されているみたいです。ここに ccSLD も含めた有効なドメインのパターンが存在し、結構ちゃんとメンテナンスされているみたいです。

ただ最近話題になっていた .me と言う ccTLD なんかはまだ無いみたい。Mozilla++ ですね。

さて Perl で書いてみよう

まず TLD ですが、Net::Domain::TLD と言うモジュールがありまして、ここから TLD のリストを得る事が出来ます。

#!/usr/bin/perl

use strict;
use warnings;

use Perl6::Say;
use Data::Dump qw(dump);
use Net::Domain::TLD qw(tlds tld_exists);

say '[tld types] ' . join(', ', Net::Domain::TLD::TLD_TYPES);
say '-' x 50;
say '[' . $_ . '] ' . join(', ', tlds($_)) for (Net::Domain::TLD::TLD_TYPES);

TLD の種別の出力と、TLD の種別ごとに TLD 一覧を出力します。

• new_open
• new_restricted
• gtld_open
• gtld_restricted
• cc

と言うのが種別になります。

tld_exists は、

• TLD と思しき文字列が
• 指定されていればその種別にそのTLDが含まれているか
• 指定されてなければそれが何らかの種別のTLDかどうか

と言うのを調べられます。

#!/usr/bin/perl

use strict;
use warnings;

use Perl6::Say;
use Data::Dump qw(dump);
use Net::Domain::TLD qw(tlds tld_exists);

say dump(tld_exists('org')); # org は TLD かどうか -> 1
say dump(tld_exists('hoge')); # hoge は TLD かどうか -> 0
say dump(tld_exists('jp', 'cc')); # jp は ccTLD かどうか -> 1
say dump(tld_exists('com', 'cc')); # com は ccTLD かどうか -> 0

TLD は調べられますが、SLD まではどうにもならないので、effective_tld_names.dat を利用してみます。

Gecko:Effective TLD Service - MozillaWiki によるとこのファイルの記述ルールは、

• 行単位で読んでいく
• // 以下はコメント
• 何も無い行は無視
• . はサブドメインの区切り文字
• ! から始まるルールは直前のワイルドカードの除外パターンとして例外的に扱う

と言うルールのようです。

まずこれらのルールを考慮して TLD がどれだけ網羅されているか、Net::Domain::TLD と比較してみます。

#!/usr/bin/perl

use strict;
use warnings;

use Data::Dump qw(dump);
use LWP::UserAgent;
use Net::Domain::TLD qw(tlds);
use Perl6::Say;

my $tld_names = 'http://mxr.mozilla.org/mozilla/source//netwerk/dns/src/effective_tld_names.dat?raw=1';
my $ua = LWP::UserAgent->new;
my $res = $ua->get($tld_names);

unless ($res->is_success) {
    die;
}

my %tlds = ();

for (split "\n" => $res->content) {
    s|(//.*)||g;
    s|\s+||g;
    next if (/^\n*$/);
    my $tld = ((split(/\./, $_))[-1]);
    $tlds{$tld}++;
}

say dump(scalar keys %tlds);
say dump(scalar (my @tlds = tlds));

say "-" x 50;

say dump(grep { !exists $tlds{$_} } @tlds);

結果は、

256
272
--------------------------------------------------
(
  "sj",
  "bv",
  "gb",
  "wf",
  "um",
  "me",
  "pm",
  "rs",
  "mf",
  "eh",
  "tp",
  "yt",
  "kp",
  "so",
  "bl",
  "tel",
)

なるほどなるほど。16個の TLD が Mozilla のリストからは漏れてるみたいです。

この未調査の TLD の事は別途何とかするかするとして、このデータを上手く使えば、ccSLD まで考慮に入れて realm の検証が出来そうです。

という訳で

次回、ccSLD も考慮に入れたモジュールを作ってみちゃったりする予定です。

と言う訳でついに来ましたね。

• [mixi] mixi OpenID
• mixi Developer Center » mixi OpenID

中の人、お疲れ様でした。

実はさっきまで mixi に行って技術的な意見交換などしてきました。mixi OpenID の技術的な側面なんかを簡単に紹介したいと思います。

ミクシィ認証

これは普通の OpenID Provider の挙動と同じです。僕のアカウントは http://mixi.jp/show_profile.pl?id=29704 なので僕の OP Local Identifier は、

https://id.mixi.jp/29704

ここでお気づきの方も居るかと思いますが、OP Local Identifier 自体も https で提供されています。さて最初の html の内容を確認しておきます。

<link href="https://mixi.jp/openid_server.pl" rel="openid2.provider" title="[mixi] mixi OpenID" />
<link href="https://mixi.jp/openid_server.pl" rel="openid.server" title="[mixi] mixi OpenID" />

OP Endpoint URL も https で提供されてますね。ついでに Yadis にも対応との事なので試してみます。

$ lwp-request -m HEAD https://id.mixi.jp/29704 | grep XRDS
X-XRDS-Location: https://mixi.jp/xrds_signon.pl

と返ってくるので、

$ lwp-request https://mixi.jp/xrds_signon.pl

を実行して、

<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns:openid="http://openid.net/xmlns/1.0" xmlns="xri://$xrd*($v*2.0)">
  <XRD>
    <Service priority="0">
      <Type>http://specs.openid.net/auth/2.0/signon</Type>
      <Type>http://openid.net/sreg/1.0</Type>
      <Type>http://openid.net/extensions/sreg/1.1</Type>
      <Type>http://openid.net/srv/ax/1.0</Type>
      <URI>https://mixi.jp/openid_server.pl</URI>
    </Service>
    <Service priority="1">
      <Type>http://openid.net/signon/1.1</Type>
      <Type>http://openid.net/sreg/1.0</Type>
      <Type>http://openid.net/extensions/sreg/1.1</Type>
      <Type>http://openid.net/srv/ax/1.0</Type>
      <URI>https://mixi.jp/openid_server.pl</URI>
    </Service>
  </XRD>
</xrds:XRDS>

AX や SREG に対応していると言う主張されているのが分かります。一点思ったのはユーザごとに XRDS 文書を提供してもいいんじゃないのかなと思いました。と言うのも http://mixi.jp/ に対してディスカバリかけた時も同じ XRDS に行き着くからです。まぁ、いつでも代えられるだろうし、そうでなければならない理由も特に無いのでいいですけどもｗ

マイミクシィ認証とコミュニティ認証

これが他の OpenID Provider とは大きく異なる点です。mixi の OpenID を使う場合に、特定のユーザとマイミクしてるかどうかや、特定のコミュニティに属しているかどうかを OpenID Protocol を用いて認証する事が出来ます。

登場人物を分かりやすくする為に、id:amachang (あま二郎さん) に登場して貰う事にしましょう。僕のブログのコメントに OpenID が使えるシーンにて、僕のマイミクさんならばコメントを書き込めると言うシーンで使えます。これはどういう風にやるかと言うと、

1. 自分の OP Local Identifier のお尻に /friends をつける
   1. https://id.mixi.jp/29704/friends
   2. 便宜上、これをマイミクシィ認証での Claimed Identifier とします
2. id:amachang が僕のブログのコメントをつける際に、mixi でログイン的なボタンを押します
   1. このボタンを押した際に自動的にマイミクシィ認証での Claimed Identifier で認証フローに進みます
3. 普通に mixi でログインして、OpenID のフロー通り redirect して僕のブログの return_to URL に戻ってきます

と言う感じなんだけど、その際の値がちょっと変わっていて、

リクエスト時

Claimed Identifier (openid.claimd_id)

https://id.mixi.jp/29704/friends

レスポンス時

Claimed Identifier (openid.claimed_id)

https://id.mixi.jp/29704/friends/XXXXXX (XXXXXX は id:amachang の mixi での id)

OP Local Identifier (openid.identity)

https://id.mixi.jp/XXXXXX

と言う形で返って来ます。リクエスト時の Claimed Identifier とは異なる値がレスポンスで返されるのが特徴です。

従って、11.4. Verifying Signatures における署名生成の元データに openid.claimd_id を用いるので OP が作った署名と RP が (リクエスト時のデータを元に) 作った署名は異なるので、直接検証 (check_authentication) に移行します。*1

コミュニティ認証もほとんど同じで、{id}/friends の代わりに /community/{community_id} を用いるだけです。詳しくは mixi Developer Center » 仕様 を見て下さい。

まとめ

是非はともかくして面白い仕組みを引っさげてリリースと言うところはさすがだなと思いました。ちょっと工夫すれば mixi 上での知人関係やらを利用したサイトを作るのも出来ちゃいますね。

是非皆さんも mixi OpenID を利用したサイトを作ってみて下さい。

合わせて読みたい

• OpenID Provider のセキュリティ対策 (1) - まずは SSL を導入！話はそれからだ - Yet Another Hackadelic
• OpenID Provider のセキュリティ対策 (2) - return_to と realm のチェックを怠るな！ - Yet Another Hackadelic
• WASForum Conference 2008 での OpenID のセキュリティについてのスライドを公開します - Yet Another Hackadelic
• Net::OpenID::Consumerでsregを試す - Yet Another Hackadelic

最近ずいぶんフィード消化してませんでした。で、久しぶりに見てみたら、こんな話がZIGOROuさんとこに。

Web+DBのOrenID特集を読みました。、教えて欲しい疑問点があります。素人なので初歩的な疑問点で申し訳ありませんが、よろしくお願い致します。

　今、携帯電話の契約者固有ＩＤのプライバシーの懸念が問題になっています。http://takagi-hiromitsu.jp/diary/20080710.html

問題点を以下に要約しますと、

　ａ　サイトで住所氏名Ｅメールアドレス等の個人特定情報を入力することによって、その個人特定情報と契約者固有ＩＤ（ｉモードＩＤ等）とが紐付けられ、ネット上での行動履歴情報が契約者固有ＩＤを手掛かりに収集され（名寄せされ）、その収集情報と個人とが結び付けられる。

　ｂ　収集情報と個人とを結び付けた情報（以下「個人特定型ライフログ」という）が、悪徳業者の手に渡り、詐欺行為等のツールとして悪用される。

というものです。

　世界に１つの固有ＩＤという点では、OrenIDも契約者固有ＩＤと同じですよねえ。そうすると、契約者固有ＩＤと同じ問題が生じるのではないかとの疑問が生じます。

　OrenIDでは、このプライバシー問題をどのように解決しているのか教えてください。

id:futureeyeさんからの質問

OrenID。オレオレIDみたいなものですね、わかります。

まあ冗談はさておき、

大きく違う点は、

* 携帯の方は自分の意思とは無関係に第三者に自分固有のIDが通知されている

* OpenID は自分の意思で第三者に認証結果を通知する

と言う訳で誰がそれを行っているかの観点で話が明らかに違います。

OpenID とプライバシーについて - Yet Another Hackadelic

以上はまず重要な前提として

クロール可能なデータはプライバシーではないと個人的には思います。

OpenID とプライバシーについて - Yet Another Hackadelic

という点について、もうちょっと深掘りしてみる。

例えば僕のはてなダイアリーは全然クロール対象だし、はてなのOpenIDつかって入ったサイトと、クロールされた結果としての僕のブログのいろいろな発言と結びつけられても、まあ仕方ない。それはそういうもんである。

だけど、例えば僕が今からログインしようとしているOpenIDのRPサイトが、ネット上の人格とは別のアクティビティである場合（最近あんまりそういうこともなくなってきたけど）、不用意に結びついてしまうとまずいな、と警戒することはあると思う。

プライベート、仕事、コミュニティなど、複数の面を持つ人は、きっと少数派ではない。そういうとき、どうするのが正しいのだろう？

はてなOpenIDじゃない、ほかのOPを使えばいい？でもそのサイトがログインを受け付けてるOPのリスト（ホワイトリスト）の中に自分のアカウントを持っていなかったら？

別のアカウントを用意する？あれ、OpenIDでアカウントの濫造は抑制されるのではなかったけ？

この例だと、問題をホワイトリストの非オープン性やペルソナ実装の必要性に持っていくこともできるけれども、プライバシーの観点から絞って見てみる。

端的に言うと、OpenID は（2.0以前は）プライバシーという観点で言うと、段差が急すぎだった。つまり、こう言っているのと同等。

「ログインしたければあなたのIDを私に曝せ、でなければ私のとこにはログインさせてあげないよ。」

この中間にあり得るはずの「ログインはしたいけれども、IDは教えたくないよ」という要求には答えられていなかった。

というと「なんだそれ？IDを教えずにログインなんてできないじゃん？誰が誰だかわからなくなるよ！」と言われそうな気がする。

うん、ログインには確かに来訪者を一意に表す識別子は必要だけど、それがグローバルである必要は無いんだってこと。インターネット中で一意なIDってのは、ログインという事象を実現することだけを考えたら、結構オーバースペックなのだ。

実際、このようなOpenIDプロバイダがある。OpenID.ee。(via tkudo)　このサービスはOpenID 2.0 の仕様を元に実装されている。

具体的には OpenID.ee と Yahoo!. とくに OpenID.ee では自身の管理しているアカウント名とは別の識別子を, RP (Relying Party) ごとにランダムに生成し払い出すらしい.

Relying Party に対してユーザを匿名化する OpenID Provider - tkudo’s weblog about identity management

ただし、そもそもOpenIDって、URLが自分を表してる、って言う前提から入ってきたような仕様なので、そこに立ち返りたい人にとっては、「本物の」URLを渡さないOpenID.eeやYahooのようなやり方はむしろなじまないのかもしれない。

たとえばOpenIDからSocial Graphにつなげようとしたいとき、FOAFのデータがそのURLにおいてあって、それディスカバリできたらいいじゃん、分散SNSだよ！みたいなことを考えてる人にとって、URLがIDじゃないのはひどくめんどくさく思えるんだろう。

だが、プライバシー原理主義からみたら、グローバルIDになり得るURLを教える同意と、ログインセッションを伝播させることに対する同意とは別物であるべきであって、その選択の自由を与えるべきだ、ということになるのだろう。

さて、実は、こういっておいてなんだけれども、自分自身の意見は、必ずしも段差はなだらかである必要はないよな、という意見でいます。結局、今はまだOpenIDはデベロッパーのものです。デベロッパーにとってわかりやすいのが一番です。あと、エンドユーザにとっても、選択肢の多さは混乱を招きます。OpenIDというだけでも（ホワイトリストつきでさえも）十分従前と比べて選択肢が増えてしまっているので、いかに混乱させないかが今の一番の課題のはずなのです。

------

以下、ちょっとOpenIDから離れて、だらだらと書く。

携帯の場合も、サイト毎にローカルなIDを渡すようにすればよかった。ドメイン毎に違う、しかし同一ドメインの中では固定で識別できるIDをゲートウェイが振ってあげられればよかった。それをしなかったのは、おそらくそれでは膨大なリクエストに対して処理能力が間に合わないという試算でもあったのだろうか。さすがに何も考えずやってることはないよな、と思ってるが。

元のIDにドメイン文字列を加えた値にハッシュ関数を適用したようなものでもいいのではないか。この場合、マッピングDBをルックアップする必要はないから、DB負荷は減らせる。でも、ハッシュ計算のCPU負荷がもっと高いだろうので、結局キャリアでは採用できないかもしれない。

ちなみにこの方法（ハッシュ）は、FeliCaのIDを記録する機能を持った組み込み機器が、プライバシー問題に対してこの方法で対処しようとしていたという話を聞いたことがある（この場合ハッシュに追加して入れるのはドメインではなくって製品／サービス毎の独自の値）。実際に商品化されたものが出ているのかどうかはわからないけれども。

そういえば、昔、ドコモがやってたな。マイボックス。今もちゃんとやってるのか。事業やサービスの善し悪しとぜんぜんちがうところで、事業者毎に違う識別子が届く、っていう細かな仕様で、ちゃんと考えてんだな、って思った記憶がある。

以下のサイトにそれっぽい記述はあるけど、明確に事業者毎に異なるIDだ、とは書いてない。もしかしたら記憶違いかも。

１．ユーザ認証機能

ユーザ認証機能とは、お客様が企業様のサイトにアクセスすると同時に、お客様を特定できるＩＤを企業様に通知する機能です。お客様はＩＤ／パスワードなどを入力することなしに自分専用の情報にアクセスすることで、より簡単に企業様の提供するサービスをご利用できます。

マイボックスサービスとは - ドコモビジネスオンライン

OpenID Provider のセキュリティ対策 (1) - まずは SSL を導入！話はそれからだ - Yet Another Hackadelicの続編です。

はじめに

RP が認証アサーションリクエストである checkid_setup/checkid_immediate を行う際には通常は return_to と realm を指定します。

return_to とは

OP から認証アサーションレスポンスを間接通信で受け取る際に戻って来るURLの事。RP が指定しておく。

realm とは

return_to のパターンをワイルドカードを使って表現する。

return_to と realm の検証

基本的に return_to の先は http://openid.art-code.org/handler であるという前提で。便宜上番号振りました。

(1) 期待通りの組合せ

realm

http://*.art-code.org

return_to

http://openid.art-code.org/handler

みたいな組合せの場合、realmで指定したパターンにreturn_toはマッチするので特に問題は無い。

(2) realm の指定がワイルドすぎる

realm

http://*.org

return_to

http://redirect.example.com/redirect?url=openid.art-code.org/handler

かなり広範囲にワイルドカードが指定してあるケース。これはダメ。

(3) realm に違反する return_to

例えば、

realm

http://*.art-code.org

return_to

http://redirect.example.com/redirect?url=openid.art-code.org/handler

これは反してるのでNGになるはず。

(4) realm/return_to は正常だがRPとは異なるホストに適用してある

さらに言うと、

realm

http://*.example.com/

return_to

http://redirect.example.com/redirect?url=openid.art-code.org/handler

だったら見かけ上OKだけど、普通に考えてOPとしてこれを許可する訳には行かない。

そもそも RP から見てまったく違うホストに対して realm も return_to も指定してあるので、こういうケースは信じるべきではない。

国内OPの対応状況

○は良く出来ました。×はダメ。△は微妙。解説はこの後で。

Yahoo! Japan の場合

(1) の場合 -> ○

のような形で realm も return_to も明示してる。これがお手本。

(2) の場合 -> ○

こんな感じで怒られた。これがあるべき姿。さすが Yahoo! ですな。一点だけ言えば openid.mode=error で返してもいい気がするけど、敢えて返さないようにしたんですかね。

(3) の場合 -> ○

(2) と同じ画面で怒られる。これも正しい。間接通信でレスポンスが戻ってこないのも (2) と一緒。

(4) の場合 -> △

これは正常であると認められてリダイレクタに飛ばされます。この議論は別途。

livedoor の場合

(1) の場合 -> ○

これはまぁOKです。ただ realm も一緒に出すとなお良いです。

(2) の場合 -> ×

(1) と同じように出た件。これは openid.mode=error でレスポンス返すなり Yahoo! と同じようにエラー画面出して戻さないとかやるべき。

(3) の場合 -> △

そもそも画面真っ白で何も出ない。結果的にrejectされたから△としておく。

(4) の場合 -> △

一応 return_to 見て分かる人はリダイレクタだと分かるから△としておく。でも素人は分からないよねぇ。

hatena の場合

(1) の場合 -> ×

realm だけ出すってのは宜しくない。return_to と共に出さないと中間者攻撃の餌食になる可能性があります。

(2) の場合 -> ×

以下のサイトでとして「*.org」ってどんだけのサイトに許可すんだよｗ

(3) の場合 -> △

どうやら hatena では Data::Dumper を使っている模様＞＜

まぁ結果的にその先に進まないから△だけどこれは恥ずかしい＞＜

(4) の場合 -> ×

realm だけしか出してないので、その先にリダイレクタが経由してあるなどユーザーに気づかせるきっかけなど一切無し。

wassr の場合

(1), (2), (4) -> ×

(3) 以外だと全部、

みたいになってる。「」の中が空っぽorz...

(3) の場合 -> △

真っ白＞＜

openid.ne.jp

(1), (2), (4) の場合 -> ×

realm しか出してない。return_to も出して下さい＞＜

あと、(2) は reject しないとダメ。

(3) の場合 -> ○

これは見事に error を返してる。ちょっと意外*1だった。

と言う訳でまとめますよ！

• 認証確認画面では return_to, realm 共に明示する
• realm に不一致な return_to に対しては openid.mode=error で返すか、リダイレクトしない
  • リダイレクトしない方が賢いかも*2

リダイレクタとrealmの検証については別途エントリ書こうと思います。(続く)

最近のプログラマ界隈の話はかなり熱いですね。

• 若者に一度だけ与えられる出会いの場、セキュリティ＆プログラミングキャンプ - IT戦記
• インターン後半 / 第2回募集 - naoyaのはてなダイアリー

暑いけど頑張ろうと思った2008年夏。まだまだ若い連中にゃ負けちゃいらんないすよ！