Windows Azure 安全最佳实践 - 第 6 部分：Azure 服务如何扩展应用程序安全性
多种 Windows Azure服务可以帮助您将应用程序安全性扩展到云。
有三种服务可提供多个提供程序之间的身份标识映射、内部部署数据中心间的连接和相互发送消息的应用程序功能（无论应用程序位于何处）。
· 使用Windows Azure Active Directory，您可以通过位于云中的应用程序的代理身份验证在应用程序上创建单点登录应用程序。使用访问控制服务功能，您可以将来自多个提供程序的标识映射到应用程序可以识别的claims。
· 通过Service Bus，您可以使用安全消息传递和中继功能启用松散耦合的分布式应用程序。
Windows Azure Active Directory
Windows Azure Active Directory是一种云服务，可对 Windows Azure 和 Microsoft Office 365上的应用程序提供身份认证和访问功能。Windows Azure Active Directory是一种多租户云服务，Microsoft Office 365依赖于其身份验证基础结构。
Windows Azure Active Directory利用被公认具备企业级质量的 Active Directory的功能，因此您可以轻松将应用程序迁移到云中。您可以使用访问控制服务 (ACS)（Windows Azure Active Directory的一项功能）启用单点登录、安全增强型应用程序以及与现有 Active Directory部署的简单互操作性。
访问控制服务
访问控制服务 (ACS)允许您将点登录 (SSO) 和集中授权集成到 Web应用程序中。它适用于大多数现代化平台，并与 Web和企业身份提供程序相集成。
ACS 是一种基于云的服务，它提供了对用户进行身份验证和授权以获取 Web应用程序和服务的访问权限的一种简单方式，以及将身份验证和授权从代码中分离出来的功能。您可以让 ACS安排用户的身份验证和大部分授权，而不必使用特定于应用程序的用户帐户实施身份验证系统。ACS可以集成基于标准的身份提供程序，包括企业目录（如 Active Directory）以及 Web身份标识提供商（如 Windows Live ID、Google、Yahoo!和 Facebook）。
访问控制服务是为使用claim的应用程序制定单点登录策略的一个关键部分。
使用 ACS，可以制定授权决策从应用程序中牵引出来,转变为一组声明性规则，以便将传入的安全claim转换为应用程序和服务可以识别的claim。通过使用简单、熟悉的编程模型定义这些规则，使其代码更为清晰。
在上图显示的方案中，最终用户使用浏览器访问应用程序。浏览器接受多个身份提供程序的凭据 -用户可以使用 Windows Live ID、Google、Yahoo!、Facebook或客户的 Active Directory登录应用程序。从身份提供程序获取token后，ACS将使用您提供的规则转换token。例如，身份提供程序可以传递电子邮件给ACS，您可以将token中的电子邮件更改为名为“electronicmail”的claim（如果需要）。
应用程序依靠 ACS来以应用程序可识别的方式提供claim。
下图显示了 Web应用程序各部分间的步骤。Web服务应用程序与此类似。
您的应用程序将显示为RelyingParty。
ACS 可兼容大多数常用的编程和运行时环境，并支持多个协议，包括 Open Authorization (OAuth)、OpenID、WS-Federation和 WS-Trust。
ACS 中提供以下功能：
· 与 Windows Identity Foundation (WIF)集成
· 对常用 Web身份提供程序（包括Windows Live ID、Google、Yahoo和 Facebook）的自带支持
· 对 Active Directory Federation Services (AD FS) 2.0的自带支持
· 支持 OAuth 2.0、WS-Trust和 WS-Federation协议
· 支持 SAML 1.1、SAML 2.0和Simple Web Token (SWT)这些token格式
· 允许用户选择其身份提供程序的可自定义的集成 Home Realm Discovery
· 基于 Open Data Protocol (OData)的管理服务，可提供对 ACS配置的编程访问
· 允许对 ACS配置进行管理访问的基于浏览器的管理门户
ACS 可以兼容几乎所有现代 Web平台，包括 .NET、PHP、Python、Java和 Ruby。
访问控制服务入门
访问控制服务2.0 示例和文档曾经可通过包含 ACS 2.0 生产版本的代码示例和文档的 CodePlex项目获取, 现在可以直接通过MSDN访问。
Service Bus
Service Bus 提供安全消息传递和中继功能，以便在云中构建松散耦合的分布式应用程序。这些消息传递方案可用于保护在云中客户端连接到内部部署中运行的应用程序，也可支持 Windows Azure上的端点。
中继和Brokered消息传递。中继服务可提供多种不同的中继连接选项，甚至可在可能时帮助协商直接连接。中继服务支持传统单向消息传递、请求/响应消息传递和P2P消息传递。它还支持整个 Internet 范围内的事件分发，并提供发布/订阅方案和双向 socket通信来提高点对点效率。不同于中继消息传递方案，brokered消息传递可视为异步，或“暂时分离”。生产者（发送者）和消费者（接收者）无需同时在线。
2011 年 9月引入的新功能支持队列、主题、订阅等功能，改进了发布/订阅消息传递，从而增强了 Service Bus。此版本在 Windows Azure平台上还支持以下新方案：
· 异步云事件 -将事件通知分发到偶然连接的客户端（例如，电话、远程 worker、网亭等）
· 事件驱动的面向服务的体系结构 (SOA) -构建可随时间轻松演变的松散耦合系统
· 高级应用程序内部消息传递 -负载水平调整和负载平衡，用于构建高可伸缩性和高弹性的应用程序。
Service Bus 中继消息传递
假设您在内部部署客户数据中心内（或在私有云中）运行应用程序。您可以向用户暴露应用程序而不将其暴露在云中。云中运行的集中“中继”服务支持多种不同的传输协议和 Web 服务标准，包括SOAP、WS-*和 REST。
使用Service Bus 中继消息传递，您可以创建一个基本 Windows Communication Foundation (WCF) 服务应用程序和一个 WCF客户端应用程序。前者配置为向 Service Bus注册发布端点，后者则通过 Service Bus端点进行调用。主机和客户端应用程序均在 Windows Server或台式计算机上执行（即，它们未托管在 Windows Azure上），并使用常见标准协议和安全措施来访问 Service Bus。
有关介绍如何构建使用 Service Bus“中继”消息传递功能的应用程序的教程，请参见Service Bus 中继消息传递教程。
Service Bus Brokered消息传递
Service Bus Brokered消息传递功能可视为异步或分离的消息传递功能，通过 Service Bus 消息传递基础结构为发布-订阅、暂时分离和负载平衡方案提供支持。解耦的通信具有众多优势，例如，可根据需要连接客户端和服务器，并以异步方式执行操作。
有关如何在 .NET中或使用 REST 实施brokered消息传递的教程，请参见Service Bus brokered消息传递教程。
Service Bus 入门
请参见：
下一篇文章
Windows Azure 安全最佳实践 - 第 7 部分：提示、工具和编码最佳实践。我总结了很多最佳实践。因此，我介绍了在保护您的Windows Azure应用程序时需要考虑的更多事项。
以下是本系列中的文章的链接：
· Windows Azure 安全最佳实践 - 第 1 部分：深度解析挑战防御对策 。
· Windows Azure 安全最佳实践 - 第 2 部分：Azure 提供哪些现成可用的安全机制。
· Windows Azure 安全最佳实践 - 第 3 部分：确定安全框架。
· Windows Azure 安全最佳实践 - 第 4 部分：需要采取的其他措施。
· Windows Azure 安全最佳实践 - 第 5 部分：基于Claims的标识，单点登录。
· Windows Azure 安全最佳实践 - 第 7 部分：提示、工具和编码最佳实践。
本文翻译自：
