The Shibboleth IdP V3 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP4 wiki space for current documentation on the supported version.


File(s): conf/relying-party.xml

Format: Native Spring / Deprecated Custom Schema

Legacy V2 File(s): conf/relying-party.xml


The SAML2.ArtifactResolution profile configuration bean enables support for the SAML 2.0 Artifact Resolution profile over SOAP. It is required when supporting the use of the Artifact profile with Browser SSO in order to deliver the full assertion. It should be disabled if not in use.


The most typical options used are described in more detail below, but not every obscure option is discussed. See the javadoc for all of the possible configuration options for this profile (note that many of them are inherited from parent classes).

Virtually all the configuration options below can be set via two different properties: a static property that explicitly sets the value to use and a lookup strategy or predicate property that takes a Function or Predicate and returns the value to use. The dynamic property is generally named "propertyNamePredicate" or "propertyNameLookupStrategy" for Boolean- and non-Boolean-valued properties respectively.

The examples shown are not specific to any particular profile configuration.


Options common to most/all profiles:

securityConfiguration   SecurityConfigurationBean named shibboleth.DefaultSecurityConfigurationAn object containing all of the default security-related objects needed for peer authentication and encryption. See SecurityConfiguration for complete details.
disallowedFeatures 3.3Integer0A bitmask of features to disallow, the mask values being specific to individual profiles


Modifying the security configuration is usually done to:

  • specify an alternate signing or decryption key to use
  • control signing or encryption algorithms (but for metadata you control, it's advisable to control algorithms by using an extension to specify supported algorithms).


Options common to SAML profiles:

Additional values to populate into audience restriction condition of assertions
includeConditionsNotBeforeBooleantrueWhether to include a NotBefore attribute in assertions
assertionLifetimeDurationPT5MLifetime of assertions
signAssertionsPredicate<ProfileRequestContext>falseWhether to sign assertions
signResponsesPredicate<ProfileRequestContext>varies by profileWhether to sign responses
signRequestsPredicate<ProfileRequestContext>falseWhether to sign requests


It isn't too common to need any of these options, and they should be changed only with care.

The additionalAudiencesForAssertion and includeConditionsNotBefore settings provide ways to work around bugs in other systems. You should never use these settings without obtaining a commitment from the other system's owner to fix their bugs.

The assertionLifetime setting does not involve control over the session with the relying party, it's only relevant in delegation scenarios.

The signing options have a complex history, which is one reason they are not themselves just boolean-valued. We provide Spring support so you can just set them to "true" or false" as though they are, but they also directly support the more dynamic approach of deriving the value with a bean.

The signResponses default varies by profile, see the notes on the individual profile pages.

If you need to enable the signAssertions option, and you control the SP's metadata, you should generally add the WantAssertionsSigned flag to it in place of using this option.

SAML 2.0

Options common to SAML 2.0 profiles:

encryptionOptionalBooleanfalseWhether to automatically disable encryption if the relying party does not possess a suitable key
encryptAssertionsPredicate<ProfileRequestContext>varies by profileWhether to encrypt assertions
encryptNameIDsPredicate<ProfileRequestContext>varies by profileWhether to encrypt NameIDs
encryptAttributesPredicate<ProfileRequestContext>falseWhether to encrypt attributes


The encryption options are generally set correctly for each different profile; see the notes on the individual profile pages. We provide Spring support so you can just set them to "true" or "false" as though they are boolean-valued, but they also directly support the more dynamic approach of deriving the value with a bean.

Note that when the conditions to encrypt various constructs evaluate to true, the IdP will fail the request if it is unable to perform the encryption, for whatever reason. This is overrideable using the encryptionOptional property, which allows the IdP to encrypt if it can but continue otherwise. If you carefully control your metadata sources, which you should do in any case, you should be able to trust that any SP lacking an encryption key is incapable of encryption anyway, making the property safe to enable.


The default value of signResponses for this profile is an extended form of the behavior that was referred to in V2 as "conditional". It signs only if TLS isn't used (very unusual) or if the receiving port is 443. It assumes that traffic over 443 will be relying on message-based security measures (but see below), whereas traffic to an alternative TLS port like 8443 will be relying on mutual authentication and thus provide a secure channel.

The default value of encryptAssertions is conditional in the same manner.