检验了一下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的一个缺陷
