Azure Insider

项目
01/29/2015

BYOD 挑战：将移动设备连接到企业

Bruno Terkaly 企业环境中的自带设备办公 (BYOD) 运动以及 Azure 移动服务如何帮助开发人员依然存在很多问题。移动服务的核心价值在于，移动服务可分摊标识，降低成本和精力，以提供对受保护企业资源的安全访问。在本文中，我们将进一步了解在将移动应用程序连接到企业资源时，将采用什么措施来支持更加复杂的方案。

我们首先定义标识利益干系人，并了解员工、贸易合作伙伴和客户的异同点。我们还会介绍软件体系结构，用来为访问本地服务和站点的浏览器和移动设备用户提供安全连接。本文稍后将演示一些使用连接到移动服务后端以及本地服务终结点的 iOS 应用的技术。

并不是所有的访问都是平等的

这一工作有几个重要的目标。第一个目标是通过最少的自定义代码或基础设施更改（包括现有网络配置）提供对本地资源的访问。另一个目标是管理这些使用情境，以在其变得敏捷和灵活时，确保其可控性和可见性。

并不是创建的所有需要在企业防火墙后访问的用户都是平等的。同样，并不是企业防火墙后的所有数据都需要相同级别的保护。一些员工需要有更多权限访问受保护信息。诸如现场销售人员的员工需要访问有关产品价格和库存级别的最新信息的权限。他们甚至还需要访问有关其客户的会计系统数据（如帐户最近付款）的权限。但他们可能并不需要访问人力资源应用程序的权限。

贸易合作伙伴有自己的专门需求。受信任的业务合作伙伴会经常通过外部网来联合标识。贸易合作伙伴通常会管理他们自己的标识基础结构来对用户进行身份验证，并使用“声明”来控制对公司受保护资源的访问。因此，合作伙伴或公司都使用信任策略来将传入声明映射到受保护的资源（如内部 Web 应用程序）所理解的声明。

还有两个不太常见的标识利益干系人。客户通常需要访问其帐户信息（类似于 PayPal 或 Netflix）的权限。目标客户实际上就是潜在客户。他可能已经提供了信用卡信息，但还没有真正购买任何东西。所有这类用户都有一个共同的特点：他们都想自带并使用自己的 iOS、Android 和 Windows Phone 设备在企业工作。

企业安全管理

在企业中，至少五个软件堆栈在保护移动设备安全方面起着重要作用。在本文中，我们将进一步了解混合连接、Azure 服务总线、Azure Active Directory 应用程序代理和 Microsoft Azure API 管理。

要让员工通过 Web UI 向 Active Directory 出示其凭据，获取访问令牌并开始工作比较简单，但标识世界却比较微妙和复杂。“一刀切”的概念简单，但不正确。员工通常被迫使用企业标识提供程序。

大多数企业通常利用主要提供基于 LDAP 的协议的 Active Directory 引入内部标识。在这个移动的、启用了云的新世界中，企业需要适用于移动设备的基于 HTTP 的通信协议。Microsoft 在 Azure 中创建了名为 Azure Active Directory (Azure AD) 的标识系统。Azure AD 的一个主要功能是，企业可以使用目录同步将标识同步到云。请访问 bit.ly/1ztaB9Z，了解这一过程的详细信息。

Azure AD 中还有许多其他不错的功能。Azure AD 提供方便的单一登录 (SSO)。这样，员工可以在一段时间内访问受保护的资源，而无需多次被迫登录并提供凭据。访问令牌以 cookie 方式本地存储在员工设备上。您可以通过使用令牌过期技术来限制访问。

Azure AD 还支持 OAuth 2.0，这可能是最常用的身份验证开放标准。OAuth 2.0 代表资源所有者，为客户端应用程序提供对服务器资源的安全委托访问。使用 OAuth 2.0，Azure AD 可以对用户进行身份验证，并发布 SAML 2.0 或 JWT 令牌。请访问 bit.ly/1pDc0rg，了解令牌工作原理的详细信息。

贸易合作伙伴

公司跨双方 IT 基础结构来管理身份验证的传统方式是通过联合身份验证信任。这包括在两家公司的联合身份验证服务之间建立信任（见图 1）。这支持业务合作伙伴之间的基于 Web 的安全事务。但是，事情并不像听上去那么简单，并且确实是个挑战。

图 1 Active Directory 联合身份验证的传统标识模型

合作伙伴需要在其 Active Directory 和另一家企业的 Active Directory 之间设置信任关系。即让一家公司的员工通过他们自己的 Active Directory 进行身份验证，然后与另一家公司的 Active Directory 交换身份验证令牌，以获取访问另一个网络中的应用的权限。这一方法需要 IT 管理员进行大量的协调和手动工作流。

图 2 描述了一种更现代的标识管理方法。虽然一些标识可能单独位于 Azure 中，但通常情况下，员工标识的副本都托管在 Azure 中。将对这些副本做最少的维护，因为大多数标识的原始副本托管在本地。后台同步进程使标识的云副本完全同步。用户可以直接连接到位于云中的数据中心的 Azure AD，然后重定向到适当的应用程序。

图 2 一种标识管理的现代方法

对于移动应用开发人员，GitHub 上提供了很多库，可以用来利用 Azure AD (bit.ly/1qmeipz)。

Android、iOS、Microsoft .NET Framework、JavaScript、Node.js 等全都受支持。例如，iOS 示例向您展示如何获取交互授权代码来使用工作帐户。您可以将此工作帐户关联到在您的数据中心运行的 Active Directory 服务器或完全在带有 Azure AD 的云中运行的 Active Directory 服务器。在后端，您可以使用基于 REST 的 Node.js API 或 .NET Web API。

客户访问权限

您通常不会想到面向客户的站点和服务拥有访问受保护的公司资源的权限。不过，这比您想象的更常见。例如，Wells Fargo 可能想要通过一个安全的网站或移动应用在 Web 上提供客户财务数据，而 Netflix 可能想要提供对受保护资源（如当前帐户余额或付款历史）的安全访问。这对于使用移动设备的客户而言，变得尤为重要。

在某些情况下，这甚至对利用社交标识提供程序（如 Microsoft 帐户、Facebook、Google 或 Twitter 等）都非常有意义。在 Azure Insider 11 月文章 (msdn.microsoft.com/magazine/dn818496) 中，我们对此方法进行了详细说明，并编写了使用 Twitter 作为标识提供程序的本地 iOS 应用程序。

这里的前提是任何人都可以下载您的应用或访问此网站。有一个公开可用的服务层。目标客户通常未经身份验证，只能看到公开信息。但即使在这种情况下，也可能会有访问本地资源的需求。您的服务可以提供一个未经身份验证的服务层或响应一组默认凭据。

安全连接工具

除标识之外，还有几个工具可以有助于将用户安全地连接到企业网络中的资源。其中一个示例是 Azure 服务总线中继（见图 3），它提供了巧妙的方法以方便地访问受保护的资源。您可以将 Azure 服务总线中继认为是一种云托管服务，充当守卫来代理客户端和企业资源之间的连接。服务总线中继经过身份验证，并只打开出站端口。它还支持主题和队列，因此，您可以实现一种分布式消息。如果需要插入大量事件，您甚至可以合并事件中心。

图 3 Azure 服务总线中继

这种方法的优点在于，不需要对本地网络进行配置更改。这包括配置用户或更改防火墙设置，因为客户端和后端服务都使用出站连接来连接到端口 80 或 443。换言之，无需针对传入通信打开其他端口，也不需要代理。

应用程序代理方法

使受保护的资源在防火墙外可用的第二个方法是使用目前为预览版的 Azure AD 应用程序代理服务。该服务通过 HTTP 和 HTTPS Web 协议，提供对组织内部 Web 应用和服务的安全访问。

此方法的最大优点在于，用户可以享受 SSO 和本机应用程序体验，同时仍使用非托管、未加入域的设备。在之前的文章中，我们讨论了“工作空间加入”的概念，即完全加入域的设备的轻量版本 (bit.ly/1tE7dRR)。它支持用户希望保留对他们个人设备控制的那些 BYOD 的情况。

Azure AD 应用程序代理提供与 Azure AD、支持 SSO、软件即服务、本地应用程序、多重身份验证和设备注册的紧密集成。此连接器将资源桥接到应用程序代理以及移动应用程序。这些连接器主要路由通信并支持冗余、扩展和多个站点。

应用程序代理有几个优势。首先，您可以实现对应用程序、设备、用户和位置级别的精细控制。现有客户端应用不需要修改，设备本身也不需要修改。它还支持多重身份验证 (MFA)，这一验证可以对高度机密资源提供额外级别的保护。MFA 提供多个支持服务，如诈骗警告、IP 白名单以及移动电话或 SMS 作为第二个身份验证因素。

应用程序代理的第三个优点在于，它提供蜂窝网络和本地网络之间的隔离功能。从不直接公开后端服务，因为应用程序代理本身包含在 Azure AD 中，而连接器直接从受保护的资源进行访问。最后，应用程序代理可防止拒绝服务攻击，以让您对限制、队列和会话管理进行控制。

API 管理

提供对受保护资源的访问的第三种方法是 Azure API 管理，它也充当本地资源的代理。通过该方法，可将在您的防火墙内实现的 Web 服务向外界公开。要使这一选择生效，您需要对本地 Web 服务器进行一些修改，同时在 Azure 门户中创建并配置一个 API。您可以使用 .NET Web API 或 Node.js 来编写 API。

首先，我们考虑使用 Azure API 管理进行身份验证，这一基本身份验证用来提供对本地 IIS Web 服务器的外部访问。实现这一情境的第一步是，对您的本地 IIS Web 服务器进行一些更改，并启用基本身份验证。在 IIS 中，您可以选择身份验证图标，深入了解基本身份验证以添加用户。Azure API 管理将使用此用户配置文件访问本地 IIS。

您可以使用 Azure API 管理的下一个方法是共享密钥身份验证。这意味着 API 管理代理需要存储密钥。在尝试连接到本地后端 Web 服务之前，它会将该密钥放置在 HTTP 标头中。因此，后端 Web 服务需要从 HTTP 标头提取密钥并处理身份验证请求，这其实不足为奇。

您可以通过访问 Azure 管理门户，导航到“API 管理”部分，然后从菜单中选择“策略”来实现共享密钥身份验证。在这里，您将添加一个策略，这只是发送到您本地 Web 服务器的一个密钥。您将要添加的策略定义文件是一个 XML 文档。

混合连接

授予访问受保护资源的权限的第四种方法，也可以说是最简单的方式是使用混合连接（见图 4），这是目前为预览版的 Azure BizTalk 服务的一个功能。混合连接将利用服务总线中继技术在本地进程与 Azure Mobile Services 服务或与 Azure Web Sites 站点之间创建简单、安全、高效的连接。您可以使用混合连接来连接任何使用 TCP 或 HTTP 进行连接的本地资源，包括数据库和 ERP 解决方案（例如 SQL、Oracle 和 SAP）。

图 4 Microsoft Azure BizTalk 服务 - 混合连接

对混合连接的要求是，本地进程必须可以通过静态 TCP 端口（如端口 1433 上的 SQL Server）进行访问。您可以使用任何框架（包括 Node.js、Java 或 .NET Framework）来连接到资源。服务总线中继的大多数配置要求是由混合连接提取出来的。不要求更改本地进程的源代码。

要使用混合连接，请在 Azure 管理门户中配置少量元数据。在承载进程的服务器（SQL Server、MySQL、您的 Web 服务等）上安装一个代理。实际上有一个服务总线中继连接使用 SAS 密钥进行身份验证。您可以从门户中分别旋转服务端和客户端密钥。由于它使用服务总线中继，因此不需要传入终结点或代理。

如果您更喜欢简化设置和开发人员工作，混合连接可能就是您的解决方案。更妙的是，因为它可用于 Azure BizTalk 服务的自由层，您可以经济有效地使用它，且只需支付传出带宽的费用。

现在进行演示

正如我们承诺过的，我们将使用本机 iOS 应用加上其 AMS 后端作为平台，来演示本文所述的一些技术。我们将使用混合连接来添加本地 Web 服务和本地 SQL Server。如果对节省空间和利用已有资源感兴趣，请参阅 AMS 团队教程 (bit.ly/1mK1LQF)。在该指南上，您将找到其他教程资源（bit.ly/1vFiPuv 和 bit.ly/1xLWuuF）的分支，用来构建完整的解决方案，这一解决方案包括以下内容：

作为 AMS 服务安装、并使用 Azure AD 租户注册的 Web API 后端
使用相同 Azure AD 租户注册的本机 iOS 应用
Web API 和 AMS 服务之间在租户中的双向链接

有几个步骤涉及在 Azure 管理门户中创建元数据，而其他步骤则涉及使用本机开发工具（Visual Studio、Xcode、Android 等）来创建实际应用。完成后，您应该有一个正常运行的系统，需要您通过输入 Azure AD 凭据进行身份验证进入您的 iOS 应用。然后，系统会让您在待处理数据上执行 CRUD 操作。将图 5 中的代码添加到移动服务代码。

图 5 客户端代码通过混合连接利用受保护的资源

// Use the SQL Server connection
try
{
  SqlConnectionStringBuilder builder = new SqlConnectionStringBuilder();
  builder["Data Source"] = "myserver";
  builder["Integrated Security"] = false;
  builder["Initial Catalog"] = "mydb";
  builder["User ID"] = "greg";
  builder["Password"] = "S3cr3t";
  int count = 0;
  string query = "SELECT COUNT(*) FROM mytable";
  using (SqlConnection conn = new SqlConnection(builder.ConnectionString))
  using (SqlCommand cmd = new SqlCommand(query, conn))
  {
    conn.Open();
    cmd.CommandType = System.Data.CommandType.Text;
    count = Convert.ToInt32(cmd.ExecuteScalar());
  }
  string results = string.Format("Count of records in mytable is {0}", 
    count);
  Services.Log.Info(results);
}
catch (Exception ex)
{
  Services.Log.Error(ex.Message);
}
// Use the Web service connection
try
{
  const string URL = "http://mydevbox:31106/";
  HttpClient client = new HttpClient();
  client.BaseAddress = new Uri(URL);
  client.DefaultRequestHeaders.Accept.Clear();
  client.DefaultRequestHeaders.Accept.Add(
  new MediaTypeWithQualityHeaderValue("application/json"));
  string response = await client.GetStringAsync("api/values/5");
  Services.Log.Info("Accessing the web service succeeded.");
}
catch (Exception ex)
{
  Services.Log.Error(ex.InnerException.Message);
}

在 SQL Server 和 Web 服务（一种简单的模板 Web 服务）寻址的连接信息中，只涉及混合连接的名称。

总结

在 BYOD 的世界中，标识变得越来越重要。为了在工作场所支持移动设备，企业承受着越来越大的压力。我们生活在混合世界的这一事实使情况变得更加复杂。关键资源都位于云和本地。身份验证可能发生在云中或本地，或者同时发生在两者之中。受保护的资源可能包括业务应用、在本地运行的服务或云托管的 Web 服务。既然有这么多变数，您就需要使用多种灵活的方法。

有关这一实现的完整详细信息，请查看 bit.ly/1rVbtCp 上的博客文章《Go Live on Azure》；有关基于 Java 的处理的主题，请参阅 bit.ly/1zW7XpZ。

Greg Oliver 于 2010 年加入 Microsoft Azure ISV 组织。他大部分时间都在帮助公司的迁移计划和实现。最近他在与一家流行的消费类游戏公司合作，帮助他们从有竞争力的云提供商迁移。在加入 Microsoft 之前，他是一家创业公司的技术合作伙伴。

Bruno Terkaly 是 Microsoft 的首席软件工程师，其目标是开发行业领先的跨设备应用程序和服务。他负责从技术支持的角度，在美国以及全世界推动顶级云和移动的机会。他通过在 ISV 评估、开发和部署期间提供结构性指导和深入参与技术问题，帮助合作伙伴将他们的应用程序投向市场。他还与云和移动工程组紧密协作，提供反馈并影响路线图。

衷心感谢以下 Microsoft 技术专家对本文的审阅：Santosh Chandwani