You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Jason Pell <ja...@pellcorp.com> on 2012/10/23 09:21:30 UTC
Re: RequireClientCertificate is not validated
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.
Thanks
Jason
On Tue, Oct 23, 2012 at 1:42 PM, Jason Pell <ja...@pellcorp.com> 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 <ja...@pellcorp.com> wrote:
>> patch attached
>>
>> On Tue, Oct 23, 2012 at 1:33 PM, Jason Pell <ja...@pellcorp.com> 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 <ja...@pellcorp.com> 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 <ja...@pellcorp.com> 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.
Re: RequireClientCertificate is not validated
Posted by Jason Pell <ja...@pellcorp.com>.
I have updated the jira with a new patch and test case
On Wed, Oct 24, 2012 at 8:35 AM, Jason Pell <ja...@pellcorp.com> 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" <dk...@apache.org> wrote:
>>
>>
>> On Oct 23, 2012, at 3:21 AM, Jason Pell <ja...@pellcorp.com> 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 <ja...@pellcorp.com> 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 <ja...@pellcorp.com> wrote:
>> >>> patch attached
>> >>>
>> >>> On Tue, Oct 23, 2012 at 1:33 PM, Jason Pell <ja...@pellcorp.com>
>> >>> 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 <ja...@pellcorp.com>
>> >>>> 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 <ja...@pellcorp.com>
>> >>>>> 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
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>
Re: RequireClientCertificate is not validated
Posted by Jason Pell <ja...@pellcorp.com>.
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" <dk...@apache.org> wrote:
>
> On Oct 23, 2012, at 3:21 AM, Jason Pell <ja...@pellcorp.com> 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 <ja...@pellcorp.com> 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 <ja...@pellcorp.com> wrote:
> >>> patch attached
> >>>
> >>> On Tue, Oct 23, 2012 at 1:33 PM, Jason Pell <ja...@pellcorp.com>
> 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 <ja...@pellcorp.com>
> 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 <ja...@pellcorp.com>
> 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
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
Re: RequireClientCertificate is not validated
Posted by Daniel Kulp <dk...@apache.org>.
On Oct 23, 2012, at 3:21 AM, Jason Pell <ja...@pellcorp.com> 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 <ja...@pellcorp.com> 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 <ja...@pellcorp.com> wrote:
>>> patch attached
>>>
>>> On Tue, Oct 23, 2012 at 1:33 PM, Jason Pell <ja...@pellcorp.com> 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 <ja...@pellcorp.com> 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 <ja...@pellcorp.com> 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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com