通过

声明提示 1：了解 SharePoint 2010 中基于声明的身份验证

**摘要：**了解与 SharePoint 2010 中基于声明的身份验证相关的五个提示。

上次修改时间： 2011年8月12日

适用范围： Business Connectivity Services | Open XML | SharePoint Designer 2010 | SharePoint Foundation 2010 | SharePoint Online | SharePoint Server 2010 | Visual Studio

本文内容
本文的范围概述
提示 1：在单个 SharePoint 2010 服务器场中创建多个声明身份验证 Web 应用程序
提示 2：将 Web 应用程序从 Windows 经典模式迁移到 SharePoint 2010 中的 Windows 声明模式
提示 3：在 SharePoint 2010 中对声明身份验证网站使用访问群体功能
提示 4：为 SharePoint 2010 声明身份验证应用程序创建标识声明和角色声明
提示 5：确定在 SharePoint 2010 中所拥有的声明
结论
其他资源

**供稿人：**Steve Peschka，Microsoft Corporation

目录

  • 本文的范围概述

  • 提示 1：在单个 SharePoint 2010 服务器场中创建多个声明身份验证 Web 应用程序

  • 提示 2：将 Web 应用程序从 Windows 经典模式迁移到 SharePoint 2010 中的 Windows 声明模式

  • 提示 3：在 SharePoint 2010 中对声明身份验证网站使用访问群体功能

  • 提示 4：为 SharePoint 2010 声明身份验证应用程序创建标识声明和角色声明

  • 提示 5：确定在 SharePoint 2010 中所拥有的声明

  • 结论

  • 其他资源

单击以获取代码下载本文附带的代码示例：SharePointClaims_MSDNExample.zip（该链接可能指向英文页面）

本文的范围概述

本文针对与 Microsoft SharePoint 2010 中基于声明的身份验证相关的常见问题提供提示与解答。它还提供了一些提示和指导以帮助解决与使用和配置声明相关的问题，并且提供了指向其他资源的链接以帮助您获取详细信息。

备注

本文随附的代码示例 SharePointClaims_MSDNExample.zip（该链接可能指向英文页面） 针对提示 5：确定在 SharePoint 2010 中所拥有的声明。

提示 1：在单个 SharePoint 2010 服务器场中创建多个声明身份验证 Web 应用程序

关于如何配置多个使用 SharePoint 2010 中的声明身份验证的 Web 应用程序，主要难点在于理解 SPTrustedIdentityTokenIssuer 对象。我在博客文章 SharePoint 2010 中基于声明的身份验证的规划注意事项（该链接可能指向英文页面）中已经指出，您只能将来自安全令牌服务 (STS) 的令牌签名证书与一个 SPTrustedIdentityTokenIssuer 对象相关联。创建 SPTrustedIdentityTokenIssuer 对象时，您需要告知 SPTrustedIdentityTokenIssuer 对象：

  • 您使用的令牌签名证书。

  • 您使用的领域。

领域非常重要，因为它包含在发送回 STS 的查询字符串中。STS 使用该领域来确定您属于哪个信赖方，以便 STS 知道要处理哪些声明规则、用于查找 Web 应用程序的信任策略的 URL 等等。即使可以向 Active Directory 联合身份验证服务 (AD FS) 2.0 等服务中添加多个令牌签名证书，但是没办法保证特定令牌签名证书将用于特定信赖方，因此您还是需要找到一种方法，使其使用单个证书。

SPTrustedIdentityProvider 对象具有一个可接受多个领域的 ProviderRealms 属性。例如，您具有两个 Web 应用程序：https://collab 和 https://mysites。您使用 Windows PowerShell 创建 SPTrustedIdentityTokenIssuer，如以下 cmdlet 代码段所示。

$realm = "urn:sharepoint:collab"
$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS v2" -Description "ADFS v2" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map -SignInUrl "https://URLToYourAdfsServer/adfs/ls" -IdentifierClaim https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

SPTrustedIdentityTokenIssuer 对象现在已创建并且具有默认领域 urn:sharepoint:collab。我们在 AD FS 2.0 中创建一个信赖方并告知它标识符为 urn:sharepoint:collab 和 https://collab/_trust/。现在，为了支持我们的第二个 Web 应用程序，我们需要向 SPTrustedIdentityTokenIssuer 对象添加另一个领域。以下是完成该操作的 Windows PowerShell 代码。

$uri = new-object System.Uri("https://mysites")
$ap.ProviderRealms.Add($uri, "urn:sharepoint:mysites")
$ap.Update()

这里需要理解的关键点是 URI。URI 应该是将使用该领域的 Web 应用程序 URL。在身份验证期间，SharePoint 执行查找以查找与该 Web 应用程序的 URI 相关联的领域；这将是 SharePoint 要使用的 URI。在此示例中，我们要将领域 urn:sharepoint:mysites 用于 https://mysites 处的 Web 应用程序，因此在添加领域时我们插入了该 URI。现在，我们可以返回 AD FS 2.0 并定义标识符为 urn:sharepoint:mysites 和 https://mysites/_trust/ 的另一个信赖方，一切应该都可以正常工作。

提示 2：将 Web 应用程序从 Windows 经典模式迁移到 SharePoint 2010 中的 Windows 声明模式

如果我有一个使用 Windows 经典身份验证的 Web 应用程序，并且希望将它更改为使用 Windows 声明身份验证，我该怎么办？可能是这样一种情况：您从 Windows 经典模式中开始，现在要迁移到声明身份验证；或者您升级了 SharePoint 2007 网站。我在一个相对较小的测试用例中完成了该任务，现在想分享一下操作过程和遇到的情况。

警告注释警告

迁移到 Windows 声明后，无法重新回到 Windows 经典模式。开始之前确保您已正确备份；我在 Microsoft SQL Server 中备份了我的内容数据库，并且在管理中心中备份了我的 Web 应用程序。强烈建议首先尝试在实验室中执行此任务，然后再到生产环境中执行。

现在，解决了应该注意的问题后，过程本身就相当简单了。只需几行 Windows PowerShell 代码和很短的时间即可完成。以下是 Windows PowerShell 命令。

$WebAppName = "http://yourWebAppUrl"
$account = "yourDomain\yourUser"
$wa = get-SPWebApplication $WebAppName

Set-SPwebApplication $wa -AuthenticationProvider (New-SPAuthenticationProvider) -Zone Default
#This causes a prompt about migration. Click Yes and continue.

#The following step sets the user as an administrator for the site. 
$wa = get-SPWebApplication $WebAppName
$account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString()

#After the user is added as an administrator, we set the policy so that the user can have the correct access.
$zp = $wa.ZonePolicies("Default")
$p = $zp.Add($account,"PSPolicy")
$fc=$wa.PolicyRoles.GetSpecialRole("FullControl")
$p.PolicyRoleBindings.Add($fc)
$wa.Update()

#The final step is to trigger the user-migration process.
$wa = get-SPWebApplication $WebAppName
$wa.MigrateUsers($true)

实现上面的命令后，可能仍存在一些问题：

  • **用户无法登录。**您可能发现用户无法登录到网站。输入您的凭据后，系统可能会通知您，您是 domain\user，但不具有访问权限。如果看到此消息，可能是您在迁移之前配置了 Web 应用程序的 portalsuperuseraccount 属性和 portalsuperreaderaccount 属性。必须更新这些属性，以使用新的基于声明的帐户名称。可以通过在迁移后查看 Web 应用程序的 Web 应用程序策略，来获得新的基于声明的帐户名称；请从该策略中复制帐户名称。

  • **现有警报可能不会激发。**目前，如果现有警报不会激发，我所知道的唯一解决方法是删除并重新创建警报。

  • **搜索爬网不起作用。**仔细检查 Web 应用程序策略，并确保搜索爬网帐户显示转换后的新帐户名称。如果不显示，则必须为爬网帐户手动创建新策略。

此外，MigrateUsers cmdlet 在计时器作业中运行，因此可能需要等待它完成。完成后，我执行了以下验证：

  • **用户可以登录。**逐个添加的用户和属于 Active Directory 组并且已添加到 SharePoint 组中的用户可以登录。

  • **任务列表的"我的任务"视图仍可以正常工作。**当我是已通过 Windows 经典身份验证的用户时为我分配的项目仍显示在"我的任务"中（即，它知道"Windows 声明 Steve"以前是"Windows 经典 Steve"）。

  • **进行中的审批工作流仍可以正常工作。**我仍然能够成功完成审批工作流。

  • **进行中的自定义 SharePoint Designer 工作流仍可以正常工作。**我仍然能够成功完成我的自定义工作流。

  • **我可以创建 SharePoint Designer 工作流。**我能够创建默认工作流和自定义 SharePoint Designer 工作流的新实例。

  • **我可以对 Web 应用程序进行爬网。**我能够成功对 Web 应用程序进行爬网。

  • **我可以查询内容。**我能够通过对 Web 应用程序进行爬网成功查询内容。

到目前为止，我发现了一个异常：在网站中创建新警报时显示已创建成功（我甚至收到了电子邮件，告诉我已经创建），但当我管理警报时，它未显示在列表中。另外，进行更改时也不会生成警报电子邮件。如果我发现其他异常，我会尽量在我的博客（该链接可能指向英文页面）上进行通报。

提示 3：在 SharePoint 2010 中对声明身份验证网站使用访问群体功能

关于使用安全声明标记语言 (SAML) 声明，您可能未注意的问题是对 SharePoint 2010 中访问群体功能的影响。默认情况下，我们只从目录（如 Active Directory）和一些轻型目录访问协议 (LDAP) 源导入用户。

问题是大多数 SAML 声明用户的帐户名称类似于 i:05:t|adfs with roles|fred@contoso.com。因此，是否可以对这些声明用户使用访问群体功能？幸运的是，答案是肯定的，但您需要做一些工作。

首先，同时也是最重要的一点：需要为这些用户创建配置文件。可以手动创建这些配置文件，也可以编写一些代码进行创建。但是您需要创建这些配置文件，并使用类似于 i:05:t|adfs with roles|fred@contoso.com 的字符串作为帐户名称，然后使用要在访问群体中使用的数据填充其他字段。

接下来，创建新的访问群体。您不能使用基于用户的访问群体，如组成员（至少在不编写更多代码的情况下无法做到这一点，编写代码不在本文的讨论范围之内）。而是应该使用基于属性的访问群体。在我的方案中，我使用了配置文件中的 Office 字段作为访问群体的基础。我为两个不同的声明用户创建了两个配置文件，并将一个配置文件的 Office 字段指定为 Contoso，将另一个配置文件的 Office 字段指定为 Wingtip Toys。因此，在我的新访问群体中，我创建了 Office = Contoso 的规则，并将它命名为 Contoso Employees。搜集我的访问群体后，我可以看到其成员资格包含我的声明用户。

为了进一步验证，我随后进入我的声明网站并将 Web 部件的目标设定为访问群体。唯一有点出人意料的是人员选取器没有使用所有访问群体列表正确填充。但是，当我搜索 Contoso Employees 时，它可以找到我创建的访问群体。我为 Web 部件目标选择了该访问群体，并保存了所做更改。最后，我以两个不同声明用户的身份导航到网站。属于 Contoso Employees 访问群体的用户可以看到部件，但是另一个则看不到。

提示 4：为 SharePoint 2010 声明身份验证应用程序创建标识声明和角色声明

由于各种原因，使用标识声明和角色声明使基于声明的身份验证 Web 应用程序启动并正常运行一直以来都是一件很麻烦的事。因此在这里，我将分享用于创建声明和 SPTrustedIdentityTokenIssuer 对象的步骤。

  1. 创建标识声明，如下面的代码所示。

    $map = New-SPClaimTypeMapping -IncomingClaimType "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" 
-IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

  2. 创建角色声明，如下面的代码所示。

    $map2 = New-SPClaimTypeMapping -IncomingClaimType " https://schemas.microsoft.com/ws/2008/06/identity/claims/role " -IncomingClaimTypeDisplayName "Role" -SameAsIncoming

  3. 创建 SPTrustedIdentityTokenIssuer 对象时包含这两个声明，如下面的代码所示。

    $ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS v2" -Description "ADFS v2" 
-Realm "yourRealmName" -ImportTrustCertificate $yourCert -ClaimsMappings $map,$map2 
-SignInUrl "https://URLToYourAdfsServer/adfs/ls" -IdentifierClaim "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"

这里的关键点之一是创建令牌颁发者时需要包含这两个声明；无法在以后添加声明。这是 SPTrustedIdentityTokenIssuers 的一个限制。

提示 5：确定在 SharePoint 2010 中所拥有的声明

我研究的一个非常有意义的问题与声明身份验证网站的一些奇怪权限错误相关。在对情况进行故障排除时，有时会遇到这样的困难：我们不能枚举 SharePoint 认为我们已拥有并将其转储到任意位置的声明。

因此，访问网站并且遇到拒绝访问错误，或者无权访问我认为应该能够访问的所有内容时，我找不出什么好方法来确定原因。为了帮助调试这类情况，我编写了一段相当简单的代码，以指示 SharePoint 替我拥有的声明，即当前用户请求。我通过两种方式实现这一点。

  • 程序集的一部分是作为 HttpModule 实现的。它枚举声明，然后将它们输出到统一日志记录服务 (ULS) 日志。可以按照"SharePoint 声明枚举"类别筛选 ULS 日志，以轻松地找到这些项。HttpModule 适用于您甚至无法登录到网站的情况。

  • 程序集的第二部分是作为 Web 部件实现的。它只是发出您拥有的声明和每个声明的值。这适用于以下情况：您可以登录到网站，但正在尝试解决为什么您无权访问您认为应该能够访问的所有内容。

本文的代码示例 SharePointClaims_MSDNExample.zip（该链接可能指向英文页面） 包含此程序集的源代码和调试版本；请阅读 Instructions.txt 文件以查看说明。

关于 SharePoint 中的声明，我了解到的另外一个要点是：身份验证到 STS 后，您的令牌会返回 SharePoint。SharePoint 包含它需要查看的所有声明的列表 — 它查找所有这些声明并将它们内置到 SPClaim 对象中。如果除了 SharePoint 需要的声明外，STS 还发送回了其他声明，SharePoint 将忽略这些额外的声明，并且不会将其添加到 SPClaim 对象中。尝试对声明身份验证问题进行故障排除时，记住这一点会很有用。

结论

本文针对有关 SharePoint 2010 中基于声明的身份验证的一些常见问题提供了解答。它还提供了五个提示和指导以帮助解决与使用和配置声明相关的问题，并且提供了指向其他资源的链接以帮助您获取详细信息。

其他资源

有关详细信息，请参阅以下资源：

  • Last updated on