Web Service 、WS-Security、Java和.net的互通（一）

和第三部分同样，这部分内容其实应该在后面才对，不过 当前工作既然做了，也需要写下来分享，那么就提前插队到成长记录当中吧。看了这篇文章以后，可能给人的感觉是有点偏离服务框架的内容。的却，如果纯粹从技 术方面来说，这部分应该不属于服务框架范畴。拿杭州作个例子，杭州是全国唯一一个 景点不但不 涨价，反而免门票的地方，原因何在，无非是管理者看得远，景点的门票收益看得到，但是是 小头，免去门票带来的商机那 才是金矿。框架其实也是这样，如果客户用起来不方便，甚至都不能用，那么框架再好，也会有人笑话你是个高高在上的理论主意者，这种框架适合于教学，而非实用。现在也是在迈出平台服务框架兼容性的第一步，那天和同事们开玩笑说，以前联通移动的 wap 业务，好在大家的开发语言都相似， isp 只需要兼容各种手机客户端，我们现在要做的就是兼容各种不同开发语言，平台，以后甚至浏览器，我们这种全部都搞通的人出去，那就真的是抢手货了。

周一测试部 和 ISV support 小组的日报反映， .net 的客户端对于复杂对象数组返回有问题，紧接着就是 .net 客户端对于 web service 的 wsse 无法调试通过。我以前没有接触过 .net ，没办法，硬着个头皮装了个 vs2005 和 WSE 3 。前面一个问题就是我前面半周间断性的解决的问题，在第三篇记录中也写了。后面的问题比较紧急，也比较严重，因为如果 wsse 不能顺利调试通过，那么将会直接影响我们后续将 wsse 全面部署的计划，同时 ISV 已经跟在后面作测试了。看了看时间进度表，下周要进入平台搜索引擎增强的开发和 WSSE 性能优化（ WSSE 对于 CPU 的 消耗真是厉害），因此也就只有两天，周四和周五。昨天晚上调试到了很晚（我说的很晚可能有些朋友觉得很早，不过对于我这种早睡早起的人来说，真的算晚 了），虽然尽力了，但是还是卡在了最后的部分（服务端返回内容的验证解析），周五一大早到公司就开始继续调试，一直到了下午 5 点钟，我的神哪，让我看到那个断点不再跳出一个令我已经看到都反胃的出错提示框（顺便说一下，微软的 vs 出错提示框作的 蛮精致，不过再好看都是出错， 2 天内看到了不下数百次，再好看也让人反胃了），最后在群里面大大的发泄了一把，公司一堆人觉得莫名其妙，不知道我受了什么打击，就搞通一个东西能够压抑成这样，其实这其中的苦也就自己知道，还是那句话：“在没有调试过 .net 的程序以前不知道开源的好啊，能看到源码是多么开心的一件事情啊，整一个 在替微软作白盒测试，连 google 都被我翻烂了，也就只看到几个老外在 Q ，而没有人在那儿 A ”。废话说了那么多，言归正传，实践是建立在理论基础上的，那么先系统性的来介绍一下关于 WSSE 的内容（如果概念已经十分熟悉了，跳过即可），以及如何解决 .net 客户端无法调试 Java 发布的 web service 的问题。

 

在互连网应用中 Web Service 已经得到了广泛的认同，同时也是因为这种广泛的应用，使得 Web Service 在规范化方面越来越成熟。企业和企业之间的信息交互，很重要一点就是信息的安全性，电子商务等互连网应用这方面的需求更为突出，如果没有安全的保证，没有客户或者企业愿意将信息在网上交互，同时也不会信任任何接受到的信息。然而，作为 SOA 的有效技术手段， Web Service 的动态性很强，服务的开发者无法预料到服务将在什么环境下被使用，因此服务的安全性变得更加复杂。

在考虑安全性方面主要有三个关键性的概念：

机密性 (Confidentiality), 完整性（ Integrity ） , 身份鉴别（ Authentication ）。

机密性：除了指定的接受者，其他人无法查看消息的内容。通常会使用密钥（对称或非对称）对消息加密，从而保证消息的机密性。
    完整性：确保消息在传输的过程中没有被修改。即保证消息的接收者接收到的消息与消息发送者最初发送的消息完全一致。通常会对消息做摘要(Digest) ，再使用密钥（对称，非对称）加密摘要，从而保证消息的完整性。   

身份鉴别：确保消息发送者的身份与消息中 所声称的用户身份一致。最简单的做法就是让用户同时发送用户名和密码，服务方确认密码的有效性从而判断该用户身份是否与用户名所代表的一致。然而在实际的 应用中的做法通常不会如此简单，此时往往会使用密钥对一段信息加密，服务方通过解密此信息确认用户的身份。

那么如何选择使用对称密钥还是非对称密钥？什么时候使用公钥 ，什么时候使用私钥 ？首先由于对称密钥的加密解密速度比非对称的密钥快很多（大约 1000 倍），所以在加密消息的时候一般都使用对称密钥。 但是有一个问题就是对称密钥又如何发布呢？网络上两个没有联系的用户如何建立起一个共享的密钥？这时就需要 PKI 来帮助我们将这个共享的密钥建立起来，即利用非对称密钥中的公钥 来加密那个共享密钥，传递到私钥 的拥有方。由此可以知道：对称密钥加密普通信息，非对称密钥加密对称密钥。

在 Integrity 中 ，使用非对称密钥的私钥 加密摘要，得到的东西是一个广为人知的东西 —Digital Signature( 数字签名 ). 而使用对称密钥加密摘要得到的是 HMAC( Hash message authentication codes ) 。他们在保证消息完整性的同时，都具有身份鉴别的功能，不过前者还有 一个功能 --- 抗否认性。值得注意的是在 Confidentiality 中，使用非对称密钥方法是用公钥 加密，私钥 解密，而在 Integrity 中使用非对称密钥的方法恰恰相反。

在当前的安全策略上很多时候会使用到 SSL 和 VPN ，他们的好处和缺点网上都有评论，但作为和传输层无关的安全策略， WS-Security 规范无疑是最具广泛的应用。 IBM ， BEA,Microsoft 共同制定了 WS-Security 规范，解决了安全的三个基本问题：机密性、完整性、身份鉴别，在 Web Services 使用 SOA P （ XML 格式）作为消息封装协议的背景下，标准化组织分别制定了 XML Encryption 、 XML Digital Signature 、与 SAML(XML 格式的 Security Token) 三套规范， WS-Security 则是规定了如何将以上规范组合起来以满足 Web Services 安全需求的一套规范。

XML Signature 规范是将数字签名和 XML 组合而成的产物，不要以为 XML Signature 仅仅是将数字签名技术应用于 XML 文件。

XML Signature 包括以下的功能：

    1 ． XML Signature 可以对任何能够以 URI 形式 (uniform resource identifier) 定位的资源做签名。既包括与签名同在一个 XML 文件中的元素，也包括其他 XML 文件中的元素，甚至可以是非 XML 形式的资源 ( 比如一个图形文件 ) ，只要能被 URI 定位到的资源都可以应用 XML Signature. 这也代表了 XML 签名的对象可以是动态的变化。

    2 ． XML Signature 可以对 XML 文件中的任一元素做签名，也可以对整个文件做签名。

    3 ． XML Signature 既可以用非对称密钥做签名 (Digital Signature) ，也可以用对称密钥做签名 ( HMAC) 。

具体的标签以及含义就不做解释了，不过如果要做签名策略配置，需要熟悉这些标签，这也会影响到后续开发中遇到的各种问题。另外两个规范这边就不做说明了，因为现在服务框架暂时只是提供了 Signature 的要求，如果内容需要加密，那么对于应用来说性能可能是不可接受的，因此需要的是利用 SSL 和签名结合的策略来实现完整的安全机制。

 

对于 WSSE 的支持

       ASF 这部分是改造了 Tusncay 的 Web Service 子项目， Tuscany 子项目内部集成的 web service 的开源框架是 axis2 ，虽然很多朋友评价 xfire 好于 axis2 ，不过个人在使用过程中感觉其实两者各有所长，只是说如何在适当的场合使用，如果需要和 Spring 很好的集成，那么 xfire 当然是最好的选择，如果需要能够有很好的 wsse 以及其他开源支持，那么 axis2 应该是个很不错的选择，毕竟 apache 组织下的开源项目众多，自家人集成起来更是得心应手，特别是 wss4j 和 axis2 的集成， axis2 的 address 和 rampart 两个子插件模块使用起来十分方便，同时在框架的可插入性和模块化上，觉得 axis2 要好过 xfire 。不过 axis2 的客户端比 xfire 要麻烦得多， xfire 封装的好多了，这也是很多人喜欢 xfire 的缘故了（不过再傻瓜也抵不过 .net 客户端的傻瓜，不过这个傻瓜模式无法让人测试，那么就真的被当成傻瓜了），毕竟易用性往往是吸引到第一批客户的重要特质，这也是后续做 ASF 所需要考虑的问题。

       使用 Axis2 的框架结合 Jetty 这个轻量级内嵌容器作为 Web Service 发布框架（不得不提的是，在作 web service 的性能测试的过程中，公司的测试资深人员对于 ASF 的 web service 性能作了肯定，其实这和使用 Jetty 也有一定的关系，现在越来越多的开源框架都使用了 Jetty 作为内置 web 轻量级容器，很灵活，同时也可以达到很好的性能要求，在后面工作中对于 hessian 集成到服务框架中来，也是采用了 Hessian+Jetty ），并且通过 Axis2 的 rampart 集成了 wss4j ，提供了 WSSE 的增强功能。

 

对于认证模式场景需求问题的解决

       ASF 对于 Web Service Security 这部分只是要求了 Signature ，而对于 Signature 需要提供两种方式， UserNameToken 和 X.509 证书。前者提供给内部的一些应用使用，后者提供给外部 ISV 使用，两者主要差别也就是在性能上，后者经过测试，在 CPU 的使用上，是 6-8 倍于不带 Signature 的 Web Service 。

       UserNameToken 这种模式很简单，就很类似于我们平常的用户认证，用户名和密码作为明文或者加密，嵌入在 Soap Header 中即可，客户端根据本地保存的受信用户 记录来交验是否是合法用户。

       X.509 就比较特殊一些，所谓的证书，其中包括了公钥 私钥 对（作为签名和认证使用），证书颁发者的信息（可能是一些 CA 机构或者是用本地的证书生成工具自己生成），证书拥有者的身份信息，以及一些导入的受信第三方的公钥 证书。当前的证书方式的签名认证主要有两种模式，一种是双方证书都是由第三方 CA 认证，同时双方都将对方的 CA 作为可信的 CA ，那么请求发起方将会把自己的证书放入到 Soap Header 中，接受方接受到请求以后，获取证书，发现是受信的 CA ，那么就认为请求发起方身份可信，同时在作完整性摘要校对。另一种模式就是双方的证书可以没有任何权威的 CA 作保证，但是双方首先就需要将附带自己公钥 的证书发送给对方，对方将这附带有公钥 的证书分别导入到证书管理库中 (java 是某个 JKS ， .net 是 windows 的当前用户或者本机的证书管理文件 ) 。双方交互的时候不需要将证书置入 Soap Header 中，但是需要将证书的引用标示（序列号或者是 X.509 SubjectKeyIdentifier ）传递给服务端，服务端根据 标示在本地的证书库中查找并且校验，这种模式的好处就是不需要 CA 的认证（省钱）同时传递的时候不需要将证书带入到 Header 中，节省了传递报文的大小，缺点就是双方需要互相保存对方的公钥 证书到本地的证书库中，同时这种模式也为跨平台带来了很多问题，后续的互通中就会提到。

       ASF 的证书认证模式中采用了后者，因为要求每个 ISV 去有一个第三方 CA 作为授权不是很可行，但是问题就是如果 ISV 需要导入我们的公钥 证书比较方便，但是我们需要管理那么多 ISV 的证书，同时又需要动态上传修改 保存证书那么就不能用原有的手动导入的模式，同时由于到时候部署的服务器集群不可能都维护一份本地的证书库，因此需要用数据库手段来维护，但是在应用启动以后再要新增或者修改证书，将会比较麻烦，因此采取了扩展 wss4j 的策略读取方式来适应新的应用场景。

 

 

 

扩展的 CrytoProvider 类图

 

扩展后的 keystore 初始化以及 signature 部分流程图

         这部分设计主要是扩展了 WSS4J 的 CrytoProvider , 扩展后的 CrytoProvider 重载了获取 X509 证书的几个方法，这里类似于 AOP ，通过提供 ICertsLoaderHandler 接口来回调获取其它存储内的 certs 构建 visual keystore ，同时在作 signature 的时候，如果发现 ISV 的 cert 不存在于当前的 visual keystore 中根据 CrytoProvider 的接口实现，来决定是全部刷新还是部分获取刷新当前的 visual keystore 中的 certs 。这样就可以达到了动态装载和刷新 certs 的要求，同时根据性能要求选择配置和实现不同的 CrytoProvider 。

 

.Net 和 Java 的互通

       Java 的客户端和服务端 Security 互通很快就搞定了，只是对于一些应用场景做证 书管理的扩展。然而，在经历了 .net 客户端调用 Java 发布的 ws 返回数组对象类型的问题以后，又一个大难题摆在了我的面前， ISV support 小组和测试部 的日报上把 .net 客户端无法在 wsse 的模式下调用 Java 发布的 Web Service 作为了重点问题，需要我支持，那么当然当仁不让的接下来尽快搞定了，虽然对 .net 来说，我算是新手中的新手，不过经过两天的测试，让我总结出了 .net 调试的技巧，那就是截包分析 （感觉又回到我前几年在通信行业干活时的状况，对于对方协议不了解，又没有源码可看，那么就截报文来分析么）。开始挺乐观的，想着 WS-Security 微软也是参与者么，应该会严格遵守的，估计一天搞定，结果活活的折腾了两天，下面所描述的如何互通可能总的看起来应该不是很复杂，不过摸索的过程可真是很费事， google 的每一条老外的信息都被我看过了，但是 Question 多 Answer 少。废话不多说，进入正题。

       首先不管是什么客户端调用什么服务端，都需要先做一件事情，准备 key pairs 。在 Java 中证书管理库可以通过 Jdk 提供的 key tools 这个工具生成 jks 格式的 Java Key Store ，可以将公钥 导出，或者将公钥 导入，同时可以生成秘钥 对保存在证书中。在 .net 中可以通过 makecert 的工具来生成符合 Public Key Cryptography Standards #12 ， PKCS#12 标准定义，包含了公钥 和私钥 的二进制格式的证书形式，以 pfx 作为证书文件后缀，同时可以通过 mmc 对 windows 的证书存储区进行管理，导入或者导出证书。其实 .net 和 java 的互通关键问题就是出在证书格式不同以及获取证书的算法上。下面就具体的描述一下如何从 Java 的开发者来做好 Java WebService 和 .net 互通的工作。

 

一． 准备双方的证书和公钥

首先通过 Java 的 keytools 生成了两个 jks ，一个叫做 alisoft.jks ，另一个叫做 myisvdemo.jks ，这里需要注意，在使用 keytools 生成证书的时候会提示需要输入两个密码，一个是 keystore 的密码（每次对 keystore 作操作的时候都需要输入密码来验证），另一个是私钥 保护密码（使用私钥 作签名或者加密的时候需要输入），这两个密码可以设置为不同的值，不过为了后面转换为 .net 的 pfx 格式的证书需要，两者需要设置为相同，同时在早期的 tomcat 中使用证书也有这种限制。然后将两个证书都自签名并将公钥 导出，分别叫做 alisoft.rsa 和 myisvdemo.rsa （因为我这里用的是 rsa 算法，所以用了这个后缀，其实可以直接命名为 .cer 后缀，因为它们的类型其实就是 base64 编码后的没有私钥 的证书，可以直接导入到 windows 中）。

准备好了这四份文件以后，将 myisvdemo.rsa 导入到 alisoft.jks 中（由于测试不采用上面提到的数据库存储的方式，因此直接导入作测试）。然后，通过一个叫做 jks2pfx 的工具包，将 myisvdemo.jks 转成为 myisvdemo.pfx 文件，通过 mmc 导入到本地计算机的证书管理中。

 

 

这时候，双击这两个证书都会显示当前的 Ca 根证书不受信任，可以直接拖动复制增加到受信任的根证书颁发机构的证书中，就不会再显示这样的提示了。最后分别将这两个证书在复制到受信任人的证书中。至此，客户端和服务端的证书都已经准备好了，接下去就是如何配置使用 .net 的客户端来调用已经发布成为带有 WSSE 的 Java Web Service 了。

 

二． 配置 .net 的客户端

首先，作为测试就建立了一个 C# 的 Windows Application, 然后在默认的 form 上面加了一个 button 作为激发调用服务端的事件控制载体。用 .net 来调用 web service 通常情况使用增加一个 web reference 来注入这个远程服务，不过这边要特别特别 强调，如果你要使用 WSSE 的话，不要急于先建立一个 Web Reference ，首先要将你的安全策略配置好，然后再建立 web reference ，不然自己手动的要去修改后台客户端代码。那么接着来说说 .net 的 WSE 。

.net 提供的 WSE （ Web Services Enhancements ）是用来增强对于 Web Service 的支持配置（包括了 WS-Security 等规范）。当前 .net 的 WSE 最新版本是 3.0 的，可以很方便的集成到 VS2005 中，而它的 2.0 版本主要是针对过去的 VS2003 版本，不过两者都是可以用的，但是在配置上面有一些差异，同时使用的方便程度也有些差距， 2.0 使用起来相对 3 要复杂一些。不过我们这里介绍的都是通过设置 WS-Policy 来应用 WS-Security ，这样比较方便，同时代码简洁，业务逻辑和具体的 WS 配置分开，是一种较好的使用模式， .net 也支持代码内嵌 WS-Security 逻辑来实现 WS-Security 的使用。

       我先来说 一下 3 如何使用。安装好 3 以后，可以在我们的项目右键菜单中最下面看到 WSE 3.0 setting ，直接选择这项，弹出类似的设置页，第一页最顶上的一项选中。

 

       然后选择 Policy Tab 页面设置，首先选中 Enable Policy ，然后选择 Add ，输入一个 Policy 的名称，后面就是一个向导配置页面，第一页的选择如下图

 

 

       后面第一个要选择的 x.509 证书是本地的密码对存在的证书，也就是用来签名并向服务端发起请求的证书所在位置，选择了 LocalMachine ，然后再选择证书，也就是上面我导入到系统中的 myisvdemo 证书。然后出现如下图

 

 

       将配置修改成图中所示，首先不要选择支持 1.1 扩展，因为 .net 和 java 对 1.1 扩展的支持实现有所差异，特别是签名回执上，连域名都不一致，所以使用起来有问题。然后我们现在只是要用 sign-only 的功能，因此就选择这项。

       下一页是选择服务端响应时使用什么证书作为解析的证书，这里就选择 local Machine 的 alisoft 证书。至此 Policy 全部配置完成，关闭配置文件。在我们的工程里面会新增加一些文件，如下图所示：

 

 

 

 

       其中在 references 中的是引入的第三方包，主要是为了将普通的 web Service 的代理类转变成为支持 WSSE 的代理类（这也是为什么我说不要先急着建立 web reference 的缘故，如果先建立 web reference 的话），打开 Reference.map 中的 reference.cs 文件，可以看到 服务代理类是继承System.Web.Services.Protocols.SoapHttpClientProtocol ，而如果在配置好策略以后服务代理类就会自动继承 Microsoft.Web.Services3.WebServicesClientProtocol ，此时的服务代理类才可以支持WSSE 的功能，因此如果先建立reference 就要手动的去修改这些客户端文件。

    然后打开wse3policyCache.config 文件，这个文件就是刚才配置的Policy 文件，修改establishSecurityContext = "false " ，这个参数如果为true 的话，会连续两次发送请求，后一次的请求内将不带有Policy 中配置的信息（这个具体的我还不是很清楚，只是看到一个国外的人询问微软工程师的时候，认为这个是个缺陷，但是微软工程师则认为这是一个让用户集成自己配置的扩展点，不过个人认为，所谓扩展点应该是在默认没有扩展的时候不影响原有的配置）。第二需要在我们的axis2 中除了配置signature 还需要配置timestamp ，默认每一次请求.net 都会自动将timestamp 作为action 执行。

    打开app.config 文件，这里面指定了web service 的policy 配置文件，这里没有什么需要修改的，只需要按照他生成的内容即可。然后建立好web Reference ，这个十分简单，就是输入wsdl 的URI ，然后填入服务的名称即可。最后一部就是写测试代码，重新打开Form1.cs ，在button 的onclick 事件中写入下面的测试代码：

private void button1_Click(object sender, EventArgs e)

        {

// AccountServiceWse 是你的客户段代理类，有WSSE 的增强功能，参看reference.cs 文件

            AccountServiceWse service = new AccountServiceWse();

 

            // 这个客户端代理类需要指定刚才配置的策略名称  

            service.SetPolicy("clientPolicy");

    

            // 简单的测试代码

            accountService.ArrayOfAccountBean result = service.getUserAccountArr("test" );

        }

噩梦开始了，到此为止， .net 给 web Service 开发者带来的便利真的是无话可说，绝对的傻瓜级，但是就是这短短的几段代码，最后一句话执行的时候总是出现错误，那个黄色的小框让我看得快崩溃了。

 

 

       根据上图的提示，错误应该在客户端这边， Java 服务端也看过，已经接收到请求并且认证签名通过，并且反签发送回客户端，同时从 Response 的 InnerXml 中拷贝出来可以看到返回的结果 Soap 包都是正确的，客户端的错误就是 Referenced security token could not be retrieved ，这个就表明了客户端的 alisoft 的公钥没有找到，导致检查返回结果的时候出现了问题，那么就去找是否是因为格式不同导致公钥没有导入或者导入错误（错误的查错方向）。

       最后发现原因出在了获取 key 的标示上，前面说到如果不是第三方权威的 CA 认证模式下，需要双方互相导入对方的公钥到本地的证书管理库中，我们是将 Jks 中的公钥导出，然后导入到了本机的证书管理模块中。公钥证书的引用在 WS-Security 中分成两种： SKIKeyIdentifier 和 IssuerSerial ，由于我们前面提到的扩展 ISV 证书动态载入的需要，我们一直使用的是 IssuerSerical 。但是微软的工具生成的是 x.509v3 版本，而 java keytools 生成的是 x.509v1 版本，如果使用 IssuerSerical 会有问题。那么只能使用 SKIKeyIdentifier ，但是使用 SKIKeyIdentifier ， .net 默认使用的是自身的 window 的序列化方式，不过可以设置其为 java 的 RFC3280 协议方式，但是 .net wse 2 和 wse 3 的 RFC3280 方式都不一样， wse 2 的可以和 java 互通， wse 3 就不可以，也就是说 2 和 3 本身在 RFC3280 的序列化方式上都有差别，自己也不能互通，因此没有办法，只能够安装 2 版本，重新来生成。下面将描述一下如何用 wse 2 来订制 web service 的 WSSE 客户端。

 

WSE2 客户端的操作流程（使用的是 WSE 2 sp3 ）：

首先还是要设置 WSE 的 Policy 到新建项目中去，不过这而 WSE 2 没有像 WSE3 那么好的集成到 VS2005 中，新建好工程以后，建立 Web Reference （这和 WSE3 不太一样，这里先建 Web Reference ，然后手动的去设置）。同样去选择 project 菜单的 show all files 。这时候通过外部打开 WSE 2 的配置工具，配置工具选择打开新建的这个项目的 app.config 文件，然后开始配置策略。配置如下列图：

 

 

 

 

       红色部分很重要，需要选择这种协议来序列化获得 key reference 。

 

 

       这里配置策略文件有所不同，这里首先会让你输入这个 Policy 所属的 URI ，和 3 不同， 3 中是在代码中配置进去的，在配置中只是申明，而没有对应配置到具体的哪一个请求，这边可以填入某一个 URI ，那么你对那个 URI 的 WebService 做任何请求的时候都会采取该策略，同时如果你就不填任何内容，直接用他默认的 ，那么所有不在指定 URI 对应策略中出现的 URI 请求和响应，都将采取这种策略，我就默认采用这种模式，因为如果不采用这种模式，相应回来的请求就找不到可以使用的策略了（这个出错信息也困扰我不少时间）。继续配置下面的内容：

 

 

 

 

      

这里我们只需要做 signature ，所以只配置了签名。

 

 

 

 

这里选择证书根据前面页面中配置的存储位置相关，第一个证书是用来签名的带有私钥的证书。第二个是受信的返回的签名交验证书。

 

 

配置完成，并保存。接下去就是要做一些 wse3 自动作的事情，而在 wse2 中需要手动修改的内容。首先把 project 菜单的 show all files 去掉，然后再选上，就会发现项目中多了一个文件： policyCache.config ，选中这个文件然后右键选择 Include in project ，不然的话每次调试都不会被拷贝到项目执行目录下面（类似于 eclipse 的 src 目录中文件在调试中会被拷贝到 bin 目录下），然后将这个文件的属性 Copy to Output Directory 设置为 Copy always, 这样每次修改以后都会被同步过去。然后选择项目右击 add reference ，加入 Microsoft.Web.Services2 这个类库，修改 Web References 下定义的服务的 Reference.cs ，将服务继承类修改一下，例如我的项目中的服务自动生成以后这么继承：

AccountService : System.Web.Services.Protocols.SoapHttpClientProtocol

修改成为：

    AccountService : Microsoft.Web.Services2.WebServicesClientProtocol

这样定义的代理类就可以有WSSE 服务增强功能了，不过注意的是如果Update 了Web Reference 的话，自动会从新生成新的客户端代理，那么又要手动去修改了。（发现如果再次通过wse 2 的配置工具打开app.config 文件, 选中General 下面的框就可以类似于3 自动生成了）

    然后双击打开policyCache.config 文件，做部分的修改：

首先在文件头部有这么一段描述：

      < defaultEndpoint >

      < defaultOperation >

        < request policy = "#Sign-X.509 " />

        < response policy = "#Sign-X.509-1 " />

        < fault policy = "" />

      defaultOperation >

defaultEndpoint >

评论

1 楼 bovxiu2 2012-05-29  

看的迷迷糊糊的  我要学的太多了。 希望楼主能坚持  对于菜鸟的我们提供帮助
先谢过