Difference between Role and GrantedAuthority in Spring Security

Question

There are concepts and implementations in Spring Security  such as the GrantedAuthority interface to get an authority to authorize control an access    I would like that to permissible operations  such as createSubUsers  or deleteAccounts  which I would allow to an admin  with role ROLE ADMIN     I am getting confused as the tutorials demos I see online  I try to connect what I read  but I think we treat the two interchangeably   I see hasRole consuming a GrantedAuthority string  I most definitely am doing it wrong in understanding  What are these conceptually in Spring Security    How do I store the role of a user  separate from the authorities for that role   I m also looking at the org springframework security core userdetails UserDetails interface which is used in the authentication-provider referenced DAO  which consumes a User  note last GrantedAuthority    public User String username               String password               boolean enabled               boolean accountNonExpired              boolean credentialsNonExpired               boolean accountNonLocked               Collection lt   extends GrantedAuthority gt  authorities    Or is there any other way to differentiate the other two  Or is it not supported and we have to make our own

User · Answer

AFAIK GrantedAuthority and roles are same in spring security. GrantedAuthority's getAuthority() string is the role (as per default implementation SimpleGrantedAuthority).

For your case may be you can use Hierarchical Roles

<bean id="roleVoter" class="org.springframework.security.access.vote.RoleHierarchyVoter">
    <constructor-arg ref="roleHierarchy" />
</bean>
<bean id="roleHierarchy"
        class="org.springframework.security.access.hierarchicalroles.RoleHierarchyImpl">
    <property name="hierarchy">
        <value>
            ROLE_ADMIN > ROLE_createSubUsers
            ROLE_ADMIN > ROLE_deleteAccounts 
            ROLE_USER > ROLE_viewAccounts
        </value>
    </property>
</bean>

Not the exact sol you looking for, but hope it helps

Edit: Reply to your comment

Role is like a permission in spring-security. using intercept-url with hasRole provides a very fine grained control of what operation is allowed for which role/permission.

The way we handle in our application is, we define permission (i.e. role) for each operation (or rest url) for e.g. view_account, delete_account, add_account etc. Then we create logical profiles for each user like admin, guest_user, normal_user. The profiles are just logical grouping of permissions, independent of spring-security. When a new user is added, a profile is assigned to it (having all permissible permissions). Now when ever user try to perform some action, permission/role for that action is checked against user grantedAuthorities.

Also the defaultn RoleVoter uses prefix ROLE_, so any authority starting with ROLE_ is considered as role, you can change this default behavior by using a custom RolePrefix in role voter and using it in spring security.

User · Answer

Another way to understand the relationship between these concepts is to interpret a ROLE as a container of Authorities   Authorities are fine-grained permissions targeting a specific action coupled sometimes with specific data scope or context  For instance  Read  Write  Manage  can represent various levels of permissions to a given scope of information    Also  authorities are enforced deep in the processing flow of a request while ROLE are filtered by request filter way before reaching the Controller  Best practices prescribe implementing the authorities enforcement past the Controller in the business layer   On the other hand  ROLES are coarse grained representation of an set of permissions  A ROLE READER would only have Read or View authority while a ROLE EDITOR would have both Read and Write  Roles are mainly used for a first screening at the outskirt of the request processing such as http          antMatcher      hasRole ROLE MANAGER    The Authorities being enforced deep in the request s process flow allows a finer grained application of the permission  For instance  a user may have Read Write permission to first level a resource but only Read to a sub-resource  Having a ROLE READER would restrain his right to edit the first level resource as he needs the Write permission to edit this resource but a  PreAuthorize interceptor could block his tentative to edit the sub-resource   Jake

User · Answer

Like others have mentioned  I think of roles as containers for more granular permissions     Although I found the Hierarchy Role implementation to be lacking fine control of these granular permission  So I created a library to manage the relationships and inject the permissions as granted authorities in the security context     I may have a set of permissions in the app  something like CREATE  READ  UPDATE  DELETE  that are then associated with the user s Role     Or more specific permissions like READ POST  READ PUBLISHED POST  CREATE POST  PUBLISH POST   These permissions are relatively static  but the relationship of roles to them may be dynamic   Example -    Autowired  RolePermissionsRepository repository   public void setup      String roleName    ROLE ADMIN     List lt String gt  permissions   new ArrayList lt String gt       permissions add  CREATE      permissions add  READ      permissions add  UPDATE      permissions add  DELETE      repository save new RolePermissions roleName  permissions        You may create APIs to manage the relationship of these permissions to a role   I don t want to copy paste another answer  so here s the link to a more complete explanation on SO  https   stackoverflow com a 60251931 1308685  To re-use my implementation  I created a repo  Please feel free to contribute  https   github com savantly-net spring-role-permissions

User · Answer

Think of a GrantedAuthority as being a  permission  or a  right   Those  permissions  are  normally  expressed as strings  with the getAuthority   method   Those strings let you identify the permissions and let your voters decide if they grant access to something   You can grant different GrantedAuthoritys  permissions  to users by putting them into the security context  You normally do that by implementing your own UserDetailsService that returns a UserDetails implementation that returns the needed GrantedAuthorities   Roles  as they are used in many examples  are just  permissions  with a naming convention that says that a role is a GrantedAuthority that starts with the prefix ROLE   There s nothing more  A role is just a GrantedAuthority - a  permission  - a  right   You see a lot of places in spring security where the role with its ROLE  prefix is handled specially as e g  in the RoleVoter  where the ROLE  prefix is used as a default  This allows you to provide the role names withtout the ROLE  prefix  Prior to Spring security 4  this special handling of  roles  has not been followed very consistently and authorities and roles were often treated the same  as you e g  can see in the implementation of the hasAuthority   method in SecurityExpressionRoot - which simply calls hasRole     With Spring Security 4  the treatment of roles is more consistent and code that deals with  roles   like the RoleVoter  the hasRole expression etc   always adds the ROLE  prefix for you  So hasAuthority  ROLE ADMIN   means the the same as hasRole  ADMIN   because the ROLE  prefix gets added automatically  See the spring security 3 to 4 migration guide for futher information   But still  a role is just an authority with a special ROLE  prefix  So in Spring security 3  PreAuthorize  hasRole  ROLE XYZ     is the same as  PreAuthorize  hasAuthority  ROLE XYZ     and in Spring security 4  PreAuthorize  hasRole  XYZ     is the same as  PreAuthorize  hasAuthority  ROLE XYZ       Regarding your use case      Users have roles and roles can perform certain operations    You could end up in GrantedAuthorities for the roles a user belongs to and the operations a role can perform  The GrantedAuthorities for the roles have the prefix ROLE  and the operations have the prefix OP   An example for operation authorities could be OP DELETE ACCOUNT  OP CREATE USER  OP RUN BATCH JOBetc  Roles can be ROLE ADMIN  ROLE USER  ROLE OWNER etc   You could end up having your entities implement GrantedAuthority like in this  pseudo-code  example    Entity class Role implements GrantedAuthority        Id     private String id        ManyToMany     private final List lt Operation gt  allowedOperations   new ArrayList lt  gt           Override     public String getAuthority             return id             public Collection lt GrantedAuthority gt  getAllowedOperations             return allowedOperations            Entity class User        Id     private String id        ManyToMany     private final List lt Role gt  roles   new ArrayList lt  gt          public Collection lt Role gt  getRoles             return roles            Entity class Operation implements GrantedAuthority        Id     private String id        Override     public String getAuthority             return id            The ids of the roles and operations you create in your database would be the GrantedAuthority representation  e g  ROLE ADMIN  OP DELETE ACCOUNT etc  When a user is authenticated  make sure that all GrantedAuthorities of all its roles and the corresponding operations are returned from the UserDetails getAuthorities   method   Example  The admin role with id ROLE ADMIN has the operations OP DELETE ACCOUNT  OP READ ACCOUNT  OP RUN BATCH JOB assigned to it   The user role with id ROLE USER has the operation OP READ ACCOUNT   If an admin logs in the resulting security context will have the GrantedAuthorities  ROLE ADMIN  OP DELETE ACCOUNT  OP READ ACCOUNT  OP RUN BATCH JOB  If a user logs it  it will have  ROLE USER  OP READ ACCOUNT  The UserDetailsService would take care to collect all roles and all operations of those roles and make them available by the method getAuthorities   in the returned UserDetails instance

[java] Difference between Role and GrantedAuthority in Spring Security

Examples related to java

Examples related to spring

Examples related to spring-mvc

Examples related to spring-security