Announcement Announcement Module
No announcement yet.
permissions/groups Page Title Module
Move Remove Collapse
This topic is closed
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • permissions/groups

    This question seems to have been asked many times over the years, but i have never found any satisfying answer.

    Is there out-of-the-box support for the general concept of Permissions/Roles/Groups?

    Some interpretation like....
    - the base authority is fine-grained Permissions (PERM_ITEM_CREATE,PERM_ITEM_READ,PERM_ITEM_UPDATE, PERM_ITEM_DELETE,etc...)
    - Roles contain permissions.
    - Roles can be assigned to Users and Groups.
    - Users can be assigned to Groups.
    - The User's permission set is the union of all permissions reachable by associated Roles and Groups.

    There could be lots of variations to enhance this...
    - Roles containing Roles.
    - Groups containing Groups.
    - Allowing Users have multiple Roles and/or being members of multiple Groups.
    - etc...

    If there is no out-of-the-box support for this, is it on any roadmap?

    Is there any reason why this type of security model is not being supported?

    Even though the framework may support extension to support this model, i still think it's important that the default model be rich enough to handle most usecases (particularly enterprise cases), since tools and frameworks will normally be built to support the default model.

    So now most tools/frameworks are stuck with a simple Role security model, which is very weak in my opinion.

    Any thoughts?

  • #2
    In short, yes. You can get User -> Group -> Role behavior by enabling group support with the default JdbcDaoImpl, all the way up to full ACL support (with group and inheritance rich object-level support). A lot of this is covered in the manual and samples.


    • #3
      Thanks Peter.

      I'm very new to Spring Security, so my apologies if i am missing the obvious.

      When you say the "manual" do you mean the reference doc? This is all i could find on the subject... well as the schema definitions for the groups....

      ...and a static concept of Role hierarchy (which is not particularly useful to me if it's not represented in the db schema)...

      Part of my problem is the language disconnect. I think most people are familiar with the concept of the Permissions/Roles/Groups, but mapping these familiar concepts to abstract Authorities/Groups confuses things somewhat.

      Personally i think the most natural concrete Authority type would be a Permission. But it seems that Spring has taken the route of making the default Authority type a Role, so Roles in the context of an Authority is quite baked into the default security model. Once that is done, it's hard to fit Permissions in.

      You suggest the default model does support Permissions, but i don't see it?

      With some amount of custom coding, i'm sure you could change Authorities to be Permissions rather than Roles, and then Groups could be overloaded to represent both Groups and Roles, since the schema suggests that Groups (Roles) can be related to Users as well as Authorities (Permissions).

      But i don't see any support for hierarchy built into the Group schema objects? So no Roles referring to Roles, or Groups referring to Roles or Groups?

      What might be nice is if Spring out-of-the-box supported a few typical "profiles" or "security models", that would generate the appropriate code and db schema based off the application config/preference. Maybe the default profile is just the simple Role authority system Spring seems to have. Another profile could also add in the concept of Groups as Spring currently defines them. But then maybe there could be other alternative models, such as the typical Permission/Role/Group model where generated schema and object names would use the language of this model.

      Anyway, at this point it still looks to me like i would have to develop custom code to support auth model i'm looking for.

      Thanks Peter.