基于资源的权限系统-设计思路

概述

权限系统提的最多的就是 RBAC(基于角色的访问控制)。 所谓角色,其实就是权限的集合,某个角色就是某几个权限的结合。其目的是为了简化授权和鉴权的过程。

基于角色的权限控制用在简单的权限环境下没有问题,如果在权限控制比较复杂的系统中,或者说要做通用的权限系统时,基于角色的权限控制会带来以下问题:

  1. 角色可以用来做功能权限,做数据权限的话,会导致角色数量非常多 比如:bug管理系统,一般有 developer, reporter, manager 等一些角色,其中,reporter 可以创建bug,developer 可以解决,回复bug,manager 可以统计bug 等等。 在这个系统中,通过设置 developer,reporter,manager 几个角色,可以使得授权,鉴权更加简单,直观。 但是,如果权限粒度要求更细的话,比如,某些reporter只能创建普通级别的bug,某些reporter可以创建各个级别的bug,或者有更加细粒度的权限要求的话,角色的数量就会激增。 到时候,管理角色本身带来的工作量反而会大于角色带来的好处。

  2. 角色是一维的,不同的角色之间一般都是独立的,而人员之间一般有树状的组织关系。所以,角色就很难与已有的组织关系互相映射。 而授权的时候,经常是上级的组织会自动获取下级创建的数据的一些权限

  3. 对于不确定的系统来说,角色不好定义。如果是bug系统,比较成熟,方便定义角色类型,如果是通用系统的话,用户其实不太容易定义好自己需要的角色。

另一种 RBAC(resource base access control)

基于角色的权限系统一般简称 RBAC,而这里的 RBAC 是指 基于资源的权限系统。

设计思路

目的是设计一种通用的权限管理系统,不和任何的实际的业务关联,只做权限相关的管理和验证。 之所以以 资源 为核心,是因为上面的提到的那些基于 角色 的限制。 基于资源的权限系统是围绕 组织树资源树 来进行权限的。

术语介绍

  • 人员 : 实际使用系统的用户,也就是需要进行权限检查的人
  • 组织 : 树形结构,但是人员可以属于一个或者多个组织
  • 资源 : 需要授权的东西都可以认为是资源,每个功能是资源,每个接口也是资源,每条数据也是资源。 资源树 上的根就是整个系统。
  • 动作 : 对资源的操作,比如常用的 创建,删除,更新,查询
  • 权限 : 组织 + 资源 + 动作 (什么人对什么资源可以做什么动作)

系统初始化

权限系统本身提供一个超级用户(admin),通过此用户来初始化最初需要的信息。

初始信息只需要定义:

  • 组织的根节点:以后追加的所有人员和组织都在此节点之下(比如就是某个公司)
  • 资源的根节点:以后追加的所有资源都在此节点之下(比如就是需要进行权限控制的系统)
  • 动作:对资源可能进行的操作(一般就是CURD,增删改查)

有了以上信息,就完成了针对某个系统和组织的权限系统的基本初始化。 基本信息初始化之后,可以导入组织/人员,以及资源信息,或者直接在权限系统提供的页面上操作。

注意 每个资源只有一个父节点,每个组织也只有一个父组织,但是每个人员可以属于多个组织。

授权过程

授权是权限系统中重要的步骤之一,另一个重要步骤就是鉴权。 授权有2种视图:

  1. 人员/组织 视图 下的授权流程

    1. 选择 资源
    2. 选择 动作
    3. 确认授权
    4. 生成权限数据

    注1 前2步的选择都可以多选。

  2. 资源 视图 下的授权流程

    1. 选择 人员/组织
    2. 选择 动作
    3. 确认授权
    4. 生成权限数据

鉴权过程

鉴权是使用最频繁的步骤,几乎每次请求都会有鉴权的操作。 鉴权就是判断 某人对某资源做某个动作 是否合法,所以鉴权的 input 是 人员/组织,资源,动作; output 则是是否鉴权成功。

    1. 根据 input 的内容(人员/组织,资源,动作),查看权限表中是否有匹配的数据
  • 1.1 有匹配的数据,返回鉴权成功
  • 1.2 没有匹配的数据,查找 人员/组织 所属的父组织,再次用 (父组织,资源,动作)作为 input,查看权限表中是否有匹配的数据
    • 1.2.1 有匹配的数据,返回鉴权成功
    • 1.2.2 没有匹配的数据
      • 1.2.2.1 当前组织已经是 根组织,返回鉴权失败
      • 1.2.2.2 当前组织不是 根组织,进入步骤 1.2

自动授权规则

对功能权限来说,一般数据量不会太大,即使没有自动授权,手动授权也可以完成。 但是对数据权限来说,不仅数据量庞大,而且如何授权也不确定,数据的变化也可能会很频繁,手动来做几乎不可能。

自动授权目的是将自动授权机制参数化,让用户通过设置不同的参数来生成不同的权限数据。 自动授权机制是以插件的形式加入到权限系统中的,默认可以提供几种常用的自动授权机制插件。 在授权时,也可以指定使用一种或者多种自动授权插件。

下面以一个示例来说明插件是如何使用的。 示例插件:创建数据时自动授权插件 功能:用户A 创建数据X 后,生成如下权限数据:

  • 用户A 可以 修改 查询 删除 数据X
  • 用户A 所属组织的成员可以 查询 修改 数据X
  • 其他组织的成员可以 查询 数据X

此插件参数就是3个list:自己的动作列表,同组织成员的动作列表,其他组织人员的动作列表 插件的参数是在权限系统中的插件管理功能中配置的(插件参数的设置需要用到动态表单,因为插件的参数个数,类型等都是不定的)

使用流程如下:

  1. 某用户创建了一条数据
  2. 创建完数据后,调用权限系统的授权接口,在授权接口中指定使用上面的 示例插件
  3. 权限系统的授权接口会调用上面的 示例插件 给用户,用户所属组织以及其他组织 分别授予相应的权限

针对不同类型的系统,授权方式千差万别,将授权的实现剥离出来,是为了增加系统的通用性。

总结

通用权限管理的主要的功能就是 授权鉴权 ,其本质都是对权限数据(什么人对什么资源可以做什么动作)的管理。 授权的难点在于给某人授与某个数据的权限之后,组织中其他关联人员可以计算出自己对这个数据的权限,这就是自动授权插件的意义。 鉴权的难点一是权限的数据量会比较大(如果权限粒度细的话),一是有些权限是需要计算的。

基于角色的权限系统的核心在 角色(人员),而基于资源的权限系统核心在 资源,资源是权限系统需要保护的东西。 希望能从资源的角度来设计出更加通用的权限管理系统。

posted @ 2016-11-30 13:49  wang_yb  阅读(12511)  评论(13编辑  收藏