다음을 통해 공유

在 SharePoint 2013 中设置场之间的 oAuth 信任

  • 아티클

原文发布于 2012 年 7 月 23 日（星期一）

在有关 SharePoint 2013 的话题中，您可能会经常听到大家提起某一种功能。事实上，我也曾多次围绕该功能撰写文章，它就是 oAuth。在 SharePoint 2013 中，oAuth 可出于建立主体（用户或应用程序）身份的需要，在两个应用程序之间建立信任。在 SharePoint 中，您可使用 oAuth 在 SharePoint 与 Exchange、Lync 以及 ACS 或使用新型云应用程序模型的各个应用程序开发人员之间、甚至在搜索内远程 SharePoint 索引功能等场景中的两个不同 SharePoint 场之间建立信任。

 

但是，oAuth 无法成为人们的身份验证提供程序；您仍需使用 New-SPTrustedIdentityTokenIssuerr 创建对身份提供程序的信任。对于 oAuth 信任，我们推出了一种新的 cmdlet：New-SPTrustedSecurityTokenIssuer，其名称与 New-SPTrustedIdentityTokenIssuer 十分相似。当我们与安全令牌颁发者建立此类信任时，我们将其称为“S2S 信任”，意思是指“服务器到服务器”。请记住这一首字母缩写形式，因为您会在 SharePoint 2013 中经常看到它。在本文中，我将深入阐述创建此信任所需的某些特殊事项。

 

首先，值得一提的是，许多要求使用 S2S 信任的功能会自己建立这种信任。它们可以通过功能激活来建立，也可以由功能团队向您提供要运行该功能的 PowerShell 脚本或 cmdlet，将信任作为功能启动的一部分进行创建。当然，有时您还需自己建立信任，本文将围绕这一点展开论述。

 

首先，您必须明确自己是否会使用 SSL。事实上，大部分 SharePoint 2013 使用案例表明，您很可能会使用 SSL。我想其原因在于，您经常会在 SharePoint 2013 中使用 oAuth，或者使用访问令牌传递 cookie。 访问令牌就像打开数据大门的钥匙。访问令牌已经过证书签名，因此无法被那些创建自有访问令牌的用户所冒充。但从理论角度来说，仍有用户可以窃取此 cookie，并在 cookie 的生命周期内重播它，因此您不可以明文形式传播该令牌。SSL 可保护您避免遭受这种重播 cookie 的攻击，其方式与您同样出于这一原因而结合使用 SSL 和基于表单的身份验证网站完全相同。当然，您仍然有各种理由要在 HTTP 上运行网站，比如：您正处于测试环境中，正在构建开发环境，完全在内部网络上运行，而且觉得风险不大。当然，我只是在对您的行为做解释，并不是在做评价。J

 

第 1 步：配置 STS

SharePoint 安全令牌服务 (STS) 的配置中存在许多设置，如果您未使用 SSL，则可能需要对这些设置进行调整。您可以使用以下 cmdlet 获取 STS 的所有配置设置：Get-SPSecurityTokenServiceConfig。建立信任的方式分为两种：其中一种使用证书，另一种是使用所有 SharePoint 场均具有的新 oAuth 元数据端点。使用元数据端点是最简便的方式，但如果该端点不受 SSL 保护，则必须将 SharePoint STS 的AllowMetadataOverHttp 属性设置为 true。如果您不准备在 SSL 上运行 Web 应用程序，则也必须将 AllowOAuthOverHttp property 属性设置为 true。以下这一小段 PowerShell 表明了如何设置这些属性：

 

$c = Get-SPSecurityTokenServiceConfig

$c.AllowMetadataOverHttp = $true

$c.AllowOAuthOverHttp= $true

$c.Update()

 

步骤 2：创建信任

根据需要配置 STS 之后，我们可以查看如何建立两个场之间的信任。如上所述，所有 SharePoint 场现在都有一个元数据端点，可用于提供信息和访问令牌签名证书。该元数据端点位于 /_layouts/15/metadata/json/1。如果真正尝试在浏览器中导航到该端点，则系统将提示您保存它，以备后续检查。当您以记事本方式打开该端点后，您会发现它只是一个 JSON 负载。它包括 STS 的名称标识符（称为“颁发者”），以及令牌签名证书的序列化版本（它将这些版本描述为密钥 x509certificate 的“值”）。如果您进一步查看数据，则会发现颁发者实际上是：服务名称 + @ + 领域值。此外，颁发者还与 STS 上的 NameIdentifier 属性匹配。这一信息非常重要，稍后我将详细阐述其中的原因。

 

在本例中，假设 FARM_A 准备将 FARM_B 用作远程 SharePoint 索引，因此 FARM_B 需要信任 FARM_A 中的调用。同样，我们还假设 FARM_A 有一个位于 https://FARM_A 的 Web 应用程序。为了创建信任，我们将按如下所示在 FARM_B 中的服务器上运行 New-SPTrustedSecurityTokenIssuer cmdlet（稍后我会在本文中解释为何使用“$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 cmdlet 建立信任。在第二个表单中，您仅需提供令牌签名证书和名称标识符。您可采取与 SharePoint 2010 中相同的操作获取令牌签名证书：转到场中的服务器，运行 MMC，为“本地计算机”添加“证书”管理单元，查找“SharePoint…证书”节点，列表中的第一个证书就是您想要的证书。无需私钥 ，仅需将其作为 .cer 文件保存至本地驱动器。您需要上述证书和 STS 的 NameIdentifier 属性才能建立信任。此时，cmdlet 如下所示（假设您已将 STS 证书复制到 FARM_B 所在服务器上的 C:\sts.cer 文件）：

 

$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 中受信任的根颁发机构列表中。同样，您仍可通过两种方式执行此操作：如果您通过元数据端点创建信任，则采取以下方式建立信任：

 

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 索引）：

此过程包括两个步骤 – 获取应用程序主体并授予其权限。请记住，在我们列举的场景中，由于 FARM_B 准备获取远程 SharePoint 索引的查询，因此需要信任 FARM_A 中的调用。对于应用程序主体，我必须引用 FARM_A 要使用的FARM_B 中的 Web 应用程序。引用后，我可以为 FARM_A 授予使用此应用程序的权限。

 

要引用应用程序主体，则可按如下所示使用 cmdlet：

 

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

 

重要信息： 此处有一个要点值得注意，我认为这一点在使用 SharePoint 2013 Beta 版的过程中尤为常见。尝试获取 SPAppPrincipal 时，您可能会在 PowerShell 中遇到异常错误。我发现，如果您服务器上的可用内存不足 5%，则所有 WCF 调用都会失败。由于此 PowerShell cmdlet 将调入作为 WCF 托管的服务应用程序端点，因此内存过低时，Get-SPAppPrincipal cmdlet 将会失败。您可以在应用程序日志中检查 Windows 事件查看器，确定这是否是导致出现问题的原因。我曾多次遇到这种现象，因此其他人很可能也会遇到。

 

请注意，正如我刚才在本文中所提到的那样，最后我会使用 $i 变量在 FARM_A 中获取 STS 的 NameIdentifier。引用 FARM_B Web 应用程序的应用程序主体之后，我可按如下所示授予其权限：

 

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

 

以上就是在两个 SharePoint 场之间创建 oAuth 信任的各种选项和方法。我将继续深入探讨 oAuth 及其各种使用方法和问题，请随时关注此博客。

这是一篇本地化的博客文章。请访问 Setting Up an oAuth Trust Between Farms in SharePoint 2013 以查看原文。