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

  • [アーティクル]

 

適用先: SharePoint Foundation 2010, SharePoint Server 2010

トピックの最終更新日: 2016-11-30

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

この記事の内容:

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

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

  • Windows 認証の実装

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

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

  • LDAP 環境での認証の選択

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

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

サポートされる認証方法

SharePoint Server 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 Server 2010 には、Windows Identity Foundation (WIF) に基づくクレームベース認証が導入されています。クレームベース認証は、サポートされているすべての認証方法で使用できます。また、Windows 認証をサポートするクラシック モード認証も使用できます。

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

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

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

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

次の図は、各認証モードがサポートする認証の種類を示しています。

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

Windows

  • NTLM

  • Kerberos

  • 匿名

  • 基本

  • ダイジェスト

サポートする

サポートする

フォームベース認証

  • LDAP

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

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

サポートしない

サポートする

SAML トークンベース認証

  • AD FS 2.0

  • Windows Live ID

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

  • LDAP

サポートしない

サポートする

SharePoint Server 2010 ファームには、それぞれのモードを使用する Web アプリケーションを混在させることができます。従来の Windows アカウントであるユーザー アカウントと Windows クレーム アカウントは、サービスでは区別されません。このため、混在する認証モードを使用するように構成されたサイトに属するユーザーが受け取る検索結果には、Web アプリケーションに対して構成されているモードにかかわらず、ユーザーがアクセスできるすべてのサイトからの結果が含まれます。ユーザーが 2 つの異なるユーザー アカウントとして認識されることはありません。これは、サービスおよびサービス アプリケーションでは、Web アプリケーションおよびユーザーに対して選択されているモードにかかわらず、ファーム内通信でクレーム ID を使用するためです。

ただし、SharePoint Server Web アプリケーションによって認識される複数のユーザー リポジトリに属するユーザーは、ログインに使用する ID に応じて、個別のユーザー アカウントとして扱われます。

どのモードを選択するかについては、次の説明を参考にしてください。

  • SharePoint Server 2010 を新しく実装する場合は、クレームベース認証を使用します。これにより、Web アプリケーションでは、サポートされているすべての認証の種類を使用できます。環境に含まれているのが Windows アカウントのみの場合であっても、新規展開時にクラシック モード認証を選択する具体的な理由はありません。選択されているモードにかかわらず、Windows 認証が同じように実装されます。クレームベース認証モードを使用する場合、Windows 認証を実装するための追加の手順は必要ありません。

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

  • フォームベース認証が必要なソリューションをアップグレードしている場合、選択できるのはクレームベース認証へのアップグレードのみです。

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

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

  • 多数の Windows ユーザーをクレーム ID に移行するには時間がかかります。アップグレード プロセス時に Web アプリケーションをクラシック モードからクレームベースに変更する場合は、Windows PowerShell を使用して Windows ID をクレーム ID に変換する必要があります。これには時間がかかる可能性があります。アップグレード プロセス時には、十分な時間を取ってこのタスクを完了します。

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

クレーム認証は、WIF に基づいています。WIF は、クレームベースの ID を実装するために使用される一連の .NET Framework クラスです。クレーム認証では、WS-Federation、WS-Trust などの標準や、SAML などのプロトコルが利用されます。クレーム認証の詳細については、以下を参照してください。

SharePoint Server 2010 でクレーム認証を使用するのに、クレーム アーキテクトである必要はありません。ただし、この記事で後述するように、SAML トークンベース認証を実装するには、クレームベース環境の管理者との連携が必要です。

Windows 認証の実装

Windows 認証方法の実装のプロセスは、どちらのモード (クラシックまたはクレームベース) でも同様です。Web アプリケーションに対してクレームベース認証を選択しても、Windows 認証方法の実装の複雑さが増すことはありません。ここでは、各方法のプロセスの概要を示します。

統合 Windows 認証 — Kerberos および NTLM

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

NTLM は、実装が最も簡単な Windows 認証の形式です。Web アプリケーションを作成している場合は、このオプションを選択します。

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

以下の手順は、Kerberos 認証の構成プロセスの概要です。

  1. SQL Server サービス アカウント用の SPN を AD DS で作成することにより、SQL 通信用の Kerberos 認証を構成します。

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

  3. SharePoint Server 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 Server 2010 では、フォームベース認証はクレームベース認証の使用時にのみ使用できます。

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

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

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

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

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

SAML トークンベース認証では、独自の内部環境とパートナーの環境のどちらの場合でも、クレームベース環境の管理者との連携が必要です。AD FS 2.0 はクレームベース環境の例です。

クレームベース環境には、ID プロバイダー セキュリティ トークン サービス (IP-STS) が含まれます。IP-STS は、関連するユーザー ディレクトリ内のユーザーに代わって、SAML トークンを発行します。トークンには、ユーザー名、ユーザーが属するグループなど、ユーザーに関する任意の数のクレームを含めることができます。

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

SharePoint 2010 Productsでの SAML トークンベース認証の実装には、詳細な計画を必要とする以下のプロセスを伴います。

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

  2. ユーザーの一意の ID として使用するクレームを定義します。これは ID クレームと呼ばれます。このプロセスの多くの例では、ユーザーの電子メール名をユーザー ID として使用します。ユーザーごとに常に一意になるトークン内の値を理解しているのは IP-STS の所有者のみなので、IP-STS の管理者と連携して適切な ID を決定します。ユーザーの一意な ID の識別は、クレーム マッピング プロセスに含まれます。クレーム マッピングは、Windows PowerShell を使用して作成します。

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

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

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

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

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

パートナー企業と SAML トークンベース認証を実装していて、独自の環境に IP-STS が含まれている場合、内部クレーム環境の管理者と連携して、内部の IP-STS からパートナーの STS への信頼関係を確立することをお勧めします。この方法の場合、SharePoint Server 2010 ファームに認証プロバイダーを追加する必要はありません。クレーム管理者がクレーム環境全体を管理することもできます。

注意

複数の Web サーバーが負荷分散されて構成されている SharePoint Server 2010 ファーム上で、SAML トークンベース認証と AD FS を使用している場合、クライアントの Web ページ ビューのパフォーマンスと機能が影響を受ける可能性があります。AD FS がクライアントに認証トークンを提供すると、アクセス制限されたページ要素ごとに、そのトークンが SharePoint Server 2010 に送信されます。負荷分散ソリューションがアフィニティを使用していない場合、セキュリティ保護される各要素は複数の SharePoint Server 2010 サーバーに対して認証され、場合によってはトークンが拒否されます。トークンが拒否されると、SharePoint Server 2010 はクライアントをリダイレクトして、AD FS サーバーに対して再認証を行います。この場合、AD FS サーバーは、短期間に作成される複数の要求を拒否する可能性があります。この動作は意図的なものであり、サービス拒否攻撃からの保護を目的とします。パフォーマンスに悪影響があったり、ページが完全に読み込まれない場合は、ネットワークの負荷分散方式を単一のアフィニティに設定することを検討してください。これにより、SAML トークンに対する要求が単一の Web サーバーに隔離されます。

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

LDAP 環境における認証の選択

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

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

ゾーンは、Web アプリケーション内の同じサイトにアクセスするためのさまざまな論理パスを表します。各 Web アプリケーションには、最大で 5 つのゾーンを含めることができます。Web アプリケーションの作成時に、既定のゾーンが作成されます。Web アプリケーションを拡張し、残りのゾーン名の 1 つ (イントラネット、エクストラネット、インターネット、またはカスタム) を選択することによって、追加のゾーンが作成されます。

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

ゾーンに関する計画は、Web アプリケーションに対して以下のどちらのモードを選択するかによって異なってきます。

  • クラシック モード — 以前のバージョンと同様、ゾーンごとに 1 種類の認証のみ実装できます。ただし、現在のバージョンでは、クラシック モードを選択したときに実装できるのは Windows 認証だけです。そのため、複数のゾーンを使用できるのは、複数の種類の Windows 認証を実装する場合か、同じ種類の Windows 認証を異なる Active Directory ストアに対して実装する場合に限られます。

  • クレーム認証 — 単一のゾーンに複数の認証プロバイダーを実装できます。複数のゾーンも使用できます。

単一のゾーンに複数の種類の認証を実装する

クレーム認証を使用していて、複数の種類の認証を実装している場合は、既定のゾーンに複数の種類の認証を実装することをお勧めします。これにより、すべてのユーザーに対して同じ URL が生成されます。

同じゾーンに複数の種類の認証を実装している場合、以下の制約が適用されます。

  • フォームベース認証の 1 つのインスタンスのみ、ゾーンに実装できます。

  • サーバーの全体管理では、統合 Windows 認証と基本認証の両方を同時に使用できます。それ以外の場合、ゾーンに複数の 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 を削除する前に、これを使用している可能性がある Web アプリケーションとの関連付けを解除してください。

ID クレーム   SAML トークンからのクレームで、ユーザーの一意の ID です。ユーザーごとに常に一意になるトークン内の値を理解しているのは IP-STS の所有者だけです。ID クレームは、必要なすべてのクレームをマッピングするプロセスの中で、標準のクレーム マッピングとして作成されます。ID クレームとしての役割を果たすクレームは、SPTrustedIdentityTokenIssuer の作成時に宣言されます。

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

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

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

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

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

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

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

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

SPTrustedIdentityTokenIssuer 設計

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