クレームに関するヒント 2 : SharePoint 2010 のクレームベース認証についての説明
概要: SharePoint 2010 のクレームベース認証に関連する 5 つのヒントについて学習します。ここで紹介するヒントとして、クレーム名、ゾーン選択の構成、既定のソリューション展開、エラー メッセージの解決などがあります。
最終更新日: 2011年3月14日
適用対象: Business Connectivity Services | Open XML | SharePoint Designer 2010 | SharePoint Foundation 2010 | SharePoint Online | SharePoint Server 2010 | Visual Studio
この記事の内容
この記事の対象範囲の概要
ヒント 1: SharePoint 2010 で選択ゾーンにのみカスタム クレーム プロバイダーが使用されるように構成する
ヒント 2: クレーム名を解決する
ヒント 3: サインインと認証時の忌まわしい 3 回のログオン プロンプト
ヒント 4: カスタム クレーム プロバイダーの既定のソリューション展開を認識する
ヒント 5: クレームベース認証で発生する TrustedMissingIdentityClaimSource エラーを解決する
まとめ
参考資料
提供元: Steve Peschka、Microsoft Corporation
目次
この記事の対象範囲の概要
ヒント 1: SharePoint 2010 で選択ゾーンにのみカスタム クレーム プロバイダーが使用されるように構成する
ヒント 2: クレーム名を解決する
ヒント 3: サインインと認証時の忌まわしい 3 回のログオン プロンプト
ヒント 4: カスタム クレーム プロバイダーの既定のソリューション展開を認識する
ヒント 5: クレームベース認証で発生する TrustedMissingIdentityClaimSource エラーを解決する
まとめ
参考資料
この記事の対象範囲の概要
この記事では、Microsoft SharePoint 2010 のクレームベース認証に関するヒントやよくある質問の回答を提供します。クレームの使用および構成に関連する問題を解決するのに役立つヒントおよびガイダンスも提供します。また、詳細な情報を確認できるその他の資料も紹介します。
ヒント 1: SharePoint 2010 で選択ゾーンにのみカスタム クレーム プロバイダーが使用されるように構成する
クレーム プロバイダーを使用するシナリオに関して、カスタム クレーム プロバイダーをすべてのアプリケーションではなく特定の 1 つか少数の Web アプリケーションにのみ使用するように構成する方法はないかと尋ねられたことが数回あります。最初はこのシナリオを簡単に解決できると考えて、クレーム プロバイダーの機能の範囲をファームではなく Web アプリケーションに設定してみました。しかし、この方法では期待どおりの結果が得られませんでした。
カスタム クレーム プロバイダーの機能は、常にファーム レベルを範囲として構成する必要があります。機能の範囲をこれと異なる構成にすると、"メソッドまたは操作は実装されていません" というエラーが発生します。
機能の範囲がファーム レベルに設定されている場合に、クレーム プロバイダーが特定の選択した Web アプリケーションまたはゾーンにのみ使用されるように構成できるでしょうか。答えは複雑です。まず、クレーム プロバイダーの SPClaimProviderDefinition クラスにある 2 つの非常に重要なプロパティ、IsEnabled と IsUsedByDefault について十分に理解する必要があります。既定で、新しいクレーム プロバイダー機能をインストールすると、そのプロバイダーでは IsEnabled プロパティと IsUsedByDefault プロパティが true に設定されます。これは、SAML (Security Assertion Markup Language) クレームがゾーンで有効になっている場所であればどこでもクレーム プロバイダーを使用するという設定です。したがって、たとえクレーム プロバイダーを特定の選択したゾーンで使用するように構成するときでも、その前に IsUsedByDefault プロパティを false に設定する必要があります。IsEnabled は true に等しく、IsUsedByDefault は false に等しいので、クレーム プロバイダーの使用をゾーン単位で構成できます。
明らかに、次の疑問はどうすれば IsUsedByDefault プロパティを false に設定できるかということです。方法は 2 つあります。カスタム クレーム プロバイダー用に機能レシーバーを使用し、そこでプロパティを構成する方法を最初に説明しましょう。FeatureActivated イベントのオーバーライド (これは既にコーディング済みのはずです) で、SPClaimProviderManager を使用してプロバイダーへの参照を取得し、IsUsedByDefault プロパティを false に設定します。以下に、筆者がクレーム プロバイダーの 1 つに使用したコードをサンプルとして示します。
SPClaimProviderManager cpm = SPClaimProviderManager.Local;
foreach (SPClaimProviderDefinition cp in cpm.ClaimProviders)
{
if (cp.ClaimProviderType == typeof(SqlClaimsProvider.SqlClaims))
{
cp.IsUsedByDefault = false;
cpm.Update();
break;
}
}
このコードでは、typeof(SqlClaimsProvider.SqlClaims) を使用し、アセンブリとクラスの名前をクレーム プロバイダーの名前に置き換えます (たとえば、typeof(MyProvider.MyClaims))。また、このコードをカスタム アプリケーションでラップすることもできます。このサンプル コードではその方法を採用しました。コードの残りの部分も、この記事の説明を進めるなかで順次記載していきます。
図 1 は、この Claims Provider Activation アプリケーションのスクリーンショットです。アプリケーションの左側には、登録済みのカスタム クレーム プロバイダーの一覧 (この例では 1 つのみ) が表示されます。登録済みのカスタム クレーム プロバイダーの下にあるチェック ボックスは、そのクレーム プロバイダーの IsEnabled プロパティと IsUsedByDefault プロパティの設定を変更するときに使用します。
注意
この Claims Provider Activation アプリケーションをダウンロードして試すには、「Configuring a Custom Claims Provider to Be Used Only on Select Zones in SharePoint 2010(英語)」を参照してください。
図 1. 登録済みのカスタム クレーム プロバイダーを表示する Claims Provider Activation アプリケーション
.jpg "クレーム プロバイダー アクティベーション アプリケーション")
プロパティを設定するには、最初にカスタム クレーム プロバイダーを選択してから、必要なチェック ボックスをオンにして IsEnabled プロパティと IsUsedByDefault プロパティを設定し、最後に [Update] ボタンをクリックします。
クレーム プロバイダーの IsEnabled のみをオンにし、IsUsedByDefault をオンにしなかった場合は、クレーム プロバイダーを使用する場所を構成できます。このように構成したクレーム プロバイダーは、ClaimsProviders プロパティに設定されたクレーム プロバイダーの名前がゾーンの SPIisSettings 含まれるときにのみ使用されます。一般的な手順でこの情報を取得しようとすると、Claims Provider Activation アプリケーションで筆者が行ったように多少の困難が伴います。最初の手順として、すべての Web アプリケーションを列挙する必要があります。これには、SPService クラスを使用します。
//Get the content service.
SPWebService ws = SPWebService.ContentService;
//Get each web application.
foreach (SPWebApplication wa in ws.WebApplications)
{
//Enumerate each zone in each web application.
}
Web アプリケーションの各ゾーンを列挙することは、あまり行わない操作です。以下に、各ゾーンを列挙するコードの例を示します。
foreach (SPAlternateUrl aam in wa.AlternateUrls)
{
//Look at each zone to see whether it is using SAML claims.
}
ゾーンで SAML クレームが使用されているかどうかを確認するために、最初にゾーンの SPIisSettings を取得します。先ほども説明しましたが、クレーム プロバイダーを ClaimsProviders プロパティに追加するか、そこから削除するには、この操作を行う必要があります。ゾーンの SPIisSetting を取得するコード スニペットを以下に示します。
SPIisSettings curConfig = wa.GetIisSettingsWithFallback(aam.UrlZone);
curConfig 変数では、ClaimsAuthenticationProviders プロパティの値をチェックします。ゾーンがクレームを使用する構成になっている場合、ClaimsAuthenticationProviders プロパティは null ではなく、カウントはゼロより大きい値になります。
ここではすべてのクレーム プロバイダーを列挙し、そのなかに ClaimsProviders プロパティに設定されているクレーム プロバイダーの名前を含む SPIisSettings を持つゾーンのクレーム プロバイダーがあれば、そのゾーンを一覧に追加し、有効として表示します。それ以外の場合は、そのゾーンにカスタム クレーム プロバイダーを使用できません。そのときはゾーンを一覧に追加したうえで無効として表示します。
基本的に、このような手順で Web アプリケーションとゾーンの一覧を作成し、カスタム クレーム プロバイダーを使用できるゾーンを確認します。
このゾーンの一覧については、SPIisSettings オブジェクトの ClaimsProviders プロパティにカスタム クレーム プロバイダー名が設定されていれば、そのクレーム プロバイダーが使用されます。
ClaimsProviders プロパティは、実際には string 型の IEnumerable であり、Add、Remove、または RemoveAt アイテムのオーバーロードされたメソッドが含まれないため、手順は多少見苦しくなります。この問題を解決するため、このプロパティを取得して List<string> に変換し、クレーム プロバイダー名の追加や削除を行えるようにしてから、List<string> を ClaimsProviders プロパティに設定しました。
以下は、このコードの例です。
List<string> providers = theZoneIisSettings.ClaimsProviders.ToList();
//NOTE: myClaimProvider is type SPClaimProviderDefinition.
if (EnableProvider)
providers.Add(myClaimProvider.ClaimProvider.Name);
else
providers.Remove(myClaimProvider.ClaimProvider.Name);
//Plug the new values back into the ClaimsProviders Ienumerable.
theZoneIisSettings.ClaimsProviders = providers;
//You must get the web application that contains the zone, and then call its
//Update method to save your changes.
theWebApp.Update();
図 2 に、Claims Provider Activation アプリケーションでの Web アプリケーションとゾーンの選択状態を示します。
図 2. 特定のカスタム クレーム プロバイダーの Web アプリケーションとゾーンを表示する Claims Provider Activation アプリケーション
.jpg "クレーム プロバイダー アクティベーション アプリケーションとゾーン")
この例では、Basketball Teams プロバイダーがこのゾーンでは有効になっていないため、メニューの表示は [Enable Basketball Teams] です。仮に有効であれば、表示は [Disable Basketball Teams] になります。その上のゾーンで、SharePoint – Anon Profile Test Web アプリケーションが無効になっていることに注目してください。これらのゾーンは、SAML クレームを使用する構成になっていないため、このように表示されます。
これですべてのプロセスの説明が終わりました。やや複雑ですが、構成には高い柔軟性があります。
ヒント 2: クレーム名を解決する
クレーム名の解決に関する問題を数回目にする機会があり、この問題のトラブルシューティングを試みる状況が今後あることを想定して、この問題に関する情報をここに提供することにします。筆者は、名前の解決が機能しないケースに遭遇した経験があります。たとえば、入力コントロールに名前を入力してから名前解決のボタンをクリックした場合などです。カスタム クレーム プロバイダーの開発中にデバッガーを接続していた場合でも、カスタム クレーム プロバイダーは正常に動作するのに、入力した名前に波打った赤い下線が引かれ、検索で一致する名前が見つからないことが通知されることがあります。
この問題に関する別の現象は、既定のクレーム プロバイダーも機能しなくなることです。たとえば、「NT 権限/すべての認証されたユーザー」と入力しても、名前が解決されません。
一部のクレーム プロバイダーが、FillResolve オーバーロードの呼び出し時にどこかで例外をスローしていることが問題の背景にあります。ここで特に事態を悪いものにするのは、恐らくこのヒントの冒頭で既に予感されたと思いますが、1 つのクレーム プロバイダーの異常によってファームの名前解決全体が機能しなくなることです。
したがって、既定のクレーム プロバイダーが名前を解決できないというこのシナリオが発生した場合、まずカスタム クレーム プロバイダーを探してください。他のユーザーが開発したカスタム クレーム プロバイダーが含まれている場合は、問題のカスタム クレーム プロバイダーを特定するために、おそらくカスタム クレーム プロバイダーを 1 つずつ削除していく必要があります。当然ながら、カスタム クレーム プロバイダーの削除に関しては別の留意事項があります。特に、カスタム クレーム プロバイダーを削除したときと異なる順序で追加すると、基となるクレームが以前と異なって生成されます。これは、クレームの一部がクレーム プロバイダーを追加した順序に基づいて機能するためです。
ただし、この記事の本題は、この名前解決の問題が起きたときに注目すべき場所と、その問題を解決する方法についてです。
注意
先ほどの説明は、カスタム クレーム プロバイダーを開発するときはクレーム プロバイダーから例外をスローするべきではないことの実例を示すために書きました。そのような操作を行えば、ファーム内での名前解決を阻害する可能性がある "悪の" プロバイダーを生み出す危険性があります。
ヒント 3: サインインと認証時の忌まわしい 3 回のログオン プロンプト
認証時にログオン プロンプトが 3 回にわたって表示される問題は、あまりに多く見られるものです。筆者は今週もこの問題に遭遇しましたが、それは不運にも再ビルドを実行する必要があった Active Directory Federation Services (ADFS) サーバーで発生しました。プロンプトが表示される最も一般的な理由として、Kerberos プロトコル設定が正しく構成されていないか、Web アプリケーションのサーバー名と異なる名前が使用されていること (無効なループバックのシナリオ) が挙げられます。
今回の問題はどちらにも該当せず、ADFS サーバーに固有の問題なので、同じ問題が将来起きた場合の参考になるように記録に留めておくことにしました。
Active Directory Federation Services (AD FS) 2.0 は、問題をイベント ログに書き込むには非常に便利なツールです。このイベント ビューアーを開くと、AD FS 2.0 用の独立したノードが表示されます。この AD FS 2.0 ノードを使用して問題を追うことができます。今回のシナリオでは、ここに疑わしい場所が見つかりました。忌まわしい 3 回のログオン プロンプトを発生する要因は 1 つではなかったため、解析にはかなりの時間が必要でした。
ADFS サーバーは、次のように構成されていました。
ADFS サーバーをドメイン アカウントとして実行する
トークン署名用に作成した証明書を ADFS に使用する
問題は、ADFS に使用したサービス アカウントが、トークン署名証明書の秘密キーにアクセスする権限を持たないことでした。そのため、ログオン プロンプトが 3 回にわたって表示されるという、何度目にしても愉快であり、驚かされる、苛立たしい現象が起きます。
証明書の秘密キーにアクセスする権限をサービス アカウントに与えるには、次の手順を実行します。
Microsoft 管理コンソール (MMC) を実行します。
[ローカル コンピューター] に 証明書スナップイン(英語)(Certmgr.dll) を追加します。
[個人用] ノードを開きます。
トークン署名証明書を右クリックし、[秘密キーの管理] をクリックします。
この情報がトラブルシューティングの時間を節約するのに役立つことを願います。
ヒント 4: カスタム クレーム プロバイダーの既定のソリューション展開を認識する
以前に、友人の Tom W. 氏 (SharePoint 2010 Kerberos white paper(英語) の執筆者) がソリューション展開の限界とカスタム クレーム プロバイダーの効果をみごとに指摘したことがありました。カスタム クレーム プロバイダーを開発するときは、エンドユーザー 向けの Web アプリケーション以外の場所で使用される可能性があることに留意する必要があります。たとえば、サーバーの全体管理で Web アプリケーション ポリシーを作成しているときは、その場所でカスタム クレーム プロバイダーが使用されます。[個人用サイト] でユーザーの権限を構成しているときは、その場所でカスタム クレーム プロバイダーが呼び出されます。Secure Store Service を使用しているときは、その場所でもカスタム クレーム プロバイダーが呼び出されます。
この問題は、規模の大きなファームを構築すると表面化します。さまざまなサービスがカスタム クレーム プロバイダー フレームワークを呼び出しているので、各カスタム クレーム プロバイダーのアセンブリを各サーバーのグローバル アセンブリ キャッシュに配置する必要があります。しかし、既定の SharePoint ソリューション展開フレームワークでは、ソリューションは Web フロントエンド サーバーにのみ展開されます。
ソリューション展開のスキーマを考慮するなら、DeploymentServerType 属性に設定できる唯一のオプションは ApplicationServer 値か WebFrontEnd 値です。実際には両方の値が必要です。なぜならば、規模の大きなファームでは Web アプリケーション サービスをアプリケーション サーバーで実行しないケースがあるからです。そのような構成では、カスタム クレーム プロバイダーは、アプリケーション サーバーのグローバル アセンブリ キャッシュに存在しません。カスタム クレーム プロバイダー フレームワークを呼び出す機能を使用すると、アセンブリが存在しないため、エラーが生成されます。
残念なことに、この問題を回避するには以下のいずれかの操作を実行するしかありません。
Web アプリケーション サービスをファームのすべてのサーバーで実行します。
カスタムの展開ジョブ、イベント レシーバー、タイマー ジョブ、またはそれに類するものを作成し、アセンブリをすべてのアプリケーション サーバーに展開します。
アセンブリを手動で展開します。
いずれのオプションも一長一短です。仮に筆者が 1 つを選ぶなら、最初のオプション (ファーム内のすべてのサーバーで Web アプリケーション サービスを実行する) を選び、これらのサーバーがエンドユーザー負荷分散プールに追加されないように注意します。
現状では、この問題の存在を知らせ、ファームで対策が必要な場合に適切に対応できるように注意を喚起することが筆者の狙いです。この問題も Tom が指摘したものであり、協力に感謝します。
ヒント 5: クレームベース認証で発生する TrustedMissingIdentityClaimSource エラーを解決する
自身の体験を含め、TrustedMissingIdentityClaimSource エラーが発生するのを数回見たことがあるので、原因と疑わしいものをここに紹介することにしました。このエラーが発生するのは、SharePoint 2010 でクレームベース認証を設定したときです。構成に誤りはないことは確認済みと仮定します。
ところが、動作を確認するためにサイトに移動すると、標準の Microsoft ASP.NET エラー ページが表示され、TrustedMissingIdentityClaimSource エラー (カスタム エラーを無効に設定してあると仮定する) の発生が通知されます。このエラーが発生する状況として最も多いのは、電子メール アドレスが ID 要求として構成されているときに、ログオンするために使用するユーザーが Active Directory (または使用中のディレクトリ) に電子メール アドレスを持っていない場合です。このとき ADFS (または使用中の ID プロバイダーのセキュリティ トークン サービス) にリダイレクトされるため、状況がさらにわかりづらくなります。画面上は認証済みに見えますが、TrustedMissingIdentityClaimSource エラーが Microsoft SharePoint Server に表示されます。
このエラーは、自分がだれであるかを示す情報 (ログインするユーザーの ID) と自分に関する情報 (たとえば、電子メールなど、SharePoint 2010 で権限を準備するために使用されるクレームの属性) に不一致があることを通知するものです。
したがって、このエラーが表示された場合は、ログオンに使用したユーザー アカウントが ID プロバイダーに受理される ID クレーム値を持っているかどうかを、まず確認することをお勧めします。また、そのような属性に値が設定されていないと、通常、クレームは SharePoint Server に送信さえされない (空の文字列値などが送信されない) ことにも注意してください。
まとめ
この記事では、SharePoint 2010 のクレームベース認証についてのよくある質問の回答を提供しています。クレームの使用および構成に関連する問題を解決するのに役立つ 5 つのヒントおよびガイダンスも提供しています。また、詳細な情報を確認できるその他の資料も紹介しています。
参考資料
詳細については、次のリソースを参照してください。