Metadata resolver is looking at ID instead of entityID

Brent Putman putmanb at
Tue Aug 7 15:23:57 EDT 2018

On 8/7/18 10:07 AM, Cody Carmichael wrote:
> Ah, you were correct that I needed to look earlier in the logs. 
>     [] - Verification
>     failed for URI "#_f82d91b40d8850701548612d14cedb7b"
>     [] - Expected
>     Digest: Igunx6qgopGS6lUqRjopyPq9wLZN51legZzLMQb0Q98=
>     [] - Actual
>     Digest: N/rKwh55tO5Ap5n9FIHEMwgmRn/iUE/TiuGiLGDan/0=
> The dev has checked the code on their side and found no issues in the
> signature.

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.

> 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.

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.

> Exactly what part of the metadata needs to be hashed to create the
> digest value that is added in the signed info? 
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.

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.

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list