When components access the SecurityContext statically through SecurityContextHolder, this can create race conditions when there are multiple application contexts that want to specify the SecurityContextHolderStrategy. This is because in SecurityContextHolder there is one strategy per classloader instead of one per application context.
To address this, components could wire SecurityContextHolderStrategy from the application context. By default, they will still look up the strategy from SecurityContextHolder. Additionally, though, there will be the option to set the SecurityContextHolderStrategy on components that work with the SecurityContext.
One of the nice consequences of this is that applications will be able to publish a SecurityContextHolderStrategy bean in their application context, and the security filters and other components will use the custom one instead.
These changes are largely internal, though note that they present the opportunity for applications to autowire the SecurityContextHolderStrategy instead of accessing the SecurityContext statically.
- [x] #11059
- [x] #11060
- [x] #11061
- [x] #11444
- [ ] #11886