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.
ProfileConfiguration-SAML
- Scott Cantor
- Derrick Johnson
SAML
Options common to SAML profiles:
| Name | Type | Default | Description |
|---|---|---|---|
| additionalAudiencesForAssertion | Collection<String> | Additional values to populate into audience restriction condition of assertions | |
| includeConditionsNotBefore | Boolean | true | Whether to include a NotBefore attribute in assertions |
| assertionLifetime | Duration | PT5M | Lifetime of assertions |
| signAssertions | Predicate<ProfileRequestContext> | false | Whether to sign assertions |
| signResponses | Predicate<ProfileRequestContext> | varies by profile | Whether to sign responses |
| signRequests | Predicate<ProfileRequestContext> | 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 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.