I have merged a fix for 2.7 3.0 and master On 17/10/2014 7:46 AM, "Jason Pell" <[email protected]> wrote:
> 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 >>>>> >>>> >
