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.

[jzheaux]

https://docs.spring.io/spring-security/reference/5.8/migration.html#_use_authorizationmanager_for_method_security

[JohnZ1385]

https://docs.spring.io/spring-security/reference/5.8/migration.html#_use_authorizationmanager_for_method_security

link broken

[sjohnr]

Hi @JohnZ1385, the guide was restructured after the comment above. See https://docs.spring.io/spring-security/reference/5.8/migration/servlet/authorization.html#_use_authorizationmanager_for_request_security instead.

[filiphr]

We are in the process of migrating from Spring Boot 2.7 to Spring Boot 3.1 and this was one of the issues that we were hit with. We are using the RunAsManager with a combination of the FilterSecurityInterceptor. The proposed solution in the documentation to use a customized RunAsAuthorizationManagerAdapter is not identical to what was happening before.

The FilterSecurityInteceptor through the AbstractSecurityInterceptor was also changing the SecurityContext with the new authentication. e.g. in

spring-security/core/src/main/java/org/springframework/security/access/intercept/AbstractSecurityInterceptor.java

Line 236 in 5828e4e

this.securityContextHolderStrategy.setContext(newCtx);

The newly proposed solution is not doing that. This might be linked to #13435 where the default SwitchUserFilter was changed to use sessions by default. However, our Switch user approach is not using sessions, which means that currently there is no way for us to provide this out of the box. It means that we need to have our own filter that is going to perform what was being done in the FilterSecurityInterceptor with the RunAsManager