I have updated the jira with a new patch and test case
On Wed, Oct 24, 2012 at 8:35 AM, Jason Pell <[email protected]> wrote: > 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 >> >
