Partager via

端对端配置 SharePoint 2010 和 ADFS v2 版本

  • Article

端对端配置 SharePoint 2010 和 ADFS v2 版本

在这篇文章中，我将以端对端的方式演练如何配置 SharePoint 2010 和 ADFS v2 版本，以使用 SAML 声明身份验证。 我会在示范中提供相关步骤和 PowerShell 脚本，并且我会尝试将各部分内容归纳到一篇大型文章中。

首先简述涉及的组件和我们需要执行的操作。 在此方案中，ADFS v2 版本是身份提供程序，又称为 IP-STS（Security Token Service，安全令牌服务）。 我们需要使用有关信赖方（或 RP）的信息配置 ADFS。 在此情况下，SharePoint 是 RP，具体取决于 ADFS 是否进行身份验证以及提供声明。 从 SharePoint 角度讲，我们必须配置它才能信任向我们发送声明的 IP-STS，然后我们必须设置要使用这些声明的 Web 应用程序和网站。

我们会先在 ADFS 中创建信赖方。 请注意，按什么顺序执行这些操作并不重要，但实际上我通常会先配置 ADFS。 因此，请转至其中安装了 ADFS 的服务器，打开 AD FS 2.0 Management 应用程序。展开“信任关系”(Trust Relationships) 节点，单击“信赖方信任”(Relying Party Trusts) 节点。

在右侧窗格中，单击“添加信赖方信任”(Add Relying Party Trust) 链接以启动“添加信赖方信任”(Add Relying Party Trust) 向导。

单击“开始”(Start) 按钮继续。

选择“手动输入信赖方数据”(Enter data about the relying party manually) 选项，然后单击“下一步”(Next) 按钮。

输入显示名称和信赖方说明（可选），然后单击“下一步”(Next) 按钮。

选择“使用 AD FS 2.0 配置文件”(use the AD FS 2.0 profile) 选项，然后单击“下一步”(Next) 按钮。

可以选择证书以对 SAML 令牌本身加密。 此操作不常用，因为 ADFS 需要通过 SSL 与 SharePoint 建立连接，因此发送令牌时使用的通道已经加密。 单击“下一步”(Next) 按钮。

选中“启用对 WS 联合身份验证被动协议的支持”(Enable support for the WS-Federation Passive protocol) 复选框。 对于协议 URL，需要输入 SharePoint Web 应用程序根网站的 Url，并包括“_trust”子目录。 在本例中，SharePoint Web 应用程序的 Url 为 https://seo14，因此 WS 联合身份验证被动协议的 Url 为 https://seo14/_trust/。 输入 Url 后，单击“下一步”(Next) 按钮。

对于信赖方信任标识符，需要输入用户登录 Web 应用程序时，此 Web 应用程序将传递给 ADFS 的领域。 通常采用 urn:foo:bar 格式创建该领域。 该领域与 Web 应用程序关联，并可确定 ADFS 如何将传入的登录请求映射到它所具有的信赖方信任。 结合 SharePoint 使用时，ADFS 会查看与登录请求关联的领域并等候查找信赖方信任，然后在对用户进行身份验证后，它会关注该 WS 联合身份验证被动协议 Url 以了解用户随后重定向到的位置。 因此，在这种情况下，我输入了 urn:seo:sharepoint 领域。 在尝试导航到我的 SharePoint 网站（网址为：https://seo14）时，将重定向到 ADFS，并且我将 SharePoint 配置为对该请求使用 urn:seo:sharepoint 领域。 在 ADFS 对我进行身份验证后，它会将我再次重定向到 https://seo14/_trust/，因为它是该信赖方的被动协议 Url。 在此添加要使用的领域，并记住它，因为在配置 SharePoint 时需要再次输入它。 然后单击“下一步”(Next) 按钮。

在大多数情况下，您希望所有用户都可以使用此信赖方。 我们假设是这种情况，那么只需接受默认选项，并单击“下一步”(Next) 按钮。

如果此时需要对信赖方信任进行其他任何配置更改，则可以在此处执行该操作。 如果不需要进行更改，只需单击“下一步”(Next) 按钮继续。

虽然我们已经配置信赖方信任，但仍需要创建一个声明规则来告知 ADFS 要将哪些声明发送回 SharePoint。 因此，请保持该复选框为选中状态，以打开“编辑声明规则”(Edit Claim Rules)对话框，然后单击“关闭”(Close) 按钮。

现在，我们将创建一个新规则，因此请单击“添加规则...”(Add Rule...) 按钮。

我们将以声明形式发送 LDAP 属性，因为此时我们要从 Active Directory 获取信息，即我们将在 ADFS 中进行身份验证，而 ADFS 将使用企业 Active Directory 对我们进行身份验证，并确定我们的属性。 因此，请保留默认值，然后单击“下一步”(Next) 按钮继续。

先键入声明规则名称；该名称可以是您所需的任何名称。 接下来，在“属性存储”(Attribute store) 下拉列表中选择“Active Directory”。 然后，根据我们的情况，我们要将电子邮件地址和用户所属的组发送回 SharePoint。 我们将使用电子邮件地址作为该用户的标识符，并且要在角色声明中发送用户所属的全部组。 若要进行映射，请从左侧下拉列表中选择所需属性，然后在右侧窗格中的下拉列表中选择将发送的声明。 此时，我们希望采用标准“电子邮件地址”(E-Mail Address) 声明来发送 Active Directory 中的“电子邮件地址”(E-Mail-Addresses) 属性。 我们希望采用标准“角色”(Role) 声明来发送用户所属的组。 在此情况下，我已选择“令牌组 - 非限定名称”(Token-Groups - Unqualified Names)，因为它将以简单字符串 - 组名的形式发送组名。 您可以发送组的 SID，但这样在尝试将角色声明分派给 SharePoint 组时将更难使用它。 在按此处所述配置该规则后，请单击“完成”(Finish) 按钮以完成规则创建过程。

单击“确定”(OK) 按钮完成在 ADFS 中创建信赖方信任的过程。 现在，不再需要在 ADFS 中执行其他任何配置操作。 不过，我们需要从中了解另一方面。 ADFS 会使用一个证书对其发送的令牌进行签名。 这样可确保客户的令牌自创建以来未曾被篡改。 若要配置 SharePoint，我们需要使用此证书的副本，因为在将其配置为使用 ADFS 作为 IP-STS 时会使用该证书副本。 若要从 ADFS 中获取此令牌签名证书，请展开“服务”(Service) 节点，然后单击“证书”(Certificates) 节点。

下一节介绍令牌签名证书。 您可能有一个或多个令牌签名证书，但始终只有一个主令牌签名证书。 单击该证书，然后单击右侧窗格中的“查看证书”(View Certificate) 链接。

在此特殊情况下，我选择使用我在 ADFS 网站上创建的 SSL 证书。 我不建议必须执行此操作，它只是我选择执行的操作。 如果要查看证书，请单击对话框顶部的“详细信息”(Details) 选项卡。

单击“复制到文件...”(Copy to File...) 按钮。 这将启动一个将证书副本保存到磁盘的向导。

单击“下一步”(Next) 按钮继续。

您不需要使用私钥，因此请接受默认设置，然后单击“下一步”(Next) 按钮。

最好使用默认格式，因此请单击“下一步”(Next) 按钮继续。

选择一个保存证书的位置，然后单击“下一步”(Next) 按钮。 确保记住此位置，因为以后需要从保存证书的位置将证书复制到 SharePoint 服务器。

现已捕获本地复制证书所需的全部信息，因此，请单击“完成”(Finish) 按钮结束向导操作，并将证书保存到某个本地文件中。 将此文件复制到 SharePoint 服务器，然后结束使用 ADFS 服务器。

切换到 SharePoint 服务器，我们将开始配置此服务器。 在开始配置 SharePoint 前，建议立即创建一个新的 Web 应用程序。 创建该应用程序是为了使用声明身份验证，但要选择“集成 Windows 身份验证 - NTLM”(Integrated Windows authentication - NTLM) 作为“身份验证设置”(Authentication Settings)。 确保将此 Web 应用程序配置为使用端口 443，并选择“使用安全套接字层(SSL)”(Use Secure Sockets Layer (SSL)) 单选按钮。 在创建 Web 应用程序后，请记住进入 IIS 管理器，编辑新虚拟服务器绑定，以便可以分派适当的 SSL 证书。 虽然以下步骤不在本文讨论范围之内，但可在 Internet 上的许多位置轻松找到它们。 在此重述一下我们的情况，我创建了一个使用端口 443 和 SSL 的 Web 应用程序，该 Web 应用程序的 Url 为 https://seo14。

要在 SharePoint 端执行的第一项操作是：添加我从 ADFS 服务器中复制的令牌签名证书。 但在执行该操作前，需要查看该证书。 在令牌签名证书链中可能包含一个或多个父证书。 如果是这种情况，那么我需要向 SharePoint 的受信任根证书颁发机构列表中添加该证书链中的各个证书。 为确定证书数目，我将查找从 ADFS 复制的令牌签名证书，并双击它；将显示证书属性窗口。 如果单击“证书路径”(Certification Path) 选项卡，则可以查看证书链中是否包含其他任何证书。 根据我的情况，我的令牌签名证书只有一个父证书，即根证书颁发机构证书。

现在我需要执行的操作是：对于以上我的令牌签名证书链中的每个证书，我需要在本地保存其副本。 为此，请单击相应证书，以启用该对话框中的“查看证书”(View Certificate) 按钮。 如果单击该按钮，则会为该证书打开一个单独的属性对话框。 然后，可以按照上面介绍的相同过程将此证书的副本保存到磁盘： 单击“详细信息”(Details) 选项卡，单击“复制到文件... ”(Copy to File...) 按钮，然后在本地将证书另存为 .CER 文件。 根据我的情况，我已执行此操作并将父证书副本保存到 C:\adfsParent.cer。 因此，现在在我的 SharePoint 服务器上有两个证书：

· C:\adfs.cer，它是我从 ADFS 服务器复制的令牌签名证书

· C:\adfsParent.cer，它是我的令牌签名证书的父证书

既然我有两个这样的证书，我就需要将它们添加到我的受信任根证书颁发机构列表中。 我将在 PowerShell 中使用以下脚本执行此操作：

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

New-SPTrustedRootAuthority -Name "Token Signing Cert Parent" -Certificate $root

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

New-SPTrustedRootAuthority -Name "Token Signing Cert" -Certificate $cert

在 PowerShell 中执行这些命令后，输出如下所示：

接下来，我将创建 SharePoint 将使用的声明映射。 如果回想本文前面的内容，就会知道我说过我将在 SharePoint 中使用电子邮件地址和角色声明。 下面是我创建这些映射时要使用的 PowerShell：

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

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

接下来，我将创建希望 SharePoint 使用的领域的变量。 对于本例，我说过我将使用 urn:seo:sharepoint 领域。 下面是用于创建我的领域变量的 PowerShell：

$realm = "urn:seo:sharepoint"

现在，准备创建 SPTrustedIdentityTokenIssuer。 这是我将所有配置信息捆绑在一起的位置，以便 SharePoint 知道如何连接和使用 IP-STS。 我将在下面显示 PowerShell，然后解释其中的重要部分：

$ap = New-SPTrustedIdentityTokenIssuer -Name "SAML Provider" -Description "SharePoint secured by SAML" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2 -SignInUrl "https://congen1.contoso.local/adfs/ls" -IdentifierClaim "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"

“Name”属性是在配置您的 Web 应用程序应使用的验证提供程序时，将显示在该 Web 应用程序中的内容。 “realm”属性是我们插入领域的位置，我们希望 SharePoint 将该领域用于此受信任的标识令牌颁发者。 “ImportTrustCertificate”属性是我们向其传递从 ADFS 服务器复制的令牌签名证书的位置。 “ClaimsMappings”属性是我们告诉它我们希望此受信任的标识令牌颁发者使用的声明内容的位置。 “SignInUrl”是为使用 IP-STS 进行身份验证而应将用户重定向到的 Url。 在本例中，我们希望用户使用 Windows 集成安全性向 ADFS 服务器进行身份验证，以便我们将其发送到 /adfs/ls 子目录。 最后，“IdentifierClaim”属性将告知 SharePoint 哪个声明是您的用于标识用户的声明。 在本例中，我们将电子邮件地址作为标识用户的方式。

在执行上一个 PowerShell 命令后，我们获得了可用于 SharePoint Web 应用程序的 SPTrustedIdentityTokenIssuer。 现在，我们将打开浏览器，导航到管理中心。单击“管理 Web 应用程序”(Manage Web Applications) 链接，在将使用 ADFS 进行身份验证的 Web 应用程序列表中单击该 Web 应用程序，然后在功能区中单击“验证提供程序”(Authentication Providers) 按钮。 在将使用 ADFS 进行身份验证的区域相对应的对话框中，单击此链接。 向下滚动到“身份验证类型”(Authentication Types) 部分。 现在可以取消选择 NTLM，您将在受信任提供程序的列表中看到一个名为“SAML Provider”的新提供程序。

选中其旁边的复选框，然后单击“保存”(Save) 按钮以保存更改。 现在可以开始为 Web 应用程序创建网站集。 再次说明，该过程的分步介绍不在本文讨论范围之内，但记住何时执行此操作很重要。 在添加“网站集管理员”(Site Collection Administrator) 时，请记住以标识声明的格式输入名称。 例如，在本例中，标识声明为电子邮件地址。 因此，在添加“网站集管理员”(Site Collection Administrator) 时，我使用的名称是 administrator@contoso.local，因为它是我希望其成为网站集管理员的人员的电子邮件地址。

现在，准备尝试转至我的新网站集。 打开浏览器，并键入 https://seo14， 然后单击 Enter。 首先，我将被重定向到与我的 Web 应用程序关联的 SPTrustedIdentityTokenIssuer 的 SignInUrl。 如果回想之前用于创建 SPTrustedIdentityTokenIssuer 的 PowerShell，就会知道 Url 为 https://congen1.contoso.local/adfs/ls。 因此，下面是我在浏览器中键入我的 SharePoint 网站的 Url 后看到的内容：

您可以看到浏览器窗口中的 Url 现在指向我的 ADFS 服务器，并且会看到登录对话框后面的背景中的图形代表 ADFS 服务器。 您可能还会注意到，我登录时使用的是我的 Windows 凭据（即 domain\user）。 请记住，我可以这么做是因为我在 ADFS 服务器上（而不是在 SharePoint 上）进行身份验证。 SharePoint 已配置为使用电子邮件地址作为我的标识，但我将在 ADFS 上进行身份验证，随后它将使用我们所创建的声明规则提取我的电子邮件地址和用户组，并将其放入将发送回 SharePoint 的声明中。 因此，在验证身份后，我将被重定向回 SharePoint（网址为：https://seo14/_trust/），如我在 ADFS 中设置的信赖方中的配置所示。 此时，当 SharePoint 获得在 SAML 令牌中获取的声明并将其转换为 SPUser 后，SharePoint 将在其一侧完成身份验证过程。 随后，我将最终转至该网站的主页：

您将看到该页面右上角的登录控件将我的标识显示为电子邮件地址，因为这是我的标识声明。

以上就是完整的端对端过程以及附加的简短说明。 您可以使用它配置您的网站，并按这些说明运行网站。

这是一篇本地化的博客文章。请访问 Configuring SharePoint 2010 and ADFS v2 End to End 以查看原文

Comments

  • Anonymous
    December 20, 2010
    The comment has been removed