expirationWarningThreshold
Michael A Grady
mgrady at unicon.net
Tue May 16 18:31:32 EDT 2017
>>> up on the users list, but there's one thing I'm sure about: a metadata
>>> provider configured to refresh federation metadata with
>>> expirationWarningThreshold="PT24H" won't do anybody much good since a
>>> deployer doesn't directly control the validUntil attribute on
>>> federation metadata.
>
> No, they don't control. But the point I was trying to make is that this setting is not about what happens under normal conditions, but rather under abnormal conditions. It's not something you can compute *directly* from knowledge of how the metadata source populates the validUntil (although that knowledge is obviously relevant). Because the very use case is "what happens when all of that breaks". So the most I can say is that it's how far in advance of a potential problem do you want to be notified so you can do something about it. If you think it would take greater than 24hrs to get your metadata source or federation operator to fix things, then maybe it is indeed greater than 24hrs.
>
I'm not sure why you think setting this value to more than 24 hours wouldn't make sense. Take the InCommon metadata, for example. I know it has a valid period of 2 weeks, and I know that just about every business day that metadata changes, and should be (if I have recommended refresh settings) therefore refreshed about once a business day. So if see that the validUntil of my copy is less than a week, then something is going wrong. it doesn't take getting to within 24 hours or less of it expiring to know I have a problem and things aren't working as I'd expect.
--
Michael A. Grady
IAM Architect, Unicon, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20170516/a3df6a05/attachment-0001.html>
More information about the dev
mailing list