用于 FIPS 140-2 验证和认证的 IBM Worklight 服务器配置,第 1 部分: 配置一个服务器端 WebSphere Application Server 基础架构

在本文中,将会学习如何逐步确认和证明您的移动应用程序的端到端运行方式的 FIPS(Federal Information Processing Standard,联邦信息处理标准)140-2(加密模块验证程序)合规性。具体步骤包括安装必备产品(IBM® Worklight Studio、部署到一个 IBM WebSphere® Application Server Liberty Profile 的 Worklight Server,以及一个 Base Profile),启用服务器端、端到端安全;配置服务器端基础架构以实现 FIPS 140-2 合规性;最后通过 WebSphere 基础架构的日志记录、跟踪和测量设施来测量、收集、分析和验证 FIPS 140-2 合规性。

Bhargav Perepa, IT 专家, IBM

Bhargav PerepaBhargav Perepa 是位于华盛顿特区的 IBM Federal Software Group 的 WebSphere 架构师和 IT 专家。他曾经是 IBM Austin WebSphere Development Lab 的 WebSphere 开发人员,并在 IBM 芝加哥积累了一些 Smalltalk 和 C++ 开发经验。Bhargav 拥有芝加哥伊利诺伊理工学院计算机科学硕士学位,以及奥斯汀市德克萨斯大学的 MBA 学位。



2013 年 10 月 21 日

简介

关于本系列

这个两部分系列将介绍如何为了通过 FIPS 140-2 合规性测试而配置 IBM Worklight Server。各个联邦政府机构通常要求用来解决方案构建和部署的供应商产品遵守这项计算机安全标准。

  • 第 1 部分:配置一个服务器端 WebSphere Application Server 基础架构
  • 即将发布:第 2 部分:将移动应用程序部署在 WebSphere Application Server 上

来自美国国家标准和技术研究所 (NIST) 的 FIPS(Federal Information Processing Standard,联邦信息处理标准)期刊 140-2 是一项美国联邦政府计算机安全标准,用于验证参与计算机使用一种普遍、公开和不安全的信息安全基础架构进行通信时采用的加密方法的信息安全性(机密性、完整性、真实性、不可抵赖性等)。请参见 参考资料,以获得更多的详细信息。

符合 FIPS 140-2 的典型程序会调用 FIPS 批准的加密函数来实现机密性、完整性和消息摘要服务,从而满足 FIPS 140-2 要求,并使用 API 来访问基础的 FIPS 140-2 密码库。TLS(Transport eLayer Security,安全传输层协议)SSL(Secure Socket Layer,安全套接字层协议)是广泛用于在开放和公共网络(比如互联网)上提供信息安全的密码协议。

获取 IBM Worklight

Worklight 是一个创建和部署原生、HTML5 和混合移动应用程序的综合平台。Worklight 框架通过跨 Android、iOS、Blackberry 和 Windows Metro 平台的更高的代码重用率,促进了敏捷开发,以及移动应用程序的测试和交付。此外,它利用广泛可用的 Web 技术和标准,降低了开发成本。

下载 免费的 IBM Worklight Developer Edition。

IBM® Worklight 平台 由以下部分组成:

  • IBM Worklight Studio 用于开发原生、混合和标准的移动应用程序
  • IBM Worklight Server 用于测试和部署这些移动应用程序
  • IBM Worklight Device Runtime Components,在智能电话和平板电脑等移动设备上运行
  • IBM Worklight Console,包含一个用于管理移动应用程序和适配器的浏览器用户界面
  • IBM Worklight Application Center 用于存储和共享整个企业内的移动应用程序

移动应用程序由应用程序资源组成,比如图像、字符串常量、颜色、图画、动画、主题、菜单、布局和适配器。可以使用 Worklight 身份验证和授权框架,保护在 Worklight 平台上运行的移动应用程序远离未授权访问。

版本适用性

本文中的步骤适用于最新的版本(Worklight v5.0.6.1 和 WebSphere v8.5.0.2),但一些图片可能来自以前的版本。所有步骤已针对 Worklight v5.0.6.1 和 WebSphere v8.5.0.2 进行了验证。

Liberty Profile v8.5.0.1 实质上是一种通过 OSGi 技术建立的轻量型、快速、动态、灵活、可合成的应用程序开发和运行时环境,专为使用 WebSphere Application Server Developer Tools for Eclipse 而设计。Liberty Profile 能够动态地置备支持所部属应用程序所需的最少功能,无需重新启动服务器。Liberty Profile 支持一部分 Java™ Platform, Enterprise Edition (Java EE) 第 6 版技术标准。图 1 给出了 Liberty Profile 架构。

图 1. Liberty Profile 架构
该图显示了 Liberty Profile 架构

WebSphere Application Server Base Profile v8.5.0.1 实际上是一个应用服务器平台,您可在该平台上部署 Java 业务应用程序。此应用服务器平台提供了数据库连接、线程和应用程序管理服务。在配置之后,每个 Base Profile 都可以充当一个惟一的运行时环境,托管一个或多个业务应用程序,提供支持所托管应用程序所需的服务。可通过一个基于浏览器的管理控制台来管理每个 Base Profile,还可将多个独立 Base Profile 的实例安装在单个系统上。图 2 给出了 Base Profile 架构。

图 2. Base Profile 架构
该图显示了 Base Profile 架构

用例架构

图 3 给出了一个端到端用例架构。请求从移动客户端设备(智能电话和平板电脑)发出,这些设备由 Google Android、Apple iOS、RIM Blackberry 或 Windows® 移动平台提供支持。客户端请求通过 Wi-Fi 或蜂窝电信提供商网络和公共互联网服务提供商网络传送到服务器端。到达服务器端后,请求流经一个托管 Worklight Server 应用程序的 WebSphere Application Server(Liberty 和 Base Profile)安全基础架构。后续的经过成功验证的请求会流到一个后端 IBM DB2® SQL 数据库服务器,如图 3 所示。操作系统平台本身(Windows 7 64 位)针对 FIPS 140-2 策略实施进行了相应的配置(参见 参考资料,获取更多信息的链接)。

图 3. 端到端用例架构图
该图显示了一个端到端用例架构图

WebSphere Application Server 是一个 Java EE 中间件基础架构软件,支持多种容易理解的服务器身份验证和信任模型,以便为企业架构和 Web 归档文件 (WAR) 等应用程序资源与服务工件提供安全保护。在为 Worklight 和其他部署的企业应用程序启用应用程序安全性时,WebSphere Application Server 企业容器契约会执行所配置的安全服务质量属性。这项安全配置选项能够集成现有的第三方单一登录产品来保护 Java EE 容器。

对于本文的用例,以这种方式保护资源是恰当的选择,因为移动设备是值得信任的(编写本文时所使用的 Samsung 平板电脑、Verizon Android 智能电话和 Apple iPad 设备由 IBM 拥有、认证和提供),服务器端资源仅提供给受信任的移动应用程序资源。在部署到 WebSphere Application Server 环境中时,Worklight 还提供了其他资源保护方式。为了保护应用程序资源,本文的用例启用了 WebSphere Application Server 应用程序安全性,使用传统的 WebSphere Application Server 身份验证和信任模型来保护在 WebSphere Application Server 上运行的 Worklight WAR 应用程序。

因为 Worklight 使用一个可扩展的身份验证模型作为其核心功能,所以,通过使用 Worklight 平台以及在 WebSphere Application Server 之上运行的 Worklight Server 应用程序开发的移动应用程序,可以将用户身份验证配置为利用基础 WebSphere Application Server 运行时为用户身份验证提供的 LTPA(Lightweight Third-Party Authentication,轻量型第三方身份验证)令牌。这是本文的用例打算演示的内容。

在服务器端、启用了安全性的配置模式中,当用户第一次启动移动设备上的移动客户端应用程序时,服务器端基础架构会向移动客户端应用程序询问用户凭据。移动客户端可使用一个登录表单将用户凭据提供给服务器。图 4 给出了这个初始身份验证请求-响应流。

图 4. 初始身份验证请求-响应序列
该图显示了初始身份验证请求-响应序列

如果用户从移动客户端收到的用户凭据在服务器端经过成功验证,那么服务器会生成一个 LTPA 令牌,将安全上下文封装为一个 LTPA cookie 并返回到移动客户端。客户端可在对服务器的后续调用中使用该 LTPA cookie。图 5 给出了这个后续的经过验证的请求-响应流。

图 5. 经过验证的后续请求-响应序列
该图显示了经过验证的后续请求-响应序列

当用户单击 Call protected DB2 SQL adapter procedure 时,onclick 事件会在服务器端调用一个 retrieveUsecase() 过程。此过程被实现为 WLv505FIPS140_2Example.js 中的一个函数调用。该函数调用将会识别涉及到的适配器、要调用的适配器过程,以及要传入的适配器过程参数。此函数还会识别在成功或未成功地调用适配器过程后,要调用的回调函数。

适配器过程使用正确的 DB2 登录凭据和 DB2 模式连接到 DB2 数据库 FIPSDB,以便从一个匹配行获取请求的信息,这个匹配行由 SQL 语句 ["SELECT CLIENT, CLIENTTYPE, MIDDLEWARE, SERVEROS, SERVERPROFILE, BACKEND, AUTHORS, REMARKS FROM DB2ADMIN.USECASES WHERE SEQNO = ?"] 中的 where 子句过滤得到。从后端 DB2 实例成功获取的信息在 JSON(JavaScript Object Notation,JavaScript 对象表示法)格式的响应中传递给客户端。DB2 登录凭据信息以明文形式显示,但可以对它进行编码。图 6 给出了 DB2 FIPSDB 数据库的 USECASES 表模式定义。

图 6. FIPSDB DB2 数据库 USECASES 表定义
该图显示了 FIPSDB DB2 数据库 USECASES 表定义

图 7 给出了填充的 USECASES 表,它包含 9 个行。

图 7. USECASES 表数据
该图显示了 USECASES 表数据
图 8

作为 FIPSDBDB2SQLAdapter 定义的一部分,通过设置可在系统上执行的并发请求的最大数量,<loadConstraints> 元素可以定义施加在一个后端应用程序上的最大负载。默认情况下,这个值被设置为 5

Worklight 对从 Worklight 应用程序传入的服务器请求进行排队。尽管并发请求数量低于最大值,但 Worklight 仍依据队列中的请求顺序将它们转发给后端应用程序。如果并发请求数量超过最大值,Worklight 会等待一个正在处理的请求完成,然后处理位于处理队列中的下一个请求。如果一个请求在队列中的等待时间超过过程中配置的超时值(默认值为 30 秒),那么 Worklight 会从队列中删除它,并向调用方返回一个 Request Timed Out 异常。

当用户单击 Logout 时,onclick 事件调用从服务器端上的 WASLTPARealm 安全域调用客户端注销,成功注销后,服务器端逻辑会重新加载该应用程序。该逻辑会释放之前创建和缓存的 LTPA 令牌。

源文件 WLv505FIPS140_2Example.html 包含两个 HTML 代码段,分别用 AppBodyAuthBody 标识符标识。这个源文件还包含 WASLTPARealmChallengeHandler.js JavaScript 源文件。这个文件定义了函数 WASLTPARealmChallengeHandler.isCustomResponseWASLTPARealmChallengeHandler.handleChallengeWASLTPARealmChallengeHandler.submitLoginFormWASLTPARealmChallengeHandler.submitLoginFormCallbackWASLTPARealmChallengeHandler.submitFailureWASLTPARealmChallengeHandler.submitSuccess。在移动设备上运行的 Worklight Device Runtime Components 调用这些函数来响应 Worklight Server 通信消息;它们不应由应用程序逻辑直接调用。基础架构逻辑基于 WASLTPARealmChallengeHandler.js JavaScript 源文件中提供的逻辑和基础客户端-服务器通信消息,控制显示 AppBody(身份验证成功时)还是 AuthBody(当提供质询时,需要提供一个登录表单来收集用户凭据)。有关 WASLTPARealmChallengeHandler.js 逻辑的更多细节,请参见 参考资料

在本文的用例的实现中,配置文件定义了以下属性。简短描述有助于理解用例实现中的相关概念。有关详细的解释,请参阅 参考资料

  • Security Test = "WASLTPA-securityTest"WASLTPA-securityTest 是一项安全测试,创建用于定义安全配置来保护 Worklight 应用程序资源,比如 WASLTPA 安全域中的适配器过程 getUsecase
  • Realm = "WASLTPARealm"WASLTPARealm 是一个保护资源(比如适配器过程 getUsecase)的身份验证域。
  • Device Provisioning ="wl_deviceNoProvisioningRealm"这个选项可确保,当一个移动应用程序第一次在一个部署的移动设备上运行时,不会发生从 Worklight Server 获取安全证书的过程。
  • loginModule一个登录模块验证从一个身份验证程序收到的客户端凭据。com.worklight.core.auth.ext.FormBasedAuthenticator 提供一个登录表单,其中包含用户名和密码输入字段,以及提交和取消按钮。该表单用户对用户进行身份验证。com.worklight.core.auth.ext.NonValidatingLoginModule 接受任何用户名-密码组合。com.worklight.core.auth.ext.SingleIdentityLoginModule 向其身份已在 worklight.properties 文件中定义(明文或编码形式)的单个用户授予访问权。

图 8 显示了从 Worklight Server SQLAdapter 模块逻辑流到后端 DB2 数据库服务器的经过验证的用户请求,Worklight Server 部署在一个 WebSphere Application Server Liberty 或 Base Profile 基础架构之上。Worklight SQLAdapter 定义提供了与身份验证信息、要处理的并发请求数量和超时参数值(前面已解释)相关的后端连接选项。

图 8. 经过验证的下游流程:Worklight-DB2 数据库服务器交换
该图显示了经过验证的 Worklight-DB2 数据库服务器交换

图 9 给出了文中的用例的一个序列图,它捕获用户、客户端和服务器角色之间所有可能和相关的交互。这些交互表示为一个随着时间流逝在组件之间流动的消息序列。

图 9. 用例的序列图
该图显示了用例的序列图

图 10 显示了 Worklight Server 用作一种基于标准的中间件软件产品的一种额外价值。Worklight Server 使用轻量型 JSON/HTTP 格式从移动设备接收请求,并在响应流中以相同格式响应移动客户端。Worklight Server 可连接到多个后端来源,以便进行多来源混搭和聚合。Worklight Server 也可以将从后端系统收到的原生响应自动转换为 JSON 格式。

图 10. Worklight Server 中间件角色
该图显示了 Worklight Server 中间件角色

图 11 给出了在一个移动设备上运行的 Worklight 客户端与在一个启用并执行了 FIPS 140-2 策略的企业基础架构上运行的 Worklight Server 之间的 SSL 握手交换过程。

图 11. SSL 消息握手过程
该图显示了 SSL 消息握手过程

用例实现方法

Worklight 平台主要包含 Worklight Studio、Worklight Server、Worklight Device Runtime Components、Worklight Console 和一个 Worklight Application Center。您可以使用 Worklight Studio 开发一个使用 HTML5、CSS3(Cascading Style Sheets version 3,级联样式表第 3 版)和 JavaScript Web 技术并且可以跨平台移植的、多平台的移动应用程序。Worklight 平台编程模型支持 HTML (web)、混合和原生移动应用程序开发。Worklight Studio 支持 Worklight 编程模型,集成了开源 Apache Cordova API;为流行的第三方 UI 框架(比如 JQuery、Sencha Touch 和 Dojo Mobile)提供了工具支持;还继承了原生软件开发工具包 (SDK),比如 Android SDK 和 Apple Xcode。Worklight Studio 改善了易开发性,支持浏览器模拟器和与原生 SDK 工具包集成。

此外,Worklight Studio 支持从客户端角度调用 SQLAdapter 过程或其他类型的适配器(类似于移动设备客户端发起的请求),或从中间件角度调用后端服务(类似于一个 Worklight Server 发起的请求),以接收该服务从后端(SQL 数据库服务器获取的数据用于测试用途。图 12图 13 分别显示了 Worklight Studio 对后端服务测试服务响应验证的支持。

图 12. 从 Worklight Studio 调用一个后端服务:请求
该图显示了在从 Worklight Studio 调用后端服务时的请求
图 13. 从 Worklight Studio 调用一个后端服务:响应
该图显示了在从 Worklight Studio 调用后端服务时的响应

使用移动浏览器测试模拟器 测试用于 Android、Apple iPhone、Blackberry 设备、Windows Phone 和移动 Web 应用程序平台的移动 Worklight 应用程序。这项功能方便了对各种可用且支持的移动设备上的移动应用程序,在移动设备微型浏览器中的页面外观、屏幕分辨率、形状规格、屏幕方向等方面的测试。此外,您可使用此功能验证 Cordova 抽象的功能测试。图 14 显示了在一个移动浏览器模拟器中对一个应用程序的测试。

图 14. 一个移动浏览器模拟器中的测试
该图显示了一个移动浏览器模拟器中的测试

使用 Android Emulator 测试和调试使用 Worklight Studio 开发的、用于 Android 设备的移动应用程序。Android Emulator 是 Android Dalvik 虚拟机 (VM) 的一种实现,设计用于在托管 Worklight Studio 的相同计算机上的 Android 虚拟设备中运行。Android Emulator 支持模拟网络连接速度和延迟、外部存储卡,以及用户和系统事件。因为该模拟器是 Dalvik VM 的一种实际实现,没有附加到任何特定的供应商硬件(三星、HTC、索尼、华为等),所以模拟器测试有助于验证移动应用程序在基线功能方面的逻辑,消除硬件引入的问题和特定于供应商硬件的问题。图 15图 16 分别显示了使用 Android API 8 模拟器及请求和响应流的移动应用程序测试。

图 15. 在一个 Android 模拟器中测试:请求
该图显示了在一个 Android 模拟器中对一个请求的测试
图 16. 在一个 Android 模拟器中测试:响应
该图显示了在一个 Android 模拟器中对一个响应的测试

图 17 提供了在嵌入到 Worklight Studio 中的 Jetty 服务器上运行的一个移动 Web 应用程序的预览。因为工具运行时环境 (Jetty) 无法了理解与 WebSphere Application Server 运行时关联的 WASLTPARealm 的操作运行时环境细节,所以该预览测试验证移动 Web 应用程序 UI 的正确呈现。

图 17. 使用 Worklight Console 预览和测试在一个测试服务器上运行的移动 Web 应用程序
该图显示了 Worklight Console 中的移动 Web 应用程序的预览

图 18 显示了如何使用 Worklight Console 将 SQLAdapter 部署到一个操作性 Worklight Server 实例。

图 18. 部署来自 Worklight Console 的适配器
该图显示了如何部署来自 Worklight Console 的适配器

图 19 显示了如何使用 Worklight Console 将移动应用程序部署到一个操作性 Worklight Server 实例。

图 19. 部署来自 Worklight Console 的移动应用程序
该图显示了如何部署来自 Worklight Console 的应用程序

图 20 显示了如何使用 Worklight Console 将移动应用程序资产完整地部署到一个操作性 Worklight Server 实例。

图 20. 移动应用程序资产的完整部署
该图显示了应用程序资产的完整部署

图 21 显示了如何将移动应用程序直接从 Worklight Console 部署到 Worklight Application Center。

图 21. 将应用程序直接部署到 Worklight Application Center
该图显示了如何将应用程序直接部署到 Worklight Application Center

图 22 显示了如何以 Android 打包格式 (.apk) 将经过签名的 Android 移动应用程序导出到文件系统中。

图 22. 将经过签名的 Android 应用程序导出到文件系统
该图显示了如何将经过签名的 Android 应用程序导出到文件系统

图 23 显示了如何将经过签名的 Android 移动应用程序从文件系统上传到一个 Worklight Application Center 实例。

图 23. 将经过签名的 Android 应用程序上传到 Worklight Application Center
该图显示了如何将经过签名的 Android 应用程序上传到 Worklight Application Center

图 24 显示了已上传到 Worklight Application Center 的 Android 移动应用程序。

图 24. 已完成的 Android 应用程序上传
该图显示了已完成的 Android 应用程序上传

服务器端基础架构配置 (Base Profile)

在一个 Base Profile 中完成以下步骤,以启用 FIPS 140-2、日志记录、跟踪和测量:

  1. 单击 Local Security Policy > Security Options > System cryptography: use FIPS compliant algorithms for encryption, hashing and signing > Enabled,为平台启用 FIPS 140-2 执行功能。

    备注:图 25 显示了针对 Windows 的 FIPS 140-2 本地安全策略配置。有关详细信息,请参见 参考资料

    图 25. Windows 本地安全策略 FIPS 140-2 配置
    该图显示了 Windows 本地安全策略 FIPS 140-2 配置
  2. 启动一个 WebSphere Application Server Base Profile 实例,然后将您浏览器的 Administrator Console 连接到服务器并启用 FIPS 140-2 配置:
    1. 单击 Security > SSL certificate and key management > Manage FIPS > Enabled FIPS 140-2
    2. 启用日志记录和跟踪,并更改日志详细信息:
      BASE-WIN2K8X64SSLTrace.log
      *=info: com.worklight.adapters.*=all: com.worklight.server.*=all: 
         com.worklight.report.*=all: com.worklight.integration.*=all: 
         com.worklight.database.*=all: com.worklight.core.*=all: 
         com.worklight.console.*=all: com.worklight.common.*=all: 
         com.worklight.gadgets.*=all
    3. 单击 Application servers > MobileServer > Process definition > Java Virtual Machine > Generic JVM arguments > -Djavax.net.debug=true,以指定 Java 虚拟机 (JVM)。
    4. 定义一个自定义 JVM 属性:
      javax.net.debug=ssl:record:plaintext:handshake:verbose:keygen:session:
         defaultctx:sslctx:sessioncache:keymanager:trustmanager
    5. 从 Administrator Console 注销。
    6. 停止 WebSphere Application Server。
  3. 编辑客户端 SSL 配置文件:
    1. 创建 C:\I\WAS\profiles\Mobile\properties\ssl.client.props 的一个备份并将它转移到安全位置。
    2. 编辑 C:\I\WAS\profiles\Mobile\properties\ssl.client.props 文件内容:
      • 设置 com.ibm.security.useFIPS=true
      • 设置 com.ibm.ssl.protocol=TLS
  4. 编辑服务器端 java.security 配置文件:
    1. 创建 C:\I\WAS\java\jre\lib\security\java.security 的一个备份并将它转移到安全位置。
    2. 修改以下代码:
      com.ibm.crypto.fips.provider.IBMJCEFIPS <-- Before
         com.ibm.crypto.fips.provider.IBMJCE

      得到以下形式:

      security.provider.1=com.ibm.crypto.fips.provider.IBMJCEFIPS
      security.provider.2=com.ibm.crypto.provider.IBMJCE
      security.provider.3=com.ibm.jsse2.IBMJSSEProvider2
      security.provider.4=com.ibm.security.jgss.IBMJGSSProvider
      security.provider.5=com.ibm.security.cert.IBMCertPath
      security.provider.6=com.ibm.security.cmskeystore.CMSProvider
      security.provider.7=com.ibm.crypto.pkcs11impl.provider.IBMPKCS11Impl
      security.provider.8=com.ibm.security.jgss.mech.spnego.IBMSPNEGO
      security.provider.9=com.ibm.security.sasl.IBMSASL
      security.provider.10=com.ibm.xml.crypto.IBMXMLCryptoProvider
      security.provider.11=com.ibm.xml.enc.IBMXMLEncProvider
      security.provider.12=org.apache.harmony.security.provider.PolicyProvider
  5. 在部署的文件系统上对 Base Profile 执行 Worklight Server 自定义,如 图 26 所示。
    图 26. 针对一个 Base Profile 的 Worklight Server 自定义
    该图显示了针对一个 Base Profile 的 Worklight Server 自定义
  6. 重新启动 WebSphere Application Server。

服务器端基础架构配置 (Liberty Profile)

在一个 Liberty Profile 中完成以下步骤,以启用 FIPS 140-2、日志记录、跟踪和测量:

  1. 自定义 server.xml 文件,添加 sslkeystorelogging 节。(参见 下载 部分中的工作文件。)
  2. 创建 jvm.options 和 log4j.properties 文件并将其暂存到合适的文件系统位置。(请参见所提供的工作文件)。
  3. 解压 worklight.war 文件,在必要时自定义它,然后重新创建该归档文件。

图 27 显示了部署的文件系统上针对一个 Liberty Profile 的 Worklight Server 自定义。

图 27. 针对一个 Liberty Profile 的 Worklight Server 自定义
该图显示了针对一个 Liberty Profile 的 Worklight Server 自定义

确保您将环境设置指定为使用 IBM Java 软件开发工具包 (JDK):

  1. 运行 <drive>:\<was-root>\bin\setupCmdLine.bat 来设置环境。
  2. 运行 <drive>:\<worklightserver-root>\server\wlp\bin\server.bat start worklightServer 来启动一个 Worklight Server 实例。
  3. 运行 <drive>:\<worklightserver-root>\server\wlp\bin\server.bat stop worklightServer 来停止 Worklight Server 实例。

图 28 提供了在一个 Worklight Server 操作性实例中对移动 Web 应用程序执行的一次预览测试。因为该实例部署在 WebSphere Application Server Liberty 或 Base Profile 配置之上,所以 WASLTPARealm 是一种有效的配置,使移动 Web 应用程序能够正常工作。

图 28. Worklight Console 中的移动应用程序的操作性预览
该图显示了 Worklight Console 中的移动应用程序的操作性预览

图 29 显示了在一个 Android 平板电脑上运行的 Worklight Application Center 客户端应用程序。

图 29. 一个 Android 平板电脑上的 Worklight Application Center 客户端中的移动应用程序下载
该图显示了一个 Android 平板电脑上的 Worklight Application Center 客户端中的移动应用程序下载

图 30 显示了 Worklight Device Runtime Components,其中 Worklight 移动应用程序被配置为与服务器端组件通信。

图 30. 移动客户端配置设置
该图显示了移动客户端配置设置

图 31 显示了部署到一个 Android 平板电脑之上且在其上运行的移动应用程序。

图 31. 在一个 Android 平板电脑上运行的移动客户端
该图显示了在一个 Android 平板电脑上运行的移动客户端

图 32 显示了在一个 Android 平板电脑上显示的服务器质询窗口。该窗口显示了所捕获的用户凭据。

图 32. 移动应用程序的服务器质询窗口(Android 平板电脑)
该图显示了移动应用程序的服务器质询窗口(Android 平板电脑)

图 33 显示了提供了有效的用户和数据库凭据后,移动应用程序的成功执行,以及一个成功的端到端请求-响应流。

图 33. 具有有效凭据的成功的移动应用程序执行
该图显示了具有有效凭据的成功的移动应用程序执行

图 34 显示了在提供无效的用户凭据时,移动应用程序的未成功执行,以及一个失败的端到端请求-响应流。

图 34. 具有无效凭据的未成功的移动应用程序执行
该图显示了具有无效凭据的未成功的移动应用程序执行

验证和确认分析

诊断日志、跟踪和测量输出文件 BHARSSLLibertyTrace.log 中的第 513 - 1644 行给出了客户端与服务器之间发生的完整的 SSL 握手。请参见 图 35可供下载的相关跟踪文件。突出显示的跟踪文件内容表示一个完整的握手流程。日志文件显示了多次 SSL 握手。可在从 Base Profile 捕获的日志文件中看到相同的模式。

图 35 显示了在一个移动设备上运行的移动客户端与在一个 IBM Java 环境中运行的服务器基础架构之间的 SSL-FIPS 140-2 握手流程。

图 35. 来自日志、跟踪和测量文件的 SSL-FIPS 140-2 握手验证和确认
该图显示了来自日志、跟踪和测量文件的 SSL-FIPS 140-2 握手验证和确认

第 513、597、664、700、1257、1274、1608 和 1644 行显示了图 35 中描述的行。分析细节的剩余部分如下所示:

  • 客户端请求。客户端向服务器发送信息,包括它支持的最高 SSL 版本和它支持的密码套件列表。(TLS 1.0 表示为 SSL 3.1。)密码套件信息包含加密算法和密钥大小:

    [TLSv1]
    Cipher Suites: [SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA, 
    SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, 
    SSL_DHE_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_DSS_WITH_AES_256_CBC_SHA, 
    SSL_ECDH_RSA_WITH_AES_256_CBC_SHA, 
    SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_AES_256_CBC_SHA, 
    SSL_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, 
    SSL_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, 
    SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, 
    SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, 
    SSL_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, 
    SSL_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, 
    SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA, SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, 
    SSL_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_DSS_WITH_AES_128_CBC_SHA, 
    SSL_ECDH_RSA_WITH_AES_128_CBC_SHA, SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA, 
    SSL_RSA_WITH_AES_128_CBC_SHA, SSL_ECDHE_RSA_WITH_RC4_128_SHA, 
    SSL_ECDHE_ECDSA_WITH_RC4_128_SHA, SSL_ECDH_RSA_WITH_RC4_128_SHA, 
    SSL_ECDH_ECDSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, 
    SSL_RSA_WITH_RC4_128_MD5, SSL_RENEGO_PROTECTION_REQUEST]
  • 服务器响应。服务器选择客户端和服务器都支持的最高的 SSL 版本和最佳的密码套件,然后将此信息发送给客户端:

    [TLSv1]
    Cipher suite:  SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
  • 证书。服务器向客户端发送一个证书或证书链。证书链 通常以服务器的公钥证书开头,以证书颁发机构的根证书结束。此消息是可选的,但只要需要服务器身份验证,就会使用它。

    chain [0] = [
    	[
    	  Version: V3
    	  Subject: CN=jserver, OU=SWG, O=IBM, C=US
    	  Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4
    	
    	  Key:  IBMJCE RSA Public Key:
    	modulus:
    	92784621582682166728351409075866971283584823984202570663
    	   6691205183708192217704549284163862788883621027968419590
    	   1240083367311839739509555666734794620185285543768168406
    	   4656845523699425906713942512767748136348517281311271488
    	   022357661402480688236843830996347540486698724905002161
    	   313848064418923142829862028699247
    	public exponent:
    	65537
    	
    	  Validity: [From: Wed Jul 30 16:39:20 EDT 2003,
    	               To: Wed Oct 13 16:39:20 EDT 2021]
    	  Issuer: CN=jserver, OU=SWG, O=IBM, C=US
    	  SerialNumber: [1059597560]
    	
    	]
    	  Algorithm: [MD5withRSA]
    	  Signature:
    	0000: 10 f0 91 c0 45 01 c7 3e  be f4 0e 7f 02 83 c1 2e  ....E...........
    	0010: 26 08 9e ba 30 2d f6 3e  c3 7c 49 c8 30 a2 7b e1  ....0.....I.0...
    	0020: a7 78 b9 e2 ac bf b5 1d  74 41 6c d3 89 61 04 c2  .x......tAl..a..
    	0030: a7 33 74 d0 28 2a d8 cf  cb 53 ab 54 79 e6 50 de  .3t......S.Ty.P.
    	0040: 0c 22 76 2a 85 51 cb a5  8b 66 7e f3 07 7a d2 af  ..v..Q...f...z..
    	0050: 2f cb aa 9d 27 59 2f 83  d6 ad c0 c7 50 57 62 c5  .....Y......PWb.
    	0060: 7f b4 cf 35 c7 26 50 b0  fd fc b5 7d 87 70 15 a0  ...5..P......p..
    	0070: 16 ec 16 e9 19 02 ba 05  d1 9b ce fb fe 2f ac 89  ................
    	
    	]
  • 服务器密钥交换。当第 3 步中发送的公钥信息不足以完成密钥交换时,服务器会向客户端发送服务器密钥交换消息:

    *** Diffie-Hellman ServerKeyExchange
  • 服务器响应完成。服务器告诉客户端,它已完成最初的协商消息:

    *** ServerHelloDone
  • 客户端密钥交换。客户端生成信息,以便创建一个要用于对称加密的密钥。对于 RSA 加密,客户端随后会使用服务器的公钥加密此密钥信息,并将它发送给服务器:

    *** ClientKeyExchange, DH
  • 完成。客户端告诉服务器,它已准备好开始安全的数据通信:

    *** Finished
  • 完成。服务器告诉客户端,它已准备好开始安全的数据通信。SSL 握手到此结束。

    *** Finished

托管 Worklight SQLAdapter 的 Worklight Server 实例与后端 DB2 数据库服务器之间的通信可在同一个日志文件中看到。在日志文件中搜索 SQLQuery 关键词,会找到 图 36 所示的内容。日志文件可验证流到后端的 SQL 调用和关联的后端响应。

图 36. 日志记录、跟踪和测量文件中的后端流验证和确认
该图显示了日志记录、跟踪和测量文件中的后端流验证和确认

结束语

本系列介绍了如何为了通过 FIPS 140-2 合规性测试而配置 Worklight Server,第 1 部分介绍了如何配置一个客户端 WebSphere Application Server 基础架构,以便进行 FIPS 140-2 合规性验证和证明,该基础架构包含带 Liberty 和 Base Profile 的 WebSphere Application Server、一个 DB2 服务器和 Worklight Server。

您学习了如何安装 IBM Mobile Foundation,提供必备产品(Oracle JDK、Android SDK、DB2)和 IBM Mobile Foundation 产品( WebSphere Application Server 的 Liberty 和 Base Profile 之上的 Worklight Studio 和 Worklight Server)。您还学习了如何使用 Worklight Studio 开发一个简单的移动应用程序,使用多种方法测试该移动应用程序,将该移动应用程序部署到一个操作环境和 Worklight Application Center,针对 FIPS 140-2 测试而配置该环境,在移动设备上测试该应用程序,以及验证该移动应用程序的端到端测试,以便使用基础架构日志记录、跟踪和测量文件进行合规性验证和证明。

致谢

衷心感谢以下 IBM 成员提供的反馈、建设性建议、支持和富有成效的团队合作:

  • William D. Dodd,软件工程师,Mobile Application Platform (bdodd@us.ibm.com)
  • William J. O'Donnell,WebSphere Foundation 安全架构师 (Bill.ODonnell@us.ibm.com)
  • Ian Robinson,杰出工程师,WebSphere Foundation 首席架构师 (ian_robinson@uk.ibm.com)
  • Srinivas R. Sama,软件工程师,IBM Worklight 支持 (srsama@us.ibm.com)
  • Tom A. Dressel,软件工程师 IBM Mobile Foundation/Worklight 支持 (tdressel@us.ibm.com)
  • Raj Balasubramanian,高级软件工程师,IBM Mobility Services 产品架构师 (raj_balasubramanian@us.ibm.com)
  • Parviz Behseta,IT 架构师,IBM 销售和经销部门 (pbehset@us.ibm.com)
  • Mark A. Smith,WebSphere 技术专业经理 (marksmith@us.ibm.com)

下载

描述名字大小
应用程序示例、配置和日志文件articlebundle_01172013.zip104MB

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=移动开发, WebSphere
ArticleID=949332
ArticleTitle=用于 FIPS 140-2 验证和认证的 IBM Worklight 服务器配置,第 1 部分: 配置一个服务器端 WebSphere Application Server 基础架构
publish-date=10212013