一文搞定权限管理！授权、鉴权超详细解析

授权概览

什么是授权 (Authorization)？

广义上的授权：

是上级将完成某项工作所必须的权力授给部属人员；是领导者通过为员工和下属提供更多的自主权，以达到组织目标的过程。

信息系统中的授权：

是管理员将某些资源的访问、管理、操作等权限赋予用户，达到管理和使用的目的。譬如主机的访问使用权限，某项功能菜单的使用权限亦或是某个数据的读写权限。

本文将对信息系统中的授权进行着重讲解

授权的意义

授权管理是所有业务系统不可缺少的一部分！

企业角度：

1）贴合管理制度：随着公司的建设发展过程中，组织或岗位的职责越来越清晰，边界越来越明确，所以授权成为公司管理的必要手段。不通的岗位，职责需要进行不同的授权

2）保障数据安全：数据是企业的核心资产，价值不可估量。授权能让公司的数据安全得到保障，不同的权限能看到及操作不同的数据，防止用户在误操作、人为破坏、数据泄露等

3）提升工作效率：好的授权，权限管理，会让员工的工作效率得到提升。让系统更加易容，让和业务操作变得更加简单，数据获取分析变得更加方便快捷。

系统建设角度

1）安全性：保护信息系统的操作使用安全，数据安全，防止泄露，违规操作。

2）商业性：提升产品的市场竞争价值，好的授权功能，能容易获得用户青睐。

3）易用性：让系统使用更加便捷，提升用户体验，对管理员更为友好。

授权的分类

三级授权

我们将整体授权类型划分为三级

（1）一级权限：访问权限

（2）二级权限：菜单、按钮权限

（3）三级权限：数据权限

依据不同等级的授权，来控制授权的最小的颗粒度。

常用的授权模型

常用的授权模型主要有 3 种：

ACL	访问控制列表
RBAC	基于角色的权限控制
ABAC	基于属性的权限控制

ACL（Access Control List），在ACL中，包含用户(User)、资源(Resource)、资源操作(Operation)三个关键要素。

通过将资源以及资源操作授权给用户而使用户获取对资源进行操作的权限。

RBAC（Role-Based Access Control ），是把用户按角色进行归类，通过用户的角色来确定用户能否针对某项资源进行某项操作。RBAC相对于ACL最大的优势就是它简化了用户与权限的管理，通过对用户进行分类，使得角色与权限关联起来，而用户与权限变成了间接关联。

ABAC（Attribute Base Access Control）基于属性的权限控制

不同于常见的将用户通过某种方式关联到权限的方式，ABAC则是通过动态计算一个或一组属性来是否满足某种条件来进行授权判断（可以编写简单的逻辑）。属性通常来说分为四类：用户属性（如用户年龄），环境属性（如当前时间），操作属性（如读取）和对象属性，所以理论上能够实现非常灵活的权限控制，几乎能满足所有类型的需求。

三级权限管理

基于RBAC模型的权限管理，可以分为三级

（1）一级权限：应用访问权限，也就是用户可以访问哪些应用

（2）二级权限：菜单访问权限，用户可以访问一个应用中的哪些菜单和按钮的权限

（3）三级权限：数据访问权限，用户可以访问某个菜单下的哪些数据的权限

场景举例

一级权限

给张三赋予“人力资源经理”角色，可以访问OA办公系统的权限。张三可以登录OA系统，访问OA中的所有页面，具有“查询员工”、“添加员工”、“修改员工”和“删除员工”权限。
李四不是人力的同学，没有权限登录OA系统。

二级权限

给张三赋予“人力资源专员”角色，可以访问OA办公系统的权限，但是不能看到OA所有的页面，比如只能看到添加员工的页面，具有“添加员工”的权限。

三级权限

因为张三是北京分公司的“人力资源经理”，所以他能够也只能够管理北京分公司员工和北京分公司下属的子公司（海淀子公司、朝阳子公司、东城区子公司等）的员工。
因为李四是海淀子公司的“人力资源经理”，所以他能够也只能够管理海淀子公司的员工。

RBAC

RBAC是什么？

RBAC 是基于角色的访问控制（Role-based access control ）在 RBAC 中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。这样管理都是层级相互依赖的，权限赋予给角色，而把角色又赋予用户，这样的权限设计很清楚，管理起来很方便。

RBAC 认为授权实际上是Who、What 、How 三元组之间的关系，也就是 Who 对 what 进行 How 的操作，也就是“主体”对“客体”的操作。

Who：是权限的拥有者或主体（如：User，Role）。

What：是操作或对象（operation，object）。

How：具体的权限（Privilege，正向授权与负向授权）。

RBAC 的四个模型

RBAC0：是RBAC的核心思想。
RBAC1：是把RBAC的角色分层模型。
RBAC2：增加了RBAC的约束模型。
RBAC3：其实是RBAC2 + RBAC1。

RBAC0 基本模型

RBAC1 基于角色的分层模型

RBAC2 约束模型

RBAC3 就是RBAC1+RBAC2

ABAC

什么是ABAC访问控制模型

基于属性的访问控制（Attribute-Based Access Control，下文简称ABAC）是一种灵活的授权模型。是通过实体的属性、操作类型、相关的环境来控制是否有对操作对象的权限。

例如：P5（职级）的同学有OA系统的权限。

上述是一个简单的ABAC的例子，就是通过实体的职级这一属性来控制是否有OA系统的权限

再比如：P5（职级）的研发（职位）同学有公司Gitlab的权限

上述例子是通过一组实体的属性（职级和职位）来控制对操作对象的权限

再比如：P5（职级）的研发（职位）同学在公司内网（环境）可以查看和下载（操作）代码。

上述例子显然比之前两个更加复杂，除了判断实体的属性（职级和职位），还判断了当前的环境属性和操作属性

所以我们可以ABAC的访问控制模型用下面这张图表现出来

ABAC的使用场景

ABAC授权模型理论上能够实现非常灵活的权限控制，几乎能满足所有类型的需求。从使用场景来说比较适用于用户数量多并且授权比较复杂的场景。简单的场景也是可以使用ABAC的，但是使用基础的ACL或者RBAC也能满足需求。

场景一：

还是拿上面的例子来说：P5（职级）的研发（职位）同学在公司内网（环境）可以查看和下载（操作）代码。

在需要根据环境属性和操作属性来动态计算权限的时候，使用其他的授权模型可能不太能满足需求。这个时候就需要使用ABAC授权模型。

场景二：

ABAC也适用于公司成员（角色）快速变化的场景，由于ABAC 是通过用户的属性来授权的。在新建用户/修改用户属性时会自动更改用户的权限，无需管理员手动更改账户角色。

在属性的组合比较多，需要更细粒度地划分角色的情况下。RBAC需要建立大量的角色。ABAC授权模型会更加灵活。

与RBAC访问控制模型的对比

ABAC对于RBAC有以下优点

对于大型组织，基于RBCA的控制模型需要维护大量的角色和授权关系，相比而言，ABAC更加灵活；对于中小型组织，维护角色和授权关系的工作量不大，反而定制各种策略相对麻烦，更容易接受RBAC授权模型。
新增资源时，ABAC仅需要维护较少的资源。而RBAC需要维护所有相关的角色。ABAC可扩展性更强、更方便。
RBAC支持带有动态参数的授权规则，RBAC只能基于静态的参数进行判断。
ABAC权限控制的粒度比RBAC更细。

IDaaS中的ABAC

IDaaS中的授权模型主要是基于用户属性（扩展字段）的授权。管理员可以在IDaaS中创建各个扩展字段，并且为账户分配这些字段的字段值。然后在分类管理中，根据扩展字段以及字段值创建分类。基于分类实现应用和权限资源的授权管理。（根据分类授权权限资源未做）

场景一：根据用户的某一个属性动态分配权限

在IDaaS分类管理中，可以根据某一个扩展字段和字段值创建一个分类。可以实现根据分类授权应用的功能。

如：工作地在北京的同学可以有“班车系统”应用的访问权限。

场景二：根据用户多个属性组合动态分配权限（暂时不支持）

未来在IDaaS分类管理中，可以通过租户多个属性和判断条件来创建分类，实现这一场景。

场景三：根据用户当前环境和用户属性动态分配权限（暂时不支持）

可能跟 SPG/T1 结合可以实现？