Re: Digest verification fails with SAAJ 1.4+

I took a look, please see my comment.

Colm.

On Wed, Mar 5, 2025 at 8:47 AM FABIAN Lukas <[email protected]> wrote:
>
> Hi,
>
>
> I opened a pull request which fixes this issue (#453), could someone review this?
>
>
>
> ________________________________
> From: FABIAN Lukas
> Sent: Monday, 13 January 2025 08:22
> To: [email protected]
> Subject: AW: Digest verification fails with SAAJ 1.4+
>
> [Sie erhalten nicht häufig E-Mails von [email protected]. Weitere Informationen, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification ]
>
> 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 <[email protected]>
> Gesendet: Dienstag, 7. Jänner 2025 13:04
> An: [email protected]
> Betreff: Re: Digest verification fails with SAAJ 1.4+
>
> [Sie erhalten nicht häufig E-Mails von [email protected]. 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 <[email protected]> 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