基于角色的访问控制（RBAC）是目前公认的解决大型企业的统一资源访问控制的有效方法。访问控制实际是复杂的，解决方式也是多样的。不用一味追求完善，在有限的资源内选择最合适自己的更重要。
基于角色的访问控制（RBAC）是目前公认的解决大型企业的统一资源访问控制的有效方法，传统的访问控制中我们直接将许可权赋予使用者，而在基于角色访问控制中先将许可权赋予角色，再通过角色与使用者连线。
一个例项
这里跳过对理论模型的解释，以最近的一个专案为例，谈下实际专案中的应用。首先交代背景：（1）简易电商后台版本，意思就是很小不需要什么复杂许可权，开始也没考虑许可权。
（2）有一个管理员账号运营和开发都在用，一个财务账号给财务导资料，新建供应商同时生成商家账号，给商家上架商品发货这些。
（3）需要增加许可权的契机就是随着业务扩大，功能变得复杂了些，再不做就要乱了。
功能模组许可权的功能模组分为三个部分：
使用者管理就是给使用者新增登入账号，让使用者能够登入系统；
角色是告诉你我在这个身份下能在系统干什么；
许可权配置是对许可权功能的管理，让系统管理员或开发人员更清楚灵活管理配置系统页面许可权、功能许可权，反正就是普通使用者用不着那种。
角色管理首先是新增角色。
字段非常简单，只要写好角色名称和描述角色是做什么的就可以。
其次是分配许可权。
很多系统做法是直接在编辑或者新增页面一起把许可权分配做了。我更偏好是一个动作下只做一件事，会比较清晰些。所以这里做了两个步骤，就是角色资讯和许可权分配独立开。
在页面互动上，这里并没有使用纯树形，而是结合选单+页面形式：左边展示导航选单，右边展示对应页面功能。
这种对于页面层级不深的其实是非常直观的，但是如果在该页面下某些二级入口甚至三级入口许可权控制就会略显混乱，会比较建议使用树形结构处理。
顺便提一句，后台设计尽量不要让页面层次太深了，这对使用者使用并不友好。如果这么做，那么使用多级选单导航或者关闭式标签导航可能是一种解决方式。
有一些需要注意的点：
1. 超级管理员
为了便于管理，在当前系统中配置了一个超级管理员角色，就是这个角色系统里面什么都能干；这个角色下通常只有一个超管，只有这个超管才能做许可权管理，其他角色是不可的。
这一点在不复杂的系统中，是一种便捷管理方式。更复杂系统需要考虑不同层级管理员、考虑角色互斥、角色继承这些问题。
2. 角色禁用启用以及删除
禁用启用都会影响到这个角色下所有使用者的使用，这点需要注意。在处理这些敏感的操作时候，一定要做二次确认。
在删除时，还需要判断下当前角色有使用者时是否能够删除。能删除则使用者怎么处理，不能删除怎么提示。
一种做法是，可以删除但删除后如果使用者赋予的角色会为空，再登入时候会对应提示；另外一种做法是要先清空使用者才能删除角色。
3. 单角色
RBAC告诉我们一个使用者可以有多个角色，但是我这里处理为一个使用者只有一个角色。实际上可以做多个角色，但是没有必要，因为我们的业务是单线的，每个角色各司其职。
如果是多角色，从我做过系统看，一个是做好角色的互斥，比如说某项业务的申请和审批不要分配到同一个人上；一个是一次只能获取一个角色，登入进入系统，第一个就是要选择角色。
如果处理更好那就首次登入选择，再次登入记住上次即可，并且支援在个人设定中自由切换。
4. 预设角色
这里商家其实是预设角色，它不可删除。这么做是因为商家某些页面字段显示与其他角色是不一样的，属于资料许可权范畴。但是如果单独细化资料许可权到字段，投入产出比那真的是划不着，所以直接在角色中写死了。在实际场景中，角色和身份是可以是对等的，比如做校园自然就有教师、学生、家长角色，这一类角色实际是是可以作为预设固定角色而不需要再建立。
使用者管理新增角色以后，我们就可以去使用者管理中管理使用者，页面如下：
在新增或编辑使用者时候我们就会给使用者设定角色。这里可能需要注意点有：
（1）使用者名称
根据实际需求去规定使用者名称，可以是邮箱可以是手机号，也可以是正常的字母+数字的组合。
当前系统使用是数字+字母的账号，那么在你忘记密码时候，如果不系结手机号或邮箱还是无法自己找回的。在当前业务条件下，登入页直接给了个联络管理员的提示，由管理员重置密码。
（2）密码
通常会有个初始密码，为了保证系统安全性，最好首次进入强制修改。如果忘记密码需要管理员重置，那需要一个重置的功能，点选二次确认后重置为初始密码。也可以是带输入框弹窗，输入为任意符合规则的密码。
（3）关联商家
可以理解为这是对资料许可权的控制手段。在实际的后台许可权管理中，有些资料许可权是根据组织架构做了限制，有些角色去配置，有些根据使用者组，而有些则是根据账号单独去配置。所以在做资料许可权时候，要具体问题具体分析，而不是别人的一定合适。
在当前系统中，实际预设有两类使用者，一个是平台的，如平台运营、财务；一个是供应商（商家），那么平台对应的资料范围是全部资料，而商家对应的资料范围是自己的。
在做许可权之前，在商户管理中，新增商户时候预设会新增一个商户账号，实际已经做了资料隔离，但是统一许可权管理后，新增使用者并且配了商家角色，实际上并不知道这个使用者管理的是哪个商家，那就需要使用者和商家中做个连结。
（4）投放限制
是某种特殊的资料限制，进一步说明对单个账号配置必要性。
比如如果做广告，只允许某使用者投放某些区域；再比如做校园管理系统中，指派班级学生助理对特定班级成员的管理（也可以通过组织架构做资料许可权控制，如果有下篇可以讨论下）。
我做的是社群电商后台，是自带社群限制属性的，有些商家只能投放一个社群，有些商家则能投放多个社群。
许可权配置更准确的说，是选单和规则的配置。不是必须的，但是建议能够在前端页面中配置。
我负责的系统是php写的，许可权是后面增加，所以开发在修改时候，每个功能按钮都做了个if判断，还好页面和功能不多，不然开发估计要哭。
所以这个并不是合理方式。
在其他系统中，则采用的是通过url结合api做的页面和功能控制，有优点也有缺点，本文不进行深入讨论。
当然我也无力探究不同的语言如何实现许可权管理，因为我听不懂。不过理解下正在做的系统如何实现的对于非技术出身产品经理而言，则是一种有益学习过程。
通过许可权配置，我们能够比较灵活的调整选单或者功能，比如调整个选单位置配置个选单icon，不需要让开发的伙伴去动下程式码，能让他们少掉几根头发。
此外，操作日志是一个必不可少的模组，它是对访问控制一个补充，记录了整体系统中所有的行为。特别是在角色中没有控制“只能操作自己内容”时，就会变得尤为重要。
我现在处理这个系统许可权问题时候，并没有在角色的维度上去控制资料许可权，而是根据实际业务在使用者的维度去控制了资料许可权。举一个例子，比如说，AB都是商家角色，都能对某个商家进行管理。如果二者资料许可权做了控制，那么A只能编辑自己录入商品，B只能编辑自己录入商品。如果没有控制，那么AB都可以编辑彼此录入商品，要是误操作这就不知道是谁干的了。在这种情况下，有日志就能知道谁进行了对应的操作，避免无法追溯问题源头。
理论溯源
理论是实践的基础。虽然枯燥，还是有必要提一下整个RBAC模型的发展脉络。产品经理社群乃至各大技术社群对于RBAC的介绍和说明已经有很多，挑了以下两篇我觉得说的很清楚文章，看完就基本知道RBAC是整个模型是什么了，感谢二位分享。
RBAC许可权管理模型：基本模型及角色模型解析及举例 http://www.woshipm.com/pd/440765.html
总结：SAAS后台许可权设计案例分析 http://www.woshipm.com/pd/2310691.html
同时我也结合了自己了解和理解资料，做了一个理论梳理。特别是最上面访问控制技术发展有兴趣的可以进一步探索下，就不贴什么枯燥的概念解释了。实在能力有限，有些是真的看不太懂。
值得一提的是，人们习惯用百度Google等搜索引擎去获取专业资讯，而很多学术论文中的一些整体解决方案往往被忽视。
学术上这种理论与实践结合研究可能滞后于现实发展的（因为新的实践提升到理论的视角是需要时间积累），但是对于从未接触过人群，这类论文却提供了一种方法论的思路。
是的，你们找不到答案的时候不妨查一下CNKI。——员外
结束语
1. 许可权管理是系统的基础功能，在最初规划时候就要考虑到每个行为都能找到是谁干的。2. 访问控制实际是复杂的，解决方式也是多样的。不用一味追求完善，在有限的资源内选择最合适自己的更重要。
最后，如有不足或者错误地方欢迎指正。计划是能由简单到复杂覆盘下自己做访问控制踩过的坑，希望有下一篇，立个flag
本文由 @员外丁 原创释出于人人都是产品经理，未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
