次の方法で共有

クレームベース ID の概要と概念

  • [アーティクル]

最終更新日: 2010年3月18日

適用対象: SharePoint Foundation 2010

クレームベース ID モデル

クレームを処理できるアプリケーションを構築する場合、ユーザーはアプリケーションに ID を一連のクレームとして提示します。あるクレームはユーザー名、あるいは別のクレームはメールアドレスであることがあります。このしくみの基本にあるのは、何らかの外部 ID システムが構成され、そこからアプリケーションに対して、ユーザーに関するすべての必要な情報 (および、受け取った ID データが信頼できる提供元から得られたものであることを示す暗号化済みの証拠) が個々の要求と共に提供されるという考え方です。

このモデルでは、シングル サインオンの実現が非常に容易になり、ユーザーのアプリケーションは以下の点を考慮する必要がなくなります。

  • ユーザーの認証

  • ユーザー アカウントおよびパスワードの保存

  • ユーザー ID の詳細を検索するために企業のディレクトリを呼び出す

  • その他のプラットフォームあるいは企業の ID システムとの統合

このモデルでは、アプリケーションはユーザーによって提供されたクレームに対して、ID に関連する判断をします。これには、ユーザーのファースト ネームによる簡単なアプリケーションの個人用設定から、アプリケーションのより高度な機能およびリソースにアクセスするためのユーザー認証に至るまで、幅広い用途が含まれます。

次のセクションおよびトピックでは、クレーム ベース ID のアーキテクチャについて理解するうえで役に立つ用語および概念について紹介します。

ID

セキュリティで保護するシステム内のユーザーまたはその他のエンティティについて記述する一連の属性です。

クレーム

ID (名前、電子メール アドレス、年齢、販売ロールのメンバーシップなど) の一部として見なします。アプリケーションが受け取るクレームが多いほど、ユーザーについてより多くの情報を得ることができます。エンタープライズ ディレクトリを記述する際によく使用されるように、"クレーム" という言葉はその配信方法により "属性" という言葉の代わりに使用されます。このモデルでは、アプリケーションではディレクトリ内のユーザー属性は検索されません。代わりに、ユーザーはクレームをアプリケーションに配信します。そして、そのクレームがアプリケーションによって検証されます。各クレームは発行者によって作成され、クレームの発行者を信頼できる場合のにみ、そのクレームを信頼します。たとえば、ユーザーが作成したクレームよりも、会社のドメイン コントローラーが作成したクレームを信頼します。

セキュリティ トークン

ユーザーは、一連のクレームを要求と共にアプリケーションに提供します。これらのクレームは、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 仕様を実装するエンドポイントが公開されます。現在の STS のほとんどが、SAML (Security Assertion Markup Language) で書式設定されたトークンを発行します。SAML は業界で認知されている XML ボキャブラリで、これを使用すると、相互運用可能な方法でクレームを表すことができます。あるいは、マルチプラットフォーム環境で、まったく異なるプラットフォーム上にある STS と通信し、プラットフォームに関係なくすべてのアプリケーションにわたってシングル サインオンを実現できます。

ブラウザー ベースのアプリケーション

クレーム ベース ID モデルを使用できるのはスマート クライアントだけではありません。ブラウザー ベースのアプリケーション (パッシブ クライアントとも呼ばれます) がこのクレーム ベース ID モデルを使用することもできます。次のシナリオはこのしくみを示しています。

まず、ユーザーがクレーム対応 Web アプリケーション (証明書利用アプリケーション) を指定します。Web アプリケーションは、ユーザーを認証できるようにブラウザーを STS にリダイレクトします。STS はシンプルな Web アプリケーションでホストされており、これは受信要求を読み取り、標準の HTTP メカニズムを使用してユーザーを認証します。そして、SAML トークンを作成し、ECMAScript (JavaScript、JScript) コードの一部で応答します。このコードにより、SAML トークンを証明書利用者に送り返す HTTP POST がブラウザーで開始されるようになります。この POST の本文には、証明書利用者によって要求されたクレームが含まれます。この時点で、通常、証明書利用者は、ユーザーが要求ごとにリダイレクトされなくてもすむようにクレームを Cookie にパッケージ化します。