Summary
Support of a simple rbac approach would be great. It doesn't have to be a full blown implementation, but just the basic role to privileges mapping would be sufficient in a lot of cases.
We've implemented something like this at https://github.com/vsfexperts/rbac . Would you be interested in taking over the code/providing something similar?
I've created a 2nd ticket in spring-boot project, as I'm unsure which is the correct project (https://github.com/spring-projects/spring-boot/issues/16075)
Comment From: vsfalexanderpilch
Is there any update on this?
Comment From: jzheaux
Hi, @vsfalexanderpilch, I wonder if updating RoleHierarchyImpl with a Map<String, List<String>> constructor would be the best fit here.
Spring Security itself likely wouldn't support a properties file directly since Framework and ultimately Boot are quite powerful at that. Further, it appears to me like the properties are essentially a Map<String, List<String>> which I wouldn't imagine would need any special handling, e.g.:
my.app.my_role_hierarchy:
admin:
- has_read
- has_write
- has_grant
user:
- has_read
I also am not clear on the value of the code generation; however, it's also true that Spring Security does not yet generate code and I think it would be better to focus on ways to provide this feature without that extra maintenance.
But, I can see a strongly-typed constructor for RoleHierarchyImpl to be quite powerful as this would allow you to have permissions listed in your @Secured, etc. annotations while still accepting roles from your UserDetailsService:
@Bean
RoleHierarchy roleHierarchy(@Value("my.app.my_role_hierarchy") Map<String, List<String>> hierarchy) {
return new RoleHierarchyImpl(hierarchy);
}
I realize this is more stripped down than what you were thinking. Would this address your needs?
Comment From: spring-projects-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: spring-projects-issues
Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.