Windows CardSpace の概要

 

David Chappell
Chappell & Associates

2006 年 4 月

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

概要： この記事では、さまざまなデジタル ID を操作および管理するための標準ベースのソリューションを提供する、CardSpace という名前の一連の新しい Windows 機能コードについて説明します。 (25ページ印刷)

内容

デジタル ID について
Windows CardSpace で提供される内容
情報カードの調査
Windows CardSpace との相互運用
Windows CardSpace とその他の Microsoft テクノロジ
まとめ
関連項目

デジタル ID について

ユーザーはだれか これは簡単な質問ですが、簡単な答えはありません。 世界を移動するにつれて、ID を表す方法が変わります。 空港の入国管理デスクでパスポートを提示する場合、あなたは国の市民です。 スピードを出すためにあなたを止めた警察官に運転免許証を見せるとき、あなたは何らかの地域に住んでいる法的な運転手です。 クレジット カードを使用して書店でベストセラーの小説の支払いを行う場合、特定のアカウント番号を持つ顧客になります。 コンテキストごとに異なる ID が必要であり、それぞれが異なる方法で表現され、異なる情報を提供します。

これらのコンテキストはすべて、ID を確立するための十分に理解された方法を持っています。 しかし、1 つの非常に重要なコンテキスト (ネットワーク化された世界) では、ID は現在、はるかに泥だらけです。 物理的な世界と同様に、私たち全員がさまざまな デジタル ID を持ち、さまざまな方法で表現されています。 しかし、今日では、このデジタル ID のポートフォリオに対処する一貫した方法はありません。 代わりに、複雑で混乱を招き、安全でない環境で苦労しています。

ただし、さまざまな種類のデジタル ID が常に必要になります。1 つの ID で十分な ID はありません。 実際には、これらの ID は常にさまざまなソースによって提供されます。1 つの ID プロバイダーで十分な ID プロバイダーもありません。 つまり、ソリューションでは、デジタル ID 用に 1 つのシステムを要求するのではなく、複数のデジタル ID システムを使用する一貫した方法を見つけることです。 必要なのは、ID に重点を置いたシステムのシステム ( メタシステム) です。

この ID メタシステム を現実にするためには、協力が必要です。 一方的に解決策を課すことができるorganizationは 1 つもありません。 幸いなことに、この問題に対処するために使用できるベンダーに依存しない通信標準が存在します。 SOAP と XML に基づく標準には、WS-Security、WS-Trust、WS-MetadataExchange、WS-SecurityPolicy が含まれます。 これらの Web サービス テクノロジを使用すると、任意の ID テクノロジを使用して、任意のソースによって作成された任意のデジタル ID を操作するための一貫した方法を定義できます。

Microsoft は、他のユーザーと協力して、この標準ベースの ID メタシステムを定義する上で大きな役割を果たしてきました。 また、Microsoft は、ID メタシステムを現実にするのに役立つ新しい機能を Windows に追加しています。 Windows CardSpace (もともとはコード名が "InfoCard" である) を使用すると、インターネット エクスプローラーの次のリリースや他のユーザーによって作成されたテクノロジなどの Microsoft テクノロジを含むすべての Windows アプリケーションが、ユーザーにデジタル ID を操作する一般的な方法を提供できます。 .NET Framework 3.0 の一部である CardSpace は、Windows Vista、Windows XP、Windows Server 2003 で使用でき、2007 年初めにリリースされる予定です。

Windows は広く使用されているオペレーティング システムであるため、Cardspace は ID メタシステムを現実にするための重要な部分です。 ただし、他の組織でも実装しない限り、このソリューションは成功しません。 したがって、Microsoft は、ID メタシステムに参加できるソフトウェアの作成と使用を積極的に奨励しています。 目標は、あらゆるコンピューターでオペレーティング システムを実行し、デジタル ID を、現在の物理的な世界で使用するのと同じくらい簡単かつ効果的かつ安全に使用できるようにすることです。

デジタル ID の記述

現実世界の ID と同様に、デジタル ID はすべての形とサイズで提供されます。 たとえば、電子メール アドレスで識別された Yahoo の電子メール アカウントがある可能性があります。 また、Amazon や eBay などのさまざまな商業組織とのデジタル ID と、MySpace.com などのサイトの ID を持つ場合もあります。 これらのそれぞれは、通常、定義したユーザー名によって識別されます。 職場では、ネットワーク ログインによって識別される、雇用主によってデジタル ID が割り当てられている場合があります。 この ID は、Active Directory などの一部のディレクトリ サービスによって管理されている可能性があり、現在は通常、会社のネットワークの境界内でのみ役立ちます。

現実の世界と同様に、さまざまなコンテキストで異なるデジタル ID を使用する正当な理由があります。 たとえば、さまざまな情報を各 ID に関連付けるのが一般的です。 Amazon で使用する ID ではクレジットカード番号へのアクセスが許可される場合があり、MySpace.com で使用される ID はアクセスできません。 各 ID を取得するための規則も異なります。 Amazon でデジタル ID を取得するのは簡単です。ユーザー名とパスワードを構成するだけです。 少なくとも会社のネットワークを実行する管理者の承認が必要であるため、雇用主でデジタル ID を取得することはおそらくやや困難です。

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

その多様性にもかかわらず、デジタル ID には共通点が 1 つあり、ネットワーク上で送信される場合、すべてのデジタル ID は何らかの 種類のセキュリティ トークンによって表されます。 セキュリティ トークンは、デジタル ID に関する情報を表すバイトのセットにすぎません。 図 1 に示すように、この情報は 1 つ以上のクレームで構成され、各 クレームには、この ID について伝達される合計情報の一部が含まれています。 単純なセキュリティ トークンには、ユーザー名を含む要求のみが含まれる場合があります。さらに複雑なセキュリティ トークンには、ユーザーの名、姓、ホーム アドレスなどを含む要求が含まれる場合があります。 一部のデジタル ID のセキュリティ トークンには、クレジット カード番号などの機密情報を含むクレームも含まれる場合があります。

図 1. セキュリティ トークン

ほとんどのセキュリティ トークンでは、これらの要求が実際に提示しているユーザーに属していることを証明するために、一部の情報が提供されます。 これを行う簡単な (現在非常に一般的な) 方法の 1 つは、要求と共にパスワードを送信することです。 より強力な方法は、秘密キーを使用してクレームのすべてまたは一部にデジタル署名し、対応する公開キー (証明書でラップされている場合があります) を提供することです。 ただし、デジタル ID を表すセキュリティ トークンは、一般的に何らかの証拠を提供します。これにより、トークンの受信者は、このトークンが実際にその ID を持つ個人またはorganizationを表していることを確認できます。

すべてのセキュリティ トークンの基本的な考え方は同じですが、これはクレームのコレクションであり、現在、これらのトークンを表すためにさまざまな形式が使用されています。 最も簡単な例は、テキスト文字列として表されるユーザー名にすぎませんが、X.509 証明書や Kerberos チケットなどのより複雑な形式も一般的です。 ただし、これらの形式は、任意のクレーム セットを伝達できるように設計されたものではありません。一部のデジタル ID には非常に役立ちます。 業界グループ OASIS によって作成された標準である Security Assertion Markup Language (SAML) を使用して作成されたトークンでは、これを許可します。 XML に基づいて、SAML を使用して、必要なクレームのセットを含むセキュリティ トークンを定義できます。

従来、デジタル ID は主に認証に使用されてきました。 現在最も一般的なセキュリティ トークン形式 (ユーザー名、X.509 証明書、Kerberos チケット) は、この形式を反映しています。これは、それらが保持する情報の大部分が ID の認証に重点を置いているためです。 しかし、デジタル ID が実際の ID ほど広範囲に役立つべきではないのはなぜですか? ウォレット内のすべてのカードには何らかのアイデンティティが反映されており、それぞれが一部の機関が主張する有用な情報も含まれています。 たとえば、運転免許証には、名前、年齢、おそらく写真、その他の情報が含まれており、すべて政府のorganizationによって正しいと主張されています。 この情報を表現したデジタル ID は、21 歳以上であることを証明したり、実際にメガネを着用したりするなど、さまざまなことに役立つ場合があります。 同様に、各クレジット カードには、名前と共にカード番号と有効期限が含まれます。 これらのカードが物理的な世界で役立つのと同様に、適切なクレームを含むセキュリティ トークンを生成するために使用できる各カードのデジタル ID を作成することも役立ちます。

セキュリティ トークンは、これまで認証情報のみを伝達することに重点を置いてきましたが、デジタル ID の概念がこれよりも広いことに気づくことが重要です。 たとえば、通常はクレジット カードを使用して自分自身を認証することはありませんが、クレジット カード番号など、この ID が伝える情報は依然として価値があります。 実際、 トークンはセキュリティ とは関係のない情報を持つ可能性があるため、セキュリティ トークンという用語は誤った用語です。 SAML やその他の方法を使用して、必要な情報をほとんど含むセキュリティ トークンを定義できます。 デジタル ID は、実際の世界で使用する多くの ID と同じように、ネットワーク化された世界で広く役立つようになりました。

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

1 つのセキュリティ トークン形式で表される 1 つのデジタル ID を、すべてに使用できれば、寿命は簡単になります。 しかし、物理的な世界で異なる ID を持っているのと同じ理由から、デジタルの世界では常に異なる ID を持つことになります。 課題は、これらの多様なデジタル ID を理解可能かつ効果的な方法で作成、使用、管理する方法です。

これは、ID メタシステムが対処する問題です。 ID メタシステムは、デジタル ID を作成して表現するためのもう 1 つのテクノロジを発明するのではなく、使用するセキュリティ トークンの種類に関係なく、複数のデジタル ID を操作するための一貫した方法を提供します。 ID メタシステムは、誰でも任意のプラットフォームに実装できる標準プロトコルを使用して、あらゆる種類のセキュリティ トークンを取得して使用して ID を伝達できるようにします。

ユーザーが ID などを選択する方法を提供することで、Windows CardSpace は 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 を使用してクレジット カード番号を取得したり、同じユーザーが別の時間にアクセスしていることを確認したり、その他の目的で使用したりする場合もあります。 証明書利用者の一般的な例としては、オンライン書店やオークション サイトなどのインターネット Web サイトや、Web サービスを通じて要求を受け入れるアプリケーションなどがあります。

これら 3 つのロールを考えると、Windows CardSpace と ID メタシステムがデジタル ID をサポートする方法を理解することは困難ではありません。 図 2 は、3 つのロール間の基本的な相互作用を示しています。

図 2. ユーザー、ID プロバイダー、証明書利用者ロール間の相互作用

図 2 に示すように、ユーザーは、Web ブラウザーなどの CardSpace をサポートするアプリケーションに依存して、複数の証明書利用者のいずれかにアクセスする場合があります。 また、証明書利用者に提示するデジタル ID のソースとして、ID プロバイダーのグループから選択することもできます。 彼女が何を選択しても、これらの当事者間の基本的な交換には、次の 3 つの手順があります。

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

   この情報は証明書利用者の ポリシーに含まれており、証明書利用者が受け入れるセキュリティ トークン形式や、それらのトークンに含める必要がある要求の正確な内容などが含まれます。

2. 証明書利用者が必要とするセキュリティ トークンの詳細を取得すると、アプリケーションはこの情報を CardSpace に渡し、適切な ID プロバイダーにトークンを要求するように要求します。

3. このセキュリティ トークンを受信すると、CardSpace によってアプリケーションに付与され、証明書利用者に渡されます。

   証明書利用者は、このトークンを使用してユーザーを認証したり、他の目的で使用したりできます。

この概要ビューは、プロセスの最も重要な側面を示しています。 次に例を示します。

• Windows CardSpace と ID メタシステムは、ID プロバイダーから要求され、証明書利用者に渡されるセキュリティ トークンの形式に完全に依存しません。 実際、CardSpace は通常、このトークンの形式を認識していません。 このため、CardSpace は、単純なユーザー名、X.509 証明書、Kerberos チケット、SAML トークンなど、あらゆる種類のセキュリティ トークンを使用して、任意のデジタル ID システムと連携できます。 これにより、CardSpace と ID メタシステムをデジタル ID テクノロジと共に使用できます。 また、将来表示される可能性のある、まだ作成されていないデジタル ID システムを接続することもできます。

• ID メタシステムによって定義され、CardSpace によって実装されるすべての交換は、公開されたオープン プロトコルを使用して行われます。

  最も一般的なシナリオでは、証明書利用者のポリシーは WS-SecurityPolicy を使用して記述され、そのポリシーは WS-MetadataExchange を使用して取得され、セキュリティ トークンは WS-Trust を使用して取得され、そのトークンはWS-Securityを使用して証明書利用者に伝達されます (ID メタシステム内の ID トークンのセキュリティで保護された交換を可能にするために必要な WS-* プロトコルが標準本体に送信される (または間もなく送信される場合)。

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

  どちらのシナリオでも、CardSpace を使用する場合、証明書利用者や ID プロバイダーが独自のプロトコルを実装する必要はありません。

図 2 に示すように、CardSpace は、ID プロバイダーと証明書利用者が ID メタシステムで使用されるプロトコルを実装する場合にのみ役立ちます。 Microsoft はメタシステムを定義する取り組みを主導しており、Windows の主要なメタシステム コンポーネントを提供するために Windows CardSpace を作成していますが、他の組織からの参加がなければ、この作業は成功できません。

デジタル ID の一貫したユーザー制御

セキュリティ トークンを取得および送信するための標準プロトコルを用意することは、確かに役立ちます。 しかし、ユーザーがこれらのトークンが表すデジタル ID を理解して賢明な決定を下す方法がなければ、システムは無駄な複雑さに陥ります。 したがって、CardSpace と ID メタシステムの主な目標の 1 つは、セキュリティ スペシャリストから、お母さん、お父さんまで、ユーザーがデジタル ID の使用について適切な意思決定を行えるようにすることです。

これを実現するために、CardSpace はデジタル ID を操作するための直感的なユーザー インターフェイスを実装します。 図 3 は、おそらくこのインターフェイスの最も重要な部分である、ID の選択に使用される画面の表現を示しています。

図 3: CardSpace ID の選択画面

このスクリーンショットに示すように、各デジタル ID は情報カードとして表示され、場合によっては InfoCard (このテクノロジのコード名のソース) のみに短縮されます。 各カードは、ユーザーが証明書利用者に提示できる可能性のあるデジタル ID を表します。 スクリーンショットに示されている視覚的な表現と共に、各カードには特定のデジタル ID に関する情報も含まれています。 この情報には、この ID のセキュリティ トークンを取得するために接続する ID プロバイダー、この ID プロバイダーが発行できるトークンの種類、およびこれらのトークンに含めることができる正確な要求が含まれます。 (後述するように、カード各情報は実際には ID プロバイダーによって作成され、ユーザーのコンピューターにインストールされます)。特定のカードを選択することで、ユーザーは実際には、特定の ID プロバイダーによって作成された特定の一連の要求を含む特定のセキュリティ トークンを要求することを選択します。 しかし、この技術的な複雑さは隠されているため、ユーザーは自分に意味のある観点から自由に考えることができます。 図 4 は、図 2 の少し拡張されたバージョンで、ユーザーの決定がプロセスに適合する場所を示しています。

図 4: ID の選択

前述のように、プロセスは証明書利用者のポリシーを要求するアプリケーションから始まります。 このポリシーは、この証明書利用者が受け入れ可能なセキュリティ トークンの種類と、それらのトークンに含める必要がある要求を示していることを思い出してください。 この情報が返されて CardSpace に渡されると、カード選択画面が表示されます。 ユーザーに一貫したエクスペリエンスを提供するために、ウォレットを開いたときにウォレット内のすべてのカードが表示されるのと同様に、このシステムで所有しているすべての情報カードが表示されます。 ただし、どの状況でも一部のカードのみが適用されるため、関連付けられたセキュリティ トークンと要求がこの証明書利用者の要件と一致しない情報カードは淡色表示されます。つまり、ユーザーはカードを送信できません。 ユーザーが特定のカードをクリックすると、CardSpace は前述のように、そのカードに関連付けられている ID プロバイダーに要求を発行します。 以前と同様に、ID プロバイダーは証明書利用者に渡されるセキュリティ トークンを返します。

ユーザーがデジタル ID を選択するための一貫した方法を提供することは、次の 2 つのメインの理由から重要です。

• ユーザーは、デジタル ID を一貫した予測可能な方法で使用できます。 これがなければ、専門家を除くすべてのユーザーにとって、結果は確かに混乱とエラーになります。 CardSpace を使用するように構築されたすべてのアプリケーションは、デジタル ID を操作するためにまったく同じメカニズムを使用し、まったく同じインターフェイスを介してユーザーに提示します。
• ユーザーは、セキュリティ テクノロジの違いから保護されます。 特定の ID のセキュリティ トークンが X.509 証明書、SAML、またはその他の方法で表現されているかどうかは気にしないでください。 共通の視覚的表現を提供することで、CardSpace はユーザーがこの不必要な複雑さに直面しないようにします。 ユーザーが何に関心を持っているか、つまり ID 自体と、それに含まれる情報という点で、すべてが表現されます。

セキュリティを強化するために、ユーザーは個人識別番号 (PIN) を使用して個人情報カードを保護することを選択できます。ユーザーは、カード情報を使用する前にこの値を入力する必要があります。 また、ローカル攻撃をさらに阻止するために、CardSpace は ID 選択画面用のプライベート Windows デスクトップを作成し、ユーザーがカードを選択できるようにします。 これは、Windows ログイン画面を分離するために使用されるメカニズムに似ています。また、ローカルで実行されている他のプロセスによる攻撃を防ぎます。

ユーザーが使用するデジタル ID を選択するための一貫したメカニズムを提供することは、ID メタシステムの本質的な部分であることを指摘する価値があります。 このペーパーでは、Windows テクノロジである CardSpace に焦点を当てていますが、他のオペレーティング システムでの実装では、カードを選択するための独自の直感的な画面を提供する必要があります。

Password-Based Web ログインの置き換え

現在インターネット上で最も一般的な種類のセキュリティ トークンは、単なるユーザー名です。 ユーザー名が実際にあなたのものであることを証明する最も一般的な方法は、それに関連付けられているパスワードを指定することです。 アクセスするサイトによってユーザー名とパスワードが割り当てられる場合がありますが、より一般的には両方を自分で選択します。 これを行うサイトでは通常、ブラウザーとの通信に SSL が使用されるため、このアプローチは合理的に安全であると見なされています。 SSL を使用すると、通信全体が暗号化されるため、攻撃者は通信をリッスンしてパスワードを盗むできなくなります。

しかし、このようなパスワードベースのスキームは、フィッシングという別の種類の攻撃に対して脆弱です。 詐欺的な電子メール メッセージを送信することで、攻撃者はユーザーをだまして実際のサイトの偽のコピーにログインさせ、パスワードやその他の個人情報を明らかにしようとします。 ただし、パスワードが Web 上の主要な認証メカニズムではない場合、この種のフィッシングは脅威の少なくなります。盗むパスワードはありません。 これを可能にし、一般に Web ログインのセキュリティを向上させるために、CardSpace ではパスワードベースの Web ログインをより強力なメカニズムに置き換えます。

Web サイトなどの証明書利用者は、パスワードを使用してユーザーを認証するのではなく、セキュリティ トークンを使用してユーザーを認証する可能性があります。 たとえば、Web サイトのファミリを提供する会社は、何らかのマシンで実行され、任意のクライアントからアクセスできる ID プロバイダーを提供する場合もあります。このプロバイダーは、そのファミリ内のすべてのサイトで受け入れられるトークンを発行できます。 この方法により、パスワードの使用が最小限に抑えられます。これは確かに CardSpace で使用できるオプションです。 ただし、セキュリティ トークンを発行するためにすべての Web サイトが受け入れる ID プロバイダーが 1 つないため、特定のサイト セットにのみ適用されます。

また、ユーザーが自分のユーザー名とパスワードを選択する場合はどうでしょうか。 このアプローチは、現在、Web サイトで非常に広く使用されています。これは単純であるためです。サードパーティの ID プロバイダーは必要ありません。 サイトはユーザーが提供する名前が実際に自分の名前であるかどうかを知ることができないため、ユーザーが本当に誰であるかを保証するものではありません。 ただし、通常、この方法を使用するサイトでは、ログインするたびに特定のユーザーを認識するだけで済みます。 これが必要なのは、そのユーザーに固有のデジタル ID であり、必ずしも彼または彼女に関する真の情報を含むものではありません。

簡単に言うと、問題は、証明書利用者が ID プロバイダーによって作成されたセキュリティ トークンを受け入れたいということです。そうすると、フィッシングされる可能性があるパスワードベースのログインを置き換えることができるためです。 ただし、ほとんどの場合、これらのトークンを作成するために広く受け入れられているサードパーティの ID プロバイダーはありません。 しかし、目標は同じユーザーによる複数のアクセスを認識するだけなので、複雑なデジタル ID は必要ありません。

この問題に対処するために、CardSpace には 自己発行の ID プロバイダーが含まれています。 図 5 に示すように、この自己発行 ID プロバイダーはローカル Windows システムで実行され、他の ID プロバイダーと同様に情報カードを生成できます。 (実際には、外部 ID プロバイダーと自己発行の多様性を区別するために、外部プロバイダーはマネージド ID プロバイダーと呼ばれることもあります。また、作成する情報カードはマネージド カードと呼ばれます)。図 5 に示す例では、ユーザーには、外部 ID プロバイダーから取得された 3 つのカードと、自己発行の ID プロバイダーから取得された 1 つのカードがあります。

図 5: 自己発行の ID プロバイダーからカードされた情報を持つユーザー

自己発行の ID プロバイダーによって作成された情報カードには、ユーザーの名前、住所、電子メール アドレス、電話番号などの基本情報のみを含めることができます。 ユーザーがこれらのカードの 1 つを証明書利用者に送信することを選択すると、そのユーザーのシステム上の自己発行 ID プロバイダーによって、ユーザーがこのカードに配置した情報を含む SAML トークンが生成されます。 また、自己発行の ID プロバイダーは公開キーと秘密キーのペアを生成し、秘密キーを使用してセキュリティ トークンに署名します。 攻撃者による再利用を防ぐために、このトークンにはタイムスタンプやその他の情報も含まれており、元のユーザーを除くすべてのユーザーにとって役に立ちません。 その後、アプリケーションは、この署名済みトークンを、関連付けられている公開キーと共に証明書利用者に送信します。 証明書利用者は公開キーを使用してセキュリティ トークンのデジタル署名を検証できるため、トークンが正当な所有者によって提示されていることを確認できます。 証明書利用者がそのユーザーの公開キーを比較してユーザーのアクティビティを収集して追跡できないようにするために、自己発行の ID プロバイダーは、このカードでアクセスされるすべての証明書利用者に対して異なるキー ペアを作成します (ただし、この詳細はユーザーには表示されませんが、この ID にカード情報は 1 つだけ表示されます)。

メインの考え方は、CardSpace の自己発行の ID プロバイダーによって作成されたものを含むほとんどの ID プロバイダーによって発行されたセキュリティ トークンは、パスワードを使用せず、Web サイトなどの証明書利用者は、パスワードではなくこれらのトークンを使用してユーザーを認証できるためです。 サイトでパスワードを使用しない場合、フィッシング詐欺師はユーザーをだましてそれらのパスワードを明らかにすることはできません。

フィッシングは深刻な問題です。 Windows CardSpace と ID メタシステムの唯一の利点がこの問題を減らすことであれば、今日のオンライン世界が大幅に改善されます。

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

パスワードベースのログインに対するウェブサイトの依存を減らすことは、フィッシングの痛みを軽減するのに役立ちますが、問題は解消されません。 ユーザーがフィッシング詐欺師のサイトにアクセスするようにだまされた場合、そのサイトは、ユーザーが提供したセキュリティ トークンを受け入れ、自己発行した場合、またはその他の方法で受け入れ、クレジット カード番号などの情報を要求する可能性があります。 フィッシング詐欺は、エミュレートしているサイトのユーザーのパスワードを取得しませんが、他の便利なことを確かに学ぶ可能性があります。

問題の根本は、ユーザーが実際のサイトを、例えば銀行とフィッシング詐欺師が立ち上げた詐欺サイトと区別できないことです。 どちらも同じロゴやその他のグラフィックスを表示できます。 フィッシング詐欺師は他の誰と同じように証明書を取得できるため、どちらも SSL を使用して通信をセキュリティで保護できます。 ユーザーがフィッシング詐欺の電子メール メッセージで提供されているリンクをクリックすると、自分が自分の銀行のサイトと同じように見えるものに接続されている可能性があります。 インターネットエクスプローラーの右下隅に小さなロックが存在する可能性があり、通信が SSL によって保護されていることを示しています。

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

• Web サイトがユーザーにその ID を証明するためのより高い保証方法
• これらのユーザーが、サイトが ID の証明として提供している保証のレベルを学習し、そのサイトを信頼するかどうかについて明示的な決定を行うための一貫した方法です。

Windows CardSpace と ID メタシステムは、これらの両方の問題に対処します。

最初の問題を解決し、Web サイトがユーザーにその ID を証明する方法を改善することは、これを行うために使用される証明書の改善に依存します。 現在、Web サイトは通常、SSL 通信に使用される証明書を使用してその ID を証明しています。 これは何よりも優れていますが、SSL 証明書は実際には、特定のサイトに特定の DNS 名があることを証明するだけです。 この DNS 名がそのサイトに表示される情報に対応するという保証はありません。 フィッシング詐欺は、自分が所有する DNS 名に発行された証明書を使用して、銀行のように慎重に細工されたサイトとの通信をセキュリティで保護する場合があります。 SSL 証明書では、この問題を解決できません。

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

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

図 6: 証明書利用者パートナーが初めてアクセスされるときに表示される画面

この例に示すように、画面には、ID が承認されているorganizationの名前、場所、Web サイトの URL、ロゴ (期限切れのメディアなど) を含めることができます。 また、この情報を検証したorganizationの名前とロゴ (VeriSign など) を含めることもできます。

ユーザーが適切な意思決定を行えるようにするために、画面に表示される内容は、ID プロバイダーまたは証明書利用者によって提供される証明書の種類によって異なります。 前述の高い保証証明書が提供されている場合、図 6 に示すように、画面にorganizationの名前、場所、Web サイトの URL、ロゴが検証されていることを示すことができます。 これは、このorganizationがより信頼に値することをユーザーに示します。 SSL 証明書のみが指定されている場合、画面は低いレベルの信頼が保証されていることを示します。 さらに弱い証明書が提供されている場合、または証明書がまったく提供されていない場合、画面は、このサイトが実際に誰であると主張しているかの証拠がないことを示します。 目標は、ユーザーがデジタル ID を提供する ID プロバイダーと、それらのデジタル ID を受け取ることを許可される証明書利用者に関する情報に基づいた意思決定を行えるようにすることです。

これはすべて深刻な質問を提起します:これは本当に平均的なWindowsユーザーに役立ちますか? 分散セキュリティに関する知識がない人(証明書が何であるか、信頼できる証明機関を知らない人)は、CardSpace を使用して本当により良い意思決定を行うことができますか? 少なくとも、新しいサイトにアクセスするための一貫した予測可能なエクスペリエンスを提供することは役立つはずです。 インターネット エクスプローラーの次のリリースを含め、CardSpace 上に構築されたすべてのアプリケーションでは、CardSpace でアクセスする各 ID プロバイダーと証明書利用者を使用するために、ユーザーの明示的な承認が必要になります。 ユーザーは常にこれに対して同じ画面を表示し、それらの画面は、ユーザーがサイトが誰であるかを保証できる程度の保証に関するガイダンスを提供します。 また、ユーザーは、サイトに初めてアクセスする際に、サイトを信頼することについてのみ決定します。 後でアクセスしても、数か月後でも、図 6 に示すような画面は表示されません。 ユーザーが以前にアクセスしたサイトにアクセスしたときにこの画面が表示される場合は、フィッシング サイトへのアクセスに何らかの方法でだまされたことを強く示しています。

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

CardSpace と ID メタシステムがどのように使用されるかを理解する最も明確な方法は、いくつかの一般的な例を見る方法です。 たとえば、インターネット 書店などのオンライン マーチャントにアクセスするとどうなるかを考えてください。 最も単純なケースでは、デジタル ID は関係しません。誰でも、マーチャントに誰かを伝えることなく、オファーの書籍を閲覧できます。 ただし、注文を行う場合は、ログインする必要があります。これにはデジタル ID を指定する必要があります。 今日は、ユーザー名とパスワードを入力して、自分で選択したユーザー名とパスワードを入力する可能性が高くなります。 このオンラインマーチャントが CardSpace と ID メタシステムもサポートしている場合は、情報カードを使用して自分自身を識別するための別のオプションが提供されます。 これを許可するために、マーチャントはログイン画面に別のボタンを持ち、ユーザー名とパスワードを入力するのではなく、カード情報でログインするためにクリックできます。

このボタンをクリックすると、ブラウザーは CardSpace を使用してこのサイトにログインします。 通常どおり、CardSpace の選択画面が表示され、このマーチャントに自分を識別するためにカードの 1 つを選択します。 この場合に選択カード情報は、自己発行の ID プロバイダー (つまり、自分で作成したもの) によって作成される可能性があります (必須ではありません)。 この時点ですべてのサイトで行う必要があるのが一意の顧客として識別されるため、この単純な形式のデジタル ID で十分です。 購入料金を支払うために、通常どおり、Web フォームにクレジット カード情報と郵送先住所を入力できます。

この単純なシナリオでは、CardSpace はパスワードを使用せずにオンライン マーチャントにログインする方法を提供しました。 これは便利であり、インターネット上のデジタル ID の一歩前進です。 しかし、デジタル ID を使用する方法の始まりにすぎません。 たとえば、この例の支払い手順では、情報カードを使用してクレジット カード情報をサイトに送信できます。 クレジット カードを発行している会社が、物理的なカードに対応する情報カード要求できる ID プロバイダーを提供しているとします。 クレジットカード情報を Web フォームに入力するのではなく、支払い画面にボタンを表示して、カード情報を提供することもできます。 このボタンをクリックすると、システムに CardSpace の選択画面が表示され、このサイトで支払いを受け付けるすべてのカードから選択できるようになります。 カードの 1 つをクリックすると、CardSpace はこのカードの発行者の ID プロバイダーに連絡し、クレジット カード情報を含むセキュリティ トークンを取得し、オンラインマーチャントに提示します。

この例が示すように、デジタル ID は、自分が誰であるかを証明するためのだけではありません。 ウォレット内のさまざまなカードで表される物理的な ID と同様に、デジタル ID を使用して支払いを行ったり、その他の目的で使用したりできます。 たとえば、ローカルでドライバーのライセンスを発行organizationが ID プロバイダーを使用できるようになったとします。 これで、あらゆる証明書利用者に対してさまざまな個人情報を検証できるデジタル ID を取得できるようになりました。 たとえば、米国では、ワインを購入するために、顧客が 21 歳以上であることを証明する必要があります。 オンラインワイン商人は、顧客に運転免許証の CardSpace バージョン (生年月日を含む) の提示を要求する場合があります。これには、ワインの支払いのためにクレジット カードの CardSpace バージョンを受け入れる場合もあります。

この運転免許証 ID プロバイダーは、他の種類の情報カードを提供することもできます。 たとえば、名前やその他の識別情報を明らかにせずに、自分が 21 歳以上であることを証明する方法が必要な場合があります。 運転免許証 ID プロバイダーは、年齢を把握しているため、ライセンス上のすべてを含むカード情報と共に、年齢以上のものを含む単純なカードも提供される場合があります。 資格のあるユーザーの場合、この ID プロバイダーは、自分が 21 歳以上であるという主張のみを含む情報カードを提供する場合もあります。これにより、年齢と同じくらい機密性の高いものが明らかになるのを回避できます。 "デジタル ID" と呼ばれていますが、特定のユーザーを識別するために実際に使用できる情報をまったく含める必要はありません。 多くの用途で必要なのは、信頼された機関によってバックアップされた要求 (21 以前など) をアサートする方法です。

Windows CardSpace と ID メタシステムの使用方法には、さらに多くの例があります。 携帯電話サービスのプロバイダーは、サブスクライバーが電話の請求書にオンライン購入を請求するために使用できるカード情報を提供する場合があります。 雇用主は、会社のネットワークで使用するために、従業員に複数のデジタル ID (それぞれ独自の情報カード) を付与する場合があります。 1 つの ID を通常のアクセスに使用できますが、もう 1 つは、このユーザーが従業員であるという事実以外のすべてを取り除いた場合、会社の管理に匿名の提案を行う目的でのみ存在する可能性があります。 現実世界の ID が異なる情報を持ち、さまざまな目的で使用されるのと同様に、デジタル ID もさまざまな方法で使用できます。 CardSpace と ID メタシステムの目的は、この広範な使用を可能にすることです。

情報カードの調査

ユーザーの観点から見ると、カード情報とは、自分の画面に表示されるデジタル ID を視覚的に表現することです。 ただし、CardSpace では、カード情報は実際にはユーザーの Windows マシンに格納されている XML ドキュメントです。 これを考えると、カードがどのように取得され、何が含まれているかを理解することが重要です。 このセクションでは、これらの問題とその他の問題について説明します。

情報カードの取得方法

カードすべての情報は、一部の ID プロバイダーによって作成されます。 自己発行 ID プロバイダーの CardSpace には、ユーザーがカードを作成できるグラフィカル ツールが用意されています。 通常は他のマシンで実行される他の ID プロバイダーの場合、ユーザーは ID プロバイダーの Web サイトや ID プロバイダーから送信された電子メール メッセージを通じて、何らかの方法で適切なカードを取得する必要があります。 これを行う方法は、各 ID プロバイダーによって定義されます。情報カードを取得する方法は必要ありません。

ただし、各カード (自己署名 ID プロバイダーによって作成されたものも含む) は、それを発行した ID プロバイダーによってデジタル署名され、ID プロバイダーの証明書が付属しています。 この署名は、ID プロバイダー自体の ID を確認するために使用されます。 カードがユーザーのコンピューター上にあると、ダブルクリックすると画面が表示され、ユーザーはこのカードを標準の CardSpace ストアにインストールできます。 これは、前に説明したように、ユーザーがセキュリティ トークンのソースとして ID プロバイダーを承認する必要がある場合でもあります (ただし、この承認は、自己発行の ID プロバイダーによって作成された情報カードには必要ありません)。 ユーザーがこれを行うと、カードを使用してセキュリティ トークンを要求できます。

情報カードに含まれる情報

情報の内容カード、ユーザーがインテリジェントにデジタル ID を選択するのに役立ちます。 また、CardSpace は、証明書利用者の要件にカードを一致させ、このカードを発行した ID プロバイダーから適切なセキュリティ トークンを取得することもできます。 これら 2 つの目標を達成するために、すべての情報カード次のものが含まれます。

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

また、情報カードに含まれていないことに注意することも重要です。この ID に関する機密データです。 たとえば、クレジット カード会社によって作成カード情報には、ユーザーのクレジット カード番号は含まれません。 この種の機密情報は、ID プロバイダーによって作成されたセキュリティ トークンの要求として表示される場合もありますが、ID プロバイダーのシステムには常に格納されます。 セキュリティ トークンで送信された場合、この情報は通常暗号化され、攻撃者と CardSpace の両方にアクセスできなくなります。 重要な点は、機密情報がカード情報に含まれることはなく、ユーザーのコンピューターに保存されることはないことです。 選択した場合、情報の所有者カード CardSpace を使用して、そのカードを使用して作成されたセキュリティ トークンに表示される情報をプレビューできます。 この情報は、ユーザーが表示を要求したときにカードを発行した ID プロバイダーからフェッチされます。 表示されると、ユーザーのシステムから機密情報が削除されます。

情報カードを使用したローミング

People、多くの場合、複数のマシンから同じデジタル ID を提示する必要があります。 私たちの多くは、職場で 1 台のコンピューター、自宅でコンピューター、旅行中に 3 台目のコンピューターを使用しています。 これらの異なるマシン間のローミングを許可するために、CardSpace にはカードエクスポート機能が用意されています。 このオプションを使用すると、USB キーなどの外部ストレージ メディアに情報カードをコピーできます。 その後、カードを他のマシンにインストールし、ホーム コンピューター、オフィス コンピューター、またはホテルの部屋でノート PC を使用している場合でも、ユーザーが同じ方法で ID プロバイダーにセキュリティ トークンを要求できます。 攻撃から保護するために、エクスポートされた情報カードは、ユーザーが選択したパススルーから派生したキーを使用して暗号化されます。 これにより、ストレージ メディアが失われた場合でも、そのパス フレーズを知っているユーザーのみが、そのメディアに含まれるカードを暗号化解除できます。

ただし、このソリューションが適していないシナリオがあります。 たとえば、誰かがインターネット カフェから CardSpace ベースの ID を使用したいとします。 これを行うには、カフェのシステムに情報カードをインストールする必要があります。 セルフマネージド ID プロバイダーを使用して作成された既存の ID を使用するには、それらの ID に関連付けられているキーもインストールする必要があります。 この情報をすべて共有パブリック コンピューターに配置することはお勧めしません。 CardSpace の最初のリリースではこのシナリオには対応していませんが、近い将来、USB ベースのハードウェアに CardSpace ストアと完全な自己発行 ID プロバイダーをインストールする機能が計画されています。 このオプションを使用できるようになると、ユーザーはこのデバイスをコンピューターに接続し、使用しているコンピューターに情報カードやキーをインストールせずに、そのデバイスに直接セキュリティ トークンを要求できるようになります。

情報カードの取り消し

CardSpace で対処する必要があるもう 1 つの問題は、失効です。 ID プロバイダーがユーザーにカード情報を発行したら、そのカードを取り消すにはどうすればよいですか? 最も簡単なケースでは、ID プロバイダー自体は、このカードに基づいてセキュリティ トークンの発行を停止できます。 この ID プロバイダーを使用するには有料サブスクリプションが必要であり、ユーザーが支払いを維持していない可能性があります。 この場合の失効は単純です。ID プロバイダーは、このカードで行われたセキュリティ トークンの要求の受け入を停止するだけです。 すべての要求には一意の CardSpace 参照が含まれているため、ID プロバイダーは失効したカードで行われた要求を簡単に識別できます。

もう少し複雑なケースは、ユーザーがカード情報を取り消したい場合です。 攻撃者が、外部 ID プロバイダーによって発行されたインストール済みの情報カードを含むユーザーのノート PC を盗んだ可能性があります。 前述のように、カード各情報には、カードを使用するたびに入力する必要がある PIN を割り当てることができます。 この操作を行った場合、攻撃者は盗まれたカードを使用できません。ただし、そのカードの PIN も認識している必要があります。 さらに、一部の ID プロバイダーでは、特定の情報をカードして新しいセキュリティ トークンが要求されるたびに、ユーザーがパスワードを入力するか、スマート カードを使用する必要がある場合があります。 これらのいずれの保護も持たないカードの場合、ユーザーはカードが侵害された各 ID プロバイダーに連絡し、カードを受け入れてはならないことを通知する必要があります。 カードの取得と同様に、これを行うための標準的なメカニズムはありません。 各 ID プロバイダーは、ユーザーが未処理の情報カードを取り消し、そのカードで行われた要求の受け入れを停止するための独自の手順を提供する必要があります。

しかし、自己発行の ID プロバイダーによって作成された情報カードはどうでしょうか。 ラップトップが盗まれた場合、これらのカードの ID プロバイダーも盗まれたため、要求の受け入れを停止するように指示する方法はありません。 これは、パスワードを失うこととよく似ています。唯一の解決策は、このパスワードを受け入れる組織にその損失について通知することです。 情報カードを作成した自己発行の ID プロバイダーと共に失われた場合、所有者は、これらの侵害されたカードを使用して作成されたセキュリティ トークンを受け入れる各証明書利用者で自分のアカウントを手動で取り消す必要があります。 CardSpace には、カードが使用されたすべてのサイトを記録するカード履歴機能が用意されているため、この盗難にあったノート PC の所有者は、カードのバックアップ コピーを使用して、どのサイトに接続する必要があるかどうかを判断できます。

Windows CardSpace との相互運用

Windows CardSpace は.NET Framework 3.0 の一部であり、その上に構築されたアプリケーションは必ずしも Windows アプリケーションです。 CardSpace 互換の ID セレクターは他のプラットフォームやデバイスに実装されていますが、ID プロバイダーと証明書利用者は Windows アプリケーションである必要はありません。 このセクションでは、CardSpace を使用する Windows アプリケーションを操作するために、これらの ID プロバイダーと証明書利用者が行う必要がある操作の概要について説明します。

ID プロバイダーの作成

ID プロバイダーは、任意のオペレーティング システム上の任意の開発プラットフォームを使用して構築できます。 ただし、CardSpace を操作するには、すべての ID プロバイダーが次の 4 つのことを行う必要があります。

• Microsoft が定義したカード形式と互換性のある情報カードを作成でき、これらのカードをユーザーに提供する必要があります。
• WS-Trust仕様で定義されているように 、セキュリティ トークン サービス (STS) を実装する必要があります。 SOAP 上に構築されたこの仕様では、STS からの特定の要求を含む特定の種類のセキュリティ トークンを要求する標準的な方法を定義します。 すべての ID プロバイダーは少なくとも 1 つの STS を実装する必要がありますが、その STS は任意の形式でセキュリティ トークンを発行できます。特定のトークンの種類は必須とされません。 必須ではありませんが、ID プロバイダーは、ID メタシステム用に Microsoft によって定義されているWS-Trustに対する特定の拡張機能もサポートすることを強くお勧めします。
• WS-SecurityPolicy を使用してポリシーを定義し、WS-MetadataExchange を使用してこのポリシーにアクセスできるようにする必要があります。 前述のように、カードすべての情報には、ID プロバイダーのポリシーを取得できるエンドポイントが含まれています。 図 2 と図 4 ではこの手順を省略しましたが、クライアント アプリケーションが ID プロバイダーにセキュリティ トークンを要求する前に、CardSpace は最初にプロバイダー独自のポリシーを ID プロバイダーに要求します。
• セキュリティ トークンの要求を認証する方法をポリシーで示す必要があります。 CardSpace の最初のリリースでは、ID プロバイダーに対してユーザーを認証するために、次の 4 つのオプションがサポートされています。

  • ユーザー名/パスワード (カードが使用されるたびに、ユーザーがこの ID プロバイダーのパスワードを入力する必要がある場合があります)

  • Kerberos チケット

  • X.509 v3 証明書 (ソフトウェア ベースまたはスマート カードのいずれか)

  • 自己発行 ID プロバイダーによって作成された SAML セキュリティ トークン。

    ID プロバイダーは、これらのオプションの一部またはすべてをサポートすることを選択できます。

ID プロバイダーは、ポリシーの一部として、ユーザーがその証明書利用者のセキュリティ トークンを要求するときに、証明書利用者の ID を指定する必要があることを示すこともできます。 既定では、証明書利用者の ID は、トークンが要求されたときに CardSpace によって ID プロバイダーに表示されません。 これにより、ユーザーがこのトークンを使用してアクセスするサービスを ID プロバイダーが認識できなくなるため、ユーザーのプライバシーが保護されます。 ただし、一部の ID プロバイダーでは、要求されたトークンを発行する前に、証明書利用者の ID に関する知識が必要になる場合があります。 たとえば、Kerberos サーバーは、そのサービスのチケットを作成するために、クライアントがアクセスするサービスの ID を認識する必要があります。 より一般的には、独自の Web サイトで使用する ID プロバイダーを確立するorganizationでは、その ID プロバイダーのみがそれらのサイトで使用するセキュリティ トークンを発行できる場合があります。フリーローダーは、この ID プロバイダーを独自の目的で使用することはできません。

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

証明書利用者の作成

ID プロバイダーと同様に、証明書利用者は、任意のオペレーティング システム上の任意の開発プラットフォームを使用して構築できます。 また、ID プロバイダーと同様に、証明書利用者は CardSpace を操作するためにいくつかのことを行う必要があります。 証明書利用者の要件は次のとおりです。

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

証明書利用者は、任意の種類のセキュリティ トークンを自由に受け入れます。 必須ではありませんが、多くの証明書利用者は、CardSpace の自己発行 ID プロバイダーによって生成されたセキュリティ トークンを受け入れます。 (Microsoft では、証明書利用者がこれらのトークンのサポートを示すためにポリシーに配置できる特定の値を定義します)。証明書利用者が受け入れるセキュリティ トークンに関係なく、この情報をローカル ID にマップすることは自由です。たとえば、SAML トークンを Windows セキュリティ識別子 (SID) または UNIX ユーザー識別子 (uid) に変換します。

ID プロバイダーと同様に、CardSpace では、証明書利用者との Web サービスの対話中にエラーが発生した場合に送信できるいくつかの SOAP エラーが定義されています。 たとえば、証明書利用者にアクセスすると、セキュリティ トークン内のいずれかの要求が無効であるか、必要な要求が見つからないことを示すエラーが発生する可能性があります。

Windows CardSpace とその他の Microsoft テクノロジ

ほとんどの新しい Microsoft オファリングと同様に、CardSpace は Windows 世界の他の部分にも影響を与えます。 デジタル ID に対するこの新しいアプローチの影響を受ける最も重要なテクノロジは、インターネット エクスプローラー (IE)、Windows Communication Foundation (WCF)、Active Directory、および Windows Live ID です。 このセクションでは、それぞれが CardSpace とどのように関連しているかについて説明します。

Windows CardSpace とインターネット エクスプローラー

Microsoft の Web ブラウザー Internet エクスプローラー 7 の次のリリースでは、ユーザーがデジタル ID に CardSpace を利用できるようになります。 現在、インターネットにアクセスするための最も広く使用されているツールであるため、IE は、この新しい ID テクノロジの重要なアプリケーションです。 最も一般的なケースでは、CardSpace は SOAP ベースのプロトコルを使用して完全に通信します。 ただし、前述のように、Web サイトは HTML と HTTP を使用して IE 7 (および可能性のある他の Web ブラウザー) と対話することもできます。

図 7 は、これを行うための 1 つのアプローチを示しています。

図 7: Windows CardSpace とインターネット エクスプローラー 7

1. このプロセスは、ブラウザー ユーザーが Web サイトの保護されたページ (オンラインマーチャントで製品を購入するページなど) にアクセスしたときに開始されます。 この時点で、Web サイトではユーザーがサイトにログインする必要があるため、サイトはブラウザーをログイン ページにリダイレクトします。

2. このリダイレクトにより、サイトはログイン フォームをブラウザーに送信します。

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

3. ユーザーがこのオプションを選択すると、IE 7 は、ログイン プロセスへの CardSpace の関与を要求する OBJECT タグまたは XHTML 構文によって識別されるコードを実行します。

4. CardSpace 画面が表示され、ユーザーは ID を選択できます。

5. これまで、このサイトとの通信はすべて HTTP を使用しています。 ただし、ユーザーが ID を選択すると、CardSpace は、通常どおり WS-Trust を使用して関連付けられている ID プロバイダーに接続し、セキュリティ トークンを取得します。

6. このトークンは、ログイン プロセスの一環として HTTP POST を使用して Web サイトに送信されます。

   Web アプリケーションは、トークンを使用してユーザーを認証したり、その他の目的で使用したりできます。

このシナリオでは、ID プロバイダーは、ユーザーのシステムでローカルに実行されている自己発行の ID プロバイダーであるか、外部プロバイダーである可能性があります。 Web サイト自体は、このサイトで使用されるカスタム トークンを生成する独自のセキュリティ トークン サービスを提供することもできます。 このオプションは、アプリケーション固有のトークンを提供するサイトやトラフィックの多いサイトに適しています。これは、ほとんどの認証作業を専用サーバーで行うことができるためです。

このプロセスについて行うもう 1 つの重要なポイントは、IE 固有のものがないということです。 任意のオペレーティング システム上の任意のブラウザーでも、同じ方法で ID メタシステムを使用できます。 Windows では、Microsoft の目標は、他のベンダーの Web ブラウザーを含むすべてのアプリケーションが CardSpace でデジタル ID を管理および使用できるようにすることです。

Windows CardSpace と Windows Communication Foundation

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

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

確かに必須ではありませんが、ほとんどのユーザーは、バージョン 3.0 の.NET Frameworkをサポートする Windows システムに ID プロバイダーと証明書利用者を実装し、WCF を使用してビルドする可能性があります。 ID プロバイダーまたは証明書利用者を作成するために必要なのは、前のセクションで示した要件に準拠した WCF サービスを構築することです。 アプリケーションがこれらの要件に準拠し、WsHttpBinding などの適切な WCF バインディングを選択する限り、CardSpace に参加できます。

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

Windows CardSpace と Active Directory

Active Directory は、ID プロバイダーにとって明らかに重要な候補です。 CardSpace は 2007 年初めにリリースされる予定ですが、その後しばらくすると Active Directory の新しいリリースはスケジュールされません。 Microsoft は、Active Directory は最終的に ID プロバイダーの役割を果たすことができると述べていますが、この機能がいつ利用可能になるのかについては発表されていません。

CardSpace と Active Directory フェデレーション サービス (AD FS) (ADFS) の関係について、さらに早急に質問します。 ADFS は現在利用可能であり、最初は CardSpace に似ています。 しかし、実際には、これら 2 つのテクノロジはまったく異なります。 CardSpace には、ID セレクターと自己発行の ID プロバイダーが用意されており、どちらもクライアント コンピューターで実行されます。 ADFS は、Active Directory を使用するorganizationが WS-Federation を使用して他の組織と ID をフェデレーションできるようにするサーバー ベースのソフトウェアです。 もう 1 つの重要な違いは、CardSpace を使用するブラウザーがアクティブな役割を果たしている間、前のセクションで説明したように、ブラウザーは ADFS に気が付かないということです。その役割は完全にパッシブです。 どちらも ID に関係していますが、CardSpace と ADFS は非常に異なる機能を実行します。

Windows CardSpace と Windows Live ID

Microsoft Windows Live ID システム (旧称 Passport) は、もともとインターネット上の任意のサイトで使用できる標準認証システムを提供することを目的としていました。 現在、この初期の取り組みから進化したネットワークは、主に Microsoft 自体が実行するサイトで構成されています。 Windows Live ID が 1 日に 10 億回近くのログインを処理するようになったとしても、レッスンは明確でした。Microsoft ほど大きな 1 つものorganizationは、インターネット上のすべての唯一の ID プロバイダーとして機能することはできません。

CardSpace と ID メタシステムは、ID プロバイダーと ID プロバイダーに関するより一般的なビューを使用して、根本的に異なるアプローチを表します。 Microsoft は、Windows Live ID が ID プロバイダーとして機能するように変更され、ユーザーは CardSpace を使用して Windows Live ID アカウントにサインインできるようになると述べています。 ただし、CardSpace は Windows Live ID に依存しておらず、1 日に Windows Live ID が提供する ID プロバイダーは、ID メタシステムで特別な役割を果たしません。

まとめ

ID メタシステムによって対処される問題は、提供されるソリューションと同様に、間違いなく重要です。 多様なデジタル ID を使用する標準的な方法を提供することで、ネットワーク化された世界を物理的な世界と同じくらい便利で安全にすることができます。 各状況で使用される ID をユーザーが制御できるようにすることで、ユーザーはデジタル ID の使用方法を正面から管理できます。 自己発行 ID を含むデジタル ID を使用すると、パスワードベースの Web ログインの必要性を減らすことができます。また、Web サイトの ID に対するユーザーの信頼度が向上すると共に、多くのユーザーを攻撃するフィッシング攻撃を減らすこともできます。

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

それでも、CardSpace は広く利用できる可能性があります。 CardSpace の基になる ID メタシステムはオープン プロトコルに基づいているため、ID プロバイダー、証明書利用者、およびその他の ID セレクター用の CardSpace 互換ソフトウェアは、任意のプラットフォームまたはデバイス上に構築できます。 CardSpace は単数形の直感的なインターフェイスを公開するため、任意の Windows ソフトウェアで予測可能かつ一貫して使用できます。 これらのすべての現実を考えると、Windows CardSpace は、デジタル ID に関心のあるすべてのユーザーにとって重要であることが保証されます。

関連項目

記事

アイデンティティの法則

Id メタシステムに関する Microsoft のビジョン

サイト

Windows CardSpace デベロッパー センター

ブログ

• キム・キャメロンの ID ウェブログ
• Andy Harjanto の InfoCard Weblog

 

著者について

David Chappell は、カリフォルニア州サンフランシスコの Chappell & Associates のプリンシパルです。 スピーキング、ライティング、コンサルティングを通じて、世界中のテクノロジプロフェッショナルがエンタープライズ ソフトウェアについて理解し、使用し、より良い意思決定を行うのに役立ちます。