Spring ACL - the main / SID is not as a user, but another object

Question

I am studying the Spring ACL implementation for our project, which represents very strict and fine-grained security requirements. I want to know if any scenario is possible.

According to the Spring ACL documentation, any object (ACL_OBJECT_IDENTY) can be allowed for ACL_SID, and the documentation says that the SID is "primary" ... that is, the user currently registered.

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

Now I have a scenario, for example, where departments have employees, E1, E2 .... E8 (suppose two in each department in sequence ... for example, D4 ​​has E7 and E8). Employees submit R * reports, and I need to protect "read" access to these reports so that: 1. The employee himself. 2. Heads of the employee department. 3. other employees of the department.

and 'admin' access to these reports: 1. Employee himself 2. Heads of the employee’s department.

Even this is possible thanks to the original understanding of the ACL, where the "main" is limited by the user, for example E * or M *. eg:

E1, E2.. E8 M1, M2.. 

and for each report we could create ACL_ENTRY, for example:

 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 case, I will check if any E * or M * has access to R1.

Everything is fine, but I feel that it can become too difficult to manage (write ACLs) if E enters and exits D or if M is added / removed to control D's ..

So, the question arises: can I use the object-object as a principal and use it to check permissions when it is necessary to evaluate permissions. Accordingly, can I add the following to ACL_SID:

 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 

That way, if I check the read for any E, I check if R1 is allowed for E D. OR, if I check if any letter E has a “record”, I can check what exactly to write in E.

Note. Coming up with the example above, I know there is a space to see if anyone has write permission. If we use MD to resolve permission for R1 instead of M itself, we will only get 'read' .. and if we add 'write' to ACL_ENTRIES for D, then all other E from M will also get 'write' (somewhere, as they should not). Assuming this is a problem with my scenario, consider the issue at a higher level.

Again the question: Should the main / SID in ACL_SID be userId / userName or can there be something else that can be interpreted differently.

Thanks at Advance. M. Rather

Answer 1

No, the sid in ACL_SID can be ROLE or any other GrantedAuthority supported by your system. You can, for example, provide the user with GrantedAuhtority for each department to which it belongs. To do this, you will need to implement your own UserDetailsService. In your implementation, UserDetails.getAuthorities () will return one GrantedAuhtority element for each department / role.

Answer 2

As far as I understand spring security, the full spring security domain is not associated with anything else, so the line principal PrincipalSid can be anything.

The only thing I know where you need to take care of is that the default ACL owner is always the current primary type of security context.