<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/2/18 6:28 PM, Tom Scavo wrote:</div>
<blockquote type="cite"
cite="mid:CAEtu=dPJhqinr0A6YbHWM==pyoZJ7CT4Bs9RTLWVuCdZOa1Q4Q@mail.gmail.com">
<pre wrap="">
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. </pre>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:CAEtu=dPJhqinr0A6YbHWM==pyoZJ7CT4Bs9RTLWVuCdZOa1Q4Q@mail.gmail.com">
<pre wrap="">For this reason, the
well-known location strategy should be avoided in most cases.</pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAEtu=dPJhqinr0A6YbHWM==pyoZJ7CT4Bs9RTLWVuCdZOa1Q4Q@mail.gmail.com">
<pre wrap="">You need to step back for a moment. The IdP rarely obtains SP metadata
directly from the SP, at least not dynamically.
</pre>
</blockquote>
<br>
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.<br>
</body>
</html>