背景
RBAC是Role-BasedAccess Control的英文缩写，意思是基于角色的访问控制。这块的功能大家已经比较熟悉了。建设任何一个系统都会包含这些。理论归理论，理论做的好，实践不一定做的好。尽管实践需要理论来指导。最近一直在设计Pass系统的用户账户体系，对于功能权限和组织权限有一些自己的见解，想和大家分享。
一些概念
功能权限
系统中的各种功能点，比如：设备相关的管理操作。在进行逻辑模型设计的时候，可能就是对应数据库中的一张菜单表，我们称之为：功能菜单。菜单会对应一个页面，页面会有很多的元素：组件、按钮、超链接，其中能操作的元素，我们称之为动作。
数据权限
首先我需要拥有功能菜单的权限，然后我们就要考虑，我能访问的数据权限。还是以设备列表为例，比如：我拥有查询设备的权限，但是我肯定不能查询所有的设备，对于这些设备数据的权限控制，我们称之为数据权限。功能权限和数据权限结合，构成了整个权限系统，能解决90%以上的业务上的权限管理问题。
角色
角色是功能的集合，解决的是功能权限设置问题，不解决数据权限的问题。
了解了这些基本概念后，我们切入正题，来聊一聊功能权限与数据权限的问题。
功能权限与数据权限
在可视化的功能页面配置过程中，我们遇到个问题：系统可以对页面进行可视化编辑的。其中，页面有很多组件构成，通过可视化的拖拽组件来实现页面开发，生产页面的功能。实体关系如下：
在这个场景中，功能权限与数据权限的边界比较难界定。以一个“链接”功能按钮为例子，其是设备列表组件内的一个动作元素，其是功能的范畴。但是这个连接会指向一个新的菜单。前面说过，其实菜单属于功能范畴。我们基于这个前提，讨论了N久，一直没有将整个业务梳理清楚，总是感觉模型抽象得不是很好，无法很好支持后期的扩展。
理越辩越明，道越论越清。慢慢的我们意识到，这里面会有两层的意思。第一层是功能权限，比如我能不能看到这个链接按钮。这块可以通过角色来实现。其实，链接也是一种动作，类似于查询。如果是查询，我们很容易将访问的部分理解为资源。链接是快捷方式访问到另一个具体的页面，一个已经存在的URL。为了便于理解，我们可以将链接的页面理解为资源，其背后隐藏了一个授权的动作：就是我将这个资源授权给你访问。这样就理清了整个逻辑模型，使用这套模型方便后续的扩展。
网友评论