基于 WebSphere DataPower SOA Appliances 构建 Web 服务安全网关
本文简要地介绍了 DataPower 的功能特点，并着重阐述了如何基于 DataPower 构建 Web 服务安全网关，并通过具体场景及配置过程示例展示并证明了 DataPower 作为 Web 服务安全网，可有效地满足 Web 服务安全网在访问合法性，数据机密性和完整性这三方面的需求。
1 WebSphere DataPower SOA Appliances 简介
IBM WebSphere DataPower SOA Appliances（以下简称 DataPower）是IBM 针对面向服务架构（SOA）所推出的又一重要产品。
随着越来越多的企业采用 SOA 提高业务的灵活性，它们发现 XML 和 Web 服务――这些当前 SOA 的基础――带来了性能瓶颈、安全风险以及营运、架构和基础设施方面复杂的工作。DataPower 正是针对这些业界的实际需求应运而生。DataPower 是设计独特，易于部署的 SOA 专用设备（1U，可机架式安装），它面向XML-Aware Network，通过以太网与外部系统进行连接，通过简单的配置（无需编写程序）即可无缝地连接到现有的 IT 基础架构中，为简化 XML 应用和 Web 服务部署、提高系统性能和增强 SOA 实施的安全性等都提供了强大的支持。
DataPower提供的主要功能包括：
- 帮助确保 Web 服务的安全――包括 XML 安全保护功能、XML 加密、数字签名、WS 安全、XML 访问控制、联合身份管理。
- 面向SOA，支持大型机和旧式应用程序――异构消息之间的转换、协议桥接。
- 网络集线器式的仲裁服务和轻便的消息代理服务――快速的、可扩展的消息转换、路由以及日志服务。
- Web 服务管理――服务级管理、内部安全、WSDM。
- “线速（wire speed）”地加速动态门户―― XML 向 HTML 转换。
DataPower产品家族主要包括如下三款产品：WebSphere DataPower XA35，WebSphere DataPower XS40和WebSphere DataPower XI50。它们的功能分别侧重于XML任务处理加速、XML/Web服务安全和企业消息总线及应用程序集成，详细的产品介绍请参考IBM中国网站的 DataPower主页。
图1.1 WebSphere DataPower 产品家族
目前，DataPower已经服务于IBM全球众多的关键客户，在SOA的架构中扮演着越来越重要的角色，下面，本文将着重介绍如何基于DataPower构建Web服务的安全网关。
2 基于 DataPower 的 Web 服务安全网关
作为安全网关，应具备满足如下安全需求的能力：
- 确保访问的合法性：访问者身份的认证与授权的能力；
- 确保数据的机密性：传输数据的加密与解密的能力；
- 确保数据的完整性：基于数字签名技术的数据签名及验证的能力。
对于Web服务的安全网关，需要针对Web服务安全需求的特点，有效地支持Web 服务安全性（WS-Security）规范中定义的满足以上三个需求的安全机制：安全性令牌传播机制、消息完整性机制和消息机密性机制。具体来讲，主要包括支持SOAP安全性元素并实现通过其内容进行访问合法性的检验，实现SOAP消息数字签名及校验，实现SOAP消息的加密与解密等。
Web服务安全网关是DataPower在SOA中所扮演的重要角色之一，DataPower实现了一个灵活有效的认证，授权及审计（AAA：Authentication，Authorization，Audit）的框架。任何SOAP的消息在到达DataPower之后，该框架会分别抽取客户端所要访问的资源和认证标识信息。其中资源可以是URL，Web服务的方法，甚至可以是消息体中任意部分所表示的内容等；对于认证标识，支持SAML token，WS-Security token，SSL客户端证书以及HTTP Basic Auth等多种安全性元素。
图2.1 DataPower 的 AAA 框架
对于取得的用户标识，DataPower可以通过内部定制的访问控制策略或者外部的访问控制服务器（例如Tivoli Access Manager、Tivoli Federated Identity Manager、RSA ClearTrust及CA eTrust等），进行用户认证。对于通过认证的用户，DataPower将进一步通过访问控制文件或者外部的访问控制服务器确认该用户是否对所请求的资源具有访问权限，如通过授权验证，DataPower还将提供审计功能，再将该消息发送给服务提供者。为了适应各种访问控制器或其他系统定义的访问控制策略，DataPower可以依据定制的规则将源SOAP消息中包含的访问资源以及用户的标识映射成其他目标形式，因此，DataPower易于与各种访问控制服务器进行集成，而无需修改访问控制器原有的配置，同时也能够在不同系统之间灵活地传播不同形式的安全性令牌。
同时，DataPower完全支持包括WS-Security在内的多种Web服务规范，包括SOAP、WSDL、UDDI、WS-Federation、WS-Trust、WS-SecureConversation以及WSDM等，还包括其他相关的安全性标准，例如：SAML1.0/1.1/2.0，XKMS，Rradius，LDAP等。在此基础上，DataPower支持XML/SOAP的加密解密以及数字签名，可以实现从整个消息体到任意字段的加密解密及数字签名，也可以实现对SOAP附件的加密。
以上各种功能已经集成在DataPower的Web Service Proxy服务中，通过将需要保护的Web服务的WSDL描述文件上传到DataPower上，再经过简单的配置，DataPower就可以生成针对该Web服务的Web Service Proxy服务。在有效实现访问控制，确保数据的完整性和机密性的基础上，Web Service Proxy服务支持SSL，支持对基于XML攻击的防护，支持基于XPATH对SOAP消息体的过滤，支持监控及服务级别的管理，这些特性都进一步扩展了安全网关的能力。
图2.2 服务级别管理：通过Web的管理控制台，可以对Web服务的访问情况进行监控，并依据预先制定的策略对客户端的请求进行不同的处理（如：notify，shape或Throttle）。
总体来看，DataPower在功能上可以有效满足Web服务安全的各项需求；内置的高性能XML处理芯片，可以使DataPower几乎线速地完成各种XML/Web服务任务；同时，作为硬件产品和封闭系统，DataPower也具有更高的可靠性和安全性，并支持集群架构，满足高可用性的需求；此外，DataPower全部功能的实现仅需要通过配置即可完成，作为SOA专用设备，它可以通过以太网非常便捷地嵌入客户现有的系统架构中，无需客户修改应用代码，无需修改现有IT系统的架构，并大大简化应用的开发工作，降低系统管理与维护的成本。
3 构建Web服务安全网关示例
通过基于DataPower实现Web服务安全网关，我们可以构建出一套完整的、提供端到端安全性的Web服务安全解决方案。下面，我们将通过一个简单的Web服务安全解决方案的构建过程，进一步说明并证明DataPower做为Web服务安全网关的独特能力。
3.1 场景说明
在下面解决方案中，Web服务客户端发送的SOAP消息Header中，带有Web 服务安全性（WS-Security）规范中定义的UsernameToken形式的安全令牌，其中包含了用户名和口令，以提供给Web服务安全网关进行认证与授权，确保访问的合法性；整个消息体通过WSSec方法进行数字签名，签名及验证所需的公钥等信息附于SOAP消息Header中，提供给Web服务安全网关进行签名验证，确保消息的完整性；客户端与安全网关之间采用HTTPS协议传输SOAP消息，保证了消息的机密性。
图3.1 示例场景
为提高解决方案的安全性，Web服务安全网关应部署与DMZ区中，它在接到客户端的SOAP消息后，首先要对SOAP消息进行数字签名验证，然后获取用户认证信息和请求的资源信息，并通过SSL连接访问控制器，进行用户身份验证和访问授权验证，对于通过以上验证的SOAP消息，Web服务安全网关将除去消息体中相关的安全性元素，再将其通过HTTP协议发送给安全域中的Web服务提供者。当Web服务提供者返回消息时，Web服务安全网关为保证消息的完整性，也可以对消息体进行数字签名等操作，再通过HTTPS将消息发回客户端，确保消息的机密性。
3.2 方案构建及DataPower配置示例
在如下的方案示例中，我们通过三台PC机和一台DataPower XI50模拟以上场景，具体如图3.2所示：
图3.2 示例方案架构
- Web服务提供者：通过部署在WebSphere应用服务器v6上的Web服务应用程序OrderTicketService对外提供三个Web服务：OrderAirTicketService，OrderFootballTicketService和OrderTrainTicketService。
- Web服务客户端：采用cURL工具和预先编写好的SOAP消息文件来模拟Web服务客户端。cURL由瑞典curl组织开发的，它是一种利用URL语法在命令行方式下工作的文件传输工具。它支持很多协议：FTP，FTPS，HTTP，HTTPS，TELNET以及LDAP等（通过访问[url]http://curl.haxx.se/[/url]获取可以它的源代码和相关说明）。在下面示例中需要应用的SOAP消息文件说明如下：
表3.1
| 文件 | 对应的Web服务 | 包含的安全元素 |
|---|---|---|
| AirTicket.xml | OrderAirTicketService | 无 |
| AirTicket_ut.xml | OrderAirTicketService | UsernameToken |
| AirTicket_ut.xml | OrderAirTicketService | UsernameToken，数字签名 |
| FootBallTicket.xml | OrderFootBallTicketService | 无 |
| FootBallTicket_ut.xml | OrderFootBallTicketService | UsernameToken |
| FootBallTicket_ut.xml | OrderFootBallTicketService | UsernameToken，数字签名 |
| TrainTicket.xml | OrderTrainTicketService | 无 |
| TrainTicket_ut.xml | OrderTrainTicketService | UsernameToken |
| TrainTicket_ut.xml | OrderTrainTicketService | UsernameToken，数字签名 |
- 访问控制服务器：采用IBM Tivoli Access Manager（以下简称TAM）实现访问控制，在TAM中预先定义了三个用户userA，userB和userC，以及它们对三个Web服务的权限（在TAM中，Web服务以URL的形式表示）：
表3.2
| Web服务 | 具有访问权限的用户 |
|---|---|
| OrderAirTicketService: OrderAirTicket/services/OrderAirTicketService | userA，userB，userC |
| OrderFootBallTicketService: OrderFootBallTicket/services/OrderFootBallTicketService | userB，userC |
| OrderTrainTicketService: OrderTrainTicket/services/OrderTrainTicketService | userC |
- Web服务安全网关：通过DataPower上的Web Service Proxy服务实现。以下将逐步详细介绍DataPower实现Web服务安全网关的配置及验证过程。
3.2.1 构建Web Services Proxy服务
首先，通过DataPower的Web管理控制台，创建一个名为WSP4SecurityGWDemo的Web Services Proxy服务，并在其WSDLs项目中，将描述Web服务OderAirTicketService的WSDL文件OderAirTicketService.wsdl上载到DataPower上，如图3.3所示：
图3.3
其次，修改OderAirTicketService的Remote Hostname为Web服务提供者的IP地址：9.181.50.166，并为其创建名为HPFH4GW，类型为HTTP Front Side Handler的Local endpoint handler，并为其设置port为9080。这里，Local endpoint handler将负责接受客户端的请求。如图3.4所示：
图3.4
在其他设置都保持默认，应用并保存设置后，WSP4SecurityGWDemo就已经可以作为OderAirTicketService的代理开始工作了。通过在Web服务客户端上输入如下命令，即可测试WSP4SecurityGWDemo是否工作正常。
curl --data-binary @AirTicket.xml |
得到如图3.5所示的结果，则证明WSP4SecurityGWDemo工作正常。
图3.5
重复上面步骤可以将另两个Web服务加入到WSP4SecurityGWDemo中。通过如下命令，即可对另两个Web服务进行相应的测试。
curl --data-binary @FootBallTicket.xml |
以上生成的Web Service Proxy仅仅提供了代理的基本功能，下面我们将分步实现SSL连接，访问控制和数字签名的功能。
3.2.2 实现基于SSL的SOAP消息传输
为实现客户端与DataPower之间基于HTTPS的SOAP消息传输，我们仅需要为WSP4SecurityGWDemo创建类型为HTTPS Front Side Handler的Local endpoint handler，并替换HPFH4GW即可。为支持SSL连接（这里我们采用单向的SSL），服务端需要配置用于加密信息的密钥对，并为客户端提供数字证书。这里我们通过DataPower提供的Crypto tool来生成密钥和自签署证书。
如图3.6所示，在Crypto tool的Generate Key项目中，输入Key的常规信息，并选择Generate self-signed certificate，同时common name应指定为DataPower的IP地址或hostname，然后点击“Generate Key”按钮，生成密钥和证书。
图3.6
通过DataPower File Management工具，如图3.7所示，可以从DataPower的temporary目录下载名为SecurityGWDemo-sscert.pem的证书文件到Web服务的客户端，以提供给cURL工具用于与DataPower建立SSL连接。
图3.7
为创建类型为HTTPS Front Side Handler的Local endpoint handler，需要先为其创建Crypto profile对象，该对象定义了SSL认证方式和对应的密钥，如图3.8所示，在名为CP4SecurityGWDemo的Crypto profile中，我们仅需要指定Identification Credentials及其包含的密钥及证书即可，这里密钥及证书的显示名称为其common name。
图3.8
完成以上步骤后，如图3.9所示，创建名为SSLFSH4GW，类型为HTTPS Front Side Handler的Local endpoint handler时，仅需要指定端口并选择Crypto profile对象即可。这里端口指定为9443。再用SSLFSH4GW为每个Web服务替换原有Local endpoint handler――HFSH4GW，在保持其他默认设置并应用保存设置后，WSP4SecurityGWDemo即可实现与客户端SSL连接，HTTP连接和无法通过认证的SSL连接都将被拒绝。
图3.9
通过在Web服务客户端上输入如下命令，即可测试WSP4SecurityGWDemo与Web服务客户端的SSL连接是否工作正常。
curl --cacert SecurityGWDemo-sscert.pem --data-binary @AirTicket.xml |
如图3.10所示，原有的HTTP连接将被DataPower拒绝，通过SSL认证的HTTPS连接可以被DataPower接受并转发给Web服务的提供者，并返回正确的结果。由此，通过HTTPS协议保证了传输过程中数据的机密性。
图3.10
通过如下命令，可以通过HTTPS对另两个Web服务进行访问。
curl --cacert SecurityGWDemo-sscert.pem --data-binary @FootBallTicket.xml |
3.2.3 实现访问控制
在本场景中，我们采用TAM作为访问控制器，DataPower从SOAP消息中取得用户标识和需要访问的目标资源都需要通过TAM进行认证和授权。为实现访问控制，需通过如下步骤完成：
1．配置TAM对象：通过DataPower的Web控制台提供了如下的配置向导，如图3.11所示，在TAM配置文件生成向导中填写了所有必要内容后，DataPower将会自动从TAM中取得与TAM进行SSL连接所必须的数字证书，并在本地生成相应的密钥文件。
图3.11
此外，在配置向导中还需要配置Authorization Server Replica，如图3.12所示。在完成以上步骤并保存配置后，即完成了名为tam的TAM对象配置。
图3.12
2．为WSP4SecurityGWDemo配置AAA action：在Web Service Proxy的Policy项目中，可以在不同层次上配置SOAP消息的处理规则（rule），每个规则可由多个action组成，每个action负责对SOAP消息进行不同的处理，由此，整个rule就可以构成一个对SOAP消息的处理流程。其中AAA action负责处理认证、授权和审计的操作。如图3.13所示，我们为request-rule添加AAA action，双击AAA图标，即可通过提供的向导进行必要配置。
图3.13
这里我们为AAA action定义了名为AAA4SecurityGWDemo的policy，该policy包括了如下内容：
1）抽取用户标识的方式：为支持Username令牌，选择“password-carrying Username Token Element from WS-security Header”。如图3.14所示，通过该向导，我们可以同时选择多种抽取用户标识的方式，以支持不同的客户。
图3.14
2）用户的认证方式：如图3.15所示，选择“Contact Tivoli Access Manager”，并在Tivoli Access Manager Configuration中选择“tam”。
图3.15
3）抽取被访问资源的方式：由于在TAM中，我们定义的被保护的资源形式为URL，因此，如图3.16所示，这里选择“URL Sent to Back End”。通过该向导，我们可以同时选择多种抽取被访问资源的方式，以支持不同的客户。
图3.16
4）授权认证方式：如图3.17所示，选择“Contact Tivoli Access Manager”，并在Tivoli Access Manager Configuration中选择 “tam”，其余项目保持默认值。完成以上设置后，在此场景中，AAA policy的其他设置保持默认设置即可。
图3.17
3、除去SOAP消息体中的安全性元素：当SOAP消息通过了AAA验证之后，即可除去消息体中的安全性元素，将其发送给后端的Web服务提供者。在Web Service Proxy的Policy项目中，可在AAA action之后，为request-rule添加Transform action，此类action可以通过指定的XSLT文件对SOAP消息进行任意形式的格式转换，在此，我们通过如下的delelteSecurityElements.xslt实现除去SOAP消息体中的安全性元素。
<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" |
将delelteSecurityElements.xslt上载到DataPower上后，通过双击Transform action图标即可对其进行必要配置。如图3.18所示，该配置过程中，仅需要将delelteSecurityElements.xslt指定为“Processing Control file”，其他设置保持默认值即可。
图3.18
通过以上三个关键步骤的配置，WSP4SecurityGWDemo已经具备了对Web服务客户端的请求进行身份及授权认证的功能，我们通过以下的命令可对此进行验证：
curl --cacert SecurityGWDemo-sscert.pem --data-binary @AirTicket_ut.xml |
在AirTicket_ut.xml，FootBallTicket_ut.xml和TrainTicket_ut.xml中，除了原有的SOAP消息体外，所包含了带有Username令牌的wsse:Security安全元素。其中，每个文件中Username令牌都带有对相应的Web服务具有访问权限的用户名和口令，因此，以上3条命令都将会得到Web服务提供者正确的相应。如果任意修改文件中用户名及口令，或以不具备访问权限的用户对Web服务发送请求，都将无法通过DataPower的验证而被拒绝，从而保证了访问的合法性。
例如，将FootBallTicket_ut.xml中的用户UserB的口令从userB4demo改为userBb4demo，再向DataPower请求OrderFootBallTicketService时，如图3.19所示，该请求将无法通过DataPower的用户验证而被拒绝。
<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" |
图3.19
3.2.4 实现数字签名验证
在DataPower中，数字签名的验通过Verify Action来实现，如图3.20所示，通过Web控制台，在Web Service Proxy的Policy项目中，为request-rule添加Verify action，全部设置保持默认值即可。
图3.20
通过以上配置，WSP4SecurityGWDemo已经具备了对Web服务客户端的请求进行数字签名验证的功能，我们通过以下的命令可对此进行验证：
curl --cacert SecurityGWDemo-sscert.pem --data-binary @AirTicket_ut_ds.xml |
其中AirTicket_ut_ds.xml，FootBallTicket_ut_ds.xml和TrainTicket_ut_ds.xml，是AirTicket_ut.xml，FootBallTicket_ut.xml和TrainTicket_ut.xml通过WSSec方法进行数字签名后得到的SOAP文件，以上三条命令都会得到Web服务提供者正确的相应，如果修改上述三个SOAP文件中的任意部分或对于没有数字签名的SOAP消息，都将无法通过DataPower的签名验证而被拒绝，从而保证了数据的完整性。
例如，将TrainTicket_ut_ds.xml中的listprice从500.0改为501.0，再向DataPower请求OrderTrainTicketService时，如图3.21所示，该请求将无法通过DataPower的数字签名验证而被拒绝。
<soapenv:Body wsu:Id="Body-356a8483-8b54-40ef-a32b-f437c5bfc542" xmlns:wsu= |
图3.21
4 结论
基于WebSphere DataPower构建Web服务安全网，可有效地满足Web服务安全网在访问合法性，数据机密性和完整性这三方面的需求。DataPower提供几乎线速地处理XML/Web服务任务的能力，作为硬件产品和封闭系统所具备有更高的可靠性和安全性，以及本身提供的集群架构，都大大提升了Web服务安全网关的整体能力；同时，DataPower全部功能的实现仅需要通过配置即可完成，作无需客户修改应用代码，为SOA专用设备，它可以通过以太网非常便捷地嵌入客户现有的系统架构中，无需修改现有IT系统的架构，将大大简化应用的开发、部署工作，降低系统管理与维护的成本。因此，我们有理由相信，DataPower将有越来越多的机会，成为IBM客户手中独特的SOA利器。
致谢
感谢IBM SW Techline经理刘京的大力支持，感谢Techline同事胡云飞提供Web服务程序，感谢Techline同事伍棵松协助配置TAM，也感谢Techline同事张为普和罗鹏的大力协助。