Verification failed for URI

[Brent Putman]

On 8/2/18 7:21 PM, Cody Carmichael wrote:
> The SP in this case is a product under development by the company I
> work for. I've been working with the SP's dev for several days on this
> and unfortunately it's very time sensitive. What would be the more
> 'usual' way to get metadata from the SP? FileBackedHttp?
Ah.  Well, if you're still in the dev/testing phase and are just trying
to get a working interop between a dev IdP and SP, then the easiest is
to probably just manually configure the SP's metadata on the IdP using
the Filesystem- provider and avoid the signature or verifying.  Since
you've presumably manually obtained it from a trusted source and and
trust your own system and filesytem, that's fine, at least for
dev/testing etc.

> I'm new to most of the concepts involved with shibboleth so I don't
> have a concept of the typical way to do things.

There probably isn't a single typical way, it depends. It's a big
topic.  The most common approaches are: 1) IdP and SP are members of a
federation and they both consume each other's metadata by consuming the
federation's published aggregate 2) use of an MDQ server for dynamic
metadata 3) share the metadata out-of-band as I described above.  #3
doesn't scale very well though, for obvious reasons, and should usually
be avoided for real production deployments.

>
> What would make the signature invalid? The dev generated the public
> and private keys and I have a copy of the public key which is the
> cert.pem that's being pointed to. 
>
>
The error you posted has nothing to do with the keys.   Either the
signature was fundamentally invalid from the time it was signed, due to
a broken signature approach, a bug, etc; or perhaps more likely, the
metadata document was changed after it was signed.  If the XML signature
library the dev is using is known to be good, then it's likely to be the
latter.  If he's doing something fundamentally wrong or the library has
bug(s) or he/she is rolling their own XML signature code, then it could
very well be the former. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180802/36e19d24/attachment.html>