On Wednesday, October 05, 2011 3:24:14 PM Daniel Kulp wrote: > One more note...
OK.... a little bit more info.... > I do have a fix for this that I'm testing. However, it involves some minor > API changes. Thus, it's not really something I can do for 2.4.x. I'll go > ahead and fix it for 2.5 and add information in the migration guide. > > Basically, in the PolicyInVerificationInterceptor where we validate that the > incoming message actually met the requirements of one of the alternatives, > we need to store a list of the alternatives that it actually matched. > That's not a huge deal except the signature of the > AssertionInfoMap.checkAlternatives had to change to return the alternatives > that did match instead of void. > > The main changes are to the AlternativeSelector interface. It now has an > additional parameter of the list of alternatives from the request (null > otherwise) that it also needs to consider. To call that, I also need to > change the PolicyEngine.getEffectiveServerResponsePolicy method to pass in > the alternatives. Both of those interfaces are public API's and thus not > something I can really change for 2.4.4. I updated the 3 AlternativeSelector we have (First, Minimal, Max) to kind of do a "dumb" isCompatible with the incoming request for each potential alternative. It really is dumb in that it just checks to see if the response alternative is equal to or a superset of the valid request alternatives. That should cover MOST cases, but there are cases where that won't trigger. For example, if the incoming message needs to have specific things encrypted and the response just needs sigs or something. If someone want to come up with something smarter, great. :-) However, with the new API's at least the user can inject a smarter algorithm in there that would better meet their needs. Dan > > In anycase, if I get the tests passing (I hate mocks), I should have this > all committed to trunk fairly soon. If you could give it a spin, that > would be great. > > Dan > > On Wednesday, October 05, 2011 2:00:20 PM Daniel Kulp wrote: > > On Tuesday, October 04, 2011 1:57:32 PM Marc Giger wrote: > > > On Tue, 04 Oct 2011 10:16:14 +0200 > > > > > > Alessio Soldano <[email protected]> wrote: > > > > You can configure the > > > > org.apache.cxf.ws.policy.AlternativeSelector > > > > [1] > > > > to be used in the Bus, either through the spring configuration > > > > or > > > > with > > > > something like: > > > > > > > > bus.getExtension(PolicyEngine.class).setAlternativeSelector(new > > > > MaximalAlternativeSelector()); > > > > > > > > The default selector is the MinimalAlternativeSelector. > > > > > > Yes, I'm aware of this. But the alternative will be selected without > > > looking into the actual request and selecting the appropriate > > > policy. > > > > > > Simple use case: > > > > > > Two alternatives, one which enforces a <sp:WssX509V3Token10/> > > > the other one enforces a <sp:WssX509Pkcs7Token10/> > > > > > > so that both token types are allowed but no other kind of Token. > > > Or an use case where both an asym- and -symmetric binding is allowed > > > for a particular operation with specific keys? Or... > > > > > > How can > > > it be done with CXF? > > > > As an FYI: this is more or less logged as: > > > > https://issues.apache.org/jira/browse/CXF-3365 > > > > Different description, but pretty much the same underlying cause. > > > > Dan > > > > > Thanks > > > > > > Marc > > > > > > > Cheers > > > > Alessio > > > > > > > > [1] http://cxf.apache.org/docs/wspconfiguration.html > > > > > > > > On 10/04/2011 08:44 AM, Marc Giger wrote: > > > > > Hi > > > > > > > > > > Yesterday I tried to setup CXF with WS-Policy via > > > > > annotations. > > > > > The > > > > > following Policy with two alternatives was applied: > > > > > > > > > > <wsp:Policy > > > > > xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy > > > > > /200 > > > > > 702 > > > > > " xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"; > > > > > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-2004 > > > > > 01-w > > > > > ss- > > > > > wssecurity-utility-1.0.xsd">> > > > > > > > > > > > <wsp:ExactlyOne> > > > > > > > > > > <wsp:All> > > > > > > > > > > <sp:AsymmetricBinding> > > > > > > > > > > <wsp:Policy> > > > > > > > > > > <sp:InitiatorToken> > > > > > > > > > > <wsp:Policy> > > > > > > > > > > <sp:X509Toke > > > > > n> > > > > > > > > > > <wsp > > > > > :Pol > > > > > icy> > > > > > > > > > > < > > > > > s > > > > > p > > > > > > > > > > W > > > > > s > > > > > s > > > > > X > > > > > 5 > > > > > 0 > > > > > 9 > > > > > V > > > > > 3 > > > > > T > > > > > o > > > > > k > > > > > e > > > > > n > > > > > 1 > > > > > 1 > > > > > / > > > > > > > > > > </ws > > > > > p:Po > > > > > licy > > > > > > > > > > </sp:X509Tok > > > > > en> > > > > > > > > > > </wsp:Policy> > > > > > > > > > > </sp:InitiatorToken> > > > > > <sp:RecipientToken> > > > > > > > > > > <wsp:Policy> > > > > > > > > > > <sp:X509Toke > > > > > n> > > > > > > > > > > <wsp > > > > > :Pol > > > > > icy> > > > > > > > > > > < > > > > > s > > > > > p > > > > > > > > > > W > > > > > s > > > > > s > > > > > X > > > > > 5 > > > > > 0 > > > > > 9 > > > > > V > > > > > 3 > > > > > T > > > > > o > > > > > k > > > > > e > > > > > n > > > > > 1 > > > > > 1 > > > > > / > > > > > > > > > > </ws > > > > > p:Po > > > > > licy > > > > > > > > > > </sp:X509Tok > > > > > en> > > > > > > > > > > </wsp:Policy> > > > > > > > > > > </sp:RecipientToken> > > > > > <sp:IncludeTimestamp/> > > > > > > > > > > </wsp:Policy> > > > > > > > > > > </sp:AsymmetricBinding> > > > > > <sp:SignedParts> > > > > > > > > > > <sp:Body/> > > > > > > > > > > </sp:SignedParts> > > > > > <sp:SignedElements> > > > > > > > > > > <!-- The IncludeTimestamp says that > > > > > the > > > > > Timestamp must be integrity > > > > > protected > > > > > either by> > > > > > > > > > > > transport or by message level > > > > > security. We > > > > > enforce message level protection > > > > > here: > > > > > -->> > > > > > > > > > > > <sp:XPath > > > > > xmlns:soap="http://schemas.xmlsoap.o > > > > > rg/s > > > > > oap > > > > > /envelope/"> > > > > > > > > > > > xmlns:wsse="http > > > > > ://d > > > > > ocs. > > > > > oasis-open.org/w > > > > > ss/2 > > > > > 004/ > > > > > 01/oasis-200401- > > > > > wss- > > > > > wsse > > > > > curity-secext-1. > > > > > 0.xs > > > > > d" > > > > > xmlns:wsu="http: > > > > > //do > > > > > cs. > > > > > oasis-open.org/w > > > > > ss/2 > > > > > 004/ > > > > > 01/oasis-200401- > > > > > wss- > > > > > wsse > > > > > curity-utility-1 > > > > > .0.x > > > > > sd">> > > > > > > > > > > > /soap:Envelope/soap:Header/w > > > > > sse: > > > > > Secu > > > > > rity/wsu:Timestamp > > > > > > > > > > </sp:XPath> > > > > > > > > > > </sp:SignedElements> > > > > > > > > > > </wsp:All> > > > > > <wsp:All> > > > > > > > > > > <sp:AsymmetricBinding> > > > > > > > > > > <wsp:Policy> > > > > > > > > > > <sp:InitiatorToken> > > > > > > > > > > <wsp:Policy> > > > > > > > > > > <sp:X509Toke > > > > > n> > > > > > > > > > > <wsp > > > > > :Pol > > > > > icy> > > > > > > > > > > < > > > > > s > > > > > p > > > > > > > > > > W > > > > > s > > > > > s > > > > > X > > > > > 5 > > > > > 0 > > > > > 9 > > > > > V > > > > > 3 > > > > > T > > > > > o > > > > > k > > > > > e > > > > > n > > > > > 1 > > > > > 1 > > > > > / > > > > > > > > > > </ws > > > > > p:Po > > > > > licy > > > > > > > > > > </sp:X509Tok > > > > > en> > > > > > > > > > > </wsp:Policy> > > > > > > > > > > </sp:InitiatorToken> > > > > > <sp:RecipientToken> > > > > > > > > > > <wsp:Policy> > > > > > > > > > > <sp:X509Toke > > > > > n> > > > > > > > > > > <wsp > > > > > :Pol > > > > > icy> > > > > > > > > > > < > > > > > s > > > > > p > > > > > > > > > > W > > > > > s > > > > > s > > > > > X > > > > > 5 > > > > > 0 > > > > > 9 > > > > > V > > > > > 3 > > > > > T > > > > > o > > > > > k > > > > > e > > > > > n > > > > > 1 > > > > > 1 > > > > > / > > > > > > > > > > </ws > > > > > p:Po > > > > > licy > > > > > > > > > > </sp:X509Tok > > > > > en> > > > > > > > > > > </wsp:Policy> > > > > > > > > > > </sp:RecipientToken> > > > > > <sp:IncludeTimestamp/> > > > > > > > > > > </wsp:Policy> > > > > > > > > > > </sp:AsymmetricBinding> > > > > > <sp:SignedParts> > > > > > > > > > > <sp:Body/> > > > > > > > > > > </sp:SignedParts> > > > > > <sp:SignedElements> > > > > > > > > > > <!-- The IncludeTimestamp says that > > > > > the > > > > > Timestamp must be integrity > > > > > protected > > > > > either by> > > > > > > > > > > > transport or by message level > > > > > security. We > > > > > enforce message level protection > > > > > here: > > > > > -->> > > > > > > > > > > > <sp:XPath > > > > > xmlns:soap="http://schemas.xmlsoap.o > > > > > rg/s > > > > > oap > > > > > /envelope/"> > > > > > > > > > > > xmlns:wsse="http > > > > > ://d > > > > > ocs. > > > > > oasis-open.org/w > > > > > ss/2 > > > > > 004/ > > > > > 01/oasis-200401- > > > > > wss- > > > > > wsse > > > > > curity-secext-1. > > > > > 0.xs > > > > > d" > > > > > xmlns:wsu="http: > > > > > //do > > > > > cs. > > > > > oasis-open.org/w > > > > > ss/2 > > > > > 004/ > > > > > 01/oasis-200401- > > > > > wss- > > > > > wsse > > > > > curity-utility-1 > > > > > .0.x > > > > > sd">> > > > > > > > > > > > /soap:Envelope/soap:Header/w > > > > > sse: > > > > > Secu > > > > > rity/wsu:Timestamp > > > > > > > > > > </sp:XPath> > > > > > > > > > > </sp:SignedElements> > > > > > <sp:EncryptedParts> > > > > > > > > > > <sp:Body/> > > > > > > > > > > </sp:EncryptedParts> > > > > > > > > > > </wsp:All> > > > > > > > > > > </wsp:ExactlyOne> > > > > > > > > > > </wsp:Policy> > > > > > > > > > > The expectation from my sided was, that one of the > > > > > alternatives > > > > > is > > > > > choosen based on the actual request. But CXF chooses per > > > > > default > > > > > the alternative with the lowest number of assertions without > > > > > taking > > > > > the actual request into account. Then this selected > > > > > alternative > > > > > (effective Policy) is always used for all subsequent > > > > > requests. > > > > > > > > > > Is this correct, or did I miss something? Is there a switch > > > > > to > > > > > change this behavior? > > > > > > > > > > Thanks > > > > > > > > > > Marc -- Daniel Kulp [email protected] http://dankulp.com/blog Talend - http://www.talend.com
