单一登录:Active Directory 联合身份验证服务开发简介

摘自 November 2006 期刊 MSDN Magazine.

Active Directory 联合身份验证服务 (ADFS) 是 Windows Server^® 2003 R2 最重要的组件之一。ADFS 能够解决很多问题，而其中最显而易见的就是企业到企业的自动化控制问题。在这篇文章中，我将从一个开发人员的角度来分析 ADFS，我们假设这个开发人员正在构建一个 Web 应用程序，而且希望其他组织也能够使用这个程序（若要了解从管理员角度对 ADFS 的分析，请参阅 TechNet Magazine 上 Matt Steele 的文章）。

 

那么，我所说的企业到企业的问题究竟是什么呢？假设有一家名为 Fabrikam 的自行车制造商想发布一个 Web 应用程序，使授权经销商能够通过这个应用程序以批发价购买自行车和零部件。但是，Fabrikam 的经销商有两百多家，而且每个经销商都有好几名员工需要使用这个应用程序。因此，Fabrikam 必须建立起一个安全性很高的登录机制。

最直接的解决方案就是创建一个包含用户名和密码的数据库，但这种方法的管理成本非常高。如果有人致电 Fabrikam，声称自己是某个经销商的员工，那么，Fabrikam 该如何验证其真实性呢？他们可能首先与这家经销商公司里某个值得信任的人取得联系，证实这名员工的身份，然后才开始设置新的帐户。您可以考虑一下这类用户帐户的维护成本：人们可能会忘记用户名和密码，当然，还可能遇到其他问题。如果这名员工离开了这家经销商公司，会出现什么情况呢？会有人记得要通知 Fabrikam 应该删除他的用户帐户（用身份标识术语的说法，就是取消设置）吗？如果没有的话，那么这个用户可能会在自己家里用该经销商的身份去下假的订单。

密码本身也存在另一个问题。随着计算能力的不断增强，破解密码变得越来越容易，如今，很多组织都倾向于使用更为强大的身份验证技术，例如智能卡。但是，由于 Fabrikam 必须面对众多不同的经销商，如果采用比密码更强大的身份验证技术，那么 Fabrikam 一定会应接不暇。

值得注意的是信任在这里也是一个重要因素。Fabrikam 相信每一家经销商能够提供准确的员工清单，这些员工将被允许通过 Fabrikam 的 Web 应用程序进行采购。

使用 ADFS 构建的解决方案

ADFS 能够帮助您建立起信任关系，从而降低了对用户帐户设置的依赖性。如果各家经销商已经能够通过软件来验证他们自己的用户，您又何必再费事去为自己的应用程序构建一个用户帐户数据库呢？

ADFS 是 Microsoft 实现的 WS 联合身份验证被动请求者配置文件协议（被动是指客户端只需要一个支持 Cookie 和 JavaScript 的 Web 浏览器 — 在实现该协议时，被动代理不需要运行任何特殊代码）。这个协议的工作原理如下：当经销商公司的某个用户将其浏览器连接到 Fabrikam 的采购应用程序时，她的浏览器将最终被重定向，回到该经销商的网站，也就是她工作的地方，这样，这家经销商就能够对她进行身份验证。然后，她的浏览器将再次重定向回到 Fabrikam，而这个新的请求将会携带一份由这家经销商签名的声明，证明这个用户确实是这家经销商的员工，而且已由经销商验证身份，可以使用该应用程序。（我说的有点简单化了。）这里的重点在于 Fabrikam 信任这家经销商对其用户的身份验证，这也是联合身份验证技术的核心所在。

如果经销商拥有支持 WS 联合身份验证被动配置文件的软件，那么 Fabrikam 就不需要为这家经销商的员工设置任何用户帐户。同样，它也不必为重设密码的请求而感到烦恼。如果经销商公司的某个用户改变了工作角色，离开了采购部门，只要对她的身份标识信息做出相应更改，以反应职位的变动，那么当她试图使用 Fabrikam 的采购应用程序时，经销商发回的声明将指出她已不再是采购代表，因此，应用程序将拒绝她的使用。或者说，假如她已经辞职离开了这家经销商公司，而且她的帐户已经被取消，那么她也将无法使用 Fabrikam 的采购应用程序。通过实现与经销商的联合身份验证，Fabrikam 完全可以保证能够收到有关用户身份的最直接、最及时的信息。

ADFS 是建立在像由Microsoft、IBM、Verisign、BEA 以及 RSA Security 所共同制定WS 联合身份验证这样的标准上。当然，不同的组织所使用的软件也常常是大相径庭。假如 Fabrikam 在 Windows Server 2003 R2 上部署 ADFS，而经销商运行的却是 IBM WebSphere 或 BEA WebLogic，这也不成问题，因为 WebSphere 和 WebLogic 都能够实现 WS 联合身份验证。

有了联合验证这样的技术，这对于最终用户也是一件好事。对于经销商公司的采购代表来说，不用再去多记一个密码，只要用浏览器连接 Fabrikam 的应用程序，就可以马上开始工作了。如果经销商的身份验证系统支持通过浏览器集成登录，犹如就像 Windows 用在 Internet Explorer^® 一样，那么，系统甚至无需提示用户提供身份凭据；用户的身份验证将自动完成，联合身份验证服务会将位于用户端里的用户身份标识信息转换为已签名的声明并发送给 Fabrikam，就像我刚才说过的那样。这就是 Web 安全性的奥秘：能够跨越 Internet，跨越组织和技术领域，实现单一登录。

ADFS 体系结构

接下来，我将向您介绍 ADFS 的各个组成部分，并对一些术语做出解释。任何一个特定的联合身份验证关系都有两“端”，一端提供用户（帐户），另一端提供应用程序（资源）。安装 ADFS 时，您需要使用 ADFS 管理单元来配置它的信任策略，ADFS 管理单元包含在“管理工具”文件夹中，在设置信任策略时，您需要指出希望与其建立联合身份验证关系的合作伙伴列表。帐户合作伙伴的用户将会使用由资源合作伙伴所提供的支持 ADFS 的应用程序。图 1 中的树状视图就是在 ADFS 管理单元中所显示的联合身份验证关系两端的 ADFS 信任策略。

图 1  伙伴双方间的信任策略 (单击该图像获得较小视图)

图 1  伙伴双方间的信任策略 (单击该图像获得较大视图)

每一端都运行着我们今天所讲述的主角 — 联合身份验证服务。每一个联合身份验证服务都会发布一个 Web 应用程序，在建立登录时，用户的浏览器应该能够被重定向到这些应用程序。联合身份验证服务很好地解决了帐户合作伙伴与资源合作伙伴之间的不匹配问题，因此，两方都不必使用相同的身份验证或相同的操作系统技术。您的应用程序不必过多考虑联合身份验证服务的工作原理；ADFS 小组提供了一个 Web 代理程序，这个代理能够以 HttpModule 的形式在 ASP.NET 管道中运行，帮助您处理中间繁重的工作。您所要做的只是对应用程序进行配置，让它使用这个 Web 代理，然后提供一些配置设置，让代理程序知道在哪里可以找到贵公司的联合身份验证服务。图 2 所显示的就是 ADFS 的基本结构，以及用户浏览器是如何与 ADFS 的各个组件进行交互的。该图说明了联合身份验证服务的双方都安装了 ADFS 后的工作模式。但是，也可能出现例外情况。比如说，帐户合作伙伴采用 WebSphere 和 IBM 目录服务来实现 ADFS，从而所发布的是一个用 Java 语言编写的联合身份验证服务，这种情况也不难想象。

图 2  ADFS 建筑构造

联合身份验证登录流程

假设 Alice 是 Fabrikam 的某个经销商的授权用户，当她第一次通过浏览器使用 Fabrikam 的采购应用程序时，Web 代理注意到她没有 ADFS Cookie。此时的她还无法登录。接下来，在采购应用程序还没看到她的请求前，Web 代理将她的浏览器重定向到 Fabrikam 的联合身份验证服务。然后，Fabrikam 的联合身份验证服务会将浏览器重定向到这家经销商的联合身份验证服务，并在请求上添加一个 Fabrikam 联合身份验证服务所独有的标识符，以便经销商能够知道是哪一个合作伙伴在请求登录。当 Alice 的浏览器最终回到自己公司的联合身份验证服务时，该服务将要求她进行身份验证。由于这家经销商使用的是集成的 Windows 身份验证，所以 Alice 的浏览器将自动做出响应，使用她的联合身份验证服务建立一个登录。登录成功之后，她的联合身份验证服务就会发布一个安全声明标记语言 (SAML) 令牌并对 Alice 做出描述，然后将 Alice 的浏览器重定向回到 Fabrikam 的联合身份验证服务。这个 SAML 令牌会与请求一起作为投递 (POST) 的主体内容来发送（返回的页面拥有能够自动提交包含隐藏输入元素表单的 JavaScript）。Fabrikam 读取该令牌的内容后，会发布另一个 SAML 令牌。这个新的令牌包含着应用程序将最终看到的声明组（我将在下面的内容中解释，为什么在声明转换环节上需要分别使用两个不同的 SAML 令牌）。第二个令牌将通过 POST 方法发送，并写入到从 fabrikam.com 发送的一个 Cookie 中，这就使得 Alice 能够使用采购应用程序，直到她的 Cookie 过期为止。在默认设定情况下，Cookie 的有效期是 10 个小时。

还记得采购应用程序中需要寻找登录 Cookie 的那个 Web 代理吗？这一系列事件就是由它引起的。现在 Cookie 已存在，这个 Web 代理就会对 Cookie 进行拆分，读取其中由 Fabrikam 的联合身份验证服务所发布的 SAML 令牌中的声明。然后，Web 代理就会允许执行采购应用程序中的网页。如果应用程序需要知道已登录的用户名，那么通过一个众所皆知的方法就可以实现：HttpContext.User.Identity.Name。

用于传送这些信息的 IIdentity 是通过 SingleSignOnIdentity 类实现的，SingleSignOnIdentity 还提供了很多其他实用的属性，包括帐户合作伙伴在其本地域内对用户进行身份验证时所使用的身份验证方法。通过这个类别，应用程序还可以找到由其联合身份验证服务所发送的整个声明组。

您应该注意的是，合作伙伴的联合身份验证服务彼此之间绝不会直接产生对话。服务之间的通信完全是通过浏览器的重定向、关联的查询字符串以及 POST 主体内容来实现的。

确保联合身份验证登录的安全性

接下来，我们对一些细节进行更深入的分析，帮助您了解如何保证这种登录的安全性。尝试在通信过程中读取 SAML 令牌，然后在方便的时候重放这些令牌从而模仿合法用户，这是一种很常见的攻击手段。为了预防这种攻击，所有的通信都通过 HTTPS 来实现。这一点极为重要；如果您的 IIS 默认设定网站还没有安装 SSL 证书，那么，当您试着安装 ADFS 时，ADFS 安装程序就会向您发出警告并自动退出，安装过程甚至不会开始。

那么，包含声明的登录 Cookie 的安全性又如何呢？如果用户想提升自己对某个应用程序的使用特权，很简单，她只要在 Cookie 中的 SAML 令牌上添加一些声明就可以了！但是，这种小伎俩是可以被检测出来的，因为每一个 SAML 令牌都签注着一个密钥，而这个密钥只有发布它的联合身份验证服务才知道。这也给您部署 ADFS 提供了一些暗示。如果您的角色是资源合作伙伴，那么您的每一个帐户合作伙伴都必须为其帐户联合身份验证服务提供证书。您的资源联合身份验证服务将使用帐户合作伙伴提供的这些证书来验证其发布的 SAML 令牌上的签名。同时，Web 代理也必须执行类似的操作，对通过登录 Cookie 接收到的每个 SAML 令牌进行验证，确保这些令牌已经过资源联合身份验证服务的签名。

ADFS 发布的 Cookie 总是会用安全位做出标记，这就要求浏览器只能通过 HTTPS（而不能通过 HTTP）来发送 Cookie。因此，如果您的应用程序有任何部分是通过 HTTP 运行的，则登录 Cookie 就不会被发送，您也无法使用该用户的身份标识信息。看上去好像该用户是一个匿名用户。我建议整个应用程序都通过 SSL 运行，这不仅可以简化操作，而且也能降低泄漏敏感数据的风险。

在启用了 ADFS 的 Web 应用程序中，跨站点脚本 (XSS) Bug 的破坏性是相当大的，只要系统是使用 Cookie 来实现登录会话的，这个 Bug 就可能存在。对于存在这种安全漏洞的应用程序来说，其 Cookie 很容易被盗，而且，一旦盗取了 Cookie，就相当于掌握了登录信息。作为一种深层防御手段，ADFS 的登录 Cookie 会在默认设定下一个工作日后过期。当然，您也可以在 ADFS 信任策略中调整这个有效期值。如果还不太了解 XSS，及如何做相对的预防，那么您可以花半个小时的时间去看看我写的 XSS 实战 (XSS lab) 互动教程。

用户来自何方？

Fabrikam 有很多经销商，这些经销商的角色都是联合身份验证帐户合作伙伴。当某个人使用采购应用程序时，Fabrikam 的联合身份验证服务器如何判断应该将这个用户的浏览器重定向到哪个合作伙伴呢？事实上，它是不知道的。由于要面对众多的合作伙伴，Fabrikam 的联合身份验证服务器必须暂停登录过程，显示一个合作伙伴列表，并让用户自己选择由哪个合作伙伴对其进行身份验证。这个环节也称为本地域识别。如果客户端选择了假的本地域，那只会给用户自己带来麻烦，因为她并没有用于验证其他任何经销商所必需的凭据。

构建强大的 ADFS 应用程序的目标之一就是避免这类详细信息再给用户造成麻烦。Northwind 自行车行可以让它的用户通过一个带有强大查询字符串参数 (whr) 的链接去使用 Fabrikam 的网站，从而消除了这个繁琐的步骤。（我觉得 whr 更像是“which home realm”的缩写，也就是“哪一个本地域”）Web 代理会寻找这个查询字符串参数，如果找到的话，就在预先处理过程中将其从请求中分离出来。这个参数的值就是合作伙伴联合身份验证服务器的 URI（每一个联合身份验证服务器都用一个 URI 来命名）。因此，Northwind 车行员工所看到的链接就会是这样的：

https://fabrikam.com/purchasing.aspx/?whr=urn:federation:
Northwindbikeshop

有了这些方法，ADFS 就不必再显示互动式的本地域识别页面了。

 

声明和转换

我在本文中已经多次谈到了声明。声明是 Windows 平台上一种全新的、越来越重要的安全概念，也是声明某个实体（例如一个用户）的一种通用方法。我们可以看一下 Kerberos 票证，它包含着已登录用户的用户标识符以及域组标识符。实际上，这就是由发布该票证的域控制器所签名的一组声明。用户标识符就是一个身份标识声明。但是，虽然这种方法对于审核或个性化设置来说或许很实用，但它通常不用于访问控制。票证中的组更可能用于执行访问检查。举例来说，如果您是“Managers”组的成员，那么您就有权审批高额采购订单。

ADFS 支持三种类型的声明：身份标识声明、组声明以及自定义声明。身份标识声明所采用的形式是用户主要名称 (UPN)，一个电子邮件地址或者一个被称为公用名的随机字符串。组声明是一个布尔值（数字或非数字），而且它不一定代表一个 Windows 组：它可能仅代表您的应用程序所能够理解的一个逻辑角色。自定义声明包含一个字符串值。您可以在 ADFS 中设置自定义声明，例如年龄、性别甚至是管理人员姓名。这些类型的自定义声明可能会让您考虑到隐私保护问题。

声明转换正是 ADFS 用以解决隐私保护以及其他实际问题（比如说，并不是每个公司都使用相同的术语，并不是每个资源合作伙伴都需要知道用户的电子邮件地址或年龄）的有效途径。正因为这样，ADFS 的信任策略才允许您对每个合作伙伴做出不同的配置；您也应该只发送合作伙伴所需要的声明。

每个公司都会定义一组组织声明；这就像是确定一个它能够理解的词汇表一样。例如，Fabrikam 可能会定义一个名为“所有者”的组声明，这个声明用来表示某自行车经销商的所有者。而 Northwind 自行车行则可能用一个名为“管理人员”的声明来表示这个角色。只要含义相同，名称不同是没有关系的，因为 Northwind 的所有者可以使用他的资源联合身份验证信任策略，将外发的“管理人员”声明映射为 Fabrikam 能够理解的“所有者”声明。管理员可以在联合身份验证关系的两端对这类映射进行设置。图 3 所显示的就是一个资源合作伙伴的信任策略中的声明映射示例。

图 3  声明映射 (单击该图像获得较小视图)

图 3  声明映射 (单击该图像获得较大视图)

有些声明映射的动态性过高，无法用信任策略中的静态映射来表示。假设某个资源合作伙伴需要通过一个名为 IsOfLegalVotingAge 的声明来验证某人已满 18 岁，但现有的数据仅仅是 Active Directory^® 中作为自定义声明存在的该用户的出生日期。此时，您需要的是一个声明转换模块，这是一个程序集，它所包含的一个类可以实现一个名为 IClaimTransform 的托管类。您可以通过信任策略属性表（如图 4 所示）将这个模块与您的信任策略连接起来。这个模块会被调用两次：一次是在正常的信任策略映射之前，另一次则是在之后，因此，您可以进行相应的预处理或后处理。每个 ADFS 信任策略都允许安装一个这样的模块，这就是说，您可以在联合身份验证的帐户端和资源端进行动态的声明转换。

图 4  声明转换模块

声明从何而来？

除非您编写的声明转换模块能够动态生成声明，否则所有的声明都会由一个帐户存储库来生成，这个存储库既可以采用 Active Directory，也可以采用 Active Directory 应用程序模式（ADAM，即基于 Active Directory 基本代码的一个轻型目录服务器）。对 Active Directory 帐户存储库来说，您可以将组声明映射到 Active Directory 中的一个或多个组上；而在 ADAM 存储库中，您必须提供 User 对象的一个属性名称和要查询的值，这样才能指出是否应该为某个特定用户发送这个组声明。每个自定义/身份标识声明都会直接映射到目录中该 User 对象的一个单一属性上。

管理员可以充分利用公司目录中现有的身份标识数据，并将其与合作伙伴进行集成，很多情况下，这一操作不需要编写任何代码。

匿名

对基于声明的系统来说，发送用户的姓名经常是根本不需要的。这是可值得注意的地方。或许所有的合作伙伴所关心的只是用户在执行请求之前是否已经过身份验证。但是，这也常常给合作伙伴带来便利，至少可以通过一些身份标识句柄来添加个人化数据或者有关该用户的其他状态信息。

为了支持这种匿名的操作模式，我们可以使用一种特殊的内置身份标识声明转换方法，叫做增强的标识隐私。如果您是一个帐户合作伙伴，而且希望能确保自己的用户在特定资源合作伙伴那里保持匿名状态，那么您只需要在信任策略中针对该合作伙伴启用这个功能，随后，该合作伙伴就看不到：

alice@northwindbikes.com

而是看到类似于下面这样的代码：

tQZPfFuodGysa4t40oj+kM2vBIU=@northwindbikes.com

 

在生成这个句柄的时候，联合身份验证服务会通过哈希算法将实际的身份标识声明、资源合作伙伴的 URI 以及一个只有您的联合身份验证服务才知道的 Salt 值组合在一起（这在 ADFS 术语中叫做“隐私密钥”）。将合作伙伴的 URI 包含进来能够确保每个资源合作伙伴所对应的句柄都各不相同，从而防止它们相互组合，生成非常完整的用户数据。隐私密钥的引入使得字典式攻击变得难上加难。

除了能够保护来自资源合作伙伴的身份标识外，这个功能还可以保持可跟踪性。当需要确定某个身份标识时，我们可以从资源日志中找到经过哈希处理的身份标识并提供给帐户合作伙伴的管理员，管理员则可以通过帐户事件日志确定出哪个用户收到了这个身份标识。

联合身份验证服务代理

安装 ADFS 联合身份验证服务之后，您会在 IIS 管理器中看到一个新的 Web 应用程序，叫做“adfs”。在它之下，您还可以看到名为“fs”和“ls”的两个子目录，分别代表联合身份验证服务和登录服务。实际上，登录服务仅仅是基于浏览器的 ADFS 前端；如果您仔细浏览 ls 目录的话，就会看到一组 ASPX 页面（顺便说一下，您也可以自定义修改这些页面，所以，花点时间仔细看看它们还是值得的）。在联合身份验证登录的过程中，浏览器就是被重定向到这里的。在已经发布的有关 ADFS 的文档中，我还没有发现“登录服务”这个术语，但只要看一下代码，就能知道这个术语的含义。在 fs 目录下，您将会看到一个名为 FederationServerService.asmx 的文件，这就是作为 ADFS 后端的 Web 服务，技术上也叫做安全令牌服务 (STS)。

之所以将这些分开，是因为前端（登录服务）的主机可以位于外围网络（通常称为 DMZ），而且可以通过位于内部网络的 ASMX Web 服务与联合身份验证服务的后端进行通信。在这种配置下，这个前端也叫做联合身份验证服务代理。

不管您的管理员有没有通过在单独的计算机上使用代理来分割联合身份验证服务，这对您编写应用程序没什么太大的影响，但是，ADFS 本身的设计能够友好地支持 DMZ，了解这一点还是有好处的。

ADFS — 激活您的 Web 应用程序

如果您承担着构建一个支持 ADFS 登录的 Web 应用程序的任务，那么您需要做这样几件事。您需要掌握如何设置 web.config 文件来加载并配置 ADFS Web 代理。图 5 显示的是我在本文示例应用程序中所使用的 web.config 文件。

web.config 文件设置好后，您应能够接受来自 ADFS 帐户合作伙伴的登录。接下来要做的是在声明的基础上制定安全决策。

实际上，ADFS Web 代理分为两种不同的类型。一种是针对 Windows NT^® 令牌应用程序的 Web 代理。这种 Web 代理将为远程用户生成一个真正的 Windows 登录会话。它通过 S4U Kerberos 扩展，从用户主要名称中生成一个登录，我已经在 2003 年 4 月份的“安全概要”专栏中对此做了介绍（如果不是在 Windows Server 2003 本地模式下运行，就会使用一个自定义身份验证数据包）。这种方式的好处在于您可以模拟这个登录，而将身份验证的任务转交给后端现有的安全资源管理器，例如文件系统或者 SQL Server™。（如果这些资源也是远程的，那么您还需要在 Active Directory 中启用协议切换。）而这种方式最大的缺点就在于您必须在自己的域中为每一个来访的用户设置一个用户帐户，这从一开始就削减了使用 ADFS 的优势！（然而，用户不需要知道自己的资源帐户密码，而且他们甚至可能不知道还会为他们设置另一个帐户。）

如果您希望采用联合身份验证，那么您所构建的应用程序就必须支持声明，而且这样一来，您不能依赖于模拟了，因为您不再用 Windows 域帐户来表示帐户合作伙伴的用户。对支持声明的应用程序来说，您将要用到的是 Web 代理，它不会对 Windows 帐户做任何的映射尝试，而是通过 HttpContext.User 将来访的声明传递给您。在本文的示例中，我用的就是这种方法。

编写代码来检查声明其实并不困难。实际上，如果您对组声明的依赖性比较强，那么您根本不需要花很多时间去考虑这些声明。只要继续使用 HttpContext.User.IsInRole 来检查组声明是否存在，将它们当作应用程序角色来对待就可以了。这就是说，您也可以使用像 ASP.NET LoginView 这样的控件，这个控件的输出就是基于通过 HttpContext.User 属性所发现的各个角色。

如果您想读取自定义声明的值，就需要编写几行新代码了。下面这段代码就是要寻找一个名为 Title 的声明：

string GetTitle() 
{
    SingleSignOnIdentity id = (SingleSignOnIdentity)User.Identity;
    SecurityPropertyCollection c =
        id.SecurityPropertyCollection.GetCustomProperties("Title");
    return (1 == c.Count) ? c[0].Value : string.Empty;
}

 

在所传输的数据中，有一部分是很有意思的，这就是在用户本地域对其进行身份验证时所使用的原始方法。实际上，ADFS 支持四种身份验证技术：Windows 集成、SSL 客户端证书、基本身份验证以及 ASP.NET Forms 身份验证。您可以通过 SingleSignOnIdentity 对象的 AuthenticationMethod 属性了解具体使用的是哪一种方法。切记，不要将它与最初的 IIdentity 的 AuthenticationType 属性相混淆；您会发现，这个属性返回的永远是 WebSSO，其基本含义就是由 ADFS 负责登录控制。

其他一些有趣的属性还包括 AuthenticatingAuthority，它返回的是对客户端进行身份验证的帐户合作伙伴的 URI。另外，最好不要忘了添加一个“退出”按钮，这样，您就会发现 SignOutUrl 属性也是很有用的。

本文的示例应用程序用一个表格列出了 SingleSignOnIdentity 的所有公共属性，如图 6 所示。此外，它还列出了安全属性的集合，基本上显示了以原始形式发送的所有声明。当然了，您必须首先设置好 ADFS，然后才能运行这个应用程序。

图 6  应用软件程序样品 (单击该图像获得较小视图)

图 6  应用软件程序样品 (单击该图像获得较大视图)

在实验室里迈出 ADFS 的第一步

如果您想亲身体验 ADFS 的强大功能，那么您需要花点时间来设置一个适当的环境。在构建我的支持声明的 B2B 设置时，我做了一些笔记，而且整理出一个非常快捷的途径，用一组（三个）虚拟 PC 镜像来代表帐户合作伙伴，然后用一台客户机代表资源合作伙伴。我已经将这些笔记上传到了我的维基百科。有些笔记可能看起来比较简略，但只要你用过虚拟 PC 和 Windows，就会一目了然了。我将指导您设置域并使用 SYSPREP，这对您来说可能还是新玩意儿。您也可以双击页面编辑我的维基百科，请将您的意见添加进来，以便以后的读者能够加以参考；不过，您添加的意见请尽量保持简要，并请遵循我原来笔记的中心思想。

此外，我的维基百科中还有一个示例应用程序，其中包括的配置文件可以供您测试。只要将 default.aspx 和 web.config 文件复制到资源合作伙伴镜像的虚拟目录中即可；接下来，您就应该能够登录到客户机，通过浏览器访问合作伙伴应用程序中的 Web 应用程序并进行登录。