[ 
https://issues.apache.org/jira/browse/CXF-6650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14970843#comment-14970843
 ] 

Grzegorz Maczuga commented on CXF-6650:
---------------------------------------

Hi Colm,

In deed second case was tried out of desperation.

For first case there is no stack trace. 
Simply SAML Token is not considered to be signed and populated SecurityContext 
is not of SAMLSecurityContext type.

Debugging it shows that in SAMLTokenProcessor.java 111:116:

        if (samlAssertion.isSigned()) {
            result = new WSSecurityEngineResult(WSConstants.ST_SIGNED, 
samlAssertion);
            result.put(WSSecurityEngineResult.TAG_DATA_REF_URIS, dataRefs);
        } else {
            result = new WSSecurityEngineResult(WSConstants.ST_UNSIGNED, 
samlAssertion);
        }

First test returns FALSE (SAML not signed) but later on in DOMSAMLUtil.java 
235:263 call to

   private static boolean checkAssertionAndBodyAreSigned

Returns TRUE (so SAML Token and Body are considered to be signed)

But then still in WSSInInterceptor.java doResults 527:590 method 
SecurityContext is not based on SAMLToken (unless it 
allowUnsignedSamlPrincipals is set to TRUE) due to the fact that samlAssertion 
is WSConstants.ST_UNSIGNED (set in SAMLTokenProcessor earlier on).

Hope that helps,
Greg




> SAML 2.0 SenderVouches / no 2-way TLS / XML Signature bug
> ---------------------------------------------------------
>
>                 Key: CXF-6650
>                 URL: https://issues.apache.org/jira/browse/CXF-6650
>             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
(v6.3.4#6332)

Reply via email to