Hi
dkulp wrote:
Then per the policy spec, ALL of the policy elements (that aren't
wsp:Optional=true) must be applied. The policy spec doesn't say what the
namespaces and such of the individual policy assertion that would go into
the
All are. Other specs (and company proprietary things) dictate those.
OK, I see--policy elements that are of a namespace that the processor does
not understand are *not* to be ignored, but an error given instead, unless
wsp:Optional=true is set.
There's one more wrinkle in the WS-Policy spec, it's an attribute called
'ignorable'.
Note, wsp:Optional is a syntactic sugar, just so that policy authors could
avoid manually typing various alternatives.
At runtime it always has to expanf into multiple alternatives on the server side (as I noted in the prev email) and it has no
meaning for the client choosing between multiple alternatives. The client just chooses al alternative where it has to meet all the
assertions, wsp:optional must've gone by that time, as far as the client choosing an alternative is concerned.
So there's also wsp:ignorable. It means "ignorable for the purpose of the policy intersection". Policy intersection is about a
client stating in advance what policies have to be met and then intersecting them against those found in a retrieved service
contract doc. Ex :
Client expects (shortcut for a policy with a single alternative) :
<wsp:Policy>
<A/>
</wsp:Policy>
Server says :
<wsp:Policy>
<ExactlyOnce>
<All><B/></All>
</ExactlyOnce>
</wsp:Policy>
Even if the client understands B the intersection fails.
Ex :
Server says :
<wsp:Policy>
<ExactlyOnce>
<All><A><B/></All>
</ExactlyOnce>
</wsp:Policy>
intersection fails again as the client expects B only.
Ex.
Server says :
<wsp:Policy>
<ExactlyOnce>
<All><A><B/></All>
<All><A></All>
</ExactlyOnce>
</wsp:Policy>
Client succeeds in choosing the second alternative
and finally :
Server says :
<wsp:Policy>
<ExactlyOnce>
<All><A><B wsp:ignorable="true"/></All>
</ExactlyOnce>
</wsp:Policy>
intersection succeeds even if the client does not understand 'B'.
Canonical example : 'B' means that service supports cxf:HA. If the client does not know what HA means then it will still be able to
consume that service. Thus it's safe to consume the alternative. The client which knows about cxf:HA will load some client side
plugins.
Hopefully we'll support the policy intersection too at some stage...
cheers, Sergey
I'll plug away a little bit more at this, and if I can't get it working will
supply a JIRA with a test case.
Thanks,
Glen
--
View this message in context:
http://www.nabble.com/Debugging-%22None-of-the-policy-alternatives-can-be-satisfied%22-WS-SecPol-error-tp24384805p24392744.html
Sent from the cxf-user mailing list archive at Nabble.com.
