Hi, I have created a simple soap service where the issue can be reproduced. Run the main class and then start the unit test, it will fail with the error "Signature cryptographic validation not successful".
-----Ursprüngliche Nachricht----- Von: Colm O hEigeartaigh <cohei...@apache.org> Gesendet: Dienstag, 7. Jänner 2025 13:04 An: dev@santuario.apache.org Betreff: Re: Digest verification fails with SAAJ 1.4+ [Sie erhalten nicht häufig E-Mails von cohei...@apache.org. Weitere Informationen, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification ] Hi, Is it possible to reproduce the issue in a unit test (or even a standalone testcase)? Colm. On Tue, Jan 7, 2025 at 11:29 AM FABIAN Lukas <lukas.fab...@svc.co.at> wrote: > > Hi, > > > > I have an issue with digest verification when using SAAJ versions newer than > 1.3. In general my issue is very similar to SANTUARIO-576. > > > > With SAAJ 1.3 everything works as intended, but if I use SAAJ 1.4 (or any > newer version, e.g. 3.0.4), the digest verification fails. After some > investigation, I noticed that with the new versions there is a type mismatch > in org.apache.xml.security.c14n.implementations.CanonicalizerBase which leads > to the Signature element not being removed, thus calculating a wrong digest > value. > > The relevant code is from line 242 onwards: > case Node.ELEMENT_NODE : > > documentLevel = NODE_NOT_BEFORE_OR_AFTER_DOCUMENT_ELEMENT; > > if (currentNode == excludeNode) { > > break; > > } > > > > In my case excludeNode is of type > com.sun.xml.messaging.saaj.soap.impl.ElementImpl and currentNode is of type > com.sun.org.apache.xerces.internal.dom.ElementNSImpl. Therefore, the > condition currentNode == excludeNode is not true and the excludeNode is not > removed. > > The behaviour seems to have changed with SAAJ 1.4 because ElementImpl is no > longer extending com.sun.org.apache.xerces.internal.dom.ElementNSImpl. It now > has a private element field to store a reference to the actual Element. > > > > A fix for my issue would be replacing > > if (currentNode == excludeNode) > > with > > if (excludeNode != null && excludeNode.isSameNode(currentNode)) > > > > but maybe there are better fixes. Especially the case from the Jira Ticket, > where the class types of currentNode and excludeNode are swapped, would not > be fixed with my approach. > > > > Is it possible to fix this in a future version of Santuario? This issue is > blocking the JBoss EAP8 migration of our application. > > > > Kind regards, > > Lukas Fabian
<<attachment: saaj-santuario-test.zip>>
