File(s): conf/relying-party.xml
Format: Native Spring
| Table of Contents | ||
|---|---|---|
|
Overview
The SAML2.SSO profile configuration bean enables support for the SAML 2.0 Browser Single Sign-On profile (the most common profile used today with Shibboleth). This includes support for "unsolicited" or "IdP-initiated" SSO via the request format documented here.
Configuration
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.
| Localtabgroup | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Notes
The default value of signResponses for this profile is "true", in keeping with modern best practice. As long as one of the response or assertion are signed, use of the profile is "safe" in terms of authentication integrity, but there are vulnerabilities in XML Encryption that make signing responses advisable when the most common encryption algorithms are used. Some of the backstory around the signing defaults is discussed in this thread.
If you encounter a relying party that accepts an unsigned response and assertion that is transmitted via POST (and not artifact), you have identified an insecure implementation and should report the issue immediately while following your local security incident response process.
The default value of encryptAssertions for this profile is "true".
The default value of signRequests for this profile is "false", and normally comes into play only for signing <saml:AuthnRequest> messages when proxying. Signing can also be triggered via the proxied IdP's WantAuthnRequestsSigned flag in metadata, which in turn can be globally ignored via the idp.saml.honorWantAuthnRequestsSigned property.