SharePoint のクレーム プロバイダー
クレーム プロバイダー
SharePoint Server のクレーム プロバイダーは、要求を発行し、要求をセキュリティ トークン (つまり、ユーザーのトークンにパッケージ化) します。 ユーザーが SharePoint Server にサインインするときに、ユーザーのトークンが検証され、ユーザーはそのトークンを使用して SharePoint にサインインします。
SharePoint のクレーム プロバイダーには、拡張と選択の 2 つのロールがあります。
注:
要求プロバイダーを作成する方法については、「 方法: SharePoint で要求プロバイダーを作成する」を参照してください。
クレーム拡張
拡張ロールでは、サインイン中に、クレーム プロバイダーがクレームによってユーザー トークンを拡張します。 クレーム拡張により、アプリケーションが追加のクレームをユーザーのトークンに拡張できます。 たとえば、Windows ベースのログインでは、Active Directory ディレクトリ サービスがすべてのユーザーのセキュリティ グループをユーザーの Windows トークンに拡張できます。 クレーム ベースのログインでは、カスタマー リレーションシップ マネジメント (CRM) アプリケーションが CRM データベースからロールを拡張できます。 これらのクレームをユーザーのトークンに含めることで、そのクレームに対してリソースを承認できます。 つまり、これらのクレームを使用して、特定のユーザーが特定のリソースにアクセスできるかどうかを決定できます。
クレーム選択
選択ロールでは、クレーム プロバイダーにより、クレームのリスト、解決、検索、表示名の機能がユーザー選択ウィンドウに提供されます。 クレーム選択を使用すると、たとえば、SharePoint サイトまたは SharePoint サービスのセキュリティを構成しているときに、アプリケーションのユーザー選択ウィンドウにクレームを表示できます。
クレーム プロバイダー使用のシナリオ
クレーム プロバイダーは、さまざまなシナリオの解決に使用されます。 次に、クレーム プロバイダーを使用して解決できるシナリオの例をいくつか示します。
リスト、解決、および検索
SharePoint Serverには、組み込みの認証プロバイダーのリスト、解決、および検索を有効にする組み込みのクレーム プロバイダーがあります。 組み込みの認証プロバイダーの例としては、Windows Active Directory、フォーム ベース認証、および信頼された SAML (Security Assertion Markup Language) トークン発行者、つまり セキュリティ トークン サービス (STS) があります。
信頼された SAML トークン発行者の場合、SharePoint Server は、リストや検索を提供しません。 ユーザーが値を入力すると、SharePoint Server はその値を常に解決します。 つまり、 と入力 adam@contoso.comすると、ユーザー 選択ウィンドウで値が受け入れられます。 これは、STS での解決方法、検索の実装方法、またはクレーム値のリスト方法を指定する業界標準が村債しないためです。
ユーザーは組み込みのクレーム プロバイダーをオーバーライドして、カスタム検索、名前の解決、およびリスト機能を実装できます。 これは、たとえば信頼された SAML トークン発行者を使用するシナリオでは特に便利です。
認証済みユーザーまたはすべてのユーザーのクレーム
SharePoint Server には、認証済みユーザーなどの概念の実装サポートを有効にする、特定の組み込みクレーム プロバイダーがいくつか存在します。 これは、すべてのユーザーのクレームとも呼ばれます。 このシナリオにより、指定された認証プロバイダーからすべてのユーザーに対して権限を付与できます。
注:
認証プロバイダーには、Windows Active Directory、フォーム ベース認証、または信頼された SAML トークン発行者 (つまり STS) があります。
SharePoint Serverには、分類サービスによって使用される内部クレームを追加するシステム クレーム プロバイダーもあります。 たとえば、このクレーム プロバイダーは、ファーム ID およびアプリケーション プール アカウントを追加します。
クレームを元のトークンに追加する
組み込みの要求プロバイダーの一部は、元の "トークン" からの要求を追加するためにも使用されます。 "token" という単語は引用符で囲まれています。一部の認証プロバイダー (たとえば、フォーム ベースの認証 (メンバーシップとロール プロバイダー ASP.NET) では実際のトークンが提供されないためです。 この場合は、概念的な観点からこのトークンを考えてみましょう。
追加のクレームをユーザーの元のクレーム トークンに追加しなければならないことがあります。 このシナリオでは、クレーム プロバイダーが必要になる可能性があります。 たとえば、SAP ロールをユーザーの元のクレームに追加するときに、クレーム プロバイダーを必要とする場合があります。
元のトークンからのものではない ID
ユーザーのピッキングとトークンの要求に関する特定の要件がシステムにあるシナリオを想定します。 このシナリオでは、Microsoft .NET Passport Unique ID (PUID) と元のユーザーに基づいてユーザーの ID を把握しています。 ただし、ユーザーに関する情報は元のユーザー トークンから取得されません。カスタム Active Directory から取得されます。 また、元のユーザー トークン (Windows Live ID によって発行) に含まれていない、ユーザーが属している可能性のある追加の Active Directory グループもあります。 このシナリオでは、システム固有のニーズを満たす要求プロバイダーを構築できます。