次の方法で共有


高信頼承認を使用する SharePoint アドインを作成する

高信頼アドインは、社内 SharePoint ファームにインストールされるプロバイダー ホスト型の SharePoint アドイン です。 このアドインを Microsoft SharePoint Online にインストールすることも、Office ストア を通して販売することもできません。 高信頼アドインは、コンテキスト トークンの代わりに証明書を使用して信頼を確立します。

注:

このトピックは、SharePoint アドインに使用する高信頼承認システムを理解するのに役立ちます。高信頼アドインの作成および展開に関する実用的な情報については、以下のトピックを参照してください。

SharePoint では、セキュリティ トークン サービス (STS) によってサーバー間の認証用アクセス トークンが提供されます。 STS により、Exchange、Lync、SharePoint アドインなどの他のアプリケーション サービスにアクセスするための一時的なアクセス トークンが利用できるようになります。ファーム管理者は、Windows PowerShell コマンドレットと証明書を使用して、SharePoint と他のアプリケーションまたはアドインとの間の信頼を確立します。 使用される各証明書は、コマンドレットを使用 New-SPTrustedRootAuthority して SharePoint によって信頼されている必要があります。 また、New-SPTrustedSecurityTokenIssuer コマンドレットを使用して、各証明書をトークン発行者として SharePoint に登録する必要もあります。

注:

STS はユーザー認証用のサービスではありません。 したがって、サーバーの全体管理の [認証プロバイダー] セクションや SharePoint のユーザー選択ウィンドウの、ユーザー サインイン ページに STS は表示されません。

2 種類のトークン発行者

高信頼 SharePoint アドインのリモート Web アプリケーションはデジタル証明書にバインドされます。 (この方法の詳細は前述の 2 つのリンク先トピックを参照。) 証明書は、リモート Web アプリケーションによって、このアプリケーションから SharePoint へのすべての要求に含めるアクセス トークンに署名するために使用されます。 Web アプリケーションは、証明書の秘密鍵を使用してトークンに署名し、SharePoint は証明書の公開鍵を使用して検証します。 証明書が発行するトークンを SharePoint が信頼するには、信頼されたトークン発行者として証明書を登録する必要があります。

トークン発行者には、特定の SharePoint アドイン用のトークンのみを発行できる発行者と、信頼ブローカーとも呼ばれ、複数の SharePoint アドイン用のトークンを発行できる発行者の 2 種類があります。

実際には、New-SPTrustedSecurityTokenIssuer コマンドレットに使用するスイッチとパラメーターの値により、どちらの種類のトークン発行者を作成するかを SharePoint ファーム管理者が決定します。 信頼ブローカーであるトークン発行者を作成するには、コマンド ラインに -IsTrustBroker スイッチを追加し、-Name パラメーターにはアドインのクライアント ID 以外の固有値を使用します。 編集した例を次に示します。

New-SPTrustedSecurityTokenIssuer -IsTrustBroker -RegisteredIssuerName "<full_token_issuer_name> " --other parameters omitted--

ブローカーではないトークン発行者を作成する場合、-IsTrustBroker スイッチは使用しません。 もう 1 つ違いがあります。 -RegisteredIssuerName パラメーターの値は必ず、2 つの GUID を "@" 文字で区切った形 (GUID@GUID) になります。 右側の GUID は、常に SharePoint ファーム (またはサイト サブスクリプション) の認証領域の ID です。 左側の GUID は、常にトークン発行者用の特定の ID です。

信頼ブローカーであるトークン発行者の作成時は、この ID はランダム GUID です。 一方、ブローカーではないトークン発行者の作成時には、この特定の発行者 GUID は SharePoint アドインのクライアント ID として使用されるものと同一の GUID でなければなりません。 このパラメーターは、発行者の名前を提供します。 さらに、その証明書がトークンを発行できる唯一の対象 SharePoint アドインを SharePoint に通知します。 次に例の一部を示します。

$fullIssuerIdentifier = "<client_ID_of_SP_app> " + "@" + "<realm_GUID> "
New-SPTrustedSecurityTokenIssuer -RegisteredIssuerName $fullIssuerIdentifier --other parameters omitted--

通常、New-SPTrustedSecurityTokenIssuer コマンドレットは、高信頼アドイン用に SharePoint を構成する他のタスクを実行するスクリプト内で使用します。そのようなスクリプトの詳細および New-SPTrustedSecurityTokenIssuer コマンドレットの完全な例については、「SharePoint の高信頼構成スクリプト」を参照してください。

高信頼 SharePoint アドインに 1 つの証明書を使用するか多数の証明書を使用するかを決定する

SharePoint およびネットワーク管理者には、高信頼 SharePoint アドインで使用される証明書を入手および管理する際に選択できる、次の 2 つの基本的な方法があります。

  • 複数の SharePoint アドインに同一の証明書を使用する。

  • SharePoint アドイン ごとに別々の証明書を使用する。

このセクションでは各方法の長所と短所を説明します。

複数の SharePoint アドインで同じ証明書を使用することの利点は、管理者が信頼および管理する証明書の数が少なくて済むことです。 この方法の欠点は、特定の SharePoint アドインとの信頼を破棄する必要がある場合、トークン発行者またはルート証明機関として証明書を削除するしか方法がないことです。 証明書を削除すると、同じ証明書を使用している他のすべての SharePoint アドインでも信頼が破棄され、それらのアドインすべてが機能しなくなります。

信頼できる SharePoint アドインを再び動作させるために、管理者は新しい証明書を使用してオブジェクトをNew-SPTrustedSecurityTokenIssuer作成し、フラグを-IsTrustBroker含める必要があります。 信頼できるアドインをホストする各サーバーに新しい証明書を登録し、それらのアドインをそれぞれ新しい証明書にバインドする必要があります。

アドインごとに 1 つの証明書を使用することの利点は、特定のアドインとの信頼を破棄するのが簡単なことです。管理者が特定のアドインの証明書との信頼を破棄する場合でも、引き続き信頼できるアドインが使用する証明書は影響を受けません。 この方法の欠点は、管理者が取得しなければならない証明書の数が多く、それらの各々を使用するように SharePoint を構成する必要があることです。この構成は、「SharePoint の信頼度の高い構成スクリプト」に示されている再利用可能なスクリプトを使用して行えます。

証明書は SharePoint のルート証明機関

この記事の最初で簡単に説明したように、SharePoint ファーム管理者は、高信頼アドインのリモート Web アプリケーションの証明書を、信頼されたトークン発行者にするだけでなく、SharePoint 内の信頼されたルート証明機関にもする必要があります。 実際、Web アプリケーションの証明書の背後に証明書発行機関の階層がある場合、そのチェーン内のすべての証明書を SharePoint の信頼されたルート証明機関のリストに追加する必要があります。

チェーン内の各証明書は、コマンドレットを呼び出して SharePoint の信頼されたルート機関の一覧に New-SPTrustedRootAuthority 追加されます。 たとえば、Web アプリケーションの証明書が LAN 上のエンタープライズ ドメイン証明機関によって発行されたドメイン証明書であり、今度はその証明書が LAN 上にあるスタンドアロンの最高レベルの証明機関によって発行されたものであるとします。 この場合、最高レベル CA、中間 CA、および Web アプリケーションのすべての証明書を SharePoint の信頼済みルート証明機関のリストに追加する必要があります。 次の Windows PowerShell コードを実行して、この処理を行うことができます。

$rootCA = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("<path_to_top-level_CA's_cer_file>")
New-SPTrustedRootAuthority -Name "<name_of_certificate>" -Certificate $rootCA

$intermediateCA = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("path_to_intermediate_CA's_cer_file")
New-SPTrustedRootAuthority -Name "<name_of_certificate>" -Certificate $intermediateCA

$certificate = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("path_to_web_application's_cer_file") 
New-SPTrustedRootAuthority -Name "<name_of_certificate>" -Certificate $certificate 

ルート証明書と中間証明書は、SharePoint ファームに一度だけ追加する必要があります。 通常、Web アプリケーションの証明書は、New-SPTrustedSecurityTokenIssuer への呼び出しなど、他の構成も実行する別のスクリプトで追加します。 例については、「SharePoint の信頼度の高い構成スクリプト」を参照してください。

アドインを開発およびデバッグ中の場合など、Web アプリケーションの証明書が自己署名証明書であるときは、証明書チェーンがないので、Web アプリケーションの証明書のみをルート証明機関のリストに追加する必要があります。

詳細については、ブログ投稿「クレーム認証での証明書チェーンのルートが信頼されていないエラー」を参照してください。 Active Directory フェデレーション サービス (AD FS) からの証明書のエクスポートに関するセクションの次までスクロールしてください。証明機関によって発行された商用証明書、自己署名証明書、ドメインで発行された証明書を使用するなど、他の何らかの方法で高信頼アドイン用の証明書を作成した場合を想定しています。

トークン発行者であることを Web アプリケーションが認識する必要がある

SharePoint アドインのリモート Web アプリケーション コンポーネントは、IIS にあるそれ自身の証明書にバインドされます。 証明書の従来の目的、つまり Web アプリケーションの識別および HTTP 要求と応答のエンコードを安全に実行するには、この方法で十分です。

しかし、高信頼 SharePoint アドインの場合、Web アプリケーションから SharePoint に送信されるアクセス トークンの公式の "発行者" というタスクが証明書に加わります。 このため、Web アプリケーションは、トークン発行者として証明書を SharePoint に登録するときに使用される証明書の発行者 ID を認識する必要があります。 Web アプリケーションはこの ID を web.config ファイルの appSettings セクションから取得します。そのセクションには IssuerId という名前のキーがあります。

アドイン開発者がこの値を設定する方法、および IIS で証明書を Web アプリケーションにバインドする方法の手順については、「信頼度の高い SharePoint アドインをパッケージ化して発行する」で説明されています。

顧客が高信頼 SharePoint アドインごとに別個の証明書を使用する方法を採用している場合、ClientId 値が IssuerId 値としても使用されることにご注意ください。 複数のアドインで同じ証明書を共有する場合は、SharePoint アドインごとにそれぞれ固有のクライアント ID を指定する必要があるので上記に該当しません。発行者 ID は SPTrustedSecurityTokenIssuer オブジェクトの識別子になります。

以下は、高信頼 SharePoint アドイン用の appSettings セクションの例です。 この例では、1 つの証明書が複数のアドインによって共有されているため、 IssuerIdClientId と同じではありません。 高信頼 SharePoint アドイン に ClientSecret キーがないことに注意してください。

<appSettings>
  <add key="ClientId" value="6569a7e8-3670-4669-91ae-ec6819ab461" />
  <add key="ClientSigningCertificatePath" value="C:\MyCerts\HighTrustCert.pfx" />
  <add key="ClientSigningCertificatePassword" value="3VeryComplexPa$$word82" />
  <add key="IssuerId" value="e9134021-0180-4b05-9e7e-0a9e5a524965" />
</appSettings>

注:

上の例では、証明書がファイル システムに保存されていることを想定しています。 これは、開発とデバッグで許容されます。 運用環境の高信頼 SharePoint アドインでは、証明書は通常 Windows 証明書ストアに保存され、ClientSigningCertificatePath キーと ClientSigningCertificatePassword キーは、通常、ClientSigningCertificateSerialNumber キーに置き換えられます。

高信頼システムにおける IT スタッフの責任

開発者はこれまでに説明したアプリケーション セキュリティの要件を理解している必要がありますが、IT 担当者はそれをサポートするために必要なインフラストラクチャを実装します。 IT 担当者は以下の運用要件を計画する必要があります。

  • 信頼された SharePoint アドインに使用する 1 つ以上の証明書を作成または購入します。

  • 証明書が Web アプリケーション サーバーに安全に保存されていることを確認します。 Windows オペレーティング システムが使用されている場合、これは、Windows 証明書ストアに証明書が保存されていることを意味します。

  • SharePoint アドインをビルドしている開発者への証明書の配布を管理します。

  • 証明書を使用するアドインと、コピーを受け取った開発者の両方について、各証明書の配布先を追跡管理します。 証明書を取り消す必要がある場合、IT スタッフは各開発者と協力して、新しい証明書への移行を調整する必要があります。

関連項目