Best Practices for "Static" Metadata

[Cantor, Scott]

On 5/6/20, 3:49 PM, "users on behalf of David Wen Riccardi-Zhu" <users-bounces at shibboleth.net on behalf of davidwen.riccardizhu at gooduncle.com> wrote:

> What is considered the best practice when moving to "static" (not-generated) Metadata?

The best practice and the only use case we focus on is third party federated trust by brokering metadata through federations that authenticate it and distribute it under a signature, which is what constitutes the PKI that was meant to be used with SAML (in the sense that there are no others that actually work and also have meaningful security properties).

Doing this bilaterally is really outside our purview. Whatever you do, you cannot derive metadata from an active and live configuration without making key rollover nearly impossible to do correctly. That's the point of the comment. Metadata is what you need people to know ahout a deployment ahead of time, not what the deployment is doing in real time.

As an IdP operator, I don't have bilateral remote metadata, I load it statically after satisfying myself of its accuracy, and I have to deal with the fallout from key changes when they happen. In practice, so few vendors manage key changes properly, and so few of their customers could rely on metadata for it anyway, that they have to advertise changes in a way that allows me to manually deal with it.

>  Could I place my metadata.xml inside /var/www/html/shibboleth/

You can do literally anything you want. It's an XML file; there's nothing special about it once you lose the ability to secure it properly with a third party key, and it doesn't matter where it lives or that anything else happens to resolve to it. Some people obviously put great store in TLS and being able to "validate" the metadata about something based on what host they get it from, but that's certainly nothing to do with the path to the file, only the host.

> If this is a correct approach, should I set my entityID to reflect the location of the Metadata

There is no particular reason to do that; trust cannot be dynamic via magically resolving URLs to documents, or it's meaningless.

The Shibboleth convention of tacking /shibboleth on the end if the entityID is not good either but it's just a long tradition. EntityIDs should be stable, clearly owned and controlled, and representative. That's all that really matters. What they resolve to is not even a blip on the importance scale.

-- Scott