The Shibboleth IdP V4 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP5 wiki space for current documentation on the supported version.
AlgorithmFilter
- Scott Cantor
- Rod Widdowson
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.
The Algorithm Support extension is made up of a couple of new XML elements in an extension namespace, <alg:DigestMethod> and <alg:SigningMethod>, and a set of processing rules that the Shibboleth IdP (and SP) both support for processing those elements along with the pre-existing <md:EncryptionMethod> element already defined in the original SAML metadata schema.
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.
Filter order is important!
This filter changes the content of the metadata and so a filter of type Algorithm should appear after any SignatureValidationFilter in the overall sequence of filters.
Position the Algorithm filter for efficiency
Deliberately position an Algorithm filter in the overall sequence of filters for optimal efficiency. In particular, a filter of type Algorithm should appear after the EntityRoleFilter since the latter effectively removes entities from the input.
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 pre-existing <md:EncryptionMethod> element is defined by the urn:oasis:names:tc:SAML:2.0:metadata namespace, the schema for which can be located at http://docs.oasis-open.org/security/saml/v2.0/saml-schema-metadata-2.0.xsd. This namespace is usually associated with the md: prefix.
Other schemas of relevance include all of the XML Signature and Encryption 1.0 and 1.1 schemas.
General Configuration
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.
Update Note
The root element of the conf/metadata-providers.xml file in the distribution has been updated to contain a number of namespace declarations and schema locations to properly reference the relevant schemas for this feature. It is advisable to update your local copy with the new example after an upgrade from V3 if you want to use this filter.
In the most typical scenarios, using this filter and the extension specification is mostly a matter of properly identifying algorithms, which are all identified in XML with URI constants. These constants sometimes, but not always, tend to be prefixed with namespace URIs from the various XML security specifications, but it can be odd and seemingly random as to which namespace was used because algorithms were introduced at different points. Digests in particular pop up in both the Signature and Encryption specs and some other algorithms were introduced by RFC 6931.
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
SHA-224, SHA-384 DigestMethod variants
RSA with SHA-2 SigningMethod variants
ECDSA SigningMethod variants
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
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.
It is possible to impose key size constraints on, for example, the size of RSA keys, but this is not a common need.
Encryption is more complex because there are actually two sets of algorithms used, one to encrypt data and one to encrypt the secret key used to encrypt the data. Data encryption specification is generally the same as with digest/signing, just a simple Algorithm XML attribute. Key encryption is sometimes more complex because it may be necessary to supply additional parameterization of the RSA-OAEP algorithm (there isn't any other reason at present to be specifying it at all).
The example at the end includes illustrations of each case.
Reference
XML Elements
Name | Description |
|---|---|
<alg:DigestMethod> <alg:SigningMethod> | Elements added to the <md:Extensions> block in metadata of all the entities which match any of the following <Entity> / <ConditionRef> / <ConditionScript> elements |
<md:EncryptionMethod> | Element added to every encryption-applicable <md:KeyDescriptor> in every role contained in the metadata of all the entities which match any of the following <Entity> / <ConditionRef> / <ConditionScript> elements |
<Entity> | The textual content is an entityID. All preceding extensions are added to the matching entity. |
<ConditionRef> | The textual content is the Bean ID of type Predicate<EntityDescriptor>. All preceding extensions are added to the entities for which this returns true. |
The content of this element is an inline or local script resource that implements Predicate<EntityDescriptor>. All preceding extensions are added to the entities for which this returns true. |
Examples
The first example is a useful tool for maintaining the AES-GCM encryption default while continuing to support ad-hoc federation at scale. In this scenario, you will never practically be able to test many of the SPs in the world, and many of them will fail to support GCM, so a quick fix is to tag them all with AES-CBC-128, the older default, and gradually inject GCM rules for important services after they've been tested.
Note that while this example will result in both algorithms attached to the metadata of the first set of SPs, the extension relies on order of appearance, and so the presence of GCM earlier will prioritize it for that SP.
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.
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.
The last example is a more comprehensive illustration of some of the fancier things that can be done.