综合前段时间对各种语言的接入情况，包括Java Xfire、.Net WSE 2.0、.Net WSE 3.0、.Net WCF、Php WSO2/WSF、Ruby WSO2/WSF，各种框架的接入难易程度不通，对wss支持的设计方式也不一样；下面就WSO2/WSF和其他各框架的设计方式及其接入成本等进行下对比；阅读全文>
发表于 @ 2008年04月22日 15:38:00|评论(loading...)|收藏
虽然说web service说是完全跨平台的，但在实际开发过程中还是会出现很多的不兼容问题，这不仅仅是由于开发人员的代码编写上，连某些标准规范都是有瑕疵的，并不是说遵循了SOAP标准规范就没有任何问题了，至于这点，大家可以多参考WS-I标准，他里面指出了很多能够保证最大化兼容性的措施和方法，这会非常有用；阅读全文>
发表于 @ 2008年04月22日 14:12:00|评论(loading...)|收藏
通过这段时间的预研发现Python语言中能够支持wss的框架很少而且极不成熟，现在能够了解到的有SOAPpy、pyGridWare、Ndg Security；当然，这些框架都还依赖于一些很知名的框架包，比如ZSI等；前两者官方文档中没有任何关于对wss支持的说明和sample，只是论坛和mail list中说这个框架能实现对wss的支持，但具体如何实现没有线索，据我的估计，这两个框架即使能实现，自己也需要写非常多的代码实现，在我的预研过程中早期就已经放弃这两个框架了；之后我转向了Ndg Security这个框架，这个框架确定能支持wss，而且有部分文档和sample可供参考；阅读全文>
发表于 @ 2008年04月17日 14:27:00|评论(loading...)|收藏
前段时间利用数字证书对几种语言（Java、.Net、Php） 调用WS-Security支持的Web Service进行了联调测试，在这个过程中各语言需要的证书格式并不一致，比如说Java我们采用jks，.Net采用pfx和cer，Php则采用pem和cer；本文会对Security证书相关各类文件格式进行一个汇总，并描述各种格式的适用场景；主要分成两类，其一为密钥库文件格式、其二为证书文件格式；阅读全文>
发表于 @ 2008年03月31日 17:59:00|评论(loading...)|收藏
目前在PHP中调用带有WS-Security支持的Web Service解决方案还是比较少的，WSF/PHP是一个不错的选择，官方首页为http://wso2.org/projects/wsf/php，下面就介绍下在运用WSF/PHP的时候需要注意的一些地方；
阅读全文>
发表于 @ 2008年03月29日 17:06:00|评论(loading...)|收藏
针对不同的.Net SDK版本有三种实现来满足对带有WS-Security支持的Web Service调用，即WSE 2.0、WSE 3.0、WCF【Windows Communication Foundation】；其中WSE 2.0针对的是VS 2003版本，WSE 3.0针对的是VS 2005版本，WCF针对的是VS 2008，从SDK要求来看，WSE 2.0和3.0是2.0，而WCF要求是3.0或3.5；前面我的同事已经将WSE 2.0调通，但是对WSE 3.0始终无法调通，具体可以参见《Web Service 、WS-Security、Java和.net的互通(在路上-基于SCA规范的应用服务框架成长记之四》；而WCF经过微软研究院几个月的调试，也已经调通，具体可以参见《.Net在Alibaba的AEP平台上的应用》；不幸的是，针对这两种配置方案经测试是不兼容的，因为不止是.Net客户端调整配置和代码，Java服务端仍然要做出调整，这对于我们的系统侵入是非常大的，因为现在已经有ISV采用WSE 2.0实现在生产环境运行了，要想在服务端做出调整的话必须要做到无缝升级，也即线上所阅读全文>
发表于 @ 2008年03月25日 17:53:00|评论(loading...)|收藏
客户端默认开启了enableSignatureConfirmation标识，这样客户端就需要验证ws返回的xml里面的wsse:SignatureConfirmation信息，而服务端却在axis2.xml中设置了false，服务端若设置为true，则要求请求的接收方确认响应中包括了来自请求的所有签名，否则验证不通过；客户端在验证服务端返回的xml有效性的时候要求：验证的顺序一定要和服务端设置一致；比如我们服务端对返回xml设置了Timestamp和Signature，那么客户端设置的InHandler中对应的action也必须是Timestamp和Signature，并且顺序要一致，否则就会验证不通过（这个在wss4j的mail list中有很多人认为这是一个bug，这个要求太强制了，wss4j也承诺后续将这个实现也改掉）；X509KeyIdentifier, DirectReference两者是将证书信息直接暴露在请求的soap xml中；而其他三者只保存对证书的标识性信息，接收端可以根据这些信息到证书库中取出具体的证书来进行相应的操作；阅读全文>
发表于 @ 2008年03月20日 20:42:00|评论(loading...)|收藏
.Net环境下每次用RSA算法加密都会得到不同的结果，这是因为每次都添加了一些随机数，其实这些随机数的生成也是遵循算法标准的，更专业的说是随机填充算法，比如NoPadding、ISO10126Padding、OAEPPadding、PKCS1Padding、PKCS5Padding、SSL3Padding，而最常见的应该是OAEPPadding【Optimal Asymmetric Encryption Padding】、PKCS1Padding；.Net的实现用的是PKCS1Padding，而且只有这一种实现，也不能通过参数指定用哪种填充算法；另外，通过RSACryptoServiceProvider.KeyExchangeAlgorithm查看到的结果是RSA-PKCS1-KeyEx，由于无法看到源码，不知道最后的KeyEx代表什么意思？阅读全文>
发表于 @ 2008年03月16日 21:31:00|评论(loading...)|收藏
RFC可以译为【请求注解】；他包含了关于Internet的几乎所有重要的文字资料。通常，当某家机构或团体开发出了一套标准或提出对某种标准的设想，想要征询外界的意见时，就会在Internet上发放一份RFC，对这一问题感兴趣的人可以阅读该RFC并提出自己的意见；绝大部分网络标准的指定都是以RFC的形式开始，经过大量的论证和修改过程，由主要的标准化组织所指定的，但在RFC中所收录的文件并不都是正在使用或为大家所公认的，也有很大一部分只在某个局部领域被使用或并没有被采用，一份RFC具体处于什么状态都在文件中作了明确的标识。现在通过RFC发布标准的组织已经很多了，比如IETF、IAB、ISO、ANSI、ITU等等；
PKCS是由美国RSA数据安全公司及其合作伙伴制定的一组公钥密码学标准，其中包括证书申请、证书更新、证书作废表发布、扩展证书内容以及数字签名、数字信封的格式等方面的一系列相关协议。
X.509是由ITU-T为证书及其CRL格式提供了一个标准；但X.509本身不是Internet标准（因为不是由IETF制定），它定义了一个开放的框架，并在一定的范围内可以进行扩展。
其实ITU阅读全文>
发表于 @ 2008年03月13日 16:11:00|评论(loading...)|收藏
私钥加密是可以用公钥解密的；所以说对于RSA算法，用任何一方密钥加密都可以用另外一个密钥解密；这也从另外一个角度说明，其实公钥和私钥是相对而言的，发放其中一个密钥出去，另外一个自然也就成为私钥了；
数字签名包括4个步骤：消息散列，DER数据编码，RSA私钥加密和字节串到位串的转换。
数字签名的验证过程包括四个步骤：位串到字节串的转换，RSA公钥解密，DER数据解码，得到解密后的散列值，最后与原始数据散列值进行比较，若每一位都相同则返回true，否则返回false；阅读全文>
发表于 @ 2008年03月12日 20:06:00|评论(loading...)|收藏