クレームに関するヒント 1 : SharePoint 2010 のクレームベース認証についての説明

  • [アーティクル]

**概要:**SharePoint 2010 のクレームベース認証に関連する 5 つのヒントを紹介します。

最終更新日: 2011年8月12日

適用対象: Business Connectivity Services | Open XML | SharePoint Designer 2010 | SharePoint Foundation 2010 | SharePoint Online | SharePoint Server 2010 | Visual Studio

この記事の内容
この記事の対象範囲の概要
ヒント 1: 1 つの SharePoint 2010 ファームに複数のクレーム認証 Web アプリケーションを作成する
ヒント 2: SharePoint 2010 で Web アプリケーションを Windows クラシックから Windows クレームに移行する
ヒント 3: SharePoint 2010 のクレーム認証サイトで対象ユーザーを使用する
ヒント 4: SharePoint 2010 クレーム認証アプリケーションの ID クレームとロール クレームを作成する
ヒント 5: SharePoint 2010 で自分がどのクレームを所有しているかを判断する
まとめ
その他の技術情報

提供元:  Steve Peschka、Microsoft Corporation

目次

  • この記事の対象範囲の概要

  • ヒント 1: 1 つの SharePoint 2010 ファームに複数のクレーム認証 Web アプリケーションを作成する

  • ヒント 2: SharePoint 2010 で Web アプリケーションを Windows クラシックから Windows クレームに移行する

  • ヒント 3: SharePoint 2010 のクレーム認証サイトで対象ユーザーを使用する

  • ヒント 4: SharePoint 2010 クレーム認証アプリケーションの ID クレームとロール クレームを作成する

  • ヒント 5: SharePoint 2010 で自分がどのクレームを所有しているかを判断する

  • まとめ

  • その他の技術情報

クリックしてコードを取得この記事に含まれるコード例をダウンロードする:SharePointClaims_MSDNExample.zip (英語)

この記事の対象範囲の概要

この記事では、Microsoft SharePoint 2010 のクレームベース認証に関するヒントやよくある質問の回答を提供します。クレームの使用および構成に関連する問題を解決するのに役立つヒントおよびガイダンスも提供します。また、詳細な情報を確認できるその他の資料も紹介します。

注意

この記事に含まれるコード例 SharePointClaims_MSDNExample.zip (英語) は、「ヒント 5: SharePoint 2010 で自分がどのクレームを所有しているかを判断する」を対象としています。

ヒント 1: 1 つの SharePoint 2010 ファームに複数のクレーム認証 Web アプリケーションを作成する

クレーム認証を使用する複数の Web アプリケーションを SharePoint 2010 で構成する方法を理解するうえで戸惑うことが多いのは、SPTrustedIdentityTokenIssuer オブジェクトに関連しています。ブログ エントリ「Planning Considerations for Claims Based Authentication in SharePoint 2010 (英語)」に記載したように、SPTrustedIdentityTokenIssuer オブジェクトには Security Token Service (STS) からのトークン署名証明書だけを関連付けることができます。SPTrustedIdentityTokenIssuer オブジェクトを作成するとき、その SPTrustedIdentityTokenIssuer オブジェクトには次の情報を通知します。

  • 使用しているトークン署名証明書。

  • 使用している領域。

領域は、STS に送り返されたクエリ文字列に含まれるので重要です。STS はその領域を使用して証明書利用者を確認します。これにより、その STS は処理対象のクレーム ルールや、Web アプリケーションの信頼ポリシーを検索するときに使用する URL を把握します。Active Directory Federation Services (AD FS) 2.0 などには複数のトークン署名証明書を追加できますが、特定のトークン署名証明書を特定の証明書利用者で使用しなければいけないようにする方法はありません。そこで、1 つの証明書で機能するようにする方法を見つけることが本当に必要なのです。

SPTrustedIdentityProvider オブジェクトには、複数の領域をとる ProviderRealms プロパティが含まれます。たとえば、https://collab と https://mysites の 2 つのアプリケーションがあるとします。Windows PowerShell を使用して、次のコマンドレット スニペットのような SPTrustedIdentityTokenIssuer を作成します。

$realm = "urn:sharepoint:collab"
$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS v2" -Description "ADFS v2" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map -SignInUrl "https://URLToYourAdfsServer/adfs/ls" -IdentifierClaim https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

これで SPTrustedIdentityTokenIssuer オブジェクトが作成されました。このオブジェクトには urn:sharepoint:collab という既定の領域が含まれます。AD FS 2.0 に証明書利用者を作成し、その利用者に識別子が urn:sharepoint:collab および https://collab/_trust/ であることを通知します。次に、2 つ目の Web アプリケーションをサポートするために、別の領域を SPTrustedIdentityTokenIssuer オブジェクトに追加する必要があります。そのための Windows PowerShell コードを次に示します。

$uri = new-object System.Uri("https://mysites")
$ap.ProviderRealms.Add($uri, "urn:sharepoint:mysites")
$ap.Update()

ここで理解すべき重要なポイントが URI です。URI は、その領域を使用する Web アプリケーションへの URL である必要があります。認証中、SharePoint はルックアップを実行し、その Web アプリケーションの URI に関連付けられている領域を探します。これが SharePoint によって使用される URI になります。この場合は、https://mysites の Web アプリケーションで領域 urn:sharepoint:mysites が使用されるようにしたいので、領域を追加したときに、その URI にプラグインしました。これで、AD FS 2.0 に戻って、2 つ目の証明書利用者を urn:sharepoint:mysites および https://mysites/_trust/ の識別子で定義でき、すべてが適切に機能するはずです。

ヒント 2: SharePoint 2010 で Web アプリケーションを Windows クラシックから Windows クレームに移行する

Windows クラシック認証を使用する Web アプリケーションがあり、そのアプリケーションを Windows クレーム認証を使用するように変更したい場合はどうすればよいのでしょう。たとえば、Windows クラシックで開始したが、クレーム認証に移行したくなることがあります。あるいは、アップグレードした SharePoint 2007 サイトを持っていた可能性もあります。ここでは、比較的小規模なテスト事例でこれを行いました。また、確認したプロセスや情報を共有する必要がありました。

注意に関するメモ注意

Windows クレームに移行すると、Windows クラシックには戻ることができないので、必ずバックアップをとってから、開始するようにしてください。ここでは、Microsoft SQL Server にコンテンツ データベースをバックアップし、サーバーの全体管理に Web アプリケーションをバックアップしました。実稼働に移行する前に、まずラボでこれを試すことを強くお勧めします。

注意はさておき、このプロセス自体は非常に単純です。少し時間をかけて数行の Windows PowerShell コードを記述するだけで実現できるはずです。次に示すのは Windows PowerShell コマンドです。

$WebAppName = "http://yourWebAppUrl"
$account = "yourDomain\yourUser"
$wa = get-SPWebApplication $WebAppName

Set-SPwebApplication $wa -AuthenticationProvider (New-SPAuthenticationProvider) -Zone Default
#This causes a prompt about migration. Click Yes and continue.

#The following step sets the user as an administrator for the site. 
$wa = get-SPWebApplication $WebAppName
$account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString()

#After the user is added as an administrator, we set the policy so that the user can have the correct access.
$zp = $wa.ZonePolicies("Default")
$p = $zp.Add($account,"PSPolicy")
$fc=$wa.PolicyRoles.GetSpecialRole("FullControl")
$p.PolicyRoleBindings.Add($fc)
$wa.Update()

#The final step is to trigger the user-migration process.
$wa = get-SPWebApplication $WebAppName
$wa.MigrateUsers($true)

上記のコマンドを実装しても、次のような問題がいくつか残る可能性があります。

  • **ユーザーがログオンできない。**ユーザーがサイトにログオンできない場合があります。資格情報を入力すると、自分がアクセス権のない domain\user である旨が通知されることがあります。このメッセージが表示された場合は、移行前に Web アプリケーションの portalsuperuseraccount プロパティと portalsuperreaderaccount プロパティを構成した可能性があります。これを、新しいクレームベースのアカウント名を使用するように更新する必要があります。新しいクレーム ベースのアカウント名を取得するには、移行後に Web アプリケーションの Web アプリケーション ポリシーを確認します。そこからアカウント名をコピーしてください。

  • **既存の警告が表示されない。**既存の警告が表示されない場合、現時点での対処方法としては、その警告を削除して再作成するしかありません。

  • **検索クロールが機能しない。**Web アプリケーション ポリシーをダブルクリックし、変換された新しいアカウント名が検索クロール アカウントに表示されることを確認します。表示されない場合は、クロール アカウントのポリシーを手動で新しく作成する必要があります。

さらに、MigrateUsers コマンドレットがタイマー ジョブで実行されるので、それが完了するのを待たなければならない可能性があります。完了後、次のことを確認しました。

  • **ユーザーがログオンできる。**個別に追加されたユーザー、および SharePoint グループに追加された Active Directory グループに所属しているユーザーがログインできます。

  • **タスク リストの [自分のタスク] ビューが引き続き動作する。**Windows クラシックの認証済みユーザーとして自分に割り当てられたアイテムは、引き続き [自分のタスク] に表示されます (つまり、"Windows クレーム Steve" は以前の "Windows クラシック Steve" として認識されます)。

  • **プロセス内にあった承認ワークフローが引き続き動作する。**承認ワークフローを引き続き適切に完了できます。

  • **プロセス内にあった SharePoint Designer のカスタム ワークフローが引き続き動作する。**自分のカスタム ワークフローを引き続き適切に完了できます。

  • **SharePoint Designer ワークフローを作成できる。**既定のワークフローおよび SharePoint Designer のカスタム ワークフローの新しいインスタンスを作成できます。

  • **Web アプリケーションをクロールできる。**Web アプリケーションを適切にクロールできます。

  • **コンテンツに対してクエリを実行できる。**Web アプリケーションをクロールし、コンテンツに対して適切にクエリを実行できます。

これまでにわかっている例外的な動作がいくつかあります。たとえば、サイト内で新しい警告を作成すると、適切に作成されたことが通知されますが (その旨を通知する電子メール メッセージも届きます)、警告を管理しようとリストを確認しても、その警告は表示されません。また、変更しても警告の電子メール メッセージは生成されません。その他にも例外的な動作が見つかったら、ブログ (英語)で紹介していく予定です。

ヒント 3: SharePoint 2010 のクレーム認証サイトで対象ユーザーを使用する

SAML (Security Assertion Markup Language) クレームの使用に関する検討事項として忘れがちなのは、SharePoint 2010 の対象ユーザー機能に対する影響です。既定では、Active Directory などのディレクトリおよびライトウェイト ディレクトリ アクセス プロトコル (LDAP) ソースからのみユーザーをインポートします。

問題は、ほとんどの SAML クレームのユーザーのアカウント名が i:05:t|adfs with roles|fred@contoso.com のような名前であるという点です。これらのクレーム ユーザーで対象ユーザーは使用できるのでしょうか。答えはイエスです。ただし、それには行わなければならない作業がいくつかあります。

まず最も重要なのは、これらのユーザーのプロファイルを作成する必要があるということです。このプロファイルは手動で作成することも、コードを記述して作成することもできます。ただし、これらのプロファイルを作成し、i:05:t|adfs with roles|fred@contoso.com といった文字列をアカウント名として使用し、他のフィールドには、対象ユーザーに使用するデータを設定する必要があります。

次に、新しい対象ユーザーを作成します。[グループのメンバー] などのユーザー ベースの対象ユーザーを使用することはできません (少なくとも追加のコードを記述せずに使用することはできません。追加コードの記述についてはここでは説明しません)。ここでは、代わりにプロパティ ベースの対象ユーザーを使用します。このシナリオでは、プロファイルの Office フィールドを対象ユーザーのベースとして使用し、2 人の異なるクレーム ユーザーに対して 2 つのプロファイルを作成しました。そして、一方のプロファイルには Contoso の Office フィールドを、もう一方のプロファイルには Wingtip Toys の Office フィールドを設定し、新しい対象ユーザーに Office = Contoso というルールを作成して、Contoso Employees という名前を付けました。対象ユーザーをコンパイルすると、メンバーシップに自分のクレーム ユーザーが含まれていることを確認できました。

これをさらに検証するために、クレーム サイトにアクセスし、Web パーツの対象を対象ユーザーに設定しました。唯一予期できなかったのは、対象ユーザーの一覧がユーザー選択ウィンドウに適切に設定されなかったという点ですが、Contoso Employees を検索することで、作成した対象ユーザーが見つかりました。そして、Web パーツの対象である対象ユーザーを選択し、変更を保存して、最後に、2 つの異なるクレーム ユーザーとしてサイトに移動しました。すると、Contoso Employees 対象ユーザーに含まれるユーザーにはパーツが表示され、そうでないユーザーには表示されませんでした。

ヒント 4: SharePoint 2010 クレーム認証アプリケーションの ID クレームとロール クレームを作成する

さまざまな理由から、クレームベース認証の Web アプリケーションを起動し、ID クレームおよびロール クレームの両方と適切に動作させるには手間がかかります。そこで、ここではクレームと SPTrustedIdentityTokenIssuer オブジェクトを作成する手順を紹介します。

  1. 次のコードに示すように、ID クレームを作成します。

    $map = New-SPClaimTypeMapping -IncomingClaimType "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" 
-IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

  2. 次のコードに示すように、ロール クレームを作成します。

    $map2 = New-SPClaimTypeMapping -IncomingClaimType " https://schemas.microsoft.com/ws/2008/06/identity/claims/role " -IncomingClaimTypeDisplayName "Role" -SameAsIncoming

  3. 次のコードに示すように、SPTrustedIdentityTokenIssuer オブジェクトを作成するときに両方のクレームを含みます。

    $ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS v2" -Description "ADFS v2" 
-Realm "yourRealmName" -ImportTrustCertificate $yourCert -ClaimsMappings $map,$map2 
-SignInUrl "https://URLToYourAdfsServer/adfs/ls" -IdentifierClaim "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"

ここで重要なのは、トークン発行元を作成するときに両方のクレームを含む必要があるという点です。これを後で追加することはできません。これは SPTrustedIdentityTokenIssuers の制限の 1 つです。

ヒント 5: SharePoint 2010 で自分がどのクレームを所有しているかを判断する

対処中の問題の中で興味深いもの 1 つは、クレーム認証サイトで発生する不明な権限エラーに関係がありました。状況のトラブルシューティングを行ううえで問題になることの 1 つに、SharePoint によってクレームとして判断されるクレームを列挙せず、それを他の場所にダンプするというものがあります。

したがって、サイトにアクセスしたときに、アクセス拒否エラーが発生した場合、またはアクセスするべきコンテンツの一部へのアクセス許可がなかった場合は、なぜそうなったのかを判断する適切な方法がありませんでした。このようなシナリオでデバッグを行うために、SharePoint が所有する自分用のクレーム、つまり現在のユーザー要求を通知する簡単なコードを記述し、次の 2 つの方法でこれを実装しました。

  • アセンブリの 1 つのパーツは HttpModule として実装され、クレームを列挙し、統合ログ サービス (ULS) ログに出力します。このエントリは、ULS ログを [SharePoint Claims Enumeration] カテゴリによってフィルターすることで簡単に見つけることができます。HttpModule は、サイトにログインできない場合に役に立ちます。

  • アセンブリの 2 つ目のパーツは Web パーツとして実装され、自身のクレームと各クレームの値を作成します。これは、サイトにログオンできるけれども、アクセスするべきコンテンツの一部にアクセスできない原因を突き止めるのに役立ちます。

この記事のコード例 SharePointClaims_MSDNExample.zip (英語) には、このアセンブリのソース コードとデバッグ バージョンが含まれています。使用方法については、Instructions.txt ファイルを参照してください。

SharePoint のクレームに関してわかったことでもう 1 つ重要なのは、STS に対する認証の後に、トークンが SharePoint に戻されるという点です。SharePoint には自身が表示できるクレームの一覧が含まれています。SharePoint はその一連のクレームすべてを検索し、SPClaim オブジェクトに組み込みます。STS が、SharePoint で表示できる以外のクレームを送り返すと、その追加クレームは SharePoint によって無視され、SPClaim オブジェクトに追加されません。これを覚えておくと、クレーム認証に関する問題のトラブルシューティングを行うときに役に立つ場合があります。

まとめ

この記事では、SharePoint 2010 のクレームベース認証についてのよくある質問の回答を提供しています。クレームの使用および構成に関連する問題を解決するのに役立つ 5 つのヒントおよびガイダンスも提供しています。また、詳細な情報を確認できるその他の資料も紹介しています。

その他の技術情報

詳細については、次のリソースを参照してください。