系统权限涉及身份验证服务和访问控制服务两个过程，那么它们是如何操作的呢？本文将简述其中的过程，希望能对大家有所帮助。

很多产品小伙伴在刚接触权限控制问题的时候，往往搜到的都是RBAC、ABAC等权限控制技术实现方法，而这种抽象方法其实不能够帮大家形象地了解“权限是如何生效的”这个问题.为什么不同角色看到的菜单不一样？不同角色拥有的操作不一样？同一个菜单列表里的数据范围也不一样？

这里主要涉及2大过程：

今天我试着用图解的方式，告诉大家权限是如何生效的。

一、系统权限如何生效

我们打开一个系统，第一步要做的就是登录，最常见的就是使用账号密码登录。当我们输入正确的账号和密码组合时，提交给系统后，系统的“身份验证服务”就会对我们提交的账号和密码组合进行验证，看看是否属于系统用户。

身份验证服务相当于门卫

在验证成功后，“身份验证服务”会给用户发一个凭证，这个凭证就相当于一个通行证，方便用户与系统后续的交互行为。

经过身份验证服务后，算是进了系统的“大门”了，但是进门之后，并不一定就可以访问系统里所有的内容，因为这时候有“访问控制服务”来对每个进来的用户进行访问控制。我们常说的页面权限控制、操作权限控制、数据权限控制等都属与“访问控制”的范畴。

访问控制服务是“钥匙”

前面提到的角色权限控制（RBAC模式）就属于访问控制的一种经典实现方式，也就是使用“角色”这个中间对象，关联允许访问的菜单以及对应菜单上的操作（比如新增、修改、删除），然后被赋予该角色的用户都能够被授予这些访问权限。

用角色控制菜单和操作权限

在数据权限上，我们一般使用组织架构管理来进行数据范围的控制。比如“订单管理”菜单中，包含了广东省所有地级市的订单内容，我们就使用广东省总公司（父级）、广州市分公司（子级）、深圳市分公司（子级）这样的组织层级，对订单管理列表的数据内容，作一个地市上的划分和控制。

比如属于广东省总公司层级的账号，可以看到所有的订单数据，而属于广州市分公司层级的账号，只能看到广州市的订单数据，看不到其它城市的订单数据。

用组织架构进行数据权限的区隔

二、UML时序图

下面我们用时序图强化一下对登录后，权限生效过程的理解：

1. 当账号密码通过验证时，我们就进入了系统大门；
2. 系统根据访问控制服务的反馈，加载对应的页面元素，其中包含菜单、按钮、列表数据等受访问控制的对象；
3. 系统页面加载完毕，用户可以进行浏览和操作。

本篇仅是想给各位产品经理科普权限生效的过程，也是“图解权限”系列的第一篇，后续我们会结合具体的后台页面，给大家具体呈现演绎一下RBAC角色权限控制的实际效果。

作者：产品经理P仔 ， 公众号：产品经理P仔

本文由@产品经理P仔 原创发布于人人都是产品经理，未经许可，禁止转载。

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

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。