本文试图用不那么学术性的白话解释各种权限管理模型和适合使用场景。
名词解释
- 客体：例如系统，数据等，本文将客体简化为权限点。
- 主体：进行权限点访问的实体。例如用户，服务，进程等。为了易于理解起见，本文将主体简化为用户。
- 访问控制：访问控制限制用户对权限点的访问权限，从而使系统在合法范围内使用；其实就是解决谁可以对什么权限点进行什么样的操作的问题。例如，某个页面只能由公司HR访问，这里用户是HR，权限点就是页面, 通过给HR关联权限达到限制页面访问的目的。
- UPM: 统一权限管理系统，也是笔者目前负责的系统。
ACL
ACL（Access Control List）是上个世纪90年代提出的权限控制模型。ACL是一个规则列表,规定资源可以什么规则访问， 例如公司的docker白名单（给docker添加了某个IP白名单，这台docker就可以访问这个IP）。
在用户权限管控场景，ACL将用户和进行了映射, 规定了哪些可以被哪些用户进行操作。ACL模型如下图所示：
ACL是一种初级权限管理，适合比较粗粒度的权限管理场景。例如“晋级评审系统” 设置了flag=“晋升评委标志位”， 隔离了评委和非评委能看的页面。再例如UPM统一权限管理系统使用flag 对 管理员 和 超级管理员能做的操作做了区分。
在UPM中针对具体业务场景我们抽象出了领域 Flag 标识位和地区Area 用来实现ACL模型。
其中地区与公司各个业务线关联，表示用户的某一业务线下地区的权限。Flag属于更上层的抽象，在UPM中Flag是抽象出来的树状权限点，主要让业务方用来给用户打标做权限控制。这个权限点的含义业务方可以自行定义，比如有的用来做组织架构，有的用来做地区，都是可以的。
使用每个模型应该针对场景扬长避短， ACL适用于业务系统权限需求简单，功能点数量较少的场景。如果业务系统权限管理需求复杂，ACL在应对大量用户和权限点的权限管控的时候就会变得非常繁琐。这时候需要用户和权限点之间再抽象一层，给权限点分一个权限点类，用户直接和这个类别关联，这样就清晰很多 – 这个权限点类就是角色。
RBAC
RBAC （Role Based Access Control） 模型也是上个世纪90年代提出的ACL增强版的权限控制模型。RBAC将人和权限点解耦，在用户和权限点之间增加了一个中间桥梁 – 角色。 角色可以看做是一组操作的集合，不同的角色具有不同的操作集，这些操作集关联到用户身上。一个用户可以拥有多个角色，从而实现权限管理的灵活性。RBAC模型如下图所示：
在UPM中RBAC模型，也就是基于角色的权限管理被用来做 页面访问权限的控制。 最直观的用户可以看到哪些URL页面或者用户可以点击哪些按钮。RBAC使用场景非常广泛，例如：
「XX系统」根据用户的岗位分为了“运营角色”，“客服角色”，“电销管理员角色”，“财务角色”等多个角色。再例如「XX系统」根据自身业务内容划分了角色：“问题诊断角色”, “查询角色”等。
RBAC模型的优点显而易见：大大简化了权限管理，降低了管理开销，使得权限管理系统具有更强大的可操作性和可管理性。事实证明，RBAC也是公司目前被业务系统使用最多的权限管理模型。
ACL✖️RBAC 组合会造成权限扩大，慎用
公司拥有多条业务线，例如专车，快车, 安全等等。这样在管理权限时候就会遇到一个问题 – 如何管理不同业务线的同一类操作问题。而这类问题使用RBAC和RBAC ∪ACL都可以解决:
- RBAC模型：「A系统」针对不同业务线的同一个操作设置了多个角色，例如角色“专车-看板角色”, “快车-看板角色”,”安全-看板角色”等等。
- RBAC✖️ACL的模型：「B系统」使用ACL标识定义了业务线资源（设置了标识位：专车，快车, 安全），再设置了一个“看板角色”，用户在申请角色的时候选择自己业务线的标识位，再选择看板角色即可。
另外，从这里例子中也可以看出虽然是同一个RBAC模型，不同使用者（业务系统）使用的效果各异。这就好比在UPM权限系统提供基础食材（权限模型），各个厨师（业务系统）对各个基础食材各有发挥，做出来的菜也不一样。同样是土豆，有的厨师做出了土豆丝，有的做出了薯条。每一种使用方式都可以解决业务系统的业务问题，权限系统重点在于提供一个可以让厨师自由选择食材的平台。
纵观ACL和RBAC两个模型，这两个模型虽然强大，但是仍然很难覆盖所有权限管理场景。例如管控“预算部门是汽车资产管理中心且操作城市是北京”的用户的某一运营操作权限，这就要求用户在有某一角色的情况下根据一个或者一组属性是否满足某种条件进行权限判断，而这就是ABAC产生的背景。
ABAC
Attribute Based Access Control (ABAC)是2013提出的模型。不同于RBAC和ACL将用户通过某种方式与资源关联的方式，ABAC是通过动态计算一个或者一组属性是否满足某种条件进行授权判断。ABAC可以实现非常灵活的权限控制，几乎能满足所有类型的需求。
一个灵活的权限管理，应该支持 Who（用户） 是否可以对 What（资源） 进行 How（策略-维度节点） 的访问操作。基于RBAC的权限管理，仅支持who对what进行操作，不支持相关业务的数据权限，也不支持多维度数据权限。
ABAC 相关概念：
- 维度： 控制数据权限的域。如地域是一个维度，产品线是另一个维度。
- 维度节点：数据权限域中的具体节点，如地域维度中，有北京、上海节点；产品线维度中，有快车、出租车、专车节点。 节点可以是扁平的，也可以组织成一棵树。
- 策略：指定控制数据权限的维度。如访问访问角色1的页面时，策略指定通过地域维度控制。策略是一个算子，并非具体的值，入参是用户id, 出参是具体维度节点。
目前我们的ABAC模型是给资源添加各种策略，并给用户维度节点权限，模型如下图：
ABAC能够完整表述权限控制的Who是否可以对What进行How操作。举个例子,如果想表述：“张三在司机报表中能够查看全国的快车司机”。这时候张三首先需要第一个权限：
- “司机报表角色”，司机报表角色对应查询司机报表功能权限点；
另外，司机报表角色需要对应策略：司机报表策略（要根据地区/产品线识别用户身份）。并建立地区维度（地区域），设置相关地区域的节点（全国，北京，天津）。建立产品线维度（产品线域），并设置相关产品线域的节点（专车，快车）
因此，张三需要第二个权限：
- 维度节点权限。“全国” 和 “快车”维度节点权限以此来控制张三可以看见哪部分报表。
权限控制如图：
总结说来，RBAC 只能做到人对权限点的权限控制, 但ABAC可以在RBAC的基础上，基于权限点属性做更丰富的条件判断，支持更灵活的权限控制。
ABAC模型虽然强大，然而通常这个模型都是最后一个选择。实际使用中往往我们推荐给权限模型使用者都是RBAC>ACL>ABAC. 正是因为ABAC模型很强大，他试图解决所有权限管理场景，就会带来管理策略非常复杂的问题，使用起来也不是很用户友好，实际场景面临运营和落地难的问题，需要配套产品合理的设计才能让用户清楚地使用。
Summary
目前我们的系统作为统一权限管理平台，支持ACL,RBAC以及ABAC三种权限模型的管理。