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 behavior?
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 [mailto:dk...@apache.org] Sent: Thursday, July 29, 2010 5:23 PM To: dev@cxf.apache.org 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 at > all. It would seem that the first if condition and the final else can be > handled by checkActions (while taking into account the ignoreActions flag). > The middle condition looks to be a potential security flaw in that we let > unsecured faults through without honoring the user's actions configuration. > 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 dk...@apache.org http://dankulp.com/blog
