This page introduces important policy and procedures associated with InCommon metadata. Other pages outline the availability of multiple metadata aggregates and provide guidance on how to configure specific metadata clients. General configuration issues, including the configuration of outbound firewalls, are discussed below.
Metadata Refresh Policy
InCommon expects participants to refresh metadata daily to ensure that SAML deployments have access to the most up-to-date keys and other registered information. Some software implementations (such as Shibboleth) handle metadata easily, 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. An optimal configuration would attempt to refresh metadata every hour, assuming your client supports HTTP Conditional GET.
Participants are strongly encouraged to use 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.
The security implications of metadata refresh!
Regular metadata refresh protects users against spoofing and phishing, and is a necessary precaution in the event of key compromise. Failure to refresh metadata exposes you, your users, and other Federation participants to unnecessary risk.
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 two 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.
Metadata Refresh Process
The mechanics of metadata refresh:
- Choose the right metadata aggregate for your particular deployment
- Deploy and configure an automated metadata refresh process:
- Configure your metadata client
- Verify the XML signature on downloaded metadata
- Validate the expiration date on downloaded metadata
- Adjust your outbound firewall rules
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.
The InCommon Federation is based on the Explicit Key Trust Model, one of several possible metadata trust models. To bootstrap the trust fabric of the Federation, participants are required to download and configure the metadata verification certificate into their metadata refresh process:
https://wayf.incommonfederation.org/bridge/certs/incommon.pem
The certificate must be obtained securely since all subsequent operations depend on it. You may check the integrity of the downloaded certificate in a variety of ways. For example, on a GNU/Linux system, you could use curl
and openssl
to check the integrity of the certificate as follows:
# get the metadata signing certificate on wayf.incommonfederation.org via HTTPS # and display the HTTP response header $ CERT_PATH=~/path/to/inc-md-cert.pem $ /usr/bin/curl --silent --dump-header /dev/tty https://wayf.incommonfederation.org/bridge/certs/inc-md-cert.pem > $CERT_PATH HTTP/1.1 200 OK Date: Tue, 17 Dec 2013 22:31:11 GMT Server: Apache Last-Modified: Mon, 16 Dec 2013 21:15:44 GMT ETag: "6077f-4fd-4edad50966000" Accept-Ranges: bytes Content-Length: 1277 Connection: close Content-Type: text/plain; charset=UTF-8 # compute the SHA-1 and SHA-256 fingerprints of the metadata signing certificate $ /usr/bin/openssl x509 -sha1 -in $CERT_PATH -noout -fingerprint SHA1 Fingerprint=7D:B4:BB:28:D3:D5:C8:52:E0:80:B3:62:43:2A:AF:34:B2:A6:0E:DD $ /usr/bin/openssl x509 -sha256 -in $CERT_PATH -noout -fingerprint SHA256 Fingerprint=2F:9D:9A:A1:FE:D1:92:F0:64:A8:C6:31:5D:39:FA:CF:1E:08:84:0D:27:21:F3:31:B1:70:A5:2B:88:81:9F:5B
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:
$ /usr/bin/curl --silent --remote-name http://md.incommon.org/InCommon/InCommon-metadata.xml $ ./xmlsectool.sh --verifySignature --signatureRequired \ --certificate $CERT_PATH --inFile InCommon-metadata.xml
You may also want to schema validate the metadata:
$ ./xmlsectool.sh --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:
- If the metadata file does not have a
validUntil
attribute on the root element. - 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.
Firewall Configuration
Depending on your environment, you may have to poke a hole in an outbound firewall to allow your metadata client to reach the metadata server. In that case, you will actually want to poke two holes in that firewall since there are two metadata servers as described below.
Hostname wayf.incommonfederation.org
resolves to one of two identical servers, either in Michigan (207.75.165.125) or Indiana (140.182.44.53). 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 wayf.incommonfederation.org
(as opposed to an IP address). On the other hand, make sure your outbound firewall (if any) is configured with both IP addresses (207.75.165.125 and 140.182.44.53).