認証方法を計画する (SharePoint Foundation 2010)

  • [アーティクル]

 

適用先: SharePoint Foundation 2010

この記事では、Microsoft SharePoint Foundation 2010 でサポートされる認証方法と認証モードについて説明します。認証とは、ユーザーの ID を検証するプロセスです。ユーザーの ID の検証が終わると、ユーザーがアクセスできるサイト、コンテンツ、機能などが認証プロセスによって決定されます。認証モードは、SharePoint Foundation 2010 による内部でのアカウントの使用方法を決定します。

この記事の内容

  • サポートされる認証方法

  • 認証モード - クラシックまたはクレームベース

  • Windows 認証の実装

  • フォーム ベース認証の実装

  • SAML トークンベース認証の実装

  • LDAP 環境用の認証の選択

  • Web アプリケーション用ゾーンの計画

  • SAML トークンベース プロバイダー用アーキテクチャ

サポートされる認証方法

SharePoint Foundation 2010 は、以前のバージョンが備えていた認証モードをサポートしています。また、オプションとして、SAML (Security Assertion Markup Language) に基づくトークンベース認証も導入しています。サポートしている認証方法を次の表に示します。

方法 例 メモ

Windows

  • NTLM

  • Kerberos

  • 匿名

  • 基本

  • ダイジェスト

現在、Windows 証明書認証はサポートされていません。

フォームベース認証

  • ライトウェイト ディレクトリ アクセス プロトコル (LDAP)

  • SQL データベースなどのデータベース

  • カスタムまたはサードパーティのメンバーシップ プロバイダーおよびロール プロバイダー

SAML トークンベース認証

  • Active Directory フェデレーション サービス (AD FS) 2.0

  • サードパーティの ID プロバイダー

  • ライトウェイト ディレクトリ アクセス プロトコル (LDAP)

WS-Federation のパッシブなプロファイルを使用する SAML 1.1 でのみサポートされます。

認証モード — クラシックまたはクレームベース

SharePoint Foundation 2010 は、Windows Identity Foundation (WIF) に基づくクレームベース認証を導入しています。クレームベース認証では、サポートされているどの認証方法でも使用できます。また、クラシックモード認証を使用することもできます。クラシックモード認証は Windows 認証をサポートしています。

Web アプリケーションを作成するときは、Web アプリケーションで使用する認証モードとして、クレームベースまたはクラシックモードのどちらかを選択します。

クレームベースまたはクラシック モード認証

クラシックモードを選択すると、Windows 認証を実装でき、ユーザー アカウントは、SharePoint Foundation 2010 によって Active Directory ドメイン サービス (AD DS) アカウントとして処理されます。

クレームベース認証を選択すると、SharePoint Foundation 2010 では、すべてのユーザー アカウントが自動的にクレーム ID に変更され、その結果、各ユーザーのクレーム トークンになります。クレーム トークンには、ユーザーに関するクレームが含まれています。Windows アカウントは Windows クレームに変換されます。フォームベースのメンバーシップ ユーザーは、フォームベース認証クレームに変換されます。SAML ベーストークンに含まれるクレームは、SharePoint Foundation 2010 で使用できます。また、SharePoint の開発者と管理者は、ユーザー トークンを追加クレームで補うことができます。たとえば、ユーザーの Windows アカウントとフォームベース アカウントは、SharePoint Foundation 2010 で使用される追加クレームによって補うことができます。

次の表に、認証の種類に対するサポートを認証モード別に示します。

種類 クラシックモード認証 クレームベース認証

Windows

  • NTLM

  • Kerberos

  • 匿名

  • 基本

  • ダイジェスト

はい

はい

フォームベース認証

  • LDAP

  • SQL データベースなどのデータベース

  • カスタムまたはサードパーティのメンバーシップ プロバイダーおよびロール プロバイダー

いいえ

はい

SAML トークンベース認証

  • AD FS 2.0

  • Windows Live ID

  • サードパーティの ID プロバイダー

  • LDAP

いいえ

はい

SharePoint Foundation 2010 ファーム内では、両方のモードを使用する Web アプリケーションを組み合わせて使用できます。サービスは、従来の Windows アカウントであるユーザー アカウントと Windows クレーム アカウントを区別しません。したがって、認証モードの組み合わせが構成されたサイトに属するユーザーは、Web アプリケーション用にどのモードが構成されているかに関係なく、自分がアクセスするすべてのサイトからの結果を含む検索結果を受け取ります。サービスとサービス アプリケーションは、Web アプリケーションとユーザー用にどのモードが選択されているかに関係なく、ファーム間通信にクレーム ID を使用するので、ユーザーが別々の 2 つのユーザー アカウントとして解釈されることはありません。

ただし、SharePoint Server Web アプリケーションによって認識される複数のユーザー リポジトリにユーザーが属している場合は、ログインにどの ID を使用しているかに応じて、異なるユーザー アカウントとして処理されます。

どのモードを選択すると良いかの判断については、次のガイドラインに従うと簡単です。

  • SharePoint Foundation 2010 を新しく実装する場合は、クレームベース認証を使用します。クレームベース認証を使用すると、サポートされているすべての認証の種類を Web アプリケーションで使用できます。環境に Windows 認証しか含まれないとしても、新たな展開を行う場合にクラシックモード認証を選択する実際的な理由はありません。Windows 認証は、どのモードが選択されていても、同じ方法で実装されます。クレームベース認証モードを使用するときも、Windows 認証を実装する追加手順は発生しません。

  • 以前のバージョンのソリューションを SharePoint Foundation 2010 にアップグレードし、そのソリューションに Windows アカウントのみが含まれる場合は、クラシックモード認証を使用できます。この認証モードを使用すると、ゾーンと URL に同じ設計を使用できます。

  • フォームベース認証を必要とするソリューションをアップグレードする場合は、クレームベース認証へのアップグレードが唯一のオプションです。

以前のバージョンから SharePoint Foundation 2010 にアップグレードして、クレームベース認証を選択する場合は、次の点に注意してください。

  • 場合によっては、カスタム コードを更新する必要があります。Web パーツや、Windows ID に依存または使用する他のカスタム コードは、更新する必要があります。カスタム コードで Windows ID を使用している場合は、コードが更新されるまでクラシックモード認証を使用してください。

  • 多数の Windows ユーザーをクレーム ID に移行するのには時間がかかります。アップグレード プロセスで Web アプリケーションをクラシック モードからクレームベースに変更するときは、Windows PowerShell を使用して Windows ID をクレーム ID に変換する必要があります。この処理には時間がかかることがあります。このタスクを完了できるようにアップグレード プロセスには十分な時間を確保してください。

  • 現在、クレームベース認証では、検索通知はサポートされていません。

クレーム認証は WIF に基づきます。WIF とは、クレームベース ID の実装に使用する一連の .NET Framework クラスです。クレーム認証では、WS-Federation、WS-Trust、プロトコル (SAML など) などの標準規格を利用します。クレーム認証の詳細については、次の資料を参照してください。

SharePoint Foundation 2010 でクレーム認証を使用するためにクレーム アーキテクトである必要はありません。ただし、SAML トークンベース認証を実装する場合は、クレームベース環境の管理者と協議する必要があります。これについては後で説明します。

Windows 認証の実装

Windows 認証方法の実装プロセスは、両方の認証モード (クラシックまたはクレームベース) の実装プロセスと似ています。Web アプリケーションにクレームベース認証を選択しても、Windows 認証方法の実装が特に複雑になることはありません。ここでは、各方法の実装プロセスをまとめます。

統合 Windows 認証 — Kerberos と NTLM

Kerberos プロトコルと NTLM は共に統合 Windows 認証方法で、クライアントは資格情報を入力しなくてもシームレスに認証されます。SharePoint サイトにエクスプローラーからアクセスするユーザーは、Internet Explorer プロセスを実行する資格情報を使用して認証されます。既定では、これらの資格情報は、ユーザーがコンピューターへのログオンに使用する資格情報です。統合 Windows 認証モードで SharePoint Server にアクセスするサービスやアプリケーションは、実行中のスレッドの資格情報 (既定ではプロセスの ID) を使用して認証を試みます。

NTLM は、Web アプリケーションの作成時に NTLM を選択するだけで実装できる、最も簡易な Windows 認証です。

Kerberos プロトコルは、チケット認証をサポートする安全なプロトコルです。Kerberos プロトコルを使用する場合は、環境に追加の構成が必要です。Kerberos 認証を有効にするには、クライアント コンピューターとサーバー コンピューターが、ドメインのキー配布センター (KDC) への信頼関係接続を保持していることが必要です。Kerberos プロトコルを構成するには、SharePoint Foundation 2010 をインストールする前に、AD DS にサービス プリンシパル名 (SPN) を設定する必要があります。

Kerberos 認証を構成するプロセスを次の手順にまとめます。

  1. SQL 通信に Kerberos 認証を構成します。そのためには、SQL Server サービス アカウント用として AD DS に SPN を作成します。

  2. Kerberos 認証を使用する Web アプリケーションの SPN を作成します。

  3. SharePoint Foundation 2010 ファームをインストールします。

  4. ファーム内の特定のサービスを、特定のアカウントを使用するように構成します。

  5. Kerberos 認証を使用する Web アプリケーションを作成します。

詳細については、「Kerberos 認証を計画する (SharePoint Server 2010)」を参照してください。

また、クレーム認証 Web アプリケーションの場合は、制約付き委任のために Claims to Windows Token Service を構成する必要があります。クレームを Windows トークンに変換するには制約付き委任が必要です。複数のフォレストが含まれている環境で、Claims to Windows Token Service を使用するには、フォレスト間の双方向で信頼が必要です。このサービスの構成方法の詳細については、「Claims to Windows Token Service の Kerberos 認証を構成する (SharePoint Server 2010)」を参照してください。

Kerberos 認証では、バックエンド データ システムにアクセスするためのクライアント資格情報を委任できますが、シナリオによっては追加構成が必要です。次の表に例を示します。

シナリオ 追加構成

クライアントの ID をバックエンド サーバーに委任する

認証されたコンテンツへの RSS フィードを表示する

コンピューターとサービス アカウントについて Kerberos の制約付き委任を構成します。

Microsoft SQL Server Reporting Services (SSRS) の ID 委任

SQL Server Reporting Services アカウントの SPN を構成します。

SQL Server Reporting Services について委任を構成します。

Excel Services in SharePoint の ID 委任

Excel Services を実行するサーバーについて制約付き委任を構成します。

Excel Services サービス アカウントについて制限付き委任を構成します。

一般的なシナリオでの構成手順など、Kerberos 認証の構成方法の詳細については、Microsoft SharePoint 2010 製品とテクノロジでの Kerberos 認証の構成に関するホワイト ペーパー (英語) (https://go.microsoft.com/fwlink/?linkid=197178&clcid=0x411) (英語) を参照してください。

ダイジェストおよび基本

ダイジェストおよび基本認証を実装するには、インターネット インフォメーション サービス (IIS) に直接構成する必要があります。

フォームベース認証の実装

フォームベース認証は、ASP.NET のメンバーシップ プロバイダーとロール プロバイダーの認証に基づく ID 管理システムです。SharePoint Foundation 2010 では、フォームベース認証は、クレームベース認証の使用時にのみ使用できます。

フォームベース認証は、AD DS 内、SQL Server データベースなどのデータベース内、または Novell eDirectory、Novell Directory Services (NDS)、Sun ONE などの LDAP データ ストア内に格納されている資格情報に対して使用できます。フォームベース認証により、ログオン フォームからの資格情報入力の検証に基づくユーザー認証が有効になります。認証されていない要求はログオン ページにリダイレクトされます。このページでユーザーは有効な資格情報を入力し、フォームを送信する必要があります。要求が認証されると、システムは後続の要求の ID を再確立するためのキーを含む Cookie を発行します。

Windows ベースでない ID 管理システムや外部の ID 管理システムに対するユーザー認証にフォームベース認証を使用するには、メンバーシップ プロバイダーとロール マネージャーを Web.config ファイルに登録する必要があります。ロール マネージャーの登録は、SharePoint Foundation 2010 での新しい要件です。以前のバージョンでは、ロール マネージャーの登録は必須ではありませんでした。SharePoint Foundation 2010 では、標準の ASP.NET ロール マネージャー インターフェイスを使用することによって、現在のユーザーに関するグループ情報を収集します。SharePoint Foundation 2010 の承認プロセスは、各 ASP.NET ロールを 1 つのドメイン グループのように扱います。Web.config ファイルへのロール マネージャーの登録は、認証のためのメンバーシップ プロバイダーの登録と同じ方法で行います。

SharePoint サーバーの全体管理 Web サイトからメンバーシップ ユーザーやロールを管理する場合は、サーバーの全体管理サイトの Web.config ファイルにメンバーシップ プロバイダーとロール マネージャーを登録する必要があります。また、これらのメンバーシップ プロバイダーとロール マネージャーは、コンテンツをホストする Web アプリケーションの Web.config ファイルにも登録する必要があります。

フォームベース認証の構成方法の詳細については、次の資料を参照してください。

SAML トークンベース認証の実装

SAML トークンベース認証では、独自の内部環境またはパートナー環境のどちらであっても、クレームベース環境の管理者と協議する必要があります。クレームベース環境の例として AD FS 2.0 があります。

クレームベース環境には ID プロバイダー STS (IP-STS) が含まれます。IP-STS は、関連するユーザー ディレクトリ内のユーザーに代わって SAML トークンを発行します。トークンは、ユーザー名、ユーザーが属するグループなど、ユーザーに関するクレームをいくつでも含むことができます。

SharePoint Foundation 2010 では、IP-STS が提供するトークンに含まれるクレームを利用してユーザーを認証します。クレーム環境では、SAML トークンを受け付けるアプリケーションは、証明書利用者 STS (RP-STS) と呼ばれます。証明書利用者アプリケーションは SAML トークンを受け取ると、その中に含まれるクレームを使用して、要求されたリソースへのクライアント アクセスを与えるかどうかを決定します。SharePoint 2010 Productsでは、SAML プロバイダーの使用が構成された各 Web アプリケーションは IP-STS サーバーに個別の RP-STS エントリとして追加されます。SharePoint ファームには複数の RP-STS エントリを含めることができます。

SharePoint 2010 Productsで SAML トークンベース認証を実装する操作には、次のプロセスが含まれます。これらのプロセスは、綿密な計画を立てて行ってください。

  1. トークン署名証明書を IP-STS からエクスポートします。この証明書は ImportTrustCertificate と呼ばれます。この証明書を SharePoint Foundation 2010 ファーム内のサーバー コンピューターにコピーします。

  2. ユーザーの一意の ID として使用するクレームを定義します。これは ID クレームと呼ばれます。このプロセスの多くの例では、ユーザーの電子メール名をユーザー ID として使用します。トークン内のどの値が各ユーザーにとって常に一意の値であるかは IP-STS の所有者にしかわからないため、IP-STS の管理者と協議して適切な ID を決定します。ユーザーの一意の ID を識別することは、クレームマッピング プロセスの一部です。クレーム マッピングは Windows PowerShell を使用して作成されます。

  3. 追加のクレーム マッピングを定義します。SharePoint Foundation 2010 ファームで使用する、トークンからの追加クレームを定義します。たとえば、クレームの例として、ユーザー ロールがあります。このユーザー ロールは、SharePoint Foundation 2010 ファーム内のリソースの使用を許可するために使用できます。トークンからのクレームのうち、マッピングを持たないものはすべて破棄されます。

  4. Windows PowerShell を使用してトークン署名証明書をインポートすることで、新しい認証プロバイダーを作成します。このインポート プロセスによって SPTrustedIdentityTokenIssuer が作成されます。このプロセスでは、マップ済みの ID クレームと追加クレームを指定します。また、SAML トークンベース認証用に構成する最初の SharePoint Web アプリケーションと関連付ける領域を作成して指定する必要もあります。SPTrustedIdentityTokenIssuer が作成された後は、追加の SharePoint Web アプリケーション用の領域をさらに作成して追加できます。こうすることで、複数の Web アプリケーションで同じ SPTrustedIdentityTokenIssuer を使用するように構成できます。

  5. SPTrustedIdentityTokenIssuer に追加する領域ごとに、IP-STS に RP-STS エントリを作成する必要があります。これは、SharePoint Web アプリケーションを作成する前に行うことができます。ただし、URL の計画は Web アプリケーションを作成する前に立てておく必要があります。

  6. 新しい SharePoint Web アプリケーションを作成し、新しく作成した認証プロバイダーを使用するようにその Web アプリケーションを構成します。この認証プロバイダーは、Web アプリケーションにクレーム モードを選択しているときは、サーバーの全体管理にオプションとして表示されます。

複数の SAML トークンベース認証プロバイダーを構成できます。ただし、トークン署名証明書をファーム内で使用できるのは 1 回だけです。構成されているプロバイダーはすべて、サーバーの全体管理にオプションとして表示されます。他の信頼できる STS 環境からのクレームが競合することはありません。

パートナー企業に SAML トークンベース認証を実装して、自分の環境に IP-STS を含める場合は、内部のクレーム環境の管理者と共に、内部 IP-STS からパートナー STS への信頼関係を構築することをお勧めします。このアプローチでは、追加の認証プロバイダーを SharePoint Foundation 2010 ファームに追加する必要はありません。また、このアプローチでは、クレーム管理者はクレーム環境全体を管理できます。

注意

複数の Web サーバーを負荷分散構成で展開している SharePoint Foundation 2010 ファームで、SAML トークンベース認証と AD FS を使用すると、クライアント Web ページ ビューのパフォーマンスと機能に影響することがあります。AD FS がクライアントに提供する認証トークンは、権限が制約されたページ要素ごとに SharePoint Foundation 2010 に発行されます。負荷分散ソリューションでアフィニティを使用していない場合、セキュリティ保護されている各要素は、複数の SharePoint Foundation 2010 サーバーに対して認証され、その結果、トークンは拒否されることがあります。トークンが拒否されると、SharePoint Foundation 2010 は、再認証するクライアントを AD FS サーバーにリダイレクトします。これが発生した後は、AD FS サーバーは短時間のうちに行われた複数の要求を拒否することがあります。この動作は仕様で、サービス拒否攻撃に対する防衛策です。パフォーマンスが低下したり、ページが完全に読み込まれない場合は、ネットワーク負荷分散を単方向アフィニティに設定することを検討します。このように設定することで、単一の Web サーバーに対する SAML トークンの要求を切り離します。

SAML トークンベース認証の構成方法の詳細については、次の資料を参照してください。

LDAP 環境用の認証の選択

LDAP 環境は、フォームベース認証または SAML トークンベース認証のどちらかを使用して実装できます。それほど複雑ではないので、フォームベース認証を使用することをお勧めします。ただし、環境で WS-Federation 1.1 と SAML Token 1.1 をサポートしている場合は、SAML をお勧めします。ADFS 2.0 に関連付けられていない LDAP プロバイダーとのプロファイル同期はサポートされていません。

Web アプリケーション用ゾーンの計画

ゾーンは、Web アプリケーション内の、同じサイトにアクセスするためのさまざまな論理パスを表します。Web アプリケーションごとに 5 つのゾーンを含むことができます。Web アプリケーションを作成すると、既定のゾーンが作成されます。それ以外のゾーンは、Web アプリケーションを拡張していずれかのゾーン名 (イントラネット、エクストラネット、インターネット、またはカスタム) を選択することで作成します。

以前のバージョンでは、他のネットワークや他の認証プロバイダーから接続するユーザーを対象とした、さまざまな認証を実装するためにゾーンは使用されました。現在のバージョンでは、クレーム認証によって同じゾーンに複数の種類の認証を実装できます。

ゾーンの計画は、Web アプリケーション用に次のどちらのモードを選択するかによって異なります。

  • クラシック モード — 以前のバージョンと同様、1 つのゾーンに 1 種類の認証しか実装できません。一方、現在のバージョンでは、クラシック モードを選択したときは、Windows 認証しか実装できません。したがって、複数のゾーンを使用しても、複数の種類の Windows 認証を実装するか、さまざまな Active Directory ストアに対して同じ種類の Windows 認証を実装する以外のことはできません。

  • クレーム認証 — 1 つのゾーンに複数の認証プロバイダーを実装できます。また、複数のゾーンを使用することもできます。

1 つのゾーンへの各種認証の実装

クレーム認証を使用して、複数の認証の種類を実装する場合は、それらの認証を既定のゾーンに実装することをお勧めします。こうすると、すべてのユーザーが同じ URL を使用できます。

同じゾーンに複数の認証の種類を実装する場合は、次の制限が適用されます。

  • ゾーンに実装できるフォームベース認証のインスタンスは 1 つだけです。

  • サーバーの全体管理を使用すると、統合 Windows 認証方法と基本認証方法の両方を同時に使用できます。それ以外の場合は、1 つのゾーンに複数の種類の Windows 認証を実装することはできません。

ファームに複数の SAML トークンベース認証プロバイダーを構成している場合、それらの認証プロバイダーは、Web アプリケーションや新しいゾーンを作成するときに、オプションとして表示されます。同じゾーンに複数の SAML プロバイダーを構成できます。

次の図は、パートナーのコラボレーション サイトの既定のゾーンに実装された、複数の種類の認証を示しています。

ゾーンでの複数の種類の認証

この図では、さまざまなディレクトリ ストアからのユーザーが、同じ URL を使用してパートナー Web サイトにアクセスしています。パートナー企業を囲む点線は、ユーザー ディレクトリと、既定のゾーンに構成される認証の種類との間の信頼関係を示しています。この設計例の詳細については、「設計サンプル: 企業展開 (SharePoint Server 2010)」を参照してください。

クロールするコンテンツの計画

クロール コンポーネントは、NTLM を使用してコンテンツにアクセスする必要があります。少なくとも 1 つのゾーンには NTLM 認証の使用が構成されている必要があります。既定のゾーンに NTLM 認証が構成されていない場合、クロール コンポーネントは、NTLM 認証の使用が構成された別のゾーンを使用できます。

複数のゾーンの実装

Web アプリケーションに対して複数のゾーンを実装する場合は、次のガイドラインに従ってください。

  • 既定のゾーンを使用して、最もセキュリティの高い認証設定を実装します。要求を特定のゾーンと関連付けることができない場合、既定のゾーンの認証設定とセキュリティ ポリシーが適用されます。既定のゾーンとは、Web アプリケーションの最初の作成時に作成されるゾーンです。通常、最もセキュリティの高い認証設定はエンドユーザーのアクセスを対象とする設定なので、エンド ユーザーは既定のゾーンにアクセスする可能性が高くなります。

  • ユーザーへのアクセスを提供するために最低限必要なゾーンのみを使用してください。各ゾーンは、Web アプリケーションにアクセスするための新規 IIS サイトとドメインに関連付けられます。必要となったときにのみ、新しいアクセス ポイントを追加してください。

  • 少なくとも 1 つのゾーンは、クロール コンポーネントに NTLM 認証を使用する構成になっている必要があります。必要でない限り、インデックス コンポーネント専用のゾーンは作成しないでください。

次の図は、パートナーのコラボレーション サイトのさまざまな認証に対応するために実装された、複数のゾーンを示しています。

各種類の認証に対して 1 つのゾーン

この図では、既定のゾーンは、社外の従業員用に使用されています。各ゾーンには、それぞれ異なる URL が関連付けられています。従業員は、社内または社外のどちらで作業しているかに応じて、ゾーンを使い分けています。この設計例の詳細については、「設計サンプル: 企業展開 (SharePoint Server 2010)」を参照してください。

SAML トークンベース プロバイダー用アーキテクチャ

SAML トークンベース プロバイダーの実装用アーキテクチャには、次のコンポーネントが含まれています。

SharePoint Security Token Service   このサービスは、ファームで使用する SAML トークンを作成します。このサービスは、サーバー ファーム内のすべてのサーバー上で自動的に作成されて開始されます。ファーム間通信ではすべてクレーム認証が使用されるため、このサービスはファーム間通信で使用されます。また、このサービスは、Windows 認証、フォームベース認証、SAML トークンベース認証など、クレーム認証を使用する Web アプリケーション用に実装される認証方法でも使用されます。Security Token Service は展開プロセス時に構成する必要があります。詳細については、「Security Token Service を構成する (SharePoint Server 2010)」を参照してください。

トークン署名証明書 (ImportTrustCertificate)   これは IP-STS からエクスポートされる証明書です。この証明書は、ファーム内の 1 台のサーバーにコピーされます。この証明書を使用して SPTrustedIdentityTokenIssuer を作成できるのは一度だけです。再度使用して SPTrustedIdentityTokenIssuer をさらに作成することはできません。この証明書を使用して別の SPTrustedIdentityTokenIssuer を作成する場合は、最初に、既存の SPTrustedIdentityTokenIssuer を削除する必要があります。ただし、既存の SPTrustedIdentityTokenIssuer を削除する前に、その SPTrustedIdentityTokenIssuer を使用している可能性がある Web アプリケーションとの関連付けを解除する必要があります。

ID クレーム   ID クレームは、ユーザーの一意の ID である SAML トークンからのクレームです。トークン内のどの値が各ユーザーにとって常に一意の値であるかは IP-STS の所有者にしかわかりません。ID クレームは、希望のすべてのクレームをマッピングするプロセス時に通常のクレームとして作成されます。ID クレームとして機能するクレームは SPTrustedIdentityTokenIssuer の作成時に宣言されます。

その他のクレーム   これらのクレームは、ユーザーを記述する SAML チケットからの追加クレームで構成されます。追加クレームには、ユーザー ロール、ユーザー グループ、またはその他の種類のクレーム (年齢など) があります。クレーム マッピングはすべて、SharePoint Foundation ファーム内のサーバー間でレプリケートされるオブジェクトとして作成されます。

領域   SharePoint クレーム アーキテクチャでは、SAML トークンベース プロバイダーを使用する構成の SharePoint Web アプリケーションに関連付けられた URI または URL は領域を表します。SAML ベース認証プロバイダーをファームに作成するときは、IP-STS に認識させる領域または Web アプリケーションの URL を一度に 1 つずつ指定します。1 つ目の領域は、SPTrustedIdentityTokenIssuer の作成時に指定します。2 つ目以降の領域は、SPTrustedIdentityTokenIssuer の作成後に追加できます。領域の指定には $realm = "urn:sharepoint:mysites" のような構文を使用します。領域を SPTrustedIdentityTokenIssuer に追加したら、その領域と RP-STS との信頼関係を IP-STS サーバーに作成する必要があります。そのためには、Web アプリケーションの URL を指定する必要があります。

SPTrustedIdentityTokenIssuer   これは SharePoint ファームに作成されるオブジェクトで、IP-STS との通信や、IP-STS からのトークンの受信に必要な値が含まれています。SPTrustedIdentityTokenIssuer を作成するときは、使用するトークン署名証明書、最初の領域、ID クレームを表すクレーム、およびその他の追加クレームを指定します。STS からのトークン署名証明書は 1 つの SPTrustedIdentityTokenIssuer にのみ関連付けることができます。ただし、SPTrustedIdentityTokenIssuer を作成した後は、追加の Web アプリケーション用にさらに多くの領域を追加できます。領域を SPTrustedIdentityTokenIssuer に追加した後は、その領域を IP-STS に証明書利用者として追加する必要もあります。SPTrustedIdentityTokenIssuer オブジェクトは、SharePoint Foundation ファーム内のサーバー間でレプリケートされます。

証明書利用者 STS (RP-STS)   SharePoint Foundation 2010 では、SAML プロバイダーを使用する構成の Web アプリケーションは、IP-STS サーバーに RP-STS エントリとして追加されます。SharePoint Foundation ファームには複数の RP-STS エントリを含めることができます。

ID プロバイダー STS (IP-STS)   これは、関連するユーザー ディレクトリ内のユーザーに代わって SAML トークンを発行する、クレーム環境内の Security Token Service です。

次の図は、SharePoint 2010 Products クレーム アーキテクチャを示しています。

SharePoint クレーム認証コンポーネント

SPTrustedIdentityTokenIssuer オブジェクトは、いくつかのパラメーターを使用して作成されます。次の図に、主要なパラメーターを示します。

SPTrustedIdentityTokenIssuer 設計

この図に示すように、SPTrustedIdentityTokenIssuer には 1 つの ID クレーム、1 つの SignInURL パラメーター、1 つの Wreply パラメーターのみを含めることができます。ただし、領域とクレーム マッピングについては複数含めることができます。SignInURL パラメーターは、IP-STS に対する認証を行うためにユーザー要求をリダイレクトする URL を指定します。IP-STS サーバーによっては Wreply パラメーターが必要です。このパラメーターの既定値は False で、True または False のどちらかに設定されます。Wreply パラメーターは、IP-STS で必要な場合にのみ使用します。