cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Dushin <>
Subject More on server response policies
Date Wed, 08 Oct 2008 17:02:19 GMT
This is a continuation of the discussion at

I've confirmed that this is still an issue in 2.2-SNAPSHOT, and I'd  
like to start a discussion of solutions.  I'll start by describing the  
policy framework architecture, as I understand it, but I'll focus on  
the server-side of a CXF request and response, when policy is  
involved.  This should give enough context to form a discussion of how  
to proceed.

Generally, the way the CXF policy framework works is as follows  
(please chime in if I've gotten any details wrong).  When the policy  
framework is loaded, at least 2 interceptors are installed on the  
interceptor chain (and again, let's just focus, for the time being, on  
the inbound server request and outbound server response):

  * ServerPolicy(In|Out)Interceptor
  * PolicyVerification(In|Out)Interceptor

The role of the ServerPolicy*Interceptors are to:
  1. Establish the "effective" policy for the request/response, based  
off a collection of policy sources (WSDL, Spring, etc)
  2. Select a set of policy assertion alternatives, using an  
alternative selector (defined essentially at Bus granularity)
  3. Construct an AssertionInfoMap, which is basically just a map from  
the policy assertion QNames out of the list of selected assertions to  
the selected assertions, themselves.  Think of it as a multimap.  Once  
constructed, the AssertionInfoMap placed on the message, for  
subsequent interceptors to inspect and/or mutate.

The role of the PolicyVerification*Interceptor is to compare the  
asserted policies against the effective policies, and to compute  
whether the effective policy has been satisfied by the collection of  
asserted policies.  If the effective policy is so satisfiable, then  
the request is allowed to proceed; otherwise, a fault is raised (and I  
see that in 2.2, Dan has added some nice helpful information about  
why).  (A bug has been identified [1] in the case of faults thrown in  
the PolicyVerificationOutInterceptor.)

(Between these interceptors, applications (like a WS-* provider) are  
expected to inspect and/or mutate the AssertionInfo objects in the  
AssertionInfoMap, to indicate that a particular policy assertion has  
been satisfied in the runtime.)

Now, the server-side request and response processing is slightly  
asymmetric, in the following respects:

  A. When processing an inbound request, the intervening interceptors  
are sandwiched by a  ServerPolicyInInterceptor and a  
PolicyVerificationInInterceptor, whereas the outbound response  
interceptor chain is sandwiched by a ServerPolicyOutInterceptor and a  
  B. The AssertionInfoMap, and the association policy assertion  
instances contained in them, are different instances on the inbound  
request and outbound response chains.  In particular, any policy  
assertion instances that are "checked off" on the inbound request side  
must also be checked off on the outbound response side.
  C. The policy alternative selection algorithm (the  
AlternativeSelector) is different on the inbound request and outbound  
response sides.  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:


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):


Now let's say a client sends a request that satisfies <gnu:Gnat>.  The  
effective policy will have been satisfied on the inbound request;  
however, on the outbound response, it will not.  The result is a fault  
raised in the PolicyVerificationOutInterceptor, though by [1], this  
can easily go undetected.

So, what are the solutions?

[bad] One workaround is to set the AlternativeSelector on the  
PolicyEngine to be something like the UnionAlternativeSelector that's  
used on the inbound request side.  That way, the AssertionInfoMap on  
the outbound response will contain all the "right" QNames, and the  
effective policy will be reported as being satisfied.  One reason this  
is bad is that the PolicyEngine is global wrt the Bus, so this sort of  
change to the engine would have all sorts of nasty unintended side- 
effects.  Perhaps a better level of granularity would work, where you  
could specify a specific policy alternative selector on a per- 
interceptor-chain basis, which would mitigate the badness, a bit.

[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.

[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?  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?



View raw message