Provide guide for migrating from FilterSecurityInterceptor to AuthorizationFilter

[vpavic]

After learning about the new authorization configuration support in HttpSecurity::authorizeHttpRequests and seeing the docs stating that AuthorizationFilter is intended to supersede the FilterSecurityInterceptor, I've opened the PR against Spring Boot (with 3.0 being a natural target for such a change) to initiate the migration to the new configuration support:

• Migrate to AuthorizationFilter in Spring Security auto-config spring-boot#31255

However, the migration wasn't as trivial as one would expect looking at the docs (for example, no apparent direct replacements for #anonymous or #fullyAuthenticated) and I haven't found any migration guide available either in the reference docs or in the Wiki here on GitHub.

So, IMO it would be a good idea to provide such a migration guide.

Here's a list of use cases that should inform the contents of such a guide:

• authorizeRequests vs authorizeHttpRequests
• filterSecurityInterceptorObserveOncePerRequest vs shouldFilterForAllDispatcherTypes
• Custom accessDecisionManager vs authorizationManager
• RunAsManager adaptation
• AccessDecisionManager adaptation
• ExpressionHandler configuration
• @EnableGlobalMethodSecurity vs @EnableMethodSecurity
• AbstractSecurityWebSocketMessageBrokerConfigurer vs @EnableWebSocketSecurity
• Make default expression handler in PrePostMethodSecurityConfiguration to use existing permission evaluator #11598

[rwinch]

@vpavic Thanks!

@jzheaux I feel like this might be something we need to enhance so that all the same expressions are available. What are your thoughts?

[jzheaux]

@rwinch, I think that most of them should be added to AuthorizeHttpRequestsConfigurer and the corresponding AuthorizationManager.

I'm not sure about hasIpAddress, I think I'd prefer to wait as protection by IP address is quite brittle these days.

I've created #11360 where I have an initial list, we can discuss anything else that needs adding over there.

Also, I realize that authorizeRequests does not expose hasPermission, but I also see some value in introducing something like PermissionAuthorizationManager to give applications a programmatic equivalent to what is available in SecurityExpressionRoot. I've added #11361 for consideration.

[vpavic]

What's the migration path for security configurations that used #filterSecurityInterceptorOncePerRequest?

[jzheaux]

Thanks, @vpavic, for asking. I don't believe there is one, yet. Will you please open a ticket to make sure it gets addressed?

[vpavic]

After taking a closer look, I'm not sure that the direct replacement is needed (or possible).

This is based on the observation that FilterSecurityInterceptor is a plain Filter that has observeOncePerRequest flag (and the accompanying logic) whereas the new AuthorizationFilter extends OncePerRequestFilter thus inheriting once per request semantics by default.

Seems to me like the replacement is to use #shouldFilterAllDispatcherTypes on the new configuration DSL.

Can you confirm?

[jzheaux]

@vpavic, I just reached out to @marcusdacoregio to confirm and yes, shouldFilterAllDispatcherTypes is the equivalent.

[vpavic]

Thanks for the confirmation. Since my last comment I updated spring-projects/spring-boot#31255 and everything builds cleanly now. In the end, the changes in that PR are quite straightforward thanks to the changes made in Spring Security in response to this issue so thanks for that.