用户权限系统一般是企业后台必备，角色与权限绑定、角色和用户之间的松耦合，多对多的关系来实现授权和授权的快速变更，从而控制用户对系统的功能使用和数据访问权限，以达到企业或机构对安全管控的目的。

和用户权限系统密切相关的还有两个模块：账号体系和组织架构。

账号体系，会负责用户账号注册，登录验证，密码找回等功能，其中用户登录验证（准入权限）和权限系统有着密切的关系。

组织架构，即公司的行政组织架构。对于大型企业可能有总公司，分公司，大区、办事处等，机构之间可能存在纵横交错，彼此有业务往来，较为复杂；对于小微企业或流程相对简单的业务，通常只有公司，部门两个级别，较为简单。面对复杂的大型企业组织架构，权限系统的设计和实现复杂性会成倍的增加。

二、规划一个权限系统的核心

2.1 核心问题

权限系统要实现的核心目标是对企业业务的安全管控，企业业务对安全性要求的级别，实现安全管控的粒度，是产品经理需要解决的核心问题，依赖产品经理拥有一定的行业经验和对用户实际业务流程、操作有较深的认识。我们使用产品经理通用的思考模型“角色→场景→任务”来梳理这一问题。

2.2 角色

B端产品的用户画像和C端产品不同。

C端产品的用户画像有梁宁提出的小闲、小明、小笨这种具备明显性格特征、行为特征的用户画像。

而B端产品是强业务、岗位职责驱动，企业组织架构下，具备不同级别不同职责的岗位，就是B端产品的用户画像。

因此产品经理弄清楚其行业客户的组织架构下的职位设置、职级设置、职责设置之间的共性即可。B端产品经理对职位、职级、职责的理解，还有很多值的探讨的地方，在此不做详述。

钉钉的角色按照职务、岗位进行设置

2.3 场景

场景即用户使用产品的时间和空间。不同时间不同空间下，意味着用户可能会使用不同的终端设备，不同的网络情况，执行不同的任务，有着不一样的行为习惯等等。

C端产品会非常重视用户场景不同而后残生的不同需求，比如一款音乐APP：晨间地铁上，伏案工作中，孤枕难眠时都会有不同的用户情绪和需求。

作为B端产品，只需重考虑以下两点：一是PC端和移动端上不同场景下的不同权限；二是如果业务操作中涉及工作地点的变更，需要考虑一些数据安全性。

2.4 任务

在B端组织架构下，每个角色要执行的任务是由职责完全决定的，因此理解角色职责，就可以掌握用户需要在产品上完成的任务。

比如企业某部门leader的职责是负责某项业务销售数据的增长，那么经常统计信息，查看报表任务会由他们完成，按照角色梳理即可。

在做角色任务梳理的时候可以从可以做什么、不可以做什么、可以向系统提交哪些数据、可以向系统查询哪些数据、可操作的数据范围几个纬度进行入手。

2.5 结论

通过对角色、场景、任务的梳理后，根据共性抽象出权限系统中的核心要素，角色类型、准入权限、使用权限、数据权限。

同时，在大型组织架构以及大型平台下，还需抽象出组织权限，应用权限方便进行细粒度的授权控制。

三、角色

3.1 角色类型

角色从使用的角度划分，一种是管理角色，一种是业务角色。管理角色是针对平台的管理用户，用来划分管理的范围。业务角色是员工在系统中执行各种实际工作流时的角色。

从创建方式的角度划分，一种是内置角色，一种是自定义角色。通常管理角色通过自定义的方式创建，业务角色通过内置的方式创建。

至于系统应该选择用什么样的方式定义权限，根据产品的组织架构，和性质来划分：

简单类型产品，没有工作流：管理角色和业务角色重合，根据需求做到菜单级别自定义授权，或功能级别自定义授权即可；

有工作流，但是组织架构较为简单：管理角色自定义到菜单或功能级别，业务角色根据业务流梳理业务角色内置即可；

复杂组织架构，复杂业务流：管理角色做到应用级别授权，管理员由IT运维人员担任，他们通常不了解业务，因此菜单或功能级别的权限划分给业务角色，业务角色根据工作流引擎内置。由于复杂业务流情况下，系统一定会有一套自定义工作流的引擎，用来随时创建和变更工作流程，因此业务角色通常是各个岗位的岗位名称即可。除此之外，可能还要处理上下级权限继承的关系。

创建变更流程都会用到的业务角色

3.2 管理角色

超级管理员

超级管理员角色是拥有最高权限的角色，通常内置一个admin用户，或者是创建某个管理实体的用户。以钉钉为例，对企业进行注册和创建的用户即为超级管理员。超级管理员对应的用户只有一个，整个系统归属于它，允许变更该用户，不允许删除角色。

普通管理员

所有的自定义管理员为普通管理员，其管理权限配置需配置组织部门权限和应用管理权限，组织部门权限是其管理的数据范围，如XX子公司、销售部，应用权限即各个应用。

在钉钉上创建子管理员

3.3 业务角色

业务角色的权限体现在工作流中，随着任务在不同岗位之间流转，不同岗位看到的内容完全一样，只是处理的表单不一样。

比如请假审批：一张请假单先通过小组leader到部门leader到人事，数据一致，只是数据的状态在发生改变。根据职位来配置业务角色即可。

一般来说，系统部署好之后，业务角色会完全初始化好，变更的话需要通过工作流引擎中添加，或者通过添加代码的方式增加。通常企业的职位、职级设置都相似，变更的情况较少发生。

3.4 组织权限

组织架构创建之后，会天然的体现组织权限，表现为数据的归属和访问范围，无需创建角色。组织权限是自动赋予在部门级别上的权限。

比如销售部门拥有销售数据提交、查看、分析报表查看、下载的权限，那么一个用户创建到销售部门下后，会自动继承该部门的组织权限，再根据该用户的具体业务角色在确定其具体可访问的数据。

比如老王是A部门的，那么老王只能访问A部门的数据，不能访问隔壁B部门的数据。老王的业务角色是普通销售员，就只能查看自己的数据，而老王的领导老万是部门经理，就可以查看销售部所有人员的数据。这便是组织权限的具体体现。

四、权限

4.1 准入权限

准入权限是对用户账号的登录限制，原则上属于用户账号体系，和角色关联不大。通常会有如下功能需求：

进入限制

直接限制账号是否拥有登入平台，或登入某个应用的权限，比如普通员工无法进入人事管理应用。

二次验证

二次验证是在识别到用户的登录地点、登录设备、登录客户端变更之后的二次验证，做的比较好的如微信的二次登录验证，支持验证码，邀请好友验证等多种方式。

时间限制

仅允许在规定时间之前使用账号，通常用于发放试用账号之类的临时账号。

设备限制

包括特定设备限制，或者设备数量限制。如果是高级别的安全性需求，登录设备可能需要先进行安全登记，才允许登录。设备数量限制通常是作为付费增值服务，比如印象笔记，免费用户最多只允许在两个设备上同时使用。

客户端限制

客户端限制通常使用的较少，BS应用使用任何浏览器都可以登录。笔者仅在企业邮箱中见过类似限制，Google企业邮箱如果需要使用foxmail类的第三方邮件客户端进行收发邮件，仅知道账号密码是不够的，还需要从Google Mail后台，生成一个实时动态密码进行验证才行。

地理位置限制

登录的地理位置限制，比如只能在工厂范围内。

网络限制

网络限制通常是企业的内网和外网限制，应用和数据只能通过企业内网访问。在一些公安、军工类安全级别高的场景下，设备被人为接入外网后，还会立即发出警报。

4.2 使用权限

用户的使用权限由其组织权限、业务角色、数据状态共同决定，通常为增、删、改、查。不做过多赘述。

另外用户角色可执行的任务，通常是可以访问的系统页面，在做权限系统时，除了要求用户只能访问被分配权限的页面，在用户通过其他方式，如直接访问url时，需要能够进行阻止。

4.3 数据权限

数据权限有两个重要的识别方式，数据状态和数据归属。

数据状态

根据工作流引擎或者业务流程确定，一张请假单可能会有草稿、待审批、审批通过、审批不通过的各种数据状态，不同的数据状态根据工作流的配置自动在各个业务角色间流转。不同数据状态下，不同角色拥有不同的操作。

数据归属

数据归属即为创建这个数据的人或拥有该数据的部门，通常情况下数据的创建人永远拥有该数据的可见的权限，比如我提交的请假单，整个流程中，我都可以随时查看该数据及数据状态的变更。历史记录的查看也依赖创建人拥有数据权限。也有一些特殊情况，比如数据归档之后，对于创建人，可能就不可见了。

One more thing

本文笔者以钉钉进行举例，实际上所有的功能权限都是钉钉租户权限，租户权限是什么意思呢？

钉钉是一个面向企业的SaaS服务系统，那么所有的客户（单个独立注册的企业）在钉钉系统里面都属于钉钉的租户。

在钉钉内部，还有另外一个租户管理系统，用以管理所有已注册租户，比如对租户进行授权，租户行为数据分析等等。租户管理系统内的用户权限也可按照本文的模式进行产品设计。

作者：一直往北方开（微信号：z445388180），多年SaaS产品、购物中心集团CRM、自主创业、云计算虚拟化行业产品经验，文章总结均为落地型实战型产品经验，热爱阅读，持续学习者、思考者

本文由 @一直往北方开 原创发布于人人都是产品经理。未经许可，禁止转载。