Page History

The above method of loading eduID.at metadata from a remote URL is secure only because the eduID.at metadata is regularly signed cryptographically ( and each signed copy contains an expiration date in the near future (days to few weeks) and signatures on that metadata are automatically verified with a trusted key before accepting the metadata in the configuration presented above configuration. Loading any other metadata over the network automatically is not secure: Metadata Among other things metadata contains protocol endpoints where an IDP would send personal data to (which should be inspected and verified by a human before use, the way this has been done for the eduID.at metadata by the ACOnet Team) as well as cryptographic keys that will be used to secure protocol messages exchanged later. But if you automatically imported cryptographic keys over the network that are later used to verify protocol messages exchanged over the network there's no trust anchor and therefore no security in that: That'd be like automatically regularly importing X.509/TLS Certificate Authority certificates over the network and blindly trusting the content of what you've imported to verify the authenticity and integrity of other protocol messsages. I.e., using SAML with remote, unsigned metadata (or not validating signed remote metadata with a previously established, trusted key) is simply Security Theatre!

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) or , listing the correct/preferred NameIDFormat, in , 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).

Reloading the Metadata service as shown immediately below is only necessary in order to activate changes to your /opt/shibboleth-idp/conf/metadata-providers.xml configuration, not for changes to the metadata itself. So ideally you'd do this only once and be done with it. If you find youself adding new MetadataProviders all the time (e.g. one for each new SAML SP you intend to add) you're probably Doing It Wrong™ and should consider the alternative alternatives documented here.