RBAC 的主要缺点是最常被称为“角色爆炸”：由于不同（现实世界）角色的数量越来越多（有时差异很小），您需要越来越多的（RBAC）角色来正确封装权限（RBAC 中的权限是对对象/实体的操作/操作）。管理所有这些角色可能会变得很复杂。

由于构成 RBAC 基础的抽象选择，它也不太适合管理个人权利，但这通常被认为不是问题。

通常提出的替代方案是 ABAC（基于属性的访问控制）。ABAC 没有角色，因此没有角色爆炸。然而，使用 ABAC，你会得到人们现在所说的“属性爆炸”。这两个问题在细节上有所不同，但在更抽象的层面上大体相同。（愤世嫉俗的人可能会指出 RBAC 解决方案的市场饱和以及由此产生的对“更新”和“更好”的访问控制解决方案的需求，但这是另一个讨论。）

RBAC 存在不同的问题，但正如 Jacco 所说，这一切都归结为角色爆炸。

RBAC 是：

• 以身份为中心，即关注用户身份、用户角色和可选的用户组
• 通常完全由 IAM 团队管理
• admin-time：角色和权限在管理时分配，并在它们被配置的持续时间内有效。

RBAC 有什么不好的地方？

• 它是粗粒度的。如果您有一个名为医生的角色，那么您将授予医生角色“查看病历”的权限。这将使医生有权查看所有医疗记录，包括他们自己的。这就是导致角色爆炸的原因
• 它是静态的。RBAC 不能使用上下文信息，例如时间、用户位置、设备类型……
• 它忽略资源元数据，例如医疗记录所有者。
• 很难管理和维护。很多时候，管理员会不断地向用户添加角色，但永远不会删除它们。您最终会拥有数十个甚至数百个角色和权限的用户
• 它不能满足动态的职责分离。
• 它依赖于应用层（API、应用程序、数据库...）中的自定义代码来实现更细粒度的控制。
• 访问审查是痛苦的、容易出错且冗长的

ABAC 是解决方案吗？

ABAC - 基于属性的访问控制 - 是处理授权的下一代方式。它由NIST和OASIS以及开源社区 (Apache) 和 IAM 供应商（Oracle、IBM、Axiomatics）推动。

ABAC 可以看作是授权，即：

• 外部化：访问控制从业务逻辑外部化
• 集中式：访问控制策略集中维护
• 标准化：访问控制策略使用 XACML，可扩展访问控制标记语言，由 OASIS 定义并由大多数 ABAC 解决方案实施的标准
• 灵活：ABAC 可应用于 API、数据库等
• 动态：访问决策是在运行时动态做出的
• 基于上下文/基于风险：ABAC 在做出决策时可以考虑时间、位置和其他上下文属性。

ABAC 提供：

• 具有策略决策点 (PDP) 和策略执行点 (PEP) 概念的架构
• 策略语言 (XACML)
• 请求/响应方案 (JSON/XACML)

基于角色的访问控制是一种访问控制策略，它基于定义和分配角色给用户，然后授予他们相应的权限。

缺点：

以下是 RBAC（基于角色的访问模型）的缺点：

1. 如果你想为大企业创建一个复杂的角色系统，那么这将是一个挑战，因为将有成千上万的员工角色很少，这可能会导致角色爆炸。

2. 使用 RBAC，可以对访问系统的某些操作进行一些限制，但您不能限制对某些数据的访问。

3. 权限和特权可以分配给用户角色，但不能分配给操作和对象。