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 03:06:04 UTC

[jira] Updated: (CXF-790) SOAP headers copied from input SOAPMessage to output SOAPMessage

     [ 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.