《基于xfire实施ws-security》由会员分享，可在线阅读，更多相关《基于xfire实施ws-security（35页珍藏版）》请在金锄头文库上搜索。
1、基于 XFire 实施 WS-Security概述概述Web Service 是安全的吗？鉴于安全性涉及诸多方面（例如身份验证和授权、数据隐私和 完整性等），而 SOAP 规范中根本没有提及安全性这一事实，所以我们不难理解人们为 什么认为答案是否定的。很少有不需要某种形式的安全性保证的企业级系统。在 Web Service 中，处理 Web Service 安全的过程比处理其他领域应用的安全问题更为复杂，因为 Web Service 具有 分布式、无状态的特性。WS-Security 是解决 Web Service 安全问题的规范，大多数商业的 Java EE 应用服务 器都实现了 WS-Se
2、curity 规范，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
3、签名和 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、Ke
4、rberos 权标规范 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
5、 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 应用中实施完整性、机密性和身份
6、验证等安全需求的规范方法。XFire 应用应用 WS-Security 的总体方案的总体方案XFire 通过 Apache 的 WSS4J 对 WS-Security 提供支持，XFire 完整发布包中包含了 WSS4J 的类包。我们知道 XFire 在发送和接收 SOAP 报文前拥有多个阶段，每个阶段都 可以注册 Handler，对 SOAP 报文进行前置和后置处理的加工操作。XFire 即通过 Handler 实施 WSS4J，当发送 SOAP 报文时，通过注册一系列 OutHandler，对 SOAP 报文进行加密、签名、添加用户身份信息等后置处理操作。而在接收 SOAP 报文时，则通
7、过注册一系列的 InHandler 对 SOAP 进行解密、验证签名，用户身份认证等前置操作。图 2 XFire 应用 WS-Security 的方案请求和响应的 SOAP 在发送之前可以通过注册的 OutHanlder 进行加工处理，让 SOAP 转换为 WS-Security 的保护格式。而服务端和客户端的接收 SOAP 报文之前，可以通过 注册的 InHandler，将 WS-Security 格式的 SOAP 转换正常的 SOAP 进行处理。由于 XFire 在 SOAP 收发过程中定义了多个不同的生命阶段，所以可以在发送前和接收前 完成 SOAP 报文安全处理的工作，这些操作完全独立
8、于业务处理逻辑，实施 WS- Security 对于 Web Service 的业务操作是透明的。使用使用 WS-Security在前面内容中，我们通过各种方式将 BbtForum 中的方法以 BbtForumSerivice 窄接口 开放为 Web Service 服务，但个 Web Service 是没有任何安全性可言的，任何拿到 WSDL 的人都可以轻松地构造客户端程序访问我们的 Web Service 服务。在这节里，我 们将解决这个问题，对 BbtForumSerivice 添加不同的安全功能。准备工作准备工作在使用 XFire 的 WS-Security 之前，必须做一些准备性的工
9、作：包括搭建安全环境，创 建密钥对和证书等内容。安装安装 Java 策略文件策略文件策略文件被 JDK 使用，用以控制加密的强度和算法。确认已经安装对应 JDK 版本的 Unlimited Strength Jurisdiction 策略文件，这是一个无限制的安全控制文件。你可以 从 http:/ 或 http:/ 页面的底部找到下载的链接。否则 在使用 WS-Security 时，可以会抛出 java.security.InvalidKeyException: Illegal key size 的错误信息。策略文件包括 local_policy.jar 和 US_export_policy.
10、jar 文件，将其拷贝到 /jre/lib/security 目录下。为了方便读者，我们在光盘 resources/jce_policy-1_5_0 拥有该策略文件的拷贝。你也许会问：为何 Sun 不把它集成到 JDK 中去，而单独“损人不利己”地弄一个链接出来 给人下载？这是因为每个国家，尤其是美国，对涉及密码的软件产品控制非常严格，在美 国国内，很多密码算法长度都作了限制，而且某些算法在某些国家没有申请专利，可以随 意使用，而在某些国家却做了明确限制，不准使用，因此 Sun 必须按照惯例行事。安装安装 SecurityProviderWSS4J 使用了 BouncyCastle 的 Sec
11、urityProvider，所以需要事先在 java.security 文 件中进行配置，否则运行加密模式的 XFire 认证时，会抛出以下的出错信息：org.apache.ws.security.WSSecurityException: An unsupported signature or encryption algorithm was used unsupported key在 java.security 文件中(位于/jre/lib/security 目录中)添加 BouncyCastleProvider 的配置：security.provider.1=sun.security.pr
12、ovider.Sunsecurity.provider.2=sun.security.rsa.SunRsaSignsecurity.provider.3=.ssl.internal.ssl.Providersecurity.provider.4=com.sun.crypto.provider.SunJCEsecurity.provider.5=sun.security.jgss.SunProvidersecurity.provider.6=com.sun.security.sasl.Providersecurity.provider.7=org.bouncycastle.jce.provide
13、r.BouncyCastleProvi derXFire 发布包中包含了 BouncyCastle SecurityProvider 的类包，位于 /lib/bcprov-jdk15-133.jar 下。必须将 bcprov-jdk15-133.jar 加 入到类路径中。你可以在 http:/docs.safehaus.org/display/PENROSE/Installing+Security+Provider 中获 取更多关于安装 BouncyCastle SecurityProvider 的帮助。创建密钥对和数字证书创建密钥对和数字证书签名和加密需要使用到数字证书和密钥对，可以使用 J
14、DK 提供的 KeyTool 工具创建密钥 对和数字证书。我们分别为服务端和客户端创建 RSA 密钥对，并生成各自的 X509 数字 证书（包含公钥和数字签名）。服务端和客户端拥有各自的密钥库 JKS 文件，服务端的密 钥库保存服务端的密钥对和客户端的数字证书，而客户端的密钥库保存客户端的密钥对和 服务端的数字证书。下面，我们来完成创建服务端和客户端密钥库的工作：编写一个用于创建 RSA 密钥对的 generateKeyPair.bat 批处理文件： rem echo off#接受参数echo alias %1echo keypass %2echo keystoreName %3echo Ke
15、yStorePass %4echo 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 导出数字证书导出数字证书编写一个使
16、用 generateKeyPair.bat 创建服务端和客户端的密钥库的 generateKeyStore.bat 批处理文件： 下面两行命名分别调用下面两行命名分别调用 generateKeyPair.bat 批处理文件为服务端和客户端生成密批处理文件为服务端和客户端生成密 钥对钥对call generateKeyPair.bat server serverpass serverStore.jks storepass serverKey.rsa call generateKeyPair.bat client clientpass clientStore.jks storepass clientKey.rsa将服务端的数字证书导入客户端的密钥库将服务端的数字证书导入客户端的密钥库keytool -import -alias server -file serverK
