WS-Security Interoperability Issues: WebSphere, JBoss, Axis and .Net

 

检验了一下WS-Security的互操作情况，涉及到了4种WSS开发包：Websphere Web Services 1.0, JBossWS 1.0.2, WSS4J 1.5.0, WSE 3.0. 总体来说，JBossWS是功能最弱的一种，但配置最简单，Websphere Web Services是功能最强的一种，但配置最复杂；WSS4J和WSE介于两者之间

 

问题一：客户端用Websphere Web Services，服务端用JBossWS，使用UsernameToken时，<wsse:UsernameToken>缺了wsu:Id属性，JBoss会用异常来抱怨：

<wsse:UsernameToken xmlns:wsse="...">

<wsse:Username xmlns:wsse="...">ibm</wsse:Username>

<wsse:Password Type="..." xmlns:wsse="...">was</wsse:Password>

</wsse:UsernameToken>

org.jboss.ws.wsse.WSSecurityException: Invalid message, UsernameToken is missing an id at org.jboss.ws.wsse.element.UsernameToken.<init>(UsernameToken.java:60)

除Websphere Web Services外，其它3种开发包缺省都会为<wsse:UsernameToken>提供wsu:Id属性，除了JBossWS外，其它3种开发包都能处理<wsse:UsernameToken>不带wsu:Id属性的情况

 

问题二：客户端用Websphere Web Services，服务端用JBossWS，使用加密时，<EncryptionMethod>缺了显式的XML namespace 声明，JBoss会用异常来抱怨：

<EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">

<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />....<..>

</EncryptedKey>

 

<EncryptedData Id="wssecurity_encryption_id_3" Type="http://www.w3.org/2001/04/xmlenc#Content" xmlns="http://www.w3.org/2001/04/xmlenc#">

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

</EncryptedData>

org.jboss.ws.WSException: Content root name does not match element name: EncryptionMethod != {http://www.w3.org/2001/04/xmlenc#}EncryptionMethod at org.jboss.ws.soap.SOAPContentElement.expandToDOM(SOAPContentElement.java:818)

来看一下完整正确的SOAP片断（显式声明的xml名称空间）：

<xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">

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

</xenc:EncryptedKey>

 

<xenc:EncryptedData Id="..." 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#aes256-cbc" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" />..<..>..

</xenc:EncryptedData>

除Websphere Web Services外，其它3种开发包缺省都会为<EncryptionMethod>提供显式的名称空间声明，除了JBossWS外，其它3种开发包都能处理<EncryptionMethod> without explicit namespace

 

问题三：JBossWS只支持DirectReference或说StraightReference的SecurityTokenReference，不支持KeyID, KeyName, X509Issuer, Embeded等方式，所以同时应用签名和加密的时候，就会出现两个<BinarySecurityToken>，这样另一方尤其是 .Net WSE就会晕菜了：<Header>中有两个Token，但是只期待一个

当然，这是通过WSE Tools选择了Certificate认证模式的结果，如果选择Anonymous，.Net会正确的处理带有多个BinarySecurityToken的SOAP请求，只不过Anonymous模式会掺杂进WSS1.1的特性：它产生的导致JBossWS晕菜的Response是这样的：

<wsse:SecurityTokenReference xmlns:wsse="..">

<wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#EncryptedKeySHA1" EncodingType="...">6LW6sXwrPX0SSBM4nV7OqgjUiv8=</wsse:KeyIdentifier>

</wsse:SecurityTokenReference>

WS-I Basic Profile 1.0 是不支持WSS1.1的

 

问题四：JBossWS和Websphere Web Services不支持UsernameToken的PasswordDigest方式，只支持PasswordText

<!--晕菜-->

<wsse:UsernameToken xmlns:wsu="..." wsu:Id="UsernameToken-5525185">

<wsse:Username>wss4juser</wsse:Username>

<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">WhTMH9PlZsmxrwDRkjgzbxPtZgM=</wsse:Password>

</wsse:UsernameToken>

 

<!--OK-->

<wsse:UsernameToken xmlns:wsu="..." wsu:Id="UsernameToken-5525185">

<wsse:Username>wss4juser</wsse:Username>

<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">wss4jpass</wsse:Password>

</wsse:UsernameToken>

问题五：WSS4J不支持同时使用UsernameToken和Signature，如果UsernameToken的user和用于签名的X509Cert的subject不同的话

因为action="UsernameToken" 和 action="Signature" 使用相同的<parameter name="user" value="username.or.subject"/>来配置username或者subject；这是有理由的，因为UsernameToken和Signature都是用来表明自己身份的，当然Signature主要是校验SOAP消息没有被篡改；通常UsernameToken会和Encryption联合使用，或者Signature和Encryption同时使用；无论如何，这是WSS4J的一个缺陷