内容


通过 IBM WebSphere DataPower SOA Appliances 确保对企业应用程序的安全移动访问

将安全性扩展到 Worklight 应用程序和最广泛的移动设备 API

Comments

引言

向企业应用程序引入移动设备访问意味着灵活的 IT 安全方法比以往任何时候都更重要。过去,公司假设人们使用企业办公室中的 Web 浏览器来访问其系统。随着越来越多的人开始使用 BYOD(个人自带设备)移动访问,安全功能也越来越多样化,此时,安全问题成为了人们最关心的问题。由于安全组件本身非常复杂,所以人们主要关心这些组件是否易于使用。此外,利用公司在 Web 和安全基础结构方面的投资来集成所有解决方案也非常重要。新组件应为未来技术提供了灵活性(这是事物发展的必然趋势),这一定也非常重要。最后,该解决方案应该尽可能完整,避免提供一个支离破碎的方法。

所有这些都表明,安全方法必须非常灵活、有效、易于维护、可重复使用、可补充现有模式并提供尽可能完整的方法。

本文介绍:

  • IBM WebSphere DataPower Integration Appliance XI52 如何在利用现有投资的同时扩展您的安全基础结构。
  • DataPower 设备如何与现有的基础结构和新的基础结构(包括 IBM Worklight® V5)结合工作,以便支持最广泛的移动设备 API,包括各种安全令牌支持。
  • 如何使用浏览器检测的常用技术快速设置 “移动 DMZ”,从而实现集成的单一登录 (SSO) 环境,其中包含 DataPower 多协议网关以及 Web 应用程序防火墙。

样例解决方案

此处所示的示例中所使用的特定版本的服务器和软件包括 IBM WebSphere DataPower Integration Appliance XI52 V5,并且与 IBM WebSphere Application Server V7 上部署的 IBM Worklight V5.0.5 相集成。LTPA 令牌为 SSO 提供了安全性。样例环境同时使用了提供的 DataPower 功能和一些自定义的 XSLT 脚本。随 IBM Rational® Software Architect V8.5.1 一起安装的 Worklight Studio V5.0.5 用于构造模拟的移动设备和 XSLT 编辑。最终结果会检测 HTTP 标头的移动浏览器,将结果重定向到 DataPower 机器上的 Web 应用程序防火墙服务,然后将 LTPA 令牌和请求一起转发给配置为 WebSphere Application Server 安全域一部分的测试 Worklight 服务器。

此概述是在架构级别上提供的,不依赖于具体的技术。要实现本示例,需要访问 DataPower 设备、Worklight Studio V5.0.5 以及配置了 Worklight 的 WebSphere Application Server。您可以使用基于 Eclipse 的工具(如 IBM Rational Application Developer)来试用这些概念。如果想进行任何修改,则需要对 XML 和 XSLT 有基本的了解。

企业面临的全新的移动挑战

传统企业在不断发展变化。过去,可以根据位置(如企业办公室)和设备(如特殊的浏览器供应商)对关键的企业内部应用程序的访问进行标准化,并确保安全性。如今,越来越多的聪明的员工开始将工作活动与个人活动结合在一起,并使用移动设备实现此操作。为了支持这一需求,企业正在通过将关键的企业内部应用程序展现给外部可用的网站和设备来应对这种变化。

任何支持移动需求都需要通过大量强大的策略来提供支持。企业需要考虑支持哪些 BYOD 设备,以及哪些员工角色能够使用这些设备。企业需要考虑移动支持如何补充现有服务。此外,企业还应该考虑这种支持影响将来开发企业内部应用程序的方式。所有基于 Web 的应用程序都应该坚持在移动友好的标准和平台(如 HTML5、Dojo 以及支持 JSON 的接口)上进行开发。

从观念上讲,企业不想失去在现有 IT 支持计划中的价值。幸运的是,DataPower 设备和 Worklight 只占用少量内存,就可以在仍然使用很多现有资产以及基础架构的同时引入对移动设备的支持。由于安全极为重要,因此应该将 DataPower 部署在 DMZ 中。这样做可确保使用适当的防火墙、代理或者虚拟专用网 (VPN) 实现从该 DMZ 到后端组件的连接。

安全框架考虑事项

本文不包含企业移动解决方案应该考虑的所有架构考虑事项。您需要与您的 IT 团队以及业务流程所有者协调工作,共同提供最适合您企业的策略。这样做的时候,需要了解企业针对各种移动用户类型的策略和要求:客户、企业合作伙伴以及打算使用移动设备工作的员工。下面是在您企业的总体移动架构策略中需要考虑的几个方面:

  1. 解决方案管理涉及您企业将要应用和实施的策略,例如:
    • 设备使用:限制用于访问应用程序的设备的共享。
    • 数据策略:确定所显示的数据是否进行了适当的分类,可显示在可能的公共领域内。
    • 更新:如何打补丁,并对其他软件进行更新。
    • 用户注册和身份管理:员工、业务合作伙伴以及客户如何通过注册来访问和执行管理任务,如重置密码。
  2. 特定于安全的考虑事项包括:
    • 加密:除了考虑传输的 SSL 支持之外,还需要考虑其他一些事项。考虑是否需要确保与呼叫传输(如移动设备内存)没有直接关联的事项的安全性,包括数据卡(例如,SD 卡)。
    • 软件安全性:哪些内容将要用于恶意软件和病毒检测,以及您是否关心违规设备。
    • 防火墙和 VPN(虚拟专用网):如何通过适度使用防火墙、VPN 隧道以及代理来限制网络曝光和可访问性。
    • 物理安全:当设备被盗时会发生什么情况?

IBM 移动设备解决方案

IBM 通过添加 IBM Mobile Foundation 解决了移动设备的需求,其中包括用于各种云集成的 IBM WebSphere Cast Iron®,用于策略、数据以及端点安全的 IBM Endpoint Manager,以及用于多平台设备支持的 IBM Worklight。使用这些组件,无论使用何种类型的设备,您都可以快速扩展您的功能,使之能够用于移动设备。需要注意的一个特殊功能是 Worklight Server,它可以安装在 WebSphere Application Server 的顶部,用于扩展 WebSphere Application Server 的安全性和功能,以便提供移动设备支持。

移动设备和 DataPower

本文的其余部分将重点介绍如何快速扩展 IBM Web 托管基础架构(包括 IBM Mobile Foundation的功能),以便包含用作移动世界入口的 DataPower 设备。

将 DataPower 设备用作 DMZ 计算机的原因有很多种:

  • 作为一个硬化的、为特定用途而建造的设备,可以用它来抵制黑客攻击。DataPower 的防火墙功能有助于保护后端服务器,防止企业外部的客户端直接访问这些服务器,包括防止 SQL 注入、计算机病毒以及跨站点脚本等事项。
  • DataPower 还支持多个安全令牌和 SSL(将在后面部分详细讨论),同时提供了对 DataPower 设备自身表单和其他用户验证页面的支持。它与 LDAP 服务器相集成,是身份验证、授权和记账 (AAA) 功能的一部分。
  • 而且,通过这一广泛的支持,您还可以将令牌支持扩展为使用 DataPower 作为智能身份管理器的一个安全令牌服务客户端(如 IBM Tivoli® Federated Identity Manager),为您生成和转换自定义令牌。

这是加载到一个设备中的很多安全功能,并且它还能够与现有安全基础架构完美集成。

起点参考架构

图 1 中所示的参考基础架构就是这个讨论的起点。您的配置可能会在细节方面有所不同,但此处所示的方法是一个常用方法。引入这部分新内容之前,让我们看一看旧方法的工作原理。

图 1. 参考企业级 Web 架构
图 1.  参考企业级 Web 架构
图 1. 参考企业级 Web 架构

下面是关键部分的简要概述:

  • 负载平衡器:负载平衡器(如 IBM WebSphere Edge Server)或硬件设备(通常称为 IP Sprayer)用来平衡集群之间的通信。DataPower 设备具有应用程序优化 (AO) 功能,还具有在设备之间自我平衡的功能,能够对后端应用服务器执行智能负载平衡。
  • 反向代理或 Web 服务器:这包括 IBM Security Access Manager WebSEAL、IBM HTTP Server 或 Apache 或者现有的 DataPower 实例等事项。这是 “首触 (first touch)” 实施安全策略。可以将该策略用作运行时强制企业策略,如 “三击” 规则(如果三次身份验证尝试失败,那么您会在一段时间内被锁定),并在公用 Internet 和专用 Intranet 之间建立一道防火墙。
  • 策略服务器:例如 IBM Security Access Manager,它提供了企业范围的策略管理点,并与反向代理相集成。
  • 应用服务器:WebSphere Application Server 内置了一些关键应用程序。它的全球安全功能可让您方便地访问和联合多种安全存储,包括 LDAP(轻型目录访问协议)服务器和令牌生成。这也是安全令牌服务和 Worklight 服务器的基本安装。
  • 安全令牌:当用户要访问的系统对用户进行身份验证时,访问这些系统的授权是由安全令牌掌控的。例如,安全令牌类型包括 IBM 的 Lightweight Third Party Authentication (LTPA) 令牌和 Security Access Markup Language (SAML)。安全令牌在基础架构的软件组件中传递,以传递用于访问系统的身份验证信息。
  • 安全令牌服务:一个良好的示例就是 IBM Tivoli Federated Identity Manager (TFIM)。它提供安全令牌转换功能(例如,在 LTPA 和 SAML 之间)。
  • 安全注册:在大型企业中,安全注册通常通过 LDAP 来完成。一个良好的示例就是 IBM Tivoli Directory Service,它为您的用户管理安全架构。

移动设备 DMZ 实现

跟随图 2 中的放大镜看一看,如何将现有 DMZ 很好地扩展成为移动设备 DMZ。我们将使用 DataPower 的 XML 防火墙功能将内部通信与外部通信分离,并且还会使用 Worklight 来处理移动设备中特定于设备的 API。

图 2. 移动设备 DMZ 的参考架构
图 2. 移动设备 DMZ 的参考架构
图 2. 移动设备 DMZ 的参考架构
图 3. 移动设备 DMZ 的细节
图 3.  移动设备 DMZ 的细节
图 3. 移动设备 DMZ 的细节

图 3 中的隔离 DMZ 表明样例移动设备 DMZ 将包含一个具有三个角色的 DataPower 计算机:

  • 用于路由的多协议网关
  • 使用其身份验证、授权和审核功能的反向代理
  • 防范威胁,如计算机病毒、SQL 注入、 URL 扫描等。

图 3 表明非移动设备通信也可以定向到反向代理服务器群集,但不需要这样做。DataPower 的内在能力和高可用性可集合所有通信,将适当类别的通信定向到适当的服务器。

可以在同一台计算机上执行分配给 DataPower 的这些角色:

  • 首先,将它用作反向代理,ISAM WebSEAL 在参考架构中具有同一作用。在传递给任何后端服务器之前,用户必须针对 DataPower 设备进行身份验证。
  • 其次,它是请求的路由服务器。它会查看 HTTP 标头并相应地转发该请求。

对于威胁防护,可以使用 DataPower 的 Web 应用程序防火墙,因为它包含很多威胁防护功能并且很容易配置。

其中一个关键因素就是 DataPower 可以生成 SSO 域 cookie,该 cookie 能够让请求围绕基础架构进行。这是确保安全集成的一个重要部分。这样做的原因有两个:

  • 使用它作为用于防火墙控制的 DMZ 计算机。
  • 使用它作为安全服务器。它还是具有高度可用性的安全设备,因此在这个 DMZ 角色中非常适合。

概念验证环境

本样例的关键是 DataPower 设备如何对用户进行身份验证、路由与非移动设备通信分离的移动设备通信并生成一个支持 SSO 的 LTPA 安全令牌。在这种情况下,我们将在路由请求的同时明确表明支持 Worklight 的应用服务器可以接受从 DataPower 生成的 LTPA 令牌,从而提供对安全的移动应用程序的访问。

为了说明这种情况,我们尽可能地将少量内存占用放在一起,同时仍然展示不平凡的互动。此概念验证示例并未涉及作为 Worklight 一部分提供的所有高级安全功能,只是展示了作为移动浏览器一部分的高级令牌友好应用程序。还有其他一些功能,您应该对它们是否适用于生产环境进行认真考虑;例如,DataPower 与 Tivoli Federated Identity Manager 全新集成,该工具在生成和使用安全令牌方面表现出色。不过,本示例涉及高级安全性并验证了这些概念。

要构建此概念验证,您需要安装以下组件:

  • Web 浏览器

    此处使用具有用于修改插件的 HTTP 代理的 Web 浏览器来模拟移动设备通信。DataPower 脚本通过识别插件发送的用户代理流来检测移动设备。针对此 Web 浏览器的一些建议包括:

    • User Agent Switcher for Firefox
    • Cookie+ manager for Firefox
    • 通过连接到您公司无线路由器的无线连接进行连接的手机上的浏览器(如本文的图像所示)。
  • 安装在 WebSphere Application Server 上的 Worklight

    请参阅 参考资料 来执行此步骤。正如您所期望的那样,Worklight 可以利用 WebSphere Application Server 的高强度安全功能。常用的 LTPA 令牌存储将在 DataPower、WebSphere Application Server 管理控制台与安全移动应用程序之间共享。对于此应用程序,我们使用了:

    • Worklight Studio V5.0.5
    • 嵌入式 WebSphere Application Server V7.0.0.15。
    将控制台修改为使用 “Type 1” 安全设置的新安全角色。请参阅 参考资料 来执行此步骤。
  • 中央安全服务器

    您需要使用该服务器让域范围的服务器可以看到 SSO。此处所示的示例使用的是 IBM Tivoli Directory Server V6.1。

  • Worklight Studio V5.0.5

    您需要使用 Worklight Studio 来创建一个样例 Worklight 应用程序。IBM Worklight Developer Edition 5.0 现在可免费下载和使用。

  • 样例移动应用程序

    下载本文附带的用于此练习的样例 Worklight 应用程序。

  • DataPower 设备

    此演示使用的 DataPower 设备是 XI52 集成设备,固件版本为 5.0.0.0。此样例应用程序由两种类型的多协议网关组成。图 5 和图 6 显示了 DataPower 设备中的脚本所使用的流程。将它们与图 9 相比较,图 9 显示了此解决方案所使用的实际处理规则。

图 4 显示了概念验证环境。

图 4. 概念验证环境
图 4. 概念验证环境
图 4. 概念验证环境

图 5 显示了使用逻辑的 LTPA 令牌。

图 5. 使用脚本的概念验证令牌的流程图
图 5.  使用脚本的概念验证令牌的流程图
图 5. 使用脚本的概念验证令牌的流程图

多协议网关的第一部分将会调用 AAA 规则来确保服务器安全,并对 SSO 使用 LTPA 令牌。它首先使用 HttpTag 的匹配规则来检测 LTPA cookie 的匹配项:值为 *LtpaToken2* 的 cookie。然后,它会检测 HTTP 标头并将请求转发给相应的服务器、支持 Worklight 的 Web 应用程序防火墙或 “常规” Web 应用程序防火墙。

图 6 显示了 LTPA 制作脚本的流程。

图 6. LTPA 制作脚本的流程
图 6. LTPA 制作脚本的流程
图 6. LTPA 制作脚本的流程

如果 LTPA cookie 不存在,那么嵌入的脚本逻辑将无法实现 LTPA 产生脚本。这些脚本使用 Web 应用程序防火墙登录页面的匹配规则。此处的关键是生成对于整个域有效的 LTPA 令牌。

SSO 的域范围令牌

此处的一个关键因素是这些服务器如何能够安全地接受来自彼此的通信。当然,通过安全套接字层 (SSL) 加密来确保通信通道的安全是确保应用程序安全的一个必不可少的部分,而且所有服务器都在每个端点上支持 SSL。但真正需要掌握的是能够了解所有服务器,从而创建一个 SSO 域的安全令牌。为此,将会使用在用户浏览器上存储为 cookie 的 IBM LTPA 令牌。

现有版本的 DataPower 的设计目标是尽可能的安全并使得限制范围尽可能的窄,因此,DataPower 从其 LTPA 脚本中生成一个 “主机” 级别的 cookie。它可以接收和处理从 WebSphere Application Server 生成的 “域” 级别 cookie,但您可能希望针对 DataPower 进行身份验证的所有用户都能够访问 WebSphere Application Server 和 Worklight 资源,无需再次被质询。为此,清单 2 中提供了一个 XSLT 脚本,可生成一个域范围的 LTPA cookie。

要让该脚本正常工作,需要某些关键因素:

  • 通用安全服务器:当然,用户必须在所有域中有效,而实现此目标的最简单的方法就是拥有一个通用的 LDAP 服务器。
  • 通用领域:LTPA 令牌有一些领域。在所有地方都使用相同的领域名称。在本示例中,我们使用的是 tonycustom
  • 通用 LPTA 密钥文件:使用从 WebSphere Application Server 导出的密钥文件。

在移动和其他 Web 应用程序之间拆分通信

该解决方案的一个关键是如何检测移动通信。有两个方法可将移动 HTTP 请求与其他通信分离。常用的方法是在 HTTP 标头中检测用户代理字段,查看它是否有移动浏览器。我们将在多协议网关中执行此操作,并且会使用简单的基本身份验证规则来质询用户,防止对服务器进行不安全的访问。下面,我们将说明它如何在定向到我们的 Worklight 应用程序的 iPhone Safari 浏览器上工作。为了进行比较,我们会将来自桌面浏览器(如 Internet Explorer)的请求发送到我们的 “常规” 应用服务器 “snoop” servlet。(这些 URL 非常相似,但实际上它们的位置完全不同。您可以将 URL 值更改为您希望的任何两个网站,以便进行自己的测试。)

创建移动设备 DMZ

创建移动设备 DMZ 有两个主要部分:创建自定义映射凭据脚本(清单 2)和 SSO setCookie 脚本(清单 2)。(假定已经通过身份验证;您恰好正在映射凭据树,以便 setCookie 脚本可以使用该树。)

清单 1 显示了用于从 DataPower 上下文中选择用户名和密码的逻辑,并将这些逻辑包含在 DataPower LDAP Search 函数中。如果找到相应的逻辑,则允许用户退出脚本。

清单 1. 用于为 LTPA 令牌映射凭据的脚本:domain-wide-MC.xsl
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
	xmlns:dp="http://www.datapower.com/extensions"
	xmlns:regexp="http://exslt.org/regular-expressions"
    extension-element-prefixes="dp regexp"
    exclude-result-prefixes="dp" version="1.0">
	<xsl:strip-space elements="serverAddress portNumber bindDN bindPassword filter" />
	<xsl:template match="/">
		<xsl:variable name="username"
			select="dp:variable('var://context/WSM/identity/username')" />
		<xsl:variable name="password"
			select="dp:variable('var://context/WSM/identity/password')" />
		<xsl:variable name="targetDN"
			select="'cn=Users,secAuthority=Default,o=ibm,c=us'"/>
		<xsl:if test="string-length($username)=0">
			<dp:reject>No input yet</dp:reject>
		</xsl:if>
		<xsl:variable name="resp"
			select="dp:ldap-search($serverAddress, $portNumber, $bindDN, 
$bindPassword, $targetDN,$attributeName, $filter, $scope, $sslProxyProfile, 
$ldapLBGroup)" />

		<!-- The format of the resp should be something like: 
			<LDAP-search-results xmlns="http://www.datapower.com/extensions">
			<result> <DN>cn=Joe User, cn=Users,dc=example, 
			dc==com</DN> </result> </LDAP-search-results> -->

		<xsl:variable name="userDN"
			select="$resp/*[local-name()='LDAP-search-results']/
*[local-name()='result']/*[local-name()='DN']" />

		<xsl:if test="string-length($userDN)=0">
			<dp:reject> USER NOT PRESENT IN LDAP"</dp:reject>
		</xsl:if>		
		<!--  outer if -->
		<!-- </xsl:if> -->
		<xsl:variable name="addlTree"
			select="',cn=Users,secAuthority=Default,o=ibm,c=us'" />
		<xsl:variable name="uniqueID" select="concat($userDN,$addlTree)" />
		<!-- Record to the log the DN results returned from the ldap-search -->
		<!-- Build a properly formatted nodeset so that the AAA action will 
			update the var://context/WSM/identity/credentials -->
		<xsl:variable name="LTPARealm" select="'tonycustom/'" />
		<xsl:message dp:priority="error">
			DEBUG  - Script ending in LDAP SUCCESS
			<xsl:value-of select="$uniqueID" />
		</xsl:message>
		<entry type="Custom">
			<xsl:value-of select="$uniqueID" />
		</entry>
	</xsl:template>
</xsl:stylesheet>

需要重点注意的是一行代码,该代码在 Search 模式下调用 LDAP 服务器来映射所需的凭据:

<xsl:variable name="resp"
select="dp:ldap-search($serverAddress, $portNumber, $bindDN, $bindPassword,
$targetDN,$attributeName, $filter, $scope, $sslProxyProfile, $ldapLBGroup)" />

要在 LDAP 目录中查找用户,$TargetDN 必须包含 LDAP 架构属性才能在 LDAP 树中找到正确的用户。

清单 2 显示了用于映射 cookie 的脚本。

清单 2. 用于设置 LTPA cookie 的脚本:set-cookie.xsl
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" 
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
	        xmlns:dp="http://www.datapower.com/extensions"
	        extension-element-prefixes="dp" 
                exclude-results-prefixes="dp">


  
  <xsl:template match="/">
    <dp:remove-http-response-header name="Set-Cookie" />

    <xsl:variable name="token-var" select="dp:variable('var://context/AAA/PPLTPA')"/>
    <xsl:variable name="token" select="$token-var//LTPAAttribute[Name = 
'LTPAToken']/Value"/>

    <dp:set-response-header name="'Set-Cookie'" value="concat('LtpaToken2=', $token, 
'; Domain=.ibm.com; Path=/;')" />

    <xsl:copy-of select="//message/*" />
    <xsl:text>
    </xsl:text>
  </xsl:template>

</xsl:stylesheet>

清单 2 显示了用于在浏览器中为 SSO 中的用户设置 LTPA 会话 cookie 的响应脚本。在 set-cookie 脚本中,需要重点注意的是以下这一行代码:

<dp:se Table 1 Script to Map Credentials for LTPA Tokent-response-header name="'Set-Cookie'"
value="concat('LtpaToken2=', $token, '; Domain=.ibm.com; Path=/;')" />

请注意,该设置是针对域范围 “.ibm.com” 域进行的。

多协议网关将检测浏览器并路由到移动后端。

清单 3 显示了一个用于该转换的 DataPower XSLT 文件示例。

清单 3. 根据浏览器进行基于内容的路由的 XLST 文件
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
	xmlns:dp="http://www.datapower.com/extensions"
	extension-element-prefixes="dp" exclude-result-prefixes="dp" version="1.0">
	<xsl:template match="/">
		<xsl:variable name="fireFoxBackSideURL" 
select="'http://datapower.ibm.com:2095/MobileLandingWeb/MobileLanding.html'" />
		<xsl:variable name="iPhoneBackSideURL" 
select="'http://datapower.ibm.com:2095/MobileLandingWeb/MobileLanding.html'" />
		<!-- We'll let Chrome route just like an iphone -->
		<xsl:variable name="chromeBackSideURL" 
select="'http://condp03a.bocaraton.ibm.com:2095/MobileLandingWeb/MobileLanding.html'" />
		<xsl:variable name="nonMobileBackSideURL" 
select="'http://datapower.ibm.com:2095/MobileLandingWeb/RegularLanding.html'" />
		<xsl:variable name="httpHeader"
			select="dp:variable('var://service/original-content-type')" />
		<!--- -->
		<xsl:message dp:priority="error">
			Version 2: The $httpHeader value is:
			<xsl:value-of select="$httpHeader" />
		</xsl:message>
		<xsl:message dp:priority="error">
			The dp:http-request-header() value is:
			<xsl:value-of select="dp:request-header('User-Agent')" />
		</xsl:message> <!--- -->
		<xsl:choose>
			<!-- var://service/routing-url is a write-only variable 
				documented in the Extension Elements/Functions Catalog. 
				See below for reference. -->
			<xsl:when test="(contains(dp:request-header('User-Agent'),
'Chrome'))">
				<dp:set-variable name="'var://service/routing-url'"
					value="$chromeBackSideURL" />
				
				<dp:set-variable name="'var://local/dpvar_route'" 
value="$chromeBackSideURL" />
				<xsl:message dp:priority="error">
					Detected Chrome: Setting URL is:
					<xsl:value-of select="$chromeBackSideURL" />
				</xsl:message>
			</xsl:when>
			<xsl:when test="(contains(dp:request-header('User-Agent'),
'iPhone'))">
				<dp:set-variable name="'var://service/routing-url'"
					value="$iPhoneBackSideURL" />
				
				<dp:set-variable name="'var://local/dpvar_route'" 
value="$iPhoneBackSideURL" />
				<xsl:message dp:priority="error">
					Detected iPhone: Setting URL is:
					<xsl:value-of select="$iPhoneBackSideURL" />
				</xsl:message>
			</xsl:when>
			<xsl:otherwise> …line                        
				<!—est of script omitted  -->

清单 3 在 HTTP 请求标头中检测用户代理。不同的浏览器采用不同的方式设置该代理值。根据检测到的浏览器类型,DataPower 变量 'var://service/routing-url' 被设置为将请求重定向到充当目标请求的安全前端的 Web 应用程序防火墙。

需要重点注意一下这一行代码,该代码将会测试浏览器来检测移动设备:

<xsl:when test="(contains(dp:request-header('User-Agent'),'iPhone'))">

该行使用 http Request 用户代理来检测是否正在使用 iPhone。如果是这样,那么就可以使用移动浏览器或其他条件将相应的内容路由到 Worklight 服务器,并将其他内容路由到另一台服务器或默认的后端。

为了说明这个脚本可以在没有移动设备的情况下工作,请为 Chrome 浏览器复制 iPhone 逻辑,这样就会出现使用 Chrome 进行的路由,该路由本来应该面向 iPhone 设备。

结果是登录页面包含在 DataPower Web 应用程序防火墙中。这样做说明了两件事情:

  • 没有任何内容离开 DataPower 的域;所有内容都安全通过 Web 应用程序防火墙。
  • 有一个之后重定向到防火墙内整个页面的登录页面,这意味着 JavaScript™ 以及重定向到页面链接的其他脚本都可以最小化。

编程注意事项

此处提供的脚本和示例材料仅用于演示:

  • 这里使用的是 “基本身份验证” 类型的质询,而不是以基于表单的身份验证,即使在登录表单上进行交互看起来可能更直观一些。这样做是为了演示出现在 “基本身份验证” 质询对话框上的领域的作用。
  • 在本示例中,我们对 URL 进行了硬编码,但也可以使用 DataPower 变量,从 DataPower 计算机上的脚本界面访问这些变量。
  • 此外,使用关闭 “follow redirects” 的建议也非常重要。这样可以防止页面中嵌入的图像和其他链接出现问题。图 8 显示了这个设置。
  • 在修改 XSLT 脚本时,务必在使用 XML 向导中的清理功能时查看空格,以确保不会向其中添加过多的空格。
  • 最后,尽管本文忽略了 SSL 设置,但生产服务器不应该在任何安全通道上忽略 SSL 设置。

重要的配置注意事项

此设置的完整步骤包含在下载材料中。但是,在执行该配置时,您应该注意一些关键步骤,在这里,我们突出强调这些步骤,以便说明各个组件之间的关系。

  • DataPower 配置

    用户标头中用于基于内容的路由的初始防火墙是通过多协议网关定义来进行的(图 7)。

    图 7. 多协议网关高级定义
    图 7 多协议网关高级定义
    图 7 多协议网关高级定义

    使用 DataPower SOA 手册中所述的最佳实践来嵌入安全规则。第一个规则 Dworks_Mobile_MPGW_Policy_rule_1 在 cookie 中检测 *LtpaToken2* 字符串:如果该字符串存在,则允许将它传递到浏览器 Route 图标。如果不存在任何 cookie,则会控制到 Dworks_Mobile_Policy_rule_0 的传递(该规则包含用于生成 LTPA 令牌的逻辑),设置 cookie(在 “转变” 步骤中),然后将它传递到浏览器 Route 图标。

    下一步涉及一个重要的设置,即 Follow Redirects,该设置用于确保该测试会解析所有嵌入的 JPEG 和 URL(图 8)。

    图 8. 重要设置:Follow Redirects
    图 8. 重要设置:Follow Redirects
    图 8. 重要设置:Follow Redirects

    Dworks_Mobile_MPGW Policy 是进行 AAA 策略和浏览器检测以及后端路由的位置。每一个最终端点都包含在一个 Web 应用程序防火墙中(图 9)。

    图 9. DataPower Web 应用程序防火墙
    图 9. DataPower Web 应用程序防火墙
    图 9. DataPower Web 应用程序防火墙
  • 应用服务器 LTPA 导出

    尽管这里没有详细介绍,但我们了解到移动浏览器通信将会发送到安装在 WebSphere Application Server 顶部的安全 Worklight 服务器,并且所有其他通信量被传递到非 Worklight 应用服务器。根据最佳实践,我们假定 WebSphere Application Server 启用了全球和应用程序安全性,通过使用 Worklight 安全文档中所述的设置,可确保 Worklight 在自身范围内是安全的。

    关键是共享 LTPA 文件(图 10)。

    图 10. WebSphere Application Server 导出 LTPA 面板
    图 10. WebSphere Application Server 导出 LTPA 面板
    图 10. WebSphere Application Server 导出 LTPA 面板

    此外,领域的名称也非常重要(图 11)。WebSphere Application Server 中使用的名称应该与 DataPower Extract Identity 选项卡的 HTTP BasicAuthentication Realm 中指定的名称相匹配(图 12)。

    图 11. WebSphere AppServer 的突出显示领域
    图 11 WebSphere AppServer 的突出显示领域
    图 11 WebSphere AppServer 的突出显示领域
    图 12. DataPower 的 Extract Identity 面板
    图 12. DataPower 的 Extract Identity 面板
    图 12. DataPower 的 Extract Identity 面板
  • DataPower LTPA 使用面板

    图 13 显示了重要的面板,该面板列出了 Web 应用程序防火墙上的 LTPA 令牌设置。在该面板中,可以将从图 10 中导出的 LTPA 密钥导入到 DataPower 配置中。

    图 13. DataPower 的 LTPA 后处理生成面板
    图 13. DataPower 的 LTPA 后处理生成面板
    图 13. DataPower 的 LTPA 后处理生成面板
  • Worklight 安全配置

    图 14 显示了该领域名称在 Worklight 配置中也是非常重要的,会在该配置的 authenticationConfig.xml 文件中使用该名称。

    图 14. Worklight Authentication Configuration Editor
    图 14.  Worklight Authentication Configuration Editor
    图 14. Worklight Authentication Configuration Editor

    最后,领域名称会用在 Worklight WAR 文件中。请注意,清单 4 所示的 XML 中的 realm-name 已添加到 web.xml 文件中。

    清单 4. 添加到 Web.xml 中以确保 WebSphere Security 的 WAR 文件安全
    	<security-constraint>
    		<display-name>MyConst</display-name>
    		<web-resource-collection>
    			<web-resource-name>MyRes</web-resource-name>
    			<url-pattern>/*</url-pattern>
    			<http-method>GET</http-method>
    			<http-method>POST</http-method>
    		</web-resource-collection>
    		<auth-constraint>
    			<description>
    			MyAuth</description>
    			<role-name>MyRole</role-name>
    		</auth-constraint>
    		<user-data-constraint>
    			<transport-guarantee>NONE</transport-guarantee>
    		</user-data-constraint>
    	</security-constraint>
    	<login-config>
    		<auth-method>BASIC</auth-method>
    		<realm-name>tonycustom</realm-name>
    	</login-config>
    	<security-role>
    		<role-name>MyRole</role-name>
    	</security-role>

测试

本文附带的 Worklight 应用程序非常简单。要进行测试,则需要使用一个 Web 浏览器(如 Firefox),该浏览器与 User Agent 插件一同加载,用于模拟移动设备,您还需要另一个浏览器(如 Chrome),用于模拟 “常规” 通信。要进行测试,请在 Firefox 中启动此 URL:http://<datapower_appliance >:2091/,其中 <datapower_appliance> 是您的 DataPower 设备的 DNS 名称。2091 是为该设备上的多协议网关服务配置的端口。

首先将由 Web 应用程序防火墙上的 AAA 策略对您进行质询(图 15)。

图 15. iPhone AAA 基本身份验证质询
图 15. iPhone AAA 基本身份验证质询
图 15. iPhone AAA 基本身份验证质询

请注意 LTPA 领域。该领域与 WebSphere Application Server 上的领域配置相匹配。

进行身份验证之后,就会将您传递到您在 XSLT 文件中编码的后端 URL,这是支持 Worklight 的应用服务器(图 16)。

图 16. 重定向到 Worklight 登录页面的 Safari 测试
图 16.  重定向到 Worklight 登录页面的 Safari 测试
图 16. 重定向到 Worklight 登录页面的 Safari 测试

跟随所显示的链接,您会到达 Worklight 欢迎页面(图 17)。

图 17. Worklight 自定义的安全应用程序欢迎页面
图 17. Worklight 自定义的安全应用程序欢迎页面
图 17. Worklight 自定义的安全应用程序欢迎页面

当定向到防火墙时,您还可以到达 Worklight 控制台,因为您已经进行了身份验证,并且已经拥有一个 LTPA 令牌(图 18)。

图 18. 通过 DataPower Web 应用程序防火墙安全访问 Worklight 控制台
图 18. 通过 DataPower Web 应用程序防火墙安全访问 Worklight 控制台
图 18. 通过 DataPower Web 应用程序防火墙安全访问 Worklight 控制台

还可以进行反向操作。如果您首先通过访问 http://<appserver>:9060/ibm/console 上的应用服务器 URL 进行质询,那么 DataPower Web 应用程序防火墙将接受应用服务器生成的 LTPA 令牌。

如果您是在自己的工作站上进行测试,那么可以使用 cookie 检测器(在本例中为 Cookie+ 管理器)来查看 LTPA 令牌(图 19)。

图 19. 用于查看 LTPA 令牌 cookie 的 Cookie+ 管理器
图 19. 用于查看 LTPA 令牌 cookie 的 Cookie+ 管理器
图 19. 用于查看 LTPA 令牌 cookie 的 Cookie+ 管理器

结束语

本文介绍了 IBM WebSphere DataPower Appliance 如何在移动设备世界和您的现有基础架构之间充当 DMZ。借助一项简单的浏览器检测技术,DataPower 可以将浏览器请求路由到 Worklight 服务器来获得全套的本机 API 支持。这一可扩展的方法可迅速构建基础架构来支持移动设备,同时让初始投资提供很好的回报。

致谢

非常感谢很多 IBM 同事、顾问、架构师和开发团队,感谢他们开发了这些创新的解决方案,并且花时间整理文档,分享他们获得的经验和教训。作者特别感谢 John Rasmussen 和 Shiu-Fun Poon,他们为本文中列出的 SSO 路由脚本提供了基础。


下载资源


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere, 移动开发
ArticleID=936058
ArticleTitle=通过 IBM WebSphere DataPower SOA Appliances 确保对企业应用程序的安全移动访问
publish-date=07012013