cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Valeri" <>
Subject RE: WSS4JInInterceptor more lax in enforcing actions when encountering message containing a SOAP Fault
Date Fri, 30 Jul 2010 00:42:29 GMT
On a related note, I also noticed that CXF does not attempt to resolve
outbound WS-SP when a fault that is not defined in the WSDL is thrown.  The
logic bails if no BindingFaultInfo can be resolved for the fault being
thrown.  When the inbound security handlers or WS-A handlers or any other
incoming interceptor throw a generic non-WSDL defined SOAP Fault, CXF does
not attempt to apply operation/binding/port/portype level policy if there is
no perfect match on the fault.  Do you know if WS-P/SP has a stance on this

I think a strict fault enforcing flag is in order for the WSS4JInInterceptor
as it could be important to enforcing policy on both WSDL defined faults and
generic SOAP Faults.  Logging the sever-side fault then becomes important
before one clobbers it with the exception from the failed inbound security
validation.  I'm weighing the usability enhancement from returning the true
fault vs. the possibility of a malicious entity poisoning the client with
fake fault responses.

-----Original Message-----
From: Daniel Kulp [] 
Sent: Thursday, July 29, 2010 5:23 PM
Cc: David Valeri
Subject: Re: WSS4JInInterceptor more lax in enforcing actions when
encountering message containing a SOAP Fault

On Wednesday 28 July 2010 5:09:26 pm David Valeri wrote:
> Lines 220-231 deal with the scenario where no security header is present
> all.  It would seem that the first if condition and the final else can be
> handled by checkActions (while taking into account the ignoreActions
> The middle condition looks to be a potential security flaw in that we let
> unsecured faults through without honoring the user's actions
> If the user desires different actions in the fault scenario, they would
> configure different instances of this interceptor in the fault chains. 
> What reason exists for this laxness with respect to action enforcement in
> the fault case?

Well, the main reason is that .net and MOST soap stacks (including CXF 
normally) send faults for security related things back unsecured no matter 
what policies are set on the binding/port/service level.   It's a straight 
soap fault.   Thus, if actions were enforced, the "real" fault that is sent 
back on the wire would be lost due to the fault  of enforcing the actions on

the fault that would not be there.

Daniel Kulp

View raw message