IBM Worklight 作为一个领先的移动应用开发和管理平台，提供了完善的安全验证框架，保证了内部应用、适配器及静态资源的安全，并且提供了很好的扩展功能，可以自定义认证器和登陆模块来进行复杂的验证。
Worklight 安全验证框架
安全框架认证流程如图 1 所示，主要包含四部分：
特定保护资源：包括内部应用、适配器（访问企业">信息系统）及静态资源。 security test：由一个或多个 ream 组成，用于资源保护。 realm：定义了处理用户验证的业务逻辑，主要包含两部分： 认证器：服务器端组件，用于收集客户端发来的用户身份信息，分为三类：基于
表单的认证器、基于适配器的认证器和基于 HTTP 头的认证器。它可以收集 HTTP request 对象的所有信息，如 cookies，body，headers 及其他属性的值。 登陆模块：服务器端组件，用于接收认证器收集到的用户身份信息，验证该身份并创建用户身份对象。当 session 结束（注销或是超时）后，登陆模块会自动销毁用户身份对象。验证逻辑可以调用企业已
有的验证框架，有多种验证方式，常见的有如下几种： Webservice 方式调用验证接口 在数据库表中
查找用户信息 使用 Websphere LTPA Token challenge handler：客户端组件，每个实例对应一个 realm，用于监测服务器端是不是在发送一个需要安全验证的请求，如果是，则收集用户身份信息，并发送至服务器端。否则验证已经完成，可以直接访问资源。
图 1. 安全框架认证示意图
在 多数情况下，我们仅需直接使用 Worklight 提供的认证器和登陆模块，如有复杂的情况，例如认证信息需要从客户端 request 的 cookie、header 和 user-agent 中获取，我们可以用 Java 来实现自己所需的认证器和登陆模块。在本例中，我们将使用认证器和登陆模块的安全验证。
基于认证器和登陆模块的安全验证简介
同 其他方式的安全验证流程类似，认证器在拦截到一个访问受保护资源的请求后，会首先检查该请求是否含有合法的用户身份，如果是，则给予访问权限，并返回请求 的数据；如果没有合法的用户身份，则启动登陆模块的验证流程，只有在验证流程成功后，才能授予访问权限，返回请求的数据。如图 2 所示。
图 2. 基于认证器和登陆模块的安全验证处理流程图
示例介绍
本文给出了一个基于自定义认证器和登陆模块的安全验证的示例，并使用该安全策略来保护适配器中的过程，读者也可以根据自己的需要使用安全策略来保护应用和静态资源。
本文的示例分为四个部分：认证器、登陆模块、适配器和客户端应用，图 3 给出了示例的请求处理流程，该处理流程同图 2 所示的标准请求处理流程类似：
图 3. 示例请求处理流程
请求访问客户端应用中的页面 Login
ModuleAuth.html。 页面中的 JavaScript 调用受保护的过程 protectResource。 安全验证框架被触发，调用认证器。 客户端页面中的 JavaScript 检查 auth
Status 属性，判断是否需要验证 如已验证，显示请求页面，显示相应的 DIV 内容，并隐藏特定的 DIV 内容，如登录输入框。至此，请求处理流程结束。 如需要验证，则显示请求页面，显示相应的 DIV 内容，如登录输入框，并隐藏特定的 DIV 内容。 用户输入相应身份信息，并触发身份验证请求，相应的登陆模块中的 login 将被触发，用于验证身份信息。 如果验证成功，则转至第 5 步。 如果验证失败，则转至第 6 步，并显示相应的错误消息。
从 开发角度看，本例的开发主要分为认证器、登陆模块、适配器和客户端应用的开发，由于只是用于演示用途，本例并未设计复杂的业务逻辑。在登陆模块中，只有简 单的认证逻辑；在客户端应用中，页面中主要分成两块，一块是在验证后才会显示的，另一块则在没有验证的时候显示。下面我们将介绍如何开发本例及相应的 Worklight 安全验证框架中的要点。