Page History

Also note that loading SAML 2.0 metadata from a remote URL – metadata that has not been checked and curated by your trusted local federation operator or by one of our peer federations – may include all kinds of entities, endpoints or requests for personal data you don''t expect at that URL (or stuff that simply wasn't there when you looked at that URL, once)! While there are ways to limit that risk (e.g. by filtering such remote metadata for only the expected entities) often the best way to deal with the underlying issues is to not automatically load such metadata from remove URLs at all. Therefore we document a method below that requires downloading and manually verifying remote metadata once and then putting that checked metadata into a local file (or directory) that's not updated automatically anymore (essentially creating a snapshot of the remote metadata). This way you're trading the security issues of improper metadata exchange for having to manually update those "snapshots" of metadata manually every once in a while when deemed necessary.
As an added bonus locally managing a copy of that remote metadata allows you to tune/fix the metadata so that it reflects the Service Provider's actual requirements (or your deployment preferences with regard to that service), e.g. listing the RequestedAttribute elements you intend to release to that service (and with the right NameFormat), listing the correct/preferred NameIDFormat, add MDUI elements to get a proper service name and logo shown on the IDP login page, and so on, including cases where the metadata provided at the remote URL is incomplete, unsuitable or simply wrong (i.e., always).