Status of the SP's Metadata Generation Handler

[Sander Maijers]

Hi Peter,

I asked as I'm wondering what Shibboleth developers think of the current
status of the Metadata Generation Handler.

On Wed, Oct 21, 2015 at 5:01 PM, Peter Schober <peter.schober at univie.ac.at>
wrote:

> * Sander Maijers <s.n.maijers at gmail.com> [2015-10-21 16:54]:
> > What is the reasoning behind the fact that the warning at the top of
> > generated SAML metadata produced by the Metadata Generation Handler
> cannot
> > be removed (at least, apparently)?
>
> First and formost, an unsigned SAML Metadata document is just a plain
> text file. Noone should be bootstrapping trust in endpoints and
> crypographic material (public keys) based on automatically downloading
> (and regularly re-downloading) plain text files over the Internet.
>

What do you mean with this comment? Whether XML data is signed or not has
no influence on its syntax (XML vs. plain) or confidentiality (encrypted
vs. plain). I take it you refer to the authentication and message integrity
of the communication channel when one uses the Metadata Generation Handler
as primary source of SAML metadata about an SP.

First of all, out-of-band SAML metadata distribution is not by definition
secure or more secure than this. In fact, I've never seen anyone do
something close to thorough out-of-band authentication of providers of SAML
metadata batches. Out-of-band SAML message integrity checking using signed
SAML metadata batches is the main alternative I suppose you're preferring.
It follows that using the Metadata Generation Handler does not of necessity
lower authentication and/or message integrity security compared to the
alternative. Moreover, there is no fundamental reason why the Metadata
Generation Handler could not put out signed SAML metadata in a way that
does not increase DoS risk, even if that would not be the case for
Shibboleth SP at this time. In the meantime, there are of course many other
security mechanisms available to deliver authentication and message
integrity, insofar needed. E.g. TLS, DNSSEC and pinning.


> Also, this handler mirrors the current software configuration, but
> sometimey you need current configuration to be different from
> published SAML Metadata. E.g. during key rollover you might want to
> configure support for a new key in the software without immediately
> publishing that key.
>

Why? Of course it depends on the consumer of SAML metadata from the
Metadata Generation Handler endpoint how quick it is subsequently
processed, and on what basis SAML metadata mutations will be accepted. It
seems that the current warning and your opinion does not consider the full
possible context of circumstances. The warning I ask about says:

> This is example metadata only. Do *NOT* supply it as is without
> review, and do *NOT* provide it in real time to your partners.


This wording implies that this metadata has by definition the status of
‘example’ metadata, which does not do justice to the fact that the metadata
may in fact have been carefully reviewed and generated from a sufficiently
complete template. Secondly, whether an SP provides it ‘in real time’ is
disconnected from the question whether it will be consumed immediately or
unchecked by partners.


> Finally, the provided Metadata will almost certainly be incomplete,
> i.e., you will need to add more data to it before publishing.
> Stuffing all of that into the SP software only that a built-in
> web-server can push it our again does not make a lot of sense.
>

What would be missing if you use a complete template?


> -peter
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>

Best,
Sander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20151021/f3f70b8e/attachment.html>