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

1. .Net client -> WebsphereWS Service

Restrictions:

1. WSE 3.0 will insert WS-Addressing elements in outgoing SOAP message by default.

2. Unfortunately, its <Action> element will be empty by default.

3. I have not found any way to remove wsa elements within WSE 3.0.

4. Once you provide wsa elements in soap message, WebsphereWS will dispatch the message according to these elements, even the mustUnderstand is 0/false.

5. I have not found any way to make WebsphereWS omit wsa elements.

6. Then, WebsphereWS will complain that <Action> is empty.

Workaround:

Add the "Action" property of SoapRpcMethodAttribute/SoapDocumentMethodAttribute:

[SoapRpcMethod("", Action="price", RequestNamespace="..", ResponseNamespace="..", Use=SoapBindingUse.Literal)]
[return: System.Xml.Serialization.XmlElementAttribute("priceReturn")]
public string price(string arg_0_0) {
object[] results = this.Invoke("price", new object[] {arg_0_0});
return ((string)(results[0]));
}

or in code you can insert the following line: proxy.RequestSoapContext.Addressing.Action = new Action( "price" ); but it seems not work.

Another Tip: WS-Addressing vs. TCP Monitor

When you route soap message with wsa elements via TCP Monitor to .Net service, The <To> element is incorrect because the port number is the port tcp monitor listening, not the port of final service. So you should make .Net service omit these wsa elements, just add SoapActorAttribute to the service class without any properties:

[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[SoapActor()]
public class Service : WebService{
}

2. JBossWS Client/WebsphereWS Client -> .Net Service

Restrictions:

1. By default, .Net service will assume aes-256 is used as symmetric key algorithm by soap client when applying encryption.

2. I have not found any way to specify other symmetric key algorithms for .Net service, both <keyExchangeFormatters> and <keyAlgorithm> does not work.

3. Both JBossWS and WebsphereWS Client do not use aes-256 as symmetric key algorithm by default.

4. In fact, both SUN JDK and IBM JDK do not support those algorithms that need a key whose size is longer than 128bit by default due to import control restrictions of some countries.

Workaround:

1. First, change the algorithm to aes-256 via IBM WebsphereWS Toolkit for WebsphereWS or configuration file for JBossWS: <encrypt type="x509v3" alias="wse2" algorithm="aes-256" />

2. Second, download the "JCE Unlimited Strength Jurisdiction Policy Files" fron SUN or IBM, and replace the original jars under jre/lib/security folder

Another Tip:

the configuration files schema of JBossWS can be found at $jbossws/src/main/resources/schema folder.

 

3. WSS4J vs. BouncyCastle

wss4j has not been fully tested with SUN JCE provider and IBM JCE provider. They suggest using BouncyCastle as the default JCE provider, so download the jar file and put it to classpath, then modify $JRE_HOME/lib/security/java.security:

security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider