...
| Show if | ||||
|---|---|---|---|---|
| ||||
4.2.0 (Unreleased)Changes to Existing BehaviorA regression in all 4.x releases was identified in the way the Logout ChangesThis release contains a few new options and optimizations to improve logout behavior and quiet noise in the logs, and are worth a review if you operate an IdP with a lot of SPs that do not support logout. It includes an automatic behavioral change that tracks the endpoint used to deliver an assertion when starting a session, and uses that URL when selecting a logout endpoint to use if there are multiple endpoints spanning different virtual hosts or paths. The endpoint selected will contain the longest matching sequence of characters starting from the beginning of the URL(s). This approach is notably more compatible with Shibboleth SPs that are virtually hosted with a single entityID. Another automatic change eliminates attempts to issue logout requests to SAML 2.0 SPs whose metadata contains no logout endpoints. This should reduce the extra noise of EndpointResolutionFailed events in the log and improve performance. A new property named A new property named Miscellaneous ChangesDisplay name and descriptive information associated with attributes used on the New Properties
New Beans
New Messages
|
...
Please note that the IdP does not, and will never, require write access to its configuration. Many potential vulnerabilities may rely on elevation of privilege by leveraging one bug to make a change to an a configuration file that in turn exposes the system to an RCE. It is a good idea to make sure the configuration is owned by a different account than the one used to run the IdP’s JVM, and so make the configuration read-only. Just making the files read-only is not sufficient since ownership is enough to allow the mode to be changed back. This is not new, and is very general advice, but it’s worth remembering.
...
Auto-Wired Components and Logging
To better accomodate accommodate plugins, the system now relies on Spring to automatically locate and consume beans of certain types at runtime instead of requiring lists of beans in many places in the user-editable configuration.
...
In addition, there are many "optional" files that are no longer installed by default, inclusing including some XML files and views, because they are part of Modules that enable optional features. Turning on some features in the configuration will require enabling the corresponding module, or things will not function correctly in ways that will vary from failure to start the IdP, to exceptions at runtime, to log messages about missing files.
...
| Note |
|---|
Beware of Guava's "compose" methodLegacy use of Guava Functions may work for the most part, but there is a known issue in Spring's wiring behavior that breaks the use of Guava's "compose" helper. If you have custom bean wiring anywhere that contains a reference like this, you will likely have to update it to avoid problems:
Using that syntax will often result in the two constructor arguments to that bean getting swapped/reversed, which reverses the order of the composition, usually producing bad output at best, and a crash or even more catastrophic outcome at worst. Unfortunately there's no easy fix for this because of the way Guava accomodates accommodates the conversion to Java 8's Function interface. As a result, the best thing you can do is simply scan for this and convert the above syntax to:
That is functionally equivalent and should avoid the re-ordering behavior we're seeing with Spring. |
...
The ldaptive JAAS module has an incompatible change in its handling of timeout settings. Specifying values in millseconds milliseconds will result in a DateTime parsing exception. The values must be converted to ISO syntax (e.g., 2000 → PT2S).
In addition, various LDAP pooling properties prefixed by "idp.pool.LDAP." (such as idp.pool.LDAP.validatePeriod) previously defaulted to numeric values expressed in seconds (e.g. 300 == 5 minutes). These are now being interpreted as milliseconds, which causes overly frequent pool validation if the defaults are used with an unmodified V3 ldap-authn-config.xml file. This is dicussed discussed further on the LDAPAuthnConfiguration page.
Finally, the LDAPConnector's maxResultSize option's behavior is different from V3 in that the connector will raise an error if the size is exceeeded exceeded rather than ignoring this condition.
...
A major new addition to V4 is the AttributeRegistry service that replaces, or at least supplements, the AttributeEncoder mechanism for translating attributes. While upgraded systems should operate unchanged, deployers are advised to review this new feature and may achieve substantial simplification of their configuration by taking advantage of it. Many existing encoders may be removeableremovable.
| Note |
|---|
Note that installing from scratch and then applying a legacy configuration will in most cases result in duplicate Attributes appearing in SAML messages due to the overlap between the existing encoders and the new rules. The upgrade process is designed to prevent that by excluding the new rules from the default configuration. Of course, the inverse is also true: if you want the new default rules to apply, you must make that transition after upgrading. |
...
Due to a Spring bug that causes problems with configuration reloading, we have deprecated the original set of HttpClient parent beans and any inheritence inheritance from those beans in custom HttpClient configurations. We have introduced new parent beans without predefined settings that were causing the problems, and adjusted the HttpClientConfiguration documentation in various ways to refer to them.
...