DataPower 和 WebSphere Application Server 之间的 WS-Policy 安全集成

本文介绍如何配置 WebSphere DataPower SOA Appliance 和 WebSphere Application Server(WAS),从而实现 SOA 服务治理所需的 WS-Policy,把策略管理转移到 DataPower 上让 WebSphere Application Server 能够提供更好的应用程序级功能。

Russell Butek, SOA 和 Web 服务顾问, WSO2 Inc

Russell Butek 是 IBM Software Services for WebSphere 的 SOA 和 Web 服务顾问。他是 WebSphere Web 服务引擎的开发人员之一。他也是 JAX-RPC Java Specification Request (JSR) 专家组的成员,参与了 Apache AXIS SOAP 引擎的实现,并推动 AXIS 1.0 遵守 JAX-RPC。



John Rasmussen, IBM Software Services for WebSphere 的资深 I/T 专家, WSO2 Inc

John Rasmussen 是 WebSphere DataPower SOA Appliance 团队的资深 I/T 专家。他于 2001 年开始接触 DataPower 设备,当时他在金融服务业作为工程师为支持 Internet 的移动设备开发 XML/XSLT/JAXP 应用程序。在此之后,John 加入 DataPower 团队作为产品开发工程师,并作为产品专家帮助客户实现 DataPower 解决方案。John 在软件开发方面有丰富的工作经历,包括在 McCormack & Dodge/D&B Software 工作以及作为应用软件和安全系统的独立顾问和开发人员。



2010 年 2 月 11 日

简介

现在请求企业资源的用户不仅包括可信的有组织的客户,还扩展到了不熟悉的用户。由于 SOA 的成功,现在可以把企业应用程序发布为服务,以动态的方式发现和处理它们。

Web Services Description Language (WSDL) 等 SOA 规范定义了应用程序方法结构,而 IBM® WebSphere® Registry and Repository 或 Universal Description Discovery and Integration (UDDI) 等机制可以提供服务的位置和执行它们的需求。现在,可以以松散耦合的方式访问以前被局限为预定义的、硬编码的应用程序编程结构的服务。

但是,这种提供资源的新方式要求有健壮的身份验证机制。WS-Security 规范支持按照统一的元数据标准使用 Security Assertion Markup Language (SAML)、X.509 证书、Kerberos 票据、Username 和其他身份传输形式,从而提供身份验证和授权标准化。

随着这些工具的发展,服务提供者希望建立适合各种应用程序和平台的有组织的策略和治理。WS-Policy 协议和支持它的规范(比如 Web Service Policy Framework、Policy Attachment、WS-SecurityPolicy 和 WS-ReliableMessagingPolicy)力求建立一种统一的发现和消费服务的方法。这样就可以作为整体控制对服务的访问,而不必单独控制。

WS-Policy 按照机器和人都可读的格式描述安全性和服务质量需求,这有助于自动地构造服务请求。可以通过设计时决策确保把适当的凭证传递给服务。可以通过运行时决策控制各个请求的授权。重要的是,WS-Policy 实际上没有定义断言的实现,而是定义了建议断言的元数据,例如描述一个服务需要 Username。由策略决策点 (PDP) 实现解释 WS-Policy 元数据,建立要求有 Username 令牌 (UNT) 的实际断言。

本文讨论如何在 WebSphere DataPower® SOA Appliance (DataPower) 中实现和实施 PDP 配置,从而为 SOA 服务治理实现 WS-Policy。DataPower 将与驻留在 WebSphere Application Server 上的应用程序交换身份信息。通过把策略管理转移到 DataPower 上,WebSphere Application Server 能够提供更好的应用程序级功能,同时 DataPower 能够提供企业范围的高性能服务治理。

LTPA 令牌

在消息通信流中,常常使用令牌传输身份信息。令牌的例子包括 SAML、X.509 证书和 Kerberos 票据。按照 WS-Trust 规范的说明,可以使用 Secured Token Services (STS) 管理和分发令牌。

IBM WebSphere 和 IBM Lotus Domino 产品使用 Lightweight Third-Party Authentication (LTPA) 令牌。LTPA 令牌包含一个使用密钥签名和对称加密的身份,密钥具有有限的寿命,由可信的实体共享。这个过程提供很强的机密性,但是没有典型的会话密钥创建阶段(即为 SSL/TLS 等非对称加密技术使用的对称加密生成短期密钥)。在使用之前,必须在这些可信的实体之间传输共享的密钥(共享的秘密)。LTPA 令牌还用于在 WebSphere Application Server 单元内或它们之间提供单点登录 (SSO)。

在进程和 WebSphere Application Server 应用程序之间,可以通过 HTTP cookie 头或在 WS-Security Binary Security Token 中传递 LTPA 令牌。它的加密性质提供了保护其中的身份信息所需的机密性。

LTPA 令牌有多个版本。Version 1 令牌包含身份和领域信息。领域用于关联 WebSphere Application Server 对于身份验证使用的用户注册表。WebSphere Application Server V6 中引入了新的 Version 2 令牌,它包含定制的属性,但是访问和使用它需要定制编程。

当 WebSphere Application Server 或 Domino 应用程序收到 LTPA 令牌时,它不需要重新验证用户的身份,但是可能仍然需要访问用户注册表,从而创建包含组关联等信息的完整的 Subject 对象。

DataPower Appliance 可以解密和使用 LTPA 身份并创建新的 LTPA 令牌(IBM Tivoli Access Manager WebSEAL 产品也提供这种功能)。必须在 DataPower 和 WebSphere Application Server 应用程序之间管理共享的密钥,必须解决密钥寿命等问题。如果没有正确地传输新的密钥,那么自动密钥生成等 WebSphere Application Server 特性可能会导致解密失败,因此最好通过脚本过程或人工干预管理密钥的生成。因为 LTPA 令牌具有良好的性能特性,而且在 WebSphere Application Server 和 DataPower 上都支持它,所以当在 WebSphere Application Server 服务器之前设置 DataPower 时,常常使用 LTPA 令牌。

示例应用程序

DataPower 在典型的应用程序环境中扮演重要的角色。DataPower 具有专门构建的硬件优化的密码功能,它可以承担数字签名完整性检查以及消息的加密和解密等处理器密集型操作。消除这些操作的处理负担让应用程序可以更高效地执行消息处理。

为了执行身份验证和授权,客户机请求的服务可能需要凭证信息。DataPower 可以用多种身份令牌执行身份验证,包括 X.509 证书、WS-Security Username 令牌、SSL 证书和 Basic Authentication 头。可以根据 LDAP 目录等存储库或通过 IBM Tivoli Access Manager 等应用程序执行授权。

示例应用程序通过 WS-Policy 策略把身份验证和实施组合起来。在图 1 所示的拓扑中,客户机必须通过 SSL 提交包含 WS-Security Username 令牌的请求,从而确保身份信息的机密性。对身份进行验证和授权。给所有已经经过身份验证的用户分配一个组身份,这个身份存储在签名的 LTPA 令牌中。使用 DataPower 和 WebSphere Application Server 都知道的共享秘密对这个令牌进行对称加密。对称加密比非对称加密快得多。

图 1. 示例应用程序体系结构
图 1. 示例应用程序体系结构

WebSphere Application Server 收到 LTPA 令牌之后,使用共享的秘密进行解密,提取出其中的身份信息,使用此信息对请求进行身份验证并建立 JEE 身份。这个简单的应用程序只显示请求消息中包含的字符串,并在后面加上运行时提供的 JEE 身份。

使用包含 DataPower 和 WebSphere Application Server 的 PDP 实现确保遵从性。在 DataPower 中,一个策略检查 WS-Security Username 令牌是否存在。在 WebSphere Application Server 中,一个策略检查请求消息元数据中对 LTPA 令牌的需求。我们的示例首先配置 WebSphere Application Server,然后是 DataPower 实现。

配置 WebSphere Application Server

本节讨论如何通过配置 WebSphere Application Server V7 Web 服务提供者,使用 LTPA 令牌并把它设置为服务请求者的身份容器。

在 WebSphere Application Server V7 中,通过策略集和绑定配置 Web 服务的服务质量。WebSphere Application Server 的策略术语与 WS-Policy 术语稍有不同。WebSphere Application Server 所说的 “策略” 在 WS-Policy 中称为 “策略表达式” —— 一组描述规则或服务需求的元数据。WebSphere Application Server 还使用 “策略集” 这个词,这是指一组策略实例。WebSphere Application Server 有许多策略,比如 WS-Security、WS-Addressing 和 HTTP 传输。策略集把策略组合为单一的可配置实体。例如,预先打包的 WebSphere Application Server 策略集之一,即默认的 Kerberos V5 HTTPS 策略集包含 WS-Security、WS-Addressing 和 SSL transport 策略的实例。

策略集说明配置是什么,但是没有说明如何实现它。例如,它指出 SOAP 请求的请求体必须加密,但是没有指出如何加密 —— 它不提供证书密钥存储。这是绑定的任务 —— 绑定确定密钥存储等可变的信息。

可以看出在 WebSphere Application Server 中有三种要使用的实体:策略集、绑定和应用程序。把策略集附着到应用程序,然后把绑定分配给应用程序。本节的其余部分讲解如何创建策略集、创建绑定、把新的策略集附着到应用程序以及把绑定分配给相同的应用程序。

创建 LTPA 策略集

可以从头创建策略集,但是 WebSphere Application Server 预先打包了许多策略集,其中之一与我们需要的很相似:LTPA WSSecurity default。因此不需要创建策略集,而是可以复制并修改这个策略集。LTPA WSSecurity default 策略集处理 LTPA 令牌,这正是我们需要的。但是,它还对消息进行签名和加密,这不是我们需要的。不希望对消息进行签名,而是让 SSL 执行加密。图 2 显示管理控制台中开始进行复制的部分:

  1. 进入 Services => Policy sets => Application policy sets。
  2. 选择 LTPA WSSecurity default 并单击 Copy。
  3. 在下面的面板中,选择新策略集的名称,比如 LTPA over SSL。
  4. 填写您选择的描述,然后单击 OK:
    图 2. 复制预先打包的 LTPA 策略集
    图 2. 复制预先打包的 LTPA 策略集

创建自己的拷贝之后,会在策略集列表中看到它,见图 3。预先打包的策略集是不可编辑的,但是新的 LTPA over SSL 策略集 可编辑的。单击 LTPA over SSL 编辑它。图 3 所示的窗口打开。

图 3. 编辑拷贝
图 3. 编辑拷贝

图 4 显示这个策略集包含两个策略实例:WS-Addressing 和 WS-Security。需要在配置中添加 SSL:

  1. 单击 Add 下拉菜单。
  2. 从可用策略列表中选择 SSL transport。

可以通过单击新的 SSL 策略实例检查它。默认值是合适的。这样就启用了 SSL。

图 4. 编辑策略集
图 4. 编辑策略集

现在,必须编辑 WS-Policy 策略实例。在图 4 所示的窗口中,进入 WS-Security => Main policy:

图 5. 取消消息保护
图 5. 取消消息保护

在这里,必须关闭消息级保护。不需要 WS-Policy 保护,也根本不进行签名 —— 我们依靠 SSL 进行加密。在自己的 LTPA 策略集版本中只需做这些修改。

创建绑定

WebSphere Application Server 附带预先打包的默认的绑定。默认绑定同样适用于 LTPA over SSL 策略集:由 SOAP 引擎检查和消费 LTPA 令牌,对 Web 服务提供者的调用成功。但是,我们希望更进一步。在使用默认绑定时,身份由 SOAP 引擎消费,并不传递给 Web 服务实现。我们希望把调用者的身份(LTPA 令牌中包含的身份)传递给实现。所以我们需要的不只是默认绑定。

可以从头创建绑定,但是这意味着要创建许多在默认绑定中已经有的配置,所以我们将复制并编辑默认绑定。复制提供者端绑定的步骤如下:

  1. 进入 Services => Policy sets => General provider policy set bindings。
  2. 按照复制默认 LTPA 策略集的方法复制 Provider sample。把拷贝命名为 Demo provider sample。
  3. 这里有一个可选的步骤。如果希望在以后节省点儿时间,可以把 Demo provider sample 设置为默认的提供者绑定。进入 Services => Policy sets => Default policy set bindings,把 Demo provider sample 设置为默认值。
  4. 为了进行修改,进入新绑定的 WS-Security 策略实例。首先看看左边的面板:
    图 6. 创建调用者
    图 6. 创建调用者
  5. 调用者定义在实现中使用哪个令牌(如果有的话)作为调用者 ID。(消息可以不包含令牌,也可以包含多个令牌 —— 对于我们的示例,消息包含一个令牌。)单击 Caller 进入下一个面板。在默认情况下,会看到没有调用者身份。单击 New 添加调用者身份:
    图 7. 配置调用者
    图 7. 配置调用者
  6. 在这个窗口中,为调用者配置指定您喜欢的任何名称 —— 名称其实没什么意义。但是,接下来两个字段的值非常有意义 —— 要小心地输入。这两个字段定义消息中作为调用者身份的令牌的完全限定名,它们的值必须与 SOAP 消息中的值完全一样。单击 Apply。

您可能想知道究竟在哪里可以找到本地部分和名称空间字段需要的值。对于本文,我们提供这些值。但是,如果您希望使用其他令牌类型呢?如果您完全记住了各种 WS-Security 规范和这些主题的信息中心页面,就知道应该使用的值。但是,大多数人记不住这么多信息,所以在管理控制台中有向导可以替您填写这些值。可以使用这个页面作为参考:

  1. 进入包含 WS-Security 策略的任何绑定。
  2. 从这个绑定进入 WS-Security => Authentication and protection => New token (under Authentication tokens) => Token generator。
  3. 选择所需的令牌类型。
  4. 向导填写 “Local part” 和 “Namespace URI” 字段,见图 8。这些字段分别与图 7 中的 “Caller identity local part” 和 “Caller identity namespace URI” 字段对应。
    图 8. 寻找给定令牌类型的完全限定名
    图 8. 寻找给定令牌类型的完全限定名

附着策略集

在前面,已经创建了策略集和绑定。现在,必须给应用程序配置策略集和绑定。对于这个示例,使用 WebSphere Application Server 附带的 JAX-WS 示例中的 EchoService 示例的变体。(如果在安装 WebSphere Application Server 时没有安装示例,可以使用本文附带的示例版本。)

  1. 进入 Services => Service providers => EchoService,见图 9。
  2. 选择 EchoService。
  3. 单击 Attach Policy Set,从下拉菜单中选择刚才创建的策略集:
    图 9. 把 LTPA 策略集附着到提供者应用程序
    图 9. 把 LTPA 策略集附着到提供者应用程序

完成这些步骤时,LTPA over SSL 策略集显示为附着的策略集,而绑定变为默认绑定。

分配绑定

如果把 Demo provider sample 绑定设置为默认绑定,那么这里就不需要做什么了;默认绑定会自动地分配。如果没有把它设置为默认的,那么:

  1. 在图 9 所示的窗口中选择服务。
  2. 单击 Assign Binding 打开绑定菜单。
  3. 选择 Demo provider sample。

本文中使用的应用程序

本文中使用的应用程序是 WebSphere Application Server 附带的 EchoService 应用程序的变体。可以使用 WebSphere Application Server 附带的 EchoService 示例,但是对于应用程序的这个版本,我们不能证明 LTPA 令牌中的身份确实被传递给服务。为了便于演示,我们修改了 EchoService 应用程序,让它不但显示输入字符串,还显示调用者身份(见 DataPower 小节中的 清单 6),这证明身份确实从 DataPower 传递到了 WebSphere Application Server 应用程序。如果希望使用修改后的示例,可以从本文末尾部分下载它。

集成 WebSphere Application Server 和 DataPower —— LTPA 密钥文件

从 WebSphere Application Server 导出 LTPA 密钥文件

现在,已经把一个 WebSphere Application Server 应用程序配置为接收 LTPA 令牌请求消息。发送者(在这里是 DataPower)必须了解 WebSphere Application Server LTPA 配置的相关信息。这些信息存储在 LTPA 密钥文件中,所以必须导出 LTPA 密钥文件,让 DataPower 可以导入它。导出这个文件的步骤如下:

  1. 在 Authentication 下面,选择 Security => Global security => LTPA。
  2. 在 Cross-cell single sign-on 下面(见图 10),输入您选择的密码。必须记住这个密码,在把密钥文件导入到 DataPower 时需要它。
  3. 输入密钥文件名并单击 Export keys:
    图 10. 从 WebSphere Application Server 导出 LTPA 密钥文件
    图 10. 从 WebSphere Application Server 导出 LTPA 密钥文件

对于导出 LTPA 密钥,必须注意一点。WebSphere Application Server 会随着时间的推移自动地重新生成 LTPA 密钥。在导出 LTPA 密钥时,导出的文件中的密钥过一段时间就不再有效了。为了让它们一直有效,可以禁用 LTPA 密钥的自动生成。这么做之后,您就必须自己管理密钥的重新生成,不再依靠 WebSphere Application Server 替您管理。

为了禁用密钥的自动生成,在图 10 中单击面板顶部 “Key generation” 下面的 Key set groups。然后,单击您的密钥集组 —— 在这个示例中是 NodeLTPAKeySetGroup。在图 11 所示的面板中,清空 “Key generation” 下面的 Automatically generate keys 复选框。

图 11. 禁用 LTPA 密钥的自动生成
图 11. 禁用 LTPA 密钥的自动生成

把 LTPA 密钥文件导入 DataPower

把 LTPA 密钥文件装载到 DataPower Appliance 的 cert:// 目录中。在下面对 DataPower 配置的讨论中会看到设备的 Authentication, Authorization, and Auditing (AAA) 策略如何使用这个 LTPA 密钥创建 LTPA 令牌。

DataPower 配置

DataPower 的设计目的是作为 WS-Policy 的策略实施点 (PEP),在 Web Service Proxy (WSP) 服务对象中支持它。在 DataPower 固件 3.7.3 或更高版本中,支持以下 WS-Policy 规范:

  • WS-Policy 1.2 和 1.5
  • Web Service Policy Framework 和 Policy Attachment 1.5
  • WS-SecurityPolicy 1.2 和 1.5
  • WS-ReliableMessagingPolicy 1.2

WS-Policy Attachment 支持在 WSDL 文档中编写的 WS-Policy。另外,可以使用 WS-Proxy GUI 把策略附着在各种 WSDL 主题上,比如消息、服务、绑定或操作主题。通过 DataPower Appliance 的 store://policies//templates 目录中提供的模板实现对 WS-Security 等标准 WS-Policy 域的支持。还有执行标准策略操作的预定义模板,比如实施数字签名、加密、要求有 Username 令牌和使用受保护的协议。

在下面的 DataPower 配置中,要配置一个 WSP,它支持示例应用程序的需求及其与 WebSphere Application Server 应用程序实施的 WS-Policy 限制的交互。这些限制是:

  • 使用 WS-Policy 要求在客户机请求中使用 Username 令牌
  • 要求对客户机请求使用受保护的传输
  • 把 Username 令牌转换为包含 LTPA 令牌的 WS-Security 头

这个 WSP 的基本配置是确定的,所以这里的重点在于主要 WS-Policy 需求,这里忽略一些基本的无关步骤。关于基本 WSP 配置的更多信息,请参见 WebSphere DataPower SOA Appliances 文档

到达的请求消息的配置

配置 WSP 的第一步是创建 WSP 并分配 WSDL。WebSphere Application Server 上的服务使用 URL https://9.30.197.37:9443/WSSampleSei/EchoService?WSDL 公开 WSDL。获得这个 WSDL 并通过 File Management WebGUI 把它装载到设备的 local:// 目录中。图 12 显示把这个 WSDL 分配给刚才创建的 WSP UNT-LTPA-Proxy:

图 12. 把 WSDL 分配给 WSP
图 12. 把 WSDL 分配给 WSP

DataPower 还支持其他 WSDL 分配方法。可以使用 Universal Description Discovery and Integration (UDDI) 或 WebSphere Service Registry and Repository 获取 WSDL。可以使用 WebSphere Service Registry and Repository 设置查询 WSDL 更改的时间间隔。例如,如果远程服务(WebSphere Application Server 应用程序)的位置改变了,WSP 可以自动地使用新的 URL。关于 UDDI 或 WebSphere Service Registry and Repository 的更多信息,请参见 WebSphere DataPower SOA Appliances 文档

这个 WSDL 包含一个服务,这个服务公开一个用于消息通信的端口。这个端口通过 HTTPS 公开,DataPower 在这个端点上把检验过的请求转发给 EchoService。清单 1 显示 WSDL 中的服务部分:

清单 1. WSDL 服务端点分配

<wsdl:service name="EchoService">
    <wsdl:port name="EchoServicePort" binding="tns:EchoSOAP">
        <soap:address location="https://9.30.197.37:9443/WSSampleSei/EchoService"/>
    </wsdl:port>
</wsdl:service>

DataPower 可以公开多个用于接收客户机消息的前端协议端口。在这里,提供一个 HTTPS 端口。在默认情况下,远程地址包含 WSDL 端口中的端点信息。如果需要,可以修改端点,也可以动态地分配;例如,如果不同类的请求使用不同的端点,比如对于 “黄金” 客户机使用高速服务,对于一般请求使用低质量的服务提供者。通过 DataPower 策略 Route 操作或 Transformation 操作中的 XSLT 执行动态分配。图 13 显示分配的本地和远程端点:

图 13. 本地和远程端点分配
图 13. 本地和远程端点分配

本地端点处理程序是一个名为 untLTPA_HTTPS_FSH 的 Front Side Protocol Handler (FSH),这个基本的 HTTPS FSH 通过端口 8082 接收通信流。现在已经定义了一个接收 HTTPS 通信流并转发到 HTTPS://9.30.197.37:9443/WSSampleSei/EchoService 的简单 WSP。

下一个配置步骤是,使用 WS-Policy 确保客户机请求包含示例应用程序所需的 Username 令牌。所有 WS-Policy 分配都通过 WS Policy 选项卡执行。策略可以附着在 WSDL 的每个级别:服务、代理、操作和 WSDL 本身。附着之后,它应用于所有后续级别 —— 例如,附着在服务上的策略是操作级的。通过使用 WS-Policy 按钮,确保所有服务的所有通信流包含 UNT:

图 14. WSP proxy 选项卡
图 14. WSP proxy 选项卡

需要确保来自客户机的所有请求都提供 UNT。DataPower 支持 WS-SecurityPolicy 1.2。WS-SecurityPolicy 1.2 规范 包含 Username 令牌断言策略,可以使用它检查这个令牌是否存在。DataPower 作为 PDP(策略决策点),为这个和其他令牌断言策略提供实现。

在 DataPower 上的 store://policies//templates 目录中,包含一个名为 wsp-sp-1-1-usernametoken.xml 的示例模板,它基本符合我们的需求。

WS-SecurityPolicy 1.2 规范支持 UsernameToken 断言的许多变体。例如,sp:IncludeToken 属性的变体对于在请求消息和/或响应消息上是否有 UNT 提出不同的要求。DataPower 中现有的模板并不支持每种变体,所以有时候可能需要修改 DataPower 模板。有一个 DataPower 模板要求在请求和响应消息上都有 UNT。没有只要求在请求消息上有 UNT 的现有模板,但是可以创建一个这样的模板。

清单 2 显示这个策略的一部分。这个策略寻找 1.1 格式的 UNT。这个模板还包含一个寻找 1.0 格式的 UNT 的策略。

清单 2. wsp-sp-1-1-usernametoken.xml 片段

<wsp:All>
   <sp:SupportingTokens>
      <sp:UsernameToken sp:IncludeToken=
      "http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Always">
         <wsp:Policy>
            <sp:WssUsernameToken11/>
         </wsp:Policy>
      </sp:UsernameToken>
   </sp:SupportingTokens>
</wsp:All>

在 WS-SecurityPolicy 1.2 规范的 5.1.1 节 Token Inclusion Values 中,说明了由 sp:IncludeToken 属性决定的令牌预期(表 1):

WS-SecurityPolicy sp:IncludeToken 说明

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never
在发起者和接收者之间发送的任何消息中不必包含令牌;应该使用令牌的外部引用。
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Once
只在从发起者发送给接收者的一个消息中必须包含令牌。令牌的引用可以使用内部引用机制。在发起者和接收者之间发送的后续相关消息可以使用外部引用机制引用令牌。
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
在从发起者发送给接收者的所有消息中必须包含令牌。在从接收者发送给发起者的消息中不必包含令牌。
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToInitiator
在从接收者发送给发起者的所有消息中必须包含令牌。在从发起者发送给接收者的消息中不必包含令牌。
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Always
在发起者和接收者之间发送的所有消息中必须包含令牌。这是默认行为。

把值 http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Always 分配给 sp:IncludeToken 属性,就表示要求在请求和响应中都有 UNT。我们只要求在请求上有 UNT。因此,可以把 sp:IncludeToken 属性改为 http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient,这只要求在请求上有 UNT,而不要求响应上有 UNT。

我们不修改 store://policies//templates 中的策略(没有这么做的权限),而是把它复制到 local:// 并改名为 wsp-sp-1-1-usernametoken_AlwaysToRecipient.xml,然后做上述修改。

既然已经创建了定制的策略,就需要把它附着到 WSDL 的服务级别。图 15 显示单击 WS-Policy 按钮之后弹出的窗口。使用 Sources 选项卡分配策略。进入 local:// 目录,选择刚才创建的 wsp-sp-1-1-usernametoken_AlwaysToRecipient.xml 策略。

一些策略文档包含多个策略,各个策略由惟一的 wsu:Id 属性区分。当遇到这样的文档时,通过选择适当的 wsu:Id 指定要使用的策略。在这个示例中,只有一个策略。单击 Attach Source and Apply for the WSP 完成分配:

图 15. 把 WS-Policy 附着到 WSDL
图 15. 把 WS-Policy 附着到 WSDL

UNT 策略不需要任何其他信息,但是一些策略需要参数。例如,实施数字签名的策略需要得到 DataPower Crypto Certificate 的名称,才能检验签名。可以在 Processing 选项卡上分配这些参数。另外,可以通过 Enabled Subject 选项卡调整要实施策略的 WSDL 元素和消息阶段。例如,可能希望只在消息的请求阶段实施策略,而不对响应实施。

如果通过 DataPower 对这个服务提交一个没有 UNT 的简单请求,就会出现违背。清单 3 显示一个没有 UNT 的 EchoRequest:

清单 3. 没有 UNT 的 EchoRequest 示例

<?xml version="1.0" encoding="UTF-8"?>
<S11:Envelope 
    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/
       oasis-200401-wss-wssecurity-secext-1.0.xsd"
    xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
       oasis-200401-wss-wssecurity-utility-1.0.xsd" 
    xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:tns="http://com/ibm/was/wssample/sei/echo/"     
    xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <S11:Body>
        <tns:echoStringInput>
            <echoInput> Are you talkin' to me?</echoInput>
        </tns:echoStringInput>
    </S11:Body>
</S11:Envelope>

可以使用 cURL (http://www.haxx.se/) 提交这个请求并查看结果。清单 4 显示 DataPower 的响应:

清单 4. 没有 UNT 时返回的错误消息

curl -k -d @echoRequestNoUNT.xml 
https://9.33.96.224:8082/WSSampleSei/EchoService -H "Content-type: 
text/xml" -H "SOAPAction: echoOperation" --key WSTC-privkey.pem --cert WSTC-sscert.pem

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Body><env:Fault><faultcode>env:Client</faultcode><faultstring>
Required elements filter setting reject: expression /*[local-name()='Envelope' 
and (namespace-uri()='http://schemas.xmlsoap.org/soap/envelope/' 
or namespace-uri()='http://www.w3.org/2003/05/soap-envelope')]/*[local-name()='Header' 
and (namespace-uri()='http://schemas.xmlsoap.org/soap/envelope/' 
or namespace-uri()='http://www.w3.org/2003/05/soap-envelope')]//*[local-name()=
'UsernameToken' and namespace-uri()='http://docs.oasis-open.
org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd'] 
was not satisfied (from client)</faultstring></env:Fault></env:Body></env:Envelope>

在请求中添加 UNT(见清单 5),就可以满足新添加的策略的需求。UNT 添加在 wsse:Header, wsse:Security 元素中:

清单 5. 包含 UNT 的 EchoRequest

<?xml version="1.0" encoding="UTF-8"?>
<S11:Envelope xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-wssecurity-secext-1.0.xsd" 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
   oasis-200401-wss-wssecurity-utility-1.0.xsd" 
xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:tns="http://com/ibm/was/wssample/sei/echo/" 
xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <S11:Header>
        <wsse:Security>
            <wsse:UsernameToken wsu:Id="username">
                <wsse:Username>fred</wsse:Username>
                <wsse:Password>flintstone</wsse:Password>
            </wsse:UsernameToken>
        </wsse:Security>
    </S11:Header>
    <S11:Body>
        <tns:echoStringInput>
            <echoInput>Are you talkin' to me?</echoInput>
        </tns:echoStringInput>
    </S11:Body>
</S11:Envelope>

离站请求消息配置

在向 WebSphere Application Server 应用程序发送请求之前,还要做一点儿工作。WebSphere Application Server 要求 LTPA 令牌中有请求者的身份。另外,可以让多个客户机发送请求,但是 WebSphere Application Server 只针对一个应用程序用户做了配置,所以必须通过 processing 策略的 AAA 操作把经过检验的请求映射到一个被 WebSphere Application Server 接受的可识别名称。图 16 显示默认的请求规则,其中添加了 AAA 策略:

图 16. 包含 AAA 操作的代理策略
图 16. 包含 AAA 操作的代理策略

AAA 策略接收来自 UNT 的客户机凭证(见图 17),这是 AAA 操作的身份提取阶段:

图 17. AAA 操作的身份提取
图 17. AAA 操作的身份提取

在真实的应用程序中,应该使用 LDAP 等机制验证 UNT 凭证,但是这个示例使用设备上存储的 AAA Info XML 文件。图 18 显示身份验证阶段:

图 18. AAA 操作的身份验证
图 18. AAA 操作的身份验证

AAA Info 文件可以方便地为 WebSphere Application Server 分配新的凭证。可以使用 Tivoli Federated Identity Manager、Secured Conversation 等替代方法,也可以使用各种定制的方法,比如用 xPath 查询请求文档或客户 XSLT。图 19 显示来自 AAA Info 文件的映射:

图 19. AAA Info 凭证映射
图 19. AAA Info 凭证映射

AAA 处理的最后一步是把 UNT 转换为 LTPA 令牌。在这个后期处理阶段,选择 Generate LTPA Token。默认选项是把 LTPA 令牌存储在 HTTP Cookie 头中。还可以把令牌存储在 WS-Security 头元素中,这里也选择了这个选项。DataPower 提供一个下拉框 (LTPA Token Version),它用来指定 LTPA 令牌格式。目的是选择令牌版本 (V1/V2),以及是使用 HTTP Cookie 还是 Binary Security Token (BST) 包含令牌。另外,有两种 BST 形式(通常用于 Web 服务通信流),它们有不同的名称空间声明。

LTPA Token Version 选项 Domino、WebSphere Version 1 和 WebSphere Version 2 的含义很明显。WebSphere Version 1 FIPS 为 Version 1 令牌提供增强的安全性,让它符合 Federal Information Processing Standard (FIPS) 的要求(Version 2 令牌本身满足 FIPS)。WebSphere V7 Version 2 用于创建使用 wwst:LTPAv2 名称空间的 BST。目前这些值还在接受审查,所以您应该在 DataPower 产品指南中查找关于自己的固件版本的最新信息。图 20 显示 LTPA 选择:

图 20. 用于创建 LTPA 令牌的 AAA 后期处理
图 20. 用于创建 LTPA 令牌的 AAA 后期处理

正如前面在介绍 LTPA 时提到的,LTPA 令牌有多个版本。我们选择了 WebSphere V7.0 Version 2 格式。另外,把从 WebSphere Application Server 获得的 LTPA 密钥文件(参见对 WebSphere Application Server 配置的讨论)装载到设备的 cert:// 目录并输入密码。可以输入 LTPA 用户属性。需要在 WebSphere Application Server 应用程序中进行编程,才能消费和解释这些名-值对。

完成 AAA 操作之后,WSP 策略的配置就完成了。通过 DataPower Appliance 提交给应用程序的请求现在由 WSP 和 WS-Policy 检验。由 AAA 策略把 Username 令牌转换为 LTPA 令牌,然后提交给 WebSphere Application Server 应用程序。清单 6 显示一个使用 cURL 的请求和响应示例。应用程序的响应是回显的字符串和从 LTPA 令牌中提取出的用户名 (wsadmin)。

清单 6. 通过 DataPower 提交请求

curl -k -d @echoRequest.xml https://9.33.96.224:8082/WSSampleSei/EchoService -H 
"Content-type: text/xml" -H "SOAPAction: echoOperation" 
--key WSTC-privkey.pem --cert WSTC-sscert.pem

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body><ns2:echoStringResponse xmlns:ns2="http://com/ibm/was/wssample/sei/echo/">
<echoResponse>JAX-WS==>> Are you talkin' to me? (user: wsadmin)</echoResponse>
</ns2:echoStringResponse></soapenv:Body>
</soapenv:Envelope>

结束语

WS-Policy 的设计目的是提供企业范围的 SOA 治理。本文演示了如何使用和实现它以确保在 WebSphere DataPower SOA Appliance 中使用 Username 令牌,以及确保在 WebSphere Application Server 中使用 LTPA 令牌。LTPA 令牌提供身份信息,而不需要重新身份验证,是一种有效、高效的单点登录方法。

参考资料

学习

获得产品和技术

讨论

  • WebSphere 论坛
    与产品相关的论坛,可以在这里提出技术问题,与其他 WebSphere 用户分享经验。
  • developerWorks 博客
    与 developerWorks 用户、作者、IBM 编辑和开发人员交流。

条评论

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=467890
ArticleTitle=DataPower 和 WebSphere Application Server 之间的 WS-Policy 安全集成
publish-date=02112010