refactor: Obtain SecurityContext from the SecurityContextHolderStrategy bean

[heruan]

This fixes #21401 by providing a SecurityContextHolderStrategy bean as part of Spring Security auto-configuration and replaces static invocations of SecurityContextHolder.getContext() by using the strategy bean instead.

• Provide SecurityContextHolderStrategy in SpringSecurityAutoConfiguration
• Remove conflicting VaadinAwareSecurityContextHolderStrategyConfiguration
• Set the strategy on filters during VaadinSecurityConfigurer build lifecycle
• Set the strategy statically when using VaadinWebSecurity for backwards compatibility
• Inject the strategy bean in AuthenticationContext and SpringAccessPathChecker
• Deprecate constructors that obtain the strategy statically
• Avoid static access in AuthenticationUtil methods
• Update tests

Breaking changes

• VaadinAwareSecurityContextHolderStrategyConfiguration has been removed — mild since it was purely for internal use
• SpringSecurityAutoConfiguration::accessPatchChecker signature has changed to include the strategy parameter — mild since this class shouldn't be extended (better have package-private bean methods)
• Applications that have set a custom strategy statically after VaadinAwareSecurityContextHolderStrategyConfiguration might expect that custom strategy to be used by Flow, instead of the bean — those apps should now provide the custom strategy as a bean (if they expect Flow to use it)

DRAFT Tests setting the strategy statically must be updated (some already are)

[github-actions]

Test Results

1 281 files  ± 0  1 281 suites  ±0   1h 17m 14s ⏱️ -1s
8 877 tests + 1  8 810 ✅ + 1  67 💤 ±0  0 ❌ ±0 
9 322 runs   - 12  9 247 ✅  - 10  75 💤  - 2  0 ❌ ±0 

Results for commit 0e328e8. ± Comparison against base commit ee5139e.

♻️ This comment has been updated with latest results.

[sonarqubecloud]

Quality Gate passed

Issues
483 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[mcollovati]

Suggested change

	* {@link #SpringAccessPathChecker(WebInvocationPrivilegeEvaluator, String)}
	* {@link #SpringAccessPathChecker(SecurityContextHolderStrategy, WebInvocationPrivilegeEvaluator)}

[mcollovati]

It would be good to add a note mentioning usage of SecurityContextHolder#getContextHolderStrategy() in the deprecated constructors to explain the deprecation (similar to AuthenticationContext)

[mcollovati]

I wonder if we should just remove the @Configuration annotation and deprecate the class for 24.8

[heruan]

Yes, that would be better. I initially removed the class to see what failed without it, but we can keep it and deprecate before complete removal.

[mcollovati]

One missing part: restore and deprecate VaadinAwareSecurityContextHolderStrategyConfiguration
This PR can be revised after VaadinWebSecurity removal gets merged.

[CLAassistant]

All committers have signed the CLA.

[sonarqubecloud]

Quality Gate passed

Issues
600 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[heruan]

This defeats the purpose of having the strategy as a bean. This PR makes sense only by removing all static methods for security.

[heruan]

The strategy bean enables to have a different strategies for different scopes (in the same thread). Setting a static accessor opens to the risk of using the wrong strategy if the method is called on a scope where the expected strategy is different.

To keep backwards compatibility, apps that want to use static access could still use SecurityContextHolder.getContext() by explicitly setting the strategy statically.

[mcollovati]

I don't understand your point. AuthenticationUtil takes a Supplier<SecurityContext> so any time this is used it should call securityContextHolderStrategy.getContext(), where securityContextHolderStrategy is the defined bean.
What am I missing?

[heruan]

The point is that the bean instance could be different during runtime, while here we statically set that specific securityContextHolderStrategy bean instance. This is equivalent to

SecurityContextHolder.setContextHolderStrategy(securityContextHolderStrategy)

and then obtain the context statically with SecurityContextHolder.getContext().

[heruan]

Or is SmartInitializingSingleton evaluated every time based on the current context?

[mcollovati]

SecurityContextHolder.setContextHolderStrategy(securityContextHolderStrategy)

And how is this different from new AuthenticationContext(securityContextHolderStrategy) or new SpringAccessPathChecker(securityContextHolderStrategy, evaluator, vaadinProperties.getUrlMapping())?

[heruan]

Those other beans are created explicitly with that instance: if the developer wants to provide their own bean, they explicitly pass the strategy they need.

The problem with static methods is that you don't have much control of what they return and using them in different contexts/scopes might result in unexpected instances.

If we want to keep support for static access to the security context, then better stick with

SecurityContextHolder.setContextHolderStrategy(securityContextHolderStrategy)

called somewhere, but I think that should be a choice on the app side.

[mcollovati]

I see, but I'm not sure if we can completely get rid of static methods in AuthenticationUtil.
What about a temporary workaround, like:

• add a constructor to AuthenticationUtil that gets SecurityContextHolderStrategy and sets it to the static field
• expose AuthenticationUtil as a bean with @ConditionalOnMissingBean
• if the developer needs, it can override the bean provide the required strategy

[heruan]

I wouldn't introduce a temporary workaround at this point. Let's split this change in multiple steps, maybe removing the separate configuration for the strategy bean and set it statically allowing the user to provide their own.

[heruan]

Closing this in favor of an incremental approach and a proper deprecation cycle of the static accessor to the holder strategy, with #22745 as a starting point.