Options common to SAML 2.0 profiles:
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 | |
proxyAudiences | Set<String> | Controls the insertion of audiences into a |
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.