metadata Archive

Configuring Shibboleth Identity Provider for SAFIRE

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.

Technical update: IdP proxies

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.

Metadata validation tool

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.

Technical update: HSM for metadata signing

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.

Metadata refresh during transition

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.

South African Identity Federation