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 >
