You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Auke Schrijnen <as...@bkwi.nl> on 2019/09/30 09:40:21 UTC
Custom wsa:To value in SOAP responses
Hi,
We are trying to implement a couple of services in Apache Axis2 and Apache Synapse which must conform to the Dutch specifications ‘Digikoppeling’ and 'SuwiML Transactiestandaard’. This is basically ‘WS-I Basic Profile 1.1’ with a few additional requirements.
One of the requirements is the use of the WS-Addressing To header in the response. Although the services only have synchronous request-response operations we have to set the wsa:To header in the response to a custom value. The result is that Axis2 tries to send the response to the address specified in the wsa:To header, which we don’t want since this is a synchronous request-response operation.
I noticed that this is the case for both the Axis2 Commons HTTP sender (CommonsHTTPTransportSender.java @ 221) and the Apache Synapse PassThrough (PassThroughHttpSender.java @ 258) and NIO sender (HttpCoreNIOSender.java @ 257).
The 'Web Services Addressing 1.0 - SOAP Binding’ specification states that ‘any response message SHOULD be sent using a separate connection and using the address value specified by response endpoint’ when a value other than "http://www.w3.org/2005/08/addressing/anonymous" is used, but this applies to 'response endpoint’, which ‘refers to the [reply endpoint] and [fault endpoint]’ (see https://www.w3.org/TR/ws-addr-soap/#addressesinsoap). It’s not clear to me if the ‘reply endpoint’ or ‘fault endpoint’ refers to the wsa:From header in the response or only the ReplyTo and FaultTo in the request.
Is the implementation in Axis2 and Synapse too strict and should it allow any value for the wsa:To in the response, or does our requirement conflict with the WS-Addressing specification?
Auke
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@axis.apache.org
For additional commands, e-mail: java-user-help@axis.apache.org
Re: Custom wsa:To value in SOAP responses
Posted by "robertlazarski ." <ro...@gmail.com>.
On Tue, Oct 8, 2019 at 1:42 AM Auke Schrijnen <as...@bkwi.nl> wrote:
> Our question is more about the WS-Addressing spec and if Axis2 and Synapse
> have implemented it correctly than how to work around the current behavior
> of Axis2 and Synapse.
>
I see.
These Axis2 contributions were made by fairly wide range of committers, who
eventually became inactive in Axis2 around a decade ago.
The WS-Addressing specs were drafted around 2004-2006, as I remember it
Sanjiva Weerawarana was on the WS-Addressing committee. Via his WSO2
company, he and his team of developers became Apache committers and
contributed their implementation of the spec to Axis2.
A few years later, a team of IBM developers became Apache committers and
implemented the WS-Addressing spec in their contribution of JAXWS to Axis2.
IOW, some of the people who drafted the WS-Addressing specs were Apache
committers and contributed a large share of the related code in Axis2.
I myself was active in the project in those days however I contributed in
other area such as the Spring implementation in Axis2. I merely can only
recall the history, and help maintain the code, at this point.
Regards,
Robert
> >
> > Auke
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe@axis.apache.org
> > For additional commands, e-mail: java-user-help@axis.apache.org
> >
>
>
Re: Custom wsa:To value in SOAP responses
Posted by Auke Schrijnen <as...@bkwi.nl>.
Thank you for your reply, see my inline response for some clarification.
> Op 7 okt. 2019, om 18:11 heeft robertlazarski . <ro...@gmail.com> het volgende geschreven:
>
> Hello, please see my comments inline.
>
> On Sun, Sep 29, 2019 at 11:40 PM Auke Schrijnen <as...@bkwi.nl> wrote:
> Hi,
>
> We are trying to implement a couple of services in Apache Axis2 and Apache Synapse which must conform to the Dutch specifications ‘Digikoppeling’ and 'SuwiML Transactiestandaard’. This is basically ‘WS-I Basic Profile 1.1’ with a few additional requirements.
>
> One of the requirements is the use of the WS-Addressing To header in the response. Although the services only have synchronous request-response operations we have to set the wsa:To header in the response to a custom value. The result is that Axis2 tries to send the response to the address specified in the wsa:To header, which we don’t want since this is a synchronous request-response operation.
>
>
> The Axis2 module trunk/modules/addressing/test has a wide range of example code that may help you here.
>
> There is also a jaws-integration module with addressing test code.
>
> I would start there.
>
> Having a response sent to another address than "the address specified in the wsa:To header" may require some custom coding or handlers - not sure.
Thanks for the suggestion, we have indeed created a custom handler. Since we don’t want the response message to be sent to a specific URL but want to sent it back over the current HTTP channel we remove the wsa:To from the message context after adding it to the response SOAP Header.
>
> I noticed that this is the case for both the Axis2 Commons HTTP sender (CommonsHTTPTransportSender.java @ 221) and the Apache Synapse PassThrough (PassThroughHttpSender.java @ 258) and NIO sender (HttpCoreNIOSender.java @ 257).
>
>
> We are about to remove any older support for commons httpclient 3. You can use the http client 4 classes by changing your axis2.xml transportSender element to instead use org.apache.axis2.transport.http.impl.httpclient4.HTTPClient4TransportSender .
The behavior isn’t specific for httpclient 3, the class for httpclient 4 (HTTPClient4TransportSender) extends the same class (CommonsHTTPTransportSender).
>
>
> The 'Web Services Addressing 1.0 - SOAP Binding’ specification states that ‘any response message SHOULD be sent using a separate connection and using the address value specified by response endpoint’ when a value other than "http://www.w3.org/2005/08/addressing/anonymous" is used, but this applies to 'response endpoint’, which ‘refers to the [reply endpoint] and [fault endpoint]’ (see https://www.w3.org/TR/ws-addr-soap/#addressesinsoap). It’s not clear to me if the ‘reply endpoint’ or ‘fault endpoint’ refers to the wsa:From header in the response or only the ReplyTo and FaultTo in the request.
>
> Interestingly enough I see a lot of axis2 source code use of the wsa headers, but nothing on wsa:From ... at a glance, I may have missed something.
Sorry, I wrote wsa:From but I meant wsa:To.
>
> Is the implementation in Axis2 and Synapse too strict and should it allow any value for the wsa:To in the response, or does our requirement conflict with the WS-Addressing specification?
>
>
> These specs are rather old now but anyways the main reason for the current axis2 behavior is security related of course, I found this section to be relevant:
>
> "
> Messages that use wsa:ReplyTo or wsa:FaultTo headers whose [address] is not the predefined anonymous URI should include claims that allow a receiver to confirm that the EPR was issued by a principle with authority to represent the [address] of the EPR.
>
> When receiving a SOAP message, certain SOAP headers may have resulted from the serialization of an EPR's [reference parameters] property. A SOAP message receiver should perform additional security and sanity checks to prevent unintended actions.
>
> "
This section is about the wsa:ReplyTo and wsa:FaultTo. In our scenario those are both absent or set with the anonymous url. Maybe an example of our scenario can help:
A client sends a request:
<Envelope>
<Header>
<wsa:From>http://some-uri-defined-by-client</wsa:From>
<wsa:ReplyTo>
<wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address>
</wsa:ReplyTo>
...
</Header>
<Body>
...
</Body>
</Envelope>
And we want to respond with:
<Envelope>
<Header>
<wsa:To>http://some-uri-defined-by-client</wsa:To>
...
</Header>
<Body>
...
</Body>
</Envelope>
In Apache Synapse we can set the wsa:To header using the Header mediator. The same can be done using an Axis2 service by setting the To value in the response message context. The default Axis2 behavior is that the response will be sent to the given url (http://some-uri-defined-by-client in the example). With our custom handler we are able to add the header to the SOAP envelope and remove the To value from the context in order to send the response over the current http connection.
Our question is more about the WS-Addressing spec and if Axis2 and Synapse have implemented it correctly than how to work around the current behavior of Axis2 and Synapse.
> Regards,
>
> Robert
>
>
> Auke
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-user-help@axis.apache.org
>
Auke
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@axis.apache.org
For additional commands, e-mail: java-user-help@axis.apache.org
Re: Custom wsa:To value in SOAP responses
Posted by "robertlazarski ." <ro...@gmail.com>.
Hello, please see my comments inline.
On Sun, Sep 29, 2019 at 11:40 PM Auke Schrijnen <as...@bkwi.nl> wrote:
> Hi,
>
> We are trying to implement a couple of services in Apache Axis2 and Apache
> Synapse which must conform to the Dutch specifications ‘Digikoppeling’ and
> 'SuwiML Transactiestandaard’. This is basically ‘WS-I Basic Profile 1.1’
> with a few additional requirements.
>
> One of the requirements is the use of the WS-Addressing To header in the
> response. Although the services only have synchronous request-response
> operations we have to set the wsa:To header in the response to a custom
> value. The result is that Axis2 tries to send the response to the address
> specified in the wsa:To header, which we don’t want since this is a
> synchronous request-response operation.
>
>
The Axis2 module trunk/modules/addressing/test has a wide range of example
code that may help you here.
There is also a jaws-integration module with addressing test code.
I would start there.
Having a response sent to another address than "the address specified in
the wsa:To header" may require some custom coding or handlers - not sure.
> I noticed that this is the case for both the Axis2 Commons HTTP sender
> (CommonsHTTPTransportSender.java @ 221) and the Apache Synapse PassThrough
> (PassThroughHttpSender.java @ 258) and NIO sender (HttpCoreNIOSender.java @
> 257).
>
>
We are about to remove any older support for commons httpclient 3. You can
use the http client 4 classes by changing your axis2.xml transportSender
element to instead use
org.apache.axis2.transport.http.impl.httpclient4.HTTPClient4TransportSender
.
The 'Web Services Addressing 1.0 - SOAP Binding’ specification states that
> ‘any response message SHOULD be sent using a separate connection and using
> the address value specified by response endpoint’ when a value other than "
> http://www.w3.org/2005/08/addressing/anonymous" is used, but this applies
> to 'response endpoint’, which ‘refers to the [reply endpoint] and [fault
> endpoint]’ (see https://www.w3.org/TR/ws-addr-soap/#addressesinsoap).
> It’s not clear to me if the ‘reply endpoint’ or ‘fault endpoint’ refers to
> the wsa:From header in the response or only the ReplyTo and FaultTo in the
> request.
>
Interestingly enough I see a lot of axis2 source code use of the wsa
headers, but nothing on wsa:From ... at a glance, I may have missed
something.
> Is the implementation in Axis2 and Synapse too strict and should it allow
> any value for the wsa:To in the response, or does our requirement conflict
> with the WS-Addressing specification?
>
>
These specs are rather old now but anyways the main reason for the current
axis2 behavior is security related of course, I found this section to be
relevant:
"
Messages that use wsa:ReplyTo or wsa:FaultTo headers whose [address] is not
the predefined anonymous URI should include claims that allow a receiver to
confirm that the EPR was issued by a principle with authority to represent
the [address] of the EPR.
When receiving a SOAP message, certain SOAP headers may have resulted from
the serialization of an EPR's [reference parameters] property. A SOAP
message receiver should perform additional security and sanity checks to
prevent unintended actions.
"
Regards,
Robert
Auke
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-user-help@axis.apache.org
>
>