You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-user@axis.apache.org by Graham Holden <Gr...@versionone.co.uk> on 2012/01/03 17:56:45 UTC
Empty Security header/mustUnderstand=1
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-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
Re: Empty Security header/mustUnderstand=1
Posted by Ted Toth <tx...@gmail.com>.
Don't know if this will help since I'm using the Java implementation
but I just went through what I think must be a similar situation
calling a dotnet service which I resolved by doing the following:
( (Stub)
binding)._setProperty(org.apache.axis.client.Call.CHECK_MUST_UNDERSTAND,
Boolean.FALSE);
Maybe someone can comment on how you could do a similar thing in C.
Ted
On Tue, Jan 3, 2012 at 10:56 AM, Graham Holden
<Gr...@versionone.co.uk> wrote:
> 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-unsubscribe@axis.apache.org
> For additional commands, e-mail: c-user-help@axis.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org