...
Tip | ||
---|---|---|
| ||
Open two terminal windows. In one window, execute ‘tail -f $LOG_FILE ’. In the other window, execute the above command. Adjust the LOG_LEVEL environment variable as needed. For example, to invoke DEBUG logging throughout, type ‘export LOG_LEVEL=4 ’ into the command window. Alternatively, apply the -D option to any (or all) of the metadata filters in the pipeline. |
Try Yes the Shibboleth IdP ensures that the metadata is valid, and it will even warn you (optionally) if the metadata is soon-to-be-expired, but the IdP is not aware of the @creationInstant
attribute and therefore it has no notion of a Freshness Interval. OTOH, the early warning system implemented above does all of the following:
Requires the
@validUntil
attribute to exist and ensures its value is in the future but not too far into the futureRequires the
@creationInstant
attribute to exist and ensures its value is in the past- Warns if the metadata is soon-to-be-expired
- Warns if the metadata is stale (but not soon-to-be-expired)
The last step is the essence of the early warning system.
Now try the following experiments:
Assuming the validity interval Validity Interval is in fact 14 days, set
maxValidityInterval
to something less and watch the process fail: an error message will be logged.Again assuming the validity interval is in fact actual Validity Interval is 14 days, set
maxValidityInterval
to something more and watch the process fail: a warning message will be logged.Set the
freshnessInterval
to some ridiculously small value (likePT60S
) and watch the process fail: a warning message will be logged.Set the
expirationWarningInterval
to some ridiculously large value (relative to the actual Validity Interval) and watch the process fail: a warning message will be logged.
Persisting the Timestamps
...