cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bimjoeipa <joel.pear...@ipaustralia.gov.au>
Subject Re: CXF Service can't process PublicKey SAML Sender Vouches IssuedToken in WS-Policy
Date Tue, 18 Feb 2014 05:30:15 GMT
coheigea wrote
> Could you try updating your CXF trunk code? It's using WSS4J 2.0.0-rc1,
> and
> not the SNAPSHOT, as of a few days now.

Can't believe I forgot to do that, I see that you changed it on the 7th Feb,
and it builds ok now.


coheigea wrote
> CXF 2.7.x does not support processing a SAML sender-vouches Assertion as
> part of an IssuedToken policy. However, this is currently supported on CXF
> trunk if you want to try with CXF 3.0.0-SNAPSHOT. I don't want to backport
> any of the changes for fear of breaking backwards compatibility for other
> scenarios.

I have exactly that same problem as in the 2.7.x series, it looks like
org.apache.cxf.ws.security.wss4j.policyvalidators.IssuedTokenPolicyValidator.checkIssuedTokenTemplate(Element,
SamlAssertionWrapper) needs the same patch I mentioned originally.

Additionally, I had other problems caused by WSS4J (when talking to my 3rd
party STS), I am getting this error:
"Caused by: org.apache.wss4j.common.ext.WSSecurityException: BSP:R5404: Any
CANONICALIZATION_METHOD Algorithm attribute MUST have a value of
"http://www.w3.org/2001/10/xml-exc-c14n#" indicating that it uses Exclusive
C14N without comments for canonicalization"

I looked into it and I believe
org.apache.wss4j.dom.processor.SignatureProcessor.checkBSPCompliance(XMLSignature,
BSPEnforcer) is interpreting  R5404
<http://www.ws-i.org/profiles/basicsecurityprofile-1.1.html#R5404>   in a
way that is more restrictive than the standard specifies.

The standard is saying "Any CANONICALIZATION_METHOD Algorithm attribute MUST
have a value of "http://www.w3.org/2001/10/xml-exc-c14n#" indicating that it
uses Exclusive C14N without comments for canonicalization.", but WSS4J is
also essentially adding "AND some parameter specifications MUST be defined"

For example my reading of the spec says that:

<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />

should be sufficient, but it is rejected if there isn't some parameter like
so:

<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
	<ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
PrefixList="soap"/>
</ds:CanonicalizationMethod>


Looking at the streaming version:
org.apache.wss4j.stax.impl.processor.input.WSSSignatureInputHandler.checkBSPCompliance(InputProcessorChain,
SignatureType), it looks like it is doing it the right way:

        CanonicalizationMethodType canonicalizationMethodType =
signatureType.getSignedInfo().getCanonicalizationMethod();
        if
(!WSSConstants.NS_C14N_EXCL.equals(canonicalizationMethodType.getAlgorithm()))
{
            securityContext.handleBSPRule(BSPRule.R5404);
        }

In 2.0.0-rc1 BSPRule.R5404 is already checked on line 722, but the extra
more restrictive rule is applied on 736 and 767.  I'm guessing the
additional rules are checking that the parameters are actually c14n
parameters, but it isn't checking the null case.
Maybe " if (!(parameterSpec instanceof ExcC14NParameterSpec)) {" should
become " if (parameterSpec == null || !(parameterSpec instanceof
ExcC14NParameterSpec)) {" ?



--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-Service-can-t-process-PublicKey-SAML-Sender-Vouches-IssuedToken-in-WS-Policy-tp5739904p5740081.html
Sent from the cxf-user mailing list archive at Nabble.com.

Mime
View raw message