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

发布时间:2014-10-22 13:41:20编辑 分享查询网我要评论
本篇文章主要介绍了"WS-Security Interoperability Workarounds: WebSphere, JBoss, Axis and .Net",主要涉及到WS-Security Interoperability Workarounds: WebSphere, JBoss, Axis and .Net方面的内容,对于WS-Security Interoperability Workarounds: WebSphere, JBoss, Axis and .Net感兴趣的同学可以参考一下。

1. .Net client -> WebsphereWS Service Restrictions: WSE 3.0 will insert WS-Addressing elements in outgoing SOAP message by default. Unfortunately, its <Action> element will be empty by default. I have not found any way to remove wsa elements within WSE 3.0. Once you provide wsa elements in soap message, WebsphereWS will dispatch the message according to these elements, even the mustUnderstand is 0/false. I have not found any way to make WebsphereWS omit wsa elements. 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 = "")][WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)][SoapActor()]public class Service : WebService{} 2. JBossWS Client/WebsphereWS Client -> .Net Service Restrictions: By default, .Net service will assume aes-256 is used as symmetric key algorithm by soap client when applying encryption. I have not found any way to specify other symmetric key algorithms for .Net service, both <keyExchangeFormatters> and <keyAlgorithm> does not work. Both JBossWS and WebsphereWS Client do not use aes-256 as symmetric key algorithm by default. 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: 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" /> 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/ security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider 

上一篇:[原创] 计划公示