Hi Colm - unfortunately I don’t have a stack trace, this showed up remotely and they didn’t send a log. And I can’t recreate it. But I was a little mistaken in my question – the log did show that it couldn’t dereference the STR, but the log also showed that the Assertion digest didn’t match, which caused signature validation to fail; so I think the dereferencing failure was a red herring.
I did some research and found this in WS-I BSP: “If a namespace that is in fact visibly used within some text to be Canonicalized via the Exclusive C14N Algorithm is included in the PrefixList, then under some valid transformations of the transmitted document signature verification may spuriously fail, because the Canonicalized form shifts the location of a namespace declaration. This case is expected to be rare in practice.” Based on that, my guess is that WSS4J and WebSphere perform canonicalization differently when the PrefixList has visibly used prefixes. Exclusive Canonicalization doesn’t really specify how that case is to be handled, so it’s not surprising that the two products work differently. So my plan then is to write some requirements that basically say not to do that, so that we can (hopefully) eliminate the potential for undefined or inconsistent behavior. Thanx, Stephen W. Chappell From: Colm O hEigeartaigh [mailto:[email protected]] Sent: Wednesday, January 27, 2016 7:17 AM To: [email protected] Subject: Re: Canonicalization & InclusiveNamespaces Hi Stephen, What is the stacktrace that you see? Could you attach the debug log of the failing request? I don't see any reason how adding InclusivePrefixes would change how WSS4J can resolve the dereferenced Assertion. Colm. On Tue, Jan 26, 2016 at 6:55 PM, <[email protected]<mailto:[email protected]>> wrote: I am trying to process a signed message with CXF 3.1.0/WSS4J 2.1.2, and having trouble with signature validation in certain situations. The request is being generated by some WebSphere client and shipped over to my software, which is complaining that it can’t resolve one of the signature references. The reference that it can’t resolve is for an STR that refers to a direct-referenced SAML Assertion. All the parts are there in the message, so there’s no obvious reason for it not to resolve. The challenging bit of this is that sometimes WSS4J *can* resolve the reference … when WebSphere is configured not to include InclusiveNamespaces as part of its exclusive canonicalization, then everything works fine. When InclusiveNamespaces is included in the transform, then it cannot resolve the reference. The example message below includes the InclusiveNamespaces clause under the reference for wssecurity_signature_id_25. Does anyone know of any reason why there’d be an issue resolving that reference? Any help or insight here would be appreciated. Thanx! <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"; soapenv:mustUnderstand="1"> <wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; wsu:Id="wssecurity_signature_id_24"> ... </wsu:Timestamp> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; ID="Assertion-uuid1e604b54-0152-1e12-9f56-96ebe7ae4d90" IssueInstant="2016-01-07T23:16:13Z" Version="2.0"> ... </saml:Assertion> <wsse:SecurityTokenReference xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; wsu:Id="wssecurity_signature_id_25"> <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID";>Assertion-uuid1e604b54-0152-1e12-9f56-96ebe7ae4d90</wsse:KeyIdentifier> </wsse:SecurityTokenReference> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#<http://www.w3.org/2000/09/xmldsig>"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#<http://www.w3.org/2001/10/xml-exc-c14n>"> <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#<http://www.w3.org/2001/10/xml-exc-c14n>" PrefixList="soapenv wsa wsse ds "/> </ds:CanonicalizationMethod> <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> <ds:Reference URI="#wssecurity_signature_id_20"> ... </ds:Reference> <ds:Reference URI="#wssecurity_signature_id_21"> ... </ds:Reference> <ds:Reference URI="#wssecurity_signature_id_22"> ... </ds:Reference> <ds:Reference URI="#wssecurity_signature_id_23"> ... </ds:Reference> <ds:Reference URI="#wssecurity_signature_id_24"> ... </ds:Reference> <ds:Reference URI="#wssecurity_signature_id_25"> <ds:Transforms> <ds:Transform Algorithm="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#STR-Transform";> <wsse:TransformationParameters> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#<http://www.w3.org/2001/10/xml-exc-c14n>"> <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#<http://www.w3.org/2001/10/xml-exc-c14n>" PrefixList="xc14n saml wsse soapenv ds xsi wsa"/> </ds:CanonicalizationMethod> </wsse:TransformationParameters> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <ds:DigestValue>CkNM3k5rGHHyiaLhBxMmYKa/HT8HwPWZMUkyfq/LyfA=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>XvZ9nbrOOwK/sp65IB28W99vyy/VL2F3TVIf6ZY/5SYhTTsv0oWTqkz6IMLJy9e9bDVVNGC9ygpLm89D2Aj4nVwljnVSPrDpBuSZz0NKS7rSp00uy0Yup/+1Hnxp5Y5XD8Dq4s/1ESPciDmltMNVqRVaf/vrGqJs3fdh+QhhzgFjeHae1OH1C20IrM4RV0B2gm6aHP/sG3FlnTyVxLK1hKqMXY8C4RnR1GS0p3ufiyi5TSUG1/57Ck3bgYuHPm8mDezi7ZE/iwUxpTj7KizJ7L7Jd+4xlHlGusr2Dy6zHT/K8Y26p4O2OTCcN6v6nSrx/hYy5UOTBN/sabyCGLTmUQ==</ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID";>Assertion-uuid1e604b54-0152-1e12-9f56-96ebe7ae4d90</wsse:KeyIdentifier> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> Thanx again, Stephen W. Chappell -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
