symfony - silex 中的模块权限与角色权限

Question

我对 symfony/silex 中的 ACL 以及如何让它们为我工作感到非常困惑。

我一直在考虑基于模块 -> 操作的解决方案。然而，阅读有关 ACL 的内容后，一切似乎都基于角色，这对于我想要实现的实现来说过于广泛。

我将拥有用户，并且所有用户都属于一个角色(管理员、用户等...)。但是，角色更多地是您可以执行的操作的指南(因为它设置具有该角色的用户开始时的默认权限)，而不是用户可以执行的一组实际操作。这些操作实际上基于系统拥有的模块以及实际授予任何用户的读取、添加、更新、删除以及除这些之外的任何其他动词的权限。

例如: 角色#1:是管理员

• 可以读取用户
• 可以发布用户
• 可以放置用户
• 可以删除用户

角色#2:管理员

• 可以读取用户
• 可以发布用户
• 无法放置用户
• 无法删除用户

由于我计划拥有多个不同的模块(用户、付款、产品等)，并且每个管理员都可以授予或撤销权限，因此它们不适合 ROLE_ADMIN、ROLE_SUPER_ADMIN、ROLE_USER 类型的角色。

我在想一些关于 ROLE_VIEW_USERS、ROLE_ADD_USERS、ROLE_EDIT_USERS 的事情，一个用户可能会拥有 100 个这样的小角色，并且每个 Controller 都有投票者来决定你是否可以执行某些操作。

这有道理吗？

Answer 1

您混淆了 ACL 和角色。它们都与权限有关，但它们的方法和功能彼此不同。

角色本质上并不与特定资源相关联。另一方面，ACL 是，并且该链接是持久的。通过使用选民，用户可以与资源绑定(bind)(或看起来如此)。

https://symfony.com/doc/current/security/voters.html#creating-the-custom-voter

用户特定的 ACL，例如如果用户具有定义的 PER 资源的特定访问权限，您将需要更多的东西。

看看 SF 食谱:

https://symfony.com/doc/current/cookbook/security/acl.html https://symfony.com/doc/current/cookbook/security/acl_advanced.html

所有者/主人/运算符(operator)可以

• 编辑
• 查看
• 删除
• 创建

所有资源(这是使用角色完成的)

---

ROLE_USER 可以

• 自行编辑
• 查看自己的
• 删除自己的
• 创建

自己的资源(这部分由 ACL 或投票者完成)

选民实际上正在创建自己的 ACL，因此除非您明确创建一个，否则不会有持久的权限(此时我会选择 ACL)。 ACL 的用例与投票者的用例基本相同，选择其中之一是一个复杂的问题。

内置的 ACL 信息来自数据库，但根据 SF 文档:“它可以包含数千万[记录]，而不会显着影响性能。”

非常简单？可以使用投票者。

如果您不想维护自己的资源规则(投票者)并且不介意 ACL 的复杂性，或者喜欢持久化 + 缓存权限，则可以改用 ACL。

请注意，创建资源时 ACL 的复杂性通常如下(尽管这可以放入服务中):

$aclProvider = $this->get('security.acl.provider');
$objectIdentity = ObjectIdentity::fromDomainObject($resource);
$acl = $aclProvider->createAcl($objectIdentity);
$tokenStorage = $this->get('security.token_storage');
$user = $tokenStorage->getToken()->getUser();
$securityIdentity = UserSecurityIdentity::fromAccount($user);
$acl->insertObjectAce($securityIdentity, MaskBuilder::MASK_OWNER);
$aclProvider->updateAcl($acl);

对于前面的场景，您可以使用 ROLE_USER 来确保经过身份验证的用户实际上是实际用户，而不是 AUTHENTICATED_ANONYMOUSLY，并使用投票者或 ACL 来确保他们只能编辑自己的资源，如果他们的 ROLE 则覆盖此设置是 ROLE_ADMIN。 (假设用户注册后获得 ROLE_USER)

security.yml 中的示例

# This could be done via @Secure(roles="ROLE_USER")
access_control:
    - { path: ^/my/api/endpoint, role: IS_USER, requires_channel: https }
    - { path: ^/my/admin/api/endpoint, role: IS_ADMIN, requires_channel: https }

controller::action 中的示例

// check for edit access
if (
    false === $authorizationChecker->isGranted('EDIT', $resource) &&
    false === $this->get('security.context')->isGranted('ROLE_ADMIN')
) {
    throw new AccessDeniedException();
}

这是 StackOverflow 中的另一个 QA，也提供了一些示例:

Symfony 2 ACL and Role Hierarchy

您还可以对这些内容使用注释:

https://symfony.com/doc/current/best_practices/security.html#authorization-i-e-denying-access (它显示了一个与另一个的工作原理)。

如果其中任何部分需要进一步解释，请告诉我。

谢谢。