1 权限模型

移动平台是一站式移动端服务平台，包含研发效能、用户运营、基础服务等三大分类，20个子系统，已经为公司接近40个 APP提供服务。如何控制公司1000人在这些APP 上以及系统上的权限，是一个复杂的问题。

权限，是 B 端系统很基础的能力，需要控制某人可以对某种资源（功能、页面、数据）做什么操作。核心要素有3个：

（1）谁

（2）资源

（3）具体什么操作

权限模型有 ACL、RBAC、ABAC、IAM等多种模型。下面就这几种模型进行简单的分析。

2 ACL 介绍

Access Control List，直接控制某个用户可以拥有哪些权限。

缺点是每次新增用户或者删除用户，都需要频繁变更权限的操作。

3 RBAC 介绍

3.1 介绍

Role base Access Control ，基于角色的权限控制。角色是一定数量的权限的集合，权限的载体。在用户和实际的权限之间增加了角色，形成了用户-角色，角色-权限的对应关系。其中角色-权限关系对中，权限可以是菜单、功能和数据。

这样，在新增或者减少用户时，只需要将用户-角色关系对添加或者删除即可。

上图是 RBAC0 的模型，也是最基础的 RBAC模型。后来 RBAC 又进一步发展出 RBAC1,

RBAC2, 以及 RBAC3.

其中：

RBAC1 中增加了角色分级的概念，一个角色可以从另外一个角色继承权限，那么在具体的鉴权时，如果当前权限不符合要求，那么需要递归查询该用户在其父角色中是否有权限。参考文献RBAC 继承中有具体的实现。

RBAC2 增加了一些限制。

RBAC3 是统一模型，包含了 RBAC1和 RBAC2.

3.2 优点

RBAC 解决了 ACL 遇到的权限变更复杂的问题，能够覆盖大多数的实际应用场景。

3.3 不足

3.3.1 顺序问题

RBAC模型没有提供操作顺序控制机制。这一缺陷使得RBAC模型很难应用关于那些要求有严格操作次序的实体系统。

例如，在购物控制系统中要求系统对购买步骤的控制，在客户未付款之前不应让他把商品拿走。RBAC模型要求把这种控制机制放到模型

3.3.2 角色暴涨

指的就是为了抓住每个不同员工职责中每个细微的区别导致增加了大量的角色。在这条路上走得太久，会发现企业对每个员工都有一个独特的角色，那反而抹除了RBAC大部分价值。

3.3.2 数据权限控制支持不足

数据权限：数据字段权限是较细颗粒度，实现不同角色用户进入同一模块时，受限于不同的角色权限可见的数据字段都有差异。

RBAC 传统模型对数据权限的控制不足，不能支持诸如控制某个页面下不同用户看到数据不同的需求，比如销售记录页面，总监可以看到整个大部门的销售数据，部门整理只能看到自己部门的数据，部门员工只能看到自己的销售数据。

在第4部分，会针对『数据权限』做一些调研分析。

4 数据权限

要实现数据权限，最重要的是抽象出数据规则。

关于数据权限如何控制？从网上的资料来看，需要讨论一下如下两个问题：

（1）权限是否需要跟角色挂钩？

（2）如果需要挂钩，应该如何实现？

4.1 权限是否需要跟角色挂钩的讨论

思路1、少加数据权限，跟主体账号关联

系统一般情况下，很少加数据权限的概念的。只有个别的功能才有数据权限的概念。但是像SaaS系统，一般情况下，以商户作为一个数据包，把账号与商户进行关联，允许账号查看该商户对应的具体数据。建议少给功能定义数据权限。

尽量少加数据权限的概念。就是要加，数据权限主要还是与账号进行关联，没有说与角色进行关联的。角色主要还是决定功能的操作权限控制。

思路2、使用角色权限和组织结构解决数据权限

如上组合，一般可以解决90% 以上的数据权限问题，如果还有特殊权限需求，新开一个角色即可。

4.2 基于角色的数据权限实现思路

数据权限一般直接穿透到持久层了，一般的做法是直接给每张表加额外的字段，辅以各种框架的拦截器修改 SQL 来实现的。

整体实现时，加拦截器，对 DB 查询进行动态改造。

这种只适合单个系统，但是不太适合像移动平台这样的多系统集中业务中台。

4.3 业界数据平台的权限实现方案

参考美团数据权限的建设

基础权限使用 RBAC，通用数据权限由平台负责，具体业务的权限，通过 plugin 实现。具体业务实现 plugin, 平台通过 RPC 来进行调用不同的 plugin 进行数据灵活鉴权。

4.4 目前移动平台对数据权限部分的实现

各个子系统本身支持 app 级别的隔离，再细化的数据区分，由各个子系统自己实现。移动平台可以提供用户基础信息供各个平台去参考使用。

5 IAM 介绍

IAM是 Identity and Access Management 的缩写，即身份与访问管理，或称为身份管理与访问控制。

IAM主要为了达到一个目的：让恰当的人或物，有恰当的权限，访问恰当的资源。其中“人或物”称为主体（Subject），“资源”称为客体（Object）。

传统的IAM一般包含如下几部分，常被称为“4A”或“5A”。

账号（Account）
认证（Authentication）

广义的认证是一种信用保证形式，指第三方公证机构对组织/个人的身份、能力、资质等的认可。
狭义的认证指的是证明“主体是谁”。IAM中认证指的是狭义的认证，常见于主体申请访问资源时。

授权（Authorization）与鉴权

授权是将权力交付给用户或机构代为行使，此时使用户或机构获得访问资源的权限。

鉴权则是判断某人是否有权限访问某个资源。

应用（Application）

狭义的应用只是业务系统在IAM中的映射，

审计（Audit）

审计日志需要记录用户的所有操作，需要记录主体、操作、客体、类型、时间、地点、结果等内容。
根据不同的维度可以划分为不同的操作日志，如操作日志和登录/登出日志、
用户日志和管理员日志、业务系统日志和IAM系统日志等。
审计相关的功能，不同规模、不同行业要求不同，通常国外比国内更严格、更强调合规。

6 移动平台权限体系

6.1 权限分层

6.1.1 四层权限模型

传统的RBAC 模型是用户-角色-资源，移动平台的权限体系依赖 RBAC 模型，但是多了 app 这一层。如上图，用户1 如果在APP3 上拥有系统1的业务角色1，但是在 APP4上并没有次权限。

也即形成了 用户-APP-角色-资源 四层结构。

6.1.2 业务超管角色

6.1.2.1 业务超管角色

业务超管角色是指拥有某个系统下所有菜单、功能集合的一个角色。如上图所示。

6.1.2.2 APP 超管与平台超管

移动平台业务上增加了平台级别的管理（平台超管）以及APP 纬度的管理（APP超管）。平台超管需要拥有整个平台所有的权限，APP 超管则需要拥有当前 APP 下所有的权限。

6.1.2.3 新建应用

所以在新建一个应用时，需要指定 APP 管理员，我们需要默认给这些 APP 管理员授权，也需要给平台超管授权当前 APP 上所有的权限。此时只需要给他们挂上当前应用的业务超管角色即可。

6.1.2.4 新增系统

目前移动平台有20个系统，在每个系统接入平台时，需要默认增加一个业务超管角色，然后给 APP 超管增加其应用上对应新系统的业务超管角色。

6.2 典型场景权限交互

6.2.1 系统添加

一个新的系统接入移动平台，需要指定『业务超管角色』、『系统负责人』，以及一些其他的角色。具指定『业务超管角色』是为了后续给『特权』用户（APP 管理员与平台管理员）授权。如上文所述，这个角色拥有系统所有的权限（包括菜单、功能、数据等）。其他普通角色则拥有自己特定的权限。需要完成这些对应关系的绑定。

系统接入的具体步骤是

1、设定角色以及角色对应的权限

2、给平台超管、APP 超管自动追加『业务超管角色』。

通过上述两个步骤，APP 超管，则拥有了新增系统在该 APP 下所有的权限了。

6.2.2 app 创建（添加应用超管）

新建 APP时，需要给当前 APP 的管理员授权移动平台所有子系统的『业务超管角色』。这样 APP 超管也就能拥有了所有子系统的权限了。

6.2.3 授权

授权，就是指权限获取的过程。移动平台独有的四层权限体系，授权时，需要操作『某人在某个 APP 下对应特定系统的 XXXX 权限』。

6.2.4 鉴权

鉴权，是鉴别某个用户是否拥有某个权限的过程。按照 用户-APP-角色-资源 的四层模型，鉴权的过程是判断某个人在某个 APP 上是否能够访问某个系统的特定资源（菜单或者功能）。

7 扩展知识

7.1 OAuth2.0

7.1.1 简介

一种授权的开放标准。具体的应用场景是第三方想访问用户的某个资源，此时需要权限。不可能直接将用户的账号密码给第三方，所以就使用 oauth2.0.

oauth2.0 的一个通俗解释文章： OAuth2.0 解释

7.1.2 授权流程

（A）用户打开客户端以后，客户端要求用户给予授权。
（B）用户同意给予客户端授权。
（C）客户端使用上一步获得的授权，向认证服务器申请令牌。
（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。
（E）客户端使用令牌，向资源服务器申请获取资源。
（F）资源服务器确认令牌无误，同意向客户端开放资源。