You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Fred Dushin (JIRA)" <ji...@apache.org> on 2007/07/14 02:53:04 UTC
[jira] Created: (CXF-790) SOAP headers copied from input
SOAPMessage to output SOAPMessage
SOAP headers copied from input SOAPMessage to output SOAPMessage
----------------------------------------------------------------
Key: CXF-790
URL: https://issues.apache.org/jira/browse/CXF-790
Project: CXF
Issue Type: Bug
Components: Soap Binding
Affects Versions: 2.0
Reporter: Fred Dushin
Priority: Blocker
Fix For: 2.0.1
When a request is made on a server, the SOAP headers in a request appear to be copied directly to the response SOAP message.
This is pretty severe in the case of WS-Security, because the consumer of the response has to use the header information to "decode" the message, since the security headers contain implicit instructtions for decrypting and verifying signatures on elements in the message (possibly elements in the security header, itself). Typically, the originator of the request (e.g., the client) does not have the key material to do this decoding.
One potential solution would be for the security interceptors to strip the SAAJ SOAPMessage of its headers as part of its processing the request, but i) it's not clear we really want to do that -- subsequent consumers on the interceptor chain, or possibly the application itself, may need this information; ii) furthermore, there's no guarantee that a security interceptor will be installed in an application, so there are scenarios where such a solution would not be efficacious.
I would prefer instead that the SOAPMessage representing the response, as it is passed to the outbound interceptor on the server side, be more of a blank slate.
This probably applies to other WS-* specs that rely on proper processing of SOAP headers.
A sample CXF program will be enclosed shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-790) SOAP headers copied from input
SOAPMessage to output SOAPMessage
Posted by "Ulhas Bhole (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512910 ]
Ulhas Bhole commented on CXF-790:
---------------------------------
Hi Fred,
What you are mentioning
"I would prefer instead that the SOAPMessage representing the response, as it is passed to the outbound interceptor on the server side, be more of a blank slate. "
was the original behavior but we try to do it now and it will break out-of-band headers and any application specific headers that were added from service side will be removed even before reaching the other side.
Every component/module which adds the headers to SOAPMessage should also have a capability to consume it and remove it from the HeaderList while reading. This was never enforced or affected the applications until the Headers were changed from DOM elements to List and made available to application via. WebServiceContext for application specific out-of-band header. Latter part (of making header list available to application and sending the out-of-band headers back) made this problem visible.
> SOAP headers copied from input SOAPMessage to output SOAPMessage
> ----------------------------------------------------------------
>
> Key: CXF-790
> URL: https://issues.apache.org/jira/browse/CXF-790
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
> Affects Versions: 2.0
> Reporter: Fred Dushin
> Priority: Blocker
> Fix For: 2.0.1
>
> Attachments: CXF-790.tar.gz
>
>
> When a request is made on a server, the SOAP headers in a request appear to be copied directly to the response SOAP message.
> This is pretty severe in the case of WS-Security, because the consumer of the response has to use the header information to "decode" the message, since the security headers contain implicit instructtions for decrypting and verifying signatures on elements in the message (possibly elements in the security header, itself). Typically, the originator of the request (e.g., the client) does not have the key material to do this decoding.
> One potential solution would be for the security interceptors to strip the SAAJ SOAPMessage of its headers as part of its processing the request, but i) it's not clear we really want to do that -- subsequent consumers on the interceptor chain, or possibly the application itself, may need this information; ii) furthermore, there's no guarantee that a security interceptor will be installed in an application, so there are scenarios where such a solution would not be efficacious.
> I would prefer instead that the SOAPMessage representing the response, as it is passed to the outbound interceptor on the server side, be more of a blank slate.
> This probably applies to other WS-* specs that rely on proper processing of SOAP headers.
> A sample CXF program will be enclosed shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CXF-790) SOAP headers copied from input
SOAPMessage to output SOAPMessage
Posted by "Ulhas Bhole (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ulhas Bhole reassigned CXF-790:
-------------------------------
Assignee: Ulhas Bhole
> SOAP headers copied from input SOAPMessage to output SOAPMessage
> ----------------------------------------------------------------
>
> Key: CXF-790
> URL: https://issues.apache.org/jira/browse/CXF-790
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
> Affects Versions: 2.0
> Reporter: Fred Dushin
> Assignee: Ulhas Bhole
> Priority: Blocker
> Fix For: 2.0.1
>
> Attachments: CXF-790.tar.gz
>
>
> When a request is made on a server, the SOAP headers in a request appear to be copied directly to the response SOAP message.
> This is pretty severe in the case of WS-Security, because the consumer of the response has to use the header information to "decode" the message, since the security headers contain implicit instructtions for decrypting and verifying signatures on elements in the message (possibly elements in the security header, itself). Typically, the originator of the request (e.g., the client) does not have the key material to do this decoding.
> One potential solution would be for the security interceptors to strip the SAAJ SOAPMessage of its headers as part of its processing the request, but i) it's not clear we really want to do that -- subsequent consumers on the interceptor chain, or possibly the application itself, may need this information; ii) furthermore, there's no guarantee that a security interceptor will be installed in an application, so there are scenarios where such a solution would not be efficacious.
> I would prefer instead that the SOAPMessage representing the response, as it is passed to the outbound interceptor on the server side, be more of a blank slate.
> This probably applies to other WS-* specs that rely on proper processing of SOAP headers.
> A sample CXF program will be enclosed shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-790) SOAP headers copied from input
SOAPMessage to output SOAPMessage
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp resolved CXF-790.
-----------------------------
Resolution: Fixed
> SOAP headers copied from input SOAPMessage to output SOAPMessage
> ----------------------------------------------------------------
>
> Key: CXF-790
> URL: https://issues.apache.org/jira/browse/CXF-790
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
> Affects Versions: 2.0
> Reporter: Fred Dushin
> Assignee: Ulhas Bhole
> Priority: Blocker
> Fix For: 2.0.1
>
> Attachments: cxf-790-testcase.patch, CXF-790.tar.gz
>
>
> When a request is made on a server, the SOAP headers in a request appear to be copied directly to the response SOAP message.
> This is pretty severe in the case of WS-Security, because the consumer of the response has to use the header information to "decode" the message, since the security headers contain implicit instructtions for decrypting and verifying signatures on elements in the message (possibly elements in the security header, itself). Typically, the originator of the request (e.g., the client) does not have the key material to do this decoding.
> One potential solution would be for the security interceptors to strip the SAAJ SOAPMessage of its headers as part of its processing the request, but i) it's not clear we really want to do that -- subsequent consumers on the interceptor chain, or possibly the application itself, may need this information; ii) furthermore, there's no guarantee that a security interceptor will be installed in an application, so there are scenarios where such a solution would not be efficacious.
> I would prefer instead that the SOAPMessage representing the response, as it is passed to the outbound interceptor on the server side, be more of a blank slate.
> This probably applies to other WS-* specs that rely on proper processing of SOAP headers.
> A sample CXF program will be enclosed shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-790) SOAP headers copied from input
SOAPMessage to output SOAPMessage
Posted by "Fred Dushin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fred Dushin updated CXF-790:
----------------------------
Attachment: cxf-790-testcase.patch
This patch can be applied to the CXF tree, using the svn-apply perl script from Subversion.
It adds a system test into ws/security, for testing round-trip message protection. The test will fail on the response side, until we address CXF-790 (either in general, or specifically in the WSS4JInInterceptor)
> SOAP headers copied from input SOAPMessage to output SOAPMessage
> ----------------------------------------------------------------
>
> Key: CXF-790
> URL: https://issues.apache.org/jira/browse/CXF-790
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
> Affects Versions: 2.0
> Reporter: Fred Dushin
> Assignee: Ulhas Bhole
> Priority: Blocker
> Fix For: 2.0.1
>
> Attachments: cxf-790-testcase.patch, CXF-790.tar.gz
>
>
> When a request is made on a server, the SOAP headers in a request appear to be copied directly to the response SOAP message.
> This is pretty severe in the case of WS-Security, because the consumer of the response has to use the header information to "decode" the message, since the security headers contain implicit instructtions for decrypting and verifying signatures on elements in the message (possibly elements in the security header, itself). Typically, the originator of the request (e.g., the client) does not have the key material to do this decoding.
> One potential solution would be for the security interceptors to strip the SAAJ SOAPMessage of its headers as part of its processing the request, but i) it's not clear we really want to do that -- subsequent consumers on the interceptor chain, or possibly the application itself, may need this information; ii) furthermore, there's no guarantee that a security interceptor will be installed in an application, so there are scenarios where such a solution would not be efficacious.
> I would prefer instead that the SOAPMessage representing the response, as it is passed to the outbound interceptor on the server side, be more of a blank slate.
> This probably applies to other WS-* specs that rely on proper processing of SOAP headers.
> A sample CXF program will be enclosed shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-790) SOAP headers copied from input
SOAPMessage to output SOAPMessage
Posted by "Fred Dushin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fred Dushin updated CXF-790:
----------------------------
Attachment: CXF-790.tar.gz
Instructions:
1. Unpack in a recent CXF kit in the samples directory.
2. Issue ant build
3. In a separate window, issue ant server
4. Issue ant client
On the server console, you will see the following trace:
{{{
[java] InInterceptor: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
[java] <soap:Header xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
[java] <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soap:mustUnderstand="1" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Timestamp-5896854"><wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2007-07-14T00:53:25.251Z</wsu:Created><wsu:Expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2007-07-14T00:58:25.251Z</wsu:Expires></wsu:Timestamp></wsse:Security></soap:Header><soap:Body xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><sayHi xmlns="http://apache.org/hello_world_soap_http/types"/></soap:Body></soap:Envelope>
[java] Executing operation sayHi
[java]
[java] OutInterceptor: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header><wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soap:mustUnderstand="1" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Timestamp-5896854"><wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2007-07-14T00:53:25.251Z</wsu:Created><wsu:Expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2007-07-14T00:58:25.251Z</wsu:Expires></wsu:Timestamp></wsse:Security></soap:Header><soap:Body><sayHiResponse xmlns="http://apache.org/hello_world_soap_http/types"><responseType>Bonjour</responseType></sayHiResponse></soap:Body></soap:Envelope>
}}}
Description:
This scenario is based off the CXF hello world sample, except that 2 interceptors have been added. On the client side, a WSS interceptor, which adds a WSS Security header with a Timestamp element. On the server side, a 2 simple interceptors that serialize the input and output DOM structures. (I might have been able to use logging interceptors, but I implemented these so that they would be closer to the SAAJ interfaces).
Youll see that no additions are made in the server to the headers.
> SOAP headers copied from input SOAPMessage to output SOAPMessage
> ----------------------------------------------------------------
>
> Key: CXF-790
> URL: https://issues.apache.org/jira/browse/CXF-790
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
> Affects Versions: 2.0
> Reporter: Fred Dushin
> Priority: Blocker
> Fix For: 2.0.1
>
> Attachments: CXF-790.tar.gz
>
>
> When a request is made on a server, the SOAP headers in a request appear to be copied directly to the response SOAP message.
> This is pretty severe in the case of WS-Security, because the consumer of the response has to use the header information to "decode" the message, since the security headers contain implicit instructtions for decrypting and verifying signatures on elements in the message (possibly elements in the security header, itself). Typically, the originator of the request (e.g., the client) does not have the key material to do this decoding.
> One potential solution would be for the security interceptors to strip the SAAJ SOAPMessage of its headers as part of its processing the request, but i) it's not clear we really want to do that -- subsequent consumers on the interceptor chain, or possibly the application itself, may need this information; ii) furthermore, there's no guarantee that a security interceptor will be installed in an application, so there are scenarios where such a solution would not be efficacious.
> I would prefer instead that the SOAPMessage representing the response, as it is passed to the outbound interceptor on the server side, be more of a blank slate.
> This probably applies to other WS-* specs that rely on proper processing of SOAP headers.
> A sample CXF program will be enclosed shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.