include SignatureValidation filter with FileBackedHTTPMetadataProvider

[Brent Putman]

On 12/19/17 4:31 PM, Cantor, Scott wrote:
> On 12/19/17, 4:01 PM, "dev on behalf of Tom Scavo" <dev-bounces at shibboleth.net on behalf of trscavo at gmail.com> wrote:
>
>> 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).
> 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.
>

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.

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.

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.

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


 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20171220/5cacf8df/attachment.html>