https://issues.apache.org/jira/browse/CXF-6054
On Fri, Oct 17, 2014 at 1:11 AM, Jason Pell <[email protected]> wrote: > I will create jira and a patch to support the property. > On 17/10/2014 12:58 AM, "Jason Pell" <[email protected]> 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" <[email protected]> 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" <[email protected]> >>> 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 <[email protected]> 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 >>>> >>>
