开发平台之权限设计

老干爹 8月前 ⋅ 2819 阅读

背景

对于应用,无论大小或复杂,权限是非常基础的功能模块。在一些日常的小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程序基本构成

 

核心逻辑

一个用户登录,只需检查其拥有哪些权限群,根据当前访问的菜单来动态地渲染加载页面程序资源(动作权限、页面元素权限);当用户访问某些数据时,根据数据资源的配置约束获取对应权限群的数据权限合集,从而对可见数据进行隔离。

上文我们提高的岗位权限、领导人权限、岗位权限,都可以在上述模型中关联出来。


注意:本文归作者所有,未经作者允许,不得转载

全部评论: 0

    我有话说: