浅谈权限配置能力设计

3 评论 8374 浏览 72 收藏 20 分钟

编辑导语:权限配置能力,可以为各应用提供权限配置原子能力,帮助应用快速集成权限配置,提高系统权限管理体验。本文作者分析了如何以RBAC模型设计可配置的权限中心,一起来看一下吧。

权限配置能力作为权限控制器,为各应用提供权限配置原子能力。这里聊聊,如果想要以RBAC模型设计可配置的权限中心,该怎么入手。

笔者根据自己的行业经验总结了一下思路,欢迎大家批评指正。

所谓权限配置能力,就是以权限、角色为中心,把权限配置单独作为原子能力服务,高度抽象,为开发者、运营人员提供一整套对菜单、接口和数据资源进行授权,同时提供标准授权界面,帮助应用快速集成权限配置,为业务运营集成权限统一管理,形成标准化流程,提高系统权限管理体验。

权限配置能力,主要实现的是从用户角色到功能应用的权限控制器,提供管理功能权限、数据权限的基础能力,提供权限服务(管理+控制)能力给每一个应用使用,免除重复开发、考虑不全的问题。

一、什么是RBAC模型

首先,我们来说说什么是RBAC模型。

RBAC认为权限授权的过程可以抽象地概括为:Who是否可以对What进行How的访问操作,并对这个逻辑表达式进行判断是否为True的求解过程,也即是将权限问题转换为What、How的问题,可以说,Who、What、How构成了访问权限三元组。

1. RBAC的组成

在RBAC模型里面,有3个基础组成部分,分别是:用户、角色和权限。

RBAC通过定义角色的权限,并对用户授予某个角色从而来控制用户的权限,实现了用户和权限的逻辑分离(区别于ACL模型),极大地方便了权限的管理。

  • 用户-角色映射:用户和角色之间的映射关系
  • 角色-权限映射:角色和权限之间的映射关系

(注:图来源于网络,如侵权可告知删除)

2. RBAC的原则

RBAC支持三个著名的安全原则:最小权限原则、责任分离原则和数据抽象原则。

  • 最小权限原则:RBAC可以将角色配置成其完成任务所需的最小权限集合。
  • 责任分离原则:可以通过调用相互独立互斥的角色来共同完成敏感的任务,例如要求一个计账员和财务管理员共同参与统一过账操作。
  • 数据抽象原则:可以通过权限的抽象来体现,例如财务操作用借款、存款等抽象权限,而不是使用典型的读、写、执行权限。

3. RBAC的优缺点

RBAC模型优点是简化了用户和权限的关系易扩展、易维护。

但也存在一定的局限性,比如,RBAC模型没有提供操作顺序的控制机制,这一缺陷使得RBAC模型很难适应哪些对操作次序有严格要求的系统。

二、权限控制框架

聊完了RBAC模型,我们可以先看看权限控制框架设计。

刚刚提到过,所谓权限,就是对资源、数据等进行配置,不同的人分配不同的权限。可以说,权限控制框架其实就是将不同的资源、数据分配给不同的角色,从而完成授权行为。

1. 权限配置

针对不同的角色配置相应的授控资源(包括菜单、接口、数据资源等)完成授权配置。

具体配置流程需要对应用系统的资源进行录入(包括菜单资源、接口资源、数据资源)后,对业务应用系统的资源进行重新配置为权限策略,最后对角色进行赋权以及角色绑定用户。

完成配置后,业务系统通过调用对外服务的SDK标准组件或接入API接口,判断资源与用户/角色的关联关系后进行权限控制即可。

实际上,授权不仅仅可以对角色进行授权,实际上还可以通过将角色与组织机构、行政区划、标签等纬度进行关联授权,甚至是直接将用户与组织机构、行政区划、标签等纬度进行关联授权。但在本文中,暂时先不考虑这种多维度的授权逻辑,只讨论常规授权逻辑。

2. 鉴权服务

针对具体的运行环境,判断授权对象是否对授控资源具有某种操作或数据范围的权限。

三、资源管理

权限策略的前提时,需要对应用系统的资源(包括菜单资源、接口资源、数据资源)进行录入。

在系统初始化时,由超级管理员或开发人员完成码资源管理的录入和管理,后续可集成到相应的管理平台中,为产品运营提供灵活可控的权限控制。

1. 菜单资源

菜单资源,指的是对业务系统的前端功能菜单/页面资源进行录入管理,以独立的URL进行区分,可进行分层级管理。

  • 新增菜单资源:需要填写资源名称、资源编码、资源路径、排序号、打开方式等信息
  • 新增子菜单:需要填写资源名称、资源编码、资源路径、菜单等级和上级菜单、排序号、打开方式等信息
  • 查询:比如可根据菜单名称、ID等进行搜索
  • 编辑:编辑菜单资源的基本信息,这里需要注意的是,要确定资源的唯一性及是否可修改等等
  • 删除:删除菜单资源,可设置一定的校验规则,比如需要删除下级菜单,才可以删除上级菜单
  • 批量导入:可按照标准文档要求,批量导入菜单信息

2. 接口资源

接口资源,指的是对业务系统的后端接口资源进行录入、管理,可以录入URL关键字段和接口请求方式。

  • 新增接口资源:需要填写选择资源名称、资源编码、资源路径、请求方式等
  • 查询:比如根据接口名称、接口地址进行搜索
  • 编辑:编辑接口资源
  • 删除:删除接口资源
  • 批量导入:可按照标准文档要求,批量导入接口信息

3. 数据资源

数据资源,主要指业务系统中存储的数据资源,通过字段信息进行区分,可以通过唯一编码录入权限管理。

  • 新增数据资源:需要填写选择数据元素名称、元素编码、所属页面名称、所属菜单路径等
  • 查询:比如根据字段名称进行搜索
  • 编辑:编辑数据字段资源
  • 删除:删除数据字段资源
  • 批量导入:可按照标准文档要求,批量导入字段信息

四、权限策略

根据业务应用实际情况,建立权限策略管理功能,对已经纳入管理的资源,包括资源管理添加的菜单、接口、数据字段资源进行重新配置权限,管理权限与资源的关联逻辑。

从控制力度来看,权限管理分为两大类:功能权限管理和数据权限管理。

在系统初始化时,由超级管理员或开发人员完成码权限策略的配置和管理,后续可集成到管理平台中,为产品运营提供灵活可控的权限控制。

1. 功能权限

1)定义

通俗的说,功能权限指用户登录系统后能看到哪些模块,操作哪些按钮。每个角色有配置固定的功能权限,角色之间权限相互隔离。所有角色的对应功能权限由管理后台进行配置。

2)分类

功能权限包括:业务功能、授权功能。

  • 业务功能:根据业务场景,定义不同的业务功能。结合实际业务场景,进行业务功能与角色关联配置,完成相关角色的权限配置。
  • 授权功能:若该角色具有“授权管理”功能,则需要通过管理后台配置允许该角色进行授权的子角色。

2. 数据权限

1)定义

如果所有信息都是公开透明的,也就不需要做数据权限的控制。可不同的业务形态多而杂,每个人、每个角色需要看到的、应该看到的数据不同,数据权限便应这些需要和规则而生。

数据权限较比于其他两个权限较为抽象,指的是用户是否有针对某些数据的浏览权限,用户在某个模块里能看到哪些范围的数据。不同角色在同一个页面看到的信息是不同的,可以通过组织架构来区分。

2)业务决定

对于数据权限的管理比较复杂,这个主要还是有具体的业务来决定的。数据权限一般和组织架构相关。根据组织机构的层级关系,结合业务实际场景,实现不同角色的数据权限的划分。

比如A业务经理只能看到自己的客户数据,但是A的业务总监可以查看到各个区域业务员的客户数据。

3)数据权限向上兼容原则

数据权限向上兼容,若出现多层级授权场景,上级可以对查看下级信息(包括统计信息、授权信息等)。当用户获取数据时,根据自己当前的部门和职位,获取到所有下属的职员信息。

例:业务管理员可以查看其管辖范围内次级管理员或业务员的所有信息。

3. 权限策略

对已经在【资源管理】已经录入的资源,在【权限策略】进行重新配置为权限策略。

  • 新增权限策略:需要填写功能名称、功能URL路径、功能描述、行政区划、组织机构等,对【权限策略列表】进行勾选
  • 查看:对已授权功能进行展示,并可以展开查看所有资源明细
  • 编辑:编辑功能权限
  • 删除:删除功能权限
  • 关联角色:关联角色,对角色进行赋权

五、角色管理

在系统初始化时,由超级管理员或开发人员完成角色管理的配置和管理,后续可集成到管理平台中,为产品运营提供灵活可控的权限控制。

1. 角色授权

在功能权限策略管理功能已经完成功能权限配置后,需要对角色进行赋权,赋权后展示角色对已授权功能权限和资源明细全景图,便于配置维护。可将角色与用户进行绑定,完成角色授权。

  • 新增角色:需填写角色的名称、角色类型、角色层级(行政区划、组织机构)
  • 编辑角色:编辑角色
  • 关联权限:关联权限策略,对角色进行赋权
  • 关联用户:将角色与用户关联起来,从而实现对用户授权

2. 角色的组织属性

1)行政区划

行政区划是行政区域划分的简称,是国家为了进行分级管理而实行的区域划分。一般来说,我国的行政区划管理体系颗粒度可到省-市-区-街道-社区村居5级管理。

一个管理员只对应一个行政区划,管理员下的查验员都跟着管理员的行政区划。

注意:很多时候,行政区划不是必要的组织属性,一般的to B企业基本不会用到该字段信息。但有时候对于政务行业相关的应用系统,行政区划信息还是必要的。

2)组织架构

组织机构是行政组织机构管理的简称,是为了实现在不同组织机构、部门等层级的分级管理设计。根据组织机构的层级关系,结合业务实际场景,实现不同角色的功能权限、数据权限的划分。

3. 角色层级

1)定义

角色层级可配置3-5个层级,包括普通用户、管理端的管理人员和业务角色。所有角色根据不同场景、不同业务需求决定,角色之间的授权限制条件也与业务场景相关。

2)分类

角色可以分为管理角色、业务角色。

  • 管理角色:具备数据查看权限、具备授权功能,同时也可以拥有业务角色的功能权限
  • 业务角色:具备业务功能,根据实际业务场景判断是否具备授权功能(一般不具备)

3)角色权限说明

所有角色与用户的关联可通过管理后台进行授权操作。

六、用户赋权

1. 用户管理

用户管理当前提供后台系统账号的新增和批量导入功能,添加用户时需要添加用户的业务属性,包括角色和角色权限。

2. 用户授权

通过管理后台或小程序,将用户与角色绑定关联,实现用户赋权。一旦用户被分配了适当的角色后,该用户就拥有此角色的所有操作权限。

用户与角色是多对多的关系。一个用户可以拥有若干角色,一个角色也可以赋予若干用户。

3. 多角色并存机制

多个角色并存的时候,不同角色的拥有不同功能权限的功能模块。这里需要分两种情况进行分析。

1)角色权限向上兼容原则

用户可以通过角色切换来进行功能模块的切换,但角色权限也存在向上兼容原则,也就是说,高级权限可以覆盖低层级权限。

比如,一个用户可能即是公司员工又是管理人员,那么这时候他既有普通员工的角色权限,也有管理层(比如业务经理)的角色权限,这时候他登录时无需进行角色切换,而是直接以他所拥有的最高层级角色登陆系统,显示他最高层级角色的功能页面即可。

2)角色权限无法兼容

但也会存在另一种情况,就是可能在系统内,某个用户他既是财务人员,又身兼监管部门要职,而这两种角色的功能业务可能会存在某种冲突,系统不允许同一用户同时兼容这两种身份,但实际上企业内部又出现了这种情况。那么我们就得对这两种角色的权限进行隔离,让同一用户能在系统中身兼多任(注:这里提供的案例可能不是非常准确)。

这里提供一个笔者的解决方案,各位如果有更好的解决思路,欢迎补充~

当面临这种角色权限无法兼容时,可以通过角色切换实现对角色权限的隔离。比如:

若用户只有1个角色或同时拥有2哥及以上的角色但角色可向上兼容,登录时默认使用该用户最高层级的角色登录,加载最高层级角色的功能页面;

若用户有2个及以上的角色,但角色之间可能存在无法兼容的情况,登录时弹框加载该用户所有角色的列表,让用户自己选择角色后,加载该角色的功能页面。

同时提示可以在【我的】->【角色切换】进行角色的切换,并在本地缓存该角色的记录,下次登录时通过读取缓存,自动加载该角色的功能页面。

七、其他授权

这里需要说明的是,授权不仅仅可以对角色进行功能授权,实际上还可以通过将角色与组织机构、行政区划、标签等纬度进行关联授权,甚至是直接将用户与组织机构、行政区划、标签等纬度进行关联授权。

但在本文中,暂时先不考虑这种多维度的授权逻辑,只讨论常规的功能授权。

这里笔者只根据自己的经验整理了一下思路,欢迎大家积极吐槽,期待能与大家一起讨论找到更好的解决方案,谢谢各位的赏读~

 

本文由 @Elaine 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自Pexels,基于 CC0 协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 感谢分享,受益匪浅

    来自山东 回复
  2. 嗯嗯学习到了,作者分享以RBAC模型设计可配置的权限中心的方法感觉很专业哈哈。

    来自江苏 回复
  3. 作者大大详细的讲解了如何以RBAC模型设计可配置的权限中心,受益匪浅。

    来自吉林 回复