Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
To: dev@cxf.apache.org
Subject: Re: More on server response policies
Date: Wed, 8 Oct 2008 13:38:34 -0400
User-Agent: KMail/1.9.9
References: <0EF8EE34-0EFF-488F-8611-476C8BE21817@dushin.net>
In-Reply-To: <0EF8EE34-0EFF-488F-8611-476C8BE21817@dushin.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200810081338.34328.dkulp@apache.org>


Fred,

Long message...    Defintely would like to see what Sergey says.  :-)


On Wednesday 08 October 2008, Fred Dushin wrote:

.......snip............


>   C. The policy alternative selection algorithm (the
> AlternativeSelector) is different on the inbound request and outbound
> response sides.  

Right.   On the inbound side, we don't know ahead of time exactly what 
will be the effective policy as we don't know what operation is being 
invoked.   Thus, a policy is setup that encompasses all operations.   On 
the outbound side, we know exactly which operation was invoked so a 
policy can be computed exactly for that operation.

What may be needed is something that runs after the operation is 
determined that recomputes the incoming effective policy. 

Note: with 2.1.2 and earlier, the client side behaved similarly.   
However, on the client side, we always know the operation, so for 
2.1.3/2.2, this is changed to really create the policy for the specific 
operation on both in and out.

> In particular, on the inbound request side, all 
> possible alternatives are selected, whereas on the outbound response
> side, the default AlternativeSelector (the MinimalAlternativeSelector)
> on the PolicyEngine is used, which generally picks one alternative
> from a collection possibilities.  As a consequence, not only are the
> AssertionInfo instances on the response AssertionInfoMap different
> from those on the request (B above), but the structure of the
> AssertionInfoMap itself is different.
>
> The combination of B and C actually conspires to yield another, more
> serious bug.
>
> Consider the following effective policy:
>
> <wsp:Policy>
>      <wsp:ExactlyOne>
>          <foo:Bar/>
>          <gnu:Gnat/>
>      </wsp:ExactlyOne>
> </wsp:Policy>
>
> On the inbound request, the key set of the AssertionInfoMap will
> contain the QNames:
>
> [{foo}Bar, {gnu:Gnat}]
>
> whereas the key set of the AssertionInfoMap on the outbound response
> will contain just the QName (say):
>
> [{foo}Bar]

Hmm..... probably should have Gnat in there as well....  Hmm.....


> [marginally better] Copy the asserted AssertionInfo objects that have
> been satisfied on the inbound request to the outbound response.  The
> assertions have already been checked off.  Why should we need to do
> this again on the outbound response?  That still won't actually solve
> the bug I've identified here, but it might still be a good thing to
> do, nonetheless.
>
> [better] Discriminate between inbound and outbound policies, and the
> level of configuration.  That way, the user can say, "here are the
> inbound policies I expect/require to be satisfied on the inbound side,
> and here are the policies for the outbound side".  The problem with
> this is that it would probably only really work when specifying
> policies through Spring, since I don't think there's a way to specify
> this sort of distinction in WSDL, or whatever other policy retrieval
> mechanisms we support.

Actually, it CAN be done in WSDL.   MS does this. Policies can be 
attached to the input and output messages which are then merged into the 
one attached to the binding.   This is part of the source of the problem 
above.   Without knowing the operation, we don't know WHICH input 
message to look at to determine the effective policy.


> [not sure, but I think it's my choice] Do away with the policy
> interceptors on the outbound server response, all together.
> Seriously, why do we need these?  What's the use-case?  

Uhh....  WS-SecurityPolicy?   Seriously.   The WS-SecurityPolicy stuff 
I've written uses the policies in the AssertionInfoMap to figure out how 
to output the message.

That said, I think the PolicyVerificationOutInterceptor should just log a 
warning if something isn't asserted properly.   By the time it runs, 
stuff is already written out to the client.  It's too late to throw a 
fault.   For the interceptors the can detect that a policy isn't 
assertable and they know before things are written out, that interceptor 
should throw an exception imediately, not wait for the verification to 
occur.   Example: if the password for the X509Token isn't correct or 
similar.  Instead of not asserting the X509Token policy, throw an 
exception.


> The only think 
> I can think of is something like "encrypting the response", or
> something like that.  However, I'm not sure there is a standard policy
> that expresses this.  There might be application-specific policies
> that have this need, but I can't really picture them.
>
> Thoughts on a solution?
>
> -Fred
>
> [1] https://issues.apache.org/jira/browse/CXF-1849


-- 
J. Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog