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

发布时间:2017-3-25 8:07:04 编辑:www.fx114.net 分享查询网我要评论
本篇文章主要介绍了"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 = "http://tempuri.org/")][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/java.security: security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider 

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

相关文章

相关评论

本站评论功能暂时取消,后续此功能例行通知。

一、不得利用本站危害国家安全、泄露国家秘密,不得侵犯国家社会集体的和公民的合法权益,不得利用本站制作、复制和传播不法有害信息!

二、互相尊重,对自己的言论和行为负责。

好贷网好贷款