要求ベースの ID モデル
要求に対応するアプリケーションを構築する場合、ユーザーはアプリケーションに対して要求のセットとして ID を指定する必要があります。 たとえば、ユーザーの名前や電子メール アドレスなどを個別に要求に指定します。 これは、ユーザーが要求を行うたびにユーザーの識別に必要な情報がアプリケーションにすべて提供されるように外部 ID システムを構築し、同時に、信頼できるソースから提供される ID データを暗号化によって保護するという考え方です。
このモデルの場合、シングル サインオンが非常に簡単に実現でき、アプリケーションで以下の処理を実行する必要がなくなります。
ユーザーを認証する。
ユーザーのアカウントとパスワードを格納する。
エンタープライズ ディレクトリを呼び出して ID の詳細を参照する。
他のプラットフォームまたは企業の ID システムを統合する。
このモデルでは、アプリケーションでユーザーからの要求に基づいて ID 関連の決定を行うことができます。 たとえば、ユーザーの名前を使用したアプリケーションの簡単なカスタマイズから、アプリケーション内の高価値の機能およびリソースへのアクセスにおけるユーザー承認まで、その内容は多岐にわたります。
フェデレーションに限定されない
要求ベースの ID モデルの本来の目的は、組織間のフェデレーションを可能にすることでしたが、現在では要求がフェデレーションだけに関連するものではないことが明らかになってきました。 ただし、これらの用語の一部はそのまま使用されています。 たとえば、WIF を ASP.NET アプリケーションで使用する場合は、要求を処理するために WSFederationAuthenticationModule と呼ばれる WIF コンポーネントを使用する必要があります。 "フェデレーション" という用語で混乱しないように注意してください。 認証と承認を外部システムで行うアプリケーションの構築には、明らかな利点がいくつかあります。 複数の Web アプリケーションまたは Web サービスを現在所有している、または将来的に所有する計画があるすべての企業には、ID 用の要求ベース モデルを導入することで利点がもたらされます。
要求ベースの ID の概要
このセクションでは、この新しい ID のアーキテクチャを理解するために役立つ用語および概念について説明します。
ID
"ID" という語は、定義があいまいになりがちです。 たとえば、このトピックでは認証および承認の説明において "ID" を使用しています。 ただし、WIF のプログラミング モデルにおいては、"ID" という用語を使用して、安全性を確保するシステムのユーザーやその他のエンティティを説明する属性のセットを表します。
要求
要求は、ID 情報の一部と考えることができます。たとえば、"営業" の役割における名前、電子メール アドレス、年齢、メンバーシップなどです。 アプリケーションが受け取る要求が多くなるほど、ユーザーに関して得られる情報が増えます。 エンタープライズ ディレクトリに関して一般的に使用される用語である "属性" を使用せずに、"要求" と呼ばれているのはなぜでしょうか。 その理由は、配信方法に関係があります。 このモデルでは、アプリケーションはユーザー属性をディレクトリで参照しません。 代わりに、アプリケーションに要求を配信して、アプリケーションが要求を調べます。 各要求は発行者により作成され、要求の信頼度は発行者の信頼度に基づきます。 たとえば、他のユーザーが作成した要求よりも、自分の会社のドメイン コントローラーにより作成された要求の方が信頼できます。 WIF は、要求の発行者を見つけるために使用できる Issuer プロパティを含む、 Claim 型により要求を表現します。
セキュリティ トークン
ユーザーが要求を行うと、要求のセットがアプリケーションに配信されます。 Web サービスでは、これらの要求は SOAP エンベロープのセキュリティ ヘッダーで送信されます。 ブラウザーベースの Web アプリケーションでは、要求はユーザーのブラウザーから HTTP POST 経由で受信されます。セッションが必要な場合は、後で Cookie にキャッシュされる場合もあります。 これらの要求がどのように受信されたかにかかわらず、要求はシリアル化される必要があります。ここにセキュリティ トークンが含まれます。セキュリティ トークンは、要求のシリアル化されたセットであり、発行機関によりデジタル署名されています。 署名は重要です。署名により、ユーザーが単に多数の要求を作成して送信しただけではないことが保証されます。 暗号化が必須ではない (要求されない) セキュリティ レベルの低い状況では署名されていないトークンを使用できますが、そのようなシナリオについてはここでは説明しません。
WIF の中核となる機能の 1 つは、セキュリティ トークンを作成および読み取る機能です。WIF および .NET Framework は、すべての暗号化作業を処理し、読み取り可能な要求のセットでアプリケーションを表します。
発行機関
発行機関の種類は、Kerberos チケットを発行するドメイン コントローラーから、X.509 証明書を発行する証明機関まで数多くありますが、ここで説明するのは要求を含むセキュリティ トークンを発行する機関です。 この発行機関は、セキュリティ トークンの発行方法を認識する Web アプリケーションまたは Web サービスです。 発行機関では、適切な要求を発行するために、要求を行う対象証明書利用者およびユーザーに関する十分な情報が必要です。また、ユーザー ストアとやり取りして要求を検索し、ユーザー認証を独自に行うことが必要な場合もあります。
どの発行機関を選択した場合でも、その機関は ID ソリューションの中核としての役割を担います。 要求を信頼してアプリケーションから認証を除外する場合、その機関に認証機能が委任され、その機関でユーザーの認証が行われます。
標準
このような相互運用をすべて実現するために、前のシナリオではいくつかの WS-* 標準が使用されています。 ポリシーは WS-MetadataExchange を使用して取得されますが、そのポリシー自体は WS-Policy 仕様に準拠しています。 STS は、セキュリティ トークンの要求と受信の方法が記述されている WS-Trust 仕様を実装したエンドポイントを公開します。 現在のほとんどの STS は、SAML (Security Assertion Markup Langauge) で書式設定されたトークンを発行します。 SAML は、相互運用可能な方法で要求を表現できる、業界内で認められた XML ボキャブラリです。 つまり、マルチプラットフォームにおいては、まったく異なるプラットフォーム上の STS と通信でき、プラットフォームに関係なくすべてのアプリケーションでシングル サインオンを実現できます。
ブラウザーベースのアプリケーション
要求ベースの ID モデルを使用できるのはスマート クライアントだけではありません。 ブラウザーベースのアプリケーション (パッシブ クライアントとも呼ばれる) でも使用できます。 次のシナリオでは、そのしくみについて説明します。
最初に、ユーザーがブラウザーで要求に対応する Web アプリケーション (証明書利用者アプリケーション) にアクセスします。 Web アプリケーションは、ユーザーを認証するためにブラウザーを STS にリダイレクトします。 STS は単純な Web アプリケーションでホストされています。このアプリケーションで、受信した要求を読み取り、標準的な HTTP メカニズムを使用してユーザーを認証してから、SAML トークンを作成し、JavaScript コードを使用して応答します。このコードによって、ブラウザーで SAML トークンを RP に送り返す HTTP POST が開始されます。 この POST の本文に、RP からの要求が含まれています。 ここでは、一般的に RP では要求を Cookie にパッケージ化して、要求が行われるたびにユーザーをリダイレクトする必要がないようにします。
情報カードと ID セレクター
WIF では、情報カードのシリアル化用の API が用意されています。この API を使用して、マネージ カードの発行機能を作成し、情報カードによるアプリケーションのサインインを可能にします。 の詳細については 、「Windows Communication Foundation での CardSpace の使用」を参照してください。
ID セレクターには次の機能があります。
Web 用の複数の ID を管理する。
指定された証明書利用者の適切な ID を選択する。
ユーザーのプライバシーを保護する。