Worktile 权限设计与实现

Worktile是国内最优秀的企业级项目协作与目标管理工具之一,这个项目已经持续了9年之久,书写了研发团队的历史长卷,我作为“后来者”有幸地参与其中。在过去研发的一年里,做的事情大多数是对原有功能的增强和重构,也学习和总结了 一点点Worktile核心技术和知识,本文就是其中之一—— 权限系统。

Worktile的权限异常复杂,在开发中,从疑惑到深入,再到后来的望之止步,直至最终的克服,这其中多次与同事的交流,又多次的总结,逐渐地清晰,到现在对它进行了我认为比较全面的总结,下面就跟大家一起 揭秘(分享) 这块复杂而精彩的内容。

一、Worktile 帐户体系


Worktile 权限设计与实现_第1张图片



首先总览一下Worktile的帐户体系。在此之前,先介绍一下该系统:它是多租户系统的一种,在我接触过的多租户系统中,有两种类型,一种是像企业微信,飞书,它们的租户类型有用户和团队/组织/企业,那么这类应用的帐户体系 就有两个用户概念,一个是系统用户,一个是团队成员;而另一种就是 Worktile,租户类型 是 企业/团队/组织的,它是不含个人租户,一切业务的基础条件是 团队(team) ,所以权限这块也是基于 团队成员来控制的。

目前比较主流的权限设计模型,一种是ACL(Access Control List),是主要是基于用户来控制权限,而另一种是RBAC模型(Role-Based Access Control )基于角色的访问控制,而这两种在Worktile中都有涉及,在绝大部分是RBAC模型,少量的权限是基于用户设计和控制的。

上图中,可以看到Worktile权限是由功能权限和数据权限两部分组成,下面对这功能权限和数据权限两部分 具体讲解。

二、设计与实现

功能权限和数据权限都是基于应用的维度来划分的,Worktile 现有的应用有项目、任务、目标(OKR)、消息、日历、审批、网盘、考勤...... (更多了解点 这里)。

功能权限

设计

功能权限是完全按照 RBAC 模型 设计的,关系为:
Worktile 权限设计与实现_第2张图片





由两部分组成:操作权限和可见权限,是按照应用模块的维度划分的,每个应用模块下分布多个权限点和可见范围。
Worktile 权限设计与实现_第3张图片





给用户呈现的形式是在应用的后台—>角色管理中(见下图),其中企业角色包含两部分: 1. 系统默认角色(所有者、管理员、成员、部门主管) 2.自定义角色,权限列表(下图右侧)中,打对勾的代表该角色已拥有的权限,数据范围 代表 该角色 在 应用内的可见维度。

可操作权限
Worktile 权限设计与实现_第4张图片





可见权限
Worktile 权限设计与实现_第5张图片





实现

在传统关系型数据库的设计,基本都是三张表:角色表,权限表,角色权限关联表,如果校验一个或一组权限,是需要三表关联查询的。

而在Worktile中则不然,采用的储存方式是:非关系型数据库Mongodb + 系统配置文件, 由一张表来表现,权限列表由系统配置文件存储。

Mongodb,天然支持数组和JSON类型的数据储存,在角色和权限的关联配置中更为灵活,这一环在此设计中,不可或缺!

配置文件主要存储的是权限列表,系统内置,前端也需要一份配置是因为列表展示位置匹配。

为何这么设计?

数据库是因为整个产品的主库就是 Mongodb,这也是最大的原因;权限列表之选择配置文件储存,我猜想 是因为权限是系统内置,并且是固定的,改动频率较低,所以没有必要每次都要再交互一次数据库,不仅是功能权限如此,下面谈到的数据权限亦是如此。

系统的权限列表

配置的数据结构大致如下(以下只是说明结构,并非实际数据):

Worktile 权限设计与实现_第6张图片

一级节点的key代表的是应用模块,二级节点的key代表权限点,value为权限的描述,详细如下:
Worktile 权限设计与实现_第7张图片

角色与权限的关联配置

在Worktile中只需要一张角色表足矣!结构如下(关键字段): id,name,privileges,is_system,其中核心字段是privileges,该字段记录的是权限项,是一个json,详细如右下图。
Worktile 权限设计与实现_第8张图片





privileges中一级节点是应用模块,value是角色拥有的权限值,该值是以 0 和 1 组成的字符串组成,其中 1代表拥有,0代表未拥有,每个字符排列的位置是由配置文件中的storage_position 字段;scope是可见范围。
Worktile 权限设计与实现_第9张图片





使用

下面基于上述实现对以下三种常见场景的使用:

获取角色下所有的权限列表 以及 拥有状态(后台管理)

获取一个成员的所有权限(登录后前端需要储存的用户权限)

校验一个企业成员是否拥有某个权限(API请求对成员的鉴权)

ps: 只举例一种,剩下两种类似。

Worktile 权限设计与实现_第10张图片



三、数据权限

看完前面 功能权限的实现 大家应该觉得非常的简单,如果下面还抱着这种心态,那可就真是小看它了,在此 我也希望大家 能够在下面仔细阅读,体会其中的设计,文章较长,有不明白或需要讨论的欢迎评论留言。

在数据权限的设计中,各行各业大多不尽相同,这是由业务来决定的,Worktile的业务就非常的复杂,所以 权限也随之复杂,Worktile中应用模块很多,由于篇幅原因不会在文中全部讲解,只挑一些典型给大家分享一下。

我这里以Worktile 核心模块 mission(项目、任务) 来讲解分析,mission是非常值得一说的,精彩在于能够允许用户 高度自定义配置,模块下的角色和权限都是可配置的(这里说明一下非上述系统角色和权限)。

由于业务的复杂,不得不在这里给大家从一些界面截图进行演示,有疑惑的地方欢迎提出。

项目(Project)

概览

项目是任务的集合,项目分解出多个任务,项目中有组件(以不同维度 对 任务 的展示和管理)
Worktile 权限设计与实现_第11张图片





项目权限的分为可操作权限和可见权限。

可操作的权限
Worktile 权限设计与实现_第12张图片





对应的页面
Worktile 权限设计与实现_第13张图片





可见权限

规则为:公开项目所有成员可见,私有项目只有已加入的成员可见。

可见范围
Worktile 权限设计与实现_第14张图片





私有项目已加入的成员
Worktile 权限设计与实现_第15张图片





到现在大家应该对项目和项目中的权限有了大体概念和认Worktile 权限设计与实现_第16张图片

设计



项目权限的设计中有角色模式、项目角色、权限三部分,这三者关系大致为:

Worktile 权限设计与实现_第17张图片



配置方面,有全局配置和项目内配置,全局配置的维度是全部的项目,项目设置是全局配置的延伸,对单个项目的配置,项目的配置来源于全局配置。

角色模式 角色模式可以理解为角色组,在项目中必须拥有一种角色模式,由系统默认角色模式和用户自定义创建 两部分组成(见下图)。

全局配置
Worktile 权限设计与实现_第18张图片



项目中配置(这里只能选择全局配置好的角色模式)

项目角色项目角色有系统内置角色(管理员、普通成员、只读成员) 和用户自定义角色(见下图)。

全局配置
Worktile 权限设计与实现_第19张图片

项目中配置
Worktile 权限设计与实现_第20张图片

项目权限在概览中,已经介绍权限列表了,下面只展示配置和关联。

全局配置(角色关联权限)
Worktile 权限设计与实现_第21张图片

项目中配置
Worktile 权限设计与实现_第22张图片

从上面的设计中可以看出,其实这块的权限还算简单,下面从技术角度讲解一下具体的实现。

项目权限的实现是由三张表和一个配置完成的,分别是项目表(Project)、角色模式(RoleMode)、角色(Role) 和 权限列表的配置文件(PrivilegeConfig)。

关系:
Worktile 权限设计与实现_第23张图片





一个项目可以配置多个角色模式,一对多,绑定字段在主表(Project) 的role_modes。

每个角色模式可以创建多个角色,一对多,绑定字段在 从表(Role) 的 role_mode_id。

每种角色可以配置多个权限,关系是一对多,只不过这里的权限字段(permission_value) 是由 0 和 1组成的 字符串,其中 0 代表 未拥有,1 代表 拥有。

项目的可见权限是通过项目两个字段来控制的,一个是visibility(公开/私有),另一个是 members(项目成员),当项目是公开的,所有成员可见,当项目是私有的,只有成员列表存在的才可见。使用:

如何获取权限列表?服务端读取系统配置文件,返回给前端,前端再映射对应位置展示即可。

如何获取角色对应的权限列表?服务端读取角色表找到对应 权限值(由 0 和 1 组成的字符串),然后根据系统配置进行排序,返回给前端,前端通过 0 1 值排列和勾选。

如何验证成员的权限?1. 可见权限,首先判断visibility是公开还是私有,如果是公开项目所有成员可见,如果是私有其次判断 当前成员是否存在于项目成员2. 如果验证的是操作权限,从项目表(Project)读取该成员的 id 和角色,再根据角色找到权限值(由0和1组成的字符串),最后根据系统配置文件对应权限的位置映射权限值的具体单个值,如果是 1 那么就拥有此权限,反之未拥有!

任务(Task)

概览

任务是工作内容的具体表现形式,任务可以对工作内容描述,流程控制,任务和任务之间的关联和派生。

ps:任务可以单独存在,也可以存在于项目中。

下面是实际场景中的使用

Worktile 权限设计与实现_第24张图片
Worktile 权限设计与实现_第25张图片





设计

任务的权限和项目的权限从设计上就有很大的不同,任务的权限 是由权限主导的,模型见下图。
Worktile 权限设计与实现_第26张图片





其中涉及角色模式、角色、权限模式、权限、安全​级别模式、安全级别等概念,​ 安全模式和安全级别等同于 可见权限。
Worktile 权限设计与实现_第27张图片





而其中与项目共同的部分是 角色模式。不同之处是任务角色是由项目角色和任务角色( 任务负责人,参与人等) 组成,而主要设计方式是通过 配置任务类型权限来控制任务的权限,换一种说法讲给任务配置权限,不如说给任务类型 配置权限,这两者是可以划等号的。

什么是任务类型?

见名知意,就是任务的所属类型,之所以 Worktile 适用于大多数企业的原因也是核心就是任务类型,同时也支持企业成员创建和自定义。

实际中使用的任务类型
Worktile 权限设计与实现_第28张图片





注:任务 有且只能 拥有一个 任务类型

可操作权限

权限模式权限模式是多个权限的集合,也可理解为权限组,由系统内置权限模式(通用权限模式、软件权限模式等) 和用户自定义权限模式(见下图)。
Worktile 权限设计与实现_第29张图片

全局配置
Worktile 权限设计与实现_第30张图片



项目中任务类型的权限配置

权限模式 与 角色模式

Worktile 权限设计与实现_第31张图片



权限模式、角色模式与角色的关联
Worktile 权限设计与实现_第32张图片





权限模式、角色与权限的 关联

Worktile 权限设计与实现_第33张图片



权限

系统内置权限:系统定义不可更改的属性权限,比如创建任务,归档任务,拷贝任务......等

任务属性权限:任务的属性是支持用户配置的,所以属性拥有 属性权限,比如修改负责人,修改任务状态......

可见权限

任务中的可见权限,称为“安全级别”。由安全模式和安全级别两部分完成。

安全模式(系统内置安全模式和自定义安全模式)
Worktile 权限设计与实现_第34张图片



安全模式与角色模式安全模式与角色模式的绑定,表示该安全模式下哪些角色模式的角色可见。

Worktile 权限设计与实现_第35张图片



安全模式与安全级别

Worktile 权限设计与实现_第36张图片



安全级别与角色表示哪些角色(包括 项目角色和任务角色)可见

Worktile 权限设计与实现_第37张图片



项目中任务类型与安全级别的配置
Worktile 权限设计与实现_第38张图片



实现

任务的权限涉及9张表,3个配置文件。
Worktile 权限设计与实现_第39张图片





表及关系:

Task任务表、TaskType 任务类型表,一对一的关系,关联字段在主表Task的task_type_id。

PermissionMode: 权限模式表,与任务类型是多对一的关系,一个任务类型有多种权限模式。

TaskPermission:任务权限字典表,是通过系统配置文件(system task permissions) 初始化到该表中的,与权限模式 的关系是多对一,一个权限模式对应多个权限项,关联字段 selectable_permission,注意该字段是同步到 权限模式下,后续供角色来选择。

RoleMode: 角色模式表,与权限模式是一对一的关系,一个权限模式绑定一个角色模式。

Role: 角色表,与角色模式表是多对一的关系。

PermissionRole: 权限角色表,与权限模式是多对多的关系,该表的权限必须是从权限模式下的权限项 中选择,角色必须是该权限模式下绑定的角色模式下的角色中选择。

SecurityMode: 安全模式表,配置的是任务的可见权限,是从系统配置文件初始化到数据库中,与角色模式是一对一的关系,一个安全模式绑定一个角色模式。

Security: 安全级别表,配置的是任务角色(含任务内置角色和默认角色模式下的角色)的可见权限,也是 从系统配置文件初始化到数据库中的,与任务角色是一对一的关系,与安全模式是多对一的关系,一个安全模式下可以配置多个角色。

使用逻辑:

检查一个成员拥有任务的操作权限
Worktile 权限设计与实现_第40张图片





检查一个成员是否对一条任务有可见权限
Worktile 权限设计与实现_第41张图片





四、总结

文中所讲权限整体是按照RBAC模型设计

权限列表均采取 配置文件的方式储存,好处是轻量,减少连表复杂操作,较少的与数据库交互

文中 mission 模块的数据权限:

项目可操作权限是角色组 + 角色 + 权限

项目可见权限绑定是成员

任务的权限是权限组 + 权限 + 角色组+ 角色来控制任务属性

非常感谢能够认真阅读到这里的伙伴,如果文中有不明白或更好的意见欢迎交流,期待更多揭秘,还望持续关注 Worktile!

欢迎进入官Worktile

你可能感兴趣的:(权限控制权限rbac)