在B端业务场景下，不同的角色会在不同的场景下使用产品。所以说，用户与角色权限是必不可少的一环。
站在巨人的肩膀上看问题，目前市场上普遍使用的RBAC权限模型。
一、了解RBAC
RBAC（Rloe-Based Access Contol），基于角色的访问控制，就是将用户通过角色与权限进行关联。其实就是构建了“用户-角色-权限”的授权模型。
具体做法是，先给系统配置好各个角色及对应权限，然后创建/注册用户时，给用户配置对应的角色。具体顺序如图：
二、了解权限
角色权限大致分为两种，功能权限与数据权限。
功能权限比较简单，就是规定该角色是否能进行某种操作。功能权限的设计需要考虑颗粒度问题：既可以设置该角色能否进行该页面的所有（某个）操作，也可以具体到该页面某个操作，该角色能否操作。例：订单管理系统-订单页面，财务角色可以导出订单报表，但财务角色没有下单操作权限。
数据权限则是规定该角色能看到哪些数据。同样的，数据权限也可以关注颗粒度，可以规定角色能看到哪些页面，也可以该页面具体哪些字段是该用户可以查看的。但一般来说，若该角色没有该页面的数据权限，默认也无功能权限（页面都看不到，更别谈什么操作了）。
事实上，当用户涉及到所属组织，权限的设计会变得更复杂一些。
三、RBAC的拓展
① RBAC0模型
若不考虑角色的组织关系时，上述就功能及数据权限已经够用了，这种基础模型就是“RBAC0”模型——权限赋予角色，用户分配角色，角色与用户之间可以多对一，也可以是多对多的关系。
②RBAC1模型
上面权限提到有时需考虑用户组织架构的问题。
举一个例子：某集团总部可以查看其子公司的所有数据，且子公司仅能操作本公司及以下本公司该部门下的功能，但不可操作别的子公司或总部的功能。
这里就涉及到公司架构的问题，由此RBAC变化出了第二种模式——RBAC1模型。基于RBAC0模型，加入角色之前的继承关系，引入“角色等级”的概念。
我理解的RBAC1模型有以下原则：
- 高级别角色创建的必须为低级别角色，不可平级创建。
- 低级别角色维护权限时，仅能维护比其低级别的角色，高级别或平级角色无权限维护。
- RBAC1模型只规定该角色能否操作某功能。
这时你是否会产生这样的疑问：RBAC1仅规定角色的功能/数据查看权限，那具体能看到哪些数据又怎么决定呢？
当我了解完RBAC1模型的知识后，我就产生了这样的疑问。后来重新理了一下逻辑，角色权限并不能帮助我们规定某二级用户应该查看什么数据，真正规定查看数据的应该是“用户与组织架构之间的关系”。
回想一下上述的例子，集团能够查看旗下所有子公司的数据，但A子公司某个部门（相当于用户）也仅能查看到A子公司的数据，无法查看别的子公司，由此可以得到的结论是：低级用户所能查看的数据为其所属组织所能查看数据的子集。
所以在创建用户或用户注册的时候，需要同时维护该用户所属组织、角色类型这两个重要信息。借由这两个信息，可以解决该用户的功能、数据权限的问题。
③RBAC2、RBAC3模型
前面也有提到一个用户可能会拥有多个角色，RBAC2模型主要是对角色的访问进行控制，应用某些限制条件，限制该用户在登录之后仅充当其中一种角色。这种场景在我工作中应用的场景还没出现，便没有过多的了解。
RBAC3模型，则是将RBAC1、RBAC2进行整合，仅有角色分级，又有限制条件。
四、总结
上诉基于我的理解，我认为“用户-角色-组织架构”三者是不分家的。具体顺序为先有角色与组织架构，再添加用户/用户注册时，分别配置角色，组织架构，最后完成功能、数据权限的约束。
RBAC模型自创建以来有着许多分化，具体使用哪种分化模型还需要产品经理根据实际使用场景进行抉择。其实RBAC模型还不仅如此，还有“用户组”等其他概念，这里不多作阐述，有兴趣的小伙伴可以自行找资料。