Namespace:urn:mace:shibboleth:2.0:metadata
Schema:http://shibboleth.net/schema/idp/shibboleth-metadata.xsd
| Table of Contents | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
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.
...
| Note |
|---|
It is unsafe and undefined to use Spring properties (%{foo}) in any of the content for this filter. |
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. |
<EntityRegex> 5.1 | The textual content is a regular expression to match against the entityID. All preceding extensions are added to matching entities. |
<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
| Note |
|---|
Note the examples assume a set of XML namespace declarations in the top of the configuration that match the shipping defaults in this release. |
...
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 use of two separate filters is required to simplify the conditional logic and ensure that only the desired SPs receive the GCM extension.
| Expand | |||||
|---|---|---|---|---|---|
| |||||
|
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. Note that it only works if the metadata as a whole does not already include the GCM algorithm extension already for every SP.
| Expand | |||||
|---|---|---|---|---|---|
| |||||
|
...