您似乎将 RBAC 和 DAC（自由访问控制）混为一谈：拒绝访问通常不用于 RBAC，而是来自 DAC 世界。经常看到 NTFS ACL（访问控制列表）中包含 DENY。

您可能正在尝试实现一个合并模型（请参阅我在此处的回复中的示例） - 例如，使用指向角色的 ACE（访问控制条目）构建一个 ACL。例如，使用组来授予对文件夹的访问权限...

您可以使用两种可能的解决方案，甚至可以混合使用，这取决于对您的系统有意义的方式（我已经在不同的上下文中构建并使用了这两种解决方案）：

• 有序 ACL - 即 ACL 不是一大堆 ACE，但它们按特定顺序排列：列表中较高的优先，继续评估 ACE，直到找到该用户的 PERMIT ACE或DENY ACE。谁在名单上，谁就赢了。
• DENY ACE 会覆盖所有其他 ACE。即，如果通过 Role1 授予用户访问权限，则扫描 ACL 以查找适用于该用户的任何 DENY，然后 Role2 无论如何都会阻止访问。

请注意，您可能没有使用标准 ACL 模型来实现这一点，而实际上只检查用户角色 - 这仍然很好，上述内容仍然适用（只是更难以可视化和解释）。

您需要弄清楚的真正问题是，什么对您的系统有意义？您是否正在尝试实施 SoD（职责分离/职责分离）？如果是这样，很明显 DENY 必须覆盖任何 PERMIT。如果您希望用户配置它（在这种情况下是它的 DAC，而不是 RBAC），第一个选项提供了最大的灵活性，因为有一种方法可以解决它。

我不确定这是一个众所周知的问题。如果您的默认位置是拒绝所有人，并且应该如此，那么规则应该只说明每个角色可以做什么。如果用户/角色完全可以根据任何规则访问资源，我认为应该允许它们。

您可能需要重新考虑您的角色布局方式。我认为在冲突中，最高的特权会获胜。工具可能会以不同的方式处理这个问题。重要的是要准确了解您的环境是如何工作的，而不是它应该如何工作。

我可能遗漏了一些东西，但使用“积极角色”之类的概念不是一个相当简单的解决方案吗？

换句话说，用户从分配给他们的角色列表中选择他们的活动角色，然后您只需针对该单个角色检查 ACL。

您可能需要考虑使用我听说的基于混合声明的访问安全性。在此模型中，基本上每个任务都被分解并用作配置文件，以使安全性更易于管理（尽管最初难以实施）。

基本上设置表类似于：

Users --> Groups --> Profiles --> Rights
 |         |_______________________^
 |____________________^
 |_________________________________^

用户表，每个用户可能有一个或多个组 用户也可能有一个或多个配置文件（也称为任务权限的子组） 用户也可能有一个或多个权限 组有一个或多个配置文件 组可能有一个或多个权限配置文件可能具有一项或多项权限

缺点来自面向任务的额外组层，但是对于大多数非开发人员来说更容易概念化这种设计。

您也可以使用纯粹的基于索赔的系统，但很难维护像 IMO 这样的长期系统。使用标准 RBAC（不是 RB-RBAC）可能会更好，并使用一组一致的规则，例如冲突 = 拒绝访问。