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

  • Best ACL / GrantedAuthority approach

    When doing ACL based access control, what would be the best way to structure your ACL information. Schematically I see 2 approaches:

    For a persistent ACL object OBJ (with id 123), priviledges R and W, and users u1 and u2:

    1) Take the 'user centric view', e.g. ACL for OBJ would be:

    u1: R
    u2: RW

    2) Take the 'GrantedAuthority (group) centric view', e.g. there are 2 predefined groups 'OBJ_123_READ' and 'OBJ_123_WRITE' and the ACL for OBJ would be:

    OBJ_123_READ: R
    OBJ_123_WRITE: W

    and then have group memberships as follows:

    OBJ_123_READ = { u1, u2 }
    OBJ_123_WRITE = { u2 }

    What would be the best approach in terms of scalability, performance, maintainability?

    I'm thinking approach 2 could be more efficient since it allows easy caching of all groups (granted authorities) for the current user. However it does involve extra overhead to maintain those predefined groups.
    On the other hand, approach 1 seems more 'natural'.

    Any input would be much appreciated!


  • #2
    I'm also having this issue. Group based or principal based. Ben, can you give your opinion? Thanks


    • #3
      Note that the reference manual seems to hint at solution 1) by giving examples like this:

      INSERT INTO acl_permission VALUES (null, 1, 'ROLE_SUPERVISOR', 1);
      INSERT INTO acl_permission VALUES (null, 2, 'ROLE_SUPERVISOR', 0);
      INSERT INTO acl_permission VALUES (null, 2, 'marissa', 2);
      INSERT INTO acl_permission VALUES (null, 3, 'scott', 14);
      INSERT INTO acl_permission VALUES (null, 6, 'scott', 1);



      • #4
        Go group (or role) based. Assigning permissions against individual principals is generally not desired. It's also quite normal to normalize (pardon the pun) your ACL schema to suit your domain model (talk to your DBA) and provide a BasicAclDao implementation.


        • #5
          General Scalability Concerns

          Hi ...

          We're evaluating acegi for a Spring-wired application of some size and wonder if anyone could point me to any more general metrics, pinch points and advice on scalability of the security framework. I've done some searching and haven't seen much that addresses where things might start to slow down, and how to postpone the inevitable day of reckoning.

          The Group/Role (kinda sorta if I understand the framework right, that is, neither in the JAAS or JEE sense) approach to management makes a lot of sense; do you see any issues with making determination of group or groups dynamic at runtime, managed by exception (e.g. defaults, then additive overrides as you go down levels of group)?

          I'd half expected a sort of "group manager" interface that laid a logical interface on the mapping of users to (many?) groups and groups to atomic privileges -- from what I can tell that's an exercise left to the reader ... I suppose I should write one?

          A brief comment ... the Reference Documentation may be the best technical documentation I've read in years. Clear ... omigod. What a pleasure.