ToB领域的权限体系设计简介
（本文适合小白入门）
一个最简单表达了权限模型的实例
小明和小李，分别用自己的帐号和密码登录了同一个平台页面。小明登陆上去后，可以看到小说和视频页面。小李登陆上去之后，只能看到小说页面。Mmmm.....他俩有不同的权限
后台是什么样的模型来实现的呢。对于ToB领域的权限控制，产品经理经常用到的是RBAC模型
什么是RBAC
RBCA是英文role-based access control的缩写，即基于角色的权限管理系统，用来实现对用户授权，访问系统的特定部分，实现不同粒度的权限控制。可以理解为一种非功能性的需求，而是一种安全机制。据说一般一个企业超过500名员工，都会需要用到权限控制。至于“安全”这个主题，在对企业打分的时候，不一定会成为一个加分项，但一定可以成为一个扣分项。
RBAC的核心是角色（role）。所有使用者的能够操作的内容，都是通过角色来进行赋予和禁止，而不是直接通过对使用者本身来继续赋予和禁止。如软件行业的行话，当一个系统太复杂了，那么就为他加一个层吧。同理，这样一个role层加入是为了简化复杂度。具体原因可以看RBAC和ACL的区别
下面来看一下，如果用户要执行一项操作，需要满足的RBAC的绕口令似的3原则
- 角色分配：一个用户必须被分配一个角色
- 角色授权：当前角色必须被授权给当前用户
- 权限授权：权限必须被授予给当前用户的角色，当前用户才能执行这项权限
RBAC和ACL的区别
传统的ACL是属于更底层更基础的数据对象的权限控制，比如一个文件可以读写的权限控制。RBAC是带有业务含义的权限控制。比如可以表达出银行业里，保险箱需要的开启需要银行经理和储户的钥匙同时存在。又比如可以表达出业务流程中不能出现“自己审理自己”的这种荒唐现象。
权限体系与帐号体系的关系
账号体系包含的内容是用户帐号的注册/登录/密码修改/密码找回功能。其中用户帐号登录，就会需要权限系统提供的功能来进行协助校验。
校验内容包含：
- 这个用户是不是被禁止，是否可以登录系统。
- 这个用户登录后，能够看到哪些页面
- 在他能够访问到的页面上，能够执行哪些操作
权限体系与组织架构的关系
组织架构是企业的行政组织架构。企业所使用的系统，都是其组织结构的反应。所以任何一个ToB的系统，如果要获得客户的认可，必须符合客户的组织结构。
大型企业的组织架构会相当复杂，比如国家电网这种重量级选手，有职能部门，地区分部，一级省公司，直属单位，再往下细分那就更多更复杂了。如果小型公司，可能就只有公司总体和部门两个级别，比较简单。可以想见，对于越复杂的组织结构，所要求的权限控制的精细度，权限限制会更加复杂
权限体系与组织架构能够一眼所见的，最直接的关系，就是数据。组织与组织之间的数据，应该是隔离的，组织A的人员，不能够去访问和操作其他组织的数据。这些需要通过权限体系来实现。
简单权限系统的设计
如前所述，首先需要设计的是角色。
角色分离
一般角色可以按照两种维度进行分离，管理的维度和业务的维度。
- 管理角色：一般是企业的运维人员，可以登录系统，进行维护和授权操作。一般通过自定义的方式，可以支持页面上新建。一般一个账号可以同时有多个自定义角色
- 业务角色：按照职责进行确认，比如财务，保洁员，总经理等。一般通过内置角色的方式来实现，不支持页面上新建。一般一个帐号可以有一个内置角色
上面说的是一般，一般，一般。当然实际情况中总会有新的不同情况
管理角色会发生变化，但是业务角色由于和企业的组织架构，职级，职能相绑定，一般创建好之后是不会发生变化的。
用户分配角色
参考RBAC三原则，当系统中新建一个用户时，必须为这个用户分配一个对应的角色
角色授权
不管是内置角色还是自定义角色，当新建一个角色时，需要为这个角色进行授权。permission是一个操作，定义了能够读取哪些资源，可以认为授权的对象是由角色+资源（resource）+ 操作组成。资源是指菜单，功能，操作是通常含义的CRUD操作，用user story来描述是，这个角色能够对哪些资源做哪些具体的操作。角色与资源之间是多对多的关系。
一个授权的例子：角色是仓库保管员，可以访问仓库页面，并对仓库里的货物进行出入和入库操作。系统管理员为小明创建了一个xiaoming的帐号，并给xiaoming绑定了仓库保管员的角色。结果就是：小明登录系统后，能够对仓库的货物进行操作了
复杂权限系统的设计
复杂权限系统设计中，会引入以下概念。后续再介绍
- 用户组
- 业务流引擎
（to be continue）
