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.
