Metadata file comment text

[Peter Schober]

* Kannadasan Venkatachalam <venki at ntu.edu.sg> [2017-04-27 10:06]:
> <!--
> This is example metadata only. Do *NOT* supply it as is without review,
> and do *NOT* provide it in real time to your partners.
> -->
> 
> Does the red text mean we should not be providing this link for
> access?

Not for anything other than maybe taking a snapshot of the metadata
and republishing that in other ways.

> Can someone please advise why this line is included and what are we
> supposed to check?

You would have to understand the issues involved in order to make that
safe. So it's easiest to say "Don't do that", though a reference to a
wiki page detailing the Why wouldn't hurt.

There are least two unrelated issues here:

Trust management[1], i.e. the question how/why someone else should
trust endpoints and crypographic keys from a text file downloaded
automatically over the Internet.

Now you may decide that relying on TLS alone is sufficient for this,
but do you know all the failure modes of the TLS and HTTP libraries in
use at every relying party consuming your metadata?
(Think about the many ways graphical web browsers today are trying to
signal a degradation or reduced/broken trust in TLS connections -- can
you be absolutely certain automatically downloading metadata will fail
at the relying parties' systems if something is not OK with TLS?)

The alternative to relying on TLS is signing the metadata itself. But
why should a metadata consumer trust a signature of your own, claiming
that your own metadata is legit?
So for that to make any sense the signature would have to come from
someone else, usually a trusted third party the metadata comsumer is
willing to rely on (e.g. what we call a federation operator). But with
third party-signed metadata often it's also the third party that's
hosting the signed metadata -- mostly because that's easier to do than
getting the third party-signed metadata hosted at the end entity
(i.e. at your SP).


The *other*, unrelated, issue is about decoupling the internals of
your current system configuration (automatically reflected in the SP's
autogenerated metadata) from what you want metadata consumers to see
at a given point in time. E.g. you might have several keys configured
to decyrpt incoming SAML protocol messages but you'd only like to
publish one of those at some point, usually during key rollover.
It's not unthinkable to create software configuration that takes all
this into consideration (e.g. SimpleSAMLphp does this, IIRC) but I'm
not sure the Shib SP currently offers this.

HTH,
-peter

[1] https://wiki.shibboleth.net/confluence/display/CONCEPT/TrustManagement