I have spent a lot of time recently trying to understand the difference between Authority and Role in Spring Security. This is a brief review of what I found.
When creating a UserDetailsService or overriding configure(AuthenticationManagerBuilder auth) in the security config class that extends WebSecurityConfigurerAdapter, I basically get complete control over what I populate inside of the UserDetails that is used/returned. This is important because the UserDetails interface really only cares about how to return one thing:
Collection<? extends GrantedAuthority> getAuthorities();
A GrantedAuthority just seems like a glorified String wrapper that names some thing. The question is... what is that thing?
This is where the subtle difference between Authority and Role comes into play.
I think that Role is an older thought/construct that automatically gets plugged into Authority if we just create a user with a Role. But completely forget about the code and classes for a minute. Think instead of Role and Authority (and User) in general definition terms:
User: A persona in the system. Someone who can be authenticated somehow.
Role: The title/type of work done by a User in the system. A user might have a "HR_MANAGER" role. Other users may also have this role.
Authority: An action that can be taken in the system. Examples might be:
When creating a UserDetailsService or overriding configure(AuthenticationManagerBuilder auth) in the security config class that extends WebSecurityConfigurerAdapter, I basically get complete control over what I populate inside of the UserDetails that is used/returned. This is important because the UserDetails interface really only cares about how to return one thing:
Collection<? extends GrantedAuthority> getAuthorities();
A GrantedAuthority just seems like a glorified String wrapper that names some thing. The question is... what is that thing?
This is where the subtle difference between Authority and Role comes into play.
I think that Role is an older thought/construct that automatically gets plugged into Authority if we just create a user with a Role. But completely forget about the code and classes for a minute. Think instead of Role and Authority (and User) in general definition terms:
User: A persona in the system. Someone who can be authenticated somehow.
Role: The title/type of work done by a User in the system. A user might have a "HR_MANAGER" role. Other users may also have this role.
Authority: An action that can be taken in the system. Examples might be:
- Approving a workflow - something typically done by a manager.
- Submitting a form - something typically done by a lower level user.
- Overriding a value by editing it after it has been submitted - something typically done by a more senior manager.
These Authorities are actions typically assigned to a Role, not specifically to a User. I am familiar with this pattern; it allows what is typically called fine grained control over actions (Authorities) by providing a level of abstraction between the action (Authority) and the User... and that level of abstraction is Role.
Now, let's come back to Spring Security.
To me, it seems like Spring Security has tried to retrofit Roles into Authorities by allowing the developer to only attach one Collection of things (GrantedAuthority is the thing) to a user... and then other configurations in configure(HttpSecurity) inside of the WebSecurityConfigurerAdapter 'interpret' the GrantedAuthority as either a Role or an Authority. For me, this was extremely confusing. Really, at the end of the day, I'm just stuffing some kind of string into GrantedAuthority and then letting Spring Security check that string when I ask it to either check hasRole or hasAuthority -- these both basically do the same thing. If I understand this correctly, this means:
I cannot use both Roles and Authorities at the same time. I have to pick one route or the other!Once I have decided whether I want to add the extra level of indirection or not, I then code it however I prefer, and then use the .hasRole() or .hasAuthority() method to basically clarify my choice to future coders because they more or less do the same thing.
Comments
Post a Comment