浅谈权限系统在多利熊业务应用
GEEK TALK
01
业务介绍
多利熊，是百度旗下的本地生活服务平台。多利熊旨在为用户提供特低价优惠的品质服务，基于百度的AI和双引擎能力，以改变市场格局之势迅速推进，为本地商家提供丰富的营销渠道，决心成为本地生活市场的重塑性力量。
多利熊覆盖餐饮、酒店、景区、休闲娱乐、丽人等众多品类。用户可以花更少的钱享受多利熊甄选的本地生活品质服务。成为多利熊分销达人，自购更省钱，分享直卖可赚取佣金，锁粉政策可让达人长期赚取用户自行下单佣金，发展下游达人组建团队更可赚取团队佣金。
多利熊架构是如何支撑起整个业务生态运转，如下图所示：
如图所示，多利熊整个业务架构分位三层。包括：生态场景层、平台支撑层、基础建设层。
多利熊生态场景：多利熊除了在百度的双引擎、百家号、私域中进行分发外，还扩展到了微信生态圈，建设了多利熊微信小程序，用于在微信生态的分发，通过微信群、微信分享、微信达人引流。除了自建外，也通过合作方式引入第三方服务商、自研商家、本地生活服务平台，从而打造多元化、多类型的本地生活服务生态圈。
多利熊平台支撑：多利熊建设了大量平台，包括：商户平台、运营平台、审核平台、小编平台、分发平台、干预平台、质量平台等等。通过丰富的平台，降低运营成本、提升商家接入效率，从而更好的支撑业务的高速发展，快速迭代。
多利熊基础建设：多利熊的基础建设层，通过集成小程序及百度中台的众多沉淀系统，迅速支撑业务快速迭代。包括：小程序自研的服务化治理方案：天路、天眼、BRCC；小程序沉淀的数据多维度分析报表和稳定性建设监控和治理手段；以及百度丰富的中台系统：交易中台、营销中台、互动中台、审核中台等等。
从图中可以看到，整个多利熊业务架构中，平台角色众多，权限系统面临非常多的挑战。
平台众多，各个平台的账号系统也会存在差异性。权限系统如何支持各平台的隔离设置，保证平台数据的合规性和安全性？
多个平台中存在众多业务角色、角色存在上下级关系，大家需要协同工作。权限系统如何支持高效的配置，保障多角色协同、高效、便利操作？
多个平台基于不同语言开发。权限系统如何保证接入的便捷性？
具体我们是如何建设，解决这些问题的呢？下面将详细介绍下。
GEEK TALK
02
权限系统介绍
2.1 权限系统模型
RBAC(role-based access control )：基于角色的权限访问控制。
RBAC是一种围绕角色和权限定义的访问控制机制，在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。角色与角色的关系可以建立起来以囊括更广泛的客观情况。
RBAC四个核心组成部分：
S（Subject）：主体，一名使用者或自动代理人
R（Role）：角色信息，被定义为一个授权等级的工作职位或职称
SE（Session）：会话级别的身份权限表达，S，R或P之间的映射关系
P（Permissions）：权限， 一种存取资源的方式
RBAC 定义了三个主要规则：
角色分配：只有当主体选择或分配了角色时，主体才能行使权限
角色授权：主体的活动角色必须为主体授权。使用上面的规则 1，此规则确保用户只能承担他们被授权的角色
权限授权：只有为主体的活动角色授权了权限，主体才能行使权限。对于规则 1 和 2，此规则确保用户只能行使他们被授权的权限
RBAC的四个模型：
Flat RBAC：基本的 RBAC 模型，基本的概念是 用户被分配给角色，权限也被分配给角色，用户通过角色获取对应的权限
Hierarchical RBAC：角色被组织成分层结构，其中“较高”层级的角色从的“较低”层级的角色继承所有权限
Constrained RBAC：向角色添加职责分离 (SOD) 的实施
Symmetric RBAC：添加了权限角色审查的要求，类似于 Flat RBAC 中描述的用户角色审查
四种模型的等级和功能描述：
Flat RBAC模型结构：
Hierarchical RBAC模型结构：
Constrained RBAC模型结构：
静态职责分离：
互斥角色：同一个用户在两个互斥角色中只能选择一个
基数约束：一个用户拥有的角色是有限的，一个角色拥有的许可也是有限的
先决条件约束：用户想要获得高级角色，首先必须拥有低级角色
动态职责分离：
会话和角色之间的约束，可以动态的约束用户拥有的角色，如一个用户可以拥有两个角色，但是运行时只能激活一个角色。
Symmetric RBAC模型结构：
2.2 权限系统设计
RBAC模型如何在我们的实际场景中选型和改造是一件深入思考的事情。首先我们要基于我们的业务场景圈定权限系统核心功能。
我们做的是本地服务tob业务，所以对于商家我们会有商家平台，除了商家的管理平台之外，我们还需要对于o端建设平台进行管理，以及我们开发同学的干预平台等，这些平台都需要权限管控。每个系统都有各自的页面，每个页面都有自己的功能实现，大到页面权限的管控，小到按钮的管控，在未来的业务发展中都是我们权限系统所需要考虑的。所以我们的权限管理相对来说任务也是比较繁重的。
针对我们以上的业务场景和需求形态，我们首先敲定了权限系统的核心职责：
页面菜单权限的管控
功能组权限管控
按钮功能权限管控
支持多业务线
我们基于Flat RBAC设计了如下的RBAC模型：
基于我们设计的RBAC模型，继续细节的考量
支持多业务线接入和业务线业务隔离
需要支持菜单权限、功能组权限、按钮权限的管控
首先考量业务线支持问题，对于这个事情我们使用了单独的表来表达产品线信息，在设计user，role 和 func 表，都需要与业务线信息表关联。
于是我们思考如何支持页面菜单权限、功能组权限和按钮权限的问题。
菜单权限、功能组权限和按钮权限都隶属于功能权限，于是我们使用一张表进行功能权限的表达，和前端页面的树形结构表达相映射，构造一个功能权限树，于是我们最终落地的ER图如下：
业务线
对于不同的系统，各自的用户体系、角色管理、权限管理都是有差异的，需要满足不同的系统的诉求，首先要做的是对各个系统的隔离。
我们设计了业务线信息的表，核心字段如下：
该表主要描述业务线的基础信息内容，用于更好的管理和配置。
业务线隔离的实质是用户表、角色表和权限表都需要指定业务线的prod_id，这样在BRAC模型的三个核心角色里都做到了业务线隔离，每个系统在使用自己的数据的时候都需要指定自己的prod_id。
用户
从业务角度分析来看，商家平台是对外面向商家登录的用户账号体系，对于o端来说，是面向我们运营同学，bd同学使用的场景，使用的内部账号体系，所以，我们这里就有这不同的用户登录体系。
我们面临着多种用户体系形态，所以，我们就兼容不同的用户体系设计，由此我们设计的用户表核心字段如下：
prod_id、user_type 和 login_id 组成联合唯一建。
角色
FLAT BRAC模型的角色并没有涉及角色的继承关系，我们现在的业务没有涉及到这么复杂的角色关系，所以我们用最简单的方式来表达角色信息，从而减少对于角色身份的管理和维护。
角色的核心字段如下：
prod_id 和 en_name组成联合唯一建。
权限
权限这块是我们思考最多的地方，我们希望可以通过统一的标准将前端页面的功能权限进行约定。
我们去了解前端使用的设计，无论是b端还是o端前端，都是我们自己的前端团队，他们讲使用统一的前端框架和风格进行设计，这样对于我们得权限系统来说就是最好的情况，我们首先需要面对的就是这样风格的权限管控。
首先看下我们b端的前端页面样式如下：
这里左侧为页面菜单栏，右侧为菜单栏对应的页面，里面就是涉及到的各个功能模块。
我们这里要处理的就是:
菜单栏的权限管控：菜单是否展示，菜单层级结构以及菜单设计的页面权限内容
页面权限：页面里涉及到的功能权限
功能组：页面中某些功能模块的功能权限
按钮：按钮的权限
于是我们准备改造权限表为树状结构如图所示：
基于这样的树状结构，我们就可以描述出前端的整个权限管控内容，权限的核心字段如下：
整体的核心设计就是这样，结合我们的微服务框架理念，我们整体的业务交互图如下：
现在我们权限系统已经在支持着多利熊B端平台和O端平台的权限管控，并正在支持小编平台，后续我们将继续服务更多平台的权限管控。
2.3 多利熊业务应用
基于上述权限系统的设计，使得多利熊业务在面对庞大的人员组织架构、复杂的业务系统时，也能够高效、灵活地实现权限的管理。
如下图的商务运营系统应用场景所示，该系统是面向内部多个团队开放的，每个团队都具有不同的职能，甚至团队内部也划分了不同的岗位。
针对该应用场景，系统权限的分配与管理主要包括以下的步骤：
1. 明确系统角色：如上图3.1所示，商务运营系统包括商家、商铺、订单等在内的多个平台。针对每个平台，需要确定好平台内需要哪些角色，不同角色在平台内承担着不同的任务。例如商户入驻系统包括了帮助商户入驻的角色、帮助商户管理成员的角色等。
2. 明确角色权限：针对角色承担的具体任务，其对应的系统可操作权限也是不同的，这就需要每一个角色分配具体的操作权限。例如帮助商户入驻的角色，可以有录入、查询、修改商家信息等接口与按钮的权限。
3. 明确团队架构：如上图3.2所示，审核管理项目需要有商务、运营、客服等多个团队，不同团队下还有相应的岗位来承担不同的任务。例如商务团队包括商务小编、商务管理员、商务负责人等岗位。
4. 为团队成员分配系统角色：为了将系统内的角色权限与团队内的组织架构进行结合，如上图3.3所示，管理人员可以通过角色配置的方式，来为岗位的人员赋予对应平台的权限。例如商务小编只有商品管理的角色，而商务可以同时有商品管理角色、商家入驻角色等，这样就实现了基于角色进行权限管理的实际应用。
GEEK TALK
03
权限系统思考
有了功能权限，我们进而应该思考另外一块领域，就是数据权限。
数据权限，就是有或者没有对某些数据的访问权限，具体表现形式就是当某用户有操作权限的时候，但不代表其对所有的数据都有查看或者管理权限。数据权限有两种表现形式：一种是行权限，另外一种是列权限。
所谓行权限，就是限制用户对某些行的访问权限，比如：只能对本人、本部门、本组织的数据进行访问；也可以是根据数据的范围进行限制，比如：合同额大小来限制用户对数据的访问。所谓列权限，就是限制用户对某些列的访问权限，比如：某些内容的摘要可以被查阅，但是详细内容就只有VIP用户才能查看。
通过数据权限，可以从物理层级限制用户对数据的行或列进行获取，这种方式比把所有数据拿到之后再根据用户权限来限制某些行或列有诸多好处。以列表数据权限为例，主要通过数据权限控制行数据，让不同的人有不同的查看数据规则；要实现数据权限，最重要的是需要抽象出数据规则。
但是光有数据规则是不够的，我们还需要把数据规则跟资源和用户进行绑定。这样资源就可以关联上了数据规则。
在设计上我们需要一个单独的数据规则管理功能，方便我们录入数据规则，然后在资源管理页面上就可以选择内置的数据规则进行资源与规则的绑定。
那么如何让不同的用户拥有不同的数据规则呢？
在RBAC模型中，用户是通过授予不同的角色来进行资源的管理，同理我们可以让角色在授予权限的时候关联上数据规则，这样最终在系统上就体现为不同的用户拥有不同的数据规则。
基于此，我们可以基本实现RBAC与数据规则的绑定；同时数据权限是一个实现相对比较复杂的功能，除了在RBAC模型基础上进行扩展，是否还有其他更合理的思路，留给大家进行思考。
END