Page Comparison

This article describes a proof-of-concept implementation of a metadata early warning system designed to work in conjunction with a Shibboleth FileBackedHTTPMetadataProvider, one of two HTTPMetadataProviders implemented in the Shibboleth IdP FileBackedHTTPMetadataProvider.

Contents

...

The rest of this article assumes you have configured a FileBackedHTTPMetadataProvider in the Shibboleth IdP. The backing file will be used as a source of (trusted) metadata:

...

1. Requires the @validUntil attribute to exist and ensures that its value is in the future but not too far into the future

2. Requires the @creationInstant attribute to exist and ensures that its value is in the past

3. Warns if the metadata is soon-to-be-expired
4. Warns if the metadata is stale (but not soon-to-be-expired)

...

Now try the following experiments:

1. Assuming the Validity Interval is in fact 14 days, set Set maxValidityInterval to something less than the actual length of the Validity Interval and watch the process fail: an error message will be logged and the metadata will be removed from the pipeline.

2. Set maxValidityInterval to something more than the actual length of the Validity Interval and watch the process fail: a warning message will be logged.

3. Again assuming Assuming the actual Validity Interval is 14 days, set maxValidityInterval to something more the subintervals to overlapping values (say, -E P3D -F P12D) and watch the process fail: a warning message will be logged.
   

4. Set the freshnessInterval to some ridiculously small value (like PT60Ssay, -F PT60S) and watch the process fail: a warning message will be logged.

5. Set the expirationWarningInterval to some ridiculously large value (relative to the actual Validity Intervalsay, -E P13D -F PT60S) and watch the process fail: a warning message will be logged.

Once When you've confirmed that the early warning system is behaving as expected, continue with the following configuration steps.

...