[ 
https://issues.apache.org/jira/browse/CXF-6144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ruud de Jong updated CXF-6144:
------------------------------
    Description: 
If a WebService has WS-Security with the soap body as part of the signature, 
the incoming security check (by the WSS4JInInterceptor) will break.
This bugs was introduced in 2.7.9 and is still present in the current codebase 
(3.0.3).
This problem is caused by the WSS4JInInterceptor. It uses the 
"SAAJInInterceptor.INSTANCE.handleMessage(msg)" on getSOAPMessage to convert a 
CXF SoapMessage to a javax.xml.soap.SOAPMessage.
During this conversion, the SAAJInInterceptor add an empty text-node at the end 
of the soap-body.
This breaks when the soap-body is part of the signature.

The old 2.7.8 version of the SAAJInInterceptor did (line 223:) 
StaxUtils.readDocElements(soapMessage.getSOAPPart().getEnvelope().getBody(), 
xmlReader, true, true);
The new 2.7.9 version does (line 140:)
StaxUtils.copy(xmlReader1, new SAAJStreamWriter(e.getSOAPPart(), 
e.getSOAPPart().getEnvelope().getBody()), true, true);

If I use XmlDebug in WSS4JInInterceptor right after this call, the old version 
returns:
(see attachment soap-body-2.7.8.txt)
while the new version returns:
(see attachment soap-body-2.7.9.txt)

Notice the additional #text/"\n" inside the body.

For this debug logging, I changed the WSS4JInInterceptor:
    private SOAPMessage getSOAPMessage(SoapMessage msg) {
        SAAJInInterceptor.INSTANCE.handleMessage(msg);
        return msg.getContent(SOAPMessage.class);
    }

to 
        private SOAPMessage getSOAPMessage(SoapMessage msg) {
                SAAJInInterceptor.INSTANCE.handleMessage(msg);
                SOAPMessage soapMsg = msg.getContent(SOAPMessage.class);
                SOAPPart soapPart = soapMsg.getSOAPPart();
                debugDomDocument(soapPart);
                return soapMsg;
        }

        private void debugDomDocument(Document doc) {
                ByteArrayOutputStream baos = new ByteArrayOutputStream();
                PrintStream ps = new PrintStream(baos);
                XmlDebug.printDocument(ps, doc);
                ps.flush();
                ps.close();
                LOG.warn("SoapPart via XmlDebug: " + baos.toString());
        }


  was:
If a WebService has WS-Security with the soap body as part of the signature, 
the incoming security check (by the WSS4JInInterceptor) will break.
This bugs was introduced in 2.7.9 and is still present in the current codebase 
(3.0.3).
This problem is caused by the WSS4JInInterceptor. It uses the 
"SAAJInInterceptor.INSTANCE.handleMessage(msg)" on getSOAPMessage to convert a 
CXF SoapMessage to a javax.xml.soap.SOAPMessage.
During this conversion, the SAAJInInterceptor add an empty text-node at the end 
of the soap-body.
This breaks when the soap-body is part of the signature.

The old 2.7.8 version of the SAAJInInterceptor did (line 223:) 
StaxUtils.readDocElements(soapMessage.getSOAPPart().getEnvelope().getBody(), 
xmlReader, true, true);
The new 2.7.9 version does (line 140:)
StaxUtils.copy(xmlReader1, new SAAJStreamWriter(e.getSOAPPart(), 
e.getSOAPPart().getEnvelope().getBody()), true, true);

If I use XmlDebug in WSS4JInInterceptor right after this call, the old version 
returns:
(see attachment soap-body-2.7.8.txt)
while the new version returns:
(see attachment soap-body-2.7.9.txt)

Notice the additional #text/"\n" inside the body.


> WS-Security fails if body has signature on WSS4JInInterceptor
> -------------------------------------------------------------
>
>                 Key: CXF-6144
>                 URL: https://issues.apache.org/jira/browse/CXF-6144
>             Project: CXF
>          Issue Type: Bug
>          Components: WS-* Components
>    Affects Versions: 2.7.9
>         Environment: Any
>            Reporter: Ruud de Jong
>         Attachments: XmlDebug.java, soap-body-2.7.8.txt, soap-body-2.7.9.txt
>
>
> If a WebService has WS-Security with the soap body as part of the signature, 
> the incoming security check (by the WSS4JInInterceptor) will break.
> This bugs was introduced in 2.7.9 and is still present in the current 
> codebase (3.0.3).
> This problem is caused by the WSS4JInInterceptor. It uses the 
> "SAAJInInterceptor.INSTANCE.handleMessage(msg)" on getSOAPMessage to convert 
> a CXF SoapMessage to a javax.xml.soap.SOAPMessage.
> During this conversion, the SAAJInInterceptor add an empty text-node at the 
> end of the soap-body.
> This breaks when the soap-body is part of the signature.
> The old 2.7.8 version of the SAAJInInterceptor did (line 223:) 
> StaxUtils.readDocElements(soapMessage.getSOAPPart().getEnvelope().getBody(), 
> xmlReader, true, true);
> The new 2.7.9 version does (line 140:)
> StaxUtils.copy(xmlReader1, new SAAJStreamWriter(e.getSOAPPart(), 
> e.getSOAPPart().getEnvelope().getBody()), true, true);
> If I use XmlDebug in WSS4JInInterceptor right after this call, the old 
> version returns:
> (see attachment soap-body-2.7.8.txt)
> while the new version returns:
> (see attachment soap-body-2.7.9.txt)
> Notice the additional #text/"\n" inside the body.
> For this debug logging, I changed the WSS4JInInterceptor:
>     private SOAPMessage getSOAPMessage(SoapMessage msg) {
>         SAAJInInterceptor.INSTANCE.handleMessage(msg);
>         return msg.getContent(SOAPMessage.class);
>     }
> to 
>       private SOAPMessage getSOAPMessage(SoapMessage msg) {
>               SAAJInInterceptor.INSTANCE.handleMessage(msg);
>               SOAPMessage soapMsg = msg.getContent(SOAPMessage.class);
>               SOAPPart soapPart = soapMsg.getSOAPPart();
>               debugDomDocument(soapPart);
>               return soapMsg;
>       }
>       private void debugDomDocument(Document doc) {
>               ByteArrayOutputStream baos = new ByteArrayOutputStream();
>               PrintStream ps = new PrintStream(baos);
>               XmlDebug.printDocument(ps, doc);
>               ps.flush();
>               ps.close();
>               LOG.warn("SoapPart via XmlDebug: " + baos.toString());
>       }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to