...
This is expected to be the final feature update to the SP in its current form with the project’s focus shifting to radical redesign.
Deprecations
Deprecations are now handled with a common “Shibboleth.DEPRECATION” logging category for easier identification.
...
The most significant changes are additional settings and default behavior to accomodate the Google-imposed SameSite cookie change. By default, the SP now assigns SameSite=None automatically to a subset of the cookies it may create that are explicitly only usable in a cross-site context, such as cookie-based RelayState or POST recovery features. It can optionally adjust the SameSite attribute for the session cookies it creates as well, using the new sameSiteSession property, but defaults to leaving session cookies unmarked and subject to default browser handling.
| Warning |
|---|
Please note, this new behavior is incompatible with the default cookieProps setting of "http" because SameSite=None generally applies only to "secure" cookies. A future SP change will likely adjust this default to "https", but the log already warns about this setting, though non-specifically. Also note, the changes described above by default will degrade functionality for older Safari versions on macOS and iOS due to a bug Apple refused to backport a fix for. A workaround is provided to accomodate broken clients but is left off by default to avoid a permanent state of legacy compatibility, but can be enabled via the sameSiteFallback setting in the |
...
Additional changes have been appllied to the default configuration (NOT upgrades) to harden the redirection behavior of the system to limit the use of the SP as an open redirector. A redirectLimit setting of exact has been added to the <Sessions> element.
Attribute Filtering Changes
...
Absent explicit configuration, the default digest algorithm used when creating signed messages has been updated from SHA-1 to SHA-256, reflecting industry guidance and matching the IdP V3 default. If compatibility with older systems is required, the default algorithm can be explicitly set via the <ApplicationDefaults> element, or specific rules for those IdPs may be specified via <RelyingParty> overrides. Note that in the majority of deployments, SPs rarely sign (and rarely need to sign) anything except for SAML logout messages.
...
SAML 1.1 support is not enabled by default; add back the string "SAML1" inside the <the <SSO> element to enable it.
Support for Attribute Queries is not enabled by default to eliminate a common source of confusion. This will impact behavior when interacting with out of date Shibboleth IdPs relying on SAML 1.1 without pushed attributes. Such systems should be migrated to SAML 2.0, but query support can be re-enabled if necessary by adding <AttributeResolver type="Query" subjectMatch="true"/> to the <the <ApplicationDefaults> element.
The default <TrustEngine> configuration (when nothing is specified, as in most cases) is now ExplicitKey-only and does not enable PKIX support.
...
A set of virtual hosts can be auto-assigned a distinct entityID without the creation of <ApplicationOverride> elements to do so, using the new entityIDSelf content setting. While this does not eliminate the overhead of managing metadata for each host, it does eliminate most actual configuration overhead within the SP itself.
...