简单的谷歌搜索会给你这个问题的答案。

像Axiomatics这样的供应商非常愿意回答这个问题。

美国政府也有意见

除非您关注该领域，否则您可能错过了1 Raindrop，但我认为它很好地回答了您的问题：

在我看来，XACML 和 ABAC 的价值实际上在于它们启用的用例。它是外向型的，通过新型服务释放价值。. . .

总结就是 ABAC 允许您更简单地表达丰富、复杂的访问控制策略。大多数访问控制策略（我正在查看您的 RBAC）依赖于某处的“某人”来更新策略，因为员工从工作转移到工作或责任转移到责任。人们会因临时需要而被添加，并且永远不会被删除。实施该政策有一个巨大的后端。

我能举出的最简单、最酷的例子来自一个真实世界的例子。事实证明，酒吧的保镖/调酒师正在检查 ID，并在记忆/复制可爱女性的信息。然后他们要么跟踪这些女人，要么等到这些女人喝得够多，判断力受损，然后开车送她们回家。这是发生坏事的机会。酒吧实施了 ABAC 解决方案。当这些女性进入时，她们将自己的身份证提交给一台机器，该机器要么发行腕带，要么将信用卡标记为 21 岁以上/以下。访问控制（酒精）是基于单一属性（超过/低于 21）决定的，没有透露任何额外的信息。

ABAC，如果作为身份基础设施的一部分实施，则意味着当 Mark Wallace 从开发人员组转移到项目经理组时，他的访问控制权限将更新，因为他更改了主管、工作站和职位，而不是因为有人记得他具有管理员权限并花时间在某处更新配置文件。人力资源部门认为跟踪我的主管是谁非常重要，并且他们在保持这些信息最新方面具有既得利益；我的权限来自那些有机的决定。

缺点？部署并不多，因为它仍然是一种新事物，而且只有在部署足够的基础架构时才能获得全部好处。供应商仍在尝试正确实施正确的协议。还有很多事情需要解决。

作为对上一个答案的扩展，我想补充一点，肯定有缺点（[哲学上]没有什么是没有的）。我看到以下内容：

• 努力定义策略：您需要投资于识别与做出 AuthZ 决策相关的属性，并从中制定策略。这可能比仅仅定义角色要困难得多。
• 用户培训：每个人都可能成为 ABAC 解决方案的管理员，至少对于他自己的数据而言。不仅有专门的管理人员负责处理 AuthZ 问题。
• 技术实施工作。您不能购买安装和运行 ABAC 解决方案。LDAP 等现有方法（理想情况下）不需要在您的软件或 COTS 中进行自定义编码。这与 ABAC 不同，因为每个 PEP 都需要询问 PDP，而且我知道没有支持这一点的现有软件，即使是像 XACML 这样的标准也是如此。

Mark C. Wallace 在另一个答案中给出了很好的解释。在这里，我会尝试给出一些我个人（和哲学）的观点。

• 从循环中消除人：虽然不是完全，但 ABAC 通过将用户属性与权限策略直接绑定，从访问控制循环中消除（更准确地说是减少）人。在 RBAC 中，我们总是需要一个管理用户来从角色中添加/删除常规用户。这种管理开销可能是我们在适应 RBAC 时付出的最高代价。

• 缺失环节的建立：尽管 RBAC 没有谈论它们，但隐含的属性概念仍然存在。属性的变化是角色分配变化背后的原因。在 RBAC 中，管理员在为角色分配或取消分配用户时手动维护这些更改。ABAC 将这些属性识别为缺失的环节，并在访问控制决策中强调其存在。因此，ABAC 在推理访问控制时提供了更高的透明度。