这个由多期文章组成的新的专栏的第一期文章将会详细探讨此功能，提供 HTML 基于
表单的登录如何部署在 DataPower 中来保护您的 Web 应用程序的实用示例。征服复杂性专栏的每一期文章都会解决一个与安全性相关的常见问题，该问题可使用 IBM
WebSphere DataPower Appliances 和其他 IBM 技术解决或简化。
简介
HTML 基于表单的登录身份验证经常可在互联网上看到。一个网站显示一个 HTML 表单，供浏览器用户提供凭据（比如用户名和密码），然后这些凭据可用于对用户访问某个 Web 应用程序的权利进行身份验证。IBM WebSphere DataPower Appliances 自 3.8.1 版开始在 Web 应用程序防火墙对象中支持 HTML 基于表单的登录。此功能作为一种一般性机制包含在第 5 版固件中的 AAA（身份验证、授权和审计）操作中。
我们看到的最常部署的用例是，将 DataPower HTML 表单登录功能部署在一个运行在 IBM WebSphere Application Server 上的 Java EE 应用程序的前面。这是一个不错的用例；DataPower 可生成一个 LTPA（Lightweight Third Party Authentication，轻量型第三方身份验证）令牌，这是 WebSphere Application Server 可理解的一种 IBM 专用的令牌格式，可将用户身份传播到应用服务器，以便可以使用它来制定授权决策或用于授权用途。但是，保护 WebSphere Application Server 上的应用程序不是 HTML 基于表单的登录的惟一用途。
本文提供一个将 DataPower 放在一个现有的未验证网站的前面的例子。在这个简单的例子中，后端是一组静态 HTML 页面，它们不需要传播身份验证信息；我们只需确保您不首先使用用户名和密码登录，就无法访问网站上的数据。未来的文章将更多地分享（在对用户执行身份验证后）您如何以一种安全方式将该信息传递到后端系统，作为一个端到端应用程序安全解决方案的一部分。DataPower 非常灵活，能够生成许多不同类型的安全令牌，这使得它成为了许多不同类型后端的前端身份验证 Web 代理的不错选择。
本文基于 DataPower 固件版本 6.0.0.3。
实现
DataPower 的 HTML 基于表单的登录实现最初基于 Java EE 规范，任何调查它的人在看到使用的表单参数的默认名称时都会很快会认识到这一点。基于表单的登录配置的大多数工作在 DataPower AAA Extract Identity (EI) 步骤中执行，不熟悉该框架的人可能不太容易理解这一点。这么做是为了为登录表单提供一个单一控制点，这个控制点被称为 HTML 表单登录策略。我们看看这样一个策略的一个简单例子。
HTML 表单登录策略
用于本文的 HTML 表单登录策略如图 1 中所示。
图 1. 一个 HTML 表单登录策略
图 1. 一个 HTML 表单登录策略
我们分析一下这个策略的每一部分。
General Source for Form-processing 配置告诉运行时，在这个实例中，您将使用静态 HTML 文件提供登录、注销和错误页面所需的 HTML 表单。还可以使用 XSL 样式表动态地生成 HTML 表单，这提供了更高的灵活性，使登录表单能够基于运行时参数而调整它的输出；例如，一种代理多个应用程序的配置可使用一个样式表来检查用户尝试访问哪个应用程序，显示一种适当个性化的外观。但是，在此练习中，无需动态生成表单。 接下来是 Redirect URL Type。对于本示例，您将使用 Host 重定向类型；这告诉运行时，在它构建一个重定向到您的一个自定义页面（比如登录页面）的 URL 时，它应该使用 HTML 主机标头的值作为它重定向到的 URL 主干。举例而言，在一些高级用例中，如果这是逆向代理链中的第二个代理，这可能不适合。在这个示例中，您可能希望告诉运行时使用 URL-in service 变量，这是下拉列表中的另一个选项；这将告诉运行时将请求基于 DataPower 变量 var://service/URL-in 的值，该值通常会使用请求所传入的 IP 地址。在大多数情况下，Host 会是更好的选择，尤其在需要考虑负载平衡的时候。 Security 此部分中的第一个指标是 Use SSL for Login，它定义您是否希望使用 SSL 执行身份验证；也就是说，您重定向到的 URL 是否应使用 HTTPS 连接到不同的端口（在 Web 上通常为 443）。仅使用 SSL 执行身份验证通常不是一种好的做法；如果需要使用 SSL，那么所有流量都应加密。因此，您通常会将此选项关闭，确保您配置的网关仅接收通过 SSL 传递的流量。如果使用一个样式表生成登录表单，SSL 选项不会出现在这里，您还应该确保您的网关仅接受通过 SSL 传递的流量。您应该始终使用一个 HTTPS 前端处理程序。对于此示例，我们通过 HTTP 展示了所有信息，所以您可以下载此示例并导入它，无需处理证书，但强烈建议所有信息都使用 SSL。 您可能认为，这个指标拥有 Enable Session Migration 这样的名称，这表明它仅在一个负载平衡的配置中有多个设备时使用。从某种程度上讲是这样的；它支持使用一个共享密钥（对称密钥加密），这样所有使用同一个密钥的设备就能够解密使用的 cookie。但是，如果不选择 Enable Session Migration 并指定一个密钥，使用的 cookie 就得不到保护。您必须在所有配置中指定一个共享密钥对象，该密钥将用于加密 cookie，否则您的 cookie 是不安全的。 Client-side URL fragments
您通过此选项告诉运行时，它在重定向到您的 HTML 基于表单的登录页面时应该使用哪些 URI。您配置登录、错误和注销页面，在发生登录、注销或身份验证错误时，运行时将基于这些 URI 生成 URL。如果用户直接访问登录页面；也就是是说，用户单击了一个直接指向登录页面的链接或在浏览器中键入完整的登录页面 URL，而不是尝试访问一个将他重定向到登录页面的受保护的资源，那么这里配置的默认 URL 是设备在身份验证后将用户重定向到的 URI。
Location of HTML pages
在这一部分中，您需要指定将用来存储您的表单的 HTML 页面的地方。此策略提供了一个从您代理的后端应用程序提供登录文件的示例。这是由维护应用程序本身的内容作者存储和更新它们的有用方式。您也可以将表单 HTML 代码直接存储在 DataPower 文件系统上的文件中，只要这么做对您的环境更合适；例如，一些组织有一条经验法则：未验证的流量完全无法绕过身份验证代理，甚至提供登录页面所需的流量。这是一条明智的法则（它最大程度地降低了风险），但它意味着这些页面必须基本独立（将 JavaScript 和级联样式表 (CSS) 嵌入到页面本身中，或者直接从网关中的一条额外规则提供它们，这增加了复杂性），它意味着这些 HTML 页面需要与您 Web 应用程序的剩余部分分开管理和分发。这里的示例页面使用了一个 CSS 来提供应用程序的相同外观，这个样式表直接从后端身份验证程序提供。
Login form properties
任何精通 Java EE 应用程序的人都会熟悉此部分的内容，至少熟悉它的默认设置（本文尚未介绍）。这些设置告诉运行时，它在提交了一个登录表单时应查找哪些参数，以便获取所提供的用户名和密码，并查找用户尝试访问的原始 URL（假设他在尝试访问一个受保护的资源后被重定向到登录页面）和登录表单所使用的 POST 操作。您可以在这里填入您喜欢的任何值 - 但是，在这里使用的任何值也必须用在登录表单本身的 HTML 中。请注意，POST 操作中使用的 URI 必须与该字符串准确匹配 – 例如，如果使用默认值 /j_security_check，那么某个提交到 /services/j_security_check 的表单将无效。
Timeouts
最后一部分定义经过验证的用户会话将保持有效的时长。这部分包括一个 Inactivity Timeout，它的默认值为 600 秒（10 分钟），还有一个 Session Lifetime，它的默认值为 1800 秒（半小时）。
这是 HTML 表单登录策略的定义。下一部分指定了您如何告诉运行时实际使用采用了 AAA 策略的策略。