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

【问题标题】：spring ACL - principal/SID not as user, but another entityspring ACL - principal/SID 不是用户，而是另一个实体
【发布时间】：2011-07-27 23:20:39
【问题描述】：

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

一切都好，但我觉得这可能会变得太复杂而无法管理（ACL 条目），如果 E 进出 D 或添加/删除 M 以管理 D..

所以，问题是：我可以使用实体对象作为主体，并在需要评估权限时使用它来验证权限。因此，我可以在 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.宁可

【问题讨论】：

只是更深入地研究 Principal 的意图，我们在 java.security.Principal 的 API 中找到了这一点： public interface Principal 这个接口代表了一个 principal 的抽象概念，它可以用来表示任何实体，例如个人、公司和登录 ID。因此，理论上“D”（部门）可能是校长。 ??

标签： spring permissions spring-security acl

【解决方案1】：

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

【讨论】：

【解决方案2】：

据我了解 Spring Security，完整的 Spring Security 域与其他东西无关，所以 PrincipalSid 的 principal 字符串可以是任何东西。

我知道您唯一需要注意的是，ACL 条目的默认所有者始终是安全上下文的当前主体。

【讨论】：