Question

我正在考虑为我们的项目实现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

Answer 1

不，ACL_SID中的sid可以是您的系统支持的ROLE或任何其他 GrantedAuthority 。例如，您可以为用户提供她所属的每个部门的 GrantedAuhtority 。为此，您需要实现自己的 UserDetailsService 。在您的实现中，UserDetails.getAuthorities（）将为每个部门/角色返回一个GrantedAuhtority元素。

Answer 2

据我了解Spring安全性，完整的Spring Security域与其他内容无关，因此principal的{{1}}字符串可以是任何内容。

我唯一需要注意的地方是，ACL Entry的默认所有者始终是安全上下文的当前主体。

spring ACL - principal / SID不是用户，而是另一个实体

2 个答案: