<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 8/7/18 10:07 AM, Cody Carmichael
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAL9ddzKOaFpmEzEExdSoeU8sDEFjNF0+X0PUVToRFR9eiNCeVA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div dir="ltr">Ah, you were correct that I needed to look earlier
in the logs.
<div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">[org.apache.xml.security.signature.Reference:791]
- Verification failed for URI
"#_f82d91b40d8850701548612d14cedb7b"<br>
[org.apache.xml.security.signature.Reference:792] - Expected
Digest: Igunx6qgopGS6lUqRjopyPq9wLZN51legZzLMQb0Q98=<br>
[org.apache.xml.security.signature.Reference:793] - Actual
Digest: N/rKwh55tO5Ap5n9FIHEMwgmRn/iUE/TiuGiLGDan/0=</blockquote>
<div><br>
</div>
<div>The dev has checked the code on their side and found no
issues in the signature.</div>
</div>
</div>
</blockquote>
<br>
Well, the digest at validation time is different than it was at
signature time. So that's the issue, period. Either there is a bug
in the signing code or the document really has been changed since it
was signed. Only you and/or your developer are in a position to
diagnose the root cause there. Quadruply so if your local developer
is writing their own XML Signature code, or trying to implement a
custom SP with a third-party XML Signature library.<br>
<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAL9ddzKOaFpmEzEExdSoeU8sDEFjNF0+X0PUVToRFR9eiNCeVA@mail.gmail.com">
<div dir="ltr">
<div>
<div> Does it matter that the cert.pem that my
metadata-provider is pointing to is a standard public cert
that contains the 'BEGIN CERTIFICATE/END CERTIFICATE'
strings? The key and cert were created per the "Creating a
SAML key and Certificate" section of the docs except the
signature algorithm is sha256WithRSAEncryption instead of
the sha1WithRSAEncryption that appears in the example. <br>
</div>
</div>
</div>
</blockquote>
<br>
The digest mismatch above has nothing to do with the cert/key in
use. The computation of the digest above does not involve the
cert/key used to sign and validation. It's a different stage of the
signing/validation operation.<br>
<br>
<blockquote type="cite"
cite="mid:CAL9ddzKOaFpmEzEExdSoeU8sDEFjNF0+X0PUVToRFR9eiNCeVA@mail.gmail.com">
<div dir="ltr">
<div>
<div>Exactly what part of the metadata needs to be hashed to
create the digest value that is added in the signed info? </div>
</div>
<div class="gmail_extra"><br>
</div>
</div>
</blockquote>
As Peter said, that topic is way too extraordinarily complex for the
user's list. XML Signature is complicated, due to things like
transforms (e.g. canonicalization). You would need to consult the
XML Signature specs for details like that. If your developer is
truly writing code at a very low level like that (vs using a
library), then you are in for some very fun and interesting
challenges. Good luck.<br>
<br>
This is one of the reasons we try to dissuade people from writing
their own SAML SP implementation. It's far preferable instead to
just use an existing one.<br>
<br>
As I think Tom or someone said previously: if you have obtained this
metadata out-of-band via some other trusted mechanism and are then
just consuming it via a local Filesystem- provider, then you really
don't need signature validation. Certainly not for dev/testing
purposes. You would however want to use signature validation for
consuming remote metadata sources in production (the alternative
being server TLS validation, which we also support).<br>
</body>
</html>