后台产品——权限设计

　　后台产品——权限设计

　　权限设计是后台产品必须要考虑的一个问题。后台产品与前台产品相比较来说，前者会涉及到更多不同的用户，为了数据的安全性以及操作的便利性，需要给不同的用户赋予不同的权限。

　　权限设计时要设计权限控制的模型，现在已有的权限控制模型有：传统的访问控制模型(DAC\MAC\ACL)、基于角色的访问控制(RBAC) 模型、基于任务和工作流的访问控制(TBAC) 模型、基于任务和角色的访问控制(T-RBAC) 模型、基于对象的访问控制模型（OBAC）、使用控制模型( UCON)、基于属性的访问控制（ABAC）模型等。

　　其中，基于角色的访问控制模型是一种比较优秀的模型，它具有以下几个特征：

　　本文，将结合作者的亲身经历来重点讨论基于角色的访问控制(RBAC) 模型如何实现。如果大家对其他的访问控制模型有兴趣，可以查看文章结尾的参考链接，也可自行在网上查找相关资料。

　　首先，先把基于角色的访问控制模型整体结构说一下，如下图所示：

　　整个模型的整体结构呈金字塔结构，从底部到顶部依次是权限、角色、用户。权限分为操作权限和数据权限；通过给角色关联操作权限和数据权限，从而使角色成为权限的集合；最后，通过给用户分配角色来让用户获取角色的权限。这个模型在“用户”和“权限”之间增加“角色”，从而使赋予用户权限变得简单，只需要给用户分配相应的角色即可。

　　以上是对这个模型的整体说明，下面将对模型图进行详细说明，从权限、角色、用户这三个方面来阐述。

　　权限

　　权限分为两部分：一部分是操作权限，这部分权限决定着用户可以进行哪些操作；另一部分是数据权限，这部分权限决定着用户可以看到哪些数据。

　　操作权限

　　操作权限决定着可以进行哪些操作。

　　“操作”并不是单独存在的，还要有操作的对象，我们把操作的对象称为“资源”。只有选定某种资源后，我们才能再去选择这种资源对应的操作。【举例】：如果选择操作权限时，只选择了一个“查看”操作是不合理的，因为系统不知道这是哪个对象的查看操作。我们必须要先选定一个对象，比如说某个菜单，然后再选择“查看”操作，这样系统才能知道可以对这个菜单进行查看操作。

　　这里的“资源”是一个比较宽泛的概念，我们将菜单、页面元素、文件等统一视为“资源”。这样做的好处在于不论是粒度大的（如菜单）还是粒度小的（页面元素、文件）资源都能很方便地进行管理，可以自由控制权限控制的粒度大小；

　　

　　同时，我们还要意识到，“资源”和“操作”是多对多的关系。

　　通过上面的论述，我们可以在实际后台产品权限设计时，将操作权限这部分划分为“资源管理”和“操作管理”这两部分。“资源管理”部分可以对资源进行管理；“操作管理”部分可以对操作进行管理。然后通过资源和操作的不同组合来实现不同资源的不同操作权限控制，非常灵活。

　　本节对应下图中红框圈起来的内容：

　　数据权限

　　数据权限决定着可以看到哪些数据。

　　先介绍一下数据权限和操作权限的区别。操作权限决定着可以对（数据）对象进行的操作；而数据权限决定着可以对哪些数据进行操作。【举例】：有两个系统用户：小明和小红。他们都能对列表的数据进行新增、修改、删除、查询操作；但是，小明能看到频道A的数据；小红能看到频道a（频道a属于频道A）的数据。从操作权限来看，这两个用户的权限一致；但是从数据权限来看，小明明显比小红可操作的数据多。

　　那么如何确保能够使数据权限生效呢？或者说，如何将数据划分到不同的数据权限，从而能够实现数据权限控制？这就要求在新建后台数据时，要对数据进行划分，划分的维度和粒度由数据权限控制的维度和粒度决定。【举例】：有两个用户需要开通后台权限，小明需要看到频道A的数据，小红需要只看到频道a的数据。通过分析得知，频道a属于频道A，因此，要在新增数据时，增加对应的频道字段，并且要精确到二级频道。最终，我们在新增数据页面增加了“一级频道”、“二级频道”字段，用来支持数据权限的实现。（另外再说一句：上一篇文章《后台产品——字段设计》中提到了字段来源有两个：业务需求和系统需求。在上面的例子中，“一级频道”、“二级频道”字段就属于从系统需求中分析出来的字段）

　　本节对应下图中红框圈起来的内容：

　　角色

　　“角色”是基于角色的访问控制(RBAC) 模型的独特部分，它是联系用户和权限的纽带。

　　“角色”可以理解为“操作权限”和“数据权限”的一个集合，在这个集合中，可以选择任意的“资源”、“操作”、“数据权限”进行搭配，然后根据需要创建各种各样的角色。打个比方来说，无论你是移动、联通还是电信用户，肯定都办理过套餐。移动有一种自选套餐，这个套餐里面包含通话时长、流量、短信等各种业务，可以任意搭配。“角色”从某种程度上，就可以理解为自选套餐。如下图所示：

　　

　　因为角色是各种“资源”、“操作”、“数据权限”的集合，其承载的信息可能会很多，所以建议在创建角色时，实时将选择的权限显示出来，这样方便当前和以后查看该角色已经选了哪些权限。

　　因为角色本身承载的信息很多，如果每次创建角色都要一个一个选择权限的话，效率会比较低。可以在创建角色时，增加一个“复制角色”的字段，如果要创建的角色和已经存在的角色差别不是很大，就可以复制这个已有角色的权限，然后在此基础上进行修改即可。当然，这个功能只会复制已有角色的权限，并不会对已有角色的权限进行回写。

　　本节对应下图中红框圈起来的内容：

　　用户

　　用户处于这个模型的最上层，当将权限、角色配置好之后，给用户赋予权限也就是水到渠成的事情了。

　　通过给用户选择角色，来给用户赋予角色所集成的权限；在这里，支持给用户同时赋予多个角色。用户的权限是这些角色权限的并集。

　　因为角色本身的权限就很多，再加上用户可能会同时选择多个角色，因此最好将已经选好的权限列出来了，这样方便当前和以后查看该用户已经选了哪些权限。

　　下面介绍一个小技巧：

　　那我们再发散一下，比方说，一个大公司的某个部门有100个用户，他们之前都是角色1的权限，现在因为业务的变动，需要将这些用户的权限变为角色2，如果每个用户都重新选择一次角色2的话，显然会比较费时费力。那么遇到这种用户比较多的情况，该怎么处理呢？ 在这种情况下，我们可以引入“用户组”的概念，先给“用户组”赋予角色1的权限，之后有新用户的话，只需要加入该用户组就可以获得角色1的权限。同时，只要将该用户组的权限改为角色2，那么该用户组下的用户也都会同时换为角色2的权限。

　　总结

　　通过上面的介绍，可以看到在这个模型中，“操作”和“资源”、“资源”和“角色”、“数据权限”和“角色”、“角色”和“用户”都是多对多的关系，这样保证了灵活性；同时，“资源”、“操作”、“角色”、“用户”又各自划分为了不同的模块，又保证了各自的独立性和扩展性。

　　大家也可以根据实际业务需求，在这个模型的基础上进行扩展来实现各自业务的需求。

　　以上是自己的一些心得体会，希望对你有用，也欢迎大家拍砖，谢谢~

　　附：参考链接