Simplify Request Authorization Configuration #13057
Labels
in: config
An issue in spring-security-config
status: duplicate
A duplicate of another issue
type: enhancement
A general enhancement
Nearly every application needs to override Spring Security's default authorization rule that all requests require the they be authenticated.
Many applications have static resources that are permitted for example, and many applications want to permit Spring Boot's
/error
endpoint. Beyond that, many applications use RBAC, ABAC or some other form of authorization that requires corresponding Spring Security configuration.This is quite simple in Spring Security already. For example, if I have a default Spring Security application, I can achieve a configuration identical to the default while changing only the authorization rules by doing the following:
Some of the above does not have to do with authorization, though. And it would be nice to not have to specify that as well. For example, many applications do not need to specify authentication mechanisms as they are inferrable by Spring Boot.
This leads to confusion and potential misconfiguration issues when a user doesn't realize that even though they specified Boot properties, they still need to specify the mechanism in the DSL. For example, if I use
spring-boot-starter-oauth2-resource-server
and am using the Boot properties, I might easily assume that I can specify my authorization rules like so:But, I would be wrong. Because I am overriding authorization rules, I also need to re-specify my authentication mechanisms. Because I don't know this, my application may end up less secure (since I've specified resource server configuration in Boot that is now no longer in effect).
Instead of having to specify authorization alongside authentication, it would be nice to be able to specify it separately.
One way to do this would be with a bean, like so:
In this case,
HttpSecurityConfiguration
would pick up theCustomizer<AuthorizeHttpRequestConfigurer>
bean and apply it before returning aHttpSecurity
prototype instance.In this case, Boot publishing a
SecurityFilterChain
would look something like:The nice thing about this is that it is a pattern that could potentially be followed for other configurers, which may lead to being able to break up
HttpSecurity
configuration into smaller consumable chunks. The downside is that it's a departure from how Spring Security is traditionally configured.Or publishing an
AuthorizationManager
bean maintains a more traditional relationship withHttpSecurity
instances:(
RequestMatcherDelegatingAuthorizationManager
DSL methods do not exist yet, but please referenceMessageMatcherDelegatingAuthorizationManager
as an example)Another nice thing about using
AuthorizationManager
is the rest of the API fits in nicely:The main downside of this route is that it duplicates the DSL already found in
AuthorizeHttpRequestConfigurer
.In that case, Boot publishing a
SecurityFilterChain
would look something like:In both cases, because authorization configuration can be declared separately, an application can do so without having to know that they must re-specify authentication mechanisms.
At this point, I feel amenable to both routes, but I slightly prefer the first one because of the broader potential it has for the entire DSL (other Customizer beans, for example). While it's not terribly obvious to a coder that
Customizer<AuthorizeHttpRequestsConfigurer>
is the right bean to publish, this could be improved with a marker inferface likeRequestAuthorizationCustomizer
. Feedback is welcome.I distantly recall that @rwinch had a concern, and, Rob, please forgive me, but could you add your concern (if you still have it) here to this ticket for the record so that I don't forget again? :)
The text was updated successfully, but these errors were encountered: