序文

[アーティクル]
12/28/2010

アプリケーションの設計者や開発者が認証について考慮する必要がない世界を想像してみてください。アプリケーションへのすべての要求の中に、アクセスコントロールを決定したり、ユーザーに合わせてアプリケーションをパーソナライズするために必要な情報が含まれている世界を。

このような世界のアプリケーションは、ユーザー名、電子メールアドレス、管理者の電子メールアドレス、さらにはクレジット限度額まで、ユーザーの情報が他のシステムコンポーネントから安全に提供されると信頼することができます。ユーザーの情報は、認証メカニズム (Microsoft® Windows® 統合認証、Web ブラウザーのフォームベースの認証、X.509 クライアント証明書、または非標準の認証であるか) に関係なく、常に同じ単純なフォーマットで到着します。企業のセキュリティポリシーの担当者がユーザーの認証方法を変更しても、常に同じフォーマットでその情報を取得できます。

これは、「クレームベース ID およびアクセスコントロールのガイド」で説明されているクレームベース ID による理想的な世界です。クレームは、ユーザーを認証および承認するアプリケーションを構築してくれる革新的な方法です。

このガイドの対象読者

このガイドでは、新しいアプリケーションを計画したり既存のアプリケーションに変更を加える際に使用できるオプションとして、クレームベース ID を評価するための十分な情報を提供します。このガイドは、ユーザーの ID 情報を要求する Web アプリケーションやサービスを設計、構築、または運用するアーキテクト、開発者、IT プロフェッショナルを対象としています。クレームベース ID を使用するアプリケーションは多くのプラットフォーム上に存在しますが、このガイドは、Windows ベースのシステムを扱うユーザー向けに記述されています。読者は、Microsoft .NET Framework、ASP.NET、Windows Communication Foundation (WCF)、および Microsoft Visual C#® について理解している必要があります。

このガイドの意図

クレームベース ID は以前から実現可能でしたが、最近、Windows ベースのアプリケーションの開発者がクレームベース ID を簡単に実装できるツールが入手可能になりました。これらのツールには、Windows Identity Foundation (WIF) や Microsoft Active Directory® Federation Services (ADFS) v2 があります。このガイドでは、一般的なシナリオに基づいて、これらのツールをどのような状況で、どのように使用するかについて説明します。

用語に関する注記

このガイドでは、クレームベース ID について、新しい用語を多用せずに説明します。ただし、各種の規格や既存の資料では、"証明書利用者"、"STS"、"サブジェクト"、"ID プロバイダー" といった用語が使用されています。ここでは、資料等で使用されている最も一般的な表現と、このガイドで使用する汎用的な用語を対比して、一部の用語について説明します。その他の用語については、このガイドの最後にある「用語集」を参照してください。

証明書利用者 (RP) = アプリケーション

サービスプロバイダー (SP) = アプリケーション

証明書利用者またはサービスプロバイダーとは、クレームを使用するアプリケーションです。"証明書利用者 (relying party)" という用語は、ID に関する情報の提供に関して、アプリケーションが発行者に依存することに由来しています。"サービスプロバイダー" という用語は、SAML (Security Assertion Markup Language) でよく使用されます。このガイドは、アプリケーションを設計して構築するユーザーを対象としているため、"証明書利用者"、"RP"、"サービスプロバイダー"、"SP" の代わりに、"アプリケーション"、"クレーム対応のアプリケーション" という用語を使用します。

サブジェクト = ユーザー

プリンシパル = ユーザー

サブジェクトまたはプリンシパルとは、ユーザーのことです。"サブジェクト" という用語は、長年に渡ってセキュリティ関連の資料に登場しています。ユーザーがアクセスコントロール、パーソナライズなどの対象 (サブジェクト) であるということがわかれば、意味は理解できます。サブジェクトがプリンターや他のデバイスなど、人間以外のエンティティである場合も考えられますが、そのようなシナリオについては、このガイドでは説明しません。また、.NET Framework では、"サブジェクト" ではなく、"プリンシパル" という用語が使用されます。このガイドでは、"サブジェクト" または "プリンシパル" の代わりに、"ユーザー" という用語を使用して説明します。

セキュリティトークンサービス (STS) = 発行者

技術的には、セキュリティトークンサービスとは、要求を受け入れ、クレームを含むセキュリティトークンを発行する発行者内のインターフェイスです。

ID プロバイダー (IdP) = 発行者

ID プロバイダーとは、発行者 (トークン発行者) のことです。ID プロバイダーは、ユーザー名、パスワード、証明書などのさまざまなユーザー資格情報を検証し、トークンを発行します。このガイドでは、わかりやすいように、"発行者" という用語を使用します。

リソースセキュリティトークンサービス (R-STS) = 発行者

リソースセキュリティトークンサービスは、1 つのトークンを受け入れて、別のトークンを発行します。このサービスは、ID に関する情報ではなく、リソースに関する情報を保持します。たとえば、R-STS は、ID プロバイダーが発行したトークンをアプリケーション固有のクレームに変換できます。

このガイドでは、ID プロバイダー、セキュリティトークンサービス、およびリソースセキュリティトークンサービスの機能を区別することには意味がありません。実際に、これらの機能は既存の資料でも混同されていることが多く、混乱に拍車をかけています。このガイドでは、これらすべての概念をまとめて "発行者" という実用的な用語を使用します。

アクティブクライアント = スマート/リッチクライアント

パッシブクライアント = ブラウザー

多くの資料では、"アクティブ" クライアントと "パッシブ" クライアントという用語が使用されています。アクティブクライアントは、Windows Communication Foundation (WCF) などの高機能ライブラリを使用することにより、セキュリティトークンを要求し受け渡すプロトコルを実装することができます (WS-Trust は、アクティブシナリオで使用されるプロトコルです)。さまざまなブラウザーをサポートするために、パッシブなシナリオでは、これよりもはるかに単純なプロトコルを使用して、HTTP GET (リダイレクト時) や POST などの単純な HTTP プリミティブに依存するトークンを要求し、受け渡します。(この単純なプロトコルは、WS-Federation 仕様のセクション 13 で定義されています。)

このガイドでは、アクティブクライアントは、リッチクライアントまたはスマートクライアントと表現します。パッシブクライアントは、Web ブラウザーと表現します。

このガイドの構成

このガイドの構成は、主要駅と路線が示された地下鉄のマップにたとえることができます。序文の後に、一般的な情報を記した 2 つの章があります。その後に、これらの知識をより高度な要件に合わせて応用するためのシナリオが用意されています。

このガイドのマップは次のようになります。

図 1

このガイドのマップ

「クレームについて」では、クレームについて概説し、最適なクレームを作成するための一般ルールと、クレームをアプリケーションに組み込む方法について説明します。シナリオに進む前に、この章を読むことをお勧めします。

「クレームベースのアーキテクチャ」では、ブラウザーベースのアプリケーションとスマートクライアントベースのアプリケーションで、クレームを使用する方法について説明します。この章では、ユーザーがイントラネットとエクストラネットのどちらにアクセスしているかに関係なく、シングルサインオンをユーザーに実装する方法を中心に説明します。この章は省略可能です。この章を飛ばして直接シナリオに進むこともできます。

「Web 用のクレームベースのシングルサインオン」では、企業イントラネット内でシングルサインオンを実装する方法について説明します。これは、Windows 統合認証を使用して実装することもできますが、さらに複雑なシナリオを実装するための最初の足がかりとなります。この章には、クレームベースのアプリケーションをクラウドに移行する方法を示す Windows Azure" のセクションが含まれます。

「Web アプリケーション用のフェデレーション ID」では、自社とビジネスパートナーそれぞれの企業ディレクトリの一貫性を維持したままビジネスパートナーにアプリケーションへのアクセスを提供する方法について説明します。つまり、パートナーの従業員は、パートナー企業の資格情報を使用してアプリケーションにアクセスできます。

「Web サービス用のフェデレーション ID」では、Web サービスでクレームベースの手法を使用する方法について説明します。この手法では、パートナーは、ブラウザーではなくスマートクライアントを使用します。

「複数のパートナーとのフェデレーション ID」は、前のシナリオのバリエーションです。独自の発行者を持っているパートナーだけでなく、持っていないパートナーとフェデレートする方法についても説明します。ASP.NET MVC フレームワークを使用して、クレーム対応のアプリケーションを作成する方法について説明します。

コードを使用するための要件

これらのシナリオは、各自のシステムで実行することも、現実に即したラボ環境を作成して実行することもできます。各自のシステムでシナリオを実行することはとても簡単で、要件も多くはありません。シナリオを各自のシステムで実行するためのシステム要件は次のとおりです。

Microsoft Windows Vista SP1、Windows 7、または Microsoft Windows Server 2008 (32 ビットまたは 64 ビット)
Microsoft Internet Information Services (IIS) 7.0
Microsoft .NET Framework 3.5 SP1
Microsoft Visual Studio® 2008 SP1
Windows Azure Tools for Microsoft Visual Studio
Windows Identity Foundation

Active Directory Federation Services (ADFS) および Active Directory のインスタンスを使用する、現実に即したラボ環境でシナリオを実行する場合は、アプリケーションサーバー、ADFS、Active Directory、およびクライアントシステムが必要です。この場合のシステム要件は次のとおりです。

アプリケーションサーバー

アプリケーションサーバーには、以下が必要です。

Windows Server 2008
Microsoft IIS 7.0
Microsoft Visual Studio 2008 SP1
.NET Framework 3.5 SP1
Windows Identity Foundation

ADFS

ADFS サーバーには、以下が必要です。

Windows Server 2008
Internet Information Services (IIS) 7.0
.NET Framework 3.5 SP1
SQL Server® 2005/2008 Express Edition

Active Directory

Active Directory システムでは、Active Directory がインストールされた Windows Server 2008 が必要です。

クライアントコンピューター

クライアントコンピューターでは、アクティブシナリオ用に Windows Vista または Windows 7 が必要です。パッシブなシナリオでは、リダイレクトをサポートするクライアントとして、任意の Web ブラウザーを使用できます。

専門家パネル

既に説明したように、このガイドでは、いくつかの企業アプリケーションの発展を追う一連のシナリオを使用します。専門家パネルは、これらの開発努力についてコメントします。このパネルには、セキュリティ専門家、ソフトウェアアーキテクト、ソフトウェア開発者、および IT プロフェッショナルが含まれます。それぞれの専門家の視点から、シナリオに検討が加えられます。以下の専門家がいます。

	Bharath はセキュリティ専門家です。企業のデータが認証および承認のソリューションによって確実に保護されるかどうかをチェックします。良い意味で慎重な人物です。 "1 つのアプリケーションに認証を提供することは簡単ですが、組織全体におけるすべてのアプリケーションを保護するとなると、事情は異なります。"
	Jana はソフトウェアアーキテクトです。アプリケーションの全体構造を計画します。彼女の見解は実用的かつ戦略的です。今日必要とされる技術的なアプローチだけでなく、企業が検討すべき将来的な方向性についても検討します。 "ユーザー、IT 組織、開発者、技術プラットフォームのニーズを調整するのは骨が折れます。"
	Markus は上級ソフトウェア開発者です。分析能力に優れ、細部に気を配る几帳面な性格です。主に、クレームベースの優れたアプリケーションを構築する作業に取り組んでいます。自分が最終的なコードの責任者であることを理解しています。 "お客様が認証に使用される認証がどのようなものであっても、私が動かしてみせます。"
	Poe は企業データセンターでの展開および実行を専門とする IT プロフェッショナルです。Active Directory の第一人者でもあります。実用的なソリューションに意欲的に取り組んでいます。問題が発生すると、午前 3 時であっても呼び出される人物です。 "認証の処理方法はアプリケーションごとに異なります。少しは整合性があるとよいのですが。"