Share via

SharePoint 2013 でファーム間の oAuth 信頼関係を設定する

  • Article

原文の記事の投稿日: 2012 年 7 月 23 日 (月曜日)

SharePoint 2013 でおそらくよく聞くトピックの 1 つに oAuth があります。私も最終的に、このトピックについてよく書くことになるかもしれません。SharePoint 2013 では、oAuth は、プリンシパル (ユーザーまたはアプリケーション) の ID を確立する目的で 2 つのアプリケーション間の信頼関係を構築するために使用されます。SharePoint では、SharePoint と Exchange や Lync などの間で、新しいクラウド アプリ モデルを使用している ACS または個々のアプリケーション開発者との oAuth 信頼関係を使用したり、さらには、検索のリモート SharePoint インデックス機能などのために 2 つの異なる SharePoint ファーム間で oAuth 信頼関係を使用したりします。

 

oAuth は、ユーザーの認証プロバイダーにはなりません。そのため、New-SPTrustedIdentityTokenIssuer を使用して ID プロバイダーとの信頼関係を作成します。oAuth 信頼関係に関しては、名前がよく似た New-SPTrustedSecurityTokenIssuer という新しいコマンドレットがあります。セキュリティ トークン発行者とこのような信頼関係を確立する場合、この信頼を S2S (サーバー間) 信頼と呼びます。この略語は SharePoint 2013 でよく見かけるようになるので、覚えておいてください。この投稿では、この信頼の作成に必要な詳細についていくつか説明します。

 

まず、S2S 信頼を必要とする多くの機能でこの信頼が自動的に確立されるということを知っておいてください。機能のアクティブ化によって確立される場合や、機能チームが機能の有効化の一環として信頼を作成する PowerShell スクリプトまたはコマンドレットを提供する場合があります。自分で確立することが必要になる場合もありますが、その手順こそがこの投稿で説明する内容です。

 

最初に解決する必要があることの 1 つに、SSL を使用するかどうかという点があります。実際のところ、SharePoint 2013 ではほとんどの場合、SSL を使用することになるでしょう。その理由は、SharePoint 2013 には oAuth を使用するシナリオが数多くあり、その際にアクセス トークンを含む Cookie を渡すためです。そのアクセス トークンは、データへの扉を開く鍵のようなものです。アクセス トークンは証明書で署名されており、自分のアクセス トークンを作成した他人がスプーフィングできないようになっていますが、理論上は他人がその Cookie を取得してその有効期間中に Cookie を再生することもできるので、クリア テキストでやり取りすることは望ましくありません。SSL はその Cookie 再生攻撃を防ぎます。その方法は、同じ理由によりフォーム ベース認証サイトで SSL を使用する場合と同じです。とはいえ、サイトを HTTP 経由で実行したいと思う理由もやはりあります。テスト環境である、開発環境を構築している、完全に内部ネットワークで実行しておりリスクを感じないなどです。ここでは判断しません。説明だけを行います。

 

手順 1: STS を構成する

SharePoint のセキュリティ トークン サービス (STS) の構成には、SSL を使用しない場合に調整できる設定がいくつかあります。すべての STS 構成設定を取得するには、コマンドレット Get-SPSecurityTokenServiceConfig を使用します。信頼を確立するための方法は 2 つあります。証明書を使用する方法と、すべての SharePoint ファームにある新しい oAuth メタデータ エンドポイントを使用する方法です。メタデータ エンドポイントを使用するのが最も簡単ですが、そのエンドポイントが SSL で保護されていない場合は、SharePoint STS の AllowMetadataOverHttp プロパティを true に設定する必要があります。Web アプリを SSL 経由で実行しない場合は、AllowOAuthOverHttp プロパティも true に設定する必要があります。次に、これらのプロパティの設定方法を示す簡単な PowerShell を紹介します。

 

$c = Get-SPSecurityTokenServiceConfig

$c.AllowMetadataOverHttp = $true

$c.AllowOAuthOverHttp= $true

$c.Update()

 

手順 2: 信頼を作成する

必要に応じて STS を構成したところで、ファーム間の信頼を確立する方法を見てみましょう。前述したように、すべての SharePoint ファームにはメタデータ エンドポイントが導入されており、情報とアクセス トークン署名証明書を提供するために使用されます。そのメタデータ エンドポイントは /_layouts/15/metadata/json/1 にあります。実際にブラウザーでそのエンドポイントに移動しようとすると、保存するように求められ、保存すると確認できます。メモ帳で開いた場合にわかることは、これが単なる JSON ペイロードであるということです。これには、STS の名前 ID ("発行者" と呼ばれます) と、シリアル化されたバージョンのトークン署名証明書 (キー "x509certificate" の "値" として示されます) が含まれています。データをもう少し確認すると、発行者が実際にはサービス名 + "@" + レルムの値であることがわかります。STS の NameIdentifier プロパティとも一致します。この情報は重要です。理由については、後ほど説明します。

 

この例では、FARM_A が FARM_B をリモート SharePoint インデックスとして使用するので、FARM_B が FARM_A からの呼び出しを信頼する必要があるとします。また、FARM_A の Web アプリケーションが https://FARM_A にあるとします。信頼を作成するには、FARM_B のサーバーで次のように New-SPTrustedSecurityTokenIssuer コマンドレットを実行します ("$i =" 要素を使用する理由については、後ほど説明します)。

 

$i = New-SPTrustedSecurityTokenIssuer -Name FARM_A -Description "FARM_A description" -IsTrustBroker:$false -MetadataEndPoint "https://FARM_A/_layouts/15/metadata/json/1"

 

ここで、サービス専用ファームとの信頼関係を設定するとします。そこから信頼を作成できるように、Web アプリケーション、サイト コレクション、および SSL 証明書を作成しません。そこで、New-SPTrustedSecurityTokenIssuer コマンドレットを使用して信頼を確立するために使用できる 2 番目の方法について説明します。2 番目の形式で、トークン署名証明書と名前 ID を指定できます。トークン署名証明書は、SharePoint 2010 の場合と同様に取得します。ファーム内のサーバーに移動して MMC を実行し、ローカル コンピューターの証明書スナップインを追加して、[SharePoint] の [証明書] ノードを確認します。一覧の最初にある証明書が必要な証明書です。ローカル ドライブに .cer ファイルとして秘密キーなしで保存します。信頼を確立するには、その証明書と、前述した STS の NameIdentifier 属性が必要です。その場合のコマンドレットは、次のようになります (FARM_B のサーバー上の C:\sts.cer というファイルに STS 証明書をコピーしていることを前提としています)。

 

$i = New-SPTrustedSecurityTokenIssuer -name FARM_A -Certificate "C:\sts.cer" -RegisteredIssuerName "00000003-0000-0ff1-ce00-000000000000@72da1552-085a-49de-9ecb-73ba7eca8fef " -Description "FARM_A description" -IsTrustBroker:$false

 

手順 3: トークン署名証明書を信頼する

SPTrustedIdentityTokenIssuer の場合と同様に、oAuth トークンに署名するために使用する信頼を、SharePoint の信頼されたルート機関の一覧に追加する必要があります。繰り返しますが、これには 2 つの方法があります。メタデータ エンドポイントを使用して信頼を作成する場合は、次のように信頼を確立できます。

 

New-SPTrustedRootAuthority -Name FARM_A -MetadataEndPoint https://FARM_A/_layouts/15/metadata/json/1/rootcertificate

 

それ以外の場合は、SharePoint 2010 の場合と同様の方法で、信頼されたルート機関の一覧に追加できます。

 

$root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\sts.cer")

New-SPTrustedRootAuthority -Name "Token Signing Root CA Certificate" -Certificate $root

 

信頼の観点からすると、この時点で完了です。信頼が確立され、それに基づいて新しいアプリケーション プリンシパルを作成できるようになりました。その使用方法は、アプリケーション自体に基づきます。リモート SharePoint インデックスの場合は、完全を期すために次へ進み、シナリオを終了します。

 

手順 4: アプリ プリンシパルを作成する (リモート SharePoint インデックスのみの例):

このプロセスには 2 つの手順があります。アプリ プリンシパルの取得とそのプリンシパルへの権限の付与です。このシナリオでは、リモート SharePoint インデックスのクエリを取得するので FARM_B が FARM_A からの呼び出しを信頼する必要があるということを思い出してください。したがって、アプリ プリンシパルのために、FARM_A が使用する FARM_B の Web アプリへの参照を取得する必要があります。取得したら、FARM_A がその参照を使用するための権限を付与できます。

 

アプリ プリンシパルへの参照を取得するには、次のようなコマンドレットを使用します。

 

$p = Get-SPAppPrincipal -Site https://FARM_B -NameIdentifier $i.NameId

 

重要: ここで、注目すべき重要事項が 1 つあります。SharePoint 2013 ベータ版では特によく発生すると思われるのですが、それは、SPAppPrincipal を取得しようとすると PowerShell で見慣れないエラーが発生が発生する可能性があるという現象です。わかっているのは、サーバーで使用できるメモリが 5% を下回るとすべての WCF 呼び出しが失敗するということです。この PowerShell コマンドレットは、WCF としてホストされているサービス アプリケーション エンドポイントを呼び出すので、メモリが不足していると Get-SPAppPrincipal コマンドレットは失敗します。このことが問題の原因であるかどうかを確認するには、Windows イベント ビューアでアプリケーション ログをチェックできます。私の環境でこれまで複数回発生しているので、おそらく他の環境でも発生するでしょう。

 

この投稿で前述したように、最後に $i 変数を使用して、FARM_A の STS の NameIdentifier を取得します。FARM_B の Web アプリのアプリ プリンシパルへの参照を取得しているので、次のようにその参照に権限を付与できます。

 

Set-SPAppPrincipalPermission -Site https://FARM_B -AppPrincipal $p -Scope SiteSubscription -Right FullControl

 

以上です。ここでは、2 つの SharePoint ファーム間の oAuth 信頼関係を作成するための選択肢と方法について説明しました。このブログでは引き続き、oAuth とそのさまざまな用途、徐々に認識されてくる問題点について詳しく説明していきます。

これはローカライズされたブログ投稿です。原文の記事は、「Setting Up an oAuth Trust Between Farms in SharePoint 2013」をご覧ください。