This post documents SAFIRE’s experiments with, and ultimate deployment of, a smartcard-based HSM for SAML metadata signing in the hope that we can help other emerging federations along the way. …

On January 30, SAFIRE generated a new metadata signing key which will be used to sign all of the Federation’s metadata aggregates. …

These instructions are based on the Shibboleth documentation and have not been extensively tested. If you use Shibboleth IdPv4, please feel free to submit revisions if necessary. The Shibboleth Identity Provider has good documentation, and so this is not a complete/worked example of how to configure it. Instead this provides the SAFIRE-specific snippets you may need when working through that documentation. Configuring a metadata provider to fetch SAFIRE metadata The Shibboleth Identity Provider provides a FileBackedHTTPMetadataProvider that allows you to periodically fetch metadata. You should use this to keep SAFIRE’s metadata up-to-date, checking for new metadata at least once a day (the example below checks every four hours). …

Identity provider proxies allow the hub-and-spoke federation to appear as a full mesh, at least for the purposes of IdP discovery. This means that service providers can make use of local discovery and see a list of individual SAFIRE identity providers rather than seeing a single entry for the whole federation. In turn, this eliminates the “double discovery” problem for service providers that use local discovery to select amongst a number of different federations (e.g. sites that use DiscoJuice or derivatives). Instead of clicking through two discovery interfaces (local to select the federation, central to select the IdP), end users can select their identity provider directly at the SP. …

To aid providers in preparing new metadata for the transition, we’ve developed a simple online SAML metadata validation tool. This tool applies very similar rules to SAFIRE’s metadata aggregator. The tool is not intended to be normative (we may accept metadata that the validator finds problematic or vice versa). Instead it is intended to allow providers to get early feedback on potential problems with their metadata. You can access the metadata validator at https://validator.safire.ac.za/. …

Metadata is the basis of trust in any federation, and this makes the key management practices for metadata signing particularly important. In response to suggestions from other federation operators, we’ve decided to try and get this “right” from the beginning — at least as far is actually practical for a small federation in its early stages. And “right” means that we should store our metadata signing key in some form of hardware security module. …

SAFIRE is in the process of transitioning, both in architecture (from full-mesh to hub-and-spoke) and governance (from the SCA to TENET). The purpose of this post is to provide more detail on the transitional arrangements. …

SAFIRE is currently transitioning from a full-mesh federation to a hub-and-spoke federation. As we change architectures, we will be asking all participants to re-submit their metadata. The current metadata has known errors, and so we want to ensure we don’t inadvertently port any others. We will instead apply the prevailing metadata registration practice statement at the time of the transition. The identity- and service provider lists shown on this website are generated automatically from the underlying metadata and, at the time of writing, reflect the metadata from the full-mesh federation. As we transition architectures, these lists will be emptied and will then slowly be repopulated as we take on new metadata. This is expected behaviour and is not intended to prejudice any participant(s). …