Announcement Announcement Module
Collapse
No announcement yet.
Role-based access control (RBAC) with Spring Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Role-based access control (RBAC) with Spring

    As another poster has said, this has been posted several times over the years. And still, there is no good answer to the question how to implement Role Based Access Control (RBAC) based on the separation of users, roles and permissions. This is a basic model for a wide range of applications.

    In the early days of Acegi, Ben Alex himself referred to the RBAC in a forum post:

    "In Acegi Security you have principals, which when authenticated are housed in an Authentication object. Each Authentication object has multiple GrantedAuthority[]s. A GrantedAuthority represents a permission."

    Unfortunately, what we have now in Spring Security are hasRole() and hasPermission() methods that are somewhat misleading with their names; the hasRole() method checks for a GrantedAuthority, but the latter represents actually a permission.

    Additionally, hasPermission() tends to be treated synonymously with ACL. But ACL is an overkill for many scenarious in which simply Role Based Access Control is desired. The two are quite different solutions.

    Somehow, all this confusion doesn't seem like the rock-solid Spring framework that I have liked a lot.

    So, what is the recommended way to implement standard Role Based Access Control (RBAC) with Spring Security?

  • #2
    Good question.

    In the acl_sid table, you could set the principal flag so that instead of the principals (or the usernames) are used, the ROLES would be used to check instead.

    Of course, this is still ACL but it's now more of RBAC

    Based on the link you provided the current Spring ACL and setting that acl_sid flag, you'll achieve the following:

    Code:
    When defining an RBAC model, the following conventions are useful:
    S = Subject = A person or automated agent
    R	=	Role	 =	Job function or title which defines an authority level
    P	=	Permissions	 =	An approval of a mode of access to a resource
    SE	=	Session	 =	A mapping involving S, R and/or P
    SA	=	Subject Assignment
    PA	=	Permission Assignment
    RH	=	Partially ordered role Hierarchy. RH can also be written: ≥ (The notation: x ≥ y means that x inherits the permissions of y.)
    A subject can have multiple roles.
    A role can have multiple subjects.
    A role can have many permissions.
    A permission can be assigned to many roles.

    Comment


    • #3
      Originally posted by mps View Post
      Unfortunately, what we have now in Spring Security are hasRole() and hasPermission() methods that are somewhat misleading with their names; the hasRole() method checks for a GrantedAuthority, but the latter represents actually a permission.
      It can represent whatever you want it to. When it comes down to it, RBAC is essentially just a mapping between a set of user attributes for admin purposes (roles) and another set which apply within an application (permissions/rights). There's nothing to stop you using that model in Spring Security.

      I'd recommend you watch Mike's presentation which is available online. He talks about this kind of thing in some detail.

      In 3.1, there is an additional pluggable GrantedAuthoritiesMapper which can be used to encapsulate a mapping between one representation (e.g. roles) and another (e.g. application permissions), but it has never been difficult to implement an attribute mapping directly in your UserDetailsService or AuthenticationProvider.

      Comment


      • #4
        Just to make it easier to find here is a link to Mike's presentation that Luke mentioned.

        Comment

        Working...
        X