<div dir="ltr">I already proposed them to have their own trusted URL and upload our Meta data, still they have not come back to me.<div><br></div><div>However provided from IdP end, if I update the meta data of our IdP as a practice (say manually) after each change and make sure it is up to date. What risk it carries? because it is update to date and https URL serves from that updated file</div><div><br></div><div>Ok with all this,  if this meta data URL is not encouraged, why not we fully block  https://<server>/idp/shibboleth instead of rendering old content as the default behavior.</div><div><br></div><div>For whatever the reason (technical/business), this is not the only client coming to us with this need or URL driven meta data retrieval.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 12, 2019 at 8:14 PM Peter Schober <<a href="mailto:peter.schober@univie.ac.at">peter.schober@univie.ac.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">* Lalith Jayaweera <<a href="mailto:ljayaweera@gmail.com" target="_blank">ljayaweera@gmail.com</a>> [2019-04-12 05:55]:<br>
> However, only way they can access our IdP meta data is via a URL, no<br>
> any other way.<br>
<br>
What Rod said.<br>
<br>
If they can validate xmldsig signatures on signed metadata *and*<br>
you're prepared to regularly sign[1] your metadata for that SP to<br>
consume then you "just" push the validUntil date on that metadata into<br>
the future (say, 5-10 days) and re-sign and re-publish that metadata<br>
every day to a URL of your choosing where the SP can fetch it from.<br>
<br>
Failing either (or both) of those conditionals I'd suggest to the SP<br>
to host the metadata on a URL of their own, i.e., on an internal,<br>
trusted server of theirs. Maybe even a file:// URL would work.<br>
Then you just send them updates (i.e., static snapshots of your<br>
metadata) via email (or whatever) every couple of years and they<br>
update the local file's content.<br>
<br>
Failing that I'd probably arrange for a test with the SP to see how<br>
their metadata consuming process reacts to incorrect TLS parameters on<br>
HTTPS hosted metadata. If all tested TLS error conditions successfully<br>
prevent the SP from ingesting the metadata that may be sufficient<br>
(until they update some part of their software stack and this security<br>
check is silently replaced with "nothing". Though to be fair that<br>
would also be possible with xmldsig validation.)<br>
<br>
Failing that -- no signature validation, no local file URLs, no<br>
reliable TLS failures in error conditions -- use of SAML and exchange<br>
of cryptographically secured protocol messages becomes somewhat of a<br>
security theatre since the trust anchor (securing all those protocol<br>
messages) is open to abuse:<br>
By dyamically importing (and blindly trusting) cryptographic keys and<br>
endpoints from a plain text file they automatically load over the<br>
internet they open themselfs up to malicious parties impersonating<br>
your IDP and doing nefarious things with your data or misusing the<br>
services at the SP in your name.<br>
<br>
-peter<br>
<br>
[1] There are Free/Libre tools for that, e.g. samlsign, XmlSecTool and<br>
    MDA (all from the Shibboleth project) or pyFF.<br>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div>