spring ACL - principal/SID not as user, but another entity

Question

I am looking into implementing Spring ACL for our project which as very stringent and fine-grained security requirements. I want to know if a certain scenario is possible.

Based on Spring's ACL documentation, any object (ACL_OBJECT_IDENTY) can be permissioned for ACL_SID, and the documentation talks about SID being a 'principal'.. i.e. the currently logged in user.

So, if I have four departments (D1,D2,D3,D4) assigned to two Managers (M1, M2), where M1 can administer D1 & D2 and M2 can administer D3 and D4.. I can easily implement using ACL.

Now, I have a scenario like, where departments have employees, E1, E2.... E8, (assume two each in each department in sequence.. such as D4 has E7 and E8). Employees submit reports R*, and I need to protect 'read' access on those reports to : 1. the Employee itself. 2. The Managers of the department of the employee. 3. other Employees of the department.

and 'admin' access to those reports to: 1. the Employee itself 2. the Managers of the department of the employee.

Even this is possible by original understanding of ACL, where a 'principal' is limited to a user, like E* or M* . such as:

E1, E2.. E8
M1, M2..

and for each report, we could create ACL_ENTRY's like:

R1 read, write to E1  //E1 is author
R1 read, write to M1  //M1 is manager of D1, and E1 belongs to D1
R1 read to E2         //E2 belongs to D1

In this scenario I will check if any E* or M* has access to R1.

All is OK, but I feel this can get too complex to manage (the ACL entries), if E's come in and out of D's or if M's are added/removed to manage D's..

So, the question is: Can I use an entity object as a principal, and use that to verify permissions when permissions need to be evaluated. Accordingly, Can I add to ACL_SID the following:

D1, D2, D3 and D4    //departmetnIds, not usersIds

And then replace ACL_ENTRIES with:

R1 read, write to E1 //E1 is author
R1 read to D1        // note D1 here

This way, if I'm checking read for any E, I'll check if R1 is permissioned to E's D. OR if I'm checking if any E has a 'write', then I can check for write specifically to E.

Note: While coming up for an example above, I know there is a gap, to see if any M has 'write' permission.. If we use M's D to resolve permission for R1 instead of M itself, we'll only get 'read'.. and If we add 'write' to the ACL_ENTRIES for D, then all the other E's of the M get 'write' as well (where-as they shouldn't). Assuming, this as a problem with my scenario, please consider the question at a higher level.

Again the question: Does the principal/SID in ACL_SID always have to be a userId/userName or can it be anything else that can be interpreted differently.

Thanks in Advance. M. Rather

Answer 1

No, the sid in ACL_SID could be a ROLE or any other GrantedAuthority that your system supports. You can, for example, give the user a GrantedAuhtority for each department she belongs to. In order to do that you will need to implement your own UserDetailsService. In your implementation the UserDetails.getAuthorities() will return one GrantedAuhtority element for each department/role.