...
If you don't refresh your metadata regularly, it is likely your software implementation will fail at some point since the XML document carries an expiration date (validUntil) that causes the metadata to expire in three weeks. InCommon strongly recommends that you do not rely on the length of this validity interval in any way, and in fact, we reserve the right to shorten the validity interval with little or no notice.
...
Firewall Configuration
Depending on your environment, you may have to poke a hole in a firewall to get metadata refesh to work. In that case, you will actually want to poke two holes in that firewall since there are two metadata servers as described below.
...
Participants should validate this certificate in whatever manner is deemed appropriate. Once this certificate file is locally installed, you can use it to verify the signature on the metadata file in conjunction with the refresh process.
Expiry Verification
Federation metadata is also limited in validity period, much as a certificate or certificate revocation list would be in a PKI-oriented system. It is important that expired metadata not be accepted, but it is equally important that metadata without a validUntil attribute on the root element also not be accepted.
Such metadata, if properly signed, could be used by an attacker in conjunction with the prevention of proper metadata refresh, and older InCommon metadata from the early years of the federation lacks an expiration. A metadata reload process should check for and ensure that a validUntil attribute is present, and reasonable, before accepting the metadata.
Software Configuration
If you plan on using the Shibboleth software for the purposes of federation, you can in fact also use Shibboleth to download and verify the signed metadata without having to rely on any other tools. Regardless of your implementation, however, you can always set up a cron job to refresh your metadata, but in that case you will also need a tool to verify the XML signature at the time of refresh.
...