Partager via

使用 SharePoint 2010 和 Azure Access Control Service 的联合 SAML 身份验证（第 1 部分）

  • Article

原文发布于 2011 年 5 月 6 日（星期五）

注意：此网站上的格式设置一如既往地糟糕。建议您下载 Word 文档附件以及本文以方便阅读。

最近，我饶有兴趣地研究了一下 Windows Azure Access Control Service (ACS)，考虑了一些不同的集成选项。关于 SharePoint 2010 的声明身份验证，以及如何集成 ADFS、Windows Live、Facebook 等，总有很多传闻。ACS（你们 Azure 正统/市场营销人士称之为 AppFabric ACS ）相当酷，因为它包括针对这些常见的开箱即用身份提供程序的“连接器”。当设置一个 ACS 命名空间（可以把它想象成带连接器和配置设置的帐户）时，便已简化了与 ADFS 2.0、Windows Live、Yahoo、Google 和 Facebook 的连接。唉，在我这样懒惰的程序员看来，那里边一定有什么名堂，所以我决定从不同角度探究一番。在本文中，我将描述第一部分。

 

对于此应用场景，我其实只想在 SharePoint 2010 和 ACS 之间直接建立信任。我希望能够用 ADFS、Windows Live、Yahoo 和 Google 帐户进行身份验证并进入我的 SharePoint 网站。我没有包括 Facebook，因为我实际上不喜欢社会计算（此博客正符合我的情形），我之所以没有 Facebook 或 Twitter 帐户，因为我对于频繁与整个世界分享无聊信息实在不感兴趣（“普菲刚生了 3 只小猫 – 好可爱呀！！！ ”）。我不会解释如何获得 Windows Azure 帐户，如何创建访问控制服务命名空间，如何管理 ACS 等。Windows Azure 人士那里应当有很多信息，我就不再赘述了。

 

我要描述的是设置各种必要的信任、证书和配置，以便让所有这一切协同工作的过程。最后，我将包括一些我以各个提供程序身份登录后得到的截图。下面是建立连接的步骤：

  1. 打开访问控制管理页

    1. 登录您的 Windows Azure 管理门户。在左窗格中，单击“服务总线、访问控制和缓存”菜单。单击左窗格（AppFabric 下）顶部的“访问控制”，单击右窗格中的命名空间，再单击功能区的“管理”部分中的“访问控制服务”按钮。“访问控制管理”页面随之弹出。

  2. 为 ADFS 添加一个身份提供程序

    1. 在左窗格的“信任关系”菜单中，单击“身份提供程序”。
    2. 单击“添加链接”
    3. 默认情况下，“WS 联合身份验证”身份提供程序单选按钮应处于选中状态，如果没有选中，则选中它。这就是要用于 ADFS 2.0 的身份验证程序。单击“下一步”按钮。
    4. 填写“身份提供程序设置”部分
      1. 填写显示名称，如“我的 ADFS 服务器”
      2. 关于 WS 联合身份验证元数据，如果您的 ADFS 服务器已通过 Internet 公开，则只需进入指向联合身份验证元数据端点的 Url。默认情况下，它位于 https://yourAdfsServer.com/FederationMetadata/2007-06/FederationMetadata.xml。如果您的 ADFS 服务器没有向 Internet 公开，则在您的本地浏览器中打开指向此端点的 Url。转至您的浏览器，以 .XML 文件格式将此页保存到本地文件系统中。然后在 ACS 的“身份提供程序设置”中，单击“文件”编辑框旁边的单选按钮，使用“浏览”按钮查找您刚才保存的联合身份验证元数据 xml 文件。

这差不多就是在 ACS 中创建自己的身份提供程序需要执行的所有操作了。

3.        为 SharePoint 添加一个信赖方

  1.  

    1. 现在，您需要添加 SharePoint 作为 ACS 的信赖方，就像您一起配置 SharePoint 和 ADFA 那样。通过单击左窗格中“信任关系”菜单下的信赖方应用程序链接开始

    2. 单击“添加链接”。

    3. 填写“信赖方应用程序设置”部分

      1. 输入显示名称，如“SharePoint 2010”
      2. 使用默认的手动输入设置模式
      3. 在“领域”编辑框中，输入一个领域，并且保存，因为当您在 SharePoint 中创建自己的 SPTrustedIdentityTokenIssuer 时，会再次用到它。出于本例的需要，我们称该领域为“urn:sharepoint:acs”。
      4. 对于返回 Url，使用和您在设置 SharePoint 作为 ADFS 中的信赖方时同样的格式：https://yourSiteName/_trust/。
      5. 令牌格式下拉列表应为 SAML 1.1
      6. 可以根据您的需要设置令牌生存期（秒）。默认为 10 分钟。我的设置是 3600 秒，即 1 个小时。

    4. 填写“身份验证设置”部分

      1. 选中身份提供程序下的所有框。其中应显示您在前面的步骤中创建的 ADFS 身份提供程序
      2. 在“规则”组下，保留默认选中的组，即“创建新规则”组。

    5. 在“令牌签名设置”中，可以保留默认选择的选项，即“使用服务命名空间证书(标准)”。

    6. 单击“保存”按钮，保存所做的更改，并创建信赖方

4.        为信赖方创建规则

  1.  
    1. 在这里，我假设您以前未在 ACS 中创建过一套规则，这样，我们便可创建一组新规则。如果您曾有一个要重用的组，那么在上一步骤中，您应当已经一一选中了要与信赖方配合使用的组，而不是采用默认的“创建新规则组”。但是，由于我们要创建一个新组，因此请单击左窗格中“信任关系”菜单下的“规则组”链接
    2. 您应当看到这样一个规则组，其名称类似于“不管您的信赖方名称是什么，总是默认规则组”。单击该规则组名称的该链接
    3. 的确，此时最简单的事情莫过于单击“生成”链接。它会自动为您创建一组规则，其中基本上列举了您将从每个身份提供程序获得的所有声明，然后还会为每一个以同一声明类型将该声明值传递给信赖方的身份提供程序创建一条规则
    4. 在“生成规则”页面上，只要选中每个身份提供程序旁边的框，单击“生成”按钮即可。这将创建如我前面所述的规则。此任务完成后，您将重定向到“编辑规则”组页面，从中您会看到所列的所有规则。在很多情况下，这便足够了，但我们这里有一个异常需要加以考虑。在 SharePoint 中，我们要用电子邮件地址作为身份声明。具有讽刺意味的是，所有身份提供程序一并发送电子邮件地址（并具有让它们这样做而创建的规则），只有 Windows Live 除外。所以直到现在，在本例中，我假造了 Windows Live 片段。我的意思是，我准备采用本例中确实提供的一个声明 - nameidentifier，并且还准备创建一个将该声明传回的规则，但本例中却要将它作为电子邮件声明传回。无需责怪 Steve，这不过是一种让此演示环境在具有最少移动部件（并且已经有一些）的情况下运行的方式。现在我们将添加此最终规则
    5. 单击“添加链接”
    6. 在“身份提供程序”下拉列表中，选择 Windows Live I
    7. 在“输入声明类型”部分，单击“选择类型:”旁边的单选按钮。Windows Live ID 只支持一个声明类型，所以该类型已处于选中状态 (nameidentifier)
    8. 向下滚动到“输出声明类型”部分，单击“选择类型:”旁边的单选按钮
    9. 在下拉列表中，找到 https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress 并选择它
    10. 如果您愿意，可以输入说明，然后单击“保存”按钮来保存更改并创建规则
    11. 您将重定向到“编辑规则组”页面，然后单击“保存”按钮来保存所有更改。您现在已处理完毕 ACS 配置，但还不要关闭浏览器，因为创建和配置其他组件时还需要从那里得到一些额外信息。

5.        在 ADFS 中为 ACS 创建信赖方

  1.  

    1. ADFS 是 ACS 的身份提供程序，ACS 又是 ADFS 的信赖方。这意味着我们需要在 ADFS 中配置一个信赖方，以便当 ACS 将身份验证请求重定向到 ADFS 时，已建立允许 ADFS 回应的信任。首先，转至您的 ADFS 服务器，打开 AD FS 2.0 管理控制台

    2. 进入 AD FS 2.0 ...信任关系…信赖方信任节点并单击右窗格中的“添加信赖方信任...”链接

    3. 单击“开始”按钮启动向导

    4. 使用默认选项，导入已在线发布的信赖方数据。您需要使用的 Url 在 ACS 管理门户内。返回到打开该门户的浏览器，在左窗格中，单击“信任关系”菜单下的“应用程序集成”链接

    5. 复制它为 WS 联合身份验证元数据显示的 Url，将其粘贴到 ADFS 向导中的“联合身份验证元数据地址(主机名或 URL):”编辑框中，然后单击“下一步”按钮

    6. 键入显示名称，也可加一些注释，然后单击“下一步”按钮

    7. 保留默认的允许所有用户访问信赖方的选项，单击“下一步”按钮

    8. 单击“下一步”按钮创建信赖方

    9. 一旦信赖方建成，即可打开 ADFS 中的“规则编辑器”来创建将声明值传递给 ACS 的新规则

    10. 选中“颁发转换规则”选项卡，单击“添加规则…”按钮

    11. 保持默认模板“以声明形式发送 LDAP 属性”为选中状态，单击“下一步”按钮。

    12. 填写规则详情的其余部分：

      1. 键入声明规则名称
      2. 从“属性存储:”下拉列表中，选择 Active Directory
      3. 在“LDAP 属性的映射”部分，映射
        1. LDAP 属性 E-Mail-Addresses 为“传出声明类型电子邮件地址”
        2. LDAP 属性 Token-Groups – Unqualified Names 为“传出声明类型角色”
      4. 单击“完成”按钮保存您的规则。ADFS 配置现在完成。

6.        使用 ACS 配置 SharePoint 信任

  1.  
    1. 这是一个多步骤过程。一开始，先从 ACS 获取令牌签名证书，幸运的是，该证书包括在 FederationMetadata.xml 文件中，所以我们将从那里提取它，并将它本地保存到 SharePoint 服务器中。在 SharePoint Server 上，打开一个浏览器，如上所述打开“访问控制管理”页面
    2. 在左窗格中，单击“信任关系”菜单下的“应用程序集成”链接，复制它为 WS 联合身份验证元数据显示的 Url 并将其粘贴到您的浏览器中。ACS FederationMetadata.xml 文件将在浏览器中显示。
    3. 找到像这样的部分（大概在从页顶部向下的第二个主要部分）：

<RoleDescriptor xsi:type="fed:SecurityTokenServiceType" protocolSupportEnumeration="https://docs.oasis-open.org/wsfed/federation/200706" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns:fed="https://docs.oasis-open.org/wsfed/federation/200706">

<KeyDescriptor use="signing">

<KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">

<X509Data>

<X509Certificate>MIIDEDCCAfiblahblahblah</X509Certificate>

</X509Data>

 

复制 X509Certificate 元素之外的数据，将其粘贴到记事本中。以 .CER 文件扩展名保存（编码应该是 ANSI）；出于本文的需要，我们假设您调用文件 C:\AcsTokenSigning.cer。这是 ACS 的令牌签名证书。

  1.  
    1. 将 ACS 令牌签名证书添加到 SharePoint 中可信根颁发机构列表中。具体步骤可参照 https://blogs.technet.com/b/speschka/archive/2010/07/07/managing-trusted-root-authorities-for-claims-authentication-in-sharepoint-2010-central-admin.aspx（该链接可能指向英文页面），也可以通过 PowerShell 来添加，像这样：

 

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

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

 

  1.  
    1. 下一步是创建您的新 SPTrustedIdentityTokenIssuer。我在很多地方都描述过此问题；您可以将 https://blogs.msdn.com/b/sharepoint_chs/archive/2010/11/25/sharepoint-2010-adfs-v2.aspx 作为起点（只要向下滚动到设置 ADFS 之后显现的信息即可）。需要记住一些事项：
      1. name 和 nameidentifier 都是 SharePoint 中的保留声明类型，所以即便 nameidentifier 是 ACS 中各标准身份提供程序间的公共声明，也不要选择它作为您的身份声明。相反，我建议现在只是回退电子邮件地址，并在 ACS 中添加相应的规则，如上所述
      2. New-SPTrustedIdentityTokenIssuer 的 SignInUrl 参数应指向您的 ACS 实例。例如 https://myAcsNamespace.accesscontrol.windows.net:443/v2/wsfederation。可以通过查看您在 ADFS 中为 ACS 设置的信赖方找到该实例。打开“信赖方属性”对话框，单击“终结点”选项卡，将它显示的 Url 作为 POST 绑定（它应当是那里的唯一一个）的 WS 联合身份验证被动端点。
    2. 最后一步就是创建 Web 应用程序，配置它以便使用声明身份验证和为 ACS 创建的 SPTrustedIdentityTokenIssuer，最后在 Web 应用程序中创建一个网站集并开始测试。

 

至此，您应该准备好了点击网站，那就试一试吧。记住，您需要将网站集管理员配置作为其中一个身份提供程序将返回的电子邮件地址之一，这样才能登录到网站。一旦进入那里，便可以如通常期望的那样，从提供程序向 SharePoint 组添加电子邮件地址或角色声明。

 

现在，要再次提醒您注意 Windows Live ID。如本文前面所述，您不会真有一个用于 Windows Live 的有效电子邮件地址，所以需要将其称为 PUID 的东西添加到您的 SharePoint 组中。为便于测试，最简单的办法是使用 Windows Live ID 登录，然后您将到达 SharePoint 中把您的登录身份称为“foo”的页面，并且您的访问被拒绝。从那里，您可以复制 PUID，以管理员用户身份登录，将 PUID 添加到 SharePoint 组中，于是一切就绪。我甚至还没有查看哪些种类的目录选项（如有）可用于 Windows Live ID（我猜可能没有）。但它是一个开始，所以我们可以继续此概念证明。现在我们已经这样做了，下面是使用各个身份提供程序登录我的网站的情形：

 

登录页

ADFS

 

Google

 

Yahoo

 

Windows Live ID

 

 

这是一篇本地化的博客文章。请访问 Federated SAML Authentication with SharePoint 2010 and Azure Access Control Service Part 1 以查看原文