我正在学习 Apache Shiro，发现了这篇文章：
新的 RBAC：基于资源的访问控制 http://www.stormpath.com/blog/new-rbac-resource-based-access-control
作者说：
......您可以将行为（权限）直接分配给角色，如果您
想。从这个意义上说，您仍然拥有基于角色的访问控制
安全策略 - 只是你会有一个明确的 RBAC 策略
而不是传统的隐性策略。
但这引出了一个问题——为什么要止步于角色？您可以分配
直接针对用户、群组或任何其他您的行为
安全策略可能允许。
看来作者更喜欢直接存储User和Permission的关系，而不是通过Role来存储。
虽然这看起来简单明了，但我有一些问题：
他们两者之间有什么本质区别吗？
数据库架构。
在基于角色的访问控制中，通常我们使用三个表来描述关系：
user
role
user_role
否，如果我使用基于资源的访问控制，构建表的正常做法是什么？
这是我第一次听说基于资源的访问控制。
走这条路我会非常小心。在授权领域本质上有两个标准：
- 基于角色的访问控制 (RBAC)，由NIST http://csrc.nist.gov/groups/SNS/rbac/并在主要供应商（CA、Oracle、IBM...）的支持下在数千个应用程序和框架中实施
- 基于属性的访问控制 (ABAC) 的标准化NIST http://csrc.nist.gov/publications/drafts/800-162/sp800_162_draft.pdf (also here http://csrc.nist.gov/projects/abac/）并且同样得到 IBM、Oracle 和我工作的 Axiomatics 等供应商的良好实施。
基于资源的访问控制似乎是 Stormpath 发明的模型，并且仅由他们支持。这可能很好，但只适用于他们的环境。
基于角色和基于属性的访问控制是 NIST 和 OASIS 等其他标准化机构（其中 SAML 和 XACML 于 10 年前定义的，至今仍受支持）支持的广泛接受的范式。
您面临的问题是：为什么基于角色的访问控制对您来说还不够？您有角色爆炸的问题吗？是不是表现力不够？您是否需要实现用户、资源和上下文之间的关系？
ABAC 和 XACML 可以让您做到这一点。我不久前在 YouTube 上发布了一个简单的视频，该视频涉及基于属性的访问控制。有一个look http://www.youtube.com/watch?v=xUEbBKnxWSo.
最重要的是，RBAC 和 ABAC 是跨多个应用程序和层工作的标准。基于资源的访问控制仅特定于 Apache Shiro。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
