权限管理方法及装置与流程

1.本公开涉及数据处理技术领域，具体涉及到一种权限管理方法及装置。


背景技术：

2.在企业实际的生产环境中，每个员工都有不同的职责，也就意味有着不同的权限范围。那么就需要有一个系统来统一管理所有员工的权限。现在市面上，大多数公司都采用了基于角色控制的rbac或者是基于属性控制的abac。
3.rbac模型在需要满足灵活复杂权限控制的场景就会显得力不从心，例如当需要赋予同一角色的人仅根据其岗位或者其他属性的不同，其权限自动的有不同的变化的场景。
4.rbac模型有角色膨胀的问题，当一类用户与另一类用户百分之九十以上的权限是重合的，但是由于其中百分之十的差异，就需要为这两类用户分别建不同的角色。在公司生产生活中，角色的增长将成几何数，极大地增加了管理员人员的维护成本，用户在申请权限时也会因角色之间的细微差异而无法区分。
5.abac模型权限太过于灵活、复杂，一旦用户量及权限数量上升时，权限管理的复杂程度将会大大提高。例如kubernetes在早期采用了abac权限管理模式，但是到后面不得不转用rbac权限模式，原因是权限控制做的太复杂了。


技术实现要素：

6.本公开的主要目的在于提供一种权限管理方法。
7.为了实现上述目的，根据本公开的第一方面，提供了一种权限管理方法，包括：在定义至少一个角色后，为所有用户配置对应的角色；基于权限的类别，建立权限树，以将每一个所述角色关联至对应的权限树，其中，所述每一个权限树包括一个根节点、以及至少一个子节点；在获取到至少一个类别的资源后，针对每一类资源建立资源树，其中，每一个资源树包括至少一个节点，每一个所述节点上挂载了资源；将所述资源树节点中的预设节点关联至预设用户。
8.可选地，方法还包括：响应于接收到用户的操作请求，在确定所述用户对应的目标角色后，确定所述目标角色对应的目标权限树中是否包含所述操作对应的权限。
9.可选地，方法还包括：如果包含所述操作对应的权限，确定所述用户关联的资源树中的节点是否包含所请求操作的；将所述目标节点挂载的目标资源反馈至所述用户。
10.可选地，将每一个所述角色关联至对应的权限树包括：将每一个所述角色关联至对应的权限树的根节点上；或，将每一个角色关联至对应的权限树的部分子节点上。
11.可选地，方法还包括：响应于接收到为用户更改预配置的角色请求，为所述用户配置新角色。
12.可选地，方法还包括：响应于接收到为用户更改预关联的所述资源树中预设节点的请求，为所述用户更改关联关系。
13.可选地，所述针对每一类资源建立资源树包括：基于预设的控制逻辑规范，自上而
下建立所述资源树。
14.根据本公开的第二方面，提供了一种权限管理装置，包括：配置单元，被配置成在定义至少一个角色后，为所有用户配置对应的角色；生成单元，被配置成基于权限的类别，建立权限树，以将每一个所述角色关联至对应的权限树，其中，所述每一个权限树包括一个根节点、以及至少一个子节点；第二生成单元，被配置成在获取到至少一个类别的资源后，针对每一类资源建立资源树，其中，每一个资源树包括至少一个节点，每一个所述节点上挂载了资源；关联单元，被配置成将所述资源树节点中的预设节点关联至预设用户。
15.根据本公开的第三方面，提供了一种计算机可读存储介质，存储有计算机指令，所述计算机指令用于使所述计算机执行权利要求1
‑
7任意一项所述的权限管理方法。
16.根据本公开的第四方面，提供了一种电子设备，包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的计算机程序，所述计算机程序被所述至少一个处理器执行，以使所述至少一个处理器执行第一方面任意一项实施例所述的权限管理方法。
17.在本公开实施例中，在传统的权限控制方法上又引入了“资源”和“资源树”的概念，结合了rbac模型与abac的优点，以资源为基础进行权限配置，通过在权限模型下根据对应的层级关系逐一建立资源，达到精准的权限控制。解决了rbac模型与abac模型存在的缺陷。
附图说明
18.为了更清楚地说明本公开具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本公开的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
19.图1是根据根据本公开实施例的权限管理方法的流程图；
20.图2是根据本公开实施例的权限管理方法的应用场景图；
21.图3是根据本公开实施例的权限管理装置的结构示意图；
22.图4是根据本公开实施例的电子设备的示意图。
具体实施方式
23.为了使本技术领域的人员更好地理解本公开方案，下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分的实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本公开保护的范围。
24.需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清
楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
25.需要说明的是，在不冲突的情况下，本公开中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本公开。
26.目前rbac对于数据权限的管理，一般是采用客户端程序硬编码来解决。这就会使得权限无法动态配置，并且由权限依赖于客户端，存在安全隐患。
27.abac模型的另一个问题是，由于其复杂性，在权限的查验，问题追踪，权限整体排查，公司级别的权限审计方面都有不好的体验。
28.根据本公开实施例，提供了一种权限管理方法，如图1所示，该方法包括如下的步骤101至步骤104：
29.步骤101：在定义至少一个角色后，为所有用户配置对应的角色。
30.在本实施例中，可以按照预设规范定义角色，以使不同的角色具有不同的权限，例如，对于金融行业，角色可以被定义为包括但是不限于管理员、经办员、审核员等等，根据不同业务规范可以定义的角色类型多种多样。
31.步骤102：基于权限的类别，建立权限树，以将每一个所述角色关联至对应的权限树，其中，所述每一个权限树包括一个根节点、以及至少一个子节点。
32.在本实施例中，权限树的结构(层次结构)可以基于业务逻辑确定，权限树可以是用于表示操作权限的权限树，根节点可以是“操作权限”，组成树结构的子节点可以包括但是不限于“查询”、“编辑”、“下载”、“创建、清空、引入、输出”等等，这些仅仅是示意性的。各个子节点的层次基于业务层次确定，例如“操作权限”作为根节点，其子节点的第一层是“查询”等，而作为“查询”的子节点可以是“下载”等，该逻辑结构基于业务逻辑实现。
33.具体地，在建立权限树之后可以将每一个角色关联至对应的权限树。
34.更具体地，权限树可以一系列需做权限控制的组件构成，例如，api，菜单，按钮，页面元素等。
35.作为本实施例一种可选的实现方式，将每一个所述角色关联至对应的权限树包括：将每一个所述角色关联至对应的权限树的根节点上；或，将每一个角色关联至对应的权限树的部分子节点上。
36.在本可选的实现方式中，如果将角色关联至权限树时，可以是关联至根节点后便与所有的子节点关联；也可以是基于用户端的配置，选择性的关联权限树的部分子节点。
37.步骤103：在获取到至少一个类别的资源后，针对每一类资源建立资源树，其中，每一个资源树包括至少一个节点，每一个所述节点上挂载了资源。
38.在本实施例中，资源的类别包括多种，例如，服务资源、一组相互关联的数据、应用、数据库、运营平台的菜单等。针对每一类的资源可以建立资源树。在资源树的节点上挂载需要控制的资源，例如文件资源，数据库资源等等。
39.作为本实施例一种可选的实现方式，针对每一类资源建立资源树包括：基于预设的控制逻辑规范，自上而下建立所述资源树。
40.在本可选的实现方式，在建立资源树时，可以按照控制逻辑粒度，自上而下建立树结构，例如，按照企业架构建立、按照文件夹的层级建立、按照地区划分建立，也可以自定义方式建立。在此不对控制逻辑进行限定，也不对其粒度进行限定，例如报表资源下的地区区分粒度。
41.步骤104：将所述资源树节点中的预设节点关联至预设用户。
42.在本实施例中，可以将资源树上的预设节点关联至预设用户，也可以基于用户端的配置将资源树上的预设节点关联至预设用户。例如，以报表资源为例，报表资源的子节点包括华南地区报表、华北地区报表，那么可以将其中任意一个子节点、或者全部子节点关联至预设用户。可以理解的是，每一个用户关联哪些节点是可配置的。建立的资源树中的节点关联至用户，实现了界定“数据权限”范围的目的。
43.本实施例的新增了“资源”和“资源树”的概念，把所有管理的数据统称为资源，对于资源按照数据权限管理层级进行划分，就形成了资源树。资源树以树状结构管理资源，通过资源路径来界定用户的权限范围，解决用户达到真正灵活控制权限。
44.作为本实施例一种可选的实现方式，方法还包括：响应于接收到用户的操作请求，在确定所述用户对应的目标角色后，确定所述目标角色对应的目标权限树中是否包含所述操作对应的权限。
45.在本可选的实现方式中，请求操作的目的是请求操作资源。可通过拦截请求，解析用户的权限树及资源树，以分析用户的权限可行性。当基于步骤101至步骤104建立了权限模型的结构后，便可实现权限管理，管理方法可以包括在接收到用户通过用户端的操作请求之后，由于预先将用户信息与角色关联，那么可以确定用户对应的角色；而每一个角色已经预先关联了权限树，便可确定该用户的权限包括哪些。
46.作为本实施例一种可选的实现方式，方法还包括：如果包含所述操作对应的权限，确定所述用户关联的资源树中的目标节点；将所述目标节点挂载的目标资源反馈至所述用户。
47.在本可选的实现方式中，根据用户请求的操作，判定该用户是否有操作权限，如果有操作权限，那么判定用户所预先关联的资源树节点，以得到用户的数据权限，如果对请求操作的数据有数据权限，那么将节点下的资源反馈至用户。同时，如果有操作权限，判定用户所预先关联的资源树节点，以得到用户的数据权限，如果对请求操作的数据中包含未关联的资源树节点(数据)，则不将所请求的数据资源反馈至用户。例如，参考图2，图2示出了权限管理模型的应用场景图，用户1和用户2均属于管理员的角色1，其中用户1和用户2的角色可以对应相同的权限树，例如，用户1、用户2关联了操作权限下的“查看文件”、“查看报表”权限，而用户1预先关联了资源树中“文件资源”中的“资信文件”子节点；以及关联了“报表资源”中的“华南地区报表”子节点；用户2关联了操作权限“查看文件”、“查看报表”权限，而用户2预先关联了“文件资源”中的“风险文件”子节点；以及关联了“华中地区报表”子节点。因此当用户1在具有“查看报表”权限的前提下，只具备查看“华南地区报表”所挂在的资源；在“查看文件”权限的前提下，只具备查看“资信文件”的权限。因此如果用户1通过用户端发送查看“华中地区报表”资源的请求、或者发送查看“风险文件”资源的请求，服务器确定用户1不具备上述“数据权限”，则不反馈对应的“华中地区报表”资源、或者“风险文件”资源给用户1。
48.作为本实施例一种可选的实现方式，方法还包括：响应于接收到为用户更改预配置的角色请求，为所述用户配置新角色。
49.在本可选的实现方式中，如果接收到用户端发送的为用户更改角色的请求后，更改用户预配置的角色，更换为新角色，从而更改了用户的操作权限。此时也可以自定义更改
用户关联的资源树中的子节点，也即数据权限。为用户更改角色后，用户的操作权限相应更改，数据权限可更改也可不更改。
50.作为本实施例一种可选的实现方式，方法还包括：响应于接收到为用户更改预关联的所述资源树中预设节点的请求，为所述用户更改关联关系。
51.在本可选的实现方式中，在接收到用户端发送的为用户更改预关联的资源树中的节点请求后，为用户更改与资源树节点的关联关系，即更改数据权限。为用户更改与资源树节点的关联关系后，如果用户的角色未更改，那么用户的操作权限也不更改，即数据权限更改后，操作权限可更改也可不更改。
52.本实施例对于用户权限的判断，分为了两个部分，一部分是判断操作权限是否满足。另一部分是判断数据权限是否满足，通过解析用户的资源树路径，得到用户的数据权限范围。
53.本实施例在传统的权限控制方法上又引入了“资源”和“资源树”的概念，结合了rbac模型与abac的优点，以资源为基础进行权限配置，通过在权限模型下根据对应的层级关系逐一建立资源，达到精准的权限控制。同时又区分了操作权限和数据权限，使得权限管理更加灵活，且管理的复杂度大大降低。
54.本实施例满足灵活复杂权限控制的需要，支持细粒度的数据权限模式。区分操作权限与数据权限，简单场景接入非常简单。摒弃客户端硬编码的方式，支持权限动态配置，热插拔。解决角色膨胀的问题，有效控制各分布式系统角色在十个到十五个之间。能够满足平台系统级别乃至公司级别的权限审计。
55.需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
56.根据本公开实施例，还提供了一种用于实施上述权限管理方法的装置，如图3所示，该装置包括：
57.配置单元301，被配置成在定义至少一个角色后，为所有用户配置对应的角色；生成单元302，被配置成基于权限的类别，建立权限树，以将每一个所述角色关联至对应的权限树，其中，所述每一个权限树包括一个根节点、以及至少一个子节点；第二生成单元303，被配置成在获取到至少一个类别的资源后，针对每一类资源建立资源树，其中，每一个资源树包括至少一个节点，每一个所述节点上挂载了资源；关联单元302，被配置成将所述资源树节点中的预设节点关联至预设用户。
58.装置还包括第一确定单元，响应于接收到用户的操作请求，在确定所述用户对应的目标角色后，确定所述目标角色对应的目标权限树中是否包含所述操作对应的权限。
59.装置还包括：第二确定单元，如果包含所述操作对应的权限，确定所述用户关联的资源树中的节点是否包含所请求操作的；将所述目标节点挂载的目标资源反馈至所述用户。
60.将每一个所述角色关联至对应的权限树包括：将每一个所述角色关联至对应的权限树的根节点上；或，将每一个角色关联至对应的权限树的部分子节点上。
61.装置还包括配置单元，响应于接收到为用户更改预配置的角色请求，为所述用户配置新角色。
62.装置还包括更改单元，响应于接收到为用户更改预关联的所述资源树中预设节点的请求，为所述用户更改关联关系。
63.针对每一类资源建立资源树包括：基于预设的控制逻辑规范，自上而下建立所述资源树。
64.本公开实施例提供了一种电子设备，如图4所示，该电子设备包括一个或多个处理器41以及存储器42，图4中以一个处理器41为例。
65.该控制器还可以包括：输入装置43和输出装置44。
66.处理器41、存储器42、输入装置43和输出装置44可以通过总线或者其他方式连接，图4中以通过总线连接为例。
67.处理器41可以为中央处理器(centralprocessingunit，cpu)。处理器41还可以为其他通用处理器、数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现场可编程门阵列(field
‑
programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等芯片，或者上述各类芯片的组合。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
68.存储器42作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序、非暂态计算机可执行程序以及模块，如本公开实施例中的控制方法对应的程序指令/模块。处理器41通过运行存储在存储器42中的非暂态软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例的权限管理方法。
69.存储器42可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据服务器操作的处理装置的使用所创建的数据等。此外，存储器42可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施例中，存储器42可选包括相对于处理器41远程设置的存储器，这些远程存储器可以通过网络连接至网络连接装置。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
70.输入装置43可接收输入的数字或字符信息，以及产生与服务器的处理装置的用户设置以及功能控制有关的键信号输入。输出装置44可包括显示屏等显示设备。
71.一个或者多个模块存储在存储器42中，当被一个或者多个处理器41执行时，执行如图1所示的方法。
72.本领域技术人员可以理解，实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各电机控制方法的实施例的流程。其中，存储介质可为磁碟、光盘、只读存储记忆体(read
‑
onlymemory，rom)、随机存储记忆体(randomaccessmemory，ram)、快闪存储器(flashmemory)、硬盘(harddiskdrive，缩写：hdd)或固态硬盘(solid
‑
statedrive，ssd)等；存储介质还可以包括上述种类的存储器的组合。
73.虽然结合附图描述了本公开的实施方式，但是本领域技术人员可以在不脱离本公开的精神和范围的情况下作出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。