我正在考虑为我们的项目实现Spring ACL，这是非常严格和细粒度的安全要求。我想知道某种情况是否可行。
基于Spring的ACL文档，任何对象（ACL_OBJECT_IDENTY）都可以获得ACL_SID的许可，文档中谈到SID是“主体”..即当前登录的用户。
所以，如果我有四个部门（D1，D2，D3，D4）分配给两个经理（M1，M2），那么M1可以管理D1＆amp; D2和M2可以管理D3和D4 ..我可以使用ACL轻松实现。
现在，我有一个场景，如部门有员工，E1，E2 ...... E8，（假设每个部门依次有两个......比如D4有E7和E8）。员工提交报告R *，我需要保护这些报告的“读取”访问权限： 1.员工本身。 2.员工部门经理。 3.该部门的其他员工。
和'admin'可以访问这些报告： 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添加'write'，那么M的所有其他E也会'写''（不应该在哪里）。假设这是我的方案的一个问题，请在更高层次上考虑这个问题。
同样问题： ACL_SID中的主体/ SID是否必须始终是userId / userName，或者是否可以是其他任何可以不同方式解释的内容。
先谢谢。 M. Rather
答案 0 :(得分：1)
不，ACL_SID中的sid可以是您的系统支持的ROLE或任何其他 GrantedAuthority 。 例如，您可以为用户提供她所属的每个部门的 GrantedAuhtority 。为此，您需要实现自己的 UserDetailsService 。 在您的实现中，UserDetails.getAuthorities（）将为每个部门/角色返回一个GrantedAuhtority元素。
答案 1 :(得分：0)
据我了解Spring安全性，完整的Spring Security域与其他内容无关，因此principal的{{1}}字符串可以是任何内容。
我唯一需要注意的地方是，ACL Entry的默认所有者始终是安全上下文的当前主体。