6分钟阅读时间 (1145字)

基于角色的ACL案例分析

A Case for Role-Based ACL

如果你的客户有多个人维护网站,你应该考虑提供基于角色的ACL。什么是“基于角色”的ACL,为什么你应该使用它而不是1.5版本的ACL方法?

坦白说,Joomla 1.5有一个明显的缺陷,使其不适合许多企业项目。网站开发者为员工提供不同角色以维护网站的能力极其有限。

ACL Groups in Joomla 1.5
1.5版本的ACL

ACL Groups - as installed by default in 2.5
2.5安装了与1.5类似的一组组

网站不同部分的责任无法相互独立。如果用户需要一个功能或需要用户是“管理员”的特定组件,我们必须让该用户成为管理员。几乎不可避免的是,我们会给用户更多的权限和访问更多区域,而不仅仅是他们需要的。这种限制对大多数公司来说是无法接受的。

幸运的是,这种限制在2.5中已被移除。问题是……许多网站开发者并没有远离1.5版本的ACL模式。

基于角色看起来是怎样的?

一个角色通常代表组织或公司内部的一些逻辑任务或一组责任。它可以分配给个人,并可以被其他个人转让或共享。一个“角色”是一个组织定义并经常理解的概念。

例如,“订单履行”的角色将赋予用户访问订单、访问运输信息、更改订单状态和调整销售产品的库存计数的能力。但可能还需要另一个角色来管理产品信息,另一个角色来访问客户的财务信息或提供退款。一个用户可能被分配所有这些角色,而另一个用户只被分配其中一个。用户的全部能力由分配给他的角色的集合确定。

角色的典型特点

与角色相关的访问权限和权限仅足以执行一项任务或一系列相关任务。这实现了“最小权限”原则。

一个角色的任务和职责与其他角色的任务和职责是隔离的(通常不重叠)。这实现了“职责分离”的原则。

  • 一个角色代表可以访问的不同区域,并具有相应的权限级别。
  • 一个人可以被分配到多个角色。
  • 可能有多个人共享同一个角色。
  • 角色可以轻松地添加、删除或在用户之间转移。
  • 角色在名称和能力上与该“角色”的商业概念相对应。

example of a role-based approach to ACL

大多数这些功能在 Joomla 1.5 中无法实现。所有这些在 2.5 中都可以实现。2.5 的 ACL 模型使我们能够实现所有这些特性,但它并不要求或强制我们这样做。实际上,默认的 ACL 配置看起来就像并模仿了 1.5 的 ACL。

基于角色的 ACL 与我们直接获得的 ACL 有显著的不同。

Sander Potjer,ACL Manager 的开发者告诉我,他更喜欢删除大部分默认的用户组,并根据特定项目需要重新构建用户组。对于基于角色的解决方案,这很有意义。直到最近,这可能并不实用。太多的扩展开发者未能为他们的 1.6/1.7/2.5 组件提供基本的 ACL 支持。因此,我们无法使用自定义组来访问这些组件——我们不得不将用户分配到“管理者”甚至“管理员”!幸运的是,ACL Manager 的当前版本可以自动为缺乏 ACL 的 2.5 组件提供基本 ACL。最后,我们可以忽略甚至删除“管理者”和“管理员”。如果你实施了 100% 的基于角色的方法,可以说你不再需要它们。

基于角色的方法给我们带来了什么?

基于角色的模型与组织的业务规则非常接近。商业领导者理解角色的概念,对几个组织的研究表明,他们更喜欢以个人分配的各种角色来定义和管理访问控制。如果我们根据他们的业务规则建模我们的 ACL,我们将向我们的客户提供一款适应他们的员工需求和未来变化的 CMS。

考虑企业面临的现实:随着时间的推移,员工和员工职责会发生变化。人员进出,责任转移。角色可能需要快速分配、删除或更改。有时多人会共享一个角色。通常,员工会保留多个角色。角色应按个人分配,有时可能将角色分配或删除作为职位名称或用户类别的例外。智能安全要求人们只能访问他们所需的内容。

企业期望能够做所有这些。如果我们定制 ACL 以围绕基于角色的组组织,那么我们向我们的客户提供了一种直观且易于管理的用户和用户角色管理系统。

the roles to which a user is assigned affects what that user has access to in the backend

此屏幕截图展示了基于角色的 ACL 的三个好处。首先,将角色分配给用户的方式直观易懂。它使用了商业界可以理解的术语。访问控制是根据组织理解和定义角色的方式来分段的。管理用户和分配用户权利的重要角色应属于最合适的人——即使这个人缺乏对系统的技术理解。这种基于角色的系统足够直观。

其次,角色可以自由聚合,并且可以按用户唯一聚合。这反映了员工和志愿者队伍的现实。

第三,CMS 的每个用户都只能访问属于该角色的任务所需的部分。如果我们设置了与基于角色的组相对应的基于角色的访问级别,我们就可以实现您所看到的效果:每个用户都看到为他们分配的角色的后端。

关于 ACL 的另一种思维方式

本文介绍了一种关于访问控制的不同思维方式。它不是一个新的模型。“基于角色的访问控制”(RBAC)于1996年正式描述,并被企业和信息系统广泛使用。事实上,Joomla的ACL新结构对应于所谓的RBAC1模型——如果我们用Joomla的“用户组”来表示“角色”而不是“用户类型”(这是一个微妙但重要的区别)。因此,Joomla!确实为构建一个基于角色的访问控制系统奠定了基础。

本文支持转向基于角色的方法。后续文章将讨论实施并展示一种可行的方法。

可能看起来不偏离1.5模型会更安全。但拥有多人管理网站的组织期望更好的东西。我们能够提供更好的。当我们把Joomla!带到企业和大型组织时,我们需要提供更好的。

在Joomla社区杂志上发表的一些文章代表了作者在特定主题上的个人观点或经验,可能不代表Joomla项目的官方立场。

1
Joomla! 网站:%E5%86%A4%E8%80%85%E9%A1%B5%E9%9D%A2
 

评论 1

已经注册? 登录这里
ssnobben 在 2021年8月22日 周日 09:22

很棒的教程!非常感谢这些实用的教程!希望看到更多关于Joomla 4的内容!

0
很棒的教程!非常感谢这些实用的教程!希望看到更多关于Joomla 4的内容! :p

通过接受,您将访问https://magazine.joomla.net.cn/之外的第三方提供的服务