SharePoint のクレームベース ID と概念
クレームベース ID モデル
クレームを処理できるアプリケーションを構築する場合、ユーザーはアプリケーションに ID を一連のクレームとして提示します。 あるクレームはユーザー名、あるいは別のクレームはメールアドレスであることがあります。 このしくみの基本にあるのは、何らかの外部 ID システムが構成され、そこからアプリケーションに対して、ユーザーに関するすべての必要な情報 (および、受け取った ID データが信頼できる提供元から得られたものであることを示す暗号化済みの証拠) が個々の要求と共に提供されるという考え方です。
このモデルでは、シングル サインオンの実現が非常に容易になり、アプリケーションが以下のことを考慮しなくても済むようになります。
ユーザーの認証
ユーザー アカウントおよびパスワードの保存
ユーザー ID の詳細を検索するために企業のディレクトリを呼び出す
その他のプラットフォームあるいは企業の ID システムとの統合
このモデルでは、アプリケーションはユーザーによって提供されたクレームに対して、ID に関連する判定を行います。 この判定には、ユーザーのファースト ネームによる簡単なアプリケーションの個人用設定から、アプリケーションのより高度な機能およびリソースにアクセスするためのユーザー認証に至るまで、幅広い用途を含みます。
ここでは、クレームベースの ID アーキテクチャを理解するための用語と概念について説明します。
ID: エンティティについて記述する属性のセット
ID は、セキュリティで保護するシステム内のユーザーまたはその他のエンティティを示す一連の属性です。
クレーム: ID 情報
要求は、ID 情報の一部 (名前、メール アドレス、年齢、Sales ロールのメンバーシップなど) と考えてください。 アプリケーションが受け取る要求が多いほど、ユーザーについて知る必要があります。 これらは"属性" ではなく "要求" と呼ばれます。これは、配信方法のため、エンタープライズ ディレクトリの記述で一般的に使用されます。 このモデルでは、アプリケーションではディレクトリ内のユーザー属性が検索されません。 代わりに、ユーザーがアプリケーションに要求を配信し、アプリケーションが要求を調べます。 各クレームが発行者によって作成され、クレームの発行者を信頼できる場合は、そのクレームを信頼します。 たとえば、ユーザーが行った要求を信頼するよりも、会社のドメイン コントローラーによって行われた要求を信頼します。
セキュリティ トークン: シリアル化されたクレームのセット
ユーザーは、要求を含む一連の要求をアプリケーションに配信します。 Web サービスでは、これらの要求は SOAP エンベロープのセキュリティ ヘッダーに含まれます。 ブラウザー ベースの Web アプリケーションでは、要求はユーザーのブラウザーから HTTP POST を介して到着し、セッションが必要な場合は後で Cookie にキャッシュされる可能性があります。 これらの要求の到着方法に関係なく、シリアル化する必要があります。 セキュリティ トークンは、発行元によってデジタル署名されたクレームのシリアル化されたセットです。 署名は重要です。ユーザーがクレームを作成して送信しただけではないことを保証できます。 暗号化が不要または望ましくないセキュリティの低い状況では、署名されていないトークンを使用できますが、そのシナリオについてはこの記事では説明しません。
セキュリティ トークンの作成および読み取り機能は、Windows Identity Foundation (WIF) の主要機能の 1 つです。 WIF および Microsoft .NET Framework では、すべての暗号化作業を処理して、アプリケーションが読み取ることができる一連のクレームをそのアプリケーションに対して提供します。
セキュリティ トークン サービス (STS)
セキュリティ トークン サービス (STS) では、このトピックの「標準」セクションで説明する相互運用プロトコルに従って、セキュリティ トークンを作成、署名、および発行します。 これらのプロトコルの実装には多くの作業が伴いますが、こうした作業はすべて、WIF によって行われるので、STS は、プロトコルのエキスパートでなくても非常に簡単に実行できます。
WIF を使用すると、独自の STS を容易に作成できます。 この STS を実施するロジック、つまりルール (セキュリティ ポリシーとよく呼ばれます) を実装する方法を指定するかどうかは作成者次第です。
発行機関
発行機関には、Kerberos チケットを発行するドメイン コントローラーから X.509 証明書を発行する証明機関まで、さまざまな種類の機関があります。 このトピックでは、クレームが含まれるセキュリティ トークンを発行する特定の発行機関 (セキュリティ トークンを発行する Web アプリケーションまたは Web サービス) について説明します。 この機関は、要求を行うターゲットの証明書利用者およびユーザーに提供する適切なクレームを発行できなければなりません。 また、ユーザー ストアとのやり取りにより、クレームを参照してユーザーを認証しなければならない可能性もあります。
どの発行機関を選択しても、発行機関は ID ソリューションにおける中心的な役割を果たします。 クレームを使用することで、アプリケーションから認証処理を除外する場合は、認証の処理を発行機関に移行して、その機関に対して自分の代わりにユーザー認証を行うように依頼します。
証明書利用者
クレームに依存するアプリケーションを作成する場合は、証明書利用アプリケーションを作成します。 証明書利用者の類義語には "クレーム対応アプリケーション" および "クレーム ベースのアプリケーション" があります。 Web アプリケーションと Web サービスは両方とも証明書利用者にできます。
証明書利用者アプリケーションは、STS によって発行されたトークンを使用し、トークンから要求を抽出して、ID 関連のタスクに使用します。 STS では、ASP.NET Web アプリケーションと Windows Communication Foundation (WCF) Web サービスの 2 種類の証明書利用者アプリケーションがサポートされています。
標準
このすべてを相互運用できるように、前のシナリオでは複数の WS-* 標準が使用されています。 WS-MetadataExchange を使用することでポリシーが抽出され、ポリシー自体は WS-Policy 仕様に従って構成されます。 また、STS では、セキュリティ トークンを要求する方法および受け取る方法が記述された WS-Trust 仕様を実装するエンドポイントが公開されます。 現在のセキュリティ トークン サービスのほとんどが、SAML (Security Assertion Markup Language) で書式設定されたトークンを発行します。 SAML は業界で認知されている XML ボキャブラリで、これを使用すると、相互運用可能な方法でクレームを表すことができます。 あるいは、マルチプラットフォーム環境で、まったく異なるプラットフォーム上にある STS と通信し、プラットフォームに関係なくすべてのアプリケーションにわたってシングル サインオンを実現できます。
ブラウザー ベースのアプリケーション
クレーム ベース ID モデルを使用できるのはスマート クライアントだけではありません。 ブラウザー ベースのアプリケーション (パッシブ クライアントとも呼ばれます) がこのクレーム ベース ID モデルを使用することもできます。 次のシナリオはこのしくみを示しています。
まず、ユーザーは要求対応 Web アプリケーション (証明書利用者アプリケーション) でブラウザーを指します。 Web アプリケーションは、ユーザーを認証できるようにブラウザーを STS にリダイレクトします。 STS は、受信要求を読み取り、標準の HTTP メカニズムを使用してユーザーを認証し、ブラウザーが SAML トークンを証明書利用者に送信する HTTP POST を開始する ECMAScript (JavaScript、JScript) コードで SAML トークンと応答を作成する単純な Web アプリケーションでホストされます。 この POST の本文には、証明書利用者が要求した要求が含まれています。 この時点では、証明書利用者が要求ごとにユーザーをリダイレクトする必要がないように、要求を Cookie にパッケージ化するのが一般的です。
Claims to Windows Token Service (c2WTS)
Claims to Windows Token Service (c2WTS) は Windows Identity Foundation (WIF) の機能です。 c2WTS によって、SAML や X.509 の Windows 以外のセキュリティ トークンからユーザー プリンシパル名 (UPN) クレームが抽出され、偽装レベルの Windows セキュリティ トークンが生成されます。 これにより、証明書利用アプリケーションがユーザーを偽装できます。 これは、証明書利用アプリケーションを実行しているコンピューターの外部にある Microsoft SQL Server などのバックエンド リソースにアクセスするときに必要な場合があります。
c2WTS は、WIF の一部としてインストールされる Windows サービスです。 セキュリティ上の理由から、c2WTS は、オプトイン ベースでのみ動作します。 これは手動で開始する必要があり、ローカル システム アカウントとして実行されます。 また、許可された呼び出し元のリストを使用して管理者が手動で c2WTS を構成する必要もあります。 既定では、このリストは空です。
証明書利用者アプリケーションがローカル システム アカウントとして実行されている場合は、c2WTS を使用する必要はありません。 ただし、証明書利用者アプリケーションがネットワーク サービス アカウントとして実行されている場合や、ASP.NET アプリケーションである場合は、たとえば、c2WTS を使用して別のコンピューター上のリソースにアクセスする必要がある場合があります。
バックエンド サーバー上の SQL データベースにアクセスする ASP.NET アプリケーションを実行するサーバーで構成されている Web ファームがあるとします。 このアプリケーションは、クレーム対応にする必要があります。 ただし、アプリケーションは、STS から受け取るクレームを使用して SQL データベースにアクセスすることはできません。 代わりに、c2WTS を使用して、UPN クレームを Windows セキュリティ トークンに変換します。 これにより、そのアプリケーションが SQL データベースにアクセスできるようになります。
注:
アプリケーションが別のサーバーのリソースにアクセスできるようにするには、ドメイン管理者が、制約付き委任を有効にするように Microsoft Active Directory ディレクトリ サービスを構成する必要があります。 制約付き委任を有効にする方法については、「 方法: ASP.NET 2.0 でプロトコルの移行と制約付き eelegation を使用する」を参照してください。