开发平台之权限设计

背景

对于应用，无论大小或复杂，权限是非常基础的功能模块。在一些日常的小APP中，可能会有简单的普通用户、vip、管理员这三种普通的角色权限合集，而对于我们日常使用的企业应用，其权限的颗粒度与角色的划分更为微小、更为复杂，如：动态创建角色、分级管理员、权限转移等。如何设计可以支撑各种需求粒度的权限呢？

需求

1、不同的人具有不同的权限，不同的人拥有不同的身份（管理员、某个岗位权限、某个特定群组、某个特定角色）。—用户权限身份多样性
2、权限的来源方式不同，比如某条记录的权限、页面的元素操作权限、菜单权限。—权限资源的多样性
3、复杂系统具有分级管理员的特征，权限的转移、临时授权与收回、角色权限的继承。—权限资源的灵活性

抽象与设计

在介绍灵活的核心设计前，先给大家普及一个入门的概念：RBAC（Role-Based Access Control，基于角色的访问控制），就是用户通过角色与权限进行关联。简单地说，一个用户拥有若干角色，每一个角色拥有若干权限。
RBAC其实是一种分析模型，主要分为：基本模型RBAC0（Core RBAC）、角色分层模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）。
更多详情大家可以了解：RBAC权限模型

核心UML

这是笔者通过多种业务场景后抽象的RBAC关系图

类说明

Group

群或组，拥有一定数量权限的集合，亦可以是权限的载体。
子类：User（用户）、Role（角色）、Position（岗位）、Unit（部门），通过用户的特定构成，形成不同业务场景的群或组，而通过对群或组的父类授权，完成了用户的权限获取。

Permission

权限，拥有一定数量资源的集成，，亦可以是资源的载体。
权限下有资源，资源的来源有：Menu（菜单）、Option（动作权限）、页面元素（按钮、tab等）、数据权限等

Program

程序，相关权限控制的呈现载体，可以在多个菜单中挂载。

常见web程序基本构成

核心逻辑

一个用户登录，只需检查其拥有哪些权限群，根据当前访问的菜单来动态地渲染加载页面程序资源（动作权限、页面元素权限）；当用户访问某些数据时，根据数据资源的配置约束获取对应权限群的数据权限合集，从而对可见数据进行隔离。
上文我们提高的岗位权限、领导人权限、岗位权限，都可以在上述模型中关联出来。
请期待下一篇《企业应用之登录设计：单点登录、域登录》。