摘要:本文介绍了 Microsoft WSE 2.0 和 Sun JWSDP 1.5之间基于OASIS WS-Security的协作。 本文将论述以下操作中所涉及到的全部内容，即用X509证书配置以上两种环境，以便安全地签署和加密SOAP请求和响应。 (22打印页)

提示:本文是以前介绍Microsoft WSE 2.0 和 Sun JWSDP 1.4之间协作的文章的更新版。 Sun JWSDP 1.5 现在把WS-Security作为First Customer Shipment(FCS),而版本1.4却是通过Early Access (EA)实现的。 因此，本文提供的示例代码已更新到FCS 1.0 版本。

[URL=http://www.microsoft.com/downloads/details.aspx?FamilyId=FAE81F8F-D4D2-44BA-95CE-DEDCF9817462&displaylang=en]下载更新的源代码: WssInteropJwsdp15Setup.msi[/URL]

本页内容
运行代码示例的必备软件和能力
WS-Security是什么？
挂起！ SSL出了什么毛病？
安装和配置示例代码
安装和配置WSE 2.0
安装和配置JWSDP 1.5
Web服务示例
用XSD描述
生成JWSDP 1.5 Web服务
启动Apache Tomcat 服务器
生成客户端
激活跟踪
为WSE 2.0 和Sun JWSDP 1.5 两者配置WS-Security  
配置X509证书的存储区
在Microsoft客户端配置证书
配置JKS(Java密钥存储区)
安装JCE RSA 供应器
使用X509来签署消息
使用X509来加密消息
结论
关于作者

运行代码示例的必备软件和能力
Microsoft .NET Framework 1.1(下载链接参见于[URL=http://www.microsoft.com/net]http://www.microsoft.com/net[/URL])

Microsoft Visual Studio .NET 2003 (本文中可选)([URL=http://www.microsoft.com/vstudio]http://www.microsoft.com/vstudio[/URL])

Microsoft Web Services Enhancements (WSE) 2.0 SP1 ([URL=http://msdn.microsoft.com/webservices]http://msdn.microsoft.com/webservices[/URL])

适当的Java 2 Standard Edition (J2SE) (J2SE)SDK(推荐1.4.2版本)([URL=http://www.java.com/]http://www.java.com[/URL])

Sun JWSDP(Java Web服务开发包)1.5([URL=http://java.sun.com/webservices/jwsdp/index.jsp]http://java.sun.com/webservices/jwsdp/index.jsp[/URL])

适用于Sun JWSDP的Tomcat 5.0([URL=http://java.sun.com/webservices/containers/tomcat_for_JWSDP_1_5.html]http://java.sun.com/webservices/containers/tomcat_for_JWSDP_1_5.html[/URL])

适用于J2SDK 1.4.2的RSA JCE 供应器(详见 [URL=http://java.sun.com/products/jce/jce14_providers.html]http://java.sun.com/products/jce/jce14_providers.html[/URL]

WS-Security是什么？
WS-Security是保证Web服务安全的规范;尤其是在消息完整性，消息机密性和单独消息认证方面。 WS-Security规范是由Microsoft，IBM和Verisign联合制定并提交OASIS批准的。

2004年4月6日，OASIS([URL=http://www.oasis-open.org/]http://www.oasis-open.org[/URL])发布了基于此规范的Web Service Secutity 1.0标准。 此标准推荐通过使用用户名和X509标记来保证SOAP消息的安全.

许多厂商现在开始支持WS-Security。 Microsoft在WSE(Web Services Enhancements)2.0中提供了对OASIS WS-Security 1.0的支持，可从MSDN下载WSE2.0。WSE2.0为.NET框架补充了Web服务支持。 Sun在JWSDP(Java Web服务开发包)1.5中提供了对OASIS WS-Security的支持，可从其站点下载。

本文将介绍以下技术：使用Microsoft WSE 2.0 和Sun JWSDP 1.5(均支持OASIS WSS 1.0标准)在.NET框架和J2SE之间安全地传递消息。

关于WS-Security的更多信息，推荐参考Don Smith的文章: [URL=http://msdn.microsoft.com/library/en-us/dnwse/html/wssecdrill.asp]WS-Security Drilldown in Web Services Enhancements 2.0[/URL].

挂起！ SSL出了什么毛病？
目前在互联网上,SSL已被证明是保护资源可行方法. 如果你曾经在线购物,那么你肯定是通过SSL来保证其安全。 这就产生一个问题-为什么不在Web服务中使用SSL呢？

目前，由于Web服务大多是基于HTTP实现的，因此完全可以使用SSL来加密通信并用证书来验证客户端和服务器。 在WS-Security规范发布之前,许多用户已经用SSL这么做了。

但是在Web服务的环境下，SSL确实有一些不足之处：

SSL仅适用于点对点通信。
SSL是通过加密两点之间的传输通道起作用的，对Web服务调用来说,就是从客户端到服务器。 如果要在多个点之间发送消息，那么使用SSL就会带来一些问题。

SSL必须保证网络上所有节点之间的通信安全(这样就使确认消息被客户端签名这件事变得很困难)。 同时，消息仅在传输阶段是安全的，如果我能够访问网络中某个节点(例如，入侵了某个服务器)那么我就可以明文读取消息的内容。

SSL受缚于TCP。
Web服务栈(WS-I Basic Profile 1.0中定义)没有明确把Web服务的使用绑定到HTTP。 因此随着Web服务实现方法的成熟，其他传输通道（包括SMTP，FTP，IBM MQSeries和MSMQ）也会获得支持。 目前在WSE 2.0中，已经可以看到其中的一些例子。这样就导致消息的格式没有变化，但是位于其下的传输通道却改变了。

对于其它传输通道，有可能不能使用SSL。 因为对于非TCP传输，通道的安全选项甚至可能不存在。在这些情形下，WS-Security在消息级别上的安全性就能保证消息本身的安全,而不是依赖底层传输通道的安全模型。由于与使用的传输通道无关，WS-Security为保证消息安全提供了一种更灵活的方法。

WS-Security支持签名或加密的消息。
WS-Security规定安全元素是消息的一部分。因此可在磁盘中保存签名消息，这适用于非认可情形。 (非认可情形是指试图证明某签名属于某个体的情形。)

设想某安全的Web服务正在运行，有时候想要知道某人是否调用过它。在使用SSL的环境中要达到此目的是比较困难的，因为即使能记录请求，传输通道也会自动地移除消息的安全部分(客户端签名)。

有了WS-Security，签名元素被应用到消息—意味着它可以和消息内容一起被保存到磁盘。 在这种情形下，就可以通过及时地检查此元素来证实某人在某时确实签署了这个消息。

WS-Security支持局部消息的签名和加密。
不像SSL，WS-Security可以支持局部消息的签名和加密。 例如，可以在一个Web服务请求中包含某次订购的信息，而WS-Security只用来加密此订购中信用卡的信息，那么在此情形中，订购信息可以被适当地查看和发送，而安全性则可以保证信用卡信息只能被目标Web服务解密。

安装和配置示例代码
为了更好地说明WS-Security中Microsoft WSE 2.0 与Sun JWSDP 1.5 之间的协作，本文附带了一份示例代码，可从本文开始处或[URL=http://www.microsoft.com/downloads/details.aspx?FamilyId=FAE81F8F-D4D2-44BA-95CE-DEDCF9817462&displaylang=en]这里[/URL]下载它。在安装示例代码时，会要求指定安装目录，默认是c:\wssinterop\jwsdp15。 如果不用默认目录，那么将需要更改此示例代码中的一些配置文件里的引用路径。

安装和配置WSE 2.0
如果还没有安装WSE 2.0，现在就应该安装，可以从[URL=http://msdn.microsoft.com/webservices/]这里[/URL]下载它。 安装过程简单直接， 推荐你选择Visual Studio Developer作为图1所示的安装类型。 这将保证在Visual Studio .Net 2003里正确安装集成选项。

图1. WSE 2.0 SP1安装向导

安装和配置JWSDP 1.5
Sun JWSDP 1.5支持三种容器来容纳Web服务：Sun Java System Application Server Platform Edition 8，Sun Java System Web Server 6.1和用于JWSDP的Tomcat 5.0。 你可以在以下站点找到关于JWSDP 1.5 所支持容器的附加信息：[URL=http://java.sun.com/webservices/containers/index.html]http://java.sun.com/webservices/containers/index.html[/URL].

本文是以用于JWSDP的Tomcat 5.0为基础的， 可从以下站点下载此版本的Tomcat：[URL=http://java.sun.com/webservices/jwsdp/index.jsp]http://java.sun.com/webservices/jwsdp/index.jsp[/URL]. 为配合示例代码，推荐在默认目录里安装Tomcat，即c:\tomcat50-jwsdp。

安装了Tomcat5.0之后，再安装Sun JWSDP 1.5。 在安装向导期间，确保通过指定Tomcat的安装目录来配置容器。这可以通过点击图2中所显示的浏览按钮然后选择Tomcat 5.0 目录来完成。

图2。 在JWSDP 1.5安装向导中选择Tomcat容器

当提示输入Tomcat管理员信息时，输入用户名admin和密码changeit(以后可更改它们)。向导中的其他选项可以保持为默认值。

Web服务示例
如果你曾经在线购物，那么很有可能你是把信用卡信息输入到一个网页的表单中。 如上文所述，很有可能用SSL来保证传输安全。

在此示例中，你将看见如何用Web服务来创建类似的操作，但使用WS-Security来保护通信，类似图3所示。

图3. Web服务示例的概览

如上所示，操作相当简单； 客户发送信用卡信息到Web服务。

要完成此操作，将需构造一个包含下列信息的SOAP请求：OrderID-识别订购的字段CreditCardNum-保存信用卡卡号的字段CreditCardExpM-保存信用卡过期月份的字段CreditCardExpY-保存信用卡过期年份的字段下面是一个可能的例子：OrderID-298532CreditCardNum-4622-1234-5678-9012CreditCardExpM-04CreditCardExpY-05

一旦接收到付款信息，Web服务将返回一个跟踪数，可认为这是收据。 在此示例中,它是由服务器产生的一个随机数。

用XSD描述
本示例中，信用卡付款信息的格式已经由XSD(XML架构定义)产生。 因为它是线路中传送的数据的典型代表,所以在写类之前做这个工作可以很好的锻炼自己的协作性.

可以在c:\wssinterop\jwsdp15\schemas目录中找到此XSD文件,它看起来像以下这样:

<?xml version="1.0" encoding="utf-8"?>
<xs:schema id="ComplexMessages"  
targetNamespace="http://schemas.wsig.samples.microsoft.com/ComplexMessa
ges.xsd" elementFormDefault="qualified"  
xmlns="http://schemas.wsig.samples.microsoft.com/ComplexMessages.xsd"  
xmlns:mstns="http://schemas.wsig.samples.microsoft.com/ComplexMessages.
xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:complexType name="Order">
        <xs:sequence>
            <xs:element minOccurs="1" maxOccurs="1" name="Id"  
type="xs:long" />
            <xs:element minOccurs="0" maxOccurs="1"  
name="CreditCardNum" type="xs:string" />
            <xs:element minOccurs="0" maxOccurs="1"  
name="CreditCardExpM" type="xs:int" />
            <xs:element minOccurs="0" maxOccurs="1"  
name="CreditCardExpY" type="xs:int" />
        </xs:sequence>
    </xs:complexType>
</xs:schema>

可见，XSD文件中定义了订购ID，信用卡卡号，过期信息。可使用诸如Microsoft Visual .Net 2003这样的XSD编辑器随心所欲地查看和操作此文件.

虽然XSD文件擅长设计数据类型，但是在每种平台上仍然需要把他们转换成类. 幸运地，已经有工具可以完成这些工作。

.NET框架SDK中一个有用工具叫xsd.exe,可在Visual Studio .NET SDK的安装目录中找到它。XSD.exe被用来从XSD文件产生类。 对于Sun JWSDP 1.5，xjc.bat是JAXB执行库附带的工具， 这个工具把XSD转变为Java类型。 完成这之后,就可以在Web服务中使用这些类了。

为了节省时间，已经用工具从此XSD文件产生了所需要的类，示例代码中已经包含了这些类。如果希望重新从此架构产生数据类型，就执行c:\wssinterop\jwsdp15\schemas目录中的generate.bat 批处理文件，则产生Java Web服务的所需的类，并相应地更新源代码。

生成JWSDP 1.5 Web服务
要测试示例，必须首先生成JWSDP 1.5 Web服务。这就需要在安装了所有必备软件情况下，运行c:\wssinterop\jwsdp15\wsdp\service 目录中的build.bat 批处理文件。为了防止错误，应该从命令行提示符处运行此批处理文件，此过程将编译Web服务源代码并创建Web服务的部署程序。

一旦完成编译，部署程序将被复制到Tomcat安装目录。 部署程序由OrderService.war和OrderService-portable.war这两个WAR文件构成，可以在Tomcat安装目录中的webapps目录中找到它们。 在默认安装情况下： c:\tomcat50-jwsdp\webapps。

启动Apache Tomcat 服务器
部署成功之后，就可以启动Tomcat服务器了。 在命令行提示符下，浏览到Tomcat安装目录中的bin目录(c:\tomcat50-jwsdp\bin)， 运行以下命令：Catalina run这将启动Tomcat服务器。

提示 也可以通过其它命令启动Tomcat服务器(例如，相同目录下的startup.bat，或者通过使用程序文件菜单选项)。使用以上命令的好处是可以在当前控制台窗口中显示所有错误消息和信息。

当Tomcat服务器启动时，找到OrderService.war被正确部署的消息：

Nov 30, 2004 1:11:32 PM org.apache.catalina.startup.HostConfig deployWARs
INFO: Deploying web application archive OrderService.war
Nov 30, 2004 1:11:32 PM org.apache.catalina.core.StandardHostDeployer install
INFO: Installing web application at context path /OrderService from URL jar:file
:C:\tomcat50-jwsdp\webapps\OrderService.war!/

当启动完成时，就可以运行客户端了。

生成客户端
如果安装了Microsoft Visual Studio .NET 2003，就可以运行解决方案文件来生成和运行客户端。这个文件是WSS.sln，可在c:\wssinterop\jwsdp15\dotnet目录中找到它。

提示 如果没装Microsoft Visual Studio .NET 2003，则可以运行客户端子目录中的build.bat文件。 然后运行Client.exe文件来运行客户端。

生成并运行客户端，应该能观察到下列信息：

Creating order...
Sending payment information to Sun JWSDP 1.5 Web Service...
Submit complete.  The tracking number for this order is: 1855259209

正如所显示的，订购被创建和发送到了Sun JWSDP Web服务。完成之后，服务器会返回一跟踪数到客户端。 (返回的跟踪数是随机的，因此你的随机数有可能和这里的不同。)

祝贺！ Web服务现在正确地工作了！ 让我们看一下线路中正在传送些什么。

激活跟踪
在介绍有关使用WS-Security步骤之前，值得先说明一下跟踪是怎样建立的。SOAP请求和响应在客户端和服务器之间往返时，跟踪使你对他们能够进行检查。这可以用于确认消息是以加密方式还是以纯文本方式发送的。

对于本文附带的示例代码中的WSE 2.0客户端和Sun JWSDP 1.5 Service, 跟踪已经自动被激活了。

对于WSE 2.0，所有消息均被写入c:\wssinterop\jwsdp15\dotnet\bin\debug目录(如果使用了批处理文件,则是dotnet目录)中的InputTrace.webinfo和OutputTrace.webinfo文件。

在app.config文件中启用<trace>配置，或者使用本文后面将介绍的WSE 2.0 配置编辑器都可以激活WSE的跟踪。

对于Sun JWSDP 1.5，所有消息都被写入Tomcat控制台。通过在服务的wsse.xml文件中配置dumpMessages=”true”来启用跟踪。稍后在文章中启用了WS-Security时，跟踪将被激活。

运行客户端之后，查看OutputTrace.webinfo文件，可看到以纯文本方式发送的信用卡信息：

<soap:Body>
<submitOrder xmlns="http://wss.samples.microsoft.com">
<OrderImpl_1 xmlns="">
<id>348922</id>
<creditCardNum>4426-1234-5678-9012</creditCardNum>
<creditCardExpM>10</creditCardExpM>
<creditCardExpY>5</creditCardExpY>
</OrderImpl_1>
</submitOrder>
</soap:Body>

InputTrace.webinfo文件以相似的方式显示了从服务返回的跟踪数。

<env:Body><ns0:submitOrderResponse><result>179688114</result></ns0:submitOrderResponse></env:Body>

也可以使用跟踪工具以图表的方式分析这些数据。 WseTrace([URL=http://workspaces.gotdotnet.com/wsetrace]http://workspaces.gotdotnet.com/wsetrace[/URL])能以UI的形式显示这些相关的消息，如图4所示。

图4. WseTrace为WSE 2.0跟踪文件提供了图形化界面（点击看大图）

既然已经看到了以明文（认为是纯文本）方式传送的信息的类型，那么接下来就看看如何用WS-Security来签名和加密信息。

为WSE 2.0 和Sun JWSDP 1.5 两者配置WS-Security
Microsoft WSE 2.0和Sun JWSDP 1.5这两种平台在配置WS-Security的方法上区别不大。

可用代码编程的方式，或使用基于WS-Policy早期实现的配置文件来配置WSE2.0。 [URL=http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-policy.asp]WS-Policy[/URL]规范说明了怎样通过外部XML文件配置Web服务的元素，并且在各厂商之间保持中立。本文的例子将用WS-Policy来启用WS-Security,但是也可以通过代码达到相同的目的。

也能通过程序或者外部XML文件配置Sun JWSDP 1.5.本文将介绍这些配置文件的示例.

配置X509证书的存储区
在执行WS-Security签署并加密消息之前，首先有必要配置X509证书和存储区。

由于示例显示了两个方向上（从WSE 2.0 到 JWSDP 1.5和其反方向)的消息的签名和加密，那么就需要配置一些证书和密钥。本示例将要用到Microsoft WSE 2.0 和 Sun JWSDP 1.5 快速开始示例中所提供的密钥和证书。所有这些证书仅用于测试，对这些示例用户可自由使用或生成证书。

下图显示了示例如何工作

图5. 客户端和服务之间的签名和加密

WSE 2.0客户端持有一个私钥和一个公钥（图中的pK1和PK1）,还持有JWSDP 1.5 Service的公钥(PK2)。JWSDP 1.5 Web服务持有一个私钥和一个公钥（pK2和PK2），还持有WSE 2.0客户端的公钥（PK1）。

当WSE 2.0客户端对一到JWSDP 1.5 Web服务的请求进行签名时，它将用私钥（pK1）来产生此消息的签名（记为SpK1(M)）。 公钥同消息一起被发送以允许Sun JWSDP 服务验证其签名(创建SpK1(M),PK1) 。

当WSE 2.0客户端对一到JWSDP 1.5 Web服务的请求进行加密时，它将用Sun Web服务的公钥(PK2)来产生密文(EPK2(M))。 Sun JWSDP 服务用相应的私钥(pK2)来解密消息。

当Sun WSDP 1.5 服务签名和加密到WSE 2.0客户端的响应时，就反向进行这些操作。

用于完成工作的证书和密钥在客户端和服务之间是不同的。对客户端，使用Windows CurrentUser 证书存储区。 对于Sun Web服务，则使用JKS(Java密钥存储区)。

本文将使用在Tomcat 5.0目录(c:\tomcat50-jwsdp\xWS-Security\etc)中的JKS文件。 Server-keystore.jks文件包含从服务器签署信息的密钥对。 Server-truststore.jks文件包含验证一请求的证书链时所需要的证书。

Sun JWSDP 1.5包括的SecurityEnvironmentHandler示例，可用作这些密钥存储区的参考。这不同于JWSDP的以前的版本(1.4)，在那个版本中，是通过在Tomcat安装中创建一个安全的连接端口来完成的。

在Microsoft客户端配置证书
WSE 2.0客户端将使用Windows存储区来访问X509证书和相应的私钥。 为把必需的证书导入到此存储区中：首先，在WSE 2.0安装目录中的示例目录(c:\Program Files\Microsoft WSE\v2.0\Samples\Sample Test Certificates).中双击Client Provate.pfx文件。遵循证书导入向导来安装证书和私钥。私钥的密码是wse2qs。 当被问及存储区位置时，确保使用了个人。

这样就建立了签署SOAP请求所必需的公钥和私钥。下一步，必须导入JWSDP 1.5 服务所使用的证书的公共部分，还有颁布证书机构的公共部分。为了导出证书的公共部分，打开命令行提示并浏览到c:\tomcat50-jwsdp\xWS-Security\etc目录。

从这里运行下面两个命令：

keytool –export –file server.cer –alias s1as –keystore server-keystore.jks

出现提示时，输入JKS的默认口令，即changeit。

keytool -export -file ca.cer -alias certificate-authority -keystore  
server-truststore.jks

再出现提示时，输入默认密码。

这两个命令将创建两个证书文件，server.cer和ca.cer。 在Windows浏览器中浏览到此目录，双击每个文件以查看它们，并且点击安装证书按钮。确保server.cer中的证书被导入到个人存储区并且把ca.cer证书存到受信任的根证书发行机构。

现在就完成了Windows存储区的配置。

配置JKS(Java密钥存储区)
你现在需要导入以下证书（PK1）的公共部分，即用来签署加密发往WSE 2.0客户端的响应的证书。为此，打开MMC(Microsoft管理控制台)，在Windows开始/运行菜单中运行mmc.exe。 打开MMC后，选择文件->添加/删除管理单元，点击添加按钮，并且选择证书管理单元选项。 点击添加按钮，选择我的用户帐户，然后关闭对话框返回到MMC控制台。

浏览到个人目录。已安装的证书列表看起来应该类似于图6所示。

图6. 证书存储区的MMC视图

为导出客户端证书的公共部分，右击WSE2QuickStartClient并选择所有任务->导出。 不要导出私钥（如果有提示）并选择BASE 64 CER作为导出类型。至于导出文件名，使用c:\tomcat50-jwsdp\xWS-Security\etc\wse2client.cer.除了导出WSE2QuickStartClient证书之外，还需要导出CA证书(在这种情况下，它是根机构，CA示例)。

为此，在MMC控制台中双击WSE2QuickStartClient证书。 转到证书路径选项卡并双击根机构证书。 在新对话框里，点击细节选项卡并且点击复制到文件按钮。

再选择BASE 64 CER并保存文件为c:\tomcat50-jwsdp\xWS-Security\etc\wse2ca.cer

为把这些证书导入到JKS，打开命令行提示到c:\tomcat50-jwsdp\xWS-Security\etc目录并使用下列命令：

keytool -import -file wse2client.cer -alias wse2client -keystore server-truststore.jks

keytool -import -file wse2ca.cer -keystore server-truststore.jks -alias wse2ca

出现提示时，输入JKS的密码changeit。

导入证书公共部分后，JKS的安装就结束了。

注意 如果没有使用Sun JWSDP 1.5示例提供的证书，而是用你自己产生的证书，那么就不能使用keytool(创建，导入和导出证书的默认工具)。 JWSDP需要X509 v3证书来进行签名和加密，并且此证书必须包含主密钥标示。工具keytool仅能创建X509 v1证书。

为克服此缺陷，Sun在JWSDP 1.5中附带提供了一个名叫pkcs12import的工具。可把它和.p12(PKCS#12) 密钥对一起使用来把一证书导入到已存在的密钥存储区。

安装JCE RSA 供应器
正确配置JKS后，需要为RSA安装JCE供应器。 默认情况下，Sun JDK 1.4.2没有为RSA附带提供一个JCE供应器。由于某些证书使用了RSA算法，因此需要下载安装第三方供应器。

在其文档中，Sun 推荐以下站点，此站点列出了提供此项支持的供应器： [URL=http://java.sun.com/products/jce/jce14_providers.html]http://java.sun.com/products/jce/jce14_providers.html[/URL].

下载之后，复制供应器的JAR文件到%JAVA-HOME%/jre/lib/ext/。

修改%JAVA_HOME%/jre/lib/security/java.security属性文件并添加新JCE供应器。 java.security文件按下列格式列出安全的供应器： security.provider.<n>=<供应器类名称>

在位置2添加新JCE供应器，确保Sun安全供应器保持在最高级别，即值为1。也许要向下调节其他安全供应器的级别以便在每个级别上只有一个安全供应器。

本文的示例已经在"Legion of the Bouncy Castle" JCE 供应器情况下测试通过。以下可供参考，安装过程中java.security文件配置如下：

security.provider.1=sun.security.provider.Sun
security.provider.2=org.bouncycastle.jce.provider.BouncyCastleProvider
security.provider.3=com.sun.net.ssl.internal.ssl.Provider
security.provider.4=com.sun.rsajca.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider

以下站点提供关于配置的进一步信息：

[URL=http://java.sun.com/webservices/docs/1.5/tutorial/doc/XWS-Security4.html#wp520663]http://java.sun.com/webservices/docs/1.5/tutorial/doc/XWS-Security4.html#wp520663[/URL].

使用X509来签署消息
正确配置X509证书存储区和密钥后，就可以对请求进行签名和加密了。

签署信息(WSE 2.0 到 JWSDP 1.5)
如前文所述，可以通过程序方式或策略文件方式用WSE 2.0签署请求。本示例将采用策略文件的方式。

可以手动或者使用WSE 2.0配置工具来创建策略文件。配置工具可提供一个类似向导的界面。

通过以下方式访问配置工具：在Visual Studio .NET 2003中右击客户端项目并选择WSE配置2.0…菜单项。如果没有安装Visual Studio .NET 2003，可从命令行运行以下命令：

C:\Program Files\Microsoft WSE\v2.0\Tools\ConfigEditor\WseConfigEditor2.exe

提示 如果从命令行运行此工具，那么需要从c:\wssinterop\jwsdp15\dotnet\client处打开app.config文件。

如图7所示，配置工具提供了许多关于安全性，路由，过滤，策略，标记发布，诊断的配置。

图7. WSE 2.0配置工具

选择图8所示的策略选项卡

图8 配置工具的策略选项卡

为启用此应用的策略，选择启用策略复选框，将显示policyCache.config文件的路径(../../policyCache.config)。

点击添加按钮。 在终点 URI字段中输入http://localhost:8080/OrderService/OrderService(确保此URL中的端口同Tomcat使用的端口（默认是8080）一样)即Sun JWSDP 1.5 服务的终点URL。

点击确认将启动WSE安全配置向导， 向导开始后，点击下一步，并再点下一步，选择选项来保护客户端应用。

向导下一步会显示将要进行的操作的类型信息。

图9 . 使用WS-Security配置向导来配制安全性

如图9所示，在向导里，可以选择是否对请求和响应消息进行签名和加密。

在此示例中，在请求消息中选择要求签名复选框(并确保没有选择要求加密复选框)。 这将使WSE 2.0 对此应用的外发请求进行签名。

在向导的下一步选择标记类型(选择X509证书)中，会要求选择一证书。 由于我们是要签署消息-此消息可以访问我们的私钥-因此需要使用客户端的证书(WSE2QuickStartClient证书)。 在选择证书窗口中确保选择了此证书：

图10. 选择证书以签署请求

点击下一步以确认选择然后点击完成来结束向导。这样就创建了策略文件，它指定客户端应签署Web服务。

有了合适的新策略文件后，再次运行客户端应用。客户端将像以前一样调用Web服务，但现在将对JWSDP Web服务的请求进行签名，可通过分析请求的SOAP踪迹来对此进行确认，可在Webinfo WSE跟踪文件或Tomcat控制台做到这些。

如果分析这些消息，则会看到它包含有一个二进制安全标记，一个签名容量清单，一个签名值和一个安全标记引用。

二进制安全标记就是公共X509证书（用它来确认签名的真实性）：

<wsse:BinarySecurityToken ValueType="http://docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"  
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
soap-message-security-1.0#Base64Binary" xmlns:wsu="http://docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"  
wsu:Id="SecurityToken-6bc048f9-1ff9-407c-9c5b-440c6067088c">MIIBxDCC...
(this part snipped for this article)... R8ajJfl</wsse:BinarySecurityToken>

签名值就是消息的被签名哈西表。

<SignatureValue>NEsW7+HcG4sIxGfoVEF1s+1DUtacoPIY4iCj1qg8eHn2znkVle80p4f
wBwXFfghchmnNlf5QF1Dt/Bte8pee2wWHGA34s8FidO9a3YjGDL1Vg+2Ed0baNOtUPYFliS
czK5dpz2rk/Aan65zD7ngjhQja9gnsierojrluug2b8EQ=</SignatureValue>

签署响应
我们已经看到了如何通过X509证书用WSE 2.0来签署消息。 如观察SOAP踪迹，则会注意到服务器发出的响应却没有被签名。可通过配置JWSDP Web服务来启用响应的签名。

为此，浏览到c:\wssinterop\jwsdp14\wsdp\service\config目录，在这里会找到wsse.xml文件，这个文件是用来配置外发服务器响应的WS-Security选项的。打开文件并反注释下面的部分：

<xwss:Sign>
       <xwss:X509Token certificateAlias="s1as"/>
   </xwss:Sign>

此行的作用是指示Web服务签署对客户端的响应。 所使用的证书是s1as，和你所记忆的一样，它是在密钥存储区内包含公钥和私钥的别名(s1as是的JKS对xWS-Security-server的别名)

反注释此行后，重新生成解决方案并部署它到Tomcat安装目录。为此需要先停止Tomcat服务器，再运行OrderService目录中的build.bat批处理文件,然后重新启动服务器。

完成之后，再运行示例。 现在在SOAP中踪迹中,就应该能看到来自JWSDP Web服务的响应被签名了-同请求相比较，除了要使用服务器证书这一点不同之外，别的都一样。

使用X509来加密消息
签名有利于检验消息完整性和发送者真实性。 比如，可以用X509签名来检验信用卡详细信息，确认跟踪数字没有在传输过程中被改变，确认发送者的身份。 WSE 2.0 和Sun JWSDP 1.5的示例代码经过修改后，都能支持基于此签名的检验。

这有利于理解消息的完整性信息(毕竟修改细节数据是不值得的)，但在机器之间传送信用卡信息时，有时候希望把数据也进行加密，这将阻止能够访问消息的人直接读取信用卡信息。

加密从WSE 2.0 到Sun JWSDP 1.5的消息
可再次使用配制工具来在WSE 2.0中配置客户端，以便加密发送到JWSDP 1.5 Web服务的消息。

打开配制工具(通过在Visual Studio .NET 2003中右击项目或者从菜单中选择WSE 2.0 配置)并浏览到策略选项卡，替换http://localhost:8080/OrderService的策略。

通过向导，按照先前在签署示例中所作的，但是这一次对请求消息要选择需要加密，如图11所示。此策略规定客户端将加密请求的数据。

图11. 选择选项以要求加密

选择证书时，要选择JWSDP 1.5服务器端证书(xWS-Security-server)，如图12所示。

图12。 选择JWSDP 1.5服务使用的证书

WSE 2.0客户端使用服务器证书的公钥来加密数据。服务器收到被加密的消息时，将用对应的私钥来解密这个请求。

完成向导并且再运行示例。客户端成功地发送信息之后，分析被发送消息的踪迹，将会看到SOAP消息体包含此次调用的被加密了的数据：

<soap:Body><xenc:EncryptedData Id="EncryptedContent-e0f66417-e3dd-4f80-
b340-5e52f154efd1" Type="http://www.w3.org/2001/04/xmlenc#Content"  
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"><xenc:EncryptionMethod  
Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"  
/><xenc:CipherData><xenc:CipherValue>io4Xnvc66EAFd0mnXzngnTIuS9Ej3/gd2M
RCnYRi348a1XRRVBS50eKYm+SZB55HwYbd02/JTgQLTrQKi1FS5NavpyDJj/1E0D9Hkgosy
6WBuyXElPFXBBYsQUyODGcukAz5CTXreDQqfsTAbGy9NIXUKgJcOA0WPwhVTh1vE19oc8x8
5ir59fglOxBmcGzQMKsLy/9SPuR5Ma6Blg5r9pFlHq9mrElH/1KwfQWyRU5LG37wUFV8VhG
6+5QvxYIq1dwDe8tTDMxVLW+VsCKCpqUgSz7ZQdaY7ncKwBcMniDIpoIAjaXB70m/igEJE+
0vLZQClAHMpFg=</xenc:CipherValue></xenc:CipherData></xenc:EncryptedData
></soap:Body>

在启用加密之前再调用一次，那么SOAP体看起来就像下面所显示的，以明文方式传送信用卡信息。

<soap:Body>
<submitOrder xmlns="http://wss.samples.microsoft.com">
<OrderImpl_1 xmlns="">
<id>348922</id>
<creditCardNum>4426-1234-5678-9012</creditCardNum>
<creditCardExpM>10</creditCardExpM>
<creditCardExpY>5</creditCardExpY>
</OrderImpl_1>
</submitOrder>
</soap:Body>

消息加密中需要特别注意的是所使用的加密算法。下面这个例子中，使用了3DES 交互密钥:

<xenc:EncryptionMethod  
Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />

WSE 2.0 默认的加密算法是Rijndael AES128，而Sun JWSDP 1.5版本支持3DES算法。 为了协作性，app.config文件中下面这一行可使WSE 2.0 也使用3DES算法：

<binarySecurityTokenManager valueType="http://docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">
        <sessionKeyAlgorithm name="TripleDES" />
      </binarySecurityTokenManager>

这为加密从WSE 2.0到Sun JWSDP 1.5的消息提供了一个方法,而且使两者能彼此协作。

加密响应
本X509示例的最后部分是显示客户端怎样对发送回客户端的响应进行加密.对于Sun JWSDP，这是通过一个类似于签名的方法来完成的。

编辑c:\wssinterop\jwsdp14\wsdp\service\config目录中的wsse.xml文件,注释掉 xwss:Sign元素并反注释 xwss：Encrypt元素：

<xwss:Encrypt>
       <xwss:X509Token certificateAlias="wse2client"/>
   </xwss:Encrypt>

确保证书的别名能读取wse2client，它对应于JKS中的WSE2QuickStartClient的公共部分。

反注释这一行后,重新生成解决方案并再部署到Tomcat.为此，需要先停止Tomcat服务器，再重新运行OrderService目录中的build.bat批处理文件，并重新起动服务器。

完成之后，再运行示例。 在SOAP踪迹中,就能看到来自JWSDP Web服务的响应被加密了-同请求非常类似。

消息加密中值得注意的是加密所使用的算法。 本例中,使用的加密算法是 RSA 的OAEP(最佳非对称填补):

<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p" />

为达到协作,app.config文件中的下面这一行将使WSE2.0启用OAEP算法：

<binarySecurityTokenManager valueType="http://docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">
        <keyAlgorithm name="RSAOAEP" />
      </binarySecurityTokenManager>

这为加密从WSE 2.0到Sun JWSDP 1.5的消息提供了一个方法,而且使两者能彼此协作。

结论
本文论述了使用Microsoft WSE 2.0和Sun JWSDP 1.5来签署和加密Web服务调用。这是通过使用X509证书和OASIS WSS 1.0实现的。

作为一个标准,WS-Security还处于起步阶段。 然而，WS-Security在为Web服务提供独立于厂商,不依赖于传输通道的安全方面的能力是强大的.所有厂商都承诺支持OASIS规范,显示了Web服务的安全是可以达到的。

感谢Kirill Gavrylyuk，Hervey Wilson(Microsoft)和Anita Jindal，Manveen Kaur，和Jitendra Kotamraju(孙Microsystems)，他们对本文做出了有价值的贡献。

关于作者
Simon Guest是Microsoft公司架构策略团队的项目经理，擅长于互用性和综合性。 Simon拥有伦敦Westminster大学IT安全硕士学位，是Microsoft.NET和J2EE 工具包(Microsoft出版，2003年9月)的作者。

可通过Simon的blog（[URL=http://www.simonguest.com/]http://www.simonguest.com[/URL]）联系到他。