One more note... 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. 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-200401-w > > > > ss- > > > > wssecurity-utility-1.0.xsd">> > > > > > > > > > <wsp:ExactlyOne> > > > > > > > > <wsp:All> > > > > > > > > <sp:AsymmetricBinding> > > > > > > > > <wsp:Policy> > > > > > > > > <sp:InitiatorToken> > > > > > > > > <wsp:Policy> > > > > > > > > <sp:X509Token> > > > > > > > > <wsp:Pol > > > > icy> > > > > > > > > < > > > > s > > > > p > > > > : > > > > W > > > > s > > > > s > > > > X > > > > 5 > > > > 0 > > > > 9 > > > > V > > > > 3 > > > > T > > > > o > > > > k > > > > e > > > > n > > > > 1 > > > > 1 > > > > / > > > > > > > > > > > > > </wsp:Po > > > > licy > > > > > > > > </sp:X509Token> > > > > > > > > </wsp:Policy> > > > > > > > > </sp:InitiatorToken> > > > > <sp:RecipientToken> > > > > > > > > <wsp:Policy> > > > > > > > > <sp:X509Token> > > > > > > > > <wsp:Pol > > > > icy> > > > > > > > > < > > > > s > > > > p > > > > : > > > > W > > > > s > > > > s > > > > X > > > > 5 > > > > 0 > > > > 9 > > > > V > > > > 3 > > > > T > > > > o > > > > k > > > > e > > > > n > > > > 1 > > > > 1 > > > > / > > > > > > > > > > > > > </wsp:Po > > > > licy > > > > > > > > </sp:X509Token> > > > > > > > > </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.org/s > > > > oap > > > > /envelope/"> > > > > > > > > > xmlns:wsse="http://d > > > > ocs. > > > > oasis-open.org/wss/2 > > > > 004/ > > > > 01/oasis-200401-wss- > > > > wsse > > > > curity-secext-1.0.xs > > > > d" > > > > xmlns:wsu="http://do > > > > cs. > > > > oasis-open.org/wss/2 > > > > 004/ > > > > 01/oasis-200401-wss- > > > > wsse > > > > curity-utility-1.0.x > > > > sd">> > > > > > > > > > /soap:Envelope/soap:Header/wsse: > > > > Secu > > > > rity/wsu:Timestamp > > > > > > > > </sp:XPath> > > > > > > > > </sp:SignedElements> > > > > > > > > </wsp:All> > > > > <wsp:All> > > > > > > > > <sp:AsymmetricBinding> > > > > > > > > <wsp:Policy> > > > > > > > > <sp:InitiatorToken> > > > > > > > > <wsp:Policy> > > > > > > > > <sp:X509Token> > > > > > > > > <wsp:Pol > > > > icy> > > > > > > > > < > > > > s > > > > p > > > > : > > > > W > > > > s > > > > s > > > > X > > > > 5 > > > > 0 > > > > 9 > > > > V > > > > 3 > > > > T > > > > o > > > > k > > > > e > > > > n > > > > 1 > > > > 1 > > > > / > > > > > > > > > > > > > </wsp:Po > > > > licy > > > > > > > > </sp:X509Token> > > > > > > > > </wsp:Policy> > > > > > > > > </sp:InitiatorToken> > > > > <sp:RecipientToken> > > > > > > > > <wsp:Policy> > > > > > > > > <sp:X509Token> > > > > > > > > <wsp:Pol > > > > icy> > > > > > > > > < > > > > s > > > > p > > > > : > > > > W > > > > s > > > > s > > > > X > > > > 5 > > > > 0 > > > > 9 > > > > V > > > > 3 > > > > T > > > > o > > > > k > > > > e > > > > n > > > > 1 > > > > 1 > > > > / > > > > > > > > > > > > > </wsp:Po > > > > licy > > > > > > > > </sp:X509Token> > > > > > > > > </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.org/s > > > > oap > > > > /envelope/"> > > > > > > > > > xmlns:wsse="http://d > > > > ocs. > > > > oasis-open.org/wss/2 > > > > 004/ > > > > 01/oasis-200401-wss- > > > > wsse > > > > curity-secext-1.0.xs > > > > d" > > > > xmlns:wsu="http://do > > > > cs. > > > > oasis-open.org/wss/2 > > > > 004/ > > > > 01/oasis-200401-wss- > > > > wsse > > > > curity-utility-1.0.x > > > > sd">> > > > > > > > > > /soap:Envelope/soap:Header/wsse: > > > > 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
