ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Giger (JIRA)" <>
Subject [jira] [Commented] (WSS-486) Streaming code does not process a (non-secured) SOAP Fault correctly
Date Mon, 13 Jan 2014 10:24:50 GMT


Marc Giger commented on WSS-486:

Hi Colm,

I think this is a bug in CXF's wss-stax integration.

When a fault is received CXF builds a new interceptor chain (CheckFaultInterceptor:~69) to
process the fault.
So far so good if WSS4JStaxInInterceptor wouldn't be in the new chain too (see StackTrace
below). But since it is it creates a new instance of InboundWSSec, the security processing
starts from beginning again but the first element it sees is the
Fault element. The Fault element is of course not a valid soap:Envelope that then triggers
the exception you've seen.
Btw, this setup resulted in a chained security processing. The later instance of the WSSecurityStreamReader
wraps the first one.

So either do not append the WSS4JStaxInInterceptor to the fault chain, or set a prop, like
it is done in the WSS4JInInterceptor
to determine if security is already processed:

if (msg.containsKey(SECURITY_PROCESSED) || isGET(msg)) {

There is nothing I can do in the wss-stax code.

java.lang.Exception: Stack trace
        at java.lang.Thread.dumpStack(
        at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
        at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(
        at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(
        at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(
        at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
        at org.apache.cxf.endpoint.ClientImpl.onMessage(

> Streaming code does not process a (non-secured) SOAP Fault correctly
> --------------------------------------------------------------------
>                 Key: WSS-486
>                 URL:
>             Project: WSS4J
>          Issue Type: Bug
>            Reporter: Colm O hEigeartaigh
>            Assignee: Marc Giger
>             Fix For: 2.0.0
> The streaming code does not process a non-secured SOAP Fault correctly. I've merged some
code to the PolicyEnforcer to not throw a PolicyValidationException when we are an initiator
+ there is no security header + there is no SOAP Fault. This allows a client to see what the
actual error message is, rather than complain about an insecured response.
> However, there is a bug in the SecurityHeaderInputProcessor, it throws the following
> Caused by: org.apache.wss4j.common.ext.WSSecurityException: Request is not a valid SOAP
>         at org.apache.wss4j.stax.impl.processor.input.SecurityHeaderInputProcessor.processNextEvent(
> I can only reproduce in conjunction with CXF. See the following test ("testSOAPFaultError"):

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message