ProfileConfiguration-SAML2

Options common to SAML 2.0 profiles:

Name

Type

Default

Description

Name

Type

Default

Description

ignoreRequestSignatures

Boolean

false

Whether to skip validation of signatures on requests

encryptionOptional

Boolean

false

Whether to automatically disable encryption if the relying party does not possess a suitable key

encryptAssertions

Boolean

varies by profile

Whether to encrypt assertions

encryptNameIDs

Boolean

varies by profile

Whether to encrypt NameIDs

encryptAttributes

Boolean

false

Whether to encrypt attributes

proxyCount

Non-negative Integer



Controls the insertion of a proxy count into a <saml2:Scoping> element (when issuing SAML 2 AuthnRequests to an IdP) and into a <saml2:ProxyRestiction> element (when issuing SAML 2 assertions)

proxyAudiences

Set<String>



Controls the insertion of audiences into a <saml2:ProxyRestiction> element when issuing SAML 2 assertions

Guidance

The encryption options are generally set correctly for each different profile; see the notes on the individual profile pages.

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 ignoreRequestSignatures option is an interoperability knob to deal with badly broken or incompetently operated services. Signed requests in some profiles, particularly SSO, are often pointless and are frequently used for no good reason. If the signer's code is broken, or even worse if they manage their key poorly and require constant flag days to update them, this allows the signature to be ignored and potentially the key to be bypassed so their incompetence doesn't impact your operations.

The proxy settings are used to apply constraints to upstream and downstream proxying in accordance with the SAML 2 standard. You will generally find that most non-Shibboleth implementations ignore the resulting content, in violation of the standard, but they're provided as a means of documenting your intent primarily in service of audit requirements.