网站内容管理系统后台 设计(不论是后台管理系统，“人员权限”始终是绕不开的话题)

　　网站内容管理系统后台 设计(不论是后台管理系统，“人员权限”始终是绕不开的话题)

　　后台系统设计-角色权限一、前言

　　无论后台管理系统如何，“人事权限”始终是一个不可避免的话题​​。无论是移动端还是PC端产品，都需要一个账号登录。仅C端产品，大部分用户只需要自己注册。

　　对于后端产品，需要公司内部人员创建账号。每个使用系统的用户都有一个唯一的账号，每个账号都有自己对应的权限。

　　大多数情况下，除了超级管理员，我们会对大多数账户的权限进行一些限制，以管理不同用户的权限。

　　比如做业务用软件的时候，不同部门、不同岗位的人有不同的权限；再比如，付费产品的付费用户和免费用户的权限也完全不同。

　　如果每个用户单独控制权限，当系统用户非常大时，会发现以下问题：

　　很多账号权限是一样的，但是每次都要重新配置；

　　当需要修改某类用户的权限时，不能批量修改，只能逐个修改，非常耗时；

　　二、经典模型-RBAC

　　这时，智能产品的祖先创造了“角色”的概念，通过权限集的抽象来创建角色，修改角色的权限来控制拥有角色的人的账户的权限。

　　1、RBAC——基于角色的访问控制

　　其基本思想是系统操作的各种权限不是直接授予特定用户，而是在用户集和权限集之间建立一个角色集。每个角色对应一组相应的权限。一旦为用户分配了合适的角色，该用户就拥有该角色的所有操作权限。

　　这样做的好处是不需要每次创建用户都分配权限，只要给用户分配相应的角色，角色的权限变化远小于用户的权限变化，这样会简化用户的权限管理以减少系统开销。

　　根据百度百科对RBAC的定义，我们可以理解为这种模型是通过角色关联用户和角色关联权限间接授予用户权限。

　　2、类别

　　RBAC模型分为RBAC0、RBAC1、RBAC2、RBAC3

　　RBAC0：是RBAC的核心思想。完全支持 RBAC 概念的任何系统的最低要求。

　　RBAC1：RBAC 角色的分层模型。加入了角色分级的概念，一个角色可以继承另一个角色的权限。

　　RBAC2：添加了 RBAC 约束模型。增加了一些限制，强调在RBAC的不同组件中对配置的一些限制。

　　RBAC3：实际上是 RBAC2 + RBAC1。称为统一模型，它包括 RBAC1 和 RBAC2，并使用传递性来包括 RBAC0。这些模型构成了 RBAC96 模型系列；

　　下面，我以最基础的RBAC0为例，说说角色权限系统：

　　三、RBAC01. user-role-authority 的关系

　　通过上面的分析，我们已经知道，在这个模型中，涉及到三个专有名词，分别是user、role、authority。以下是我对这三个词的简单定义：

　　用户：使用系统的人；

　　作用：权限的集合；

　　权限：数据权限、功能权限（页面权限+操作权限）；

　　在这个RBAC0模型中，我们给角色分配权限，然后将用户和角色关联起来，继承角色对应的权限。用户和角色、角色和权限都是多对多的关系。用户拥有的权限等于其角色所拥有的所有权限的并集；

　　

　　user-role-permissions的关系--图1

　　接下来，我们将一一分析，如何巧妙地结合这三个术语，创建一个完整的系统用户权限管理。

　　2.用户管理

　　

　　新用户--图2

　　

　　系统用户列表--图3

　　添加新用户有两个关键点。一是关联角色，二是关联组织部门。

　　关联角色：从RBAC0模型的关系图1我们已经知道，用户和角色之间是多对多的关系。因此，图2中的用户“吴京”与战狼和伪装者的角色相关联，则他具有战狼和伪装者两个角色的联合。

　　用户权限也可以单独修改。修改用户权限不会影响角色本身的权限。如果修改了角色权限，则该角色下关联的所有用户的相应权限都会被修改。

　　关联组织部门：什么是组织部门？再来看看分解-权限管理；

　　2.权限管理

　　权限可以分为两类：数据权限和功能权限：

　　数据许可

　　顾名思义，就是账户可以查看的数据。例如，当一个公司有多个独立的运营中心时，如何保证每个运营中心信息的独立性，如何实现运营中心之间无法查看业务数据。这涉及到数据权限。

　　数据权限一般通过数据权限树来控制。什么是数据权限树？

　　数据权限树在一定程度上等同于公司的组织结构。当然，我们可以根据公司的特点进行修改。不一定要严格按照公司的部门架构来设立，只要这样的架构能够更方便的为公司服务即可。，如下所示

　　

　　权限树--图4

　　例如：当一家公司有3个子公司时，每个子公司都是一个独立的业务部门。这样，在为各个子公司的用户配置权限时，只需要配置其子公司下的数据即可；

　　当业务单据需要跨公司时，可能需要进行一些特殊处理。比如创建订单的时候，选择公司的时候，权限就释放了，因为无法确定哪些公司会合作。

　　查询页面的显示原理：所有与公司业务相关的文档，任何人都可以查看公司业务数据的权限。以电子商务中常见的仓库转移单为例：

　　

　　权限示例--图5

　　可以查看此文档的人员是：

　　A公司拥有业务组1权限的人员+业务组B公司拥有B仓库权限的所有人员。这有点含糊不清，但这并不妨碍我们把事情说清楚。

　　功能权限

　　功能权限是页面权限+操作权限的集合。页面权限是指你的系统分为哪些页面，比如销售订单查询页面、产品库存页面等等。操作权限是指页面上可以看到的操作：查询、添加、删除、导出等。

　　页面权限：所有系统都由单独的页面组成。用户是否可以看到该页面的菜单以及是否可以进入该页面称为页面权限。

　　操作权限：用户在操作系统的任何页面上进行的任何操作都是操作权限，如添加、删除、修改、查看、导出、查看等。

　　

　　功能权限--图6

　　以后台系统功能权限为例，如图4所示。一般来说，功能权限的配置方法是按照模块+页面名称+页面对应操作的模型来配置，这样配置就清楚了，概率的误差比较小。.

　　3.角色管理

　　角色管理是 RBAC0 模型的关键。下面是角色管理的图解说明： 角色的建立主要包括3个模块，基本信息功能权限和数据权限。

　　需要基本信息和功能权限，可选数据权限。数据权限一般是在用户账户上配置的。

　　如果该角色适用于所有组织，则可以为其配备数据权限。如果角色是为某个组织建立的，那么配置数据权限就很麻烦。

　　例如：以图3所示的公司结构为例。如果每个子公司都有自己的财务系统，最后需要汇总到总公司财务系统下，如果系统只建立一个财务角色，那么这个时候，只需要配置功能权限，数据权限就可以了添加用户时，为总行财务和分行财务配置不同的数据权限；

　　如果系统设置了两个或多个财务角色，一个叫总行财务，一个叫子公司1财务，一个叫子公司1财务，那么每个财务角色在创建时都可以设置数据权限和功能权限。配置完成后，创建新用户时无需再配置。

　　应该如何创建具体的角色？各公司可根据实际情况灵活配置。

　　

　　新角色--图7

　　

　　角色列表--图8

　　四、总结

　　RBAC0模型基本可以满足任何系统建立比较完善的权限体系。当然，它也有一些不足，比如：

　　一个用户有多个角色，如果多个角色之间存在互斥关系如何处理？

　　角色之间存在层级关系时，如何为角色建立层级关系？

　　......

　　这时候我们需要介绍以下升级机型：

　　1、RBAC1：它是RBAC角色的层次模型。增加了角色分类的概念。一个角色可以从另一个角色继承权限。

　　

　　RBAC1角色分类概念-图9

　　2、RBAC2：添加了 RBAC 约束模型。增加了职责分离，规定了在给角色分配权限时，或者给用户分配角色时，以及用户在某个时刻激活角色时，必须遵守的强制性规则。

　　互斥角色：同一用户最多只能被分配到一组互斥角色中的一个角色，支持职责分离的原则。互斥角色是指各自权限相互限制的两个角色。例如，财务部门有两个角色：*敏*感*词*和审计师。它们是互斥的角色，所以用户不能同时拥有这两个角色，体现了职责分离的原则。

　　基数约束：分配给角色的用户数量是有限的；用户可以拥有的角色数量是有限的；也应该限制同一角色对应的访问权限的数量，以控制系统中高级权限的分配

　　前置角色：即用户想要获得上一级角色，必须先获得下一级角色

　　3、RBAC3：其实就是RBAC2+RBAC1。称为统一模型，它包括 RBAC1 和 RBAC2，并使用传递性来包括 RBAC0。

　　以上是基于本人主导和使用过的系统对角色权限系统的总结和总结。有不足之处，希望大家多交流。