Page Comparison

Namespace:urn:mace:shibboleth:2.0:metadata
Schema:http://shibboleth.net/schema/idp/shibboleth-metadata.xsd

Overview

A filter of type Algorithm adds extension elements defined by the SAML V2.0 Metadata Profile for Algorithm Support, which the IdP supports as a means of determining the best cryptographic algorithms to use when communicating with a particular relying party. It is the only practical mechanism whereby newer algorithms can be safely deployed without breaking interoperability.

This filter is typically used to add algorithm extensions to remote metadata at runtime. The filter is usually applied to an HTTP metadata provider such as the FileBackedHTTPMetadataProvider or the DynamicHTTPMetadataProvider, since locally-maintained metadata can generally be edited directly.

...

To use the Algorithm filter, sequences of these "method" elements are supplied as filter content. When a child element such as <Entity> or <ConditionRef> or <ConditionScript> evaluates to true, the "method" elements are applied to the corresponding metadata in the appropriate location.

Other Relevant Schemas

The schema for the <alg:DigestMethod> and <alg:SigningMethod> extension elements is part of the OASIS SAML V2.0 Metadata Profile for Algorithm Support specification.

...

The most complex aspect of this filter, aside from actually understanding the algorithms to specify and what they're actually called, is that the XML gets more complex than most people are used to because of the variety of namespaces involved. The similarities, and sometimes subtle differences, between the URIs for the namespaces and the URIs of the algorithms is also a source of constant pain. The XML Signature and Encryption 1.0 and 1.1 standards are very complex and specifying things requires careful attention to detail in some cases.

...

A useful set of references and an incomplete set of some of the important algorithms defined within them:

• XML Signature 1.0 (see 1.1 for the actual latest formal spec)

  • SHA-1 DigestMethod

  • RSA with SHA-1 SigningMethod

• RFC 6931

  • SHA-224, SHA-384 DigestMethod variants

  • RSA with SHA-2 SigningMethod variants

  • ECDSA SigningMethod variants

• XML Signature 1.1

• XML Encryption 1.0 (see 1.1 for the actual latest formal spec)

  • SHA-256 DigestMethod

  • AES-CBC EncryptionMethod for data

  • RSA-OAEP-MGF1 with SHA-1 digest and MGF EncryptionMethod for keys

• XML Encryption 1.1

  • AES-GCM EncryptionMethod

  • RSA-OAEP with variable digest and MGF EncryptionMethod for keys

In most cases, all that's necessary to define use of a digest or signing algorithm is for the enclosing extension element to carry an Algorithm XML attribute containing the proper URI. You should get some warnings if an improper or unsupported URI is used.

...

XML Elements

Examples

...

This example is appropriate for a metadata source containing lots of SPs, a large number of which do not support GCM and/or can't be practically tested.

<MetadataFilter xsi:type="Algorithm">
	
	<!-- GCM-supporting SPs. -->
    <md:EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#aes128-gcm" />
    <Entity>https://tested.example.org/sp</Entity>
    <Entity>https://also-tested.example.org/sp</Entity>

	<!-- Tag everything with CBC. -->
	<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" />
	<ConditionRef>shibboleth.Conditions.TRUE</ConditionRef>

</MetadataFilter>

The second example is sensible for a smaller metadata source for which the bulk of the SPs are assumed to support GCM and/or can practically be tested prior to deployment to identify the exceptions. This is just a straightforward application of CBC to the non-supporting systems.

<MetadataFilter xsi:type="Algorithm">
	
	<!-- CBC-only SPs. -->
	<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" />
    <Entity>https://broken.example.org/sp</Entity>
    <Entity>https://also-broken.example.org/sp</Entity>

</MetadataFilter>

The last example is a more comprehensive illustration of some of the fancier things that can be done.

<MetadataFilter xsi:type="Algorithm">

	<!--
	Use AES-CBC encryption and OAEP with SHA-256 for key encryption padding.
	Normal defaults are AES-GCM and OAEP with SHA-1.
	-->
	<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" />
	<md:EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#rsa-oaep">
		<xenc11:MGF Algorithm="http://www.w3.org/2009/xmlenc11#mgf1sha256" />
		<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
	</md:EncryptionMethod>

    <Entity>https://sp1.example.org</Entity>

	<!-- For a second SP, also switch to SHA-512 and RSA with SHA-512 for signing. -->
	<alg:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha512" />
	<alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/>
	
    <Entity>https://sp2.example.org</Entity>

</MetadataFilter>