You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Fred Dushin <fr...@dushin.net> on 2008/10/08 19:02:19 UTC
More on server response policies
This is a continuation of the discussion at
http://mail-archives.apache.org/mod_mbox/cxf-dev/200808.mbox/%3c3AAFD5B7-693A-4FDB-AA50-15696098F98C@dushin.net%3e
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
PolicyVerificationOutInterceptor
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:
<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]
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?
-Fred
[1] https://issues.apache.org/jira/browse/CXF-1849
Re: More on server response policies
Posted by Fred Dushin <fr...@dushin.net>.
Just to be clear, my +1 is a long-term strategy, and is not held with
the conviction of a religious belief. A patch for CXF-1849 has been
applied, and as long as I can get that back-merged to the 2.1.x-fixes
branch, that gets me over the hump.
-Fred
On Oct 9, 2008, at 5:41 PM, Fred Dushin wrote:
> Correct. Dan, you: +1 on logging (FINE or lower log level). Me: +1
> on removing the validation out interceptor (outbound server side
> only), since it's doing nothing put churning cycles and possibly
> confusing the user.
Re: More on server response policies
Posted by Fred Dushin <fr...@dushin.net>.
Yeah, I think this summarizes it well.
On Oct 9, 2008, at 5:10 PM, Sergey Beryozkin wrote:
> Hi,
>
> I'd like to try to summarize what we've talked at this thread. Fred
> - please
> feel free to challenge what I'm about to say :-)
>
> Original problem : server-side outbound Policy interceptor assumes
> that no
> policy alternative has been asserted on the outbound path and
> reports a
> failure by (mistakenly) writing to the output stream.
Correct -- and in general, this will only happen if there is an
alternative of cardinality > 1.
>
>
> During the discussion (I think/hope :-)) we've mostly agreed that
> unless
> there's a really strong need for the application to depend upon the
> out
> verifier failing, this out verifier should do nothing, possibly just
> logging
> a message and perhaps do nothing at all in most cases.
Correct. Dan, you: +1 on logging (FINE or lower log level). Me: +1
on removing the validation out interceptor (outbound server side
only), since it's doing nothing put churning cycles and possibly
confusing the user.
>
>
> It's the role of the actual policy interceptors to take stronger
> action when
> necessary. The role of the verifier is to validate that those
> interceptors
> have actually done their work. Unless the (out) verifier is given
> some hints
> about the scope of a given policy expression, it can not reliably
> assert
> that just because this policy has not been asserted on the outbound
> path it
> means that the policy contract has not been fulfilled.
>
> Note that adding such hints only makes sense when it's of paramount
> importance that the out verifier validates that a given policy has
> been
> engaged on the out path. In other case they're not needed and thus
> the out
> verifier can keep quiet.
>
> Only when we do want the out verifier to fail (softly with WARNING
> or throw
> some exception) then it would make sense adding the hints to the
> policy
> expressions.
>
> One way to provide such hint is basically to do a custom
> implementation of
> PolicyAssertion and return the value based on the custom knowledge
> (similarly to the way interceptors tell about their phases).
>
> Another idea is to introduce new features to represent inbound or
> outbound
> only assertions. IMHO this is a bit too coarse-grained and
> introducing new
> features to represent some qualities of policies (in/out) may not be
> justified. That said this idea may be of help when dealing with
> tightly
> controlled 3rd party policy expressions (see next).
>
> Another idea is to introduce a custom attribute, to be added to
> individual
> policy expressions when needed. There's a concern that it may be too
> intrusive. IMHO the compactness and portability (can be applied to
> policies
> in the wsdl) of this solution outweighs these concerns.
All three ideas amount to essentially the same idea: that the
effective policy (hence the policy vocabulary, hence the contents of
the AssertionInfoMap) is possibly different on the inbound and
outbound interceptor chains. /How/ that's done is probably less
important that /that/ it be done, because I don't think the current
way is really workable -- Right now I have to hack my way through the
outbound response AssertionInfoMap, checking off Assertions that have
already been checked off on the inbound channel, which is a hack
(requires that I artificially store data on the Exchange, etc), and
just adds extra overhead to the runtime.
-Fred
RE: More on server response policies
Posted by Sergey Beryozkin <se...@iona.com>.
Hi,
I'd like to try to summarize what we've talked at this thread. Fred - please
feel free to challenge what I'm about to say :-)
Original problem : server-side outbound Policy interceptor assumes that no
policy alternative has been asserted on the outbound path and reports a
failure by (mistakenly) writing to the output stream.
During the discussion (I think/hope :-)) we've mostly agreed that unless
there's a really strong need for the application to depend upon the out
verifier failing, this out verifier should do nothing, possibly just logging
a message and perhaps do nothing at all in most cases.
It's the role of the actual policy interceptors to take stronger action when
necessary. The role of the verifier is to validate that those interceptors
have actually done their work. Unless the (out) verifier is given some hints
about the scope of a given policy expression, it can not reliably assert
that just because this policy has not been asserted on the outbound path it
means that the policy contract has not been fulfilled.
Note that adding such hints only makes sense when it's of paramount
importance that the out verifier validates that a given policy has been
engaged on the out path. In other case they're not needed and thus the out
verifier can keep quiet.
Only when we do want the out verifier to fail (softly with WARNING or throw
some exception) then it would make sense adding the hints to the policy
expressions.
One way to provide such hint is basically to do a custom implementation of
PolicyAssertion and return the value based on the custom knowledge
(similarly to the way interceptors tell about their phases).
Another idea is to introduce new features to represent inbound or outbound
only assertions. IMHO this is a bit too coarse-grained and introducing new
features to represent some qualities of policies (in/out) may not be
justified. That said this idea may be of help when dealing with tightly
controlled 3rd party policy expressions (see next).
Another idea is to introduce a custom attribute, to be added to individual
policy expressions when needed. There's a concern that it may be too
intrusive. IMHO the compactness and portability (can be applied to policies
in the wsdl) of this solution outweighs these concerns.
Futhermore, IMHO it's unlikely that adding such an attribute would cause any
practical interop/policy validation issues - but if it will then we might be
able to rely on previous proposal or come up with something else such that
we can point to one or more of the assertions inside a given alternative
(lists of qnames or xpaths at the existing policy feature, stripping out
such attributes when publishing them, etc).
I'd like to stress the fact that such hints may only needed when there's an
explicit demand for the out verifier to validate if the policies have been
used on the out path.
Thanks, Sergey
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: More on server response policies
Posted by Fred Dushin <fr...@dushin.net>.
That would probably get me over this particular hump, and it would be
the least disrptive, because I have cases where my clients are barfing
because they are getting an actual response, followed by a fault.
On Oct 8, 2008, at 1:38 PM, Daniel Kulp wrote:
> 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.
Re: More on server response policies
Posted by Daniel Kulp <dk...@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
Re: More on server response policies
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Fred
I strat thinking this message gets a bit off-track :-) Few more comments.
>
> That's fine, in that the AssertionBuilder can render a decision about what interceptors to add to the chain. But that won't
> solve the bug I've identified.
As we've said many times what will solve this problem is the out verifier logging a message. For now, untill
we sort out the issue of hints.
>> I actually think that the single effective policy should apply to the given operation, in/out. But this policy can contain
>> expressions which are valid for the outbound only or inbound only or both. I don't think WS-Policy provides for effective
>> polices for in or out only, It's a single effective policy instance for the scope of a given operation. Though the
>> AssertionInfoMap should be in/out- specific.
>
> How are you going to render that calculation? The policy framework has and should have no idea what the content of the
> assertions is. You don't really want to go peeking into the assertion for breadcrumbs, do you?
Sorry, not following you. Neither I'm talking of the policy engine peeking into the individual assertions,
PolicyAssertion is an interface and the AssertionInfoMap could check the scopes (when they're introduced)
>
>>> How about this, for a proposal:
>>>
>>> <jaxws:endpoint ...>
>>> <jaxws:features>
>>>
>>> <cxf:PolicyFeature>
>>> <wsp:Policy><foo:Bar/></wsp:Policy>
>>> </cxf:PolicyFeature>
>>>
>>> <cxf:InboundPolicyFeature> <!-- new type -->
>>> <wsp:Policy><gnu:Gnat/></wsp:Policy>
>>> </cxf:InboundPolicyFeature>
>>>
>>> <cxf:OutboundPolicyFeature> <!-- new type -->
>>> <wsp:Policy><bling:Blang/></wsp:Policy>
>>> </cxf:OutboundPolicyFeature>
>>>
>>> </jaxws:features>
>>> </jaxws:endpoint>
>>
>> I'd just prefer
>>
>> <wsp:Policy><bling:Blang cxf:scope="default/in/out"/></wsp:Policy>
>
> So, what you're saying is that the policy framework would know something special about the cxf:scope attribute, and that any
> schema for policy assertions would need to be adjusted to support such an attribute. That's kind of messy, isn't it?
Not at all. I think we're getting off track again here. First you're saying that there're no need
for the out interceptor at all, and now you're saying that something has to be adjusted. As I said,
any more or less decent schema has the default extension point for 'any' attributes. Next, often there's
no even need to verify on the outbound path. Only for those polices which really need to do it we can add
such an attribute.
>
> I agree that your proposal is semantically equivalent to mine. I just think it's better to treat the customer's (i.e., the
> customer of the policy f/w) policies as kind of sacrosanct.
>
>> IMHO this is more compact and easier on the eye.
>
> Well, that's an aesthetic argument, which is hard to argue against, because of its subjectivity. Let's talk about it from a
> technical, rather than aesthetic point of view.
No. It's not an aesthetic argument. This solution is more portable in that it can be applied to
policies both in the spring configuration and in WSDL. It's more compact and given that you're concerned about the overall
complexity of Ws-Policy expression I don't get the point of this comment : isn't it what we're after = reducing the complexity as
much as possible ?
Finally, I just don't think it works at all :
>>> <cxf:PolicyFeature>
>>> <wsp:Policy><foo:Bar/></wsp:Policy>
>>> </cxf:PolicyFeature>
>>>
>>> <cxf:InboundPolicyFeature> <!-- new type -->
>>> <wsp:Policy><gnu:Gnat/></wsp:Policy>
>>> </cxf:InboundPolicyFeature>
A single Policy (alternative) expression may contain a bunch of expressions. So instead of
<wsp:Policy><foo:Bar/><bar:Baz wsp:scope="out-only"/></wsp:Policy>
you suggest creating a single feature per single expression. I disagree.
>
> Right, but isn't the wsdl:port really equivalent to the jax:ws endpoint? I thought Dan's point was that you could associate
> policies with in/out messages in the binding, and that would be your mechanism for specifying different effective policies for
> the in and out channels. And that works beautifully in WSDL. My needs are outside of WSDL, so I'd like a spring-based
> mechanism for doing the same kind of thing.
No, that's not correct. As I've said many times before, the fact that your policies live in
spring does not mean that they're different from those living in WSDL. Those which live in Spring
will be attached to WSDL once I fix the pending bug (with truly private stuff being removed). In both cases
these polices are of common interest to both client and server. This is the point of using of WS-Policy.
I don't want to conflate this thread with the discussions on teh purpose of WS-policy though.
>
>> We can also suggest to the ws-policy group to consider standardizing on such attribute (as it can be of real help to client
>> runtimes) in the next maintenance release of the spec, whenever it happens.
>
> Yeah, well, that's not gonna help me with my Q4 release.
I'm sorry - don't get this comment either.
>> On the client it's none needed either - the client needs to iterate through all the available alternatives and find the best
>> one.
>
> Interesting. So it should be the policy consumer that selects the alternatives? I don't think the current architecture supports
> that, does it?
PolicyAlternativeSelector is broken, It has to go. It does not make sense to select only the first alternative,
or the last or the middle one because it's never going to go reliably.
Cheers, Sergey
>
> -Fred
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: More on server response policies
Posted by Fred Dushin <fr...@dushin.net>.
On Oct 9, 2008, at 10:38 AM, Sergey Beryozkin wrote:
>> Does <foo:Bar> apply to the inbound our outbound path? Or both?
>> What are the semantics here?
>
> This coarse-graned policy applies to an endpoint so as I said it's
> up to the <foo:Bar/> implementation as to whether it will affect in/
> out/both pathes.
That's fine, in that the AssertionBuilder can render a decision about
what interceptors to add to the chain. But that won't solve the bug
I've identified.
>> Correct. Or more appropriately, based on the actual content of
>> the policy.
>
> Not necessarily. ...
I guess I wasn't claiming policy content was the only deciding
factor. Let's just drop it.
> I actually think that the single effective policy should apply to
> the given operation, in/out. But this policy can contain expressions
> which are valid for the outbound only or inbound only or both. I
> don't think WS-Policy provides for effective polices for in or out
> only, It's a single effective policy instance for the scope of a
> given operation. Though the AssertionInfoMap should be in/out-
> specific.
How are you going to render that calculation? The policy framework
has and should have no idea what the content of the assertions is.
You don't really want to go peeking into the assertion for
breadcrumbs, do you?
>> How about this, for a proposal:
>>
>> <jaxws:endpoint ...>
>> <jaxws:features>
>>
>> <cxf:PolicyFeature>
>> <wsp:Policy><foo:Bar/></wsp:Policy>
>> </cxf:PolicyFeature>
>>
>> <cxf:InboundPolicyFeature> <!-- new type -->
>> <wsp:Policy><gnu:Gnat/></wsp:Policy>
>> </cxf:InboundPolicyFeature>
>>
>> <cxf:OutboundPolicyFeature> <!-- new type -->
>> <wsp:Policy><bling:Blang/></wsp:Policy>
>> </cxf:OutboundPolicyFeature>
>>
>> </jaxws:features>
>> </jaxws:endpoint>
>
> I'd just prefer
>
> <wsp:Policy><bling:Blang cxf:scope="default/in/out"/></wsp:Policy>
So, what you're saying is that the policy framework would know
something special about the cxf:scope attribute, and that any schema
for policy assertions would need to be adjusted to support such an
attribute. That's kind of messy, isn't it? Would it also mean that
policy assertions were less portable, at least as far as copying/
pasting policies across documents is concerned? It's bad enough, with
all of the namespaces you need to keep track of in a typical CXF
config file.
I agree that your proposal is semantically equivalent to mine. I just
think it's better to treat the customer's (i.e., the customer of the
policy f/w) policies as kind of sacrosanct.
> IMHO this is more compact and easier on the eye.
Well, that's an aesthetic argument, which is hard to argue against,
because of its subjectivity. Let's talk about it from a technical,
rather than aesthetic point of view.
> Furthermore, when such policies will be dynamicallyt attached to
> WSDL instance, it would provide more hints to client runtimes/tools.
> Such attribute can also be applied when polices are explicitly
> attached to WSDL. For ex, as I said earlier, there's no explicit
> indication to verifiers on the scope of this policy when it's
> attached to some container element like wsdl:port
>
> <wsdl:service>
> <wsdl:port>
> <wsp:Policy><bling:Blang/></wsp:Policy>
> </wsdl:port>
> </wsdl:service>
Right, but isn't the wsdl:port really equivalent to the jax:ws
endpoint? I thought Dan's point was that you could associate policies
with in/out messages in the binding, and that would be your mechanism
for specifying different effective policies for the in and out
channels. And that works beautifully in WSDL. My needs are outside
of WSDL, so I'd like a spring-based mechanism for doing the same kind
of thing.
>
>
> we have a PolicyAssertion abstraction and we can add a helper method
> like getScope(), by default it applies to say 'in' only or in/out
> with possisble overrides.
>
> To be honest though, I wouldn't be too concerned now about ensuring
> that outbond policy verifier fails (or reports a warning). I reckon
> the default behaviour (of just logging some FINE message) would do
> in case say <bling:Blang/> ends up in the list of policies.
Well, I think i) it's a waste of time to do -- why do something if it
has no purpose -- green computing, and all that. But also, ii) it's
just going to raise a question with a customer. "Why is there is log
entry that says something failed? The request passed! What's going
on? Quick, file a bug."
> Only when it's absolutely critical that an outbound message does not
> leave the server runtime if some policies have not been applied to
> the outbound message (SLA agreement with non policy aware client
> runtimes for ex) then I'd consider adding such hints.
Hold it -- so you're saying this interceptor should raise a fault?
>> Yup. If it's of no use, remove it.
>
> Mostly agreed but see above - we might need it at some time. And
> it's probably can behave differently on the client side.
It's surely needed on the client side -- I wasn't saying to remove
verification on the outbound side of any side of a request. My
suggestion was to remove the interceptor from the outbound server
response interceptor chain, as it's really doing nothing but chewing
up clock cycles.
> We can also suggest to the ws-policy group to consider standardizing
> on such attribute (as it can be of real help to client runtimes) in
> the next maintenance release of the spec, whenever it happens.
Yeah, well, that's not gonna help me with my Q4 release.
>
> And I'd like to stress again that PolicyAlternativeSelector is
> really not needed at all and it needs to be deprecated.
> On the server side any of the many available alternatives can be
> valid at any moment of time for a given message and once the
> effective policy is calculated it should stay fixed for the outbound
> path. Thus no need for any special alternative algorithms on the
> server.
> On the client it's none needed either - the client needs to iterate
> through all the available alternatives and find the best one.
Interesting. So it should be the policy consumer that selects the
alternatives? I don't think the current architecture supports that,
does it?
-Fred
Re: More on server response policies
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
> Suppose you have this config:
>
> <jaxws:endpoint ...>
> <jaxws:features>
> <cxf:PolicyFeature>
> <wsp:Policy><foo:Bar/></wsp:Policy>
> </cxf:PolicyFeature>
> </jaxws:features>
> </jaxws:endpoint>
>
> Does <foo:Bar> apply to the inbound our outbound path? Or both? What are the semantics here?
This coarse-graned policy applies to an endpoint so as I said it's up to the <foo:Bar/> implementation as to whether it will affect
in/out/both pathes. As far as the policy verification is concerned, the default behaviour is to fail on the inbound path if a single
alternative includinfg a single <foo:Bar/> policy expression has not been asserted and (to be fixed) log a message on the outbound
path.
>> All required interceptors are
>> installed - but the api allows for on-demand interceptors installation (for
>> ex, based in the in message's content & headers).
>
> Correct. Or more appropriately, based on the actual content of the policy.
Not necessarily. Consider an optional MTOM policy assertion. There's no strict need to install an MTOM interceptor
in advance, untill a given message arrives. You can 2 messages coming in, one is non-MTOM, another one is.
>
>> AFAIK,
>> PolicyVerificationInInterceptor would say OK as long as at least one of the
>> alternatives is fully satisfied. In your example we have a compact policy
>> expression, so there'no problems if either <foo:Bar/> or <gnu:Gnat/> has
>> been asserted.
>>
>> On the outbound path only the alternative which has been selected during the
>> inbound path should be optionally verified. I don't think any alternative
>> selection algorithm should apply on the outbound path as we already have an
>> alternative active in the scope of a given operation.
>
> That assumes the effective policy is the same on the inbound and outbound sides. I think that's an invalid assumption (as I
> think you are saying, as well). Or at least I think we should be able to discriminate between inbound and outbound policies. I
> stand corrected in the case of WSDL, but I think we need a way to make the same distinction in spring (and however else we
> retrieve policy).
I actually think that the single effective policy should apply to the given operation, in/out. But this policy can contain
expressions which are valid for the outbound only or inbound only or both. I don't think WS-Policy provides for effective polices
for in or out only, It's a single effective policy instance for the scope of a given operation. Though the AssertionInfoMap should
be in/out-specific.
>
> How about this, for a proposal:
>
> <jaxws:endpoint ...>
> <jaxws:features>
>
> <cxf:PolicyFeature>
> <wsp:Policy><foo:Bar/></wsp:Policy>
> </cxf:PolicyFeature>
>
> <cxf:InboundPolicyFeature> <!-- new type -->
> <wsp:Policy><gnu:Gnat/></wsp:Policy>
> </cxf:InboundPolicyFeature>
>
> <cxf:OutboundPolicyFeature> <!-- new type -->
> <wsp:Policy><bling:Blang/></wsp:Policy>
> </cxf:OutboundPolicyFeature>
>
> </jaxws:features>
> </jaxws:endpoint>
I'd just prefer
<wsp:Policy><bling:Blang cxf:scope="default/in/out"/></wsp:Policy>
IMHO this is more compact and easier on the eye. Furthermore, when such policies will be dynamicallyt attached to WSDL instance, it
would provide more hints to client runtimes/tools. Such attribute can also be applied when polices are explicitly attached to WSDL.
For ex, as I said earlier, there's no explicit indication to verifiers on the scope of this policy when it's attached to some
container element like wsdl:port
<wsdl:service>
<wsdl:port>
<wsp:Policy><bling:Blang/></wsp:Policy>
</wsdl:port>
</wsdl:service>
we have a PolicyAssertion abstraction and we can add a helper method like getScope(), by default it applies to say 'in' only or
in/out with possisble overrides.
To be honest though, I wouldn't be too concerned now about ensuring that outbond policy verifier fails (or reports a warning). I
reckon the default behaviour (of just logging some FINE message) would do in case say <bling:Blang/> ends up in the list of
policies. Only when it's absolutely critical that an outbound message does not leave the server runtime if some policies have not
been applied to the outbound message (SLA agreement with non policy aware client runtimes for ex) then I'd consider adding such
hints.
>
> I think this gets us over a hump, but I also think it's kind of a cop- out. Why log anything? Why even do the check? What's the
> purpose, if there's no tangible side-effect? Choke up a log with more garbage?
So we can have a default scope be "in-only", but when we want to block the response we can override it.
>
>>
>>
>> While (on the server side) PolicyVerificationInInterceptor is useful in that
>> it ensures that at least one alternative has been met, its out counterpart
>> is of little use. Unless we provide some hints.
>
> Yup. If it's of no use, remove it.
Mostly agreed but see above - we might need it at some time. And it's probably can behave differently on the client side.
>
>
> Not sure what you mean here. Attributes on the wsp:Policy elements, themselves? I'd think there'd be a better way to do that,
> than to add proprietary stuff to standard policy expressions. At any rate, if that's what you mean, then I think we should try
> to avoid it, since it won't be in any way interoperable.
any client runtime should be able to ignore unrecognized attributes. Any policy expression
should have an extension point for any additional attributes. I honestly think it's an issue at all.
If we ever have to deal with 3rd party policies with closed schemas then we can also use your proposed
extension.
We can also suggest to the ws-policy group to consider standardizing on such attribute (as it can be of real help to client
runtimes) in the next maintenance release of the spec, whenever it happens.
Cheers, Sergey
>
>>
>>
>> Without such helper attributes the default (server) behavior should likely
>> be :
>> - PolicyVerificationInInterceptor throws fault if none of the alternatives
>> has been met (as it is now)
>> - PolicyVerificationOutInterceptor logs a FINE message if not all of the
>> expressions in the alternative selected during the inbound invocation has
>> been met.
>
> Why? What possible use is this to the user?
See above please.
>
> I'll reiterate that the API on setting a PolicyAlternativeSelector is too coarse -- it's on the PolicyEngine, which is basically
> in 1-1 correspondence with the Bus. I can think of 4 different ways you'd want to configure one of these guys (client/server
> in/out), and you'd want to be able to configure that on a per-endpoint basis (at least).
And I'd like to stress again that PolicyAlternativeSelector is really not needed at all and it needs to be deprecated.
On the server side any of the many available alternatives can be valid at any moment of time for a given message and once the
effective policy is calculated it should stay fixed for the outbound path. Thus no need for any special alternative algorithms on
the server.
On the client it's none needed either - the client needs to iterate through all the available alternatives and find the best one.
Cheers, Sergey
>
> -Fred
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: More on server response policies
Posted by Fred Dushin <fr...@dushin.net>.
Doh! That was supposed to be [{foo:Bar}, {bling}Blang]
On Oct 9, 2008, at 9:44 AM, Fred Dushin wrote:
> And on the outbound side you'd get [{foo:Bar}, {gnu}Gnat]
Re: More on server response policies
Posted by Fred Dushin <fr...@dushin.net>.
On Oct 8, 2008, at 5:16 PM, Sergey Beryozkin wrote:
> Hi
>
> I agree with what Dan suggested - logging a message in a
> PolicyVerificationOutInterceptor should suffice in most cases. Few
> more
> comments.
>
> I think that asserting a policy on the outbound path makes sense
> only if
> a specification for a given policy expression explicitly states that
> it
> applies to both inbound and outbound paths or to outbound path only.
Suppose you have this config:
<jaxws:endpoint ...>
<jaxws:features>
<cxf:PolicyFeature>
<wsp:Policy><foo:Bar/></wsp:Policy>
</cxf:PolicyFeature>
</jaxws:features>
</jaxws:endpoint>
Does <foo:Bar> apply to the inbound our outbound path? Or both? What
are the semantics here?
> on the
> server inbound path, a union of all policy expressions is selected
> as at any
> moment of time we may need to satisfy requests from clients meeting
> either
> all or one of the available alternatives.
> All required interceptors are
> installed - but the api allows for on-demand interceptors
> installation (for
> ex, based in the in message's content & headers).
Correct. Or more appropriately, based on the actual content of the
policy.
> AFAIK,
> PolicyVerificationInInterceptor would say OK as long as at least one
> of the
> alternatives is fully satisfied. In your example we have a compact
> policy
> expression, so there'no problems if either <foo:Bar/> or <gnu:Gnat/>
> has
> been asserted.
>
> On the outbound path only the alternative which has been selected
> during the
> inbound path should be optionally verified. I don't think any
> alternative
> selection algorithm should apply on the outbound path as we already
> have an
> alternative active in the scope of a given operation.
That assumes the effective policy is the same on the inbound and
outbound sides. I think that's an invalid assumption (as I think you
are saying, as well). Or at least I think we should be able to
discriminate between inbound and outbound policies. I stand corrected
in the case of WSDL, but I think we need a way to make the same
distinction in spring (and however else we retrieve policy).
How about this, for a proposal:
<jaxws:endpoint ...>
<jaxws:features>
<cxf:PolicyFeature>
<wsp:Policy><foo:Bar/></wsp:Policy>
</cxf:PolicyFeature>
<cxf:InboundPolicyFeature> <!-- new type -->
<wsp:Policy><gnu:Gnat/></wsp:Policy>
</cxf:InboundPolicyFeature>
<cxf:OutboundPolicyFeature> <!-- new type -->
<wsp:Policy><bling:Blang/></wsp:Policy>
</cxf:OutboundPolicyFeature>
</jaxws:features>
</jaxws:endpoint>
So on the inbound side you'd get [{foo}Bar, {gnu:Gnat}]
And on the outbound side you'd get [{foo:Bar}, {gnu}Gnat]
> If we have the Ex2
> (above) then this alternative will simply have no any inbound
> behaviors to
> engage (see more below). In Ex1 - it's up to that specific policy's
> out
> interceptors to do any additional outbound work.
>
> Thus, in many cases, like in Ex1, if no explicit out policy
> interceptors
> have been provided then PolicyVerificationOutInterceptor should
> simply log a
> (FINE?) level message as suggested. In fact it's not clear what else
> it can
> do other than do this logging on the server side.
I think this gets us over a hump, but I also think it's kind of a cop-
out. Why log anything? Why even do the check? What's the purpose,
if there's no tangible side-effect? Choke up a log with more garbage?
>
>
> While (on the server side) PolicyVerificationInInterceptor is useful
> in that
> it ensures that at least one alternative has been met, its out
> counterpart
> is of little use. Unless we provide some hints.
Yup. If it's of no use, remove it.
>
>
> We can introduce additional optional hints (in the form of policy
> attributes) to both in/out verifiers that this policy only applies
> to the in
> or out path or to both paths. Thus, in case of Ex2, In verifier
> won't fail
> but Out verifier can log a WARNING (or throw a fault if its phase
> can be
> changed). Likewise, in Ex3, In verifier may throw exception while OUT
> verifier will keep quiet. In case of Ex1, both in/out verifiers may
> report
> failures (through exceptions or logging).
Not sure what you mean here. Attributes on the wsp:Policy elements,
themselves? I'd think there'd be a better way to do that, than to add
proprietary stuff to standard policy expressions. At any rate, if
that's what you mean, then I think we should try to avoid it, since it
won't be in any way interoperable.
>
>
> Without such helper attributes the default (server) behavior should
> likely
> be :
> - PolicyVerificationInInterceptor throws fault if none of the
> alternatives
> has been met (as it is now)
> - PolicyVerificationOutInterceptor logs a FINE message if not all of
> the
> expressions in the alternative selected during the inbound
> invocation has
> been met.
Why? What possible use is this to the user? The more I think of it,
the more I realize the PolicyVerificationOutInterceptor on the
outbound server side is kind of pointless, especially in light of the
current bug in its behavior.
I'll reiterate that the API on setting a PolicyAlternativeSelector is
too coarse -- it's on the PolicyEngine, which is basically in 1-1
correspondence with the Bus. I can think of 4 different ways you'd
want to configure one of these guys (client/server in/out), and you'd
want to be able to configure that on a per-endpoint basis (at least).
-Fred
RE: More on server response policies
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
I agree with what Dan suggested - logging a message in a
PolicyVerificationOutInterceptor should suffice in most cases. Few more
comments.
I think that asserting a policy on the outbound path makes sense only if
a specification for a given policy expression explicitly states that it
applies to both inbound and outbound paths or to outbound path only.
If a given policy expression specifies a behavior which is only engaged on
the inbound path then there's no need to verify that it indeed was engaged
on the outbound path. And vice versa.
Ex1. A policy expression is attached to a wsdl:service/wsdl:port. Only this
policy's interceptors know when to get involved and assert a policy - either
on the inbound only, outbound only or both. This policy applies to all
operations.
Ex2. A policy expression is attached to a
wsdl:binding/wsdl:operation/wsdl:output. When a given operation is executed
this policy assertion is only executed on the outbound path - hence no sence
to verify it on the inbound path.
Ex 3 : policy is attached to wsdl:binding/wsdl:operation/wsdl:input
I'll comment a bit more on these examples later. Now, as Dan said, on the
server inbound path, a union of all policy expressions is selected as at any
moment of time we may need to satisfy requests from clients meeting either
all or one of the available alternatives. All required interceptors are
installed - but the api allows for on-demand interceptors installation (for
ex, based in the in message's content & headers). AFAIK,
PolicyVerificationInInterceptor would say OK as long as at least one of the
alternatives is fully satisfied. In your example we have a compact policy
expression, so there'no problems if either <foo:Bar/> or <gnu:Gnat/> has
been asserted.
On the outbound path only the alternative which has been selected during the
inbound path should be optionally verified. I don't think any alternative
selection algorithm should apply on the outbound path as we already have an
alternative active in the scope of a given operation. If we have the Ex2
(above) then this alternative will simply have no any inbound behaviors to
engage (see more below). In Ex1 - it's up to that specific policy's out
interceptors to do any additional outbound work.
Thus, in many cases, like in Ex1, if no explicit out policy interceptors
have been provided then PolicyVerificationOutInterceptor should simply log a
(FINE?) level message as suggested. In fact it's not clear what else it can
do other than do this logging on the server side.
While (on the server side) PolicyVerificationInInterceptor is useful in that
it ensures that at least one alternative has been met, its out counterpart
is of little use. Unless we provide some hints.
We can introduce additional optional hints (in the form of policy
attributes) to both in/out verifiers that this policy only applies to the in
or out path or to both paths. Thus, in case of Ex2, In verifier won't fail
but Out verifier can log a WARNING (or throw a fault if its phase can be
changed). Likewise, in Ex3, In verifier may throw exception while OUT
verifier will keep quiet. In case of Ex1, both in/out verifiers may report
failures (through exceptions or logging).
Without such helper attributes the default (server) behavior should likely
be :
- PolicyVerificationInInterceptor throws fault if none of the alternatives
has been met (as it is now)
- PolicyVerificationOutInterceptor logs a FINE message if not all of the
expressions in the alternative selected during the inbound invocation has
been met. If we have a policy-aware client runtime on the other end then it
will also do its own verification.
There're some differences in how things are handled in the policy aware
client runtime but we can discuss it in the other thread...
Cheers, Sergey
-----Original Message-----
From: Fred Dushin [mailto:fred@dushin.net]
Sent: 08 October 2008 18:02
To: cxf-dev@incubator.apache.org
Subject: More on server response policies
This is a continuation of the discussion at
http://mail-archives.apache.org/mod_mbox/cxf-dev/200808.mbox/%3c3AAFD5B7-693
A-4FDB-AA50-15696098F98C@dushin.net%3e
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
PolicyVerificationOutInterceptor
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:
<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]
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?
-Fred
[1] https://issues.apache.org/jira/browse/CXF-1849
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland