You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Jason Pell <ja...@pellcorp.com> on 2014/10/16 15:02:37 UTC
Upgrading to cxf 2.7.13 - SAMLTokenPrincipal no longer being
registered as a SecurityContext
All I get now is the X500Principal of the https token.
My policy is below. I am relying on the RequireClientCertificate to have
the saml token "signed" and thus I would have expected it to be present in
the security context. I am at a loss as to why something like this could
change between point releases.
<!-- 2.3.1.1 (WSS1.0) SAML1.1 Assertion (Bearer) -->
<wsp:Policy wsu:Id="TLSBearerPolicy"
xmlns:wsp="http://www.w3.org/ns/ws-policy"
xmlns:wsu="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsp:All>
<sp:TransportBinding>
<wsp:Policy>
<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken>
<wsp:Policy>
<sp:RequireClientCertificate/>
</wsp:Policy>
</sp:HttpsToken>
</wsp:Policy>
</sp:TransportToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic128 />
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict />
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp />
</wsp:Policy>
</sp:TransportBinding>
<sp:SignedSupportingTokens>
<wsp:Policy>
<sp:SamlToken sp:IncludeToken="
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
">
<wsp:Policy>
<sp:WssSamlV11Token11/>
</wsp:Policy>
</sp:SamlToken>
</wsp:Policy>
</sp:SignedSupportingTokens>
</wsp:All>
</wsp:Policy>
Re: Upgrading to cxf 2.7.13 - SAMLTokenPrincipal no longer being
registered as a SecurityContext
Posted by Jason Pell <ja...@pellcorp.com>.
I have merged a fix for 2.7 3.0 and master
On 17/10/2014 7:46 AM, "Jason Pell" <ja...@pellcorp.com> wrote:
> https://issues.apache.org/jira/browse/CXF-6054
>
> On Fri, Oct 17, 2014 at 1:11 AM, Jason Pell <ja...@pellcorp.com> wrote:
>
>> I will create jira and a patch to support the property.
>> On 17/10/2014 12:58 AM, "Jason Pell" <ja...@pellcorp.com> wrote:
>>
>>> I don't think I can easily override the wss4j interceptor as I am using
>>> WS policy so the interceptors are added for me.
>>>
>>> Am eager to understand the security issues with client certs. When will
>>> these be publicized
>>> On 17/10/2014 12:56 AM, "Jason Pell" <ja...@pellcorp.com> wrote:
>>>
>>>> I would be interested to understand why it is a security issue when the
>>>> client TLS establishes the trust relationship.
>>>>
>>>> I had just finished adding basic saml support to our product and now
>>>> with the upgrade I am back to square one.
>>>>
>>>> From the docs I have read using TLS with client auth instead of signed
>>>> is a good alternative and performs better.
>>>> On 17/10/2014 12:22 AM, "Colm O hEigeartaigh" <co...@apache.org>
>>>> wrote:
>>>>
>>>>> There have been some considerable changes to SAML processing based on
>>>>> some
>>>>> security issues that will become public soon. The security context is
>>>>> not
>>>>> populated via unsigned SAML tokens any more (even if they are received
>>>>> over
>>>>> TLS with client authentication). If you want to support this you will
>>>>> have
>>>>> to override the doResults method of the WSS4JInInterceptor. If you
>>>>> really
>>>>> want to though, we could introduce a new JAX-WS property (defaulting to
>>>>> false) to all this behaviour.
>>>>>
>>>>> Colm.
>>>>>
>>>>> On Thu, Oct 16, 2014 at 2:02 PM, Jason Pell <ja...@pellcorp.com>
>>>>> wrote:
>>>>>
>>>>> > All I get now is the X500Principal of the https token.
>>>>> >
>>>>> > My policy is below. I am relying on the RequireClientCertificate to
>>>>> have
>>>>> > the saml token "signed" and thus I would have expected it to be
>>>>> present in
>>>>> > the security context. I am at a loss as to why something like this
>>>>> could
>>>>> > change between point releases.
>>>>> >
>>>>> >
>>>>> > <!-- 2.3.1.1 (WSS1.0) SAML1.1 Assertion (Bearer) -->
>>>>> > <wsp:Policy wsu:Id="TLSBearerPolicy"
>>>>> > xmlns:wsp="http://www.w3.org/ns/ws-policy"
>>>>> > xmlns:wsu="
>>>>> >
>>>>> >
>>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>>>> > "
>>>>> > xmlns:sp="
>>>>> > http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
>>>>> >
>>>>> > <wsp:All>
>>>>> > <sp:TransportBinding>
>>>>> > <wsp:Policy>
>>>>> > <sp:TransportToken>
>>>>> > <wsp:Policy>
>>>>> > <sp:HttpsToken>
>>>>> > <wsp:Policy>
>>>>> >
>>>>> <sp:RequireClientCertificate/>
>>>>> > </wsp:Policy>
>>>>> > </sp:HttpsToken>
>>>>> > </wsp:Policy>
>>>>> > </sp:TransportToken>
>>>>> > <sp:AlgorithmSuite>
>>>>> > <wsp:Policy>
>>>>> > <sp:Basic128 />
>>>>> > </wsp:Policy>
>>>>> > </sp:AlgorithmSuite>
>>>>> > <sp:Layout>
>>>>> > <wsp:Policy>
>>>>> > <sp:Strict />
>>>>> > </wsp:Policy>
>>>>> > </sp:Layout>
>>>>> > <sp:IncludeTimestamp />
>>>>> > </wsp:Policy>
>>>>> > </sp:TransportBinding>
>>>>> >
>>>>> > <sp:SignedSupportingTokens>
>>>>> > <wsp:Policy>
>>>>> > <sp:SamlToken sp:IncludeToken="
>>>>> >
>>>>> >
>>>>> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
>>>>> > ">
>>>>> > <wsp:Policy>
>>>>> > <sp:WssSamlV11Token11/>
>>>>> > </wsp:Policy>
>>>>> > </sp:SamlToken>
>>>>> > </wsp:Policy>
>>>>> > </sp:SignedSupportingTokens>
>>>>> > </wsp:All>
>>>>> > </wsp:Policy>
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Colm O hEigeartaigh
>>>>>
>>>>> Talend Community Coder
>>>>> http://coders.talend.com
>>>>>
>>>>
>
Re: Upgrading to cxf 2.7.13 - SAMLTokenPrincipal no longer being
registered as a SecurityContext
Posted by Jason Pell <ja...@pellcorp.com>.
https://issues.apache.org/jira/browse/CXF-6054
On Fri, Oct 17, 2014 at 1:11 AM, Jason Pell <ja...@pellcorp.com> wrote:
> I will create jira and a patch to support the property.
> On 17/10/2014 12:58 AM, "Jason Pell" <ja...@pellcorp.com> wrote:
>
>> I don't think I can easily override the wss4j interceptor as I am using
>> WS policy so the interceptors are added for me.
>>
>> Am eager to understand the security issues with client certs. When will
>> these be publicized
>> On 17/10/2014 12:56 AM, "Jason Pell" <ja...@pellcorp.com> wrote:
>>
>>> I would be interested to understand why it is a security issue when the
>>> client TLS establishes the trust relationship.
>>>
>>> I had just finished adding basic saml support to our product and now
>>> with the upgrade I am back to square one.
>>>
>>> From the docs I have read using TLS with client auth instead of signed
>>> is a good alternative and performs better.
>>> On 17/10/2014 12:22 AM, "Colm O hEigeartaigh" <co...@apache.org>
>>> wrote:
>>>
>>>> There have been some considerable changes to SAML processing based on
>>>> some
>>>> security issues that will become public soon. The security context is
>>>> not
>>>> populated via unsigned SAML tokens any more (even if they are received
>>>> over
>>>> TLS with client authentication). If you want to support this you will
>>>> have
>>>> to override the doResults method of the WSS4JInInterceptor. If you
>>>> really
>>>> want to though, we could introduce a new JAX-WS property (defaulting to
>>>> false) to all this behaviour.
>>>>
>>>> Colm.
>>>>
>>>> On Thu, Oct 16, 2014 at 2:02 PM, Jason Pell <ja...@pellcorp.com> wrote:
>>>>
>>>> > All I get now is the X500Principal of the https token.
>>>> >
>>>> > My policy is below. I am relying on the RequireClientCertificate to
>>>> have
>>>> > the saml token "signed" and thus I would have expected it to be
>>>> present in
>>>> > the security context. I am at a loss as to why something like this
>>>> could
>>>> > change between point releases.
>>>> >
>>>> >
>>>> > <!-- 2.3.1.1 (WSS1.0) SAML1.1 Assertion (Bearer) -->
>>>> > <wsp:Policy wsu:Id="TLSBearerPolicy"
>>>> > xmlns:wsp="http://www.w3.org/ns/ws-policy"
>>>> > xmlns:wsu="
>>>> >
>>>> >
>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>>> > "
>>>> > xmlns:sp="
>>>> > http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
>>>> >
>>>> > <wsp:All>
>>>> > <sp:TransportBinding>
>>>> > <wsp:Policy>
>>>> > <sp:TransportToken>
>>>> > <wsp:Policy>
>>>> > <sp:HttpsToken>
>>>> > <wsp:Policy>
>>>> > <sp:RequireClientCertificate/>
>>>> > </wsp:Policy>
>>>> > </sp:HttpsToken>
>>>> > </wsp:Policy>
>>>> > </sp:TransportToken>
>>>> > <sp:AlgorithmSuite>
>>>> > <wsp:Policy>
>>>> > <sp:Basic128 />
>>>> > </wsp:Policy>
>>>> > </sp:AlgorithmSuite>
>>>> > <sp:Layout>
>>>> > <wsp:Policy>
>>>> > <sp:Strict />
>>>> > </wsp:Policy>
>>>> > </sp:Layout>
>>>> > <sp:IncludeTimestamp />
>>>> > </wsp:Policy>
>>>> > </sp:TransportBinding>
>>>> >
>>>> > <sp:SignedSupportingTokens>
>>>> > <wsp:Policy>
>>>> > <sp:SamlToken sp:IncludeToken="
>>>> >
>>>> >
>>>> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
>>>> > ">
>>>> > <wsp:Policy>
>>>> > <sp:WssSamlV11Token11/>
>>>> > </wsp:Policy>
>>>> > </sp:SamlToken>
>>>> > </wsp:Policy>
>>>> > </sp:SignedSupportingTokens>
>>>> > </wsp:All>
>>>> > </wsp:Policy>
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Colm O hEigeartaigh
>>>>
>>>> Talend Community Coder
>>>> http://coders.talend.com
>>>>
>>>
Re: Upgrading to cxf 2.7.13 - SAMLTokenPrincipal no longer being
registered as a SecurityContext
Posted by Jason Pell <ja...@pellcorp.com>.
I will create jira and a patch to support the property.
On 17/10/2014 12:58 AM, "Jason Pell" <ja...@pellcorp.com> wrote:
> I don't think I can easily override the wss4j interceptor as I am using WS
> policy so the interceptors are added for me.
>
> Am eager to understand the security issues with client certs. When will
> these be publicized
> On 17/10/2014 12:56 AM, "Jason Pell" <ja...@pellcorp.com> wrote:
>
>> I would be interested to understand why it is a security issue when the
>> client TLS establishes the trust relationship.
>>
>> I had just finished adding basic saml support to our product and now with
>> the upgrade I am back to square one.
>>
>> From the docs I have read using TLS with client auth instead of signed is
>> a good alternative and performs better.
>> On 17/10/2014 12:22 AM, "Colm O hEigeartaigh" <co...@apache.org>
>> wrote:
>>
>>> There have been some considerable changes to SAML processing based on
>>> some
>>> security issues that will become public soon. The security context is not
>>> populated via unsigned SAML tokens any more (even if they are received
>>> over
>>> TLS with client authentication). If you want to support this you will
>>> have
>>> to override the doResults method of the WSS4JInInterceptor. If you really
>>> want to though, we could introduce a new JAX-WS property (defaulting to
>>> false) to all this behaviour.
>>>
>>> Colm.
>>>
>>> On Thu, Oct 16, 2014 at 2:02 PM, Jason Pell <ja...@pellcorp.com> wrote:
>>>
>>> > All I get now is the X500Principal of the https token.
>>> >
>>> > My policy is below. I am relying on the RequireClientCertificate to
>>> have
>>> > the saml token "signed" and thus I would have expected it to be
>>> present in
>>> > the security context. I am at a loss as to why something like this
>>> could
>>> > change between point releases.
>>> >
>>> >
>>> > <!-- 2.3.1.1 (WSS1.0) SAML1.1 Assertion (Bearer) -->
>>> > <wsp:Policy wsu:Id="TLSBearerPolicy"
>>> > xmlns:wsp="http://www.w3.org/ns/ws-policy"
>>> > xmlns:wsu="
>>> >
>>> >
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>> > "
>>> > xmlns:sp="
>>> > http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
>>> >
>>> > <wsp:All>
>>> > <sp:TransportBinding>
>>> > <wsp:Policy>
>>> > <sp:TransportToken>
>>> > <wsp:Policy>
>>> > <sp:HttpsToken>
>>> > <wsp:Policy>
>>> > <sp:RequireClientCertificate/>
>>> > </wsp:Policy>
>>> > </sp:HttpsToken>
>>> > </wsp:Policy>
>>> > </sp:TransportToken>
>>> > <sp:AlgorithmSuite>
>>> > <wsp:Policy>
>>> > <sp:Basic128 />
>>> > </wsp:Policy>
>>> > </sp:AlgorithmSuite>
>>> > <sp:Layout>
>>> > <wsp:Policy>
>>> > <sp:Strict />
>>> > </wsp:Policy>
>>> > </sp:Layout>
>>> > <sp:IncludeTimestamp />
>>> > </wsp:Policy>
>>> > </sp:TransportBinding>
>>> >
>>> > <sp:SignedSupportingTokens>
>>> > <wsp:Policy>
>>> > <sp:SamlToken sp:IncludeToken="
>>> >
>>> >
>>> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
>>> > ">
>>> > <wsp:Policy>
>>> > <sp:WssSamlV11Token11/>
>>> > </wsp:Policy>
>>> > </sp:SamlToken>
>>> > </wsp:Policy>
>>> > </sp:SignedSupportingTokens>
>>> > </wsp:All>
>>> > </wsp:Policy>
>>> >
>>>
>>>
>>>
>>> --
>>> Colm O hEigeartaigh
>>>
>>> Talend Community Coder
>>> http://coders.talend.com
>>>
>>
Re: Upgrading to cxf 2.7.13 - SAMLTokenPrincipal no longer being
registered as a SecurityContext
Posted by Jason Pell <ja...@pellcorp.com>.
I don't think I can easily override the wss4j interceptor as I am using WS
policy so the interceptors are added for me.
Am eager to understand the security issues with client certs. When will
these be publicized
On 17/10/2014 12:56 AM, "Jason Pell" <ja...@pellcorp.com> wrote:
> I would be interested to understand why it is a security issue when the
> client TLS establishes the trust relationship.
>
> I had just finished adding basic saml support to our product and now with
> the upgrade I am back to square one.
>
> From the docs I have read using TLS with client auth instead of signed is
> a good alternative and performs better.
> On 17/10/2014 12:22 AM, "Colm O hEigeartaigh" <co...@apache.org> wrote:
>
>> There have been some considerable changes to SAML processing based on some
>> security issues that will become public soon. The security context is not
>> populated via unsigned SAML tokens any more (even if they are received
>> over
>> TLS with client authentication). If you want to support this you will have
>> to override the doResults method of the WSS4JInInterceptor. If you really
>> want to though, we could introduce a new JAX-WS property (defaulting to
>> false) to all this behaviour.
>>
>> Colm.
>>
>> On Thu, Oct 16, 2014 at 2:02 PM, Jason Pell <ja...@pellcorp.com> wrote:
>>
>> > All I get now is the X500Principal of the https token.
>> >
>> > My policy is below. I am relying on the RequireClientCertificate to
>> have
>> > the saml token "signed" and thus I would have expected it to be present
>> in
>> > the security context. I am at a loss as to why something like this
>> could
>> > change between point releases.
>> >
>> >
>> > <!-- 2.3.1.1 (WSS1.0) SAML1.1 Assertion (Bearer) -->
>> > <wsp:Policy wsu:Id="TLSBearerPolicy"
>> > xmlns:wsp="http://www.w3.org/ns/ws-policy"
>> > xmlns:wsu="
>> >
>> >
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>> > "
>> > xmlns:sp="
>> > http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
>> >
>> > <wsp:All>
>> > <sp:TransportBinding>
>> > <wsp:Policy>
>> > <sp:TransportToken>
>> > <wsp:Policy>
>> > <sp:HttpsToken>
>> > <wsp:Policy>
>> > <sp:RequireClientCertificate/>
>> > </wsp:Policy>
>> > </sp:HttpsToken>
>> > </wsp:Policy>
>> > </sp:TransportToken>
>> > <sp:AlgorithmSuite>
>> > <wsp:Policy>
>> > <sp:Basic128 />
>> > </wsp:Policy>
>> > </sp:AlgorithmSuite>
>> > <sp:Layout>
>> > <wsp:Policy>
>> > <sp:Strict />
>> > </wsp:Policy>
>> > </sp:Layout>
>> > <sp:IncludeTimestamp />
>> > </wsp:Policy>
>> > </sp:TransportBinding>
>> >
>> > <sp:SignedSupportingTokens>
>> > <wsp:Policy>
>> > <sp:SamlToken sp:IncludeToken="
>> >
>> >
>> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
>> > ">
>> > <wsp:Policy>
>> > <sp:WssSamlV11Token11/>
>> > </wsp:Policy>
>> > </sp:SamlToken>
>> > </wsp:Policy>
>> > </sp:SignedSupportingTokens>
>> > </wsp:All>
>> > </wsp:Policy>
>> >
>>
>>
>>
>> --
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>
Re: Upgrading to cxf 2.7.13 - SAMLTokenPrincipal no longer being
registered as a SecurityContext
Posted by Jason Pell <ja...@pellcorp.com>.
I would be interested to understand why it is a security issue when the
client TLS establishes the trust relationship.
I had just finished adding basic saml support to our product and now with
the upgrade I am back to square one.
>From the docs I have read using TLS with client auth instead of signed is a
good alternative and performs better.
On 17/10/2014 12:22 AM, "Colm O hEigeartaigh" <co...@apache.org> wrote:
> There have been some considerable changes to SAML processing based on some
> security issues that will become public soon. The security context is not
> populated via unsigned SAML tokens any more (even if they are received over
> TLS with client authentication). If you want to support this you will have
> to override the doResults method of the WSS4JInInterceptor. If you really
> want to though, we could introduce a new JAX-WS property (defaulting to
> false) to all this behaviour.
>
> Colm.
>
> On Thu, Oct 16, 2014 at 2:02 PM, Jason Pell <ja...@pellcorp.com> wrote:
>
> > All I get now is the X500Principal of the https token.
> >
> > My policy is below. I am relying on the RequireClientCertificate to have
> > the saml token "signed" and thus I would have expected it to be present
> in
> > the security context. I am at a loss as to why something like this could
> > change between point releases.
> >
> >
> > <!-- 2.3.1.1 (WSS1.0) SAML1.1 Assertion (Bearer) -->
> > <wsp:Policy wsu:Id="TLSBearerPolicy"
> > xmlns:wsp="http://www.w3.org/ns/ws-policy"
> > xmlns:wsu="
> >
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> > "
> > xmlns:sp="
> > http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
> >
> > <wsp:All>
> > <sp:TransportBinding>
> > <wsp:Policy>
> > <sp:TransportToken>
> > <wsp:Policy>
> > <sp:HttpsToken>
> > <wsp:Policy>
> > <sp:RequireClientCertificate/>
> > </wsp:Policy>
> > </sp:HttpsToken>
> > </wsp:Policy>
> > </sp:TransportToken>
> > <sp:AlgorithmSuite>
> > <wsp:Policy>
> > <sp:Basic128 />
> > </wsp:Policy>
> > </sp:AlgorithmSuite>
> > <sp:Layout>
> > <wsp:Policy>
> > <sp:Strict />
> > </wsp:Policy>
> > </sp:Layout>
> > <sp:IncludeTimestamp />
> > </wsp:Policy>
> > </sp:TransportBinding>
> >
> > <sp:SignedSupportingTokens>
> > <wsp:Policy>
> > <sp:SamlToken sp:IncludeToken="
> >
> >
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
> > ">
> > <wsp:Policy>
> > <sp:WssSamlV11Token11/>
> > </wsp:Policy>
> > </sp:SamlToken>
> > </wsp:Policy>
> > </sp:SignedSupportingTokens>
> > </wsp:All>
> > </wsp:Policy>
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
Re: Upgrading to cxf 2.7.13 - SAMLTokenPrincipal no longer being
registered as a SecurityContext
Posted by Colm O hEigeartaigh <co...@apache.org>.
There have been some considerable changes to SAML processing based on some
security issues that will become public soon. The security context is not
populated via unsigned SAML tokens any more (even if they are received over
TLS with client authentication). If you want to support this you will have
to override the doResults method of the WSS4JInInterceptor. If you really
want to though, we could introduce a new JAX-WS property (defaulting to
false) to all this behaviour.
Colm.
On Thu, Oct 16, 2014 at 2:02 PM, Jason Pell <ja...@pellcorp.com> wrote:
> All I get now is the X500Principal of the https token.
>
> My policy is below. I am relying on the RequireClientCertificate to have
> the saml token "signed" and thus I would have expected it to be present in
> the security context. I am at a loss as to why something like this could
> change between point releases.
>
>
> <!-- 2.3.1.1 (WSS1.0) SAML1.1 Assertion (Bearer) -->
> <wsp:Policy wsu:Id="TLSBearerPolicy"
> xmlns:wsp="http://www.w3.org/ns/ws-policy"
> xmlns:wsu="
>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> xmlns:sp="
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
>
> <wsp:All>
> <sp:TransportBinding>
> <wsp:Policy>
> <sp:TransportToken>
> <wsp:Policy>
> <sp:HttpsToken>
> <wsp:Policy>
> <sp:RequireClientCertificate/>
> </wsp:Policy>
> </sp:HttpsToken>
> </wsp:Policy>
> </sp:TransportToken>
> <sp:AlgorithmSuite>
> <wsp:Policy>
> <sp:Basic128 />
> </wsp:Policy>
> </sp:AlgorithmSuite>
> <sp:Layout>
> <wsp:Policy>
> <sp:Strict />
> </wsp:Policy>
> </sp:Layout>
> <sp:IncludeTimestamp />
> </wsp:Policy>
> </sp:TransportBinding>
>
> <sp:SignedSupportingTokens>
> <wsp:Policy>
> <sp:SamlToken sp:IncludeToken="
>
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
> ">
> <wsp:Policy>
> <sp:WssSamlV11Token11/>
> </wsp:Policy>
> </sp:SamlToken>
> </wsp:Policy>
> </sp:SignedSupportingTokens>
> </wsp:All>
> </wsp:Policy>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com