Windows CardSpace の紹介

David Chappell
Chappell & Associates

April 2006
日本語版最終更新日 2006 年 10 月 16 日

対象 :
   Windows CardSpace
   Windows Vista
   Windows XP
   Windows Server 2003

概要 : この記事では、さまざまなデジタル ID の処理と管理を行う標準ベースのソリューションを提供する、Windows の新機能 (コードネーム CardSpace) を紹介します。

目次

デジタル ID について
Windows CardSpace の機能
インフォメーション カードの調査
Windows CardSpace との相互運用
Windows CardSpace と他の Microsoft テクノロジ
まとめ
参考資料

デジタル ID について

あなたはだれですか。単純な質問ですが、答えは単純ではありません。ID を表す立場は、状況により変化します。空港の出入国審査でパスポートを提示するときは、ある国の市民としての立場です。スピード違反で停車を求めてきた警官に運転免許証を提示するときは、ある地域に住む正規のドライバーとしての立場です。書店でベスト セラー小説をクレジット カードで購入するときには、特定の口座番号を持つ顧客としての立場です。場が変われば、必要な ID も変わります。それぞれの ID は表現される方法と提示する情報が異なります。

このような場のいずれも、ID を証明するための方法が人々に十分に認知されています。しかし、重要な場の 1 つであるネットワークの世界では、ID がまだ混乱しています。実際の世界と同様に、私たちすべてがさまざまな "デジタル ID" を持ち、さまざまな方法でそれを表現しています。しかし今のところ、この一連のデジタル ID を処理する一貫した方法は存在しません。ややこしく、セキュリティが十分でない環境で苦労を続けています。

これからも、さまざまな種類のデジタル ID が常に必要です。1 つの ID では事足りません。また、ID は各種提供元から提供されるのが常なので、1 つの ID プロバイダで事足りないのも実情です。つまり、解決には、デジタル ID を単一のシステムに任せるのではなく、複数のデジタル ID システムを一貫して使用できる方法を見出す必要があります。必要なのは、ID に特化したシステムのシステム ("メタシステム") です。

この "ID メタシステム" を実現するには、協力が必要です。1 つの組織が一方的にソリューションを押し付けることはできません。さいわい、この問題に対処できる、特定のベンダに依存しない通信標準が存在します。SOAP と XML をベースにした、WS-Security、WS-Trust、WS-MetadataExchange、WS-SecurityPolicy などの標準です。これらの Web サービス テクノロジを使用すると、任意の提供元が任意の ID テクノロジで作成した任意のデジタル ID を処理するための、一貫した方法を定義できます。

Microsoft は、他の組織と協力しながら、標準ベースの ID メタシステムを定義するうえで大きな役割を果たしています。また、ID メタシステムを実現するために、Windows に新機能を追加しました。Windows CardSpace (以前は "InfoCard" というコードネームでした) によって、次期リリース版の Internet Explorer を始めとする Microsoft テクノロジや他社のテクノロジなど、任意の Windows アプリケーションでデジタル ID を一貫した方法で処理できます。CardSpace は、.NET Framework 3.0 の一部として Windows Vista、Windows XP、および Windows Server 2003 で使用できます。リリース予定は 2007 年初頭です。

Windows は広く使用されているオペレーティング システムなので、ID メタシステムの実現に Cardspace が重要な役割を果たします。ただし、このソリューションは他の組織が実装して初めて成功します。したがって、Microsoft は ID メタシステムに参加できるソフトウェアの作成と使用を積極的に奨励しています。目標は、人々が、実際の世界で ID を使用するときと同様に、使用するコンピュータや実行するオペレーティング システムを問わず、デジタル ID を簡単、効果的、安全に使用できるようにすることです。

デジタル ID の説明

実際の世界の ID と同様、デジタル ID もあらゆる形状とサイズのものがあります。たとえば、Yahoo の電子メール アカウントをお持ちの方は多いと思いますが、これは電子メール アドレスで識別されます。また、Amazon、eBay などの営利組織や、MySpace.com などのサイトのデジタル ID をお持ちの方もいるかと思いますが、それぞれの ID はユーザーが定義したユーザー名で識別されるのが一般的です。業務上、勤務先からデジタル ID を割り当てられる場合がありますが、これはネットワーク ログインで識別します。業務上の ID は Active Directory などのディレクトリ サービスでメンテナンスされている場合が多く、通常は社内ネットワーク内部のみで有効です。

実際の世界と同様に、状況に応じてデジタル ID を使い分けるのには、もっともな理由があります。たとえば、ID ごとに異なる情報を関連付けることがよくあります。Amazon で使用する ID はクレジット カード番号にアクセスできますが、MySpace.com で使用するアカウントはクレジット カード番号にアクセスできません。それぞれの ID を取得する規則も異なります。Amazon のデジタル ID は、ユーザー名とパスワードを決定するだけで簡単に取得できます。それに比べ、勤務先でデジタル ID を取得するのは、少なくとも社内ネットワークを運用する管理者の承認が必要になるため困難です。

デジタル ID の表現 : セキュリティ トークン

デジタル ID は多様であるにもかかわらず、すべてに共通した重要な特徴があります。すべてのデジタル ID は、ネットワークで送信されるとき、ある種の "セキュリティ トークン" として表現されます。セキュリティ トークンとは、デジタル ID についての情報を表す一連のバイト列です。図 1 に示すように、この情報は 1 つ以上の "要求" から構成されます。それぞれの要求には、この ID について伝達される情報の一部が格納されます。単純なセキュリティ トークンであればユーザー名を含んだ要求のみが格納され、複雑なセキュリティ トークンになるとユーザーの姓、名、自宅住所などを含んだ複数の要求が格納される場合があります。一部のデジタル ID のセキュリティ トークンには、クレジット カード番号などの秘密情報を含んだ要求が格納される場合もあります。

Aa480189.introinfocard01(ja-jp,MSDN.10).gif
図 1. セキュリティ トークン


大半のセキュリティ トークンには、要求が、要求を提示しているユーザーのもので間違いないことを証明するために提供される情報があります。その身元証明の単純 (であり、現在一般的) な方法の 1 つは、要求と共にパスワードを送信することです。強力な方法としては、秘密キーを使用して要求のすべてまたは一部にデジタル署名を行い、対応する公開キーを、通常は証明書にラップして提供します。身元証明の方法はどのようであれ、デジタル ID を表すセキュリティ トークンは一般に、このトークンが送信者の ID を持つ個人または組織を表していることをトークンの受信者が確認できる証明を提供します。

要求の集合であるという基本的な考え方はすべてのセキュリティ トークンに共通ですが、現状ではさまざまな表現形式が使用されています。ユーザー名をテキスト文字列として表現するだけの単純な形式もありますが、一般的には X.509 証明書、Kerberos チケットなどの複雑な形式が使用されています。ただし、これらのどの形式も、複数の要求から任意のセットを取り出して送信できる設計がされていません。デジタル ID によっては、そのような設計が便利です。業界団体 OASIS が策定した標準である Security Assertion Markup Language (SAML) で作成するセキュリティ トークンは、選択した要求のみを送信することが可能です。XML をベースにしている SAML を使用すると、要求のうち必要なセットを含むセキュリティ トークンを定義できます。

従来、デジタル ID の主な用途は認証でした。このことは、現在広く使用されているセキュリティ トークンの形式である、ユーザー名、X.509 証明書、Kerberos チケットに反映されています。これらの形式で送信される情報の大部分は、ID の認証に的を絞っています。しかし、デジタル ID も実際の ID のように幅広く使用できる必要はないでしょうか。財布に入っているすべてのカードは、一枚一枚が ID を表すだけでなく、どこかの機関が正しいと認めた有用な情報も記録しています。たとえば、運転免許証には、名前や年齢のほか、おそらく顔写真などの情報が記録されていて、そのいずれもが公的機関が正しいと認める情報です。この情報を表現するデジタル ID があれば、成人であることや視力を矯正していることを証明する場合など、さまざまな場面で役立ちます。同様に、クレジット カード一枚一枚に、あなたの名前と共にカード番号と有効期限が記録されています。このカードが実際の世界で役立つのと同様に、適切な要求を伝えるセキュリティ トークンを生成できるデジタル ID を各カードに対して作成すれば役立ちます。

セキュリティ トークンはこれまで認証情報のみを送信することに重点を置いてきましたが、デジタル ID の概念が広がったことを認識することが重要です。たとえば、クレジット カードで自分を認証することは通常ありませんが、この ID が伝えるクレジット カード番号などの情報には価値があります。事実、セキュリティと無関係な情報を伝えることができる点で、"セキュリティ トークン" という用語は不適切です。SAML などの方法を使用すると、要求するほぼあらゆる情報を含むセキュリティ トークンを定義できます。実際の世界で使用している多くの ID と同様に、ネットワークに接続した世界でもデジタル ID を幅広く使用できるようになっています。

デジタル ID の使用 : Windows CardSpace と ID メタシステム

1 つの形式のセキュリティ トークンで表現した 1 つのデジタル ID をあらゆる用途に使用できれば、面倒な生活から解放されるでしょう。しかし、実際の世界で複数の ID を使い分けているのと同じ理由で、デジタルの世界でも ID は常に使い分けます。問題は、その多様なデジタル ID を理解しやすく、効果的な方法で作成、使用および管理することです。

これこそが、ID メタシステムで対処する問題です。デジタル ID を作成および表現するために別のテクノロジを考案するのではなく、ID メタシステムによって、使用されているセキュリティ トークンの種類を問わず一貫した方法で複数のデジタル ID を処理します。ID メタシステムにはだれもが任意のプラットフォームに実装できる標準プロトコルを使用しているので、任意の種類のセキュリティ トークンを取得および使用して、ID を送信できます。

Windows CardSpace はユーザーが ID を選択する方法を提供するだけでなく、ID メタシステムで重要な役割を果たします。この記事では、CardSpace と、それをどのように ID メタシステムに統合するかについて説明します。このテクノロジが何を実現し、どのように動作するかを明確にすることがこの記事の目標です。ただし、この記事はこのシステムのベータ リリースに基づいています。いつものとおり、最終的なリリースまでに一部の仕様が変更される場合があります。

Windows CardSpace の機能

このテクノロジには、次の 4 つの際立った特徴があります。

  • 任意のデジタル ID システムに対するサポート
  • ユーザーによる一貫性のあるデジタル ID 管理
  • パスワードによる Web ログインを代替
  • リモート アプリケーションの ID に対するユーザーの信頼向上

ここでは、ID メタシステムの構成要素である CardSpace が上記の 4 つの特徴をどのように実現するかについて説明します。

任意のデジタル ID システムに対するサポート

私たちが使用する数多くのデジタル ID は、提供元も表現方法も異なります。つまり、依存しているデジタル ID システムや、それぞれのシステムで基底にしているテクノロジは通常、一様ではありません。この複雑な状況を一般化して考えるには、次の 3 種類の役割を考慮すると簡単です。

  • ユーザー - "サブジェクト" ともいいます。デジタル ID が関連付けられたエンティティです。ユーザーは人である場合が多いですが、組織、アプリケーション、コンピュータなどもデジタル ID を所有できます。
  • ID プロバイダ - ID プロバイダは、その名前が示すとおりユーザーにデジタル ID を提供する存在です。たとえば、勤務先から割り当てられるデジタル ID の場合、ID プロバイダは Active Directory などのシステムであることが一般的です。Amazon で使用するデジタル ID の場合、自分でユーザー名とパスワードを定義するので、ID プロバイダは実質的に自分自身です。デジタル ID が伝達する情報や、ユーザーが本当に名乗っているとおりの人物であることを保証する度合いは、デジタル ID を作成した ID プロバイダによって異なる場合があります。
  • 証明書利用者 - 証明書利用者とは、任意の方法でデジタル ID を利用するアプリケーションです。証明書利用者は、頻繁に ID (この ID のセキュリティ トークンを構成する要求に含まれる情報) を使用してユーザーを認証し、そのユーザーに特定の情報へのアクセスを許可するなどの承認を決定します。証明書利用者は、クレジット番号を入手する、同じユーザーが複数回情報にアクセスしていることを確認するなどの目的で、ID を使用する場合があります。証明書利用者の代表的な例として、オンライン書店、オークション サイトなどのインターネット Web サイト、および Web サービス経由で要求を受理するアプリケーションがあります。

この 3 つの役割があれば、Windows CardSpace と ID メタシステムで任意のデジタル ID をどのようにサポートするかは簡単に理解できます。図 2 に、3 つの役割の基本的な相互関係を示します。

Aa480189.introinfocard02(ja-jp,MSDN.10).gif
図 2. ユーザー、ID プロバイダ、証明書利用者の相互関係


図 2 からわかるように、ユーザーは Web ブラウザなどの CardSpace をサポートするアプリケーションを使用して、証明書利用者にアクセスできます。ID プロバイダのグループの中から、証明書利用者に提示するデジタル ID の提供元を選択することもできます。選択内容に関係なく、3 者間の基本的なデータ交換は次の 3 つの手順で行われます。

  1. まず、ユーザーがアクセスしようとしている証明書利用者が求めるセキュリティ トークンの要件をアプリケーションが取得します。

    この要件は証明書利用者の "ポリシー" に記載されています。ポリシーの内容は、証明書利用者が受理するセキュリティ トークンの形式、トークンに含まれている必要がある要求などです。

  2. 証明書利用者が必要としているセキュリティ トークンの詳細を取得したら、その情報を CardSpace に渡してセキュリティ トークンを適切な ID プロバイダから要求します。
  3. CardSpace がこのセキュリティ トークンを受け取り、アプリケーションを経由して証明書利用者に渡します。

    証明書利用者は、このトークンを使用してユーザーの認証などを行うことができます。

この概略図は、プロセスの重要な部分を示しています。詳細は次のとおりです。

  • Windows CardSpace と ID メタシステムは、ID プロバイダから要求し、証明書利用者に渡すセキュリティ トークンの形式を一切問いません。事実、CardSpace は通常、セキュリティ トークンの形式を認識すらしません。したがって、単純なユーザー名、X.509 証明書、Kerberos チケット、SAML トークンなど、任意の種類のセキュリティ トークンで、任意のデジタル ID システムと連携できます。つまり、どのようなデジタル ID テクノロジが実装されていても、それと共に CardSpace および ID メタシステムを使用できます。また、将来発表される可能性がある、未開発のデジタル ID システムをプラグインにすることもできます。
  • ID メタシステムで定義され、CardSpace で実装されているすべてのデータ交換には、公開されているオープンなプロトコルが使用されます。

    最も一般的なシナリオでは、証明書利用者のポリシーが WS-SecurityPolicy で記述され、そのポリシーを WS-MetadataExchange で取得し、セキュリティ トークンを WS-Trust で取得し、そのトークンを WS-Security で証明書利用者に送信します (ID メタシステムで ID トークンをセキュリティで保護して交換するために必要なすべての WS-* プロトコルは、現在標準化機関に提出されているか、近い将来提出されます)。

    Web ブラウザと Web サイトが連携する単純 (であり、おそらく一般的) なシナリオでは、証明書利用者のポリシーを HTML で表現して、このポリシー情報とセキュリティ トークンを共に HTTPS を使用するサイトで交換できます。ID プロバイダとの対話処理を WS-Trust に依存しますが、証明書利用者として機能するために、Web サイトに WS-* 仕様を実装する必要はありません。

    いずれのシナリオも、CardSpace と連携するために、証明書利用者または ID プロバイダが標準以外のプロトコルを実装する必要はありません。

図 2. で示したとおり、ID メタシステムで使用しているプロトコルを ID プロバイダと証明書利用者が実装している場合に限り、CardSpace は有用です。Microsoft はメタシステムを定義するために努力を注ぎ、Windows の主要なメタシステム コンポーネントとなる Windows CardSpace を作成しましたが、他の組織の参加がなくてはこの努力が実ることはありません。

ユーザーによる一貫性のあるデジタル ID 管理

セキュリティ トークンの取得と送信に使用する標準のプロトコルがあると便利です。しかし、トークンが提示するデジタル ID をユーザーが理解して的確な判断を下せる方法がなければ、システムは無用に複雑になります。したがって、CardSpace と ID メタシステムの大きな目標の 1 つは、セキュリティの専門家から皆さんのご両親に至るすべてのユーザーが、自分のデジタル ID について適切に判断できるようにすることです。

これを実現するため、CardSpace のデジタル ID を処理するユーザー インターフェイスは直感的に操作できるようになっています。図 3 に、このユーザー インターフェイスで最重要と思われる ID 選択画面を示します。

Aa480189.introinfocard03(ja-jp,MSDN.10).gif
図 3. CardSpace の ID 選択画面


このスクリーンショットからわかるように、各デジタル ID は "インフォメーション カード" (省略して、このテクノロジのコードネームの由来である "InfoCard" と呼ばれる場合もあります) として表示されます。各カードは、ユーザーが証明書利用者に提示できるデジタル ID を表します。スクリーンショットに表示されている画像以外に、各カードには特定のデジタル ID についての情報が含まれています。情報の内容は、この ID のセキュリティ トークンを取得するために通信する ID プロバイダ、その ID プロバイダが発行できるセキュリティ トークンの種類、およびセキュリティ トークンに含めることができる要求です (後で説明しますが、各インフォメーション カードは実際には ID プロバイダが作成し、ユーザーのコンピュータにインストールされます)。ユーザーは特定のカードを選択することで、特定のセキュリティ トークンを要求します。このセキュリティ トークンには、特定の ID プロバイダが作成した特定の要求セットが含まれます。しかし、このような技術的に複雑なしくみは隠されているので、ユーザーは自分にとって意味があるところを考えればよいようになっています。図 4 は図 2 を少し拡張したものです。ユーザーの決定がプロセスのどの部分に該当するかを示しています。

Aa480189.introinfocard04(ja-jp,MSDN.10).gif
図 4. ID の選択


既に説明したとおり、アプリケーションが証明書利用者のポリシーを要求することからプロセスが開始します。このポリシーは、証明書利用者が受理するセキュリティ トークンの種類、およびセキュリティ トークンに含まれている必要がある要求を示しています。このポリシー情報を取得して CardSpace に渡すと、カード選択画面が表示されます。ユーザーの操作性に一貫性を持たせるため、ユーザーがこのシステムに保有しているすべてのインフォメーション カードが表示されます。財布を開いたときに中のカードがすべて見えるのと同様です。ただし、特定の状況で受理されるカードは限られています。したがって、そのときの証明書利用者の要件に一致しないセキュリティ トークンおよび要求が関連付けられているインフォメーション カードは、送信できないようにすべて淡色表示されます。特定のカードをクリックすると、既に説明したとおり、そのカードが関連付けられた ID プロバイダに要求が発行されます。先ほどと同様、ID プロバイダからセキュリティ トークンが返され、証明書利用者に渡されます。

ユーザーが一貫した方法でデジタル ID を選択できるようにすることは、以下の 2 点で重要です。

  • 一貫した、予測可能な方法でデジタル ID を使用できます。この方法がない場合、熟練ユーザー以外は混乱を招いてエラーが発生することは必至です。CardSpace を使用するために構築したすべてのアプリケーションは、デジタル ID をまったく同じメカニズムで処理し、まったく同じインターフェイスでユーザーに提示します。
  • ユーザーが、セキュリティ テクノロジの差異を考慮する必要がなくなります。特定の ID のセキュリティ トークンが X.509 証明書か、SAML か、その他のものかを考慮する必要がありません。共通の表示を使用することで、ユーザーの操作が必要以上に複雑にならないようになっています。すべてのデータは、ユーザーに関わりがある、ID 自体とその中の情報という形で表現されます。

セキュリティを強化するため、個々のインフォメーション カードに暗証番号 (PIN) を設定して保護し、インフォメーション カードを使用する際にこの番号の入力を求めることができます。ローカル攻撃を抑止するため、ユーザーがカードを選択する ID 選択画面には、専用の Windows デスクトップが用意されます。これは、Windows へのログイン画面を分離するメカニズムと同様であり、ローカルで実行されている他のプロセスによる攻撃を防止します。

使用するデジタル ID を一貫した方法で選択できるメカニズムを提供することが、ID メタシステムの本質的な要素であることも指摘するに値します。この記事は Windows テクノロジである CardSpace に特化していますが、他のオペレーティング システムでの実装も、直感的にカードを選択できる独自の画面を用意するのが適切です。

パスワードによる Web ログインを代替

インターネットで現在使用されている最も一般的なセキュリティ トークンの種類は、単なるユーザー名です。ユーザー名が実際に本人のものであることを証明する最も一般的な方法は、ユーザー名に対応するパスワードを入力することです。ユーザー名とパスワードは、アクセスしているサイトから割り当てられる場合もありますが、多くの場合、自分で選択します。ユーザー名とパスワードを割り当てるサイトは、ブラウザとの通信に SSL を使用する場合が多いので、この方法はセキュリティが適度に保護されていると見なされています。SSL を使用すると、通信全体が暗号化されるので攻撃者が通信を傍受してもパスワードを盗み出すことはできません。

しかし、このようにパスワードを使用する方式が受けやすい攻撃が他にあります。フィッシングです。偽装した電子メール メッセージを送信し、実在するサイトの偽サイトにユーザーをログインさせて、パスワードだけでなく、時には他の個人情報も入力させます。しかし、パスワードが Web での有力な認証メカニズムでなかったら、盗み出すべきパスワードがないので、このようなフィッシングはそれほど脅威にはなりません。これを実現し、Web ログインのセキュリティを全体的に強化するため、パスワードを使用する Web ログインを CardSpace によって強力なメカニズムに差し替えることができます。

Web サイトなどの証明書利用者はユーザーを認証する際に、パスワードではなく、セキュリティ トークンを使用できます。たとえば、ある企業が、公開している一連の Web サイトのすべてのサイトが受理するトークンを発行できる ID プロバイダを、任意のクライアントからアクセスできる特定のコンピュータで実行することが可能です。この方法は、CardSpace を使用する場合に選択できる方法であり、パスワードの使用を最小限に抑えることができます。ただし、すべての Web サイトが受理するセキュリティ トークンを発行する単一の ID プロバイダは存在しないので、この方法は特定の一連のサイトのみに対して有効です。

では、ユーザーが自分でユーザー名とパスワードを選択する場合はどうなるでしょうか。現在は、この方法が Web サイトで広く使用されています。その理由の 1 つは、サードパーティの ID プロバイダを必要としない点です。この方法は、ユーザーが自分の実際のユーザー名を入力しているかどうかをサイトで確認できないので、ユーザーが本当に名乗っているとおりの人物であることはあまり保証されません。しかし、この方法を採用しているサイトでは、特定のユーザーがログインするごとにそのユーザーを認識できればよい場合が一般的です。必要なのはユーザーの一意のデジタル ID であり、そのユーザーの本当の情報は必ずしも必要ありません。

要するに問題は次のようになります。パスワードを使用したログインではフィッシングの危険があるので、これに替わる手段として、証明書利用者は ID プロバイダが作成したセキュリティ トークンを受理しようとしています。しかしほとんどの場合、そのようなトークンを作成できる、広く受け入れられているサードパーティの ID プロバイダは存在しません。最終的には同一ユーザーが複数回アクセスしていることを認識できればよいので、複雑なデジタル ID は必要ありません。

この問題に対処するため、CardSpace には "自己発行 ID プロバイダ" が含まれています。図 5 に示すとおり、この自己発行 ID プロバイダはローカルの Windows システムで実行します。他の ID プロバイダと同様にインフォメーション カードを作成します (事実、外部の ID プロバイダと自己発行 ID プロバイダを区別するため、外部の ID プロバイダを "マネージ" ID プロバイダ、そこで作成されるインフォメーション カードを "マネージ" カードと呼ぶ場合があります)。図 5 の例では、外部の ID プロバイダから取得した 3 枚のカードと、自己発行 ID プロバイダから取得した 1 枚のカードがあります。

Aa480189.introinfocard05(ja-jp,MSDN.10).gif
図 5. 自己発行 ID プロバイダから取得したインフォメーション カードを持つユーザー


自己発行 ID プロバイダが作成するインフォメーション カードには、ユーザーの名前、住所、電子メール アドレス、電話番号などの基本情報のみが格納されます。ユーザーが自己発行 ID プロバイダが作成したインフォメーション カードを証明書利用者に送信するとき、ユーザーのシステムの自己発行 ID プロバイダによって、ユーザーがそのカードに登録した情報を含んだ SAML トークンが生成されます。また、公開キーと秘密キーのペアが生成され、セキュリティ トークンに秘密キーで署名します。攻撃者が再利用しないようにするため、このセキュリティ トークンはタイムスタンプなどの情報を含んでいるので、本来のユーザー以外にとっては役に立ちません。署名されたセキュリティ トークンは、対応する公開キーと共に証明書利用者に送信されます。証明書利用者は、公開キーを使用してセキュリティ トークンのデジタル署名を確認することで、正規の所有者がトークンを提示していることを確認できます。証明書利用者が共同でユーザーの公開キーを照合してユーザーの行動を追跡することができないように、このカードを使用してアクセスする証明書利用者ごとに、異なるキー ペアが作成されます (ユーザーにはこの詳しいしくみが隠されているので、1 つの ID に対しては 1 枚のインフォメーション カードしか見えません)。

CardSpace の自己発行 ID プロバイダが作成するものを含め、大半の ID プロバイダが発行するセキュリティ トークンにはパスワードが使用されないので、Web サイトなどの証明書利用者はパスワードでなくトークンでユーザーを認証できるというのが、中心となる考え方です。サイトでパスワードを使用しなければ、フィッシャーはユーザーを騙してパスワードを入力させることができません。

フィッシングは深刻な問題です。Windows CardSpace と ID メタシステムの唯一の利点がこの問題を縮小することだとすれば、現在のオンライン世界は今後大きく改善されるでしょう。

Web アプリケーションの ID に対するユーザーの信頼向上

Web サイトがパスワードを使用したログインへの依存度を低下させれば、フィッシングに悩まされることは少なくなりますが、問題が解決するわけではありません。ユーザーが騙されてフィッシング サイトにアクセスした場合、ユーザーが提供したセキュリティ トークンが、自己発行かどうかにかかわらずそのサイトで受理され、クレジット カード番号などの情報を要求される場合があります。フィッシャーは、ユーザーが本来のサイトで使用しているパスワードを入手しない代わりに、他の有用な情報を入手するに違いありません。

問題の根源は、ユーザーが、取引銀行などの実際のサイトと、フィッシャーが設置した偽装サイトを見分けられないことです。どちらも表示されるロゴやその他の画像は同じです。フィッシャーも一般の人と同様、証明書を取得できるので、通信をセキュリティで保護するため SSL を使用できます。フィッシャーが送信した電子メール メッセージに記載されているリンクをクリックすると、ユーザーは取引銀行のサイトのようなページに接続にしたと考えます。Internet Explorer の右下には、SSL によって通信がセキュリティで保護されていることを示す小さな錠前も表示されます。

この問題を解決するには、次の 2 つが必要です。

  • Web サイトの ID をユーザーに証明する確実な方法
  • ユーザーが、サイトが提供している ID 証明がどの程度保証されているかを知ったうえで、そのサイトを信頼するかどうかを明示的に判断するための一貫した方法

この 2 つの問題に、Windows CardSpace と ID メタシステムで対処します。

最初の問題を解決するため、Web サイトが ID をユーザーに証明する方法を改善するには、使用する証明書を改善します。現在、Web サイトが ID を証明する場合、SSL 通信に使用する証明書を使用するのが一般的です。何もしないよりは良いのですが、SSL 証明書で実際に証明されるのは、特定のサイトが特定の DNS 名を持っていることのみです。この DNS 名が、そのサイトに表示されている情報に対応している保証はありません。フィッシャーが、取引銀行のサイトに似せて注意深く作成したサイトとの通信をセキュリティで保護するため、自分の所有する DNS 名用に発行された証明書を使用する場合もあります。この問題は、SSL 証明書だけでは解決できません。

この問題を解決するため、Microsoft は同業他社と協力して、新しいレベルの証明書を作成しています。この証明書には、発行を受けた組織の名前、場所、ロゴなど、従来の SSL 証明書より多くの情報を記載できます。この高保証証明書は、発行元機関との強い合意が必要であるため取得が難しく、信頼できる情報源になります。ID プロバイダと証明書利用者は、いずれもこの新しい証明書を使用して、CardSpace アプリケーションのユーザーに ID を保証できます。

高保証証明書を作成することで、上記の 2 つの問題の 1 つ目に対処します。ただし、最終的にどのサイトを信頼するかは人間が決定する必要があります。CardSpace を使用すると、ユーザーがアクセスする ID プロバイダと証明書利用者は、例外なく使用の承認を受ける必要があるので、この決定を明示的に行うことができます。あるインフォメーション カードをユーザーのシステムに初めてインストールすると、カードを発行した ID プロバイダが作成したセキュリティ トークンを受理する意思があるかどうかを確認する画面が表示されます。同様に、Web サイトなどの証明書利用者に初めてアクセスすると、この証明書利用者にデジタル ID 情報を送信する意思を確認する画面が表示されます。図 6 は、証明書利用者に初めてアクセスしたときに表示される画面の例です。

Aa480189.introinfocard06(ja-jp,MSDN.10).gif
図 6. 証明書利用者に初めてアクセスしたときに表示される画面


この例では、ID を承認中の組織 (例では Overdue Media) の名前、場所、Web サイトの URL、およびロゴが表示されます。この情報を確認した組織 (例では VeriSign) の名前とロゴも表示されます。

ユーザーが適切な決定を下せるように、ID プロバイダまたは証明書利用者が提供した証明書の種類によって画面の表示内容は変わります。先ほど説明した高保証証明書が提供された場合、図 6 で示したように、画面には組織の名前、場所、Web サイトの URL、ロゴが確認済みであることが表示され、この組織が信頼できることをユーザーに示すことができます。SSL 証明書のみが提供された場合、画面には保証されている信頼のレベルが低いことが表示されます。これより弱い証明書が提供されたか、証明書がまったく提供されない場合、画面にはこのサイトの身元を一切証明できないことが表示されます。目標は、デジタル ID を要求する ID プロバイダ、およびそのデジタル ID の受け取りを許可する証明書利用者について、ユーザーが情報を得たうえで決定できるようにすることです。

以上のことから、重大な疑問が起こります。一般的な Windows ユーザーにとって CardSpace の利点はあるのでしょうか。証明書とは何か、また、信頼できる証明機関がどこなのかがわからない分散セキュリティの初心者の方が、CardSpace を適切な判断に役立てることができるのでしょうか。少なくとも、一貫した、予測可能な方法で新しいサイトにアクセスできるようにすることは有用です。次期リリース版の Internet Explorer など、CardSpace をベースにしたアプリケーションを使用する場合、CardSpace でアクセスする各 ID プロバイダと証明書利用者について、ユーザーが明示的に使用を承認する必要があります。その際に表示される画面は毎回同じですが、この画面にはサイトの身元がどの程度保証できるかについてのメッセージが表示されます。ユーザーは、サイトを信頼するかどうかを、始めてアクセスするときにのみ決定します。それ以降にアクセスする場合は、1 か月後であっても図 6 のような画面は表示されません。アクセスしたことのあるはずのサイトにアクセスして図 6 の画面が表示された場合、フィッシング サイトに誘導された可能性が非常に高いことを示しています。

Windows CardSpace の使用 : シナリオの例

CardSpace と ID メタシステムの使用法を理解するには、代表的な例を見る方法が最も確実です。たとえば、インターネット書店などのオンライン ショップにアクセスしたときに起こることを考えます。最も単純な場合はデジタル ID が使用されていない場合で、販売している本をだれでも認証の必要なく眺めることができます。本を注文する場合はログインする必要があるので、このときデジタル ID を渡す必要があります。現在、デジタル ID を渡すにはユーザー自身が選択したユーザー名とパスワードを入力する方法が主流です。このオンライン ショップが CardSpace と ID メタシステムをサポートしている場合、ユーザーの身元を証明するためにインフォメーション カードを使用するという選択肢が加わります。これを実現するため、オンライン ショップのログイン画面に独立したボタンがあり、クリックするとユーザー名とパスワードを入力するのではなく、インフォメーション カードでログインできるようになっている場合があります。

このボタンをクリックすると、CardSpace を使用してこのサイトにログインします。通常どおり CardSpace の選択画面が表示されるので、このオンライン ショップに身元を証明するカードを 1 枚選択します。必須ではありませんが、このとき、自己発行 ID プロバイダが作成したインフォメーション カード (つまり、自分で作成したインフォメーション カード) 選択するのが一般的です。この時点でサイトはユーザーが一意の顧客として識別できればよいので、この単純な形式のデジタル ID で十分です。購入代金を支払う場合、通常どおり Web フォームにクレジット カード情報とメール アドレスを入力します。

この単純なシナリオでは、CardSpace を使用することでパスワードを入力せずにオンライン ショップにログインできます。便利な方法であり、インターネットのデジタル ID にとっての前進です。しかし、これはデジタル ID の使用の始まりに過ぎません。この例の支払いの段階で、インフォメーション カードを使用してクレジット カード情報をサイトに送信することもできます。クレジット カードの発行会社が、実際のカードに対応するインフォメーション カードを要求できる ID プロバイダを提供しているとします。サイトでは、Web フォームにクレジット カード情報を入力するのではなく、インフォメーション カードを提示するボタンを支払い画面に設置します。このボタンをクリックすると CardSpace の選択画面が表示されるので、このサイトで支払いの際に受理されるすべてのカードから選択できます。いずれかのカードをクリックすると、CardSpace はそのカードの発行者である ID プロバイダと通信して、ユーザーのクレジット カード番号が含まれたセキュリティ トークンを取得し、オンライン ショップに提示します。

この例でわかるように、デジタル ID はユーザーの身元を証明するだけではありません。財布に入っているさまざまなカードが表す実際の ID と同様に、デジタル ID は支払いなどの用途に使用できます。たとえば、運転免許証を発行する機関が ID プロバイダを公開したとします。その結果、運転免許証の所有者は、証明書利用者に対してさまざまな個人情報を証明するデジタル ID を持つことができます。たとえば米国では、ワインを購入するには成人であることを証明する必要があります。ワインのオンライン ショップは、生年月日が記載された CardSpace 版の運転免許証の提示を顧客に要求し、ワイン代金の支払いに CardSpace 版のクレジット カードを受理することができます。

この運転免許証の ID プロバイダは、他の種類のインフォメーション カードも提供できます。たとえば、名前やその他の識別情報を公開せずに、自分が成人であることを証明したいユーザーがいるとします。運転免許証の ID プロバイダはこのユーザーの年齢を把握していて、免許証のすべての登録内容が含まれたインフォメーション カードとは別に、年齢のみが含まれた簡易カードを提供する場合があります。また、年齢のように秘密情報となりうる情報を公開しないようにするため、成人であることのみを示すインフォメーション カードを該当者に提供する場合もあります。"デジタル ID" とはいっても、特定のユーザーを識別できる情報を含める必要は一切ありません。多くの場合、必要とされるのは、成人であることを示す要求など、信頼された機関の裏付けがある要求を提示する方法のみです。

Windows CardSpace と ID メタシステムの使用例は、他にも多数あります。携帯電話サービス事業者が、加入者のオンライン ショッピングの購入金額を通話料金の請求書に含めることができるインフォメーション カードを提供する場合があります。勤務先が従業員に対し、社内ネットワークの使用を許可するために複数のデジタル ID を個別のインフォメーション カードとして提供する場合があります。1 つの ID を通常のアクセスに使用して、経営について匿名で提案する用途専用に、その人物が従業員であるということ以外の情報を削除した別の ID を用意する場合があります。実際の世界の ID は、それぞれ伝える情報や用途が異なります。それと同様に、デジタル ID もさまざまな用途で使用できます。CardSpace と ID メタシステムの目標は、デジタル ID を幅広い用途で使用できるようにすることです。

インフォメーション カードの調査

ユーザーの観点で見ると、インフォメーション カードは、画面上に表示されるデジタル ID の画像表現です。一方、CardSpace にとっては、ユーザーの Windows コンピュータに格納された XML ドキュメントです。したがって、インフォメーション カードの取得方法と内容を理解することが重要です。ここでは、その 2 点を始めとする問題について説明します。

インフォメーション カードの取得方法

すべてのインフォメーション カードは、ID プロバイダが作成します。自己発行 ID プロバイダの場合、ユーザーが CardSpace のグラフィカル ツールを使用してカードを作成できます。その他の ID プロバイダの場合、他のコンピュータで実行されていることが多いので、ID プロバイダの Web サイト、ID プロバイダが送信する電子メール メッセージなどの方法で適切なカードを取得する必要があります。インフォメーション カードの取得方法は、決まった方法があるわけでなく、ID プロバイダが個別に定義します。

(自己発行 ID プロバイダが作成するものを含め) 各インフォメーション カードは、取得方法にかかわらず発行元である ID プロバイダのデジタル署名が行われ、ID プロバイダの証明書が添付されます。ID プロバイダ自体の ID を証明するためにこの署名を使用します。インフォメーション カードがユーザーのコンピュータに届いた後、カードをダブルクリックすると標準の CardSpace ストアにインストールするための画面が表示されます。既に説明しましたが、このとき、ID プロバイダをセキュリティ トークンの発行元として承認する必要があります (自己発行 ID プロバイダが作成したインフォメーション カードは、この承認が不要です)。承認が完了した後は、インフォメーション カードを使用してセキュリティ トークンを要求できます。

インフォメーション カードの内容

インフォメーション カードには、ユーザーがデジタル ID を的確に選択できるようにする内容が含まれています。インフォメーション カードと証明書利用者の要件を照合して、そのカードを発行した ID プロバイダから適切なセキュリティ トークンを取得するための内容も含まれています。この 2 つの目標を達成するため、すべてのインフォメーション カードには以下の内容が含まれています。

  • ユーザーの画面に表示されるインフォメーション カードの画像の JPEG ファイルまたは GIF ファイル、およびインフォメーション カードの名前。
  • この ID プロバイダから要求できるセキュリティ トークン 1 種類以上と、各セキュリティ トークンに含めることのできる要求の一覧。証明書利用者の要件を満たすセキュリティ トークンを作成できる ID プロバイダと、証明書利用者のポリシーを照合できます。
  • セキュリティ トークンを要求するためにアクセスできる、この ID プロバイダのエンドポイントの URL。
  • ID プロバイダのポリシーを取得できるエンドポイントを識別する URL。この後説明するとおり、この情報は ID プロバイダに対する要求を認証する方法も含みます。
  • インフォメーション カードを作成した日時。
  • インフォメーション カードの CardSpace 参照。URI として指定するグローバル一意識別子形式です。この一意識別子は、インフォメーション カードを発行した ID プロバイダが作成するもので、このインフォメーション カードを使用してセキュリティ トークンを要求するとき、毎回 ID プロバイダに渡されます。

インフォメーション カードに含まれない情報を確認しておくことも重要です。この ID についての秘密情報です。たとえば、クレジット カード会社が作成したインフォメーション カードであれば、ユーザーのクレジット カード番号を含んでいないなどです。この種の秘密情報は、ID プロバイダが作成するセキュリティ トークンに要求として現れる場合もありますが、常に ID プロバイダのシステムに保管されています。この情報をセキュリティ トークンに入れて送信するとき、通常は暗号化され、攻撃者と CardSpace からアクセスできないようになっています。要点は、秘密情報はインフォメーション カードに含まれないので、ユーザーのコンピュータにも保存されない点です。インフォメーション カードの所有者は、選択すれば、そのカードで作成されるセキュリティ トークンに現れる情報を CardSpace を使用してプレビューできます。この情報は、ユーザーがプレビューを要求するとカードを発行した ID プロバイダから読み込まれます。表示が終わった秘密情報は、ユーザーのシステムから削除されます。

インフォメーション カードを使用したローミング

複数のコンピュータから同じデジタル ID を提示したい場合が頻繁にあります。私たちの多くは、職場と自宅と外出先でコンピュータを使い分けています。それらのコンピュータ間でローミングできるようにするため、CardSpace には "カードのエクスポート" 機能があります。これは、インフォメーション カードを USB キーなどの外部記憶メディアにコピーする機能です。この機能でインフォメーション カードを他のコンピュータにインストールできるので、ユーザーは自宅のコンピュータを使用しているとき、職場のコンピュータを使用しているとき、またはホテルの部屋でラップトップを使用しているとき、いずれも同じ方法で ID プロバイダからセキュリティ トークンを要求できます。攻撃から保護するため、エクスポートしたインフォメーション カードはユーザーが選択したパスフレーズから生成したキーで暗号化されます。したがって、記憶メディアを紛失した場合でも、パスフレーズを知っている人物しか中のインフォメーション カードの暗号化を解除できません。

しかし、このソリューションが適さないシナリオもあります。たとえば、インターネット カフェで CardSpace ベースの ID を使用するとします。そのためには、インフォメーション カードをカフェのシステムにインストールする必要があります。自己管理 ID プロバイダで作成した既存の ID を使用するには、その ID に対応するキーもインストールする必要があります。だれでも使用できる共有コンピュータにこれらすべての情報を格納するのは良いことではありません。CardSpace の最初のリリースはこのシナリオに対処していませんが、近い将来、CardSpace ストアと完全な自己発行 ID プロバイダを USB ベースのハードウェアにインストールできるようにする計画があります。この機能が実現したら、コンピュータに装着したデバイスから直接セキュリティ トークンを要求できるので、使用しているコンピュータにインフォメーション カードやキーをインストールする必要がありません。

インフォメーション カードの失効

失効についても CardSpace で対処する必要があります。ID プロバイダがインフォメーション カードをユーザーに発行した後、どのように失効させるのでしょうか。最も単純な場合では、ID プロバイダ自体がこのインフォメーション カードに基づくセキュリティ トークンの発行を停止できます。たとえば、使用に有料の会員登録が必要な ID プロバイダで、会員が支払いを延滞している場合です。この場合の失効は、ID プロバイダが、このインフォメーション カードで作成したセキュリティ トークンの要求の受理を停止するだけで済みます。すべての要求は一意の CardSpace 参照を伴うので、失効したカードで作成した要求を ID プロバイダが識別するのは容易です。

少し複雑な場合として、ユーザーがインフォメーション カードを失効させることがあります。たとえば、外部の ID プロバイダが発行したインフォメーション カードがインストールされたユーザーのラップトップが攻撃者に盗まれた場合です。既に説明したとおり、各インフォメーション カードには、使用するごとに入力が必要な PIN を割り当てることができます。PIN を割り当てている場合、攻撃者は各カードの PIN も知っていないと盗んだインフォメーション カードを使用できません。また、ID プロバイダによっては、特定のインフォメーション カードで新しいセキュリティ トークンを要求するごとに、毎回パスワードの入力かスマート カードの使用をユーザーに要求している場合があります。いずれの保護策も講じていないカードのユーザーは、盗まれたインフォメーション カードの各 ID プロバイダに、カードを今後受理しないよう通知する必要があります。受理の停止は、インフォメーション カードを取得するときと同様に、標準メカニズムはありません。ユーザーが有効なインフォメーション カードをキャンセルしてそのインフォメーション カードで作成した要求の受理を停止する方法は、ID プロバイダが独自に用意する必要があります。

では、自己発行 ID プロバイダが作成したインフォメーション カードの場合はどうでしょうか。ラップトップが盗まれた場合、インフォメーション カードの ID プロバイダも盗まれたことになるので、要求の受理を停止する方法がありません。パスワードをだれかに知られた場合に、このパスワードを受理する組織にそのことを伝えるしか解決策がない状況に似ています。インフォメーション カードを、そのカードを作成した自己発行 ID プロバイダと共に紛失した場合、紛失中のカードで作成したセキュリティ トークンを受理する証明書利用者ごとに、インフォメーション カードの所有者が手動でアカウントをキャンセルする必要があります。CardSpace には、インフォメーション カードを使用したすべてのサイトを記録するカード履歴機能があるので、盗まれたラップトップの所有者はカードのバックアップ コピーを使用して、どのサイトでキャンセルする必要があるかを判断できます。

Windows CardSpace との相互運用

Windows CardSpace は .NET Framework 3.0 の一部なので、これをベースに構築したアプリケーションは必然的に Windows アプリケーションになります。しかし現在、他のプラットフォームおよびデバイスに CardSpace 互換の ID セレクタが実装されてきています。ID プロバイダと証明書利用者が Windows アプリケーションである必要はありません。ここでは、CardSpace を使用する Windows アプリケーションと連携するために、ID プロバイダと証明書利用者に必要な条件の概要を説明します。

ID プロバイダの作成

ID プロバイダは、任意のオペレーティング システムに任意の開発プラットフォームで構築できます。どのように作成したかにかかわらず、すべての ID プロバイダは、CardSpace と連携するには次の 4 つの動作を行う必要があります。

  • Microsoft が定義したカード形式と互換性のあるインフォメーション カードを作成できる必要があります。また、ユーザーがインフォメーション カードを取得する方法が必要です。
  • WS-Trust 仕様の定義に従って "セキュリティ トークン サービス (STS)" を実装している必要があります。SOAP をベースに作成されたこの仕様には、特定の要求を含んだ特定の種類のセキュリティ トークンを STS から要求する標準の方法が定義されています。すべての ID プロバイダは 1 つ以上の STS を実装する必要がありますが、STS で発行できるセキュリティ トークンの種類に決まりはなく、任意の形式のトークンを発行できます。必須ではありませんが、Microsoft が ID メタシステム向けに定義した WS-Trust の特定の拡張機能をサポートすることを強くお勧めします。
  • WS-SecurityPolicy でポリシーを定義して、WS-MetadataExchange でそのポリシーにアクセスできるようにする必要があります。既に説明したとおり、すべてのインフォメーション カードには ID プロバイダのポリシーを取得するためのエンドポイントが含まれます。図 2 および 4 ではこの手順を省略しましたが、クライアント アプリケーションが ID プロバイダからセキュリティ トークンを要求する前に、ID プロバイダに独自のポリシーがあるかどうかを問い合わせます。
  • セキュリティ トークンが要求された場合の認証方法をポリシーの中に明示する必要があります。CardSpace の最初のリリースでは、ID プロバイダにユーザーを認証するオプションを 4 つサポートしています。
    • ユーザー名/パスワード (場合によっては、インフォメーション カードを使用するごとにこの ID プロバイダのパスワードを入力する必要があります)
    • Kerberos チケット
    • X.509 v3 証明書 (ソフトウェア ベースまたはスマート カードから)
    • 自己発行 ID プロバイダが作成した SAML セキュリティ トークン

      ID プロバイダは上記の任意のオプション (すべてまたは一部) を選択できます。

ポリシーの一環として、ユーザーが証明書利用者で使用するセキュリティ トークンを要求する場合に、その証明書利用者の ID を提示する必要があることを明記できます。既定では、セキュリティ トークンを要求するとき、証明書利用者の ID は ID プロバイダに公開されません。これは、ユーザーがそのセキュリティ トークンでどのサービスにアクセスするのかを ID プロバイダに知られないようにして、ユーザーのプライバシーを保護するためです。しかし、ID プロバイダによっては、要求されているセキュリティ トークンを発行するために、証明書利用者の ID が必要になる場合があります。たとえば、Kerberos サーバーの場合、クライアントがアクセスするサービスのチケットを作成するために、そのサービスの ID を取得する必要があります。より一般的な例として、組織の Web サイトで使用する ID プロバイダを組織が独自に作成する場合、その ID プロバイダを、組織のサイトで使用するセキュリティ トークンしか発行できないようにして、他者による便乗使用を防止することがあります。

CardSpace には、エラーが発生した場合に送信できる SOAP fault も定義されています。たとえば ID プロバイダにアクセスするときに生成される場合がある SOAP fault には、セキュリティ トークンを要求する際に参照したインフォメーション カードが無効または期限切れであることや、要求された要求を含むセキュリティ トークンを作成できなかったことが示されます。

証明書利用者の作成

証明書利用者も ID プロバイダと同様に、任意のオペレーティング システムに任意の開発プラットフォームで構築できます。また、CardSpace と連携するために次の動作を行う必要があります。証明書利用者の要件を以下に示します。

  • セキュリティ トークンを受理できる必要があります。WS-Security を実装する方法が最も一般的ですが、Web サイトは HTTP で送信されたセキュリティ トークンを受理できます。
  • ポリシーを定義する必要があります。ID プロバイダと同様に、WS-SecurityPolicy でポリシーを定義して、WS-MetadataExchange でそのポリシーにアクセスできるようにする方法が最も一般的です。Web サイトはポリシーを HTML で記述して HTTP で送信できます。
  • 証明書を公開する必要があります。WS-* 仕様を実装している証明書利用者が証明書を公開するには、Microsoft が定義した WS-Addressing エンドポイント参照の拡張機能を使用します。WS-Addressing の EndpointReference に Identity 要素を追加することで、証明書利用者の証明書を標準の方法でクライアントに公開できます。

証明書利用者は、どのような種類のセキュリティ トークンも受理します。必須ではありませんが、多くの証明書利用者は CardSpace の自己発行 ID プロバイダが作成したセキュリティ トークンを受理します (そのようなセキュリティ トークンをサポートすることを示すため、証明書利用者がポリシーに記載する特定の値が Microsoft によって定義されています)。証明書利用者がどのようなセキュリティ トークンを受理しても、SAML トークンを Windows セキュリティ識別子 (SID) や UNIX ユーザー識別子 (uid) に変換するなどして、その情報をローカル ID にマップできます。

ID プロバイダの場合と同様に、Web サービスで証明書利用者と対話処理を行っているときにエラーが発生した場合に送信できる SOAP fault が定義されています。たとえば、証明書利用者にアクセスするときに生成される場合がある SOAP fault は、セキュリティ トークン内の要求の 1 つが無効であることや、要求した要求がないことが示されます。

Windows CardSpace と他の Microsoft テクノロジ

新しい Microsoft 製品やサービスの多くがそうであるように、CardSpace も Windows の世界の他の部分に影響を及ぼします。この、デジタル ID にとっての新しい取り組みが影響するテクノロジで特に重要なのが、Internet Explorer (IE)、Windows Communication Foundation (WCF)、Active Directory、および Windows Live ID です。ここでは、それぞれのテクノロジが CardSpace とどのように関連するかについて説明します。

Windows CardSpace と Internet Explorer

Microsoft の Web ブラウザの次期リリースである Internet Explorer 7 では、デジタル ID を CardSpace に任せることができます。現在、インターネットへのアクセス手段として最も広く使用されている IE は、この新しい ID テクノロジにとって重要なアプリケーションです。通常、CardSpace は全面的に SOAP ベースのプロトコルで通信します。しかし、既に説明したとおり、Web サイトは HTML および HTTP を使用して IE 7 (およびおそらく他の Web ブラウザも含む) と対話処理を行うことができます。

図 7 にその方法の 1 つを示します。

Aa480189.introinfocard07(ja-jp,MSDN.10).gif
図 7. Windows CardSpace と Internet Explorer 7


  1. ブラウザのユーザーが Web サイト上の保護されたページ (オンライン ショップの商品購入ページなど) にアクセスすると、プロセスが開始します。このとき、ユーザーはサイトへのログインを要求され、ブラウザがログイン ページにリダイレクトされます。
  2. リダイレクトの結果、ブラウザにログイン フォームが送信されます。

    通常どおり、このフォームにユーザー名とパスワードを入力してサイトにログインすることもできますが、サイトが CardSpace ログインをサポートしている場合、フォームのあるページには特定の OBJECT タグまたは XHTML 構文が追加されます。追加される情報の内容はサイトのポリシーです。この情報により、ブラウザにはWindows CardSpace ログイン オプションが表示されます。

  3. ユーザーがこのオプションを選択すると、ログイン プロセスで CardSpace を使用することを要求するコードが実行されます。実行コードは OBJECT タグまたは XHTML 構文で識別されます。
  4. CardSpace 画面が表示され、ユーザーが ID を選択します。
  5. このサイトとのここまでのすべての通信は HTTP を使用しています。しかし、ユーザーが ID を選択した後は、通常どおり WS-Trust を使用して関連する ID プロバイダと通信し、セキュリティ トークンを取得します。
  6. 取得したトークンはログイン プロセスの途中、HTTP POST を使用して Web サイトに送信されます。

    Web アプリケーションでは、セキュリティ トークンをユーザーの認証などに使用できます。

このシナリオの ID プロバイダは、ユーザーのシステムでローカルに実行している自己発行 ID プロバイダか、外部のプロバイダかを問いません。Web サイト自体で独自のセキュリティ トークン サービスを提供して、そのサイトで使用するカスタム トークンを生成することもできます。これは、認証動作の大半を専用サーバーで行うことができるので、アプリケーション固有のトークンを提供するサイトや、トラフィックの多いサイトにとって合理的な選択肢です。

このプロセスに、IE 固有の要素が一切ないことも指摘しておきます。任意のオペレーティング システムの任意のブラウザで、同じように ID メタシステムを使用できます。Microsoft は、Windows 上で、他のベンダの Web ブラウザを含めた任意のアプリケーションが CardSpace でデジタル ID を管理および使用できるようにすることを目標として明言しています。

Windows CardSpace と Windows Communication Foundation

Windows Communication Foundation は、サービス指向のアプリケーションを構築するための次期 Microsoft プラットフォームです。WCF には、WS-Security、WS-SecurityPolicy、WS-Trust、WS-MetadataExchange など、CardSpace および ID メタシステムで使用する相互運用プロトコルがすべて実装されています。CardSpace 自体も大部分が WCF をベースに作成されています。当然のことですが、WCF を使用すると、証明書利用者、ID プロバイダ、または CardSpace クライアントとして機能するアプリケーションを簡単に作成できます。

その方法を理解するには、(操作を実装する) WCF サービスと (操作を呼び出す) WCF クライアントについて若干の知識が必要です。すべての WCF サービスは、サービスの操作にアクセスするための "エンドポイント" を 1 つ以上公開します。すべての WCF クライアントは、通信先のエンドポイントを指定します。サービスとクライアントはいずれも、エンドポイントの "バインディング" を指定します。バインディングは、SOAP メッセージを送信するためのプロトコル、セキュリティの実装方法などを定義します。たとえば、WsHttpBinding というバインディングは、SOAP メッセージを HTTP で送信し、WS-Security をサポートすることなどを示します。また、WCF では、WS-SecurityPolicy で表現した、アプリケーション ポリシーのわかりやすい説明が自動的に作成されます。

必須ではありませんが、.NET Framework 3.0 をサポートする Windows システムで ID プロバイダと証明書利用者を実装する場合、WCF で実装することが多くなると考えられます。ID プロバイダまたは証明書利用者を作成するために必要な作業は、前のセクションに記載した要件の一覧に準拠する WCF サービスを構築することのみです。要件に準拠し、WsHttpBinding などの適切な WCF バインディングを選択している限り、アプリケーションは CardSpace に参加できます。

ただし、デジタル ID の指定に CardSpace を使用する WCF クライアント アプリケーションを作成するには、CardSpace ソフトウェアを直接使用する必要があります。WCF アプリケーションが認証に CardSpace を使用することを示す特別なバインディングが用意されています。WCF クライアントが通信先のエンドポイント (証明書利用者が実装しているエンドポイント。証明書利用者が WCF をベースに作成されているかどうかを問いません) との間にこのバインディングを指定している場合、セキュリティ トークンを要求すると、自動的に CardSpace が呼び出されます。CardSpace 選択画面が通常どおり表示され、ユーザーは送信するデジタル ID を選択します。自動的に適切な ID プロバイダと通信してセキュリティ トークンを取得し、WCF アプリケーションの出力要求に挿入します。開発者は、使用する適切なバインディングを指定するだけで、他の動作を CardSpace に任せることができます。

Windows CardSpace と Active Directory

Active Directory は ID プロバイダの重要な候補として、疑問の余地がありません。しかし、CardSpace は 2007 年初頭のリリースを予定していますが、それ以前の Active Directory の新しいリリースは予定されていません。Microsoft は、Active Directory に最終的に ID プロバイダとしての機能を実装すると発表していますが、この機能が利用できるようになる時期については明言していません。

差し迫っては、CardSpace と Active Directory フェデレーション サービス (ADFS) がどのように関連するかという疑問があります。ADFS は既に利用できます。当初、ADFS は CardSpace に類似するものと見られていました。しかし実はこの 2 つのテクノロジはまったく異なります。CardSpace には、いずれもクライアント コンピュータで実行できる ID セレクタと自己発行 ID プロバイダがあります。ADFS は、WS-Federation を使用して、Active Directory を使用する組織が ID を他の組織と統合するためのサーバー ベースのソフトウェアです。もう一つ重要な違いがあります。CardSpace を使用するブラウザは前のセクションで説明したとおり能動的な役割を果たしますが、ADFS はブラウザに認識されないのでブラウザの役割は受動的です。CardSpace と ADFS は、いずれも ID に関係していますが、機能は大きく異なります。

Windows CardSpace と Windows Live ID

Microsoft Windows Live ID システム (以前は Passport と呼んでいました) は、もともとインターネット上のどのサイトでも使用できる標準の認証システムを目指していました。この最初の取り組みから発展したネットワークは、現在、大部分が Microsoft 自体の運営するサイトから構成されています。Windows Live ID は 1 日に処理するログインが 10 億に迫るまでになりましたが、Microsoft ほどの巨大な組織でも、1 つの組織がインターネット上の全サイトで使用される単独の ID プロバイダになることは不可能という明確な教訓を得ました。

CardSpace と ID メタシステムは、ID と ID プロバイダに対する見方を広げて、根本から異なる方法を採用しました。Microsoft は、Windows Live ID を ID プロバイダとして機能するように変更すること、およびユーザーが CardSpace を使用して Windows Live ID アカウントにサインインできるようにすることを発表しています。しかし、CardSpace は Windows Live ID に依存しません。また、Windows Live ID が将来提供する ID プロバイダが ID メタシステムの中で特別な役割を果たすことはありません。

まとめ

ID メタシステムで提供されるソリューションが重要であるのと同様に、ID メタシステムで対処する問題も重要であることは明白です。さまざまなデジタル ID を扱う標準の方法があれば、ネットワークの世界も実際の世界と同様に便利で安全になります。ユーザーが状況によって使用する ID を選択できるようなれば、ユーザーは自分のデジタル ID の使用法に直接責任を負うことになります。自己発行 ID を含めたデジタル ID を使用することで、パスワードで Web にログインする必要を減らすことができます。また、ユーザーが Web サイトの ID をいっそう信頼できるようになれば、多くのユーザーを苦しめるフィッシング攻撃を減らすこともできます。

Windows CardSpace はこのようなソリューションの重要部分です。しかし、他のオペレーティング システム用のソフトウェアを作成する皆さん、ID プロバイダを作成する皆さん、および証明書利用者を提供する皆さんが、標準の Web サービス プロトコルを実装して、この ID メタシステムの相互運用が実現するまで、この取り組みは終わりません。Microsoft は Windows 用のソフトウェアを提供することで役割を果たしていますが、単独では ID メタシステムのビジョンを成功させることができません。他の組織も、デジタル ID を効果的に使用することで得られる利点について理解し、この取り組みへの参加を選択することが必要です。

しかし、CardSpace は広く利用されるものと考えられます。CardSpace のベースになっている ID メタシステムはオープンなプロトコルを使用しているので、ID プロバイダや証明書利用者を始めとする ID セレクタ用の CardSpace 互換ソフトウェアは、任意のプラットフォームまたはデバイスに構築できます。また、CardSpace は直感的に操作できる単一のインターフェイスを公開しているので、Windows ソフトウェアであれば一貫した、予測可能な方法で使用できます。以上のすべての事実から、Windows CardSpace はデジタル ID に関心があるすべての人にとって重要になるに違いありません。

参考資料

訳注 : 下記の資料はいずれも英語版のみです。

記事

The Laws of Identity (英語)

Web サイト

Windows CardSpace Developer Center

ブログ

著者について

David Chappell (英語) leave-ms は、カリフォルニア州サンフランシスコにある Chappell & Associates の社長です。全世界のプロの技術者がエンタープライズ ソフトウェアを理解して使用し、的確な判断を下せるようにするために、講演、執筆、コンサルティングを行っています。


表示: