metadata early warning system

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

metadata early warning system

Tom Scavo
TL;DR Looking for feedback on a proof-of-concept implementation of a
metadata early warning system:
https://wiki.shibboleth.net/confluence/x/CgDKAg

The implementation consists of a metadata filter written in bash.
Essentially the filter is a superset of the Shibboleth
RequiredValidUntil metadata filter. Like the RequiredValidUntil
filter, the bash filter rejects metadata that never expires or for
which the validity interval is too long. In addition, the filter
ensures that the metadata is associated with a @creationInstant
attribute. This allows the filter to warn if the metadata is stale,
long before the metadata expires.

Unlike the RequiredValidUntil filter, the bash filter is intended to
run every time a metadata refresh is attempted, whether or not fresh
metadata is pulled down from the server. To simulate this behavior,
the bash filter relies on the backing file of a
FileBackedHTTPMetadataProvider as its metadata source.

As a side effect, the filter persists the values of the
@creationInstant and @validUntil attributes to a log file. It then
converts a portion of the log file to JSON. The data in the JSON file
are sufficient to construct a time-series plot, examples of which are
shown in the wiki article:
https://wiki.shibboleth.net/confluence/x/CgDKAg

Feedback is welcome.

Tom
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: metadata early warning system

Cantor, Scott E.
My general feeling is that if there's a logging deficiency in noting refresh failures clearly enough, or impending expiration or whatever, we should get that corrected, I think that's more useful than going outside the system to come up with something that generally isn't a problem in most cases.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: metadata early warning system

Tom Scavo
On Mon, Apr 2, 2018 at 2:29 PM, Cantor, Scott <[hidden email]> wrote:
> My general feeling is that if there's a logging deficiency in noting refresh failures clearly enough, or impending expiration or whatever, we should get that corrected

Okay. I'm not sure if I should continue the discussion here or in
jira. First let me try to clarify:

Support for @creationInstant implies a bit more than improved logging.
I think it boils down to these three items:

1) Modify the behavior of boolean attribute
MetadataProvider/@requireValidMetadata: If @creationInstant exists and
is in the future, the metadata is not valid

2) Add attribute MetadataProvider/@freshnessInterval (to complement
@expirationWarningThreshold, which is misnamed [1])

3) Add filter MetadataProvider/RequireTimestamps (or add a boolean
attribute to the RequiredValidUntil filter) that requires
@creationInstant in addition to @validUntil

Items (1) and (2) are straightforward but item (3) may require a bit
more effort, I don't know.

> I think that's more useful than going outside the system to come up with something that generally isn't a problem in most cases.

HTTP conditional requests give the illusion the file has changed so
you wouldn't know if there's a problem until it's too late. The only
way to know for sure is to parse the metadata.

Thanks,

Tom

[1] https://issues.shibboleth.net/jira/browse/OSJ-236
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: metadata early warning system

Cantor, Scott E.
On 4/5/18, 10:13 AM, "dev on behalf of Tom Scavo" <[hidden email] on behalf of [hidden email]> wrote:

> 1) Modify the behavior of boolean attribute
> MetadataProvider/@requireValidMetadata: If @creationInstant exists and
> is in the future, the metadata is not valid

That would not be appropriate since the definition of valid metadata doesn't involve that attribute. We also don't change the meaning of existing settings, pretty much ever. Which would mean yet more settings, which I'm opposed to.

> 2) Add attribute MetadataProvider/@freshnessInterval (to complement
> @expirationWarningThreshold, which is misnamed [1])

I think more settings is a bad direction.

I'm also much more concerned about the limitations I've identified in the dynamic plugins to worry about aggregates. Until those issues are dealt with, there shouldn't be more time spent on the old way of doing things.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: metadata early warning system

Tom Scavo
On Thu, Apr 5, 2018 at 10:27 AM, Cantor, Scott <[hidden email]> wrote:
> On 4/5/18, 10:13 AM, "dev on behalf of Tom Scavo" <[hidden email] on behalf of [hidden email]> wrote:
>
>> 1) Modify the behavior of boolean attribute
>> MetadataProvider/@requireValidMetadata: If @creationInstant exists and
>> is in the future, the metadata is not valid
>
> That would not be appropriate since the definition of valid metadata doesn't involve that attribute.

If @creationInstant is allowed to be in the future, then it is a
useless piece of metadata and that's the end of it.

>> 2) Add attribute MetadataProvider/@freshnessInterval (to complement
>> @expirationWarningThreshold, which is misnamed [1])
>
> I think more settings is a bad direction.

If I had to choose one, I'd choose @freshnessInterval for sure. The
other one is much less useful. By the time an expiration warning is
issued, it is too late.

> I'm also much more concerned about the limitations I've identified in the dynamic plugins to worry about aggregates. Until those issues are dealt with, there shouldn't be more time spent on the old way of doing things.

I understand your concern about dynamic metadata but that is
orthogonal. Everything I've said so far applies to entity metadata as
well.

Without @creationInstant, a metadata issuer can work around the
validity check in RequiredValidUntil. Suppose
maxValidityInterval="P14D". On day #1, the issuer creates N files with
identical content:

File 1: valid until day #14
File 2: valid until day #15
File 3: valid until day #16
etc.

On day #1, the issuer publishes file #1; on day #2, the issuer
publishes file #2; and so forth. Since all the files are identical (in
content), the issuer has quietly subverted the trust model. To prevent
this, the filter should compute the difference (@validUntil -
@creationInstant) and ensure this quantity does not exceed
maxValidityInterval.

Tom
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: metadata early warning system

Cantor, Scott E.
On 4/5/18, 11:37 AM, "dev on behalf of Tom Scavo" <[hidden email] on behalf of [hidden email]> wrote:

> If @creationInstant is allowed to be in the future, then it is a
> useless piece of metadata and that's the end of it.

There are no mandatory semantics for that attribute, it's informational. Has nothing to do with validity. It's not NotBefore.

> Suppose
> maxValidityInterval="P14D". On day #1, the issuer creates N files with identical content:

That's impossible since validUntil is an absolute time; those files would all be different. There is no validity computation that isn't based on an absolute time comparison.

If somebody signed ten different files whose validUntil was fixed, so the file was identical, time only moves forward and if the original metadata file was acceptable on day 1, it would remain acceptable on day 10 with a shorter window.
 
-- Scott


--
To unsubscribe from this list send an email to [hidden email]