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