The Incommon Federation wiki has moved.

Please visit the new InCommon Federation Library wiki for updated content. Remember to update your bookmarks.

Click in the link above if you are not automatically redirected in 15 seconds.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 25 Next »

The InCommon Federation metadata is published at the following location:

InCommon expects participants to refresh metadata daily to ensure that SAML endpoints have access to the most up-to-date keys and other registered information. Some software implementations (such as Shibboleth) handle metadata with ease, but regardless of your software, please read this entire page to understand the requirements and pitfalls associated with metadata consumption.

It is strongly recommended that InCommon SPs and IdPs refresh and verify metadata at least daily.

Participants are strongly encouraged to rely on SAML software that properly handles metadata; failure to do so can have profound effects on the successful use of the Federation. In addition to maintaining the security of your own deployment, proper metadata use is critical to ensure that other participants can depend on your system behaving correctly when they make changes.

In addition, if you don't refresh your metadata regularly, it is likely that a 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 actual 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 an outbound 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.

Hostname resolves to one of two identical servers, either in Michigan ( or Indiana ( The actual server used at any given point in time is unspecified and left to the discretion of InCommon Operations. If one of the servers goes down or requires maintenance, the other can be brought up within minutes, with minimal disruption of services.

Therefore, please make sure both your SAML implementation and your metadata refresh processes are configured with hostname (as opposed to an IP address). On the other hand, make sure your outbound firewall (if any) is configured with both IP addresses ( and

Signature Verification

Federation metadata is signed for integrity and authenticity. Participants are strongly encouraged to verify the XML signature on the metadata file before use; failure to do so will seriously compromise the security of your SAML deployment.

To bootstrap the trust fabric of the Federation, participants are required to download the following certificate, which contains the public key corresponding to the Federation's private metadata signing key:

You may check the integrity of the downloaded certificate in a variety of ways. For example, you could use openssl after the fact as follows:

$ openssl x509 -sha1 -in incommon.pem -noout -fingerprint
SHA1 Fingerprint=74:27:8F:96:7C:F1:BF:CA:AA:1B:41:AF:B6:33:64:48:A2:15:0E:B4

Once the certificate file is locally installed, you can use it to verify the signature on the metadata file. For example, you could use the XmlSecTool (or some similar 3rd-party tool) to verify the signature: --verifySignature --signatureRequired \
    --certificate incommon.pem --inFile InCommon-metadata.xml

You may also want to schema validate the metadata: --validateSchema \
    --schemaDirectory schema-files --inFile InCommon-metadata.xml

For convenience, we provide a set of (suitably modified) schema files that permit offline schema validation.

Expiry Verification

Federation metadata has an expiration date, much like an X.509 certificate. It is important that expired metadata not be accepted, otherwise an attacker would be able to substitute expired metadata in conjunction with a metadata refresh. In particular, a metadata file should not be accepted if either of the following conditions are true:

  1. If the metadata file does not have a validUntil attribute on the root element.
  2. If the validUntil attribute on the root element is expired.

A metadata reload process should check each of the above conditions before accepting the metadata; alternatively if your SAML implementation is known to ignore/reject expired metadata (a basic correctness requirement), it may be sufficient to ensure that a validUntil attribute exists and is not unexpectedly far into the future.

Verify the expiration date independently!

Verifying the signature on a SAML metadata file does not verify the presence or value of an expiration date. The only way to verify the expiration date is to parse the XML.

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 software implementation, however, you can always set up a cron job to refresh your metadata, but in that case you will need additional tools to verify the XML signature at the time of refresh and check the validUntil attribute as noted above. Participants are encouraged to share such tools and scripts for the benefit of the community.

Apart from this refresh process, your software implementation needs to be configured to consume InCommon metadata. Exactly how this is done depends on your implementation of course. Instructions how to configure Shibboleth for metadata consumption are provided elsewhere in this wiki. Also, see the resources linked below for related information.

For More Information

  • No labels