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

最新推荐文章于 2020-07-02 07:53:58 发布

cuxiong8996

最新推荐文章于 2020-07-02 07:53:58 发布

阅读量2.4k

点赞数

文章标签： java python 安全 linux 大数据

原文链接：https://www.ibm.com/developerworks/websphere/library/techarticles/0911_rasmussen/0911_rasmussen.html

版权

对企业资源的请求已扩展到不仅包括受信任的组织客户，还包括遥远而陌生的客户。 SOA的成功导致将企业应用程序发布为可以动态方式发现和处理的服务。

SOA规范（例如Web服务描述语言（WSDL））已经定义了应用程序方法结构，同时创建了诸如IBM®WebSphere®Registry and Repository或通用描述发现与集成（UDDI）之类的机制来向服务广告位置和需求执行它们。曾经局限于预定义和硬编码的应用程序编程结构的服务现在可以以松散耦合的方式访问。

资源的这种暴露伴随着确保可靠认证的努力。 WS-Security规范已经发展为支持在统一元数据标准中使用安全声明标记语言（SAML），X.509证书，Kerberos票证和用户名以及其他形式的身份传输，以提供身份验证和授权的标准化。

随着这些工具的发展，服务提供商已寻求建立与应用程序和平台无关的组织策略和治理。 WS-Policy协议及其支持的规范，例如Web Service Policy Framework，Policy Attachment，WS-SecurityPolicy和WS-ReliableMessagingPolicy，寻求建立一种统一的方法，该方法可以在发现服务时被发现和使用。这样，可以整体控制对服务组的访问，而不是单独控制。

WS-Policy以机器和人类可读的格式描述安全性和服务质量要求，以促进服务请求的自动构建。可以制定设计时决策，以确保将正确的凭据传递给服务。可以针对单个请求的授权做出运行时决策。重要的是，WS-Policy实际上并未定义断言的实现，而是定义了宣告断言的元数据，例如描述了服务需要用户名。取决于策略决策点（PDP）的实现，该实现解释WS-Policy元数据以对用户名令牌（UNT）的存在进行实际断言。

本文将通过在WebSphereDataPower®SOA Appliance（DataPower）中实现和实施PDP配置来演示用于SOA服务治理的WS-Policy的实现。 DataPower将与WebSphere Application Server上托管的应用程序交换身份信息。通过将策略管理转移到DataPower，WebSphere Application Server能够更好地提供应用程序级功能，而DataPower提供企业范围的高性能服务治理。

LTPA令牌简介

令牌通常用于在消息流量中传达身份。令牌的示例包括SAML，X.509证书和Kerberos票证。如WS-Trust规范所述，可以通过安全令牌服务（STS）管理和分发令牌。

轻量级第三方认证（LTPA）令牌由IBM WebSphere和IBM Lotus Domino产品使用。 LTPA令牌包含使用与受信任实体共享的有限生存期密钥进行签名和对称加密的身份。此过程可提供有效的机密性，而无需典型的会话密钥创建阶段，该阶段为非对称加密技术（例如SSL / TLS）使用的对称加密建立临时密钥。使用之前，必须在这些受信方之间传送共享密钥（共享机密）。 LTPA令牌还用于在WebSphere Application Server单元之内或之间提供单点登录（SSO）。

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

LTPA令牌有多种版本。版本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功能可能会导致解密失败，因此最好通过脚本化过程或手动干预来管理密钥生成。由于它们的性能功能和对WebSphere Application Server和DataPower的支持，因此当DataPower位于WebSphere Application Server服务器的前面时，通常会使用LTPA令牌。

样品申请

DataPower在典型的应用程序环境中扮演着宝贵的角色。通过使用专用的，硬件优化的加密功能，DataPower可以减轻处理器密集型操作的负担，例如数字签名完整性检查以及对消息进行加密和解密以提高机密性。减轻这种繁重的处理的负担，可使应用程序堆栈更有效地执行为其设计的消息处理。

客户端可以请求需要凭据信息的服务，以认证和授权应用程序访问。 DataPower旨在验证各种身份令牌，包括X.509证书，WS-Security用户名令牌，SSL证书和基本身份验证标头。可以针对诸如LDAP目录之类的存储库或通过诸如IBM Tivoli Access Manager之类的应用程序来执行授权。

该示例应用程序通过WS-Policy策略将身份验证与强制执行结合在一起。下面的图1显示了一种拓扑，其中客户端必须通过SSL提交包含WS-Security Username令牌的请求，以确保身份信息的机密性。身份经过身份验证和授权，可以访问应用程序。所有经过身份验证的用户都被分配了一个组标识，该组标识存储在签名的LTPA令牌中。该令牌使用DataPower和WebSphere Application Server已知的共享机密对称加密。对称加密比非对称加密快几个数量级。

图1.示例应用程序架构

一旦WebSphere Application Server接收到LTPA令牌，它将使用共享密钥进行解密，提取其中包含的身份信息，并使用它来认证请求并建立JEE身份。这个简单的应用程序仅回显包含在请求消息中的字符串，并将运行时提供的JEE身份附加到其上。

使用DataPower和WebSphere Application Server的PDP实现可确保合规性。在DataPower中，策略会验证WS-Security用户名令牌的存在。在WebSphere Application Server中，策略验证请求消息元数据中对LPTA令牌的需求。我们的示例首先配置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传输策略的实例组成。

策略集告诉您什么是配置，但不告诉您如何实现。例如，它告诉您必须对SOAP请求的主体进行加密，但不告诉您如何对其进行加密-它不提供证书密钥库。这就是绑定的目的-绑定是填充变量信息（例如密钥库）的实体。

从这个简短的介绍中，您可以看到您将使用WebSphere Application Server中的三个实体：策略集，绑定和应用程序。您将策略集附加到应用程序，然后将绑定分配给该应用程序。本节的其余部分向您展示如何创建策略集，创建绑定，将新策略集附加到应用程序以及将绑定分配给同一应用程序。

创建LTPA策略集

您可以从头开始创建一个策略集，但是WebSphere Application Server预先打包了许多策略集，其中一个几乎是您所需要的：LTPA WSSecurity缺省值。因此，您可以创建一个副本并修改该副本，而不是创建一个副本。 LTPA WSSecurity缺省策略集处理您需要的LTPA令牌。但是它也可以对消息进行签名和加密，而您不需要。除了让消息签名外，您还可以让SSL进行加密。下面的图2显示了从中开始复制的管理控制台部分：

导航到服务=>策略集=>应用程序策略集。
选择“ LTPA WSSecurity默认值”，然后单击“复制”。
在随后的面板中，为新策略集选择一个名称，例如LTPA over SSL。
填写您的选择的描述，然后单击确定：
图2.复制预先打包的LTPA策略集

您已经创建副本后，你会看到它在策略集列表，如图3预先打包的策略集是不可编辑，但你新的LTPA over SSL策略集是可编辑的。单击SSL上的LTPA进行编辑。打开图4中的窗口。

图3.编辑副本

图4显示了您的策略集由两个策略实例组成：WS-Addressing和WS-Security。您需要将SSL添加到配置中：

点击添加下拉菜单。
从可用策略列表中选择SSL传输。

您可以通过单击来检查新的SSL策略实例。默认值已足够。这就是启用SSL所需要做的一切。

图4.编辑策略集

现在，您必须编辑WS-Security策略实例。从图4的窗口中，导航到WS-Security => Main policy：

图5.删除消息保护

我们必须在这里做的是通过取消选中该框来关闭消息级保护。您没有在进行WS-Security保护，也没有在进行签名-而是依靠SSL进行加密。这就是我们在您的LTPA策略集版本中所做的所有更改。

创建绑定

WebSphere Application Server带有预先打包的默认绑定。缺省绑定对于LTPA over SSL策略集照常工作：LTPA令牌已由SOAP引擎验证和使用，并且对Web服务提供者的调用成功。但是，我们想更进一步。使用默认绑定，身份由SOAP引擎使用-不会传递给Web服务实现。我们希望将调用者的身份（LTPA令牌中包含的身份）传递给实现。因此，我们需要的比默认绑定更多。

我们可以从头开始构建绑定，但这意味着要构建默认绑定中已经存在的许多配置，因此我们将制作一个副本并编辑该副本。要复制提供方绑定：

导航到服务=>策略集=>常规提供程序策略集绑定。
复制提供程序样本的方式与复制默认LTPA策略集的方式相同。命名复制演示提供程序示例。
此时，作为可选步骤，如果您希望将来节省一些时间，可以将Demo提供程序示例设置为默认提供程序绑定。导航到服务=>策略集=>默认策略集绑定，并将演示提供程序样本设置为默认值。
要进行更改，请进入新绑定的WS-Security策略实例。您将首先看到左侧面板：
图6.创建调用者
调用方定义将哪个令牌（如果有）用作实现中的调用方ID。（一条消息可能带有零个或多个令牌-在我们的示例中，它将带有一个。）单击“呼叫者”，转到下一个面板。默认情况下，您可以看到没有呼叫者身份。要添加一个，请单击“新建”：
图7.配置调用者
在此窗口中，为呼叫者配置提供所需的任何名称-名称实际上并不重要。但是，接下来两个字段中的值非常重要-小心错别字。这两个字段定义了消息中令牌的完全限定名称，以用作调用者身份，并且这些值必须与SOAP消息中的值完全匹配。单击“应用”。

您可能想知道在哪里可以找到本地部分和名称空间字段的正确值。对于本文，我们提供了它们。但是，如果要使用其他令牌类型，值是什么？如果您完全记住了有关这些主题的各种WS-Security规范和信息中心页面，则只知道它们是什么。但是我们大多数人无法掌握那么多信息，因此管理控制台中有一个地方可以由向导为我们填写这些值。您可以将该页面用作参考：

导航到具有WS-Security策略的任何绑定。
从该绑定导航到WS-Security =>身份验证和保护=>新令牌（在Authentication令牌下）=>令牌生成器。
选择所需的令牌类型。
该向导将填写“ Local part”和“ Namespace URI”字段，如下面的图8所示。这些字段分别对应于上面图7中的面板上的“呼叫者身份本地部分”和“呼叫者身份名称空间URI”字段。
图8.查找给定令牌类型的全限定名称

附加策略集

在前面的部分中，您创建了一个策略集和一个绑定。现在，您必须使用该策略集和绑定配置应用程序。对于此示例，请使用EchoService示例的变体，该示例是WebSphere Application Server随附的JAX-WS示例的一部分。（如果您在安装WebSphere Application Server时选择不安装样本，那么您可以使用本文随附的该样本的版本。）

导航到Services => Service provider => EchoService，如下图9所示。
选择EchoService。
单击附加策略集，然后从下拉菜单中选择新创建的策略集：
图9.将我们的LTPA策略集附加到提供者应用程序

完成这些步骤后，LTPA over SSL策略集显示为已附加策略集，并且绑定将为默认绑定。

分配绑定

如果将演示提供程序样本绑定设置为默认绑定，则无需在此处做任何事情；默认绑定是自动分配的。如果尚未将其设置为默认值，则：

在上面的图9所示的窗口中选择服务。
单击分配绑定以下拉绑定菜单。
选择演示提供程序示例。

本文中使用的应用程序

如前所述，本文使用的应用程序是EchoService应用程序的变体，它是WebSphere Application Server随附的示例的一部分。您可以自由使用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以后可以导入它。要导出此文件：

在认证下，选择安全性=>全局安全性=> LTPA。
在跨单元单点登录下（如下图10所示），输入您选择的密码。将密钥文件导入DataPower时，必须记住该密码。
输入密钥文件名，然后单击导出密钥：
图10.从WebSphere Application Server导出LTPA密钥文件

如果导出LTPA密钥，则必须注意一件事。 WebSphere Application Server会随着时间的推移自动重新生成LTPA密钥。当您导出LTPA密钥时，有时导出文件中的密钥将不再起作用。为了使它们正常工作，您可以禁用自动生成LTPA密钥。执行此操作时，现在必须自己管理密钥的再生，而不是依靠WebSphere Application Server来为您完成。

要禁用自动重新生成密钥，在图10中，单击面板顶部“密钥生成”下的密钥集组。然后单击您的密钥集组-在此示例中为NodeLTPAKeySetGroup。在图11所示的面板中，清除“密钥生成”下的自动生成密钥复选框。

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

将LTPA密钥文件导入DataPower

将LTPA密钥文件加载到DataPower Appliance的cert：//目录中。您将在DataPower配置讨论中看到设备的身份验证，授权和审核（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服务策略框架和策略附件1.5
WS-SecurityPolicy 1.2和1.5
WS-ReliableMessagingPolicy 1.2

WS-Policy Attachment支持WSDL文档中编写的WS-Policy。另外，可以使用WS-Proxy GUI将策略附加到各种WSDL主题，例如消息，服务，绑定或操作主题。对标准WS-Policy域（例如WS-Security）的支持是通过DataPower Appliance的store：// policies // templates目录中提供的模板实现的。您将在其中找到预定义的模板，以执行标准的策略操作，例如执行数字签名，加密，用户名令牌的存在以及在其他策略模板中使用安全协议。

在下面的DataPower配置中，您将配置一个WSP以支持示例应用程序的需求及其与WebSphere Application Server应用程序施加的WS-Policy限制的交互。这些是：

使用WS-Policy在客户端请求上要求用户名令牌
根据客户要求要求安全运输
使用LTPA令牌将用户名令牌转换为WS-Security标头

假定WSP的基本配置，所以这里的重点是主要的WS-Policy要求，并且未显示一些基本的不相关步骤。有关基本WSP配置的更多信息，请参阅WebSphere DataPower SOA Appliances文档或WebSphere DataPower SOA Appliance Handbook 。

传入请求消息配置

配置WSP的第一步是创建WSP并分配WSDL。 WebSphere Application Server上的服务使用URL https://9.30.197.37:9443/WSSampleSei/EchoService?WSDL公开WSDL。 WSDL已获得，并通过文件管理WebGUI加载到设备的local：//目录中。图12显示了将WSDL分配给新创建的WSP UNT-LTPA-Proxy：

图12. WSDL分配给WSP

DataPower支持WSDL分配的替代方法。您可以使用通用描述发现和集成（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中的service部分：

清单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策略“路由”操作或在“转换”操作的XSLT中执行的。图13显示了本地和远程端点的分配：

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

本地终结点处理程序是名为untLTPA_HTTPS_FSH的前端协议处理程序（FSH），这是一个基本的HTTPS FSH，它可以通过端口8082接受通信。您现在已经定义了一个简单的WSP，它可以接受HTTPS通信并将其转发到HTTPS://9.30.197.37。：9443 / WSSampleSei / EchoService。

下一步配置步骤是使用WS-Policy确保客户端请求包含示例应用程序所要求的Username令牌。所有WS-Policy分配都是从WSP Policy选项卡进行的。可以将策略附加到WSDL的每个级别：服务，代理，操作以及WSDL本身。连接时。它将在所有后续级别上执行-例如，服务附带的策略是操作级别。您需要确保所有服务的所有流量都包含UNT，您可以通过WS-Policy按钮执行此操作：

图14. WSP代理选项卡

这些要求是为了确保应客户的所有请求提供UNT。如前所述，DataPower支持WS-SecurityPolicy 1.2。 WS-SecurityPolicy 1.2规范包含可用于断言此令牌存在的用户名令牌断言策略。作为PDP（策略决策点）的DataPower提供了此令牌声明策略和其他令牌声明策略的实现。

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节中，令牌包含值是对sp：IncludeToken属性所确定的令牌期望的以下描述（表1）：

WS-Security Policy sp：IncludeToken描述

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/从不

令牌不得包含在发起者和接收者之间发送的任何消息中；相反，应该使用对令牌的外部引用。

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，而无需响应。

与其在store：// policies // templates中修改策略（您无权执行），而是将其复制到local：//，然后重命名为wsp-sp-1-1-usernametoken_AlwaysToRecipient.xml以及上述的AlwaysToRecipient更改。

现在，您已经创建了自定义策略，需要将其附加到WSDL的服务级别。图15显示了单击WS-Policy按钮得到的弹出窗口。 Sources选项卡用于分配策略。导航到local：//目录，可以选择新创建的wsp-sp-1-1-usernametoken_AlwaysToRecipient.xml策略。

某些策略文档将包含多个策略，这些策略由唯一的wsu：Id属性来区分。遇到此类文档时，请通过选择适当的wsu：Id来指定要使用的文档。在此示例中，只有一个。单击附加源并申请WSP以完成分配：

图15.将WS-Policy附加到WSDL

UNT策略不需要任何其他信息，但是某些策略需要参数才能完成。例如，强制执行数字签名的策略要求使用DataPower加密证书的名称来验证签名。 “处理”选项卡允许分配这些属性。此外，“启用的主题”选项卡使您可以微调实施策略的WSDL元素和消息阶段。例如，您可能希望只对消息的请求阶段执行策略，而不对响应执行策略。

如果在没有UNT的情况下通过DataPower向此服务提交简单请求，则会发生违规。清单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>

如清单5所示，在请求中添加UNT应该可以满足新添加策略的要求。 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，因此您必须通过处理策略的AAA操作将经过验证的请求映射到WebSphere Application Server接受的专有名称。图16显示了带有AAA策略的默认请求规则：

图16.具有AAA操作的代理策略

AAA策略从UNT接受客户端的凭据，如图17所示，它演示了AAA操作的身份提取阶段：

图17. AAA动作身份提取

虽然实际应用程序将使用诸如LDAP之类的机制来验证UNT凭据，但本示例使用了存储在设备上的AAA Info XML文件。图18显示了身份验证阶段：

图18. AAA操作认证

The AAA Info file provides a convenient way to assign the new credential for WebSphere Application Server. You can use alternative methods, such as Tivoli Federated Identity Manager, Secured Conversation, or various custom methods, such as xPath inquiry into the request document or customer XSLT. Figure 19 shows the mapping from the AAA Info file:

Figure 19. AAA info credential mapping

The final step in AAA processing is converting the UNT to the LTPA token. In this post-processing phase, Generate LTPA Token has been selected. The default option is to store the LTPA Token in an HTTP Cookie header. Optionally, the token can be stored in the WS-Security header element, and that option has been chosen here. DataPower provides a dropdown box (LTPA Token Version), which is used to designate the LTPA token format. The goals are to select the token version (V1/V2), and whether to use an HTTP Cookie or a Binary Security Token (BST) to contain the token. In addition there are two forms of BST (typically used with Web service traffic) available with different namespace declarations.

The LTPA Token Version options of Domino, WebSphere Version 1 and WebSphere Version 2 are self evident. WebSphere Version 1 FIPS provides enhanced security compliant with the Federal Information Processing Standard (FIPS) for the Version 1 token (the Version 2 token is inherently FIPS compliant). And WebSphere V7 Version 2 is used to create a BST with the wwst:LTPAv2 namespace. These values where undergoing review when this article was published, so you should check the DataPower product guides for the latest information on your firmware revision. Figure 20 shows the LTPA selection:

Figure 20. AAA post-processing for LTPA token creation

Referring back to the LTPA introduction, there are multiple versions of the LTPA Token. We've selected the WebSphere V7.0 Version 2 format. In addition, the LTPA Key File as obtained from WebSphere Application Server (see discussion under WebSphere Application Server configuration) is loaded onto the device's cert:// directory and the password is entered. LTPA User Attributes could have been entered. These name-value pairs require application programming in the WebSphere Application Server application for consumption and interpretation.

Completing the AAA action finalizes the configuration of the WSP policy. Requests submitted to the application through the DataPower appliance are now validated by the WSP and the WS-Policy. Username tokens are converted to LTPA Tokens by the AAA policy and submitted to the WebSphere Application Server application. Listing 6 shows an example of a request and response using cURL. The application responses with the echoed string and the username (wsadmin) as extracted from the LTPA Token.

Listing 6. Submission of request through 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 has been designed to provide enterprise-wide SOA governance. This article demonstrated its use and implementation within the WebSphere DataPower SOA Appliance for the enforcement of Username Tokens and within WebSphere Application Server for the enforcement of LTPA tokens. LTPA tokens are an effective and efficient method of single sign-on, by providing identity information that does not need to be re-authenticated.

翻译自: https://www.ibm.com/developerworks/websphere/library/techarticles/0911_rasmussen/0911_rasmussen.html