UAA 和 Cloud Foundry 的安全性介绍

    精彩文章,何不与朋友分享

[译注]本文翻译自Cloud Foundry英文博客站点,原文题为“Introducing the UAA and Security for Cloud Foundry”,文章发表时间是 2012 年 07 月 23 日。

Cloud Foundry 是一个分布式系统,具有许多前端和后端组件。如果您比较熟悉 Cloud Foundry 的体系结构,您可能已经注意到云控制器是通过轻量级 HTTP API 来实现其功能的。内部组件也使用相同的方法彼此通信。直到最近,我们才可以使用自定义身份验证机制(存在一些缺陷)来达到上述目的。这篇博客将向您介绍我们在此领域进行的变革。

我们创建了一个新组件来处理所有外部用户面临的安全问题,该组件名为用户帐户和身份验证服务,简称为 UAA。该组件自从 2012 年 3 月就已经在 cloudfoundry.com 上发布,现已开始在 Cloud Foundry 用户与平台之间的交互中发挥重要作用。本文将介绍 UAA 的基本功能以及它对于 Cloud Foundry 的用户和管理员所发挥的作用。

UAA 的设计目标

  • Web 应用程序需要能够对用户进行身份验证并代表用户访问平台资源,而不收集用户凭据。(我们关注过多个收集用户凭据的应用程序,但 UAA 出现后,我们便无法找到其他替代了。)
  • 系统需要具有扩展能力,平台和用户会添加更多的组件(例如,为现有应用程序或者部署新应用程序或服务提供管理用户界面)。
  • 应为平台上所有面向用户的应用程序提供单点登录 (SSO)。
  • 应为平台 API 用户提供跨平台和多语言编程支持。
  • 应能够方便地为各种社会部署(例如,通过 GitHub 登录)和企业部署(例如,企业 AD)制订身份验证机制的策略。

在实现过程中,需要谨慎对待安全性问题。要确保您的基础已受保护并让用户确信其数据安全性的一种方法是使用标准协议和接口,因为它们已得到许多安全工程师的修正并通过了大量审核人员的审核。开放标准往往会有大量的用户参与客户端库和实用程序的实现和及文档编制,因此会很容易为大范围的用户提供支持。基于这个原因,我们选择在 UAA 中使用某些最新最好的开放标准,其中最重要的一个就是 OAuth2。另外还值得一提的是 SCIMOpenID Connect(后者的规范尚未稳定,因此我们还没有完全实施)。

OAuth2 简介

OAuth2 是一个为客户端应用程序(通常为 Web 应用程序)提供支持的协议,可以在用户许可的情况下代表用户执行操作。允许客户端执行的操作将在资源服务器(另一 Web 应用程序或 Web 服务)上执行,用户通过告诉授权服务器其信任客户端所要求执行的操作来批准这些操作。如果授权服务器允许,客户端也可以以自身名义执行操作(而不是代表用户)。

Cloud Foundry UAA 是一个授权服务器,也是一个资源服务器(例如,对于与用户帐户有关的资源)。Cloud Foundry 中的另一资源服务器是云控制器,这是用于管理用户应用程序和服务的主要接口。下文会对授权及授权流程(包括时序图)进行更为详细的说明。

UAA 快速入门

要想查看实际运行中的 UAA,最快的方式是通过浏览器访问 http://uaa.cloudfoundry.com。如果您拥有 Cloud Foundry 帐户,即可登录并看到基本主页,从而确认您已通过身份验证。单击右上角的链接即可退出。

您也可以使用命令行询问 UAA 正在执行的操作:

$ curl -H "Accept:application/json" uaa.cloudfoundry.com/login { "timestamp":"2012-06-21T10:52:35-0700", "commit_id":"b19eb89", "prompts":{"username":["text","Username"], "password":["password","Password"] } }

响应会告诉您 UAA 的构建时间、来自 GitHub 的 git 提交 ID 以及对用户执行身份验证所需的登录端点信息。

代码还可以通过其默认配置部署为名为 devuaa 的 Cloud Foundry 应用程序:http://devuaa.cloudfoundry.com。如果您不想自己亲自部署,可以使用此部署进行测试。UAA 自带一个后端和一个用户帐户(用户名:marissa,密码:koala)。要亲自构建服务器并查看它在本地运行,可以对项目进行克隆并遵照 GitHub 上 README 中的说明操作。

对于希望代表用户执行操作的 Web 应用程序而言,正常流程为授权代码流程。以下是用户通过身份验证后的交互时序图:

时序图,授权代码流程,对于已通过身份验证的用户(步骤 2-4)


UAA 还自带一个名为 app 的 OAuth2 客户端,因此,您可以在浏览器中访问此链接来查看部分 OAuth2 授权代码流程。以 marissa 用户身份登录,您可能会看到用户的批准页面,在此页面中 marissa 需要确认她允许名为“app”的客户端访问她的配置文件数据 (scope=openid)。

您可能不会看到此页面,因为可能已经有人登录此页面,批准访问并获得了访问令牌,因此服务器不需要再次进行提示。访问令牌是对批准的记录,因此如果尚未授予过访问令牌,那么您就看到批准页面。通过按下“授权”(Authorize) 按钮来批准授予权限,您应看到浏览器转至 http://localhost/nolink(有意使用不存在的链接)并带有一个包含授权代码的查询参数。

获取访问令牌是另一个步骤(客户端应用程序通常会执行此步骤),用以交换令牌端点(位于 https://devuaa.cloudfoundry.com/oauth/token)上的访问令牌的授权代码。令牌端点没有用户界面,因此无法在浏览器中看到任何内容,但是如果您访问该位置,系统会提示您输入身份验证详细信息,因为令牌端点使用 HTTP Basic 对客户端应用程序进行身份验证。

大多数人对 Cloud Foundry 使用的命令行客户端为 vmc。由于历史和实际原因,vmc 会在命令行上直接收集用户凭据,因此它不是浏览器流。UAA 在其 /login 端点上公布它所需要的凭据,vmc 收集数据并进行发送,进而获得一个令牌。OAuth2 具有一个本应用于旧版 Cloud Foundry 的资源所有者密码授权类型,但对于将来的使用存在过多的限制,因为它被限定为采用用户名-密码身份验证方式。作为替代,我们使用了包含多项增强的隐式流。下图是它的工作方式:

时序图,vmc 隐式流:


有关 UAA 1.0 版所有功能的详细说明,请参阅 UAA 参考博文

登录服务器

UAA 可以并确实处理具有 Cloud Foundry 帐户的用户身份验证。它只知道如何执行用户名-密码身份验证,并只适用于已注册用户,这对于基本用户情况是没问题的,例如,对于习惯于使用密码进行登录的 vmc 用户。对于其他情况,例如,要允许用户使用社交网络帐户进行身份验证,或者使用外部身份提供程序(如 VMware Horizon)或企业目录,您有两个选择。1) 采用 UAA,修改身份验证过滤器和登录用户界面。或者 2) 部署另一个可以处理身份验证的组件并将其他一切委派给 UAA 处理。我们将 2) 称为登录服务器,这是我们即将在 cloudfoundry.com 中采用的一种设计。UAA 的示例目录中提供了两个示例应用程序(一个 Java 示例,一个 Ruby 示例),它们将向您展示如何实现登录服务器。

总结

UAA 可以处理用户在 Cloud Foundry 中所面临的所有安全问题,并为平台中的其他组件提供了一些后端服务,其中的一些可以由用户自己的应用程序使用。UAA 的主要作用是充当 OAuth2 授权服务器,但它提供的许多其他服务是与用户帐户和客户端注册相关的。我们将在 cloudfoundry.orgcloudfoundry.com 博客站点上发布更多包含详细示例的文章来说明如何使用 UAA。UAA 所支持的服务范围及其已注册的客户端也一直在扩展,因此请关注有关各种新功能的博文。

    精彩文章,何不与朋友分享

发表评论

电子邮件地址不会被公开。 必填项已用 * 标注

您可以使用这些 HTML 标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" cssfile="">