Spring ACL-主体/ SID不是用户，而是另一个实体

我正在考虑为我们的项目实施Spring ACL，这是非常严格且细粒度的安全性要求。我想知道某种情况是否可能。

基于Spring的ACL文档，可以为任何对象（ACL_OBJECT_IDENTY）授予ACL_SID的权限，并且该文档谈到SID是“主要” ..即当前登录的用户。

因此，如果我将四个部门（D1，D2，D3，D4）分配给两个经理（M1，M2），则M1可以管理D1和D2，M2可以管理D3和D4。我可以使用ACL轻松实现。

现在，我有一个这样的场景，其中部门有员工E1，E2 ...... E8（假设每个部门依次有两个员工，例如D4有E7和E8）。员工提交报告R *，我需要保护对以下报告的“读取”访问权限：1.员工本身。2.员工部门的经理。3.部门的其他员工。

和“管理员”对以下报告的访问权限：1.员工本身2.员工部门的经理。

通过对ACL的原始理解，甚至可以做到这一点，其中“本金”仅限于用户，例如E *或M *。如：

E1, E2.. E8
M1, M2..

对于每个报告，我们可以创建ACL_ENTRY，例如：

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

在这种情况下，我将检查是否有任何E *或M *可以访问R1。

一切都很好，但是我觉得如果E进出D或添加/删除M来管理D的话，管理（ACL条目）会变得太复杂了。

因此，问题是：我可以使用实体对象作为主体，并在需要评估权限时使用该对象来验证权限。因此，我可以在ACL_SID中添加以下内容：

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

然后将ACL_ENTRIES替换为：

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

这样，如果我正在检查任何E的读取，我将检查R1是否被允许访问E的D。或者如果我正在检查是否任何E具有“写”功能，则可以检查是否专门对E进行写操作。

注意：在上面的示例中，我知道有一个间隙，看看是否有M具有“写”权限。如果我们使用M的D来解析R1的权限，而不是M本身，则只会得到“如果我们在D的ACL_ENTRIES中添加“写入”，则M的所有其他E也将得到“写入”（在不应该的地方）。假设这是我的方案的问题，请从更高层次考虑该问题。

再问一个问题：ACL_SID中的主体/ SID是否始终必须是一个userId / userName，或者可以是其他任何可以不同解释的东西。

提前致谢。M·拉瑟