Share via

Windows CardSpace 概要 Part.1

  • Article

さて、次は何のネタ書くかなぁ……と思っていたのですが、ちょっと寄り道して Windows CardSpace （WCS）の話題にしてみようかと思ったり。

Windows CardSpace というのは、.NET Framework 3.0 に含まれるコンポーネントの一つで、

  • WPF (Windows Presentation Foundation)
  • WCF (Windows Communication Foundation)
  • WF (Windows Workflow Foundation)
  • WCS (Windows CardSpace)

と、.NET Framework 3.0 の一角を占める重要なコンポーネント…なのですが、これがびっくりするほど知られていません。確かに私も実際の案件で使ったことがあるテクノロジではなく、また現時点で利用しようと思うとハードルの高い技術なのですが、考え方は非常に単純であり、概要については知っておいて損はない技術の一つです。特にセキュリティがらみの技術は、実際にそれを使うにせよ使わないにせよ、設計概念を理解しておくと、実際のシステム開発ではその類推で設計できることが結構あります。幸い、概念レベルで見ると非常に面白い技術なので、今回は気楽にエントリを読んでもらえると嬉しいです。

  • Windows CardSpace とはどんなものか？
  • 現実世界のカード身分証明との比較
  • コンピュータシステムとの比較

1. Windows CardSpace とはどんなものか？

Windows CardSpace は、.NET Framework 3.0 に同梱されているコンポーネントです。このため、Windows Vista には最初からインストールされており、XP などでも .NET 3.0 をインストールすることで利用することができるようになります。ちなみに、どこにインストールされているのかというと、コントロールパネルの項目の中に「Windows CardSpace」という項目があり、これを選択すると起動します。

image  image

とはいえ、この画面だけだと「いったいこれはなに？？」となると思います。この画面は、この PC の中にある「お財布」と、そこに含まれる「カード」なのですが、この説明でもさっぱりわからないと思いますので、ちょっと PC の世界を離れて、現実世界の話をしてみたいと思います。

2. 現実世界のカード身分証明との比較

もともと Windows CardSpace は、ID メタシステムのためのコンポーネントとして開発されました。ID メタシステムとは、エンドユーザの身分証明・身元証明（ID 証明）の方法に関する汎用的なフレームワークのことなのですが、そもそも現実世界の中では、一般的にどのような形で身分証明が行われているのかを考えてみます。

例えば、私がお酒を買う場合を考えてみます。お酒を買うまでの流れは以下のようなものでしょう。

image

  • 私は非常に若く見えるので、お酒屋さんから年齢確認を求められます。
  • 私は財布を開き、大量のカードの中から適切なカード（例えば健康保険証やパスポートなど）を一枚取り出して酒屋さんに見せます。
  • すると、酒屋さんはカードの内容を確認し、お酒を売ってくれます。
  • もちろん、提示するカードが年齢証明に使えないようなカード（例えばヨドバシカメラのポイントカードなど）だったら、お酒を売るのを拒否されてしまいます。

さて、この一連の流れでは、以下の 3 つのロールが存在します。

  • IP （Identity Provider） : 身分証明書を発行する立場の人、あるいは組織
    例 ：外務省（パスポート）、警視庁（免許証）、健康保険組合（健康保険証）、企業（社員証）、ビデオレンタル会員証（ビデオレンタル店）、etc.
  • Principal : 身分証明書を使って何かをしようと思っている人
    例 ：エンドユーザ
  • RP （Relying Parties） : 身分証明書による確認を求める立場の人
    例 ：酒屋さん（年齢確認のため）、警備員（社員のみを入館させるため）、etc.

※ 上述した 3 つの用語（IP, Principal, RP）はセキュリティの専門用語で、いろんなところで出てくるのでぜひ覚えてください。わかりにくければ、上のイラストになぞらえて覚えておくとよいでしょう。

実は、現実世界におけるカードの身分証明の動きを見ると、必ず IP, Principal, RP の三者が介在した動きをしています。いくつか例を取り上げてみます。

例1. 酒屋さんでお酒を買うとき

image

さきほどの例です。この場合、お酒を買う場合には、年齢証明が必要なため、パスポートや免許証、健康保険証などの提示が求められます。IP, Principal, RP がどれに対応するのかはいうまでもないでしょう。このケースには、以下のような特徴があります。

  • 提示するカードを Principal が選ぶことができるが、なんでもよいというわけではない。
    「公的機関から発行されている信頼されたカード」であることが必要であり、社員証などは通常却下されます。通常は、RP （酒屋）から利用可能なカードの選択肢が示され、手持ちのカードの中から適切なものをチョイスして見せることになります。
  • 提示するカードを全部見せる必要は必ずしもない。
    見せなければいけない情報は「生年月日」（年齢に関する情報）だけであり、カードに載っている氏名や住所、電話番号などまで見せる必要性は本来はありません。

後者に関して少し補足すると、酒屋さんが本当に知りたい情報は、年齢に関する情報だけであり、それ以外の項目は「隠してしまっても」本来は問題ありません。実際には面倒なのでまるごと見せてしまうことが多いでしょうが、原則論からいえば、必ずしも名前や住所などを酒屋さん見せる必要性はないわけです。

なお、カード上に記載された「生年月日」のような、カード上に記載されている情報のことを、セキュリティ用語で "Claim" （主張） と呼びます。

※ 日本語で「主張」というと、opinion （オピニオン）みたいなニュアンスを感じますが、そういった意味はとりあえずないと思ってもらって OK なのですが、MSDN などのドキュメントを読む際、「主張」という訳語であるがゆえに「？」となってしまうことがしばしばあります。このような場合には、それが "Claim" （カード上の情報項目）のことを指している、と思って読むとよいと思います。 私は誤解を避けるために、「主張」と呼ばずに「クレイム」と呼んでいます。

例2. 病院にかかるとき

image

病院で診察を受けるときには、健康保険証の提示を求められます。この場合の IP, Principal, RP も言うまでもないでしょうが、病院での診察のケースでは非常に面白いところがあります。それは健康保険証の提示は、初回 1 回だけ行えばよい、という点です。

通常、初回に健康保険証を提示すると、病院から診察券が発行され、その後の診察ではこの診察券を使って受診することになります。

image

こうなると、実は最初のときは RP であった病院自身が、診察券に関する IP の役割を担うことになるわけです。つまり、その病院の診察券については、病院が IP と RP の両方を兼ねる、ということになります。

実はこの RP が IP の役割を兼ねる、というケースは現実世界では極めてよくあります。いわゆるほとんどの会員カードの類はこれに準じており、初回のみ公的機関発行のカードの提示を求めたあと、以降は自社で発行したカードを使う仕組みになっているはず。このようなものは、RP が IP を兼ねることになります。

例3. バーのボトルキープ

image

最後の例として、バーでのボトルキープの例を考えてみたいと思います。バーに行くと、キープされたボトルに名刺が輪ゴムでかかっている光景がよく見られます（……いや最近はそんな光景ないかもしれませんが、一応そういうことにしといてください（笑））。このとき、普通に考えると、

  • 企業が IP。
  • お客さんが Principal。
  • バーが RP。

ということになる……のですが、チョイ悪オヤジの場合、まさかここで会社のいつもの名刺を真っ向切って出すわけにはいきません。そこで、チョイ悪オヤジは偽の名刺や自作した名刺をこっそり作っておき、ベンチャー企業の社長の肩書の偽名刺を出すわけです。（例が悪いとかいうツッコミはなしで^^） バーの側からしても、別にその人の肩書きを暴く必要はなく、本人を一意識別できさえすればよい。つまり、本物の名刺である必要性はなく（＝本人の身元保証を取る必要はなく）、偽の名刺だろうが自作した名刺だろうが、本人を一意識別できさえすればよい、ということになります。

実はこのシナリオは非常に重要です。というのも、実際にみなさんにも以下のような心当たりがないでしょうか？

  • 物販サイトでのユーザ登録で、年齢のサバを読んで登録した。
  • オンラインゲームのユーザ登録に、偽名を使った。

多くの場合、物販サイトやオンラインゲームのユーザ登録では、厳密に正しいユーザ情報を取得するよりも、気軽に登録してもらうことの方が重要なケースが多々あり、このような場合には偽名の登録でも実質的に問題なし、としているケースも少なからずあります（罰則規定などはあるにせよ）。現実のシステムでは、このようなシナリオもきちんとサポートできなければならない、ということがいえます。

ちなみにこのような偽造名刺シナリオの場合には、Principal （自分自身）が IP を兼ねることになります。自分自身が「こうだ！」と決めたものが、そのまま正しいものとして RP に示される、というわけです。

3. コンピュータシステムとの比較

さて、CardSpace を利用する・しないにかかわらず、ユーザ認証を行うコンピュータシステムでは、必ず RP, Principal, IP に相当する役割の人たちが存在します。具体例をいくつか見てみます。

例1. Windows 統合認証を利用するイントラネット Web システム

image

この場合には、IP = Active Directory、RP = Windows 統合認証を要求する Web システム、利用する身分証明用のカード = Kerberos チケット、となります。

例2. Windows LiveID 認証を求めるインターネット Web システム

いわゆる Hotmail や MSDN サイトなどは、LiveID （昔の Passport）を使った認証を行っています。

image

この場合には、以下のような役割分担になります。（実際には、RP サイト上でログインを行うと、IP サイトへのリダイレクトが行われ、クッキーなどを介して LiveID 認証サーバから RP サイトへ認証情報が引き継がれます。）

image

例3. 通常のパスワード認証を使っている Web サイト

さて、では次のような場合はどうでしょうか？

image

一般的な Web サイトでは、新規ユーザ登録時にパスワードを自分で決めて ID 登録を行います。そのあと、このパスワードを使って Web サイトにアクセスしますが、この場合の IP, RP はそれぞれどれに対応するでしょうか？

正解は以下の通り。

image

この場合の IP は、Web サイト側ではないことに注意してください。確かにパスワード確認をしているのは Web サイトなのですが、そもそも正しいパスワードが何かを決めたのは、Web サイトではなく、ユーザ側です。つまり、本人であることの証明用のデータ（パスワード＝自分を証明するカード）を自分自身で作り出していることになるため、このケースでは IP = Principal となるわけです。

ここまでのまとめ

では、ここまでの話をまとめておきます。

  • ユーザ認証がかかわるシステムでは、必ず IP, Principal, RP の 3 者が存在する。
    IP （Identity Provider） : 身分証明書を発行する立場の人、あるいは組織
    Principal : 身分証明書を使って何かをしようと思っている人
    RP （Relying Parties） : 身分証明書による確認を求める立場の人
  • カード上に記載されている、その人に関する情報項目のことを Claim （主張） と呼ぶ。
    カード上のすべての情報が必要なわけではなく、一部の Claim のみで十分なことも多い。
  • 会員カード方式では、RP が会員カードの発行元（IP）になる。
    初回のみ公的機関発行のカードを確認し、二回目以降は RP が発行した会員カードを確認するような場合には、RP が IP を兼ねることになる。
  • 自分で決定したパスワードを登録するようなシステムでは、Principal が IP となる。

引き続き次回は、ここまでの話が Windows CardSpace にどのように反映されているのか、という話をしたいと思います。

Comments

  • Anonymous
    November 26, 2008
    “某コンサルタント”さんではなかったのかと小一時間ｗ それはさておき、次回も非常に楽しみです。

  • Anonymous
    November 27, 2008
    いえ、「某」デスヨ？^^ というか、実際あんまり顔は知られてないですよ、多分。 単に例3. をやりたかっただけ、という話もありますが^^。

  • Anonymous
    December 06, 2008
    金曜日の夜はお世話になりました。 CardSpaceは今までノータッチだったので勉強させていただきます。 最近は.NETにおける更新系ビジネスロジックの基底クラスのあり方について考えています。条件は、データアクセスにTableAdapterを使う、実際のビジネスロジックを実装するプログラマにコネクション管理をさせない、トランザクション管理をさせない、例外処理を実装させない、という感じです。この辺を隠蔽化するものを作ってます。大体はできているのですが、何かしっくり来ないんですよね。。。まだまだ研究が必要そうです、、、