Signing metadata

Cantor, Scott cantor.2 at osu.edu
Wed Jun 21 13:39:00 EDT 2017


On 6/21/17, 1:27 PM, "users on behalf of Larissa Riedel" <users-bounces at shibboleth.net on behalf of larissa.riedel88 at gmail.com> wrote:

> thanks for the help! So generating and signing the metadata on the fly is only feasible for testing environments and in production
> environments the SP and IdP Metadata should be distributed from static files?

They don't have to be static, they do have to be decoupled from the actual configuration of a system.

> Would you mind giving me a more in depth explanation why that gap is necessary? Unfortunately I don't understand the
> reasoning.

The most prevalent use case for automated metadata exchange is changing a key. The SP has no facility for adding a key at runtime that doesn't end up in the generated metadata, or including a key in the metadata before it gets into the runtime. Part of the process for changing a key involves a guarantee that a key won't get used until after the metadata change propagates or a guarantee that the key can be used before it ends up in the metadata. By definition then, you can't use metadata for the most important thing it's meant to be used for in an automated situation if you generate it with no intervening gap or you'll end up with an outage.

> To verify my understanding: The usual way would be that the "federation" retrieves the static metadata of all SPs and IdPs every
> X hours, verifies each of them and then creates the federation metadata file and sign it?

Most federations rely on a manual process of operators registering changes to their metadata via strongly authenticated access. The propagation of the changes is automated, not the receipt of the changes.

 -- Scott




More information about the users mailing list