基于Spring安全框架实现安全解决方案，特别是其acl模块。 应用程序中有数百万个域对象和数百个用户。 使用Spring Security Acl模块，acl_sid和其他相关表中的条目增长到10亿，这会影响应用程序的性能。 想知道处理此类场景的最佳实践。 是否有任何替代安全框架可以有效地处理类似情况。
有几个框架可以使访问控制更易于管理。
首先，ACL非常好且易于配置，但它们不能很好地扩展。
RBAC是NIST在1992年定义的一个众所周知的模型。许多应用程序和框架实现了RBAC模型。在RBAC中，您为用户提供一组角色，每个角色都有一组权限。因此，用户继承这些权限。例如，您可以拥有一个具有查看所有事务权限的经理角色。
Spring Security，Apache Shiro，JAAS和许多其他框架（开源，商业......）实现了RBAC。
有时RBAC是不够的。特别是当您想要使用上下文或关系时。例如，在RBAC中，很难实现处理以下内容的角色和权限：
经理可以查看自己部门的交易
为此，您将使用ABAC。您将定义角色属性，用户部门属性和事务部门属性。然后，您将在策略中将属性组合在一起：
如果user.department == transaction.department，具有role == manager的用户可以执行action =='view transaction'
XACML是可扩展访问控制标记语言，是OASIS定义的标准，越来越多地用于实现复杂的授权挑战。今天有几个实现：
在访问控制列表中，每个要保护的项目都有一个列表，您必须在这些列表中插入用户身份。您可能还想添加操作数据，以便最终得到：
如果你有100万个项目和10,000个用户，你可能有100万x 10k x 3个动作（读，写，删除）=总计300亿行。这等同于管理噩梦，但也可能是性能问题。
现在RBAC的想法是简化这一点。我们使用角色和权限作为间接级别，而不是将用户分配给ACL中的项目。所以爱丽丝会成为一名编辑。鲍勃和卡罗尔将成为观众。您的ACL现在更简单：
名单越来越小。然而RBAC仍有几个问题。它仍然必须具有每个对象的ACL。如果你有一百万个对象，你仍然会有几百万行（但仍然比300亿更好）。
使用ABAC，您可以选择使用对象属性，例如部门或分类。对象不再具有ACL，您最终编写使用这些属性的策略。这使得策略的数量变小（通常为数百个）。
由于属性，ABAC更好地扩展。