What is the advice - meta data retrieval

[Lalith Jayaweera]

I already proposed them to have their own trusted URL and upload our Meta
data, still they have not come back to me.

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

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.

For whatever the reason (technical/business), this is not the only client
coming to us with this need or URL driven meta data retrieval.

On Fri, Apr 12, 2019 at 8:14 PM Peter Schober <peter.schober at univie.ac.at>
wrote:

> * Lalith Jayaweera <ljayaweera at gmail.com> [2019-04-12 05:55]:
> > However, only way they can access our IdP meta data is via a URL, no
> > any other way.
>
> What Rod said.
>
> If they can validate xmldsig signatures on signed metadata *and*
> you're prepared to regularly sign[1] your metadata for that SP to
> consume then you "just" push the validUntil date on that metadata into
> the future (say, 5-10 days) and re-sign and re-publish that metadata
> every day to a URL of your choosing where the SP can fetch it from.
>
> Failing either (or both) of those conditionals I'd suggest to the SP
> to host the metadata on a URL of their own, i.e., on an internal,
> trusted server of theirs. Maybe even a file:// URL would work.
> Then you just send them updates (i.e., static snapshots of your
> metadata) via email (or whatever) every couple of years and they
> update the local file's content.
>
> Failing that I'd probably arrange for a test with the SP to see how
> their metadata consuming process reacts to incorrect TLS parameters on
> HTTPS hosted metadata. If all tested TLS error conditions successfully
> prevent the SP from ingesting the metadata that may be sufficient
> (until they update some part of their software stack and this security
> check is silently replaced with "nothing". Though to be fair that
> would also be possible with xmldsig validation.)
>
> Failing that -- no signature validation, no local file URLs, no
> reliable TLS failures in error conditions -- use of SAML and exchange
> of cryptographically secured protocol messages becomes somewhat of a
> security theatre since the trust anchor (securing all those protocol
> messages) is open to abuse:
> By dyamically importing (and blindly trusting) cryptographic keys and
> endpoints from a plain text file they automatically load over the
> internet they open themselfs up to malicious parties impersonating
> your IDP and doing nefarious things with your data or misusing the
> services at the SP in your name.
>
> -peter
>
> [1] There are Free/Libre tools for that, e.g. samlsign, XmlSecTool and
>     MDA (all from the Shibboleth project) or pyFF.
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190414/9e58bb4a/attachment.html>