基于XFire实施WS-Security
基于XFire实施WS-Security
概述
Web Service是安全的吗？鉴于安全性涉及诸多方面（例如身份验证和授权、数据隐私和完整性等），而 SOAP 规范中根本没有提及安全性这一事实，所以我们不难理解人们为什么认为答案是否定的。
很少有不需要某种形式的安全性保证的企业级系统。在 Web Service中，处理Web Service安全的过程比处理其他领域应用的安全问题更为复杂，因为Web Service具有分布式、无状态的特性。
WS-Security是解决Web Service安全问题的规范，大多数商业的Java EE应用服务器都实现了WS-Security规范，Apache WSS4J是WS-Security的开源实现，WSS4J通过SOAP中WS-Security相关的信息对SOAP报文进行验证和签名，XFire通过WSS4J对WS-Security提供了支持。你可以从http://ws.apache.org/wss4j了解更多关于WSS4J的信息。
认识WS-Security
2002 年 4 月，IBM、Microsoft 和 VeriSign 在他们的 Web 站点上提议建立 Web Services Security (WS-Security)规范。此规范包括安全凭证、XML签名和XML加密的安全性问题。此规范还定义了用户名凭证和已编码的二进制安全性凭证的格式。
2002 年 6 月，OASIS 从 IBM、Microsoft 和 Verisign 接收到了提议的WS-Security安全性规范。不久之后就在 OASIS 成立了“Web Service 安全性技术委员会”（WSS TC）。
2006年2月15日，OASIS通过了WS-Security 1.1安全规范，1.1规范突出了对安全权标支持、消息附件和权限管理的增强。1.1规范包括WS-Security核心规范及用户名权标规范1.1、X.509权标规范1.1、Kerberos权标规范1.1、SAML权标规范1.1、权限表达（REL）权标规范1.1、带附件的SOAP（SWA）规范1.1和模式1.1。
也许读者会提出这样的问题：SSL也具有完整性和机密性，为什么还需要另外一个WS-Security规范呢？之所以要制定WS-Security规范，是SSL存在以下的问题：
- 端对端的通信，脱离传输层就无法保证安全性；
- 消息必须全部加密/或者全部签名，而不能针对消息的某部分，没有考虑XML处理。
SSL对应OSI的传输层，前面我们提到过Web Service是和传输层无关的，将安全问题依附在SSL上就违反了Web Serivce与传输层无关的原则。而WS-Security对应于OSI的应用层，建立消息层SOAP之上。
针对不同领域的细分问题，OASIS 在WS-Security的基础上又制定了几十个规范，其中包括WS-SecureConversation、WS-Federation、 WS-Authorisation、WS-Policy、WS-Trust、WS-Privacy等，形成了一个庞大Web Service安全性协议家族。
图1 WS-Security所在位置
有了WS-Security规范，用户就拥有在Web Service应用中实施完整性、机密性和身份验证等安全需求的规范方法。
XFire应用WS-Security的总体方案
XFire通过Apache的WSS4J对WS-Security提供支持，XFire完整发布包中包含了WSS4J的类包。我们知道XFire在发送和接收SOAP报文前拥有多个阶段，每个阶段都可以注册Handler，对SOAP报文进行前置和后置处理的加工操作。XFire即通过Handler实施WSS4J，当发送SOAP报文时，通过注册一系列OutHandler，对SOAP报文进行加密、签名、添加用户身份信息等后置处理操作。而在接收SOAP报文时，则通过注册一系列的InHandler对SOAP进行解密、验证签名，用户身份认证等前置操作。
图2 XFire应用WS-Security的方案
请求和响应的SOAP在发送之前可以通过注册的OutHanlder进行加工处理，让SOAP转换为WS-Security的保护格式。而服务端和客户端的接收SOAP 报文之前，可以通过注册的InHandler，将WS-Security格式的SOAP转换正常的SOAP进行处理。
由于XFire在SOAP收发过程中定义了多个不同的生命阶段，所以可以在发送前和接收前完成SOAP报文安全处理的工作，这些操作完全独立于业务处理逻辑，实施WS-Security对于Web Service的业务操作是透明的。
使用WS-Security
在前面内容中，我们通过各种方式将BbtForum中的方法以BbtForumSerivice窄接口开放为Web Service服务，但个Web Service是没有任何安全性可言的，任何拿到WSDL的人都可以轻松地构造客户端程序访问我们的Web Service服务。在这节里，我们将解决这个问题，对BbtForumSerivice添加不同的安全功能。
准备工作
在使用XFire的WS-Security之前，必须做一些准备性的工作：包括搭建安全环境，创建密钥对和证书等内容。
安装Java策略文件
策略文件被JDK使用，用以控制加密的强度和算法。确认已经安装对应JDK 版本的Unlimited Strength Jurisdiction策略文件，这是一个无限制的安全控制文件。你可以从http://java.sun.com/j2se/1.5.0/download.jsp 或 http://java.sun.com/j2se/1.4.2/download.html页面的底部找到下载的链接。否则在使用WS-Security时，可以会抛出java.security.InvalidKeyException: Illegal key size的错误信息。
策略文件包括local_policy.jar和US_export_policy.jar文件，将其拷贝到<JAVA_HOME>/jre/lib/security目录下。为了方便读者，我们在光盘resources/jce_policy-1_5_0拥有该策略文件的拷贝。
你也许会问：为何Sun不把它集成到JDK中去，而单独“损人不利己”地弄一个链接出来给人下载？这是因为每个国家，尤其是美国，对涉及密码的软件产品控制非常严格，在美国国内，很多密码算法长度都作了限制，而且某些算法在某些国家没有申请专利，可以随意使用，而在某些国家却做了明确限制，不准使用，因此Sun必须按照惯例行事。
安装SecurityProvider
WSS4J使用了BouncyCastle的SecurityProvider，所以需要事先在java.security文件中进行配置，否则运行加密模式的XFire认证时，会抛出以下的出错信息：org.apache.ws.security.WSSecurityException: An unsupported signature or encryption algorithm was used unsupported key
在java.security文件中(位于<JAVA_HOME>/jre/lib/security目录中)添加BouncyCastleProvider的配置：
…
security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=com.sun.net.ssl.internal.ssl.Provider
security.provider.4=com.sun.crypto.provider.SunJCE
security.provider.5=sun.security.jgss.SunProvider
security.provider.6=com.sun.security.sasl.Provider
security.provider.7=org.bouncycastle.jce.provider.BouncyCastleProvider
…
XFire发布包中包含了BouncyCastle SecurityProvider的类包，位于<XFIRE_HOME>/lib/bcprov-jdk15-133.jar下。必须将bcprov-jdk15-133.jar加入到类路径中。你可以在http://docs.safehaus.org/display/PENROSE/Installing Security Provider中获取更多关于安装BouncyCastle SecurityProvider的帮助。
创建密钥对和数字证书
签名和加密需要使用到数字证书和密钥对，可以使用JDK提供的KeyTool工具创建密钥对和数字证书。我们分别为服务端和客户端创建RSA密钥对，并生成各自的X509数字证书（包含公钥和数字签名）。服务端和客户端拥有各自的密钥库JKS文件，服务端的密钥库保存服务端的密钥对和客户端的数字证书，而客户端的密钥库保存客户端的密钥对和服务端的数字证书。
下面，我们来完成创建服务端和客户端密钥库的工作：
- 编写一个用于创建RSA密钥对和generateKeyPair.bat批处理文件：
rem @echo off
#接受参数
echo alias %1
echo keypass %2
echo keystoreName %3
echo KeyStorePass %4
echo keyName %5
①创建RSA密钥对
keytool -genkey -alias %1 -keypass %2 -keystore %3 -storepass %4-dname "cn=%1" -keyalg RSA
keytool -selfcert -alias %1 -keystore %3 -storepass %4 -keypass %2 ②使用私钥进行自签名
keytool -export -alias %1 -file %5 -keystore %3 -storepass %4 ③导出数字证书
- 编写一个使用generateKeyPair.bat创建服务端和客户端的密钥库的generateKeyStore.bat批处理文件：
①下面两行命名分别调用generateKeyPair.bat批处理文件为服务端和客户端生成密钥对
call generateKeyPair.bat server serverpass serverStore.jks storepass serverKey.rsa
call generateKeyPair.bat clientclientpassclientStore.jks storepass clientKey.rsa
②将服务端的数字证书导入客户端的密钥库
keytool -import -alias server -file serverKey.rsa -keystore clientStore.jks -storepass storepass -noprompt
③将客户端的数字证书导入服务端的密钥库
keytool -import -alias client -file clientKey.rsa -keystore serverStore.jks -storepass storepass -noprompt
运行该批处理文件后，将分别为服务端和客户端生成一个Java密钥库文件，它们分别拥有一个自己的密钥对和对方的数字证书。我们通过表1对两者密钥库文件的内容进行说明：
表1密钥库说明
|
|
服务端Java密钥库 |
客户端Java密钥库 |
| 对应密钥库文件 |
serverStore.jks |
clientStore.jks |
| 密钥库密码 |
storepass |
storepass |
| 库中包含的内容 |
server密钥对、client数字证书 |
client密钥对、server数字证书 |
| 密钥对别名 |
server |
client |
| 密钥对私钥的保护密码 |
serverpass |
clientpass |
- 将serverStore.jks和clientStore.jks拷贝到<工程目录>/src/META-INF/xfire的目录下，以便后面的实例代码使用。