阿里架构师如是说:权限系统就该这么设计
前言
权限管理是所有后台系统的都会涉及的一个重要组成部分,主要目的是对不同的人访问资源进行权限的控制,避免因权限控制缺失或操作不当引发的风险问题,如操作错误,隐私数据泄露等问题。
目前在公司负责权限这块, 所以对权限这块的设计比较熟悉, 公司采用微服务架构, 权限系统自然就独立出来了, 其他业务系统包括商品中心, 订单中心, 用户中心, 仓库系统, 小程序, 多个 APP 等十几个系统和终端。
1. 权限模型
迄今为止最为普及的权限设计模型是 RBAC 模型, 基于角色的访问控制(Role-Based Access Control)
1.1 RBAC0 模型
RBAC0 模型如下:
这是权限最基础也是最核心的模型, 它包括用户 / 角色 / 权限, 其中用户和角色是多对多的关系, 角色和权限也是多对多的关系。
用户是发起操作的主体, 按类型分可分为 2B 和 2C 用户, 可以是后台管理系统的用户, 可以是 OA 系统的内部员工, 也可以是面向 C 端的用户, 比如阿里云的用户。
角色起到了桥梁的作用, 连接了用户和权限的关系, 每个角色可以关联多个权限, 同时一个用户关联多个角色, 那么这个用户就有了多个角色的多个权限。
有人会问了为什么用户不直接关联权限呢?在用户基数小的系统, 比如 20 个人的小系统,管理员可以直接把用户和权限关联,工作量并不大,选择一个用户勾选下需要的权限就完事了。
但是在实际企业系统中,用户基数比较大, 其中很多人的权限都是一样的,就是个普通访问权限,如果管理员给 100 人甚至更多授权, 工作量巨大。
这就引入了 "角色 (Role)" 概念, 一个角色可以与多个用户关联, 管理员只需要把该角色赋予用户, 那么用户就有了该角色下的所有权限, 这样设计既提升了效率, 也有很大的拓展性。
- 权限:
是用户可以访问的资源, 包括页面权限, 操作权限, 数据权限:
- 页面权限:
即用户登录系统可以看到的页面, 由菜单来控制, 菜单包括一级菜单和二级菜单, 只要用户有一级和二级菜单的权限, 那么用户就可以访问页面
- 操作权限:
即页面的功能按钮,包括查看, 新增, 修改, 删除, 审核等,用户点击删除按钮时,后台会校验用户角色下的所有权限是否包含该删除权限。如果是, 就可以进行下一步操作, 反之提示无权限。
有的系统要求 "可见即可操作", 意思是如果页面上能够看到操作按钮, 那么用户就可以操作, 要实现此需求, 这里就需要前端来配合, 前端开发把用户的权限信息缓存, 在页面判断用户是否包含此权限, 如果有, 就显示该按钮, 如果没有, 就隐藏该按钮。
某种程度上提升了用户体验, 但是在实际场景可自行选择是否需要这样做
- 数据权限:
数据权限就是用户在同一页面看到的数据是不同的,比如财务部只能看到其部门下的用户数据,采购部只看采购部的数据。
在一些大型的公司,全国有很多城市和分公司,比如杭州用户登录系统只能看到杭州的数据,上海用户只能看到上海的数据,解决方案一般是把数据和具体的组织架构关联起来。
举个例子, 再给用户授权的时候, 用户选择某个角色同时绑定组织如财务部或者合肥分公司, 那么该用户就有了该角色下财务部或合肥分公司下的的数据权限。
以上是 RBAC 的核心设计及模型分析, 此模型也叫做 RBAC0, 而基于核心概念之上, RBAC 还提供了扩展模式。包括 RBAC1,RBAC2,RBAC3 模型。下面介绍这三种类型。
1.2 RBAC1 模型
此模型引入了角色继承 (Hierarchical Role) 概念,即角色具有上下级的关系,角色间的继承关系可分为一般继承关系和受限继承关系。
一般继承关系仅要求角色继承关系是一个绝对偏序关系,允许角色间的多继承。
而受限继承关系则进一步要求角色继承关系是一个树结构,实现角色间的单继承。这种设计可以给角色分组和分层,一定程度简化了权限管理工作。
1.3 RBAC2 模型
基于核心模型的基础上,进行了角色的约束控制,RBAC2 模型中添加了责任分离关系。
其规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。
责任分离包括静态责任分离和动态责任分离。主要包括以下约束:
- 互斥角色:
同一用户只能分配到一组互斥角色集合中至多一个角色,支持责任分离的原则。
互斥角色是指各自权限互相制约的两个角色。比如财务部有会计和审核员两个角色, 他们是互斥角色, 那么用户不能同时拥有这两个角色, 体现了职责分离原则
- 基数约束:
一个角色被分配的用户数量受限;一个用户可拥有的角色数目受限;同样一个角色对应的访问权限数目也应受限,以控制高级权限在系统中的分配
- 先决条件角色:
即用户想获得某上级角色, 必须先获得其下一级的角色
1.4 RBAC3 模型
即最全面的权限管理, 它是基于 RBAC0,将 RBAC1 和 RBAC2 进行了整合。
1.5 用户组
当平台用户基数增大,角色类型增多时,而且有一部分人具有相同的属性,比如财务部的所有员工,如果直接给用户分配角色,管理员的工作量就会很大。
如果把相同属性的用户归类到某用户组,那么管理员直接给用户组分配角色,用户组里的每个用户即可拥有该角色,以后其他用户加入用户组后,即可自动获取用户组的所有角色,退出用户组,同时也撤销了用户组下的角色,无须管理员手动管理角色。
根据用户组是否有上下级关系, 可以分为有上下级的用户组和普通用户组:
- 具有上下级关系的用户组:
最典型的例子就是部门和职位,可能多数人没有把部门职位和用户组关联起来吧。
当然用户组是可以拓展的,部门和职位常用于内部的管理系统,如果是面向 C 端的系统。关注公众号 Java旅途 回复手册 领取Java面试大全
比如淘宝网的商家,商家自身也有一套组织架构,比如采购部,销售部,客服部,后勤部等,有些人拥有客服权限,有些人拥有上架权限等等,所以用户组是可以拓展的
- 普通用户组:
即没有上下级关系,和组织架构,职位都没有关系,也就是说可以跨部门,跨职位。
举个例子,某电商后台管理系统,有拼团活动管理角色,我们可以设置一个拼团用户组,该组可以包括研发部的后台开发人员,运营部的运营人员,采购部的人员等等。
每个公司都会涉及到到组织和职位, 下面就重点介绍这两个。
1.5.1 组织
常见的组织架构如下图:
我们可以把组织与角色进行关联,用户加入组织后,就会自动获得该组织的全部角色,无须管理员手动授予,大大减少工作量,同时用户在调岗时,只需调整组织,角色即可批量调整。
组织的另外一个作用是控制数据权限, 把角色关联到组织, 那么该角色只能看到该组织下的数据权限。
1.5.2 职位
假设财务部的职位如下图:
每个组织部门下都会有多个职位,比如财务部有总监,会计,出纳等职位,虽然都在同一部门,但是每个职位的权限是不同的,职位高的拥有更多的权限。
总监拥有所有权限,会计和出纳拥有部分权限。特殊情况下, 一个人可能身兼多职。
1.6 含有组织 / 职位 / 用户组的模型
根据以上场景, 新的权限模型就可以设计出来了, 如下图:
根据系统的复杂度不同, 其中的多对多关系和一对一关系可能会有变化
1、在单系统且用户类型单一的情况下,用户和组织是一对一关系,组织和职位是一对多关系,用户和职位是一对一关系,组织和角色是一对一关系,职位和角色是一对一关系,用户和用户组是多对对关系,用户组和角色是一对一关系,当然这些关系也可以根据具体业务进行调整。
模型设计并不是死的, 如果小系统不需要用户组, 这块是可以去掉的。
2、分布式系统且用户类型单一的情况下,到这里权限系统就会变得很复杂,这里就要引入了一个 "系统" 概念。
3、此时系统架构是个分布式系统,权限系统独立出来,负责所有的系统的权限控制,其他业务系统比如商品中心,订单中心,用户中心,每个系统都有自己的角色和权限,那么权限系统就可以配置其他系统的角色和权限。
4、分布式系统且用户类型多个的情况下,比如淘宝网,它的用户类型包括内部用户,商家,普通用户,内部用户登录多个后台管理系统,商家登录商家中心,这些做权限控制,如果你作为架构师,该如何来设计呢? 大神可以在评论区留言交流哦!
2. 授权流程
授权即给用户授予角色, 按流程可分为手动授权和审批授权。权限中心可同时配置这两种, 可提高授权的灵活性。
- 手动授权:
管理员登录权限中心为用户授权,根据在哪个页面授权分为两种方式:给用户添加角色,给角色添加用户。
给用户添加角色就是在用户管理页面,点击某个用户去授予角色,可以一次为用户添加多个角色;给角色添加用户就是在角色管理页面,点击某个角色,选择多个用户,实现了给批量用户授予角色的目的。
- 审批授权:
即用户申请某个职位角色,那么用户通过 OA 流程申请该角色,然后由上级审批,该用户即可拥有该角色,不需要系统管理员手动授予。
3. 表结构
有了上述的权限模型, 设计表结构就不难了, 下面是多系统下的表结构, 简单设计下, 主要提供思路:
4. 权限框架
- Apache Shrio
- Spring Security
在项目中可以采用其中一种框架, 它们的优缺点以及如何使用会在后面的文章中详细介绍。
5. 结语
权限系统可以说是整个系统中最基础,同时也可以很复杂的,在实际项目中,会遇到多个系统,多个用户类型,多个使用场景,这就需要具体问题具体分析,但最核心的 RBAC 模型是不变的, 我们可以在其基础上进行扩展来满足需求。
希望对你有所帮助!
如果看完的小伙伴有兴趣了解更多的话,欢迎添加vx小助手:SOSOXWV 免费领取资料哦!
阿里架构师如是说:权限系统就该这么设计相关推荐
- DDD洋葱架构才是 yyds,阿里架构师手记(DDD)领域驱动设计应对之道
虽然身为架构师,设计一个高质量的架构依然是复杂与困难的. 简单来说,动用大量的资源只为了一套优质的三高架构并不正确,而是该在了解当前业务现状的情况下,创造出灵活.可维护.健硕能成长的. 就拿近两年程序 ...
- 【十年磨一剑】我们能从阿里架构师的身上学到什么?
前言 做技术的,一定不能放弃技术.在精进技术的同时完善其他方面的能力,十年如一日.不忘初心,方得始终. 正文 本文是看到阿里巴巴系统架构师黄勇的采访记录有感而发,如有侵权,请联系我.下面就一起来看看阿 ...
- 进阶阿里架构师:算法、编程语言、数据库、架构设计!书单推荐!
阿里架构师必读书单 数据结构与算法:算法.算法导论等. 编程语言:java编程思想.java核心技术等 模式与设计:设计模式.代码重构.深入理解java虚拟机 数据库:mysql优化.oracle.r ...
- 高性能mysql_「高性能MySQL」十年阿里架构师推荐,这份高性能MySQL文档送给你
MySQL MySQL的概述 MySQL是一个关系型数据库管理系统,由瑞典MySQL AB 公司开发,目前属于 Oracle旗下产品.MySQL 是最流行的关系型数据库管理系统之一,在 WEB 应用方 ...
- 软考·系统架构师论文——论软件的高并发设计
文章目录 说明 摘要 过渡 项目背景 论点理论 论点实践 结尾 说明 1.[摘要 300~330字] ① 项目介绍:时间.项目名.项目主要功能简述.作者角色及工作内容 ② 项目技术简介:正文理论/分论 ...
- 架构师学习笔记(四)架构师线路之系统架构师企业架构师
架构师线路之系统架构师&企业架构师 系统架构设计师 知识结构 具备的能力 职业定位 工作职责 系统架构设计师 系统架构师是一个最终确认和评估系统需求,给出开发规范,搭建系统实现的核心构架,并澄 ...
- 阿里架构师开源《Kotlin入门教程指南》+《高级Kotlin强化实战》
对于有Java基础的程序员来说,Kotlin是一门非常容易上手的编程语言,也是一门必须掌握的编程语言.Java代码在运行前需要编译生成一种特殊的class文件,然后Java虚拟机会识别并解释这些cla ...
- 架构师如是说(一)——敏感式开发
也不是大分享,只要是我刚出来实习的一个小小的总结并记录下来. "我们在开发的时候,开发出来了一个小功能了,就先公开给别人用,先给我们内部人员用用,完了再开放给客户用."公司的架构师 ...
- 架构师怎样绘制系统架构蓝图?
前言 今天我们来了解一些关于软件设计文档的基础知识,这样你在学习后面的具体案例时,就能更加清楚地理解文档是基于什么方式来组织的了. 首先,请你设想这样一个场景:如果公司安排你做架构师,要你在项目开发前 ...
最新文章
- 支持全球探测点的新一代网站监控
- PermSize 设置过小对性能的影响(OutOfMemoryError:PermGen spac)
- HDU-6290_奢侈的旅行(Dijstra+堆优化)
- python编写性别比例_Python分析微信好友性别比例和省份城市分布比例的方法示例【基于itchat模块】...
- 10个奇葩的代码注释,笑出声!
- NumPy 秘籍中文第二版·翻译完成
- php.exe安装教程,经典的php for win32安装 (转)-PHP教程,PHP应用
- 解方程c语言程序,C语言程序解线性方程组
- js基础-14-JS阻止事件冒泡和默认事件
- JavaScript离线帮助文档 网盘下载
- 蝶形算法 matlab,FFT快速傅里叶变换(蝶形算法)详解
- 我家遥控器载波波形研究
- 图片验证码识别教程技术原理分析
- JAVA JNI中int和Integer完全不同
- Java 方法参数传递
- azkaban上传zip报错:Error Chunking during uploading files to db
- Python入门学习小记:100以内素数/质数之和
- 层次Voronoi Diagrams更好地为HNSW的最底层获取入口点优化近似最近邻搜索(HVS)
- mysql 计算gps坐标距离_mysql实现经纬度计算两个坐标之间的距离
- Linux 网卡操作
热门文章
- – 9、查询学过编号为“01“并且也学过编号为“02“的课程的同学的信息
- 没有了 main 函数,程序还能跑吗?
- device-side assert triggered at /pytorch/aten/src/THC/THCReduceAll.cuh:327
- HttpURLConnection的用法
- 奶牛乘法c语言数组,C++程序题,奶牛问题
- 树莓派+DHT11温湿度传感器+yeelink物联网云
- 区块链应该到支付领域有哪些好处?
- session共享的另外一篇博客.好文章
- 灰度共生矩阵和灰度游程矩阵
- 基于无向图的城市间快递派送算法