Hi Colm, I can see in the http log of SoapUI that it is not transmitting the id attributes of the WS-Addressing headers except the "RelatesTo" that I added myself:
Tue Aug 21 13:49:04 CEST 2018:DEBUG:>> " <wsa:RelatesTo wsu:Id="id-137" xmlns:wsu=" http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd ">relatesToBlablaTest</wsa:RelatesTo>[\n]" Tue Aug 21 13:49:04 CEST 2018:DEBUG:>> " [\n]" Tue Aug 21 13:49:04 CEST 2018:DEBUG:>> " [\n]" Tue Aug 21 13:49:04 CEST 2018:DEBUG:>> " [\n]" Tue Aug 21 13:49:04 CEST 2018:DEBUG:>> " [\n]" Tue Aug 21 13:49:04 CEST 2018:DEBUG:>> " [\n]" Tue Aug 21 13:49:04 CEST 2018:DEBUG:>> " [\n]" Tue Aug 21 13:49:04 CEST 2018:DEBUG:>> " <wsa:Action> http://EMVS.EU/20161/IProductServiceV20161/ConfirmProductMasterDataStatus </wsa:Action><wsa:ReplyTo><wsa:Address>replyToBlablaTest</wsa:Address></wsa:ReplyTo><wsa:From><wsa:Address>fromBlaBlaTest</wsa:Address></wsa:From><wsa:FaultTo><wsa:Address>faultToBlablaTest</wsa:Address></wsa:FaultTo><wsa:MessageID>uuid:b23511ed-5bd8-4468-8410-a040c44eff3c</wsa:MessageID><wsa:To>toBlablaTest</wsa:To></soap:Header>[\n]" So it looks like the problem is indeed on the SoapUI side of things. What is probably happening is, that SoapUI is reapplying all the WS-Addressing headers to the message just when the message is sent, thereby overriding the changes (and removing the Id-attributes) that were performed earlier by applying WS-Security on the message. It's a bit disturbing that what you see in SoapUI is not what is sent, because SoapUI will perform some additional processing just before sending the message. But this means I can fix the problem by disabling the WS-Addressing processing by SoapUI and managing the headers manually. This makes SoapUI stay hands off the WS-Addressing headers and send the message with all id attributes intact. Thanks so much for your support. I spent two entire days on this, wading through the guts of CXF searching for the issue, and for some reason I didn't consider checking into what SoapUI is actually sending. Lesson learned. Best regards On Tue, Aug 21, 2018 at 1:35 PM Colm O hEigeartaigh <cohei...@apache.org> wrote: > If you enable the CXF logging feature, does the inbound message contain the > wsu:Ids for the WS-Addressing headers? If not then it would indicate the > problem is on the SOAP-UI side and not CXF. Could the manual change you are > making be causing a problem with SOAP-UI (just guessing). Failing that, if > you have a test-case to reproduce I can take a look. > > Colm. > > On Tue, Aug 21, 2018 at 12:29 PM, Elric Morgenstern <elric...@gmail.com> > wrote: > > > Hi Colm, > > > > thanks for your blazingly fast response. > > > > Thanks to your pointers on where to look, I think I have found the > > immediate cause of problem. getDocumentElement() contains all > WS-Addressing > > headers, but all the elements except the "RelatesTo" don't contain the > "id" > > attribute for some reason: > > "RelatesTo" attributes: [wsu:Id="id-137", xmlns:wsa="http://www.w3.org/ > > 2005/08/addressing", xmlns:wsu="http://docs.oasis- > > open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"] > > "Action" attributes: [xmlns:wsa="http://www.w3.org/2005/08/addressing";] > > "From" attributes: [xmlns:wsa="http://www.w3.org/2005/08/addressing";] > > etc. > > > > This explains why the elements can not be resolved. This of course begs > > the next question, why all the WS-Addressing headers except "RelatesTo" > are > > gobbling up the "wsu:Id" attribute. The "RelatesTo" is also the only > > element that contains the "wsu" namespace as attribute. > > Incidentally, the "RelatesTo" header is the only WS-Addressing element I > > added to the message manually, because SoapUI wouldn't add it > automatically. > > > > I wonder if it's related to this blog post describing a problem with > > custom id tags when the id already has a meaning in the schema: > > https://blogs.msdn.microsoft.com/shawnfa/2004/04/05/ > > searching-for-custom-id-tags-with-signed-xml/ > > > > But I'm not aware of any id attribute in WS-Addressing headers. > > > > > > On Tue, Aug 21, 2018 at 12:23 PM Colm O hEigeartaigh < > cohei...@apache.org> > > wrote: > > > >> Hi, > >> > >> Could you try putting a breakpoint in the DOMCallbackLookup here: > >> > >> https://github.com/apache/wss4j/blob/eb907a956bb604d89bb56e5c960c7b > >> 9f6abd4e27/ws-security-dom/src/main/java/org/apache/wss4j/dom/callback/ > >> DOMCallbackLookup.java#L96 > >> > >> Firstly check that doc.getDocumentElement() contains all of the > >> WS-Addressing headers. Then if it does check to see why > >> XMLUtils.findElementById > >> doesn't find the correct Element. > >> > >> Colm. > >> > >> On Tue, Aug 21, 2018 at 11:01 AM, Elric Morgenstern <elric...@gmail.com > > > >> wrote: > >> > >> > Hi guys, > >> > > >> > first of all, thanks for the great frameworks CXF and WSS4J! > >> > > >> > I have setup a web service with signature validation that I'm calling > >> from > >> > SoapUI, and when validating the signatures, WSS4J can not resolve the > >> > <Reference>'d elements in the signatures, with an exception: > >> > > >> > javax.xml.crypto.dsig.XMLSignatureException: > >> > javax.xml.crypto.URIReferenceException: > >> > org.apache.xml.security.utils.resolver.ResourceResolverException: > >> Cannot > >> > resolve element with ID id-132 > >> > > >> > What is being singed are all WS-Addressing headers and the message > body. > >> > What is weird is that by debugging the code it seems that WSS4J always > >> > manages to resolve only the "RelatesTo" and the message body, but not > >> any > >> > of the other WS-Addressing headers. > >> > > >> > I have set a breakpoint in the class > >> > org.apache.wss4j.dom.processor.SignatureProcessor:372: > >> > Code: > >> > // Test for replay attacks > >> > testMessageReplay(elem, > >> > xmlSignature.getSignatureValue().getValue(), key, data, wsDocInfo); > >> > > >> > setElementsOnContext(xmlSignature, > >> > (DOMValidateContext)context, > >> > data, wsDocInfo); > >> > boolean signatureOk = xmlSignature.validate(context); > >> > if (signatureOk) { > >> > return xmlSignature; > >> > } > >> > > >> > After calling "setElementsOnContext", the "context" object of type > >> > "DOMValidateContext" always only contains the "RelatesTo" and "Body" > >> > elements in the "idMap" HashMap: > >> > Contents of "idMap" in DOMValidateContext: > >> > > >> > {id-137=[wsa:RelatesTo: null], id-139=[soap:Body: null]} > >> > > >> > > >> > It's a complete mystery to me why WSS4J is not able to find the other > >> > referenced elements. All the elements are referenced in the same way, > >> using > >> > an id: > >> > <ds:Reference URI="#id-133"> > >> > > >> > I'm using CXF version 3.2.4 > >> > Tomcat 9.0.10 > >> > And I'm calling the web service using Soap UI 5.3.0 > >> > > >> > Below is a simplified version of the Soap message. > >> > Any help on what could be going wrong is greatly appreciated. > >> > > >> > <soap:Envelope xmlns:ns="http://blabla.test"; xmlns:ns1=" > >> http://blabla.xxx > >> > " > >> > xmlns:soap="http://www.w3.org/2003/05/soap-envelope";> > >> > <soap:Header xmlns:wsa="http://www.w3.org/2005/08/addressing";> > >> > <wsse:Security xmlns:wsse=" > >> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- > >> > wssecurity-secext-1.0.xsd" > >> > xmlns:wsu=" > >> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- > >> > wssecurity-utility-1.0.xsd > >> > "> > >> > <wsse:BinarySecurityToken>...</wsse:BinarySecurityToken> > >> > <ds:Signature Id="SIG-140" xmlns:ds=" > >> > http://www.w3.org/2000/09/xmldsig#";> > >> > <ds:SignedInfo> > >> > <ds:CanonicalizationMethod Algorithm=" > >> > http://www.w3.org/2001/10/xml-exc-c14n#";> > >> > <ec:InclusiveNamespaces PrefixList="wsa ns ns1 soap" > >> > xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/> > >> > </ds:CanonicalizationMethod> > >> > <ds:SignatureMethod Algorithm=" > >> > http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> > >> > <ds:Reference URI="#id-132"> > >> > <ds:Transforms> > >> > <ds:Transform Algorithm=" > >> > http://www.w3.org/2001/10/xml-exc-c14n#";> > >> > <ec:InclusiveNamespaces PrefixList="ns ns1 > soap" > >> > xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/> > >> > </ds:Transform> > >> > </ds:Transforms> > >> > <ds:DigestMethod Algorithm=" > >> > http://www.w3.org/2001/04/xmlenc#sha256"/> > >> > > >> > <ds:DigestValue>igHah0Fsph3yT1AfqBPAQFwZoe21h7Xaw5/XN/EI/TM=</ds: > >> > DigestValue> > >> > </ds:Reference> > >> > <ds:Reference URI="#id-133"> > >> > <ds:Transforms> > >> > <ds:Transform Algorithm=" > >> > http://www.w3.org/2001/10/xml-exc-c14n#";> > >> > <ec:InclusiveNamespaces PrefixList="ns ns1 > soap" > >> > xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/> > >> > </ds:Transform> > >> > </ds:Transforms> > >> > <ds:DigestMethod Algorithm=" > >> > http://www.w3.org/2001/04/xmlenc#sha256"/> > >> > > >> > <ds:DigestValue>BvwYUy3zLMTN6UHkNhuZG2iLlv8jT/zTuMDXaaj39uk=</ds: > >> > DigestValue> > >> > </ds:Reference> > >> > <ds:Reference URI="#id-134"> > >> > <ds:Transforms> > >> > <ds:Transform Algorithm=" > >> > http://www.w3.org/2001/10/xml-exc-c14n#";> > >> > <ec:InclusiveNamespaces PrefixList="ns ns1 > soap" > >> > xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/> > >> > </ds:Transform> > >> > </ds:Transforms> > >> > <ds:DigestMethod Algorithm=" > >> > http://www.w3.org/2001/04/xmlenc#sha256"/> > >> > > >> > <ds:DigestValue>ds9Kq8RNZFb8O1Liud1TxxlEm4aMeoLpm3pO10Efw8A=</ds: > >> > DigestValue> > >> > </ds:Reference> > >> > <ds:Reference URI="#id-135"> > >> > <ds:Transforms> > >> > <ds:Transform Algorithm=" > >> > http://www.w3.org/2001/10/xml-exc-c14n#";> > >> > <ec:InclusiveNamespaces PrefixList="ns ns1 > soap" > >> > xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/> > >> > </ds:Transform> > >> > </ds:Transforms> > >> > <ds:DigestMethod Algorithm=" > >> > http://www.w3.org/2001/04/xmlenc#sha256"/> > >> > > >> > <ds:DigestValue>OQW8p1GB6BlIr5sKp/vRRyZrwMTIK7tbTKU64JxkiM4=</ > >> > ds:DigestValue> > >> > </ds:Reference> > >> > <ds:Reference URI="#id-136"> > >> > <ds:Transforms> > >> > <ds:Transform Algorithm=" > >> > http://www.w3.org/2001/10/xml-exc-c14n#";> > >> > <ec:InclusiveNamespaces PrefixList="ns ns1 > soap" > >> > xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/> > >> > </ds:Transform> > >> > </ds:Transforms> > >> > <ds:DigestMethod Algorithm=" > >> > http://www.w3.org/2001/04/xmlenc#sha256"/> > >> > > >> > <ds:DigestValue>UdwSWsTRFhFH3qgeCESL1RPy+5B/RpWkZXzHANiBBeA=</ds: > >> > DigestValue> > >> > </ds:Reference> > >> > <ds:Reference URI="#id-137"> > >> > <ds:Transforms> > >> > <ds:Transform Algorithm=" > >> > http://www.w3.org/2001/10/xml-exc-c14n#";> > >> > <ec:InclusiveNamespaces PrefixList="ns ns1 > soap" > >> > xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/> > >> > </ds:Transform> > >> > </ds:Transforms> > >> > <ds:DigestMethod Algorithm=" > >> > http://www.w3.org/2001/04/xmlenc#sha256"/> > >> > > >> > <ds:DigestValue>QQgyhzpWNnFn97J2NpJcYAeoDtgFxVeHtCsgbu4UiZg=</ds: > >> > DigestValue> > >> > </ds:Reference> > >> > <ds:Reference URI="#id-138"> > >> > <ds:Transforms> > >> > <ds:Transform Algorithm=" > >> > http://www.w3.org/2001/10/xml-exc-c14n#";> > >> > <ec:InclusiveNamespaces PrefixList="ns ns1 > soap" > >> > xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/> > >> > </ds:Transform> > >> > </ds:Transforms> > >> > <ds:DigestMethod Algorithm=" > >> > http://www.w3.org/2001/04/xmlenc#sha256"/> > >> > > >> > <ds:DigestValue>5xuElno+hnvrP9kEEydeqnOr31CnwwaibbGULW > >> > t45oo=</ds:DigestValue> > >> > </ds:Reference> > >> > <ds:Reference URI="#id-139"> > >> > <ds:Transforms> > >> > <ds:Transform Algorithm=" > >> > http://www.w3.org/2001/10/xml-exc-c14n#";> > >> > <ec:InclusiveNamespaces PrefixList="ns ns1" > >> > xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/> > >> > </ds:Transform> > >> > </ds:Transforms> > >> > <ds:DigestMethod Algorithm=" > >> > http://www.w3.org/2001/04/xmlenc#sha256"/> > >> > > >> > <ds:DigestValue>LyjD1agKv+vE6BJHvRfQaVMwkUscqFFOhTgeljsd > >> > VxA=</ds:DigestValue> > >> > </ds:Reference> > >> > </ds:SignedInfo> > >> > <ds:SignatureValue>....</ds:SignatureValue> > >> > <ds:KeyInfo Id="..."> > >> > <wsse:SecurityTokenReference > >> > wsu:Id="STR-7FFC76A4DC1B36D2C1153484111729556"> > >> > <wsse:Reference > >> > URI="#X509-7FFC76A4DC1B36D2C1153484111729554" ValueType=" > >> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- > >> > x509-token-profile-1.0#X509v3 > >> > "/> > >> > </wsse:SecurityTokenReference> > >> > </ds:KeyInfo> > >> > </ds:Signature> > >> > <xenc:EncryptedKey Id="..." xmlns:xenc=" > >> > http://www.w3.org/2001/04/xmlenc#";> > >> > <xenc:EncryptionMethod Algorithm=" > >> > http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> > >> > <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig# > "> > >> > <wsse:SecurityTokenReference> > >> > <wsse:KeyIdentifier EncodingType=" > >> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- > >> > soap-message-security-1.0#Base64Binary" > >> > ValueType=" > >> > http://docs.oasis-open.org/wss/oasis-wss-soap-message- > >> > security-1.1#ThumbprintSHA1 > >> > ">.....</wsse:KeyIdentifier> > >> > </wsse:SecurityTokenReference> > >> > </ds:KeyInfo> > >> > <xenc:CipherData> > >> > <xenc:CipherValue>....</xenc:CipherValue> > >> > </xenc:CipherData> > >> > <xenc:ReferenceList> > >> > <xenc:DataReference URI="#ED-131"/> > >> > </xenc:ReferenceList> > >> > </xenc:EncryptedKey> > >> > </wsse:Security> > >> > <wsa:RelatesTo wsu:Id="id-137" xmlns:wsu=" > >> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- > >> > wssecurity-utility-1.0.xsd > >> > ">relatesToBlablaTest</wsa:RelatesTo> > >> > <wsa:Action wsu:Id="id-132" xmlns:wsu=" > >> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- > >> > wssecurity-utility-1.0.xsd > >> > ">http://test.action</wsa:Action> > >> > <wsa:ReplyTo wsu:Id="id-135" xmlns:wsu=" > >> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- > >> > wssecurity-utility-1.0.xsd > >> > "> > >> > <wsa:Address>https://localhost:8008/ReplyTo</wsa:Address> > >> > </wsa:ReplyTo> > >> > <wsa:From wsu:Id="id-133" xmlns:wsu=" > >> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- > >> > wssecurity-utility-1.0.xsd > >> > "> > >> > <wsa:Address>https://localhost:8008/From</wsa:Address> > >> > </wsa:From> > >> > <wsa:FaultTo wsu:Id="id-134" xmlns:wsu=" > >> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- > >> > wssecurity-utility-1.0.xsd > >> > "> > >> > <wsa:Address>https://localhost:8008/FaultTo</wsa:Address> > >> > </wsa:FaultTo> > >> > <wsa:MessageID wsu:Id="id-136" xmlns:wsu=" > >> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- > >> > wssecurity-utility-1.0.xsd > >> > ">uuid:72fb1403-c8af-4d17-bd80-6a9a594c2980</wsa:MessageID> > >> > <wsa:To wsu:Id="id-138" xmlns:wsu=" > >> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- > >> > wssecurity-utility-1.0.xsd > >> > ">https://localhost:8008/to</wsa:To> > >> > </soap:Header> > >> > <soap:Body wsu:Id="id-139" xmlns:wsu=" > >> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- > >> > wssecurity-utility-1.0.xsd > >> > "> > >> > <xenc:EncryptedData Id="ED-131" Type=" > >> > http://www.w3.org/2001/04/xmlenc#Content"; xmlns:xenc=" > >> > http://www.w3.org/2001/04/xmlenc#";> > >> > <xenc:EncryptionMethod Algorithm=" > >> > http://www.w3.org/2001/04/xmlenc#aes256-cbc"/> > >> > <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#";> > >> > <wsse:SecurityTokenReference wsse11:TokenType=" > >> > http://docs.oasis-open.org/wss/oasis-wss-soap-message- > >> > security-1.1#EncryptedKey" > >> > xmlns:wsse=" > >> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- > >> > wssecurity-secext-1.0.xsd" > >> > xmlns:wsse11=" > >> > http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd";> > >> > <wsse:Reference URI="#EK-7FFC76A4DC1B36D2C1153484111728 > >> > 653"/> > >> > </wsse:SecurityTokenReference> > >> > </ds:KeyInfo> > >> > <xenc:CipherData> > >> > <xenc:CipherValue>.........</xenc:CipherValue> > >> > </xenc:CipherData> > >> > </xenc:EncryptedData> > >> > </soap:Body> > >> > </soap:Envelope> > >> > > >> > >> > >> > >> -- > >> Colm O hEigeartaigh > >> > >> Talend Community Coder > >> http://coders.talend.com > >> > > > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com >
