Inside Microsoft.com: Using Active Directory Federation Services

项目
08/17/2016

Microsoft.com 技术内幕使用 Active Directory 联合身份验证服务

Jim Guthrie

Microsoft 能够为业务伙伴提供外联网，使他们得以访问重要的内部资源。外联网的体系结构要求组织外的每个参与者都要在该空间中拥有唯一的域帐户。由于众所周知的原因，是 Microsoft 工作人员而不是业务伙伴

来创建和管理该帐户。否则的话，用户体验就可能达不到令人满意的效果，而管理如此众多的伙伴用户也会给 Microsoft 造成相当的资源负担。

这就是为什么使用外联网的道理。当客户或合作伙伴登录一项应用程序时，需要输入其凭据。在同样的会话期间，如果用户决定访问不同的资源，系统还会提示其输入凭据。只要持续访问不同的资源，就要不断的输入凭据。如果用户登录一项单独的应用程序，而该应用程序又涉及到多种资源，例如财务数据库，则用户需要针对所有不同的资源进行身份验证。这对于用户可说是既麻烦又费时的使用体验。

幸好，使用 Active Directory®联合身份验证服务 (ADFS)，我们能够非常轻松地解决多个身份验证的问题，您也一样。ADFS 是一个 Windows Server® 2003 R2 组件，能够增强两个或多个组织间的信任机制，使他们共享多个资源，同时又保证了每个组织管理自己用户组的能力。在本专栏中，我将阐明 Microsoft 是如何规划使用 ADFS 来解决此多资源外联网问题，这将为您实施类似解决方案提供必要的参考信息。在讨论细节问题之前，我们先看图 1来熟悉一些基本的 ADFS 术语。

Figure 1 ADFS 术语

术语	定义
联合身份验证	建立 Active Directory 联合身份验证信任的一对领域或域。
联合身份验证服务资源 (FS-R)	向 FS-A 和所需资源输入身份验证请求的路由。
联合身份验证服务帐户 (FS-A)	提供 FS-R 身份验证要求的帐户令牌。
联合身份验证服务代理 (FS-P)	为 FS 服务器提供入站 Internet 通信隔离层。
声明	服务器关于客户端作出的声明（例如名称、标识、密钥、组、权限或功能）。
领域发现	每个 FS-A 都有一个域或领域，登录凭据就储存在这里。领域发现决定 ADFS 会话使用哪一个 FS-A。

ADFS 解决方案

当用户试图访问可识别 ADFS 的应用程序时，会将浏览器发送到联合身份验证服务资源 (FS-R) 以进行领域发现。用户可选择在会话期间使用哪一组凭据。基于客户端选择的领域，用户会被重定向到联合身份验证服务帐户 (FS-A) 服务器。用户将从该服务器收到一个基于用户输入凭据的有效帐户令牌（存储在 cookie 中），该凭据以下列形式输入：Windows Live™ ID（以前的 Passport 帐户）、Windows 集成身份验证或 SSL 身份验证（见图 2）。在该模型中，由各组织自行维护他们自己的帐户联合身份验证服务器。有了 Microsoft 业务伙伴的服务器，就省去了 Microsoft.com 在此环境下管理所有帐户的负担。当然，如果您担负起了相应的责任，就必须仔细选择与之联合的组织，并保证这些组织能够积极地管理他们的帐户信息。

图 2 ADFS 流程

图 2** ADFS 流程 **(单击该图像获得较大视图)

路由的下一站是返回到 FS-R 服务器，将帐户令牌换为资源令牌。在此配置下，该令牌包含了用户在 FS-R 上执行声明映射过程而获得的完整的权限列表。一旦收到令牌，在整个会话开启期间或者在默认的 24 小时（可自行配置）内，用户将针对可识别 ADFS 的应用程序获得单一登录 (SSO) 能力。结论就是您能够在可识别 ADFS 的应用程序上启用 SSO，进而是更加安全和高效的客户体验。欲完整了解 ADFS 身份验证过程，请参阅 Matt Steele 于 2006 年 7 月在 TechNet 杂志上发表的文章，标题是：使用 ADFS 简化单一登录操作。

为了保证 Microsoft 企业资源的安全，我们将外联网面向 internet 的一端和公司端隔离开来，这就是说每个服务器潜在都是双宿主服务器。我们允许来自公司内部用户的单向信任，并使用服务器提供所需的保护。我们也为外联网空间建立了单独的域，这样外部用户可以访问他们需要的资源。

实施过程中应加以关注的两个主要领域是负载平衡和 ADFS 策略文件更改。负载平衡对全局和局部而言都是一个挑战。最初，我们在两个区域的前端 Web 服务器群集使用了内容传送网络 (CDN) 合作伙伴 Akamai 或 Savvis 提供的全局负载平衡。这将保证系统对最终用户的可用性，即使是在双区域服务器脱机这种极少发生的情况下，也是如此。通过 CDN 提供的服务器运行状态检查服务，自动进行故障转移而实现上述目标。而且，将来我们能够很轻松地加入更多群集。为节省成本，我们的预运行部署选择了不使用 CDN 服务。

在区域性水平上，我们通过网络负载平衡 (NLB) 群集，配对服务器使其具备本地故障转移功能。我们没有使用任何特殊的负载平衡功能，所以仅仅通过硬件就能轻松完成该工作，而这里我们为了节省成本再次使用 NLB。在其支持的所有环境下，该配置将保证超过 99.9% 的正常运行时间的稳定性。

我们面对的另一个挑战是：在整个环境中，确保 ADFS 策略文件和ADFS 主干线的正确分布，并且能复制对其所做的任何更改。为了实现这一点，我们利用 Windows Server 2003 R2 的另一内置功能 — 分布式文件系统复制 (DFS-R)，一种基于状态的新型多主机复制引擎。在每台后端服务器上，我们启用一个 24 小时的交错复制 DFS-R 组成员身份。现在，无论对策略文件做什么更改，都会分发到所有的服务器上。只要我们控制了更改文件的权限，我们就拥有稳定的、高可用性的服务。

我们已经努力促使所有的更改都能通过 ADFS 管理单元进行，但事实上我们有时不得不手动更新文件。当手动更新时，切记要让 ADFS 跟踪该文件的版本。因此您必须添加该文件，这样你的更改会反映在环境中：

<TrustPolicyEntryUri>urn:federation:parttestint</TrustPolicyEntryUri> 
<TrustPolicyVersion>127
</TrustPolicyVersion>

还要记住，像所有的 XML 一样，策略 XML 文件也区分大小写。在整个策略 XML 文件中，有许多对应用程序或其他 ADFS 服务器的引用。在这种情况下，必须将其逐字逐句地从一个服务器复制到另一个服务器。请注意下列的常见示例：第一，RevocationCheckFlags 是由手动输入；第二，在 UI 上改变一个受信任应用程序的 URL。

<RevocationCheckFlags>None
</RevocationCheckFlags>
<TrustPolicyEntryUri>https://adfstest.parttest.extranettest.microsoft.com/NTApp/
</TrustPolicyEntryUri>

对于其他的安全级别，我们使用另一个 ADFS 组件，联合身份验证服务代理 (FS-P)，保证有传入的 Internet 请求时，FS-R 保持为一层而不被直接访问。Microsoft.com 实施代理的独特方式是：在预运行中使用单独的一组代理，作为几个 ADFS 环境的宿主。有趣的是，开发此技术之初，我们发现需要简单地修改一下注册表项才可以实现上述功能。该注册表项位于 HKLM\Software\Microsoft\WebSSO。简单修改一下该注册表项的初始目录值，能够让您在几个环境下使用该代理。其默认位置是：

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttestint”

如切换环境，注册表项会有如下变化：

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttest”

创建批处理文件可以简化这一过程的管理。然而当前版本的 ADFS MMC 管理单元不支持环境切换，因为代理和资源或帐户服务器之间是一对一关系。这是代理服务器利用率实现最大化的唯一方式。最终会节省巨额成本，因为无论选择多少不同的环境作为宿主，所需物理服务器的数量是有限的。

从体系结构的角度来讲，我们是在虚拟机上运行预运行环境，这又是一种节约成本的方式。可以省去额外购置六台服务器的需求。至今还没有出现过任何性能方面的问题。然而，为了满足运行环境方面急剧增长的需求，我们选择了使用更高性能的物理机器。

不仅仅是 Active Directory

Microsoft.com 不仅使用 Active Directory 帐户进行身份验证，而且与 Windows Live ID 帐户也成功地进行了集成。我们发现通过使用 Windows Live ID (WLID) 4.5，就能在单独的 Windows Live ID 中使用客户声明转换来代理访问 Microsoft 资源。这是实现 SSO 身份验证的巨大胜利，因为我们不再需要特定的域帐户。

挑战依然存在

我们眼前最大的挑战就是共享令牌签名证书的 ADFS 管理工作。我们使用仍然有效的标准证书，尤其是那些尚未续订、有效期为一年的证书。续订时，每台适当的服务器都需要进行相应的更新，这将对 FS-R 产生重要的影响。尽管可以管理大约 15 到 20 个联合身份验证，但是我们希望的规模即使达不到数千个，也至少是数百个联合身份验证。这样，就需要有全职员工在单独的环境下管理 SSL 证书。我们有几个团队正在探寻使上述解决方案实现自动化的最佳方法，但其执行过程还没有最终确定下来。

另一个的挑战是迄今为止，并不是所有的应用程序都能识别 ADFS。这就需要站点进行一些编程才能利用 ADFS 的优势。我们正与 Microsoft® Office SharePoint® 服务团队紧密合作，确保下一代 SharePoint 能够支持 ADFS 的实施要求。

结束语

如果您决定转到 ADFS 模式，那么还需要另外考虑一些因素。其中之一是客户可以访问的资源数量。在组织之间建立联合信任也许是个普通任务，但也需要时间和精力来编写、检查和执行可以接受的访问策略。因此，如果仅有一个资源供客户访问，那么您就要考虑是否有这个必要建立联合信任。但是，随着资源数量的增加，所能得到的好处也会增加。

Jim Guthrie 是 Microsoft.com 运营团队中的一员，而且除了是 ADFS（Active Directory 联合身份验证服务）的工作成员外，他还是企业门户平台支持团队的系统工程师。

其他资源