Metadata Aggregation Practice Statement v20170303 (Draft)

SAFIRE generates a number of metadata aggregates for various purposes, including inter-federation and its own internal operations. This document gives a broad overview of how the aggregation process works. It is currently non-normative and will be refined over time.

Metadata aggregator

SAFIRE makes use of WAYF’s PHPH (PHederation PHeeder) metadata aggregation software. An overview of the configuration of this aggregator and the aggregates it generates is publically available at https://phph.safire.ac.za/.

Not all of the aggregates generated by PHPH are intended for public consumption. The definitive source of information about SAFIRE’s metadata is  https://safire.ac.za/technical/metadata/.

SAFIRE Federation Registry

SAFIRE’s internal federation registry serves as an input to the aggregation process. The process for taking entities into the federation is documented in the metadata registration practice statement.

The registry is implemented as a Git repository hosted in a private repository on Github. To ensure that the aggregator functions correctly in the event of an outage, it maintains a cached copy of this repository and collates entities into a private feed. However, a webhook exists to ensure that changes that are pushed into the master repository are automatically pulled by the aggregator when it next runs, thus updating the cache. This means that changes to the federation registry should automatically reflect with aggregates on the next publish.

Publication information

All metadata aggregates generated by SAFIRE make use of the [SAML-Metadata-RPI-V1.0] metadata extension to indicate that SAFIRE is the publisher. The following is a non-normative example

<md:Extensions xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:mdrpi="urn:oasis:names:tc:SAML:metadata:rpi">
  <mdrpi:PublicationInfo creationInstant="2017-03-03T08:00:01Z" publisher="https://safire.ac.za"/>
</md:Extensions>

Signing

All metadata aggregates produced by SAFIRE are signed at publication using XMLDsig with the rsa-sha256 algorithm. A separate key management practice statement details the processes for handling private keys. Details of the signing keys for individual aggregates are available from https://safire.ac.za/technical/metadata/.

Logo caching

To ensure the availability of logos within the federation hub’s user interface (and in particular, on the user consent page) and on discovery pages, the aggregator caches logos specified by [SAML-Metadata-MDUI-V1.0] metadata extensions. The local logo cache is used to replace logo URLs in metadata with their equivalent using the [RFC2397] data: URI scheme.

Only logos whose file size is smaller than 50KiB and whose dimensions are declared as being larger than 48 and smaller than 305 pixels are cached.

The logo cache is inspected during each aggregation run, and cached logos are updated if necessary. Freshness lifetime is calculated from the Expires: and Cache-Control: max-age directives from the logo source in accordance with [RFC7234]. Where the lifetime is not known, requests are made with an If-Modified-Since: header. However, the aggregator does not understand ETags nor does it honour must-revalidate directives.

 Timings

Timing of metadata aggregate generation

Metadata aggregates can be generated either automatically or manually. Routine moves, adds and changes to entities are usually only published by the automated process, as are updates from interfederation.

Automatic metadata aggregate generation is done one once per day, started at 10:00 SAST (UTC+2). The generation time can vary but is typically completed within five minutes.

Manual generation is done on an ad-hoc basis as and when required. This is typically in response to emergency change requests or to correct errors that have been reported in the published aggregates.

Timing of new metadata imports

SAFIRE’s federation hub and identity provider proxies can import new metadata either automatically or manually.New metadata is automatically fetched

New metadata is automatically fetched once an hour, beginning at seven minutes past the hour. Importation time can vary but typically takes no longer than a couple of minutes. In general, you can safely assume that new metadata will be imported by 10 past the hour.

Hosting

Published metadata aggregates are hosted on https://metadata.safire.ac.za/. This web server provides appropriate headers to facilitate caching per [RFC7234].

References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[SAML-Metadata-RPI-V1.0] “SAML V2.0 Metadata Extensions for Registration and Publication Information Version 1.0”, 3 April 2012, OASIS Committee Specification 01. http://docs.oasis-open.org/security/saml/Post2.0/saml-metadata-rpi/v1.0/cs01/saml-metadata-rpi-v1.0-cs01.html.

[SAML-Metadata-MDUI-V1.0] “Metadata Extensions for Login and Discovery User Interface Version 1.0”, 3 April 2012, OASIS Committee Specification 01. http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-ui/v1.0/sstc-saml-metadata-ui-v1.0.html

[RFC2397] Masinter, L., “The ‘data’ URL scheme”, RFC 2397, August 1998.

[RFC7234] Fielding, R., Nottingham, M. & Reschke, J., “Hypertext Transfer Protocol (HTTP/1.1): Caching”, RFC 7234, June 2014.

South African Identity Federation