Options common to SAML profiles that create assertions:
Name | Type | Default | Description |
|---|---|---|---|
additionalAudiencesForAssertion | Collection<String> | Additional values to populate into audience restriction condition of assertions | |
includeConditionsNotBefore | Boolean | true | Whether to include a |
assertionLifetime | Duration | PT5M | Lifetime of assertions |
signAssertions | Boolean | false | Whether to sign assertions |
signResponses | Boolean | varies by profile | Whether to sign responses |
signRequests | Boolean | false | Whether to sign requests |
Guidance
It isn't too common to need any of these options, and they should be changed only with care.
The additionalAuduencesForAssertion 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 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. Related, the idp.saml.honorWantAssertionsSigned property can be turned off to globally ignore that flag in metadata should you wish to do so.