Verification failed for URI

[Brent Putman]

On 8/2/18 6:28 PM, Tom Scavo wrote:
> If you forget to configure a child element, the provider will default
> to the well-known location strategy. This constrains the entityID to
> be an URL (not an URN) but the provider does not check the URL scheme.
> If the scheme on the entityID is "http:", the metadata exchange will
> be vulnerable to a man-in-the-middle attack. 

That's true, but if the metadata is signed and you have the
SignatureValidation filter enabled with requireSignedRoot="true", as he
does, then that warning re MITM is not really relevant.

> For this reason, the
> well-known location strategy should be avoided in most cases.

I'd say personally that's a little strong.  If used correctly, as it
appears to be here, then it's technically speaking fine, albeit a little
atypical.


> You need to step back for a moment. The IdP rarely obtains SP metadata
> directly from the SP, at least not dynamically.

It's unusual, but we do support that model of self-signed and
self-published metadata, including use of URI subject alt names in certs
to bind the signing key to the party's entityID.  There was a time when
we thought this might be one way out of the non-scalable batch model of
metadata.  MDQ is probably the true way forward at this point, but the
well-known location strategy isn't really "bad", if implemented correctly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180802/3a5ff692/attachment.html>