Windows Azure AppFabric

项目
07/13/2015

再叙 Windows Azure AppFabric 访问控制服务

Vittorio Bertocci

如果您要寻找能更轻松地在您的网站和服务中对用户进行身份验证和授权的服务，则应再来关注一下 Windows Azure AppFabric 访问控制服务（简称 ACS），因为现在实现了一些重大更新（在撰写本文的时候）。

允许分属不同组织的用户访问您的应用程序，同时维持较高的安全标准，这样的工作一直以来都颇具挑战性。这个问题在传统上一直与业务和企业方案有关，在这些方案中，用户通常依赖于目录。随着社交网站作为在线活动的重要舞台的兴起，使得人们日益关注如何可以让用户从 Windows Live ID、Facebook、Yahoo 和 Google 这类媒介访问应用程序。

随着开放标准的出现，这种情况有所改观；但是直到今日，要直接在应用程序中实现这些标准并同时处理好所有这些不同实体使用的身份验证协议，仍是一个巨大的挑战。如果要自行完成这些任务，最糟糕的事可能是您始终有忙不完的工作：协议不断演变，新标准不断涌现，而且您经常会被迫恢复并升级那些复杂的、受到加密约束的身份验证代码。

ACS 极大简化了这些难题。简而言之，ACS 可作为您的应用程序与存储您要使用的帐户的用户存储库（标识提供程序，简称 IP）之间的中介。ACS 将负责处理有关将每个 IP 与适当的协议相结合的低层细节，从而使您的应用程序代码不必考虑每个事务类型的细节。ACS 支持很多协议，如 OpenID、OAuth WRAP、OAuth 2.0、WS-Trust 和 WS-Federation。这样，您就可以利用很多 IP。

将您的解决方案中的身份验证（以及某些授权）外包给 ACS 很容易。您只需利用 Windows Identity Foundation (WIF)（一个可通过高级标识和访问功能增强应用程序的 Microsoft .NET Framework 扩展）并完成一个简短的 Visual Studio 向导即可。您通常可以轻易完成此操作而不必编写任何代码！

听起来很难吧？别担心，此问题不只您一个人遇到；因为发生此问题时通常涉及标识和安全，所以解释起来比实际操作要难。让我们选择一个 ACS 的常见用途，即，将您的网站的身份验证外包给多个 Web IP，然后按照必需的步骤进行操作。

将网站的身份验证外包给 ACS

首先选择一个普通的网站，并让用户可以使用 Google 帐户登录。

开始之前，请先确保我们已具有必备软件。以下是所需的软件：

Visual Studio 2010
Windows Identity Foundation Runtime
Windows Identity Foundation SDK 和以下软件之一：Windows 7、Windows Server 2008、Windows Server 2008 R2 或 Windows Vista SP1

尽管不是硬性要求，但在计算机上安装 IIS 还是有帮助的；如果您没有安装 IIS，则需要对演练的各个步骤进行调整。

Visual Studio 无需赘述，但对 WIF（发音为“dub-IF”）略微介绍一下并解释它成为必备软件的原因可能会对您有所帮助。（有关 WIF 的详细解释，请参阅“Programming Windows Identity Foundation”[Microsoft Press, 2010]）。

WIF 是对 .NET Framework 的扩展，提供了一个用于处理身份验证和用户身份的新模型，此模型将应用程序与身份验证执行过程的细节分离开来。传统的身份验证系统（如 ASP.NET 成员提供程序 API）会强制您处理身份验证过程的细节。这要求您使用低级别的 API 来处理低级别构造，如密码和证书等。WIF 提供了便利的抽象功能，使您可以指定外部实体来处理用户身份验证，从而完全改变了这种状况。利用基于表单的身份验证，您可以指定一个给定页面（通常为 login.aspx），在这个页面中，只要调用方尚未进行身份验证，就会重定向请求。利用 WIF，您可以登记每当用户需要进行身份验证时要调用的外部实体（一个 IP）。在设计时选择 IP 的方式以及在运行时使用 IP 的方式需遵循众所周知的协议。WIF 负责发现应使用哪些协议并相应地强制执行通信策略。再次重申，演示操作比解释操作容易得多。

创建初始解决方案

打开 Visual Studio。通过选择“文件”|“新建”|“网站”来创建一个新网站。让我们创建一个新的 ASP.NET 网站，但在此之前，请先确定已将 Web 位置选择为“HTTP”并将 URL 配置为在 IIS 中运行（参见图 1）。这将确保在使用 WIF 工具时可以顺畅运行。如果您的 Web 服务器上提供了 HTTPS，那么最好使用它；虽然本演练并没有严格要求，但我们强烈建议在生产系统上使用它，因为这会减少 WIF 出现警告的次数。

图 1 选择 ASP.NET 网站并使用 HTTP 作为位置

单击 F5 后，您将会看到，您有了一个基本的 ASP.NET 网站；单击“登录”链接后，系统将提示您输入用户名和密码。我们要做出的更改之处就是：不使用用户名和密码，也不直接在网站中处理身份验证，而是使用 WIF 将身份验证外包给 ACS。ACS 将反过来允许我们开放对外部 IP 的访问。

配置 ACS 项目

首先，我们需要在 Windows Azure AppFabric LABS 门户网站中创建一个项目。LABS 门户网站是一个专门设置的、用来允许社区访问早期组件的环境。这里没有与 AppFabric LABS 相关的成本，但也没有服务级别的协议或保证。

打开您的浏览器并转到 portal.appfabriclabs.com。系统将提示您使用 Windows Live ID 进行登录。登录后，您将需要创建新项目，请单击“创建项目”链接。您将必须选择项目名称，请选择适当的名称并单击“确定”。完成后，您将看到活动的项目名称（本例中为“acsdemoproject”），请单击它（参见图 2）。

图 2 在 Windows Azure AppFabric LABS 门户网站中创建项目

在可以将身份验证外包给 ACS 之前，您需要定义一个服务命名空间。应将该服务命名空间看作为您提供一小部分您自己的 AppFabric LABS 环境，而对于 ACS，则应将其看作与应用程序中 ACS 交互时将使用的资源的所有 URI 的唯一组件。该服务命名空间中的所有内容都由您来控制。单击“添加服务命名空间”，指定名称，选择区域（在 LABS 中，您只能选择“美国(南部/中部)”），再单击“创建”。请注意，AppFabric 使用的 URI 在公共 Internet 上可用，并且用以唯一地标识服务，因此您必须选择尚未被他人选用的命名空间。

激活命名空间会花费一点时间，但是一旦激活后，您就可以单击“访问控制”链接来开始为您的网站配置 ACS。

现在您已经进入管理门户网站，可以在此处为您的网站配置 ACS（参见图 3）。

图 3 Windows Azure AppFabric 访问控制服务管理门户网站

单击“管理”按钮以开始操作。该管理门户网站提供了一些引导式步骤来引导您完成开始过程，而这正是我们要做的。

选择所需的标识提供程序

单击“标识提供程序”链接。我们将在此处配置要在您的应用程序中使用的各个社交 IP。默认情况下，Windows Live ID 将显示在列表中；让我们添加对 Google 帐户的支持。

单击“添加标识提供程序”链接，这将会显示提供程序的列表。单击“Google”旁边的“添加”按钮。您可以为 IP 指定自定义图像 URL，但在此示例中无需指定，请继续操作并单击“保存”。这样，我们就添加了 Google 作为已识别的用户身份来源。

让 ACS 识别您的网站

既然已经配置了我们的 IP，就需要为 ACS 提供有关我们的网站的信息。在标识术语中，我们通常将应用程序称为“依赖方”，这表示应用程序依赖一个或多个 IP 来代为处理身份验证。ACS UI 也与此术语保持一致。

单击“依赖方应用程序”URL，然后单击“添加依赖方应用程序”。让我们指定以下信息：

名称：我的网站
领域：https://localhost/Website/
返回 URL：https://localhost/Website/
令牌格式：SAML 2.0
令牌签名：使用服务命名空间证书（典型）

在这里至少要简单介绍一下“令牌格式”（我们将在本文的后面花更多时间讨论这个主题）。令牌是 IP 用来表明已成功进行身份验证操作的项目（通常是 XML 片段或其他序列化格式的项目）。当使用 IP 选择的任何系统进行用户身份验证后，用户的浏览器将重定向至 ACS 并带有一个证明用户已被识别的令牌。使用的令牌格式和协议将根据 IP 确定。ACS 将检查令牌，如果对此满意（稍后将对此进行详细的说明），则会发出它自己的新令牌并将其发送回您的应用程序。您在本步骤中更改的设置将确定您希望 ACS 使用哪个令牌格式传回应用程序。ACS 能够发出三种类型的令牌（SAML2.0、SAML1.1 和 SWT），它们在表达力、安全性、对某些客户端类型的适用性等方面的能力各有千秋。此处请选择 SAML2.0；在这里，细节不是很重要。

领域应该与我们之前创建的网站的 URL 对应，这点很重要。当使用选择的 IP 进行身份验证后，ACS 将使用您在此处指定的 URL 将用户重定向回您的网站。请注意，默认情况下“创建新规则组”将处于选定状态，我们将在下个步骤中利用它。完成操作之后，请单击“保存”以返回管理门户网站。

添加规则

规则是一些很有趣的构造，可用于对用户身份信息进行更细致的控制。但是，为了启用从多个 IP 登录，我们现在要使用的方案不需要显式使用规则。因此，我们会将所有关于规则的说明延后到本文的下个部分中讲述，因为它们在那里才会派上用场。在这里，我们将只采用默认设置。

单击“规则组”链接。您应会看到在我们添加依赖方应用程序时创建的规则组（“我的网站的默认规则组”）。选择此规则组，单击“生成规则”链接，确认已选择 Google 和 Windows Live ID，然后单击“生成”按钮 – 您在本方案中只需对规则执行这些操作就可以了。

收集 WS-Federation 元数据地址

至此，我们已完成了 ACS 的配置。但是，在回到 Visual Studio 之前，让我们从“应用程序集成”页面获取一些信息。单击“应用程序集成”链接并复制“WS-Federation 元数据”URL – 我们要将它与 WIF 结合使用以设置要利用的网站。

简单介绍一下，WS-Federation 元数据文档是计算机可读的、有关 ACS 如何处理身份验证的说明。您的应用程序将需要该文档，以便配置为将身份验证外包给 ACS。

将网站配置为使用 ACS

返回到 Visual Studio 和您的网站。现在我们要利用 WIF 将身份验证外包给 ACS，这将使 Google 帐户能够访问我们的应用程序。在解决方案资源管理器中，右键单击网站项目并选择“添加 STS 引用”。这将启动联合身份验证实用工具向导，该向导会将网站配置为使用 WIF 作为身份验证机制并使用 ACS 作为身份验证机构。STS 是“Security Token Service”（安全令牌服务）的缩写，用于指示能提供请求令牌的入口点的特殊类型的 Web 服务或网页；每个 IP 或令牌颁发者通常使用一个安全令牌服务。

您在大多数时候只需单击“下一步”即可；必须输入信息的步骤非常少。前进到“安全令牌服务”步骤并指定“使用现有 STS”。粘贴从 ACS 门户网站复制的联合身份验证元数据 URL（参见图 4）。

图 4 在 Visual Studio 中启动联合身份验证实用工具向导

对于从此处开始的后续步骤，请保留默认值并单击“下一步”，直至最后选择“完成”。该向导添加所有必需的 WIF 程序集，向您的网站添加某些文件，（最重要的是）使用在进行身份验证时利用 ACS 所必需的信息更新您的 web.config。

测试身份验证流

现在是时候尝试您刚进行了安全加固的网站了！单击 F5。您将立即重定向到“本地域发现”页面，用户可以通过此页面从我们之前在 ACS 管理门户网站中配置的多个 IP 中进行选择（参见图 5）。

图 5**“本地域发现”页面**

在选择“Google”并输入 Google 帐户凭据之后，您将看到要求您允许 ACS 项目访问的审批页面 – 这不是您的网站在请求权限，而是 ACS 在请求权限，了解这点很重要（参见图 6）。

图 6 要求获得从 Google 获取信息的权限的 Windows Azure AppFabric 访问控制服务

在允许 ACS 要求的访问权限之后，您将重定向回该网站（参见图 7）。就是这样 – 您现在登录网站了！

图 7 **成功！**登录到网站

如果您要验证使用 Windows Live ID（命名空间中配置的其他 IP）是否也会获得相同的体验，则只需执行以下操作：关闭浏览器，再次单击 F5，在“本地域发现”页面选取“Windows Live ID”而不选取“Google”。

如果您有任何在网站上启用身份验证协议的经验，就会知道，添加一个 IP 在传统上意味着要学习其协议和 API，编写颇具挑战性的代码，然后进行一遍又一遍的测试，直到能够正常运行。以后每次另外添加一个 IP 都要完成同样的工作，而且通过请求了解正在使用哪个协议也非常麻烦。

在这里，我们事实上不需要做任何这类工作，您可能已注意到，我们连一行代码都没有编写。如果我们要添加额外的标识提供程序，则只需操作 ACS 管理门户网站上的几个屏幕即可，而不会对应用程序本身造成任何影响。如果 IP 改进了它们的协议，则 ACS 会对其代码做出更改以适应新的条件，我们的应用程序甚至会完全不知道已经发生了变化。

ACS：结构和功能

既然已经亲自体验过 ACS 的强大功能，您就可以简单了解一下 ACS 的概念以及它的工作原理了。这里将需要一些理论知识，但您会发现您在演练前面所述的方案时已经了解了大部分需要了解的内容。

ACS 根据基于声明的标识 原则运行。基于声明的标识背后的主要设计理念是，标识事务中的每个实体都扮演着一个或多个规范的角色，这些角色有四种，如下面的简短列表所示：主体、标识提供程序 (IP)、依赖方 (RP) 和联合身份验证提供程序 (FP)。在本演练中，您已经看到了所有这些角色的运转。这些实体之间的交互可归结为请求、获取和转发安全令牌，如图 8 所示。

图 8 请求、获取和转发安全令牌

主体是由用户扮演的角色，也就是需要进行身份验证的实体。IP 是一个实体，用于存储主体的帐户：用户名、凭据和特性等。IP 使用一个或多个 STS 来公开其身份验证功能和颁发令牌。RP 是主体要使用的应用程序。这三个角色对于描述最基本的情况已经足够了：主体从 RP 信任的 IP 处获取一个令牌，然后将该令牌用于 RP，从而完成身份验证。

我们在演练过程中有件事没有说明，那就是令牌不只用于表示身份验证操作的成功结果，还用于传输描述用户的以下特性：名称、电子邮件地址角色和 RP 需要了解且由 IP 提供的任何其他内容。如果您回想一下签名安全令牌的属性，就会明白这些特性为何无法篡改，以及它们如何通过加密确保来自特定的 IP。这意味着，一个 RP 可以根据对生成它收到的特性的 IP 的信任度来确定这些特性是否有效。想像一下在现实生活中您需要证明某些事情的情况 – 例如，您实际上住在某个地址。公司经常要您提供公共事业帐单，主要是因为他们对公共事业公司的信任度比对您的信任度更高。尽管信息是一样的（地址），但生成此信息的 IP 就使情况完全不一样了。

当某个特性作为安全令牌的一部分发出时，我们将该特性称为声明。这个概念非常重要，它为整个方法提供了名称，而 ACS 所做的每件事几乎都是围绕声明展开的。我们先要了解另一个概念，然后再深入讨论一下相关细节。

尽管您可以用主体-RP-IP 角色为每个系统建模，但这种方法在实际操作中并不是十分方便。如果一个 RP 信任多个 IP（正如我们方案中的情况），模型就会要求 RP 维持多个关系并处理不同的协议，等等。第四个角色 FP 在这里就派上用场了。FP 是一个或多个 RP 与一个或多个 IP 之间的中介，如图 9 所示。

图 9 作为中介的联合身份验证提供程序

FP 信任多个 IP，它的行为方式与应用程序一样，期望获得由 IP 生成的令牌。反过来，RP 也信任 FP，目的是让 FP 公开自己的 STS（用于为 RP 颁发令牌）。FP 负责处理使用各个 IP 的细节，同时始终对 RP 显示相同的外观，所以可以对 IP 进行配置和解除配置而不会影响 RP。FP 也可以将来自不同 IP 的声明转换为对 RP 更有用的声明。它可以规范化不同的传入声明类型和额外声明（如角色或权限）等。

正如您猜想的那样，ACS 扮演着 FP 的角色，如图 10 所示。

图 10 扮演联合身份验证提供程序角色的 Windows Azure AppFabric 访问控制服务

当您创建服务命名空间之后，可以在云中获取完全属于自己的功能完备的 FP。该 FP 在预设模式下包括四个不同的 STS 端点，这些端点全都提供适用于不同应用程序类型的不同协议：WS-Federation 用于登录到网站；WS-Trust 用于调用 SOAP Web 服务；OAuth WRAP 和 OAuth 2 用于 REST Web 服务；Web API 用于一般情况。这些都是用来将您的应用程序配置为将身份验证外包的端点。

正如我们看到的，ACS 已预配置为信任各个 Web IP，它还通过为这些 IP 提供页面或可嵌入代码来改善在这些 IP 中进行选择的体验。除此之外，ACS 还能用于与商用 IP（如 Active Directory Federation Services 2.0 (AD FS 2.0)）建立信任关系，这些 IP 会公开 STS 端点本身。在实际操作中，ACS 会公开您在将网站配置为信任 ACS 时已看到的“添加 STS 引用”功能的对应功能。将 AD FS 2.0 用作 IP 的做法非常有用，因为它允许您在需要时重用用户帐户，包括 Windows Azure 托管应用程序中的帐户（这些帐户传统上只在内部部署中有效）。商用 IP 还有另一个有用的功能，那就是它们通常会提供大量声明集，在令牌处理过程中可以使用这些声明集来添加复杂的身份驱动逻辑。

ACS 允许您以规则的形式描述声明转换逻辑，这是一个简单但又功能强大的机制。例如，您可以为客户分配一个角色，方法很简单，只需在“如果传入名称标识符声明具有值 X，请添加类型角色的输出声明和值 Y。”行中输入相应内容即可。

此处讨论的所有功能都可以通过您在本演练中使用的管理门户网站访问；或者，也可以利用基于 OData 的管理服务访问，该服务可在与现有流程集成的同时完全控制 ACS 设置。

我想多说一句，我们这里只是介绍了 ACS 功能的一些皮毛。我们欢迎您查看身份标识开发人员培训工具包和 Windows Azure 平台培训工具包中的动手实验室，以便更深入地探讨了解方案。如果您要为网站、Web 服务或 Web API 简化访问管理，那么 ACS 就能助您一臂之力！

Vittorio Bertocci* 是开发人员和平台推广团队的架构推广人员，还是扩大的工程团队（负责生产基于 Microsoft 声明的平台的组件）的成员。他负责 .NET 开发人员社区的标识推广以及身份标识开发人员培训工具包和第 9 频道的“IdElement 秀”节目等方案的实施。他最近撰写了“Programming Windows Identity Foundation”(Microsoft Press, 2010) 一书。*

Wade Wegner* 是 Microsoft 的高级技术推广人员，负责影响和推动 Microsoft 对于 Windows Azure 平台的技术策略。您可以通过他在 wadewegner.com 上的博客或在 twitter.com/WadeWegner 上的 Twitter 与他联系。*

*衷心感谢以下技术专家对本文的审阅：*Kent Brown