文章从权限模型和概念出发，对权限系统的核心进行剖析，抽象出权限系统中的核心要素，并结合案例对权限系统进行介绍。

一个最简单表达了权限模型的实例

小明和小李，分别用自己的帐号和密码登录了同一个平台页面。小明登陆上去后，可以看到小说和视频页面。小李登陆上去之后，只能看到小说页面。

emmm…..他俩有不同的权限。

后台是什么样的模型来实现的呢。对于ToB领域的权限控制，产品经理经常用到的是RBAC模型

什么是RBAC

RBCA是英文role-based access control的缩写，即基于角色的权限管理系统，用来实现对用户授权，访问系统的特定部分，实现不同粒度的权限控制。可以理解为一种非功能性的需求，而是一种安全机制。据说一般一个企业超过500名员工，都会需要用到权限控制。至于“安全”这个主题，在对企业打分的时候，不一定会成为一个加分项，但一定可以成为一个扣分项。

RBAC的核心是角色（role）。所有使用者的能够操作的内容，都是通过角色来进行赋予和禁止，而不是直接通过对使用者本身来继续赋予和禁止。如软件行业的行话，当一个系统太复杂了，那么就为他加一个层吧。同理，这样一个role层加入是为了简化复杂度。具体原因可以看RBAC和ACL的区别

下面来看一下，如果用户要执行一项操作，需要满足的RBAC的绕口令似的3原则

1. 角色分配：一个用户必须被分配一个角色
2. 角色授权：当前角色必须被授权给当前用户
3. 权限授权：权限必须被授予给当前用户的角色，当前用户才能执行这项权限

RBAC和ACL的区别

传统的ACL是属于更底层更基础的数据对象的权限控制，比如一个文件可以读写的权限控制。RBAC是带有业务含义的权限控制。比如可以表达出银行业里，保险箱需要的开启需要银行经理和储户的钥匙同时存在。又比如可以表达出业务流程中不能出现“自己审理自己”的这种荒唐现象。

权限体系与帐号体系的关系

账号体系包含的内容是用户帐号的注册/登录/密码修改/密码找回功能。其中用户帐号登录，就会需要权限系统提供的功能来进行协助校验。

校验内容包含：

1. 这个用户是不是被禁止，是否可以登录系统。
2. 这个用户登录后，能够看到哪些页面
3. 在他能够访问到的页面上，能够执行哪些操作

权限体系与组织架构的关系

组织架构是企业的行政组织架构。企业所使用的系统，都是其组织结构的反应。所以任何一个ToB的系统，如果要获得客户的认可，必须符合客户的组织结构。

大型企业的组织架构会相当复杂，比如国家电网这种重量级选手，有职能部门，地区分部，一级省公司，直属单位，再往下细分那就更多更复杂了。如果小型公司，可能就只有公司总体和部门两个级别，比较简单。可以想见，对于越复杂的组织结构，所要求的权限控制的精细度，权限限制会更加复杂

权限体系与组织架构能够一眼所见的，最直接的关系，就是数据。组织与组织之间的数据，应该是隔离的，组织A的人员，不能够去访问和操作其他组织的数据。这些需要通过权限体系来实现。

简单权限系统的设计

如前所述，首先需要设计的是角色。

1. 角色分离

一般角色可以按照两种维度进行分离，管理的维度和业务的维度。

1. 管理角色：一般是企业的运维人员，可以登录系统，进行维护和授权操作。一般通过自定义的方式，可以支持页面上新建。一般一个账号可以同时有多个自定义角色
2. 业务角色：按照职责进行确认，比如财务，保洁员，总经理等。一般通过内置角色的方式来实现，不支持页面上新建。一般一个帐号可以有一个内置角色

上面说的是一般，一般，一般。当然实际情况中总会有新的不同情况

管理角色会发生变化，但是业务角色由于和企业的组织架构，职级，职能相绑定，一般创建好之后是不会发生变化的。

2. 用户分配角色

参考RBAC三原则，当系统中新建一个用户时，必须为这个用户分配一个对应的角色

3. 角色授权

不管是内置角色还是自定义角色，当新建一个角色时，需要为这个角色进行授权。permission是一个操作，定义了能够读取哪些资源，可以认为授权的对象是由角色+资源（resource）+ 操作组成。资源是指菜单，功能，操作是通常含义的CRUD操作，用user story来描述是，这个角色能够对哪些资源做哪些具体的操作。角色与资源之间是多对多的关系。

一个授权的例子：角色是仓库保管员，可以访问仓库页面，并对仓库里的货物进行出入和入库操作。系统管理员为小明创建了一个xiaoming的帐号，并给xiaoming绑定了仓库保管员的角色。结果就是：小明登录系统后，能够对仓库的货物进行操作了。

本文由 @花生草 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。