Web Service 、WS-Security、Java和.net的互通(在路上-基于SCA规范的应用服务框架成长记之四)

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使用SOAP（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