<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 12/19/17 4:31 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:C3898465-B37F-457F-AD14-59AEB7F2F089@osu.edu">
<pre wrap="">On 12/19/17, 4:01 PM, "dev on behalf of Tom Scavo" <a class="moz-txt-link-rfc2396E" href="mailto:dev-bounces@shibboleth.netonbehalfoftrscavo@gmail.com"><dev-bounces@shibboleth.net on behalf of trscavo@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">OTOH, if the metadata is not signed, what should the default action of
the software be? I believe it should go out to the network by default.
If the deployer makes an explicit decision to grab a locally trusted
file instead, then that's fine. All I'm saying is that shouldn't be
the default behavior of the software (which is it if the deployer
happens to use FileBackedHTTPMetadataProvider).
</pre>
</blockquote>
<pre wrap="">
We don't agree with that. At least I don't, I guess the rest of the team can speak for themselves, but Brent presumably wouldn't have implemented it that way if he felt it was incorrect to do so.
</pre>
</blockquote>
<br>
Although I didn't implement this originally (Chad did), I agree with
how it works currently, and with what Scott said earlier in the
thread. The backup file is a local cache of data that you've
already fetched and trusted, and is there merely to optimize things
when you restart/refresh the provider, as well as provide a backup
against the remote source being down when you restart/refresh. It's
implicitly trusted. It has to be, you have to be able to trust your
local system, or it's game over.<br>
<br>
I really do not understand the concern about whether it was signed
or not, vs the fact that at some particular and arbitrary time, a
human (or cron etc) decides to restart/refresh the provider or the
IdP. They just seem completely orthogonal to me.<br>
<br>
Consider: A remote source has a validUntil that is 24 hours.
Consider the case of one file-backed provider that fetches that and
isn't restarted, so that you have the same metadata and trust it for
the 24 hour duration. Consider a second file-backed provider that
fetches the same, but is restarted/refreshed every hour or two. Is
the latter somehow different vis-a-vis security and trust? Should
it have to re-fetch and re-validate the data merely because a human
chose to restart/refresh? IMHO no. The restart has nothing to do
with how/why you trust that metadata, or the trust in the mechanism
by which it is obtained.<br>
<br>
If it makes you feel any better, the current behavior of the
file-backed provider in the IdP is that it loads the backup file in
the foreground thread, and then immediately schedules a background
thread refresh attempt for a few seconds in the future (duration is
also configurable). So the issue that you are apparently concerned
with is only going to have a window of a few seconds. Assuming the
fetch is successful, that is - if it's not, it will keep the data
loaded from the backup file, which is the main point of the
file-backed provider (in addition to optimizing the startup).<br>
<br>
<br>
<br>
</body>
</html>