IdP 3.3.2 FileBackedHTTPMetadataProvider: RequiredValidUntilFilter & HTTP Conditional GET

[David Arnold]

Perfect, thanks Scott.  I already have a query in to CAF to determine
the best "mutually acceptable" validUntil expectation.  I'll also get
our operations team to monitor idp-process.log for this condition.

Thanks,

D.

On Thu, 2019-01-17 at 16:39 +0000, Cantor, Scott wrote:
> 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
> 
> 
-- 
David Arnold, Lead Architect - PeopleSoft
University Technology Services
McMaster University BSB233
1280 Main Street West
Hamilton, ON Canada L8S 4K1
Email: arnoldd at mcmaster.ca
Phone: 905-525-9140 x23843
Web: http://www.mcmaster.ca/uts