Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

Table of Contents

...

First download the bash-library source code. For example, if If you have git installed, you can clone the repository as follows:

...

Next download the saml-library source code by cloning the repository:

Code Block
languagebash
$ git clone https://github.com/trscavo/saml-library.git

...

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:

Code Block
languagebash
titleLocate the backing file
$ idp_home=/path/to/idp/home/
$ backing_file="${idp_home%%/}/metadata/federation-metadata.xml"

...

Federations publish metadata files having with Validity Intervals of various lengths. For the sake of illustration, let’s assume the actual Validity Interval in metadata is two weeks (which is actually in fact quite common):

Code Block
languagebash
titleDefine the max length of the Validity Interval
$ maxValidityInterval=P14D

As described in the story referenced at the beginning of this article, to conceptualize the metadata early warning system, we divide the Validity Interval into three subintervals: the Freshness Interval (bounded on the left by the @creationInstant attribute), the Expiration Warning Interval (bounded on the right by the @validUntil attribute), and a no-name subinterval sandwiched in the middle. That isIn effect, the @creationInstant and @validUntil attributes essentially partition the Validity Interval into GREEN, YELLOW, and RED subintervals, respectively.

...

The partition is determined by the lengths of the Freshness Interval and the Expiration Warning Interval. The choice of subinterval lengths depends on the production signing frequency of federation metadata. If we assume the federation publishes fresh metadata at least once every business day, the following subinterval lengths make sense (but YMMV):

...

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:

  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.

...

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

Persisting the Timestamps

Now let’s modify the above command slightly so that the values of the @creationInstant and @validUntil attributes are persisted to a log file. For startersillustration, we’ll configure a log file in the /tmp directory:

...