如果您的客户网站由多个人维护，那么您应该考虑提供基于角色的ACL[访问控制列表]。基于角色的ACL[访问控制列表]是什么，为什么您应该使用它而不是Joomla 1.5中应用的ACL[访问控制列表]方法呢？

坦白说，Joomla 1.5存在一个明显的问题，这阻碍了其在许多企业项目中的应用。网站开发者在这种情况下被极度限制，无法为支持该网站的工作人员提供不同的角色。

该网站不同部分的责任无法相互隔离。如果用户需要某个功能或特定组件，该组件要求用户拥有“管理员”权限，那么我们不得不将此用户指定为管理员。几乎不可避免地，我们必须授予比任何单个用户所需的更多权限和访问权限。对于大多数公司来说，这种限制是不可接受的。

幸运的是，这一限制在Joomla 2.5版本中被取消。但问题是...许多网站开发者并没有从1.5版本的ACL[访问控制列表]模型中跳出来得太远。

基于角色的ACL[访问控制列表]是什么样的呢？

角色倾向于代表一些逻辑任务或一组职责，这些职责属于组织或公司内部。它可以分配给某个个人，也可以转移到其他个人或在他们之间共享。某个“角色”是组织定义和普遍理解的某种概念。

例如，“执行订单”角色将允许某个用户访问订单，访问运输信息，改变订单状态和调整库存中销售的商品数量。但可能需要另一个角色来管理商品信息，而另一个角色可能用于访问客户财务信息或处理退款。一个用户可能被指定所有这些角色，而另一个用户只被指定其中一个。用户的全部权限由分配给他们的角色集合确定。

典型角色的特点

与角色关联的访问和权限恰好足够执行任何任务或相关任务集。这包括“最小权限”原则。

一个角色的任务和义务与其他角色的任务和义务是隔离的（通常不会重叠）。这包括[实施]“职责分离”原则。

1. 角色是[网站]各部分的组合代表，这些部分的访问权限通过权限级别来分配。
2. 一个人可以分配一个或多个角色。
3. 可能有多个人共享同一个角色。
4. 在用户中，某个角色可以轻松添加、删除或迁移。
5. 任何角色在名称和能力上都符合该“角色”的商业概念。

在Joomla 1.5中，大多数这些功能都无法应用。所有这些功能都可以在2.5中应用。2.5的ACL（访问控制列表）模型为我们提供了应用所有这些特性的能力，但它既不要求也不强迫我们这样做。实际上，默认的2.5版本的ACL配置看起来就像1.5版本的ACL配置。

基于角色的ACL与默认的ACL有显著区别。

ACL Manager插件的开发者Sander Potjer告诉我，他更喜欢删除大多数默认安装的用户组，并根据任何给定的项目需求重建用户组。对于基于角色的解决方案来说，这很有意义。直到最近，这可能并不实用。太多的扩展开发者在为1.6/1.7/2.5版本提供ACL初始支持方面失败了。因此，我们无法为这些组件使用任何任意的组，我们不得不将某个用户分配给“manager”组甚至“管理员”组。幸运的是，当前版本的“ACL Manager”可以自动为2.5版本缺少ACL组件的组件提供初始ACL。最后，我们甚至可以删除“manager”和“administrator”组。如果您完全采用基于角色的方法，那么它们无疑不再需要。

我们在基于角色的模型中获得什么？

应用于某公司的基于角色的模型非常接近该公司的业务规则。商业领导者理解角色的概念，并且多项组织研究显示，他们更喜欢根据分配给人们的不同角色来定义和控制访问。如果我们根据我们的业务规则建模我们的ACL，那么我们将向客户提供一个内容管理系统，该系统能够适应其员工的需求和未来的变化。

思考公司面临的现实情况：员工和员工的职责会随着时间的推移而变化。人们来来去去，职责在转移。角色可能需要快速分配、撤销或更改。有时，某个角色会被多人共享。经常，某个员工会拥有多个角色。角色应该个别分配，有时某个角色可能因为不适合职位或用户类别而被分配或撤销。智能安全要求人们只能访问他们所需的内容。

公司理所当然地期望能够做到这一切。如果我们调整ACL以围绕基于角色的组来组织它，那么我们就为我们的客户提供了一个直观且易于管理的用户和角色管理系统。

分配给用户的角色会影响该用户在管理面板中的访问权限。

这幅图像展示了基于角色的ACL（访问控制列表）的三种优势。第一：将角色分配给用户是直观的。它使用公司能理解的术语。访问控制根据组织如何理解和定义其员工角色进行分段。管理用户和分配用户权限的主要角色应属于最合适的人——即使这个人缺乏该系统的技术知识。这个基于角色的系统足够直观。

第二：角色可以自由组合，可以针对单个用户唯一组合。这反映了与员工或志愿者群体工作的现实情况。

第三：CMS的每个用户将只能访问执行该角色任务所需的[相关]部分。如果我们设置了基于角色的访问级别，这些级别与基于角色的用户组[匹配]，那么我们就可以实现您在这里看到的：每个用户都看到为分配给他的或她的角色定制的行政控制面板。

关于ACL（访问控制列表）的另一种思考方式。

本文介绍了关于访问控制的另一种思考方式。这不是一个新的模型。“基于角色的访问控制”（RBAC）在1996年得到正式描述，并被公司和信息管理系统广泛使用。实际上，Joomla系统的新ACL结构[访问控制列表]与RBAC1模型相符合；如果我们把Joomla系统的“用户组”看作是“角色”而不是“用户类型”（这是一个细微但非常重要的区别）。因此，Joomla!确实为构建严肃的基于角色的访问控制系统提供了基础。

本文为转向基于角色的方法构建了论点。下一篇文章将探讨应用并展示一个工作场景。

可能不偏离[Joomla 1.5中采用的]模型看起来更安全。但那些由多人维护的网站的组织期望更好的东西。我们可以提供更好的东西。当我们把Joomla!带给公司和大组织时，我们必须提供最好的东西。

译者注：在这两篇关于ACL（访问控制列表）的第一篇文章中，作者Randy Carey探讨了ACL的基本概念和原则，主要从满足网站所有者业务需求的角度进行探讨。在下一篇文章“应用基于角色的ACL”中，将探讨如何将这些原则应用于实践。