You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by David Valeri <dv...@apache.org> on 2010/07/28 23:09:26 UTC
WSS4JInInterceptor more lax in enforcing actions when encountering message containing a SOAP Fault
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?
RE: WSS4JInInterceptor more lax in enforcing actions when encountering message containing a SOAP Fault
Posted by David Valeri <dv...@apache.org>.
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:dkulp@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
dkulp@apache.org
http://dankulp.com/blog
Re: WSS4JInInterceptor more lax in enforcing actions when encountering message containing a SOAP Fault
Posted by Daniel Kulp <dk...@apache.org>.
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
dkulp@apache.org
http://dankulp.com/blog