SharePoint 2013 でユーザー認証方法を計画する

 

適用先:SharePoint Foundation 2013, SharePoint Server 2013

トピックの最終更新日:2016-12-16

概要:さまざまなユーザー認証方法を使用して Web アプリケーション ユーザーのセキュリティを確保する方法を計画します。

この記事では、SharePoint 2013でサポートされるユーザー認証の種類および方式について説明し、Web アプリケーションおよびゾーンでどれを使用するか決定する方法について説明します。

この記事の内容

ユーザー認証は、認証プロバイダーに対して、ユーザーの ID を検証することです。認証プロバイダーは、ユーザーの資格情報を含むディレクトリまたはデータベースで、ユーザーが適切な資格情報を提出したか確認できます。認証プロバイダーの一例は、Active Directory ドメイン サービス (AD DS) です。認証プロバイダーは、ユーザー ディレクトリや属性ストアとも呼ばれます。

認証方式とは、ユーザーの ID を証明するアカウント資格情報およびその他の情報のやり取りのことを指します。認証方式の結果は、一般的には、認証プロバイダーがユーザーを認証したというクレームを含むトークンの形式の証明になります。

認証の種類とは、時には業界標準プロトコルを使用して、1 つまたは複数の認証プロバイダーに対して資格情報を確認する特定の方法です。認証の種類では、複数の認証方式を使用できます。

ユーザー ID の検証後、ユーザーがアクセスできるサイト、コンテンツ、および機能が承認プロセスによって決定されます。

ユーザー認証の種類と方式の計画では、以下を決定する必要があります。

  • 各 Web アプリケーションおよびゾーン用のユーザー認証の種類および方式

  • 決定された認証の種類と方式をサポートする目的で必要な認証インフラストラクチャ

  • クレームベース認証を使用する目的で、クラシック モード認証を使用する現在の Web アプリケーションおよびゾーンを移行する方法

AD DS 内のユーザー ID は、ユーザー アカウントに基づきます。適切な認証では、ユーザーはアカウント名とパスワードを提出します。リソースへのアクセスを決定する目的で、アプリケーションは、ネットワーク上でのグループ メンバーシップまたは役割のような、アカウント属性とその他の情報について AD DS に対してクエリを実行することがあります。これは Windows 環境では適切に機能しますが、インターネット、パートナー、またはクラウド ベースのコンピューティング モデルをサポートする、サード パーティー認証プロバイダーとマルチベンダー環境ではスケール アウトしません。

クレームベース ID では、ユーザーは、一般的に、信頼できる ID プロバイダーからデジタル署名セキュリティ トークンを取得します。トークンには一連のクレームが含まれます。各クレームは、ユーザーの名前、グループ メンバーシップ、およびネットワーク上の役割のような、ユーザーについてのデータの特定のアイテムを表します。クレームベース認証は、クレームベースの ID テクノロジとインフラストラクチャを使用するユーザー認証です。クレームベース認証をサポートするアプリケーションは、資格情報の代わりに、ユーザーからセキュリティ トークンを取得し、クレーム内のその情報を使用してリソースへのアクセスを決定します。AD DS のようなディレクトリ サービスへの個別のクエリは不要です。

Windows でのクレームベース認証は、クレームベースの ID を実装する目的で使用される一連の .NET Framework クラスである Windows Identity Foundation (WIF) に基づいています。クレームベース認証では、WS-Federation、WS-Trust などの標準や、SAML (Security Assertion Markup Language) などのプロトコルが利用されます。

クレームベース認証の詳細については、以下を参照してください。

ユーザー認証、サーバー間認証、およびアプリケーション認証としてクレームベース認証が広く使用されていることから、SharePoint 2013ファームのすべての Web アプリケーションおよびゾーンでクレームベース認証を推奨します。詳細については、「SharePoint 2013 でサーバー間認証を計画する」と「SharePoint Server でアプリ認証を計画する」を参照してください。クレームベース認証を使用するとき、Web アプリケーションでは、すべてのサポートされる認証方式が使用できます。そして、サーバー間認証とアプリケーション認証を使用する、SharePoint 2013の新機能とシナリオを活用できます。

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

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

SharePoint 2013では、サーバーの全体管理で Web アプリケーションを作成するとき、クレームベース認証の、認証の種類および方式のみを指定できます。SharePoint の以前のバージョンでは、サーバーの全体管理で、Web アプリケーションのクラシック モード認証も構成できました。クラシック モード認証は Windows 認証を使用し、SharePoint 2013は AD DS アカウントとしてユーザー アカウントを処理します。

クラシック モード認証を使用するように Web アプリケーションを構成するには、New-SPWebApplicationWindows PowerShell コマンドレットを使用して作成する必要があります。クラシック モード認証用に構成された SharePoint 2010 製品 Web アプリケーションは、SharePoint 2013にアップグレードしたとき、その認証設定を保持します。しかし、SharePoint 2013にアップグレードする前に、Web アプリケーションをクレームベース認証に移行することを推奨します。

SharePoint 2013ファームでは、両方のモードを使用する Web アプリケーションを混合して含めることができます。従来の Windows アカウントであるユーザー アカウントと Windows クレーム アカウントは、一部のサービスでは区別されません。

アップグレードする前に移行することの詳細については、「SharePoint 2013 でクラシックモードからクレームベース認証に移行する」を参照してください。

アップグレード後の移行の詳細については、「SharePoint 2013 でクラシックモードからクレームベース認証に移行する」を参照してください。

SharePoint 2013でクラシック モード認証を使用する Web アプリケーションを作成する方法については、「クラシック モード認証を使用する Web アプリケーションを作成する (SharePoint 2013)」を参照してください。クレームベース認証を使用する Web アプリケーションを、クラシック モード認証を使用するようにする移行はできないことに注意してください。

重要重要:
Office Online は、クレームベース認証を使用する SharePoint 2013 Web アプリケーションでのみ使用できます。クラシック モード認証を使用する SharePoint 2013 Web アプリケーションでは、Office Online の表示と編集は正常に機能しません。クラシック モード認証を使用する SharePoint 2010 Web アプリケーションを SharePoint 2013 に移行する場合は、それらの Web アプリケーションが Office Online で機能するように認証方法をクレームベース認証に移行する必要があります。

SharePoint 2013は、さまざまな認証方式と、以下の認証の種類の認証プロバイダーをサポートします。

  • Windows 認証

  • フォームベース認証

  • SAML トークンベース認証

Windows 認証の種類は、既存の Windows 認証プロバイダー (AD DS) と認証プロトコルを活用します。これらは、Windows ドメイン環境が、接続するクライアントの資格情報を検証する目的で使用します。クレームベース認証とクラシック モードの両方で使用される Windows 認証方式には、以下が含まれます。

  • NTLM

  • Kerberos

  • ダイジェスト

  • 基本

詳細については、この記事の「Windows 認証の計画」を参照してください。

SharePoint 2013 での Windows クレーム認証のビデオを参照してください

ビデオ (再生ボタン) アイコン

Windows 認証の種類ではありませんが、SharePoint 2013は、匿名認証もサポートします。ユーザーは、自分の資格情報を確認されることなく SharePoint コンテンツにアクセスできます。匿名認証は既定で無効です。一般的には、公開されたインターネット Web サイトのような、セキュリティを必要とせず、すべてのユーザーが使用可能なコンテンツを発行する際に SharePoint 2013を使用するときに匿名認証を使用します。

匿名認証を有効にすることに加えて、サイトおよびサイトリソースへの匿名アクセス (権限) を構成する必要があることに注意してください。

メモメモ:
匿名認証とフォーム認証の SharePoint の設定が無効であっても、Web アプリケーションを提供するために SharePoint によって作成された インターネット インフォメーション サービス (IIS) Web サイトでは、匿名認証とフォーム認証のメソッドが常に有効になります。   これは意図的なものであり、IIS 設定で匿名認証またはフォーム認証を直接無効にすると SharePoint サイトでエラーが発生します。

フォームベース認証は、ASP.NET のメンバーシップ プロバイダーとロール プロバイダーの認証に基づく、クレームベース ID 管理システムです。フォーム ベース認証は、以下のような、認証プロバイダーに保存される資格情報に対して使用できます。

  • AD DS

  • SQL Server データベースのようなデータベース

  • Novell eDirectory、NDS (Novell Directory Services)、または Sun ONE のような LDAP (ライトウェイト ディレクトリ アクセス プロトコル) データ ストア

フォーム ベース認証では、ユーザーがログオン フォーム (一般的には Web ページ) で入力する資格情報に基づいてユーザーを検証します。認証されていない要求はログオン ページにリダイレクトされ、ユーザーは有効な資格情報を提供して、フォームを提出する必要があります。後続の要求の ID を再確立するキーを含む Cookie が発行されます。

SharePoint 2013 でのフォーム ベース クレーム認証のビデオを参照してください

ビデオ (再生ボタン) アイコン
メモメモ:
フォーム ベース認証では、ユーザー アカウント資格情報はプレーンテキストとして送信されます。したがって、Web サイト トラフィックを暗号化する SSL (Secure Sockets Layer) を使用していない場合は、フォーム ベース認証を使用しないでください。

詳細については、「フォーム ベース認証の計画」を参照してください。

SharePoint 2013での SAML トークンベース認証は、SAML 1.1 プロトコルと WS-Federation パッシブ リクエスター プロファイル (WS-F PRP) を使用します。SAML トークンベース認証では、独自の内部環境とパートナーの環境のどちらの場合でも、クレームベース環境の管理者との連携が必要です。Active Directory フェデレーション サービス (ADFS) 2.0 を使用する場合、SAML トークンベース認証環境を既に持っています。

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

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

SharePoint 2013 での SAML ベース クレーム認証のビデオを参照してください

ビデオ (再生ボタン) アイコン

SAML トークンベース認証の認証プロバイダーのセットは、クレーム環境の IP-STS に基づきます。AD FS 2.0 を使用する場合、認証プロバイダー (AD FS 2.0 では属性ストアと呼ばれます) には、以下が含まれます。

  • Windows Server 2003 Active Directory と Windows Server 2008 での AD DS

  • SQL Server 2005 および SQL Server 2008 のすべてのエディション

  • カスタム属性ストア

詳細については、「SAML トークンベース認証の計画」を参照してください。

SAML トークンベース認証、またはフォーム ベース認証は LDAP 環境を使用することができます。現在の LDAP 環境に合う認証の種類を使用する必要があります。まだ LDAP 環境を持っていない場合、より単純なフォームベース認証を使用することをお勧めします。しかし、認証環境が既に WS-Federation 1.1 と SAML 1.1 をサポートしている場合は、SAML を推奨します。SharePoint Server 2013 には、LDAP プロバイダーが含まれます。SharePoint Foundation 2013 では、サード パーティー LDAP プロバイダーを展開する必要があることがあります。

Windows 認証方法の計画と実装の過程は、クレームベースおよびクラシック認証で似ています。Web アプリケーションに対してクレームベース認証を選択しても、Windows 認証方法の実装がより複雑になることはありません。ここでは、Windows 認証方式の計画の概要を示します。

NTLM および Kerberos プロトコルは、両方とも統合 Windows 認証方法であり、ユーザーは資格情報の入力を求められずにシームレスに認証されます。次に例を示します。

  • Internet Explorer から SharePoint サイトにアクセスするユーザーは、Internet Explorer プロセスが認証用に実行されている資格情報を使用します。既定では、これらの資格情報は、ユーザーがコンピューターにログオンするときに使用した資格情報です。

  • 統合 Windows 認証方式を使用し SharePoint リソースにアクセスするサービスまたはアプリケーションは、既定でプロセスの ID である実行中のスレッドの資格情報を使用して、認証を試みます。

NTLM は、最も簡単に実装できる Windows 認証の形式であり、一般的には認証インフラストラクチャの追加の構成は不要です。Web アプリケーションを作成または構成するときは、このオプションを選択します。

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

Kerberos 認証を検討すべき理由は、以下のとおりです。

  • Kerberos プロトコルは最も強力な統合 Windows 認証プロトコルであり、クライアントおよびサーバーの高度暗号化標準 (AES) 暗号、相互認証などの高度なセキュリティ機能をサポートしています。

  • Kerberos プロトコルを使用すると、クライアントの資格情報の委任を行うことができます。

  • 安全な認証方法の中でも Kerberos は AD DS ドメイン コントローラーへのトラフィックが最も少なくて済む方法です。Kerberos では、特定のシナリオでページの遅延を減らすことができ、状況によってはフロントエンド Web サーバーの処理ペース数を増やすことができます。Kerberos はドメイン コントローラーへの負荷を減らすこともできます。

  • Kerberos プロトコルは、多くのプラットフォームおよびベンダーがサポートするオープンなプロトコルです。

Kerberos 認証が適切ではないかもしれない状況は、以下のとおりです。

  • Kerberos 認証を有効に機能させるには、その他の認証方式と比較して、インフラおよび環境で追加の構成が必要です。多くの場合、Kerberos プロトコルを構成するにはドメイン管理者の権限が必要とされます。Kerberos 認証は、セットアップや管理が複雑な面があります。Kerberos を誤って構成すると、サイトへの認証がうまく行われません。

  • Kerberos 認証では、KDC および AD DS ドメイン コントローラーにクライアント コンピューターが接続できる必要があります。Windows 展開では、AD DS ドメイン コントローラーが KDC となります。これは組織のイントラネットでは一般的なネットワーク構成ですが、インターネットと対面する展開は、通常、この構成ではありません。

以下の手順では、Kerberos 認証を構成する方法を要約して説明します。

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

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

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

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

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

Kerberos プロトコルを計画する方法の詳細については、「SharePoint 2013 で Kerberos 認証を計画する」を参照してください。

ダイジェスト認証方式では、ユーザー アカウント資格情報は、Web アプリケーションまたはゾーンをホストする Web サーバー上のインターネット インフォメーション サービス (IIS) サービスに、MD5 メッセージ ダイジェストとして送信されます。基本認証方式では、ユーザー アカウント資格情報はプレーンテキストとして送信されます。したがって、Web サイト トラフィックを暗号化する SSL (Secure Sockets Layer) を使用していない場合は、基本認証方式を使用しないでください。

現在の環境が、Web サイトに対してダイジェストまたはベーシックな認証のみをサポートする Web ブラウザーまたはサービスを使用している場合、これらの旧式の認証方式を使用する必要があることがあります。

NTLM、Kerberos、および匿名認証方式と異なり、ダイジェストおよび基本認証方式は、インターネット インフォメーション サービス (IIS) スナップインで Web アプリケーションまたはゾーンに対応する、Web サイトのプロパティから構成します。

クレームベース認証を使用している場合は、以下を参照してください。

クラシック モード認証を使用している場合は、以下を参照してください。

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

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

フォーム ベース認証を構成する詳細な手順については、「SharePoint 2013 でクレームベースの Web アプリケーション用にフォームベース認証を構成する」を参照してください。

SAML トークンベース プロバイダーの実装のアーキテクチャは、以下のコンポーネントから成ります。

  • SharePoint Security Token Service   このサービスは、ファームが使用する SAML トークンを作成します。サービスは自動的に作成され、サーバー ファーム内のすべてのサーバー上で開始されます。すべてのファーム間通信でクレームベース認証を使用することから、このサービスはファーム間通信で使用されます。また、クレーム認証を使用する Web アプリケーションに対して実装される認証方法でもこのサービスが使用されます。このような認証方式には、Windows 認証、フォームベース認証、SAML トークンベース認証が含まれます。

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

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

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

  • 領域   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 を指定します。

    SharePoint Web アプリケーションで既存の信頼できるプロバイダーを使用できるようにするには、それらのアプリケーションの領域マッピングを追加する必要があります。 2 番目の Web アプリケーションのための追加の領域マッピングを既存の信頼できる構成に追加するには、次の Windows PowerShell 構文を使用します。

    $tp =  Get-SPTrustedIdentityTokenIssuer -Name "Trusted"
    
        $newUri = New-Object System.Uri("http://secondSite.mysharepoint.com")
    
        $newRealm = "urn:sharepoint:site2"
    
    $tp.ProviderRealms.Add($newUri, $newRealm)
    
        $tp.Update()
    
    メモメモ:
    上記で使用される URL は、web アプリケーションと関連付けられている URL である必要があります (「Get-SPWebApplication」を参照してください)。これが、SharePoint が既定の URN のかわりにこの URN を送信するタイミングを決定する方法です。 ADFS サーバーに証明書利用者を設定する場合は、URN を使用する必要があり、またエンドポイントは、上記の URL に "/_trust/" が追加された URL が推奨されます。
  • SPTrustedIdentityTokenIssuer   IP-STS との間で通信したり、トークンを受け取ったりするのに必要な値を含む、SharePoint ファーム上に作成されるオブジェクトです。SPTrustedIdentityTokenIssuer の作成時に、使用するトークン署名証明書、最初の領域、ID クレームに相当するクレーム、および追加のクレームを指定します。STS からのトークン署名証明書は、1 つの SPTrustedIdentityTokenIssuer にのみ関連付けることができます。ただし、SPTrustedIdentityTokenIssuer の作成後に、別の Web アプリケーション用の領域をさらに追加できます。SPTrustedIdentityTokenIssuer に領域を追加した後は、それを証明書利用者として IP-STS にも追加する必要があります。SPTrustedIdentityTokenIssuer オブジェクトは、SharePoint 2013ファーム内のサーバー間でレプリケートされます。

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

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

以下の図は、SharePoint 2013 SAML トークン クレーム アーキテクチャを示します。

SAML トークン クレーム アーキテクチャ

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

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

  • 単一 ID クレーム。

  • 単一 SignInURL パラメーター。

    SignInURL パラメーターは、IP-STS に認証するためにユーザー要求をリダイレクトする先の URL を指定します。

  • 単一 Wreply パラメーター。

    一部の IP-STS サーバーでは、Wreply パラメーターが必要です。このパラメーターは、true または false に設定されます。false が既定値です。Wreply パラメーターは、IP-STS によって要求されている場合にの使用します。

  • 複数の領域。

  • 複数のクレーム マッピング。

SharePoint 2013に SAML トークンベース認証を実装するには、次の手順を使用します。これらの手順では事前に計画が必要となります。

  1. IP-STS からトークン署名証明書をエクスポートします。SharePoint 2013ファーム内のサーバーに証明書をコピーします。

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

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

  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 アプリケーションを作成したとき、認証プロバイダーはサーバーの全体管理で信頼できる ID プロバイダーとして表示されます。

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

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

重要重要:
SharePoint 2013でクレームベース認証を使用するときは、ネットワーク負荷分散を単一のアフィニティに設定する必要はなくなりました。
メモメモ:
SAML トークン ベース認証を使用するように Web アプリケーションが構成されている場合、ユーザー選択ウィンドウ コントロールに対する検索機能が SPTrustedClaimProvider クラスで提供されません。ユーザー選択ウィンドウ コントロールで入力されたテキストは、有効なユーザー、グループ、またはクレームであるかどうかにかかわらず、解決済みであるかのように自動的に表示されます。SharePoint 2013ソリューションで SAML トークン ベース認証を使用する場合、独自の検索、名前解決を実装するカスタム クレーム プロバイダーの作成を計画してください。
詳細については、「SharePoint 2013 のユーザー選択ウィンドウ用のユーザー設定のクレーム プロバイダーを計画する」を参照してください。

AD FS を使用して SAML トークンベース認証を構成する詳細な手順については、「AD FS を使用して SAML ベースのクレーム認証を構成する (SharePoint 2013)」を参照してください。

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

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

ゾーンの計画は以下に基づきます。

  • クレームベース認証 (推奨) - 単一のゾーンに複数の認証プロバイダーを実装できます。複数のゾーンも使用できます。

  • クラシック モード (非推奨) - ゾーンごとに 1 種類の認証のみを実装できます。しかし、クラシック モードは Windows 認証方式のみをサポートします。これにより、複数のゾーンを使用できるのは、複数の方式の Windows 認証を実装する場合か、同じ種類の Windows 認証を異なる AD DS ストアに対して実装する場合に限られます。

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

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

同じゾーンに複数の認証方式を実装しようとしている場合、以下の制約があります。

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

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

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

次の図は、パートナーとのグループ作業用のサイトの既定のゾーンに実装されている複数の種類の認証を示しています。

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

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

図では、異なるディレクトリ ストアからのユーザーが、同じ URL を使用してパートナーの Web サイトにアクセスしています。パートナー企業を囲む点線のボックスは、ユーザー ディレクトリと、既定のゾーン内で構成されている認証の種類との間の関係を示しています。この設計例の詳細については、「SharePoint 2013 の設計サンプル: 企業ポータルおよびエクストラネット サイト」を参照してください。

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

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

複数のゾーンの実装

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

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

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

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

次の図は、パートナーとのグループ作業用のサイトでさまざまな種類の認証に対応するように実装されている複数のゾーンを示しています。

認証の種類ごとに 1 つのゾーン

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

図の中で、既定のゾーンはリモートの従業員用に使用されています。各ゾーンには、それぞれ異なる URL が関連付けられています。従業員は、社内で作業しているか、リモートで作業しているかに応じて、異なるゾーンを使用します。

表示: