我正在学习 Apache Shiro，我发现了这篇文章：
并且作者说：
.......如果需要，您可以将行为（权限）直接分配给角色。从这个意义上说，您仍将拥有基于角色的访问控制安全策略 - 只是您将拥有显式 RBAC 策略，而不是传统的隐式策略。
但这引出了一个问题——为什么要停留在角色上？您可以将行为直接分配给用户、组或您的安全策略可能允许的任何其他内容。
似乎作者更喜欢直接存储 User 和 Permission 的关系，而不是通过 Role。
虽然这看起来简单明了，但我有一些问题：
它们之间有什么本质区别吗？
数据库架构。
在基于角色的访问控制中，通常我们使用三个表来描述关系：
user
role
user_role
否，如果我使用基于资源的访问控制，构建表的正常做法是什么？
这是我第一次听说基于资源的访问控制。
我会非常小心地走这条路。在授权领域，基本上有两个标准：
基于资源的访问控制似乎是 Stormpath 发明的一种模型，只有他们支持。这可能很好，但它只适用于他们的环境。
基于角色和基于属性的访问控制是被 NIST 和其他标准化机构如 OASIS（SAML 和 XACML 于 10 年前定义并且今天仍然支持）所支持的广为接受的范例。
您的问题是：为什么基于角色的访问控制对您来说还不够？你有角色爆炸的问题吗？表达力还不够吗？您是否需要实现用户、资源和上下文之间的关系？
ABAC 和 XACML 可以让您做到这一点。不久前，我在 YouTube 上发布了一个简单的视频，该视频处理基于属性的访问控制。看看。_
底线是 RBAC 和 ABAC 是跨多个应用程序和层工作的标准。基于资源的访问控制仅特定于 Apache Shiro。