Closed
Description
Expected Behavior
HttpSecurity's authorizeHttpRequests()
uses role hierarchy defined as a bean or defined as a separate method like setRoleHierarchy(RoleHierarchy rh) {...}
so the flow will be like
@Bean
public SecurityFilterChain filterChain(@NotNull HttpSecurity http) {
...
http.authorizeHttpRequests()
.setRoleHierarchy(getRoleHierarchy())
.requestMatchers("my.site/admin")
.hasRole("ADMIN")
...
}
Current Behavior
HttpSecurity's authorizeHttpRequests()
uses role hierarchy by .access()
method using redefined AuthorityAuthorizationManager<RequestAuthorizationContext>
. it is quite inconvenient and quite a lot of code.
so i need to do
@Bean
public AuthorityAuthorizationManager<RequestAuthorizationContext> adminAuthorityAuthorizationManager() {
AuthorityAuthorizationManager<RequestAuthorizationContext> objectAuthorityAuthorizationManager = AuthorityAuthorizationManager.hasAuthority("ROLE_ADMIN");
objectAuthorityAuthorizationManager.setRoleHierarchy(getRoleHierarchy());
return objectAuthorityAuthorizationManager;
}
and then use this
http.authorizeHttpRequests()
.requestMatchers("my.site/admin")
.access(adminAuthorityAuthorizationManager())
Context
i found that AuthorityAuthorizationManager
has a non-static RoleHierarchy
field.
well, i propose:
- make a private static
RoleHierarchy
field inAuthorizeHttpRequestsConfigurer.AuthorizedUrl
defaulted toNullRoleHierarchy
- set it by a static method
setRoleHierarchy()
- pass it to
hasRole...
methods under-the-hood - pass it to
hasRole...
methods ofAuthorityAuthorizationManager
in 3) - set it to inner field
roleHierarchy
(!) - continue as it is now
so, we will have an easy setter for roleHierarchy without clumsy use of redefined classes for each custom role