...
The idp.hsts property default has been changed from “off” to 1 year, as we assume all IdPs have long since moved to TLS endpoints.
Several default cookie names and paths have been adjusted to leverage Google’s non-standard trick of prefixing them with “__Host-” to prevent domain injection of important cookies. The path also had to be adjusted to the server root, as a requirement of that trick. There are related changes to web.xml described separately below. This change is generally not impactful except for one unusual case: an upgrade, using the “client-side” storage option (the default) without enabling HTML Local Storage causes a separate cookie to be used, and that cookie’s name was left alone, but is affected by the path change. In such a deployment, an older cookie with a non-root path may override the new cookie, and prevent the IdP from “seeing” the newer storage data, preventing the SSO experience. The workaround at present is to change the cookie name used for the storage data using the idp.storage.clientSessionStorageName property. (In new installs, this has already been done.)
The idp.xml.strictEntityResolution property, used to prevent any attempts while parsing XML to locate remotely hosted schemas, has been changed to “true” by default. This may impact deployers who are relying on
schemaLocationhints in files that reference unknown schema locations. By design we support particular HTTP URLs that reference all our schemas to allow for editor validation, while routing all access to the schemas by the software through local copies. Using other URLs will be blocked and trigger a warning.The XML processing code in OpenSAML has been enhanced to support a more strict form of processing that rejects unexpected/unknown XML Attributes, Elements, and even stray characters inside elements. Older versions tended to ignore them. In the vast majority of cases, rejecting such content is desirable but it is possible to turn off this processing mode by setting the property opensaml.config.xml.unmarshall.strictMode to “false”. Note that this setting appears to reject otherwise valid metadata produced by Microsoft products (see Known Bugs).
The deprecated
joda-timelibrary has been removed from the distribution. Any customizations that rely on this library either must be removed or the library re-added for local inclusion. The most likely historical use of it would be in the configuration of the expiring-password interceptor or other features reliant on date-based predicates.Spring 6 has implemented a 10,000 character limit on the size of SpEL expressions to counter various denial of service vectors. This primarily impacts the use of some of our properties, as they are injected into Spring expressions to process them and/or allow dynamic behavior. We would, of course, not advise any approach that would lead to the use of such large properties and will review any areas of configuration that need additional flexibility as they’re reported to us.
The path/name of the low-level metrics providing timing data regarding dynamic metadata resolution have changed to avoid exposing internal class names and better align to the expanded metrics available in this release. If scripts depend on these JSON structure paths and can’t be updated easily, the base name of the various metrics can be adjusted via the
metricsBaseNamesetting added to the MetadataConfiguration schema.A new feature of the MFA login flow is the ability to better control the value of the timestamp that is associated with the results and eventually communicated to SPs. Prior to V5, the timestamp defaulted to the latest timestamp found on one of the “embedded” results being combined by the flow (e.g., when combining the results of the Password and Duo features). V5 defaults to using the earliest timestamp instead, and a property (idp.authn.MFA.useLatestTimestamp) has been added to control this.
Various APIs have been converted from reliance on Spring’s Resource interface to our “equivalent” non-Spring Resource interface due to inconsistencies in the way resources were “derived” from strings in the configuration. In most cases, the locations of files tend to be handled with properties or Strings and this is compatible; in unusual cases where actual Spring Resource class types were defined and injected into some beans, this may break and require adjustments to the configuration.
The internal default CAS ticket service has been switched from the original server-side storage version to the encrypted/encoded service that embeds the required state into the ticket. Deployers whose configurations include the shibboleth.CASTicketService bean will see no change as this bean overrides the internal default. The main impact of this change is that ticket size increases (affecting some broken clients) and that multi-hop proxying is unsupported. If the latter is needed, reverting to the in-memory version is required.
When validating a CAS proxy ticket via the proxyValidate endpoint, V4 identified the proxying service in the resultant
<cas:proxies>block by its CAS service URL, which did not match the protocol specification requirement of identifying a proxied service by its proxy callback URL. This issue has been fixed in V5, but this is obviously a change in behavior. Any services accepting a CAS proxy ticket and restricting access based on the identity of the proxying service should evaluate whether any changes need to be made to their configuration. SeeJira Legacy server System Jira serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key IDP-2028
...