spring-projects / spring-security

Spring Security
http://spring.io/projects/spring-security
Apache License 2.0
8.75k stars 5.87k forks source link

Reintroduce expressions for http security #13184

Open puskaiz opened 1 year ago

puskaiz commented 1 year ago

When trying to migrate our codebase to Spring 3, I realized, that our security configuration cannot be migrated easily.

Code, that cannot be migrated (not real code, just an example):

http
  .authorizeRequests()
  .mvcMatchers("/admin/{id}")
  .access("hasRole('ADMIN') && @webSecurity.check(#id)"))

According to the documentation, we should write an AuthorizationManager for this use-case. We have used the same expressions on method security - and that was awesome.

It would be nice if expressions on http security would work again.

jzheaux commented 1 year ago

You can use WebExpressionAuthorizationManager.

That said, I agree that the use case for extracting path parameters could use some work. Would you mind if we repurposed this ticket to take a look at that?

puskaiz commented 1 year ago

Having the same expressions on url security and method security is a great value (as I mentioned, I have provided an example, in our applications we have complicated expressions). I did understand the migration, played with the WebExpressionAuthorizationManager ... and we can do the migration for URL security. But the end result is not as clean as in Spring Boot 2.

Please, use this ticket as you wish.

jzheaux commented 1 year ago

Thanks, @puskaiz. Given your response, I think it would be better to leave this ticket open and watch for votes. While I am hesitant to reintroduce expressions -- since as you mentioned, they have a tendency to encourage complicated expressions -- I don't mind leaving this ticket for others to find and explain their point of view. I've added https://github.com/spring-projects/spring-security/issues/13256 to address path extraction.

s3curitybug commented 1 year ago

In Spring Security 5.7 (currently 5.7.9), WebExpressionAuthorizationManager is not defined and the method access already does not accept a string as argument unless the deprecated authorizeRequests method is used, instead of authorizeHttpRequests. How should we use expressions?

Actually, the code in the documentation does not work: https://docs.spring.io/spring-security/reference/5.7/servlet/authorization/expression-based.html#_tabs_2

puskaiz commented 1 year ago

Would it be hard to reintroduce expressions? A long time ago, we started by extending WebSecurityExpressionRoot, DefaultWebSecurityExpressionHandler for Url security and SecurityExpressionRoot, DefaultMethodSecurityExpressionHandler for method security in order to introduce new elements to security expressions. We were happy to migrate our security expressions on using beans, so no custom code was needed to add some additional conditions to Url/method security expressions. Now I feel, that we should make a step back, as we cannot use the same expressions on the Url/method security, at least not without writing custom code.

puskaiz commented 1 year ago

any chances to re-introduce expressions?