是否始终需要ACL？

Question

对于具有高度复杂的访问控制规则的Web应用程序，您是否始终使用ACL？

在确定用户权限时，我有很多考虑因素，包括：

• 他们是否已登录？
• 他们是管理员还是普通用户？
• 他们是在浏览图表中的节点吗？
• 他们在浏览什么类型的节点？
• 他们与节点的关系是什么（即节点的路径）？
• 用户的默认设置是什么？
• 节点的默认设置是什么？
• 将用户连接到节点的图形边缘的设置是什么？
• 等

开发ACL证明是困难的。过了一会儿，我采取了对每个动作顶部的基本属性进行“if / then”检查，例如： if(isAdmin) {...}

这似乎工作正常，我想知道是否应该将其作为永久性解决方案留在原地。因此，问题是：访问控制的复杂性是否会超过ACL？或者只是我需要更努力一点？

Answer 1

当您的访问控制模型变得过于复杂，因为访问不再仅基于用户的身份时，您希望转移到另一个访问控制模型。

您可以使用基于角色的访问控制（RBAC），其中权限分组为角色，角色分配给用户。 Active Directory和其他LDAP产品允许您执行基于角色的访问控制。

但是，如果您想要实现的不仅仅是角色，尤其是您想要考虑关系，图形和图形边缘，那么您需要使用基于属性的访问控制（ABAC）。在基于属性的访问控制中，您可以实现授权逻辑，该逻辑考虑用户属性（他们的角色，部门，位置，年龄，公民身份......）以及资源属性（节点在图表中的位置，边缘...... 。）以及节点和用户之间的关系。

我在ABAC上传了一段视频：www.youtube.com/watch？v = xUEbBKnxWSo CERIAS也有一些很棒的：www.youtube.com/watch?v=3ZCoupGHmwo

今天实施ABAC的主要标准是XACML，即可扩展访问控制标记语言。我会研究XACML（免责声明 - 我为Axiomatics工作，XACML供应商）。

您可以查看供应商和开源XACML实现。

使用XACML，而不是拥有一堆if（isAdmin）和if（validCitizen）语句，最终会得到一个if（isAuthorized（））语句。实际的授权逻辑集中在用XACML表示的策略中。这也称为外部授权。

Answer 2

首字母缩略词ACL代表访问控制列表。因此，根据定义 - 只要您根据用户所属的用户或他们所属的组控制用户访问权限，您就拥有了ACL。

所以对第一个问题的简短回答是，是的，你总是使用ACL。

至于其他问题，我会对他们两个说“是”

ACL可能变得比它控制的应用程序要复杂得多 - 例如，如果您想要对用户可以执行的操作进行过于精细的控制。因此，如果你认为它变得复杂 - 看看你是否能够“愚蠢”，将一些ACO组合在一起甚至删除它们（并允许所有用户访问它们）。