IdP 3.3.2 FileBackedHTTPMetadataProvider: RequiredValidUntilFilter & HTTP Conditional GET

[Cantor, Scott]

On 1/17/19, 11:15 AM, "users on behalf of David Arnold" <users-bounces at shibboleth.net on behalf of arnoldd at mcmaster.ca> wrote:

> The upshot is that a RequiredValidUntilFilter failure for a given payload is
> essentially permanent (or you restart your IdP, clearing memory and any
> HTTP cached values).

Filters come after. The state of the HTTP resource is what's tracked (because it is in fact fixed), not the result of evaluating the filters, because by then it's already been stored off.

> Is this expected behaviour?

Yes. You would not apply the filter with a threshold that would be exceeded under expected operation. You allow whatever slack is needed (much like clock skew), and you monitor for errors in the log. If, like, most, you can't really stare at logs all day, automating that via email notifications and such is a good idea.

If a federation promises a validity window of X days, you wouldn't use X as the filter value, but X + a few days, essentially. It used to give me some heartburn that revocation windows were still on the order of weeks, but when I consider that use of SAML in every other context has absolutely no revocation mechanism whatsoever, I get less defensive about how I designed things.

-- Scott