cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colm O hEigeartaigh (JIRA)" <>
Subject [jira] [Commented] (CXF-6650) SAML 2.0 SenderVouches / no 2-way TLS / XML Signature bug
Date Fri, 23 Oct 2015 10:00:29 GMT


Colm O hEigeartaigh commented on CXF-6650:

Thanks for that. I don't believe the second case should work. An internal signature should
only sign the SAML Assertion, not some external data. You are using the "enveloped-signature"
transform incorrectly here as well, as this is only meant to be used when you are signing
some parent Node.

However, the first case should work. What is the service side stack trace for this scenario?
A signature signing the SOAP Body + SAML Assertion is the typical sender-vouches scenario,
so I am puzzled if this is not working.


> SAML 2.0 SenderVouches / no 2-way TLS / XML Signature bug
> ---------------------------------------------------------
>                 Key: CXF-6650
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 3.0.6
>            Reporter: Grzegorz Maczuga
>         Attachments: SAMLwExternalSignature.txt, SAMLwInternalSignature.txt
> When an Oracle Api Gateway:
> - inserts a SenderVouches SAML 2.0 Assertion 
> - there is no 2-way TLS connection thus CXF require that both SAML Token and SOAP Body
are signed by same signature.
> Then CXF server fails to accept such request in following cases:
> 1) when signature is outside SAML Token element then token is considered to be not signed
by CXF SAMLTokenProcessor
> 2) when signature is inside SAML Token then Signature processing fails as CXF cannot
find referenced external Body element
> 3) when signature is inside SAML Token but it only signs SAML and no BODY, then it fails
Sender-vouches requirements
> Workaround to this is to:
> 1) Set in CXF that “not signed” SAML is OK:
> <entry key="ws-security.enable.unsigned-saml-assertion.principal" value="true" />
> 2) Enforce Signature of SAML on WSDL/WS-SecurityPolicy level:
> <ns3:SignedSupportingTokens>
> 	<ns3:WssSamlV20Token11/>
> </ns3:SignedSupportingTokens>
> but I believe that options 1) and 2) should normally work.

This message was sent by Atlassian JIRA

View raw message