Hi Please see
http://svn.apache.org/viewvc?rev=979764&view=rev I've updated EndpointPolicyImpl to ignore Policies containing no assertions in its updatePolicy() - called currenty from WSPolicyFeature only - I think it is a safe update as opposed to say ignoring empty alternative altogether. I've confirmed a corresponding JBossWS/CXF test with no Spring involved passes with this update Sergey On Mon, Jul 26, 2010 at 9:17 PM, Sergey Beryozkin <[email protected]>wrote: > Hi Dan > > On Mon, Jul 26, 2010 at 7:45 PM, Daniel Kulp <[email protected]> wrote: > >> On Monday 26 July 2010 12:31:31 pm Sergey Beryozkin wrote: >> > > If so, then either of those proposals would definitely change the >> > > behavior of >> > > things, especially on the client side. We kind of ran into this with >> > > the TCK. >> > > >> > > For example, if the addressing policy is "optional", with the current >> > > behavior, the client would not bother sending the addressing headers. >> > > Doing >> > > the addressing stuff slows things down so choosing the "empty" >> > > alternative is >> > > a good thing. >> > > >> > > I wondering if it's possible to allow the empty on outgoing on the >> > > client, but >> > > not on the server. >> > >> > that would probably be a right solution anyway given that as far as the >> > server is concerned it has to prioritize on the non-empty alternative >> > > Either that or we would need a new selector that somehow >> > > would take the incoming policy into affect when calculating the >> outgoing >> > > policy. For example, if the addressing/rm assertions were asserted >> on >> > > incoming side, then chose an alternative that has those. Might be a >> bit >> > > more >> > > complicated to write. Plus, the PolicyEngine would have to updated >> to >> > > allowing pulling the selector off the endpoint/message or similar. >> > > >> > > Another idea might be to have the PolicyEngine have two >> > > AlternativeSelectors, >> > > one for the requestor based requests that would be truely minimal and >> one >> > > for >> > > the other cases that would ignore the minimal. >> > > >> > > For this specific issue I like the idea of restricting the server side >> to >> > >> > choosing a non-empty alternative as it seems the simplest option and yet >> > the correct one too. >> >> >> >> Not really. IMO, the "correct" thing would be to somehow compare the >> possible >> alternatives with the AssertionMap of the incoming request to figure out >> which >> alternative is "most assertable" based on the assertions of the incoming >> request. For example, there COULD be a policy that was use "either >> security >> or RM". To select the correct policy on the outgoing side, you would >> really >> need to look at the incoming assertions. >> >> I don't disagree :-). > My point is that the optionality should not affect the server side, in > other words, if we have an optional RM policy, the server should still be > able to enforce RM if needed. I recall that in the presence of multiple > alternatives the server installs all the interceptors capable of dealing > with the union of all the assertions collected from all the alternatives - > this is not optimal but works :-). I agree the enhancement you're referring > to would be worth spending time upon, but yes it can become very complicated > especially in case of WS-Security policies, and nested ones in particularly. > > > Ignoring an empty alternative on the server side may only have problems > where the client indeed chose to ignore the optional policy - may be this is > what you're referring to, but given that CXF out interceptors are usually > well-behaved :-) (i.e if no RM/WSA in headers were present then RM/WSA out > interceptors won't break the flow), this should probably be safe enough... > > I'll start investigating tomorrow where the empty alternative is coming > from, given that no optional assertions are specified. I suspect it might be > coming from the merge of the empty Policy with a non-empty one. May be there > is a better and simpler fix : if we have an empty policy and a non empty one > at a merge time then we immediately return the assertions taken from a > non-empty one... > > > >> Unfortunately , that starts getting really complex and requires a bunch of >> API >> changes. :-( >> >> agreed :-) > > thanks, Sergey > > >> Dan >> >> >> >> >> > >> > cheers, Sergey >> > >> > > Dan >> > > >> > > On Friday 23 July 2010 1:19:53 pm Sergey Beryozkin wrote: >> > > > Hi >> > > > >> > > > >> > > > after spending quite a bit of time on debugging the issue I think >> I've >> > > > traced where the problem is. >> > > > Given that Policy with two assertions below we eventually get a >> > > >> > > normalized >> > > >> > > > policy, with a single ExactlyOnce and one alternative <All> with >> those >> > > >> > > two >> > > >> > > > simple assertions inside, this is stored with EndpointPolicyImpl. >> > > > >> > > > Next, we get an EffectivePolicyImpl but there we end up with two >> > > > alternative, one is a proper All with WSA & RM, another one is >> empty. >> > > >> > > This >> > > >> > > > is not too bad but PolicyEngine in its supportsAlernative method >> > > > returns "true" for an empty alternative such as <All/> and given >> that >> > > > EffectivePolicyImpl uses a MinimalSelector by default, this empty >> > > > alternative is actually overriding a previous valid one on the basis >> > > > that it's size (0) is less than that of the valid one. >> > > > >> > > > I propose two fixes : >> > > > 1. PolicyEngine.supportsAlernative has to return false for an empty >> > > > alternative. >> > > > 2. MinimalSelector should ignore empty alternatives >> > > > >> > > > Any objections ? >> > > > >> > > > I'm going apply the to the snapshot and experiment if it fixes the >> > > > issue >> > > > >> > > > cheers, Sergey >> > > > >> > > > On Wed, Jul 21, 2010 at 7:50 PM, Daniel Kulp <[email protected]> >> wrote: >> > > > > Sergey, >> > > > > >> > > > > Not sure what would cause this. My suggestion would be to stick a >> > > > > breakpoint >> > > > > at the end of the PolicyIn and Out interceptor's handleMessage >> calls >> > > >> > > and >> > > >> > > > > have >> > > > > it print the interceptor chain. If the RM policy is enabled, it >> > > >> > > SHOULD >> > > >> > > > > have >> > > > > added the RM interceptors. That would at least tell you if >> it's a >> > > > > policy >> > > > > issue or an RM issue. >> > > > > >> > > > > Dan >> > > > > >> > > > > On Wednesday 21 July 2010 12:22:01 pm Sergey Beryozkin wrote: >> > > > > > Hi >> > > > > > >> > > > > > I'm looking into the following issue. >> > > > > > WSDL fragment : >> > > > > > >> > > > > > <wsdl:binding name="SimpleServiceSoapBinding" >> > > >> > > type="tns:SimpleService"> >> > > >> > > > > > <wsp:Policy> >> > > > > > >> > > > > > <wswa:UsingAddressing xmlns:wswa=" >> > > > > > >> > > > > > http://www.w3.org/2006/05/addressing/wsdl"/> >> > > > > > >> > > > > > <wsrmp:RMAssertion xmlns:wsrmp=" >> > > > > > >> > > > > > http://schemas.xmlsoap.org/ws/2005/02/rm/policy"/> >> > > > > > >> > > > > > </wsp:Policy> >> > > > > > >> > > > > > </wsdl:binding> >> > > > > > >> > > > > > When the client invokes a simple echo() operation, the following >> is >> > > > > > happening on the wire : >> > > > > > >> > > > > > 1. WS-RM CreateSequence request is sent and a successful >> response >> > > > > > containing the sequence id/etc is sent back >> > > > > > 2. Actual echo() request is sent with WS-A and WSRM headers >> > > >> > > included >> > > >> > > > > > However the server replies with no WS-A/WS-RM headers and thus a >> > > > > > runtime policy verification fails on the client side. >> > > > > > >> > > > > > Note that no Spring is used in this case. >> > > > > > >> > > > > > Obviously, the client recognizes that the above policy needs to >> be >> > > > > >> > > > > applied >> > > > > >> > > > > > and the server initially responds well to a WS-RM only request. >> It >> > > > > >> > > > > appears >> > > > > >> > > > > > though it is happening due to WS-RM interceptors installed by >> > > > > > default on the server side. >> > > > > > >> > > > > > Question is : is it a bug that the server does not apply a >> policy >> > > > > > to the outbound message (it is probably not even enforcing it on >> > > > > > the inbound message too) in a WSDL-first with no Spring case ? >> > > > > > Also, why the client does recognize the policy requirement but >> the >> > > > > > server does not ? >> > > > > > >> > > > > > it's been awhile since I looked into the Ws-Policy code so some >> > > >> > > initial >> > > >> > > > > > feedback will help :-) >> > > > > > >> > > > > > thanks, Sergey >> > > > > >> > > > > -- >> > > > > Daniel Kulp >> > > > > [email protected] >> > > > > http://dankulp.com/blog >> > > >> > > -- >> > > Daniel Kulp >> > > [email protected] >> > > http://dankulp.com/blog >> >> -- >> Daniel Kulp >> [email protected] >> http://dankulp.com/blog >> > >
