Yep Colm said the same thing in the jira. And i would have quickly reached the same conclusion when i went to test my actual scenario which is one of:
username and password token with tls but no client cert Username no password and tls with client cert My initial patch would have caused an exception to be thrown no matter what! On Oct 24, 2012 8:16 AM, "Daniel Kulp" <[email protected]> wrote: > > On Oct 23, 2012, at 3:21 AM, Jason Pell <[email protected]> wrote: > > > Hi, > > > > I have added further analysis to the jira including the idea of > > throwing a policy exception in HttpsTokenInInterceptor, rather than > > change > > TransportBindingPolicyValidator. The HttpsTokenOutInterceptor already > > does this. > > > > Not sure what the intention was originally. I have started looking at > > the svn log to try and get an understanding of the change history > > of these classes, not much to add as yet. > > > > Would really appreciate the developer known as 'coheigea' having a > > look at this, as you are the author of this part of the code. > > That would be Colm. > > I'm not sure if throwing the exception there is the right thing. You > could have a policy that is a "ExactlyOne" with a transportBinding with a > HttpsToken and another with some other setup. In that case, the exception > would be thrown and the other alternative could not really be checked. On > the incoming side on the server, we tend to just assert tokens that pass > and allow the policy mechanism at the end figure out if one of the policies > was completely asserted. > > Most likely, the lines in the TransportBindingPolicyValidator.java > shouldn't be there. > > Dan > > > > > > > > Thanks > > Jason > > > > On Tue, Oct 23, 2012 at 1:42 PM, Jason Pell <[email protected]> wrote: > >> oops - sorry I meant that the test case was attached to the jira to > >> illustrate the bug. > >> > >> On Tue, Oct 23, 2012 at 1:41 PM, Jason Pell <[email protected]> wrote: > >>> patch attached > >>> > >>> On Tue, Oct 23, 2012 at 1:33 PM, Jason Pell <[email protected]> > wrote: > >>>> https://issues.apache.org/jira/browse/CXF-4595 > >>>> > >>>> I will attach a test case to prove the issue asap > >>>> > >>>> > >>>> > >>>> On Tue, Oct 23, 2012 at 1:13 PM, Jason Pell <[email protected]> > wrote: > >>>>> My namespaces look like: > >>>>> > >>>>> xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"; > >>>>> xmlns:wsu=" > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd > " > >>>>> xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"; > >>>>> > >>>>> > >>>>> > >>>>> On Tue, Oct 23, 2012 at 1:12 PM, Jason Pell <[email protected]> > wrote: > >>>>>> Hi, > >>>>>> > >>>>>> I am debugging 2.7.1 trunk to try and figure out why my > >>>>>> RequireClientCertificate="true" appears to be ignored. > >>>>>> > >>>>>> My policy looks like: > >>>>>> > >>>>>> <wsp:Policy wsu:Id="SslWithUsernamePasswordToken"> > >>>>>> <wsp:ExactlyOne> > >>>>>> <wsp:All> > >>>>>> <sp:TransportBinding> > >>>>>> <wsp:Policy> > >>>>>> <sp:TransportToken> > >>>>>> <wsp:Policy> > >>>>>> > <sp:HttpsToken RequireClientCertificate="true" /> > >>>>>> </wsp:Policy> > >>>>>> </sp:TransportToken> > >>>>>> <sp:AlgorithmSuite> > >>>>>> <wsp:Policy> > >>>>>> > <sp:Basic256 /> > >>>>>> </wsp:Policy> > >>>>>> </sp:AlgorithmSuite> > >>>>>> > >>>>>> <sp:IncludeTimestamp > /> > >>>>>> </wsp:Policy> > >>>>>> </sp:TransportBinding> > >>>>>> > >>>>>> </wsp:All> > >>>>>> </wsp:ExactlyOne> > >>>>>> </wsp:Policy> > >>>>>> > >>>>>> I can see in the HttpsTokenInInterceptor that because there is no > >>>>>> client token, the AssertionInfo is not being asserted, which I > assumes > >>>>>> means > >>>>>> it should raise a policy error. > >>>>>> > >>>>>> However in the TransportBindingPolicyValidator it overrides this and > >>>>>> actually sets the AssertionInfo that was not asserted to true! > >>>>>> > >>>>>> If I disable the second line, I get an exception because no client > >>>>>> certificate is present. > >>>>>> > >>>>>> Index: > src/main/java/org/apache/cxf/ws/security/wss4j/policyvalidators/TransportBindingPolicyValidator.java > >>>>>> =================================================================== > >>>>>> --- > src/main/java/org/apache/cxf/ws/security/wss4j/policyvalidators/TransportBindingPolicyValidator.java > (revision > >>>>>> 1400641) > >>>>>> +++ > src/main/java/org/apache/cxf/ws/security/wss4j/policyvalidators/TransportBindingPolicyValidator.java > (working > >>>>>> copy) > >>>>>> @@ -68,7 +68,7 @@ > >>>>>> // HttpsToken is validated by the > HttpsTokenInterceptorProvider > >>>>>> if (binding.getTransportToken() != null) { > >>>>>> assertPolicy(aim, binding.getTransportToken()); > >>>>>> - assertPolicy(aim, > binding.getTransportToken().getToken()); > >>>>>> + // assertPolicy(aim, > binding.getTransportToken().getToken()); > >>>>>> } > >>>>>> > >>>>>> // Check the AlgorithmSuite > >>>>>> > >>>>>> This is obviously not a complete patch, but it does I hope prove > that > >>>>>> there is an issue with client cert validation. I shall open up a > jira > >>>>>> for this, but I don't feel confident enough to try and > >>>>>> provide a patch without guidance as this is definately an area I am > >>>>>> not very familiar with. > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > >
