编辑导语：权限配置能力，可以为各应用提供权限配置原子能力，帮助应用快速集成权限配置，提高系统权限管理体验。本文作者分析了如何以RBAC模型设计可配置的权限中心，一起来看一下吧。
权限配置能力作为权限控制器，为各应用提供权限配置原子能力。这里聊聊，如果想要以RBAC模型设计可配置的权限中心，该怎么入手。
笔者根据自己的行业经验总结了一下思路，欢迎大家批评指正。
所谓权限配置能力，就是以权限、角色为中心，把权限配置单独作为原子能力服务，高度抽象，为开发者、运营人员提供一整套对菜单、接口和数据资源进行授权，同时提供标准授权界面，帮助应用快速集成权限配置，为业务运营集成权限统一管理，形成标准化流程，提高系统权限管理体验。
权限配置能力，主要实现的是从用户角色到功能应用的权限控制器，提供管理功能权限、数据权限的基础能力，提供权限服务（管理+控制）能力给每一个应用使用，免除重复开发、考虑不全的问题。
首先，我们来说说什么是RBAC模型。
RBAC认为权限授权的过程可以抽象地概括为：Who是否可以对What进行How的访问操作，并对这个逻辑表达式进行判断是否为True的求解过程，也即是将权限问题转换为What、How的问题，可以说，Who、What、How构成了访问权限三元组。
在RBAC模型里面，有3个基础组成部分，分别是：用户、角色和权限。
RBAC通过定义角色的权限，并对用户授予某个角色从而来控制用户的权限，实现了用户和权限的逻辑分离（区别于ACL模型），极大地方便了权限的管理。
（注：图来源于网络，如侵权可告知删除）
RBAC支持三个著名的安全原则：最小权限原则、责任分离原则和数据抽象原则。
RBAC模型优点是简化了用户和权限的关系易扩展、易维护。
但也存在一定的局限性，比如，RBAC模型没有提供操作顺序的控制机制，这一缺陷使得RBAC模型很难适应哪些对操作次序有严格要求的系统。
聊完了RBAC模型，我们可以先看看权限控制框架设计。
刚刚提到过，所谓权限，就是对资源、数据等进行配置，不同的人分配不同的权限。可以说，权限控制框架其实就是将不同的资源、数据分配给不同的角色，从而完成授权行为。
针对不同的角色配置相应的授控资源（包括菜单、接口、数据资源等）完成授权配置。
具体配置流程需要对应用系统的资源进行录入（包括菜单资源、接口资源、数据资源）后，对业务应用系统的资源进行重新配置为权限策略，最后对角色进行赋权以及角色绑定用户。
完成配置后，业务系统通过调用对外服务的SDK标准组件或接入API接口，判断资源与用户/角色的关联关系后进行权限控制即可。
实际上，授权不仅仅可以对角色进行授权，实际上还可以通过将角色与组织机构、行政区划、标签等纬度进行关联授权，甚至是直接将用户与组织机构、行政区划、标签等纬度进行关联授权。但在本文中，暂时先不考虑这种多维度的授权逻辑，只讨论常规授权逻辑。
针对具体的运行环境，判断授权对象是否对授控资源具有某种操作或数据范围的权限。
权限策略的前提时，需要对应用系统的资源（包括菜单资源、接口资源、数据资源）进行录入。
在系统初始化时，由超级管理员或开发人员完成码资源管理的录入和管理，后续可集成到相应的管理平台中，为产品运营提供灵活可控的权限控制。
菜单资源，指的是对业务系统的前端功能菜单/页面资源进行录入管理，以独立的URL进行区分，可进行分层级管理。
接口资源，指的是对业务系统的后端接口资源进行录入、管理，可以录入URL关键字段和接口请求方式。
数据资源，主要指业务系统中存储的数据资源，通过字段信息进行区分，可以通过唯一编码录入权限管理。
根据业务应用实际情况，建立权限策略管理功能，对已经纳入管理的资源，包括资源管理添加的菜单、接口、数据字段资源进行重新配置权限，管理权限与资源的关联逻辑。
从控制力度来看，权限管理分为两大类：功能权限管理和数据权限管理。
在系统初始化时，由超级管理员或开发人员完成码权限策略的配置和管理，后续可集成到管理平台中，为产品运营提供灵活可控的权限控制。
1）定义
通俗的说，功能权限指用户登录系统后能看到哪些模块，操作哪些按钮。每个角色有配置固定的功能权限，角色之间权限相互隔离。所有角色的对应功能权限由管理后台进行配置。
2）分类
功能权限包括：业务功能、授权功能。
1）定义
如果所有信息都是公开透明的，也就不需要做数据权限的控制。可不同的业务形态多而杂，每个人、每个角色需要看到的、应该看到的数据不同，数据权限便应这些需要和规则而生。
数据权限较比于其他两个权限较为抽象，指的是用户是否有针对某些数据的浏览权限，用户在某个模块里能看到哪些范围的数据。不同角色在同一个页面看到的信息是不同的，可以通过组织架构来区分。
2）业务决定
对于数据权限的管理比较复杂，这个主要还是有具体的业务来决定的。数据权限一般和组织架构相关。根据组织机构的层级关系，结合业务实际场景，实现不同角色的数据权限的划分。
比如A业务经理只能看到自己的客户数据，但是A的业务总监可以查看到各个区域业务员的客户数据。
3）数据权限向上兼容原则
数据权限向上兼容，若出现多层级授权场景，上级可以对查看下级信息（包括统计信息、授权信息等）。当用户获取数据时，根据自己当前的部门和职位，获取到所有下属的职员信息。
例：业务管理员可以查看其管辖范围内次级管理员或业务员的所有信息。
对已经在【资源管理】已经录入的资源，在【权限策略】进行重新配置为权限策略。
在系统初始化时，由超级管理员或开发人员完成角色管理的配置和管理，后续可集成到管理平台中，为产品运营提供灵活可控的权限控制。
在功能权限策略管理功能已经完成功能权限配置后，需要对角色进行赋权，赋权后展示角色对已授权功能权限和资源明细全景图，便于配置维护。可将角色与用户进行绑定，完成角色授权。
1）行政区划
行政区划是行政区域划分的简称，是国家为了进行分级管理而实行的区域划分。一般来说，我国的行政区划管理体系颗粒度可到省-市-区-街道-社区村居5级管理。
一个管理员只对应一个行政区划，管理员下的查验员都跟着管理员的行政区划。
注意：很多时候，行政区划不是必要的组织属性，一般的to B企业基本不会用到该字段信息。但有时候对于政务行业相关的应用系统，行政区划信息还是必要的。
2）组织架构
组织机构是行政组织机构管理的简称，是为了实现在不同组织机构、部门等层级的分级管理设计。根据组织机构的层级关系，结合业务实际场景，实现不同角色的功能权限、数据权限的划分。
1）定义
角色层级可配置3-5个层级，包括普通用户、管理端的管理人员和业务角色。所有角色根据不同场景、不同业务需求决定，角色之间的授权限制条件也与业务场景相关。
2）分类
角色可以分为管理角色、业务角色。
3）角色权限说明
所有角色与用户的关联可通过管理后台进行授权操作。
用户管理当前提供后台系统账号的新增和批量导入功能，添加用户时需要添加用户的业务属性，包括角色和角色权限。
通过管理后台或小程序，将用户与角色绑定关联，实现用户赋权。一旦用户被分配了适当的角色后，该用户就拥有此角色的所有操作权限。
用户与角色是多对多的关系。一个用户可以拥有若干角色，一个角色也可以赋予若干用户。
多个角色并存的时候，不同角色的拥有不同功能权限的功能模块。这里需要分两种情况进行分析。
1）角色权限向上兼容原则
用户可以通过角色切换来进行功能模块的切换，但角色权限也存在向上兼容原则，也就是说，高级权限可以覆盖低层级权限。
比如，一个用户可能即是公司员工又是管理人员，那么这时候他既有普通员工的角色权限，也有管理层（比如业务经理）的角色权限，这时候他登录时无需进行角色切换，而是直接以他所拥有的最高层级角色登陆系统，显示他最高层级角色的功能页面即可。
2）角色权限无法兼容
但也会存在另一种情况，就是可能在系统内，某个用户他既是财务人员，又身兼监管部门要职，而这两种角色的功能业务可能会存在某种冲突，系统不允许同一用户同时兼容这两种身份，但实际上企业内部又出现了这种情况。那么我们就得对这两种角色的权限进行隔离，让同一用户能在系统中身兼多任（注：这里提供的案例可能不是非常准确）。
这里提供一个笔者的解决方案，各位如果有更好的解决思路，欢迎补充~
当面临这种角色权限无法兼容时，可以通过角色切换实现对角色权限的隔离。比如：
若用户只有1个角色或同时拥有2哥及以上的角色但角色可向上兼容，登录时默认使用该用户最高层级的角色登录，加载最高层级角色的功能页面；
若用户有2个及以上的角色，但角色之间可能存在无法兼容的情况，登录时弹框加载该用户所有角色的列表，让用户自己选择角色后，加载该角色的功能页面。
同时提示可以在【我的】->【角色切换】进行角色的切换，并在本地缓存该角色的记录，下次登录时通过读取缓存，自动加载该角色的功能页面。
这里需要说明的是，授权不仅仅可以对角色进行功能授权，实际上还可以通过将角色与组织机构、行政区划、标签等纬度进行关联授权，甚至是直接将用户与组织机构、行政区划、标签等纬度进行关联授权。
但在本文中，暂时先不考虑这种多维度的授权逻辑，只讨论常规的功能授权。
这里笔者只根据自己的经验整理了一下思路，欢迎大家积极吐槽，期待能与大家一起讨论找到更好的解决方案，谢谢各位的赏读~
本文由 @Elaine 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Pexels，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。