<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div id="compose-container" style="direction:ltr"><span><span></span></span>
<div>
<div style="direction:ltr">Thank you very much Peter. I now have better understanding of why it's included. </div>
<div><br>
</div>
<div style="direction:ltr">-Venki</div>
<div><br>
</div>
<div class="acompli_signature">Get <a href="https://aka.ms/o0ukef">Outlook for iOS</a></div>
</div>
</div>
<br>
<br>
<br>
<div class="gmail_quote">On Thu, Apr 27, 2017 at 5:15 PM +0800, "Peter Schober" <span dir="ltr">
<<a href="mailto:peter.schober@univie.ac.at" target="_blank">peter.schober@univie.ac.at</a>></span> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div dir="3D"ltr"">
<pre>* Kannadasan Venkatachalam [2017-04-27 10:06]:
>
>
> 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
--
To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net
</pre>
</div>
</blockquote>
</div>
<hr>
<font face="Arial" color="Gray" size="2">CONFIDENTIALITY: This email is intended solely for the person(s) named and may be confidential and/or privileged. If you are not the intended recipient, please delete it, notify us and do not copy, use, or disclose its
contents.<br>
Towards a sustainable earth: Print only when necessary. Thank you.</font>
</body>
</html>