web服务安全 SOAP

28 views

Skip to first unread message

zhy19790824

unread,

Sep 17, 2007, 2:06:58 AM9/17/07

to 北京诺贝尔国际软件信息技术有限公司

Web服务安全
关键词： web服务安全 SOAP

一、安全性的三个需求

（a）验证（authentication）

（b）数据完整性（data integrity）

（c）数据机密性（data confidentiality）。

验证（authentication）用来确保业务事务中的各方确实是他们所声称的；因而，身份证明是必需的。这个证明可以以不同的方式获得。一个简
单的例子就是通过提交用户 ID 和密码。一个更复杂的例子是，使用由信任的认证机构（Certificate Authority）（比如
Verisign）签发的 X.509 证书。这个证书中包含身份凭证，并且具有一对与之相关联的私钥和公钥。由一方提交的身份证明包括证书本身以及单
独一条使用证书的私钥数字签名的信息。通过确认使用与一方的证书相关联的公钥签名的信息，接收方可以验证发送方是证书的所有者，从而确认他们的身份。在
双方彼此验证时，称作相互验证（mutual authentication），并且这种验证通常是在 Web 服务客户和 Web 服务提供者之间
完成的。

为了确认在事务中交换的业务信息的完整性，确保在 Internet 上传送期间消息的内容没有被改变或破坏，可以使用安全性密钥对数据进行数字签名。
这是安全性的三个需求中的第二个。一个常用的实践方法是使用发送方的 X.509 证书的私钥对 Web 服务请求的 SOAP Body 进行数字签
名。类似地，也可以签署请求中的 SOAP 头代码块，以确保在实际业务上下文范围以外的事务中交换的信息的完整性（例如，消息 ID、安全性令牌）。
同样地，还可以对 Web 服务响应进行数字签名，从而确保数据的完整性。

安全性的三个需求的第三个是机密性（confidentiality）。可以利用加密技术来使 Web 服务请求和响应中交换的信息不可读。这样做的
目的是，确保访问传送中的、内存中的、或已经持久化的数据的任何人都将需要适当的算法和安全性密钥解密数据才能访问实际的信息。

二、 Web服务安全概述

Web服务使用XML来进行数据交换，而XML在默认情况下是明文编码的；同时，大部分Web服务使用HTTP协议作为传输协议，同样，HTTP也是使
用明文方式来传输数据的。这就造成了在不加密的传输协议上传输不加密的信息，从而使信息传输的保密性受到威胁.

根据应用的对安全要求的级别不同，可以采用不同的方式来实现安全性，以下是目前最常用的一些实现方式（从低到高排列）：

J2EE Web应用默认的访问控制（数据是明文的）；

使用axis的Handler进行访问控制（数据是明文的）；

使用Servlet过滤器（Filter）进行访问控制（数据是明文的）；

使用SSL/HTTPS协议来传输（加密的数据传输协议）；

使用WS-Security规范对信息进行加密与身份认证（数据被加密传输）。

前面三种对安全要求不高的应用是可行的，他们能用Web应用访问认证机制进行权限验证,但是消息的传输都是明文的。这三种实现起来也较简单。第四种应用
SSL/HTTPS协议，主要缺点在于资源消耗大，关键的一点在于它只能对整个消息加密，不能灵活的实现某些需求里面只要求对消息中的某部分敏感信息进
行安全处理。相对于第五种它的优点在于性能较优，处理时间短。我们应用的是第五种，WS-Security规范是IBM、Microsoft 和
Verisign 于2002年十二月份联合发布的，该规范描述如何向 SOAP 消息附加签名和加密报头；另外，它还描述如何向消息附加安全性令牌
（包括二进制安全性令牌，如 X.509 证书），提供了一套帮助 Web 服务开发者保护 SOAP 消息交换的机制。

Web服务中应用WS-Security规范安全模型如下图。

一个消费应用程序CA（客户端），一个服务提供程序SP（服务端）。在Web服务请求和响应过程中都对SOAP消息进行安全处理。两端分别有各自的密钥
库，一般每一方有两个密钥库，一个装自己的密钥对，一个装自己信任的别人的公钥。

下面针对具体的应用进行介绍，前面所提到的实现安全的前四种方法这里不再详叙，只介绍WS-Security规范实现的安全。

三、应用WS-Security规范实现Web服务安全性

在我们的WebJet中安全模块如下图所示。主要就是对发送的SOAP消息进行安全处理。

下面通过一个实例来介绍处理的详细过程。

例子的服务程序很简单，就是一个税收缴纳服务，输入月收入，返回应缴纳的税收数目。

服务端程序：PersonalTaxService..java WSSecurityServerRequestHandler.java
WSSecurityServerResponseHandler.java

客户端程序：WSSClient1.java WSClientHandler.java
WSClientRequestHandler.java WSClientResponseHandler.java

两端都要用到的辅助程序： WSHelper.java (在我们的应用程序和ws-security.jar，tsik.jar之间起桥梁作
用) MessageConveter.java(提供SOAPMessage和Document之间转换)。此外用到了ws-
security.jar包和Versign公司的tsik.jar包(基于XML进行安全处理)。

第一步：生成密钥及密钥库。

脚本省去，共生成四个文件：client.keystore client.truststore server.keystore
server.truststore 分别是客户端的密钥库，客户端的信任库，服务端的密钥库，服务端的信任库。库中装的是密钥对，可以通过工具
KeyTool查看详细信息，也可以通过命令或者程序导出X509证书。

第二步：部署配置服务端。

将服务端程序编译后放在axis/web-inf/classes目录下，直接修改server-config.wsdd文件配置服务，在适当位置加
入：

<service name="PersonaTaxService" provider="java:RPC"> //服务名

<parameter name="className"
value="com.hellking.study.webservice.PersonalTaxService"/> //

<requestFlow> //请求流，添加Handler

</handler>

</requestFlow>

</handler>

</responseFlow>

</service>

在这里配置好要用的密钥库，以及需要的参数。

第三步：测试客户端程序。

客户端程序也有Handler模块与服务端程序对应，不同的是Handler模块是在客户程序静态注册的。启动Tomcat，运行客户程序查看结果。

在这个例子中，可以看到，客户端服务端的进行安全处理的Handler模块是独立的，可以插入到我们的应用当中。在WebJet的引擎中我们就可以加入
这个模块。

下面看看在这个具体例子中SOAP消息在处理的过程中的变化：

未经处理的SOAP消息：包括SOAP Head SOAP body

加密的SOAP消息： SOAP body 已被加密，在SOAP Head 中加入了<wsse:Security>元素，其中包括被对方公钥加密的
单钥以及公钥标识。

加密并签字的SOAP消息： SOAP body已被加密。在SOAP头中包含如下几个部分：1.用对方公钥加密的单钥值 2.发送方的公钥证书
3. 对加密后的BODY的摘要 4.时间戳 5.对时间戳的摘要 6. 对发送方公钥证书的签名。各部分的作用如下：1.是为了让对方解密。2.是
让对方验证身份。3是防止对消息内容的窜改。4.是防重放攻击 5 是防重放，防窜改时间 6.防抵赖，对发送行为签字确认。

对这个例子程序不再进行详细分析，需要注意和考虑的如下几个问题：

1. 部署服务运行程序是注意密钥参数的配置，不能出错。

2. Handler模块虽可以独立插入到其他程序中。但是其灵活性还需提高，如这里是对SOAP消息的整个BODY部分加密，基于XML
的加密是可以灵活的对整体或者指定元素或者内容加密，在某些应用中只需对SOAP消息中的部分敏感信息加密，这个问题针对具体应用需要进一步考虑。

3. 对一个实际系统而言，证书的发布管理是个问题，需要继续考虑。

Reply all

Reply to author

Forward

0 new messages

web服务 安全 SOAP

zhy19790824

web服务安全 SOAP