Hi, This started out as a plea for help, but turned into a possible workaround for a problem I, and (from old mailing-list messages, and https://issues.apache.org/jira/browse/RAMPART-197), others have been having. I don't really "understand" Rampart/Axis (blundering by search-engine assisted trial-and-error seems to have worked so far!) so if there's a "better" solution, I'd be glad to hear it. Otherwise, I throw this out in case it's of use.
I'm using Axis2/C 1.6 and Rampart 1.3. The scenario is that a 3rd-party product is generating SOAP requests with a security header and we've written written a SOAP server (using the above) to process them. Through trial-and-error, I've massaged the server's "services.xml" to accept/validate/process the request's security header; the problem is that the SOAP response includes an empty security header with "mustUnderstand" set to "1": RETRIEVING DATA.. /* retrieving time = 15:42:54*/ /* time throughput = 1 sec(s)*/ --------------------- HTTP/1.1 200 OK Date: Tue Jan 03 15:42:53 2012 GMT Server: Axis2C/1.6.0 (Simple Axis2 HTTP Server) Content-Type: text/xml;charset=utf-8 Content-Length: 557 <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsse curity-secext-1.0.xsd" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"/> </soapenv:Header> <soapenv:Body> <indexOutgoingDocumentResponse xmlns="http://orchard_genericws_EDRMService/"> <edrmDocumentId>1614</edrmDocumentId> </indexOutgoingDocumentResponse> </soapenv:Body> </soapenv:Envelope> This "emerges" from the Axis/Rampart server quite happily, but throws an exception in the 3rd-party application when it receives it. I've seen some oldish messages indicating that some consumers don't like the empty "<wsse:Security .../>" line, and so because of the "mustUnderstand=1" they throw a fault, but with no obvious resolution. On the assumption that we probably can't get the 3rd-party app changed, is there a way of: a) Setting "mustUnderstand" to "0" (which would presumably let the fact that the 3rd-party app cannot understand the empty element be ignored), or b) Telling Rampart/Axis not to include either the "wsse:Security" element in the header, or not to include the header at all? STOP PRESS: At this point, I remembered seeing something about inflow/outflow addressing in "axis2.xml"; after a bit of playing, I found that commenting-out the "Security" phase from the "outflow" in "axis2.xml": ... <phaseOrder type="inflow"> <!-- System pre defined phases --> <phase name="Transport"/> <phase name="PreDispatch"/> <phase name="Dispatch"/> <phase name="PostDispatch"/> <!-- End system pre defined phases --> <phase name="Security" /> <!--<phase name="Rahas"/>--> <!--phase name="userphase1"/--> <!--phase name="RMPhase"/--> <!--phase name="SavanPhase"/--> </phaseOrder> <phaseOrder type="outflow"> <!-- User defined phases could be added here --> <!--phase name="RMPhase"/--> <!--phase name="SavanPhase"/--> <!--phase name="userphase1"/--> <!--system predefined phase--> <phase name="MessageOut"/> <!--<phase name="Security"/> *** CHANGE HERE *** --> </phaseOrder> ... AND commenting-out the "handler" in "modules\rampart\module.xml": <inflow> <handler name="RampartInHandler" class="mod_rampart"> <order phase="Security"/> </handler> </inflow> <outflow> <!-- *** CHANGE HERE *** <handler name="RampartOutHandler" class="mod_rampart"> <order phase="Security"/> </handler> --> </outflow> Stops Rampart adding any SOAP headers to the response: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <indexOutgoingDocumentResponse xmlns="http://orchard_genericws_EDRMService/"> <edrmDocumentId>1615</edrmDocumentId> </indexOutgoingDocumentResponse> </soapenv:Body> </soapenv:Envelope> (while still processing/checking the incoming security details). This probably won't be suitable in all cases (when you DO need some security stuff in the response), but it might solve at least some of the problems. Graham Holden Software Development Manager Version One Limited Tel. 01625.856500 Fax. 01625.856501 ---------------------------------------------------------------- Version One End-User Seminars REGISTER NOW! http://www.versionone.co.uk/seminars ---------------------------------------------------------------- Version One Ltd. is the author of intelligent electronic document delivery and imaging software. This software enables the electronic storage, retrieval, management, enhancement and delivery of business documents such as invoices, purchase orders and statements. Version One's 'paperless office' technology is seamlessly integrated into all major finance and ERP systems. With a typical ROI of less than six months, Version One's solutions are enabling thousands of organisations to save dramatic amounts of time and money. Version One is a Member of BASDA (Business Application Software Developers Association) and ESA (European Software Association). The opinions expressed within this email represent those of the individual and not necessarily those of Version One Limited. The contents of this email may be privileged and are confidential. It may not be disclosed to or used by anyone other than the addressee(s), nor copied in any way. Version One Limited, Pentland House, Village Way, Wilmslow, Cheshire, SK9 2GH, UK. Registered office: Munro House, Portsmouth Road, Cobham, Surrey, KT11 1TF, UK Registered in England Number: 2443078 VAT Registration Number: 927 5479 83 Version One is an Advanced Computer Software PLC company. ----------------------------------------------------------------- Think about the environment - Do you really need to print this email? --------------------------------------------------------------------- To unsubscribe, e-mail: c-user-unsubscr...@axis.apache.org For additional commands, e-mail: c-user-h...@axis.apache.org