The information on this page has been superseded and should be regarded as historical. For most purposes, you should use the current edition of this document instead.
4 Metadata
The federation publishes metadata describing participating entities. This metadata provides the information required for entities to know how to communicate with each other, and establishes a trust fabric permitting entities to verify each other’s identities.
Note, however, that presence in the federation metadata alone should not be taken to imply particular behavioural guarantees. In particular:
-
it is the responsibility of each identity provider to establish appropriate policies for attribute release based on their knowledge of individual service providers;
-
it is the responsibility of each service provider to decide how much trust to place in the attributes presented by an identity provider based on their knowledge of the individual identity provider.
4.1 Production Metadata Aggregate
The UK federation’s metadata format and conventions are described in detail in [UKFTS].
The production metadata aggregate can be retrieved from the following location:
http://metadata.ukfederation.org.uk/ukfederation-metadata.xml
4.2 Metadata Refresh
The metadata published by the federation is regularly updated to include new entities, to describe changes to existing entities, and to remove old entities either because they have left the federation or because the entity has been reported as compromised.
Entities working with old copies of the federation metadata may therefore be unable to communicate with new federation members, be unable to communicate with members whose details have changed, and be vulnerable to attacks based on compromised entities. For these reasons, all federation members are strongly recommended to refresh the metadata used by their entities on a regular basis. A daily refresh operation should be regarded as normal.
Entities should not refresh metadata more than four times a day unless they make use of conditional GET (see [UKFTS] section 4.3, “Support for Conditional GET”) to reduce the impact on the federation metadata servers.
Metadata refresh involves the following steps:
-
retrieving the revised metadata from the publication location given above,
-
verifying the authenticity of the revised metadata (see next section),
-
replacing the metadata in use by the entity.
Most current federated identity software in use within the UK federation provides integrated functionality combining all three of these steps.
Users of other software may make use of the xmlsectool application provided by
the Shibboleth project.1
4.3 Metadata Signature Verification
The security and reliable operation of each entity in the federation depends on using metadata which is both recent and authentic. The former requirement is met by regular metadata refresh, as described above; authenticity of the metadata is assured by verifying the digital signature on each downloaded metadata file before using the metadata.
The current signing certificate for the federation can be retrieved as a Base64-encoded X.509 certificate suitable for use with most current software from the following location:
http://metadata.ukfederation.org.uk/ukfederation.pem
Important note: the security of each federation member depends on the use of authentic metadata. In order to be sure that the metadata signature verification is being properly performed, it is first essential to verify that the correct signing certificate is being used in the verification operation. This may be achieved by checking the certificate’s fingerprint “out-of-band”, for example through a telephone call to the federation operator. It is not safe to assume that the certificate downloaded from the above location is itself authentic without performing this additional step.
We recommend that each federation member verifies the fingerprint of the federation signing certificate through a telephone call to the federation operator. The SHA-1 fingerprint of a Base64-encoded certificate can be obtained on many systems using the following command:
openssl x509 -noout -fingerprint -sha1 -in ukfederation.pem
For additional security, you can generate a fingerprint using the SHA-256
algorithm by replacing -sha1 with -sha256 in the above command.
If you are unable to contact the federation operator directly, you can obtain a lower level of assurance as to the integrity of the downloaded certificate by comparing its fingerprints against the values given below. Note that the federation has used several certificates to represent the same key over time; any of these certificates are acceptable to the Shibboleth software, but the fingerprints do differ. Users of non-Shibboleth software may need to make use of the most recent version of the signing certificate.
The fingerprints for the version of the signing certificate in use from November 2014 are:
SHA1: AD:80:7A:6D:26:8C:59:01:55:47:8D:F1:BA:61:68:10:DA:81:86:66
SHA256: 89:E5:40:74:AA:05:48:73:BF:A1:41:E8:67:5A:45:31:
C9:13:5B:6E:F3:B6:A7:49:DE:7B:B8:62:92:9D:8B:17
The fingerprints for the version of the signing certificate in use from November 2012 until November 2014 are:
SHA1: F9:7F:1A:1E:43:D3:D5:41:6D:C9:D5:0E:3B:6E:8F:5B:97:6C:4B:2E
SHA256: BB:9F:84:9F:F5:BB:F1:A2:97:EA:F4:0D:F1:EF:E9:89:
34:38:6F:7E:FC:B7:0D:84:E1:F6:40:9E:E6:08:18:B7
4.4 Federation URI
The following URI is used as the Name attribute of the outermost EntitiesDescriptor element in the federation metadata:
http://ukfederation.org.uk
This federation URI may be used to refer to the federation as a whole.
Use of the federation URI as a relying party identifier in attribute release policies (as is possible, for example, with the Shibboleth software) is NOT RECOMMENDED. Amongst other issues, use of the federation URI in this way assumes that the entity consumes an aggregate containing all of the federation metadata, and therefore prevents a transition to query-based metadata acquisition (see the Future Directions section for the Metadata Publication Service in [UKFTS]).
The federation URI should never be used in attribute release policies relating to personally identifying information (PII). For attributes which do not constitute PII, consider releasing to all authenticated relying parties instead.
4.5 Future Directions
4.5.1 Attribute Requirements for Service Providers
The SAML 2.0 metadata specification ([SAML2Meta]) enables the federation operator to publish details of the attributes used by service providers directly in the metadata. This will allow the service provider to announce the attributes it requires for basic operation and those it makes use of to provide additional services (e.g., user personalisation).
This facility is being investigated with a view to publishing the attribute requirements of service providers directly in the federation metadata.