次の方法で共有

Windows CardSpace 概要 Part.2

  • [アーティクル]

さて、前回は Windows CardSpace の理解をするために必要な前提知識として、そもそも現実世界におけるカード認証の仕組みについて解説しました。キーポイントとなる考え方はこれです。

image

  • 自分のお財布の中には、公的機関や企業などから発行された、各種の名刺が入っている。（場合によっては自分がねつ造した自前の名刺が入っていることも！）
  • お酒を買おうとするときは、酒屋さんから指定されたカードを、お財布の中からチョイスして提示する。

Windows CardSpace は、この現実世界におけるカード認証の動きを、コンピュータシステムの世界の中で実現しようとするものです。

［Windows CardSpace をサポートする Web サイトの動き］

では、まず Windows CardSpace による認証をサポートする Web サイトが、どのようなものになるのかのイメージを見てみます。

image

  • 通常の Web サイトでは、ユーザ名／パスワードによるログイン認証画面が用意されています。
  • Windows CardSpace をサポートしているサイトでは、さらにこれに加えて、CardSpace ログインボタンが用意されています。
  • このボタンをクリックすると、ブラウザから ActiveX コントロール経由で、クライアント PC 内にあるカードセレクタがポップアップとして起動します。（※ .NET Framework 3.0 がインストールされていない PC ではエラーになります。）

image

  • このカードセレクタは、簡単にいえば「当該 PC の中にあるお財布」です。
  • この中に入っているカード（これを情報カード（Information Card）と呼びます）のうち、当該 Web サイトに対して提示可能なカードが表示されます。提示不可能なカードについてはグレーアウトされます。（先の酒屋さんの例で言うと、パスポートや健康保険証のみが提示可能なカードとして取り扱われ、その他の社員証カードなどについてはグレーアウトすることになります。）
  • カードをダブルクリックすると、Web サイトへのログインが完了します。

……と、このように、まさに「現実世界におけるカードの提示」と同じような方法で Web サイトにログインできることになります。

ちなみに現実世界の場合、お財布の中にカードがあふれかえっている人は少なくないと思いますが（自分もそうですが；）、コントロールパネルの "Windows CardSpace" という項目から、この PC のお財布の中に入っているカードを管理（追加・削除など）することができます。

image

※ さらにこの画面では、自分でカードを自作することもできる（自作名刺を作ることもできる）のですが、これについては後述します。

［情報カードとセキュリティトークンの違い］

さて、上記の動作だけ見ると、Windows CardSpace は現実世界のカードシステムをそのままコンピュータシステム上に投影したもののように見えます。しかし、実は現実世界のカードと Windows CardSpace の情報カードには決定的な違いがあります。それは、

「CardSpace では、情報カードそのものを身分証明や身元証明に利用できない。」

という点です。これだけだと分かりにくいので、ちょっと説明を加えます。

まず、現実世界の場合には、カードそのものを身分証明や身元証明に利用できます。例えば、免許証や健康保険証を提示すれば、そのままで年齢確認をしてもらえます。しかし、この方法では以下のようなリスクがあります。

  • カードが盗難されたものだった場合に、RP 側（Relying Party、Web サイト側）がそれをチェックすることができません。例えば、提示されたカードが実は盗難されたものであることに気付かずに、本来のカードの持ち主以外にお酒を売ってしまったり会員カードを発行してしまったりするリスクがあります。
  • 実は誤った人にカードを発行してしまっていた場合や、カードが盗難にあった場合に、IP 側（Identity Provider、カードの発行元）がこれを即座に差し止めることができません。
  • また、IP 側（Identity Provider）の想定外の用途にカードを使われる危険性もあります。

こうした理由から、現実世界では健康保険証や運転免許証をなくしたりするととんでもないことになるのですが、同様のことが CardSpace で発生すると大きな問題になります（PC とか紛失するととんでもないことに、となっては困るわけです）。

このため、Windows CardSpace では、クライアント（Principal）から Web サイト（RP）に対してカードを提示しようとするつど、カード発行元（IP）から、セキュリティトークンをオンラインで取り寄せます。セキュリティトークンとは、簡単にいえば「ワンタイムパスワード」のようなもので、一回だけ有効なアクセスチケット、だと思っていただけると分かりやすいでしょう。具体的な処理の流れは以下のようになります。

image

① Web サイト（RP）がユーザに対してカードの提示を要求する。

  • 実際に RP からクライアントに対して要求されているのは、カードそのものの提示ではなく、セキュリティトークンの提示が要求されています。
  • より詳細には、利用可能なカード（IP）の種類と、必要な Claim リスト（例えばユーザ名と年齢情報が欲しい、など）がサーバから指定されます。

② Web ブラウザから、カードセレクタが起動し、カードを選択する。

  • 情報カードを選択すると、あたかもカードそのものを Web サイトに送信しているかのようにみえる（＆そのように書いてある）のですが、実際にはカードそのものは Web サイトに送信されていません。
  • このカードの中には、発行元の IP の情報が書かれており、まず IP に対してこのカードを送信し、セキュリティトークン（RP にアクセスするためのチケット）の発行を求めます。
  • ちなみに、IP 側が持っている、オンラインでセキュリティトークンを発行することのできるサービスのことを STS （Security Token Issuing Service、セキュリティトークン発行サービス）と呼びます。

③ IP 側の STS は、送られてきたカードの情報をチェックし、セキュリティトークンを発行する。

  • STS は、情報カードが偽物でないかどうか、どの RP に対してどんな Claim を持つセキュリティトークンを必要としているのか、そもそも当該ユーザに対するトークン発行の差し止めは行われていないか、などのチェックを行った上で、セキュリティトークンを発行します。
  • セキュリティトークン上には、必要最小限の Claim だけが記載されています。（このため、RP 側が必要としていない Claim 情報についてはそもそも RP に対して送信されません。）

④ セキュリティトークンを RP に送信し、Web サイトにログインする。

  • RP 側では、送信されてきたセキュリティトークンが、本当に IP から発行されたものかどうかをデジタル署名などによりチェックし、正しいことが確認できた場合には、送信されてきた Claim 情報を信用して使います。

つまり、この流れからわかるように、

  • セキュリティトークンが、実際に身分や身元を証明するためのデータになる。
  • 情報カードそのものには、セキュリティトークンが含まれていない。
  • セキュリティトークンは、オンラインでそのつど取り寄せなければならない。

ということになります。このセキュリティトークンと情報カードの関係は、現実世界になぞらえていうと、

  • CardSpace の情報カード ＝ 印鑑カードや住基カード
    印鑑カードや住基カードそのものは、印鑑の証明には使えない。
  • セキュリティトークン ＝ 実際の印鑑証明書
    印鑑証明書は、印鑑カードや住基カードを持っていくとすぐに発行してくれる。

のような関係にあります。（……ってかえってわかりにくい？；） 重要なのは、情報カードそのものは、アクセスチケットを入手するためのものであって、それ自体がアクセスチケットになっているわけではない、という点です。このようにすることにより、IP 側が、オンライン上でのアクセスチケット（セキュリティトークン）発行の即時差し止めをすることができるようになっている（＝PC が盗難された場合のリスクを低減している）わけです。

※ なお、STS から発行される Claim の中には、ユーザのパスワード情報が含まれているわけではありません。STS から発行される Claim の中に含まれる情報の例としては、名前、年齢、生年月日、e-mail アドレスなどの、個人の属性情報などがあります。RP 側は、IP のことを信頼しているので、STS が当該 IP から発行されたものだと確認できれば、そこに書かれている情報（名前や年齢、生年月日など）はすべて信用することになります。

［マネージカードと自己発行カード］

さて、Windows CardSpace を理解する上でもう一つ欠かせない概念が、自己発行カード（Self-issued Information Card、個人用カード） です。

一般的に、Windows CardSpace で取り扱うカードは、IP から発行されたものを自分の PC にインストールする、という形式で使います。コントロールパネルから Windows CardSpace ランタイムを開くと、カードの管理画面が出てきますが、この中の「マネージカードのインストール」を選択してカードをインストールします。

image

ちなみに Windows CardSpace の情報カードは、拡張子 .crd のファイル（中身は XML 形式で書かれたファイル）です。.crd ファイルの入手方法自体は CardSpace では規定されていませんが、オンラインで発行してもらうパターンや、ディスクや CD-ROM 媒体にコピーして受け取る方法などがあります。

このように、IP が発行する情報カードのことを、一般に 「マネージカード」（Managed Card） と呼びます。（現在のところ、マネージカードを発行してくれる企業や IP は残念ながらほとんどないのですが；。）

しかし、Windows CardSpace の情報カードにはもう一つ、自己発行カード（個人用カード） と呼ばれるものがあります。これは簡単に言うと、自分で名刺を自作する、というもので、Part.1 で解説した、ボトルキープのケースに該当するものです。上記の画面から個人用カードの作成ボタンを押すと、自前の名刺を作ることができます。

image

この自己発行カードはどういうときに使うのかというと、Part.1 で解説した、「通常のパスワード認証を使っている Web サイト」のケースで利用します。通常の多くのサイトでは、新規ユーザ登録時に、自分で決めたパスワードを登録しておくわけですが、このパスワードのかわりに、自作した名刺（自己発行カード）を登録しておきます。

image

このようにすると、当該ユーザがその Web サイトにアクセスするときに、パスワードを入力するかわりにカード（＝自分の作った自己発行カード） を提示してログインをすることができるようになります。

※ 個人用カード、という用語が分かりにくいと思うのですが、これは個人用というよりも自作の名刺を意味している、と考えたほうがよいと思います。（というか、カードが個人用なのは当たり前なのでw）

ちなみに自己発行カードを使う場合のシステム的な動作を示したのが下図になります。この場合には、当該 PC にインストールされている Windows CardSpace ランタイムそのものが IP になります。この IP のことを自己発行プロバイダ（Self-Issue Provider） と呼びます。RP （Web サイト）では、パスワード情報のかわりにカードに関する情報を登録しておくことになり、パスワード確認のかわりにカード情報（＝本人のカードかどうか、前回提示されたカードと同一のものかどうか）を確認することになります。

image 

自己発行プロバイダによって作成した自己発行カード（個人用カード）は、自分の公的な身元証明目的で利用することはできませんが、パスワードがわりに利用するには十分、ということになります。

＃ この説明だけ読むと、カードの偽造や捏造ができるのでは？ というふうに読めると思いますが、その辺のリスクは公開鍵暗号などによって担保されています。なので PC が盗難されない限り、他の人が同一のカードを捏造したりすることはできないように設計されています。（この辺は書くと長くなるので今回は割愛しますが）

ちなみに、この自己発行カードの登録機能を持っている代表的な Web サイトの一つが、Windows Live です。こちらのアドレスからログインしようとすると、情報カード（自己発行カード）によるログインができるようになっています。（※ 実際に使う場合には、一度普通のパスワードでログインしたあとで、自己発行カードをパスワードのかわりとして登録しておく作業が必要になります。） 詳細な情報はこちらのアドレスを見てもらうとよいと思います。（日本語だとここが分かりやすいです）

［パスワードのかわりに情報カードを登録するメリット］

さて、CardSpace を使うと現実世界のように「カードを見せる」ことによるログインができるようになるわけですが、とはいえこれだけのメリットだと、なかなか現在慣れ親しんでいるパスワード方式から乗り換えるメリットが見えづらい、と思います。しかし、Windows CardSpace を使うことには、以下のようなメリットもあります。

  • ユーザが、サイトごとに複雑なパスワードを使い分けなくても済むようになります。
    クラッキングのリスクを避けるためにはサイトごとに複雑なパスワードを使い分ける必要がありますが、実際にはこれは非常に困難で、多くのユーザはそもそも単純な文字列をパスワードとして使ってしまっているでしょう。しかし、Windows CardSpace を使う場合には、そもそもパスワードを利用する必要がありません。
  • あるサイトでユーザ情報 DB がクラックされても、他サイトまで影響が及ぶリスクが低くなります。
    多くのユーザは複数のサイトで共通のパスワードを使うため、ひとつのサイトがクラックされると他のサイトもクラックされる、というリスクが発生します（＝どこか一つでも情報漏洩が発生すると、自分が使っているすべてのサイトでリスクが生じる）。しかし、CardSpace では同一のカードを使っていてもサイトごとに送信されるセキュリティトークンが変化するように設計されているため、クラッキングリスクが低減します。
  • フィッシングのリスクを低減させることができます。
    サイトに対して初めてカードを送信するときには警告メッセージが表示されるようになっているために、フィッシングされたときに誤ってカードを送信するリスクが減ります。また、EV 証明書と呼ばれる高保障証明書を利用することもできるため、サイトの正当性を保証しやすくなっています。

［プラットフォーム中立性］

なお、Windows CardSpace は以下のようなプラットフォーム中立性を持っています。

  • マルチブラウザ対応
    IE 7.0, FireFox 1.5, 2.0 をサポート（ただし .NET Fx 3.0 が必要）。Java で動作する CardSpace や Apple/Safari、Linux/FireFox で動作する CardSpace なども 3rd party やオープンソースで開発されています。また、ポート 80 のみで動作可能です。
  • 可能な限り、オープンな仕様に基づいて設計されている
    情報カードのフォーマット（.crd ファイルのスキーマ）は現時点では独自（標準仕様が存在しないため）ですが、STS からのトークン発行などにはオープンな WS-* を利用しています。
  • 単一の ID プロバイダを必要としない
    Live ID （Passport）などと異なり、ID 情報そのものの囲い込みを目的としていません。あくまで、CardSpace は、「ネットワーク空間の中でカード情報をやり取りする枠組み」のみを定義しています。（実はセキュリティトークンのフォーマットも規定していないため、IP が複数存在していても全く問題なく運用することができる仕組みを採っています）

［現状で CardSpace を利用する場合の注意点］

さて、このように様々なメリットを持った Windows CardSpace ですが、実際に Windows CardSpace に対応した Web サイトを開発しようとした場合には、実は結構厄介な話があります。それは、 .NET Framework 3.0 に含まれる WCS ランタイムだけでは、CardSpace 対応のシステム全体を構築できない、という点です。

Windows CardSpace を使った認証システムの構築には、下図のような機能が必要になります。

image

ところが、WCS ランタイムの含まれている機能は、クライアント機能、すなわちカードストア、セレクタ、自己発行 IP の 3 つのみです。**実際に WCS 対応システムを作るためには、IP, STS, RP の実装が必要になる**のですが、これらの実装はそんなに簡単ではありません。具体的には、以下のような機能実装が必要になります。

  • IP （Identity Provider） ：カード発行に必要な一連の機能
    ユーザ管理、マネージカード発行／再発行、失効、リニューアル、etc.
  • STS （Security Token Service） : トークン発行に必要な機能
    マネージカードの内容確認、セキュリティトークン発行、失効管理、etc.
  • RP （Relying Parties） : トークン受付に必要な機能
    クライアントへのトークン提示要求、受信したトークンの解析機能、etc.

実は、WCS 自身はカードの中身や暗号化ロジック、トークンの形式を一切規定していないため、自由度が高い半面、自力での実装が必要です。こうした問題を踏まえ、IP, STS, RP の実装を簡素化するためのフレームワークを開発しています。それが Codename "Geneva" と呼ばれるものです。今回はこちらの詳細には触れませんが（というかごめんなさい、白状すると私もちゃんと調べきれてないのです＞＜）、Geneva の開発チームの blog がこちらにありますので、興味がある方はぜひ読んでみてください。

［まとめ］

というわけで、2 回にわたって Windows CardSpace について解説してきましたが、全体像を振り返りながらまとめると以下のようになります。

CardSpace では、以下の 3 者がカードやセキュリティトークンの情報をやり取りする。

  • RP （Relying Parties） : カード情報の提示を求めるサイト
  • Principal : エンドユーザ
  • IP （Identity Provider） : カードを発行するサイト

CardSpace では、カードとセキュリティトークンが区別される。

  • カード（情報カード）
    IP からセキュリティトークンを発行してもらうためのカード。STS（セキュリティトークンサービス）の URL、記載可能な Claim 一覧などが記載されている。
  • セキュリティトークン
    IP の STS から必要のつど発行してもらう、実際の「身元証明」情報。必要最小限の Claim のみが記載された形で発行され、これを RP に提示することで、RP に対し、身元証明を行う。

Windows CardSpace は、現在のところ IP, RP, STS などの実装の困難性、そしてランタイムの普及率などの問題からなかなか流行っていないのが実情だと思いますが、エンドユーザにとっても非常にメリットのある、わかりやすい技術であることには間違いがありません。今後、Geneva などの正式リリース、あるいは Vista や .NET Framework 3.0 などの最新プラットフォームの普及に伴い、徐々に使いやすい環境が整ってくることになるはずなので、概要とその狙いはぜひ知っておいていただければ、と思います。

Comments

  • Anonymous
    December 08, 2008
    webクライアントが.net3.0に依存してしまうのは現状だと大きなデメリットがある気がします。 それだったらClickOnceやSilverlightでいいような気もしてます。 ただ考え方自体は素敵なので、どちらかといえば標準化されてほしい技術です＾＾。

  • Anonymous
    January 08, 2009
    気になった点をいくつか。 まず、IPはユーザーがどんなRPを利用しようとしているかがすべてわかるのか、ということです。 ユーザーの行動履歴はその気になれば悪用できますから、ユーザーはIPが信頼できるかどうかを見極めなければなりませんね。 それから、RPが要求する Claim は標準化されているのか？ というのも気になりました。 各々のRPが、必要とする Claim を好き勝手な名前で呼んでいたら困りますね。 最後に、RPはIPをどうやって信頼するのだろうか、という疑問が。 よろしかったら答えてやってください。

  • Anonymous
    January 09, 2009
    The comment has been removed

  • Anonymous
    January 11, 2009
    > これは現実世界でも当たり前のことで、例えば区役所などは信頼しうる IP となりますが、その辺の怪しげなお店から発行された会員カードの場合、そこは信頼しうる IP とはならないでしょうし、そこから発行されたカードを RP が受け付けることもないでしょう。 現実では、怪しげなお店の会員カードをどこかで提示しても、そのことを怪しげなお店が知ることはできない、という違いがあります。 「信頼できる IP か？」は、RP にとってと、ユーザーにとっての2つの視点があります。 従来は、ユーザーは「信頼できる RP か？」だけ気にしていればよかったのが、今度は IP についても気にする必要が出てくるということです。 > 各々のRPが、必要とする Claim を好き勝手な名前で呼んでいたら困りますね。 今のところ、自己発行カードしかもってないので、他のカードの使い勝手がわからないのですが、自己発行カードには、住所や電話番号を記載することもできますよね。 これは、認証以外の、例えば通販サイトでの送付先入力を簡単にするような目的にも使えるんじゃないだろうかと思っています。 その際、RP である通販サイトは「住所」という Claim を要求しているのに、カードには「自宅住所」とか「勤務先住所」という Claim は載っていても「住所」という Claim が載っていないと面倒なことになりそうだな、と思ったわけです。 どうもまだ、自分の中で、情報カードは何であって何でないのかということが、いまひとつ整理しきれずに、いろいろごっちゃになっているようです。 例えば、CardSpace は、Web 上でのシングルサインオンを実装する手助けにはならなそうですね。

  • Anonymous
    January 11, 2009
    The comment has been removed

  • Anonymous
    January 11, 2009
    > 信頼できないクレジットカード会社からカードを発行してもらい、それを適当なお店で使ったらどうなるか？ クレジットカードは、IP に行動履歴がわかる数少ない例かと思います。 > もともと Claim 情報を共通化しよう、という動きは昔からあるのですが、こうしたデジタルデータの標準フォーマットを決定するというのは、業界やユーザの賛同を得にくい、という現実もあります。 そうだろうな、と思います。 > 同一のカードを複数のサイトに見せることは可能なので、あるカードを受け付けてくれる RP が複数ある場合には、シングルサインオンができる形になります。 すいません、言葉が足りませんでした。 ここでシングルサインオンとは、プロファイル情報を複数サイトで共有することを含めて言ってます。 CardSpace では同じカードでもサイトごとにトークンが違うので、RP 側では他の RP と同じカードが提示されたかどうかはわからないわけですよね。 そうすると、情報共有のためには何か別の仕組みが必要だと思います。 もともと、情報流出の問題に触れられているあたり、プロファイル共有自体を問題視しているのかもしれませんが。

  • Anonymous
    January 12, 2009
    The comment has been removed

  • Anonymous
    January 12, 2009
    > 特に、目的特化型で発行しているカードについては、他の目的で使われたくないケースもよくあります。 なるほど。 「他の目的に使われたくないケース」っていうのがいまひとつ想像できませんでしたが、納得しました。 > CardSpace の場合には共有できるプロファイル情報にかなり制限があるのです。 すいません。 関係ない話題を一緒に書いたので混乱させてしまったようです。 ここで言う「プロファイル共有」とは、その前に言っていた「通販サイト等でのプロファイル入力支援」とは別件で、従来通り、サーバ側で管理されているプロファイルのことです。 「同じカードが提示された」ことがわかるなら可能ですね。

  • Anonymous
    January 29, 2009
    Windows Card Space のダイアログが表示されるのが遅い。 送信を押しても反応が遅い。 ログインするだけでタバコが吸えます。orz