Fixing the security issue required an internal redesign of the External login flow (the other three essentially reuse the External flow to function) and the fix required changes to some Java classes that are part of the public API. This is allowed in a patch when necessary to address critical bugs. While these changes are visible, they do not impact the documented/intended "public" interface to the External login mechanism used by deployers building external logic.
The changes would only impact deployers in these cases:
- Anybody copying one of the impacted login flows for private use.
- This is something we expect somebody might have done but is explicitly not supported because doing so would also involve references to non-API classes that are subject to change at any time so is already known to be unsafe across upgrades.
- Anybody inheriting from the ExternalAuthentication class to provide an alternate concrete implementation of that class for use in a custom login flow.
- This would be
- necessary if one were to build an alternate version of an external login flow without using non-public classes. We consider it unlikely because of the first bullet: people are taking the easy way out and copying the flows without regard for the correctness of that approach.
- Anybody directly instantiating/adding an instance of the ExternalAuthenticationContext class to the profile request context tree.
- This is also not something we would expect anybody to have done unless they had also duplicated other implementation classes or were, again, using implementation classes directly in an unsupported manner, so it's more likely to be a consequence of one of the first two.
Note that various third party login flow extensions are known to be impacted by this change and deployers will need to test those. Those flows generally have violated the API contract as mentioned above and will need to be modified in some cases to work with this patch release, contrary to normal assumptions about patch releases.
3.4.5 (Sep 18, 2019)