4 Metadata Publication Service

The UK federation makes metadata available to participants and other partners through its Metadata Publication Service, or MPS.

4.1 Service Implementation

The MPS is implemented using a number of distinct virtual machines across multiple geographic locations. At present, up to four machines are in use across two locations, but these details are subject to change without notice to allow for service scaling and maintenance.

The service is accessed through the DNS name metadata.ukfederation.org.uk, which is a CNAME for the actual infrastructure naming and will, following the DNS chain, resolve to both IPv4 and IPv6 addresses (A and AAAA records). These DNS records have a low time-to-live value (currently 5 minutes) to allow rapid reconfiguration of the service to be performed.

4.2 Metadata Aggregate Publication

The MPS makes available a number of defined aggregates, or aggregated metadata documents. Each of these aggregates may be retrieved using a standard HTTP GET method, as defined in [RFC7231] section 4.3.1.

A MIME media type of application/samlmetadata+xml is reported for all aggregates, as required by [SAML2Meta] appendix A.

4.2.1 Aggregate Locations

The most important of these aggregates is the production aggregate, which is located at the following URL:

http://metadata.ukfederation.org.uk/ukfederation-metadata.xml

The production aggregate is intended to be used by all federation participants under normal circumstances.

From time to time, it is necessary to make significant changes to either the format or content of the production aggregate. To allow testing of such changes before they are implemented in the production aggregate, a test aggregate is maintained alongside it at the following URL:

http://metadata.ukfederation.org.uk/ukfederation-test.xml

The test aggregate is re-signed and re-published in the same way and at the same times as the production aggregate. This is intended to allow sites wishing to make use of the test aggregate to use it as a direct replacement for the production aggregate without loss of functionality or timeliness. However, as the test aggregate may be used to test experimental features, it is not recommended for long-term use by production deployments.

Although the test aggregate is usually composed of metadata for the same entities as the production aggregate, it may from time to time include additional entities of an experimental nature.

Features initially introduced for testing purposes in the test aggregate are periodically migrated into the production aggregate. In most cases, because notice is usually given to allow participants to verify these features through the test aggregate, no problems are encountered at this stage. However, the MPS also maintains a fallback aggregate to cover transitional problems, located at the following URL:

http://metadata.ukfederation.org.uk/ukfederation-back.xml

The fallback aggregate is composed of metadata for the same entities as the production and test aggregates, but omits features that have been only recently introduced to the production aggregate. The delay in introducing new features, normally of around one month, provides a temporary solution for problems which were not detected through use of the test aggregate.

Like the test aggregate, the fallback aggregate is not intended for long-term use by production deployments. Use of the fallback aggregate should always be temporary, and should always be notified to the federation helpdesk.

The MPS publishes an export aggregate, for use by by partner federations as part of inter- federation metadata exchange arrangements, at the following URL:

http://metadata.ukfederation.org.uk/ukfederation-export.xml

Entities are currently selected for inclusion in the export aggregate by agreement between the entity’s registrant and the federation operator. In the longer term, the contents of the export aggregate will be based instead on all entities from the normal aggregates which meet appropriate technical eligibility criteria.

An additional export preview aggregate is made available for use by partner federations wishing to test future changes to the standard export aggregate:

http://metadata.ukfederation.org.uk/ukfederation-export-preview.xml

Use of any other aggregates published by the MPS is not supported.

4.2.2 Aggregate Structure

Aggregate documents published by the MPS currently have a simple “flat” structure in which all <EntityDescriptor> elements in the aggregate are directly contained within a single <EntitiesDescriptor> document element.

The previous edition included the following text, aimed at supporting future “structured” metadata aggregates:

Metadata consumers MUST however be capable of processing aggregates containing nested <EntitiesDescriptor> elements, as described in [SAML2Meta] section 2.

Further study confirmed that this approach was not viable for the foreseeable future, and support for nested aggregates is no longer REQUIRED for use in the UK federation.

4.2.3 Aggregate Signature Profile

The <EntitiesDescriptor> document element of a UK federation metadata aggregate is digitally signed using a 2048-bit RSA key called the UK federation metadata signing key, described in section 4.2.4 below.

The signature profile used for all aggregates makes use of [XMLSig] and the SHA-256 cryptographic hash function (defined in [FIPS180-4]). It results in the following signature elements:

<ds:SignatureMethod
     Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<ds:DigestMethod
     Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>

Current best estimates (see, for example, [SP800-57part1] tables 2, 3 and 4) are that the 128-bit security strength believed to be delivered by SHA-256, and the 112-bit security strength believed to be delivered by the UK federation’s 2048-bit RSA signing key, will be adequate through to the year 2030. A transition to a stronger signature profile is therefore unlikely to be required on security grounds within that period, unless significant new cryptanalytic results are reported against either SHA-256 or RSA.

4.2.4 Aggregate Signing Key

The UK federation metadata signing key is published in the form of an X.509 certificate referred to as the UK federation metadata signing certificate.

Metadata consumers MUST verify an aggregate’s signature against this key and MUST reject an aggregate whose signature cannot be verified. This acts as a protection against attacks in which consumers are provided with fabricated metadata.

Verification of the signature against the signing key SHOULD be performed by direct key comparison as described in [SAML2MIOP]. For the benefit of software which cannot implement [SAML2MIOP] and requires the signing certificate to be taken into consideration, the signing key has been re-certified from time to time and re-published as a new signing certificate. The certificate which comes into use in November 2014 has an expiry date in late 2037, so it is not anticipated that this recertification will be performed again.

The current UK federation signing certificate can be retrieved in Base64-encoded form from the following location:

http://metadata.ukfederation.org.uk/ukfederation.pem

The fingerprints for the version of the signing certificate in use from November 2014 is:

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 to 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

The fingerprint for the version of the signing certificate in use from November 2010 to November 2012 is:

SHA1: 94:7F:5E:8C:4E:F5:E1:69:E7:DF:68:1E:48:AA:98:44:A5:41:56:EE

The fingerprint for the version of the signing certificate in use from November 2008 to November 2010 is:

SHA1: D0:E8:40:25:F0:B1:2A:CC:74:22:ED:C3:87:04:BC:29:BB:7B:9A:40

The fingerprint for the version of the signing certificate in use from November 2006 to November 2008 is:

SHA1: BB:F4:CE:85:7A:BC:8C:7F:5B:44:8F:FE:39:4C:25:BE:EC:B9:08:B4

4.2.5 Aggregate Validity

The document <EntitiesDescriptor> of a UK federation metadata aggregate includes a validUntil attribute defining the last instant during which the aggregate should be considered valid. The validUntil attribute’s value is set at the time of construction of the aggregate to allow a “validity interval” of a certain number of days after the aggregate’s construction. This interval acts as a protection against certain attacks involving replay of old federation metadata containing compromised information.

Metadata consumers SHOULD reject metadata aggregates lacking a validUntil attribute and MUST discard aggregates whose validUntil instant has passed.

In normal operation, the validity interval used for UK federation metadata aggregates is 14 days. This may be varied in either direction for operational reasons, but until further notice will never be less than 7 days nor more than 28 days.

4.3 Metadata Query Publication

As well as publishing metadata for all entities known to the UK federation within a single large aggregate document as described above, the MPS provides the ability to use the Metadata Query Protocol (MDQ) described in [MDQuery] and [MDQuerySAML] to request the metadata for an individual entity. Because most SAML entities only communicate with a relatively small number of others, using MDQ to acquire metadata can dramatically reduce the required bandwidth and memory to operate an entity.

4.3.1 Metadata Query Locations

The Metadata Query Protocol defines operation relative to a base URL (see [MDQuery] section 2.7). The UK federation uses the following base URL:

http://mdq.ukfederation.org.uk/

Metadata for all entities (equivalent to the UK federation’s production aggregate) can be found at a path of “entities” relative to the base URL (see [MDQuery] section 3.2.2):

http://mdq.ukfederation.org.uk/entities

Metadata for individual entities can be found at a path constructed by composing the URL with “entities/” and a URL-encoded form of the entity’s entityID (see [MDQuery] section 3.2.1). For example, metadata for the UK federation’s test identity provider can be found at the following URL (split across two lines for clarity):

http://mdq.ukfederation.org.uk/entities/https:%2F%2Ftest-
        idp.ukfederation.org.uk%2Fidp%2Fshibboleth

The use of a SHA-1 transformed identifier is also supported, as described in [MDQuerySAML] section 2.2.2. For the same entity as above (and again, split across two lines for clarity):

http://mdq.ukfederation.org.uk/entities/{sha1}52e2065f
        c0d53744e8d4ee2c2f30696ebfc5def9

4.3.2 MDQ Response Signature Profile

The <EntityDescriptor> document element of a UK federation MDQ response is digitally signed using a 4096-bit RSA key called the UK federation MDQ response signing key, described in section 4.3.3 below.

The signature profile used for MDQ responses makes use of [XMLSig] and the SHA-256 cryptographic hash function (defined in [FIPS180-4]). It results in the following signature elements:

<ds:SignatureMethod
     Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<ds:DigestMethod
     Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>

Note that, unlike the signature profile used for the UK federation metadata aggregates, the signatures included in MDQ response documents do not include a <ds:KeyInfo> element containing an X.509 certificate wrapping the public key corresponding to the MDQ response signing key. MDQ clients MUST be able to validate MDQ response signatures by direct knowledge of the key to be expected.

The <ds:KeyInfo> element contained in many digital signatures is strictly a convenience so that the client can identify which key the document has been signed with. Because the document itself contains the public key, the client MUST NOT rely on the <ds:KeyInfo> for technical trust.

The UK federation aggregates include a copy of the signing key purely as a convenience; the cost of including this information is very small relative to the size of the aggregate. Including it with each MDQ response — which each represent only a single entity and are therefore much smaller — would constitute a much larger overhead, and the redundant information is therefore excluded.

4.3.3 MDQ Response Signing Key

The UK federation MDQ response signing key is published in the form of an X.509 certificate referred to as the UK federation MDQ response signing certificate.

Metadata consumers MUST verify an MDQ response’s signature against this key and MUST reject a response whose signature cannot be verified. This acts as a protection against attacks in which consumers are provided with fabricated metadata.

Verification of the signature against the signing key MUST be performed by direct key comparison as described in [SAML2MIOP].

The UK federation MDQ response signing certificate can be retrieved in Base64-encoded form from the following location:

http://mdq.ukfederation.org.uk/ukfederation-mdq.pem

The fingerprints for the signing certificate are:

SHA1:   3F:6B:F4:AF:E0:1B:3C:D7:C1:F2:3D:F6:EA:C5:60:AE:B1:5A:E8:26
SHA256: AF:02:B3:2B:00:68:04:1D:D0:C9:F3:EC:01:77:10:F8:
        B7:8B:92:78:15:2F:2B:4E:9C:C4:39:DB:DD:C9:51:3E

4.3.4 MDQ Response Validity

The document <EntityDescriptor> of a UK federation MDQ response includes a validUntil attribute defining the last instant during which the response should be considered valid. The validUntil attribute’s value is set at the time of construction of the document to allow a “validity interval” of a certain number of days after the response’s construction. This interval acts as a protection against certain attacks involving replay of old federation metadata containing compromised information.

Metadata consumers SHOULD reject MDQ responses lacking a validUntil attribute and MUST discard responses whose validUntil instant has passed.

In normal operation, the validity interval used for UK federation MDQ responses is 14 days. This may be varied in either direction for operational reasons, but until further notice will never be less than 7 days nor more than 28 days.

4.4 Support for Conditional GET

The metadata documents provided through the MPS are normally signed and re-published once every working day. Client software accessing the service more frequently than this may therefore end up repeatedly downloading and re-processing large quantities of redundant information, particularly when dealing with the large metadata aggregates.

To allow clients to optimise their behaviour, the service returns both a last modified date and a strong entity tag value, and supports the use of these values with the HTTP conditional GET mechanism described in [RFC7232].

For example, a successful initial fetch of one of the UK federation’s published aggregate documents might result in the following HTTP response headers, amongst others:

HTTP/1.1 200 OK
Date: Fri, 30 Mar 2018 15:57:46 GMT
Last-Modified: Fri, 30 Mar 2018 15:21:06 GMT
ETag: "240b9a3-568a2c9f7bc80"
Content-Length: 37796259
Content-Type: application/samlmetadata+xml

The entity tag and last modified date values returned as part of this initial response could be used as part of a later conditional GET by including the If-None-Match and If-Modified-Since headers in the request:

GET /ukfederation-metadata.xml HTTP/1.1
Host: metadata.ukfederation.org.uk
Accept: */*
If-None-Match: "240b9a3-568a2c9f7bc80"
If-Modified-Since: Fri, 30 Mar 2018 15:21:06 GMT

Note that as described in [RFC7232] section 2.4, both of these headers SHOULD always be sent in a conditional GET to the MPS, as both values were provided to the client in the original response. The entity tag value MUST always be sent.

If the requested document has not changed since the initial request, the response headers resulting from this later request might include the following:

HTTP/1.1 304 Not Modified
Date: Fri, 30 Mar 2018 16:20:56 GMT
Last-Modified: Fri, 30 Mar 2018 15:21:06 GMT
ETag: "240b9a3-568a2c9f7bc80"

Here, the 304 status code indicates that the document has not been modified; in this case, the response body will be omitted.

It is recommended that, where possible, client software designed to access the MPS makes use of conditional GET requests as described above in order to minimise both local processing and load on the service.

4.5 Support for Compression

SAML metadata, as an XML document format, tends to be bulky but repetitive. One result of this is that most SAML metadata documents are capable of being compressed at a ratio of between roughly 3:1 and 5:1, with larger documents demonstrating higher ratios.

To take advantage of this, the MPS allows metadata clients to indicate that they can consume the compressed form of published metadata through use of the HTTP content coding system as described in [RFC7231] section 3.1.2.1.

The result is a large reduction in the amount of data a compatible client needs to transfer. This obviously benefits the individual client while also improving the scaleability of the central service.

Clients indicate which encoding types they support by means of the Accept-Encoding header within the GET request (see [RFC7231] section 5.3.4).

The MPS supports the “gzip” compression scheme (see [RFC7230] section 4.2.3). There are no plans at the time of writing to support other compression schemes.

Note that although the MPS MAY respond to a request in which the Accept-Encoding header includes the value gzip by returning a compressed result, it is not required to do so. Clients MUST be prepared to process uncompressed responses.