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.

Overview

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 present 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.

...

General Configuration

The most complex thing about using 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.

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.

...

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 will not should get some warnings if an improper or unsupported URI is used; it will simply be ignored as an unknown/unsupported algorithm.

It is possible to impose key size constraints on, for example, the size of RSA keys, but this is not a common scenarioneed.

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).

...

Attributes

None.

Child Elements

Any of the following can be supplied in any order:

...

Examples

...