CN115618387A - 基于abac的鉴权方法、装置、设备及计算机可读介质 - Google Patents

Abstract

本申请提供了一种基于ABAC的鉴权方法、装置、设备及计算机可读介质，其中，一种基于ABAC的鉴权方法，所述方法包括：接收用户的请求信息；根据目标授权规则对所述请求信息进行鉴权，得到鉴权结果；所述目标授权规则为基于所述ABAC的默认授权条目的层级关系，进行条目扩展后得到的授权规则；根据所述鉴权结果，对所述请求信息放行或者拦截。本申请提供了一种基于ABAC的鉴权方案，可以至少用以解决现有的基于ABAC的鉴权方式，需要耗费很大的计算量的技术问题。

Description

基于ABAC的鉴权方法、装置、设备及计算机可读介质

技术领域

本申请涉及信息技术领域，尤其涉及一种基于ABAC的鉴权方法、装置、设备及计算机可读介质。

背景技术

在操作***中，权限是保证多用户操作***正常工作的一种非常重要的机制。对于某些文件或者程序来说，它有自身的属性，明示着哪种权限的用户可以使用它读写或者执行功能。而对于一些通用的程序来说，哪个用户运行它，它就会自动继承那个用户的权限。例如，在Windows中有一个Administrator用户和一个普通用户Etuser，Administrator用户打开一个记事本和Etuser用户打开记事本的权限是不一样的。其中，权限管理***中的基于角色的访问控制和基于属性的访问控制是被大家广泛采用的两种权限模型。

基于属性的访问控制，英文全称Attribute-based Access Control，简称“ABAC”，是一种为解决行业分布式应用可信关系而提出的访问控制模型，ABAC访问控制利用了一组称为“属性”的特征来进行访问控制，这包括实体的主体属性(又称用户属性)、客体属性(又称资源属性)和环境属性。

基于角色的访问控制，英文全称Role-Based Access Control，简称“RBAC”，是一种面向企业安全策略实施的访问控制方式。其基本思想是对***操作的各种权限不是直接授予具体的用户，而是在用户集合与权限集合之间建立一个角色集合，每一种角色对应一组相应的权限。一旦用户被分配了适当的角色后，该用户就拥有此角色的所有操作权限。这里，角色通常是指具有某些共同特征的一组人，例如:部门、地点、资历、级别、工作职责等。

与RBAC相比，ABAC能够对资源细粒度地授权以及根据上下文动态执行，具备更强的灵活性和动态性。

在实际应用中，ABAC和RBAC往往会被使用在需要进行权限继承的场景中，权限继承，即是说哪些用户执行的命令自动继承当前用户的权限，而涉及到操作那些没有当前用户权限的文件时，操作***就可以自动中断并提示。

发明人发现相关技术中至少存在如下技术问题：

在需要进行权限继承的场景中，由于RBAC具有权限与角色相关联的特性，因此可以通过角色的授权逻辑来实现分层级的继承关系。但是ABAC授权的逻辑通常是碎片化的，且依赖于上下文属性，这使得基于ABAC的权限继承通常是隐式的且与业务逻辑耦合，然而，这种隐式授权下的权限继承方式，需要耗费很大的计算量，即对***的计算性能具有较高的损耗。

发明内容

本申请的一个目的是提供一种基于ABAC的鉴权方法、装置、设备及计算机可读介质，至少用以解决现有的基于ABAC的鉴权方式，需要耗费很大的计算量的技术问题。

为实现上述目的，本申请的一些实施例提供了一种基于ABAC的鉴权方法，所述方法包括：接收用户的请求信息；根据目标授权规则对所述请求信息进行鉴权，得到鉴权结果；所述目标授权规则为基于所述ABAC的默认授权条目的层级关系，进行条目扩展后得到的授权规则；根据所述鉴权结果，对所述请求信息放行或者拦截。

本申请的一些实施例还提供了一种基于ABAC的鉴权装置，所述装置包括接收模块、鉴权模块和输出模块：所述接收模块，用于接收用户的请求信息；所述鉴权模块，用于根据目标授权规则对所述请求信息进行鉴权，得到鉴权结果；所述目标授权规则为根据所述ABAC的默认授权条目的层级关系，进行条目扩展后得到的授权规则；所述输出模块，用于根据所述鉴权结果，对所述请求信息放行或者拦截。

本申请的一些实施例还提供了一种基于ABAC的鉴权设备，所述设备包括：一个或多个处理器；以及存储有计算机程序指令的存储器，所述计算机程序指令在被执行时使所述处理器执行如上所述的基于ABAC的鉴权方法。

本申请的一些实施例还提供了一种计算机可读介质，其上存储有计算机程序指令，所述计算机程序指令可被处理器执行以实现如上所述的基于ABAC的鉴权方法。

相较于现有技术，本申请实施例提供的方案中，通过在接收用户的请求信息后，根据目标授权规则对所述请求信息进行鉴权，得到鉴权结果，然后再根据所述鉴权结果，对所述请求信息放行或者拦截。其中，由于本申请实施例中的目标授权规则，是根据ABAC的默认授权条目结构的层级关系，对ABAC的默认授权条目结构进行扩展而得到的授权规则，本质上对层级关系作出了进一步的优化扩展，使得把相关技术中无法事先缓存的进行计算的权限转移到了ABAC中，构建了可以以较低的计算性能损耗来支持隐式权限继承的ABAC模型，因此，降低了权限管理***的计算复杂度，进而降低了耗费的计算量的开销，同时，还可以提升鉴权效率。

附图说明

图1为本申请实施例提供的一种基于ABAC的鉴权方法的流程图；

图2为本申请实施例提供的一种相关技术中的权限管理***的结构示意图；

图3为本申请实施例提供的一种基于ABAC的鉴权方法的应用实例的示意图；

图4为本申请实施例提供的一种的基于ABAC的鉴权装置的结构示意图；

图5为采用本申请实施例提供的一种基于ABAC的鉴权的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在本文中使用以下术语。

分层：如果分层清晰而准确，可以看出这两个业务上层具有相同的抽象，即最上层都是组件与布局的结合，而筛选联动与数据查询，以及从数据模型映射到图元关系的映射功能都属于附加项，这些项移除了也不影响***的运行。

碎片化：逻辑是自身将碎片信息建构到一起的产物。

算法复杂度：分为时间复杂度和空间复杂度。其作用：时间复杂度是指执行算法所需要的计算工作量；而空间复杂度是指执行这个算法所需要的内存空间。(算法的复杂性体现在运行该算法时的计算机所需资源的多少上，计算机资源最重要的是时间和空间(即寄存器)资源，因此复杂度分为时间和空间复杂度。)其中，时间复杂度是指一个算法花费的时间与算法中语句的执行次数成正比例，哪个算法中语句执行次数多，它花费时间就多。

图，是由若干给定的顶点及连接两顶点的边所构成的图形，这种图形通常用来描述某些事物之间的某种特定关系。顶点用于代表事物，连接两顶点的边则用于表示两个事物间具有这种关系。

数据库，英文全称Data Base，简称DB，是依照某种数据模型组织起来并存放二级存储器中的数据集合。

MongoDB：一个基于分布式文件存储的数据库，旨在为WEB应用提供可扩展的高性能数据存储解决方案。

本文首先对相关技术中的隐式授权进行说明。

隐式授权与显式授权相对，是指没有进行过明确声明的权限授予逻辑。隐式授权通常与业务中具体场景和实体的交互关系有逻辑关联，鉴权时通常也需要通过动态计算。

举例来说，某业务中有项目和知识库两种实体，可以通过ABAC将这两种实体的权限定向授权给某些用户。这种明确的授权动作即为显式授权，这种情况下，ABAC在鉴权时只需要判断是否存在类似(知识库A，用户a)的授权条目即可。但在某些业务场景下，项目和知识库的权限不是独立的。比如有一需求如下：管理员把某项目p添加进知识库A，那么之前拥有知识库A权限的用户a，现在也应该被允许访问项目p。对此，在相关技术中，ABAC往往不会新创建一条明确的(项目p，用户a)授权条目。而是使得在这条业务路径中，用户a对项目p的权限是从项目p的父级知识库A继承而来，这种间接的权限继承的方式即隐式授权。

那么，在上述相关技术所提到的例子中，ABAC为什么不从新创建一条明确的(项目p，用户a)授权条目，使用显式授权的方式呢？对此，发明人指出，如果要使用显式授权的方式，那么当依赖某一业务路径上的任意节点发生变化时，则需要将该变化同步更新到ABAC中所有与该业务路径相关联的条目。继续以上述的用户、知识库和项目三者之间的授权关系为例来说，可以通过ABAC预先构建好与对应任务相关联的全部项目与全部授权对象(用户)的条目的集合：(a1,an)x(p1,pn)。那么当存在对其进行更新的更新信息时，应至少考虑以下三种场景：

(1)当授权对象发生变化时，需要重新计算用户a的集合，从而重新构建ABAC的条目；

(2)当与对应任务相关联的知识库发生变化时，需要重新计算项目p的集合，从而重新构建ABAC的条目；

(3)当与对应任务相关联的的知识库中内部的项目发生变化时，需要重新计算p集合，从而重新构建ABAC的条目。

由上可见，若采用显式授权的方式，需要ABAC高度绑定实体交互的各种事件以同步创建出所有授权条目，而这又导致授权条目对于这些变动十分敏感，显然，这种牵一发而动全身的设计并不合理，因为用户往往不会接受在将知识库授权给某个人或组织后，还要把其中装载的内容再挨个重复授权一遍。因此，从产品逻辑的角度来讲，使用隐式授权的方式进行权限继承是合理的，然而，发明人发现在其具体技术实现上存在不小的挑战：隐式授权下的权限继承方式，需要耗费很大的计算量。

具体地说，以权限管理***对(项目p，用户a)进行鉴权为例，对于显式授权，去数据库中直接查询是否存在对应的条目即可。对于隐式授权，如上文的例子(知识库A->知识库中的项目p->用户a)，其鉴权逻辑可以如下：

可见，在当前鉴权逻辑中存在一性能问题点(IO 1)，即根据项目P反查知识库A需要耗费较大的计算量，因为项目p可能被添加至任意知识库，反查全量结果需要占用较多的数据库计算资源(CPU和内存)以及数据传输所耗费的网络吞吐量。但由于这种情况下，业务场景比较简单，因此在实际应用中可以通过索引、缓存等方式进行优化。然而，真实业务场景会复杂得多，此处以在上述示例的基础上增加一层“课程”的层级关系来做举例，用以表明随着层级的增加，鉴权算法的复杂度会呈指数级上升。

具体地，假设当前的业务场景中新增一层“课程”实体的路径，课程T可以和知识库A相关联，课程T和知识库A也分别可以直接和项目p相关联，那么判断课程T的项目p是否可以授权给用户a，其鉴权逻辑可以如下：

可见，该算法包括以下3个策略：

1.用户被直接授权访问该项目；

2.该项目处于某个用户有权限访问的课程或知识库；

3.该项目处于某个知识库，这个知识库关联了某个用户有权限的课程；

该算法根据上面的策略依次做判断；上述算法中间比较复杂的部分是要先找到项目所在的所有课程和知识库，再去查询这些知识库关联的所有课程，进而才可以根据用户是否有列举出来的这些实体的权限来判断能否访问该项目。可见，加了一层路径后，IO请求量扩展了好几倍，还多了一个O(n2)复杂度的计算。即，在隐式授权中，随着路径层级的增加，鉴权逻辑的复杂度会呈几何倍数增加，这是因为权限管理***需要逐层遍历才能在ABAC的条目中找到符合要求的条目。不难看出，如果不对该方法进行优化，最差的情况就是IO(n^层级数)计算，并且伴随了大量的数据IO；此外，在该方法中，权限管理***会逐渐对业务产生深度的耦合，其动态计算非常依赖实体的交互逻辑，不利于后续的测试和维护迭代。

而且，本领域技术人员可以理解，无论是在权限管理***的鉴权层对继承权限的确定进行动态处理，还是在权限管理***的授权层对继承权限的确定进行动态处理，由于隐式授权中用户没有直接被授权访问某实体，是否拥有权限需要把有关联的父实体全部拉出来，判断用户是否具有其中某个父级实体的权限。由于实体之间的关联关系随时可能发生变动，所以这里是非常动态的鉴权算法而无法事先缓存，这导致权限管理***的处理的复杂度升高，其与业务逻辑细节的耦合程度也不理想。

基于此，本申请实施方式提供了一种基于ABAC的鉴权方法，通过在接收用户的请求信息后，根据目标授权规则对所述请求信息进行鉴权，得到鉴权结果，然后再根据所述鉴权结果，对所述请求信息放行或者拦截。其中，由于本申请实施例中的目标授权规则，是根据ABAC的默认授权条目结构的层级关系，对ABAC的默认授权条目结构进行扩展而得到的授权规则，本质上对层级关系作出了进一步的优化扩展，使得把相关技术中无法事先缓存的进行计算的权限转移到了ABAC中，构建了可以以较低的计算性能损耗来支持隐式权限继承的ABAC模型，因此，降低了权限管理***的计算复杂度，进而降低了耗费的计算量的开销，同时，还可以提升鉴权效率。

如图1所示，本申请实施方式提供的基于ABAC的鉴权方法可以包括如下步骤：

步骤S101，接收用户的请求信息。

步骤S102，根据目标授权规则对所述请求信息进行鉴权，得到鉴权结果。其中，所述目标授权规则为基于所述ABAC的默认授权条目的层级关系，进行条目扩展后得到的授权规则。

步骤S103，根据所述鉴权结果，对所述请求信息放行或者拦截。

可以参见2，其示出了相关技术的一些例子中的权限管理***的结构连接关系。权限管理***包括授权层和鉴权层，其中，在接收到用户的请求信息后，可以由授权层根据目标授权规则对所述请求信息进行鉴权，得到鉴权结果，并由鉴权层根据所述鉴权结果，对所述请求信息放行或者拦截，进而可以降低鉴权层的计算复杂度。

具体地说，在一些例子中，ABAC的默认授权条目的结构可以表示为(对象，资源，权限)，其含义为：给对象授予指定资源的指定操作权限的授权行为。之后，可以根据该默认授权条目的层级关系，对默认授权条目进行条目扩展，得到目标授权规则。这样，在接收到用户的请求信息后，可以根据该目标授权规则对所述请求信息进行鉴权，得到鉴权结果，进而根据所述鉴权结果，对所述请求信息放行或者拦截。

此处以(项目p，用户a)的鉴权场景为例，假设前置路径是(任务T，知识库A)，用户a拥有任务T的读权限(用户a，任务T，读权限read)。根据本申请实施例提供的方案，基于所述ABAC的的默认授权条目的层级关系，还可以进行如下扩展：(任务T，知识库A)、(知识库A，项目p)。于是可以得到进行条目扩展后的授权规则，即目标授权规则：(用户a，任务T->知识库A->项目p，读权限read)。在该例子中，假设得到的鉴权结果是通过，则对所述请求信息放行，使得用户具备对任务T的读权限；否则，在其他例子中，若得到的鉴权结果是不通过，则对所述请求信息拦截，使得用户不具备对任务T的读权限。

在实际应用中，所述目标授权规则的层级关系可以以层级图的形式来体现，比如层级图中的点和点之间的连线(边)代表两个实体之间的关系。可以理解，随着实际业务的扩展，会产生更多的实体关系，这样，通过本申请实施例提供的方法，层级图中各节点与授权主体可以在通过各种边建立连接关系，这样，当授权查询时，只需要映射新的关系所对应的数据结构的边即可。

此外，需要说明的是，本申请实施例提供的方案，可以拓展到任意内容协作平台等权限***较为复杂的场景。

不难发现，与相关技术相比，本申请实施例中，通过在接收用户的请求信息后，根据目标授权规则对所述请求信息进行鉴权，得到鉴权结果，然后再根据所述鉴权结果，对所述请求信息放行或者拦截。其中，由于本申请实施例中的目标授权规则，是根据ABAC的默认授权条目结构的层级关系，对ABAC的默认授权条目结构进行扩展而得到的授权规则，本质上对层级关系作出了进一步的优化扩展，使得把相关技术中无法事先缓存的进行计算的权限转移到了ABAC中，构建了可以以较低的计算性能损耗来支持隐式权限继承的ABAC模型，因此，降低了权限管理***的计算复杂度，进而降低了耗费的计算量的开销，同时，还可以提升鉴权效率。

在本申请一些实施例中，所述目标授权规则的生成方法可以包括：获取所述默认授权条目的层级关系；根据所述层级关系，确定所述默认授权条目的权限继承关系；根据所述权限继承关系，对所述默认授权条目进行条目扩展，以得到所述目标授权规则。

具体地说，假设项目p和任务T存在关联关系，项目p和知识库A存在关联关系，可以认为任务T和知识库A之间存在权限继承关系，则可以根据该任务T和知识库A之间存在的权限继承关系对所述默认授权条目进行扩展，以得到所述目标授权规则。

与相关技术相比，本申请实施例提供了具体如何根据ABAC的默认授权条目结构的层级关系来对ABAC的默认授权条目结构进行扩展的一种实现方式，有利于本申请实施例灵活多变的实现。

在本申请一些实施例中，所述根据所述权限继承关系，对所述默认授权条目进行条目扩展可以包括：根据所述权限继承关系，确定所述默认授权条目中资源的父资源和子资源；获取权限上限，所述权限上限用于表征所述权限继承关系中，可对所述资源执行的操作权限的上限；根据所述父资源、所述子资源以及所述权限上限，确定附加授权条目；根据所述附加授权条目，对所述默认授权条目进行条目扩展。

此处以一示例对权限上限进行解释说明。比如某一用户对某个父资源的所有的权限的集合是读操作和写操作，即意味着该用户对该资源可以读取评论，也可以发布评论。那么该用户对子资源的操作权限就不能超出上述权限的集合。比如，该用户对该资源所具有的权限仍然是读操作和写操作，不能执行超过这个权限的操作，比如该用户无法删除这个资源的子资源。

具体地说，在一些例子中，ABAC的默认授权条目的结构可以表示为(对象，资源，权限)，其含义为：给对象授予指定资源的指定操作权限的授权行为。在本申请实施例中，可以根据该默认授权条目的结构的层级关系进行条目扩展。比如说，确定的新的条目，其结构可以表示为：(父资源，子资源，权限上限)，其含义为：将子资源绑定至父资源的授权组，对子资源权限不超过指定的权限上界。可以理解，该新的授权条目在权限管理***内中可以起到层级图的边的作用，基于该新的数据结构，可以在条目表中构造出授权图以加速鉴权结果的计算。

综上，在上述示例中，ABAC的默认条目的结构是：对象-资源-权限，三者组成了一个授权，用于进行条目扩展的附加授权条目的结构是：父资源-子资源-权限上界。需要指出，本申请实施例具体扩展的是结构设计，具体生成哪些条目需要根据具体业务授权场景来确定，本申请实施例对此不作具体限定。

与相关技术相比，本申请实施例提供了具体根据所述权限继承关系，对所述默认授权条目进行条目扩展的一种实现方式，有利于本申请实施例灵活多变的实现。

在本申请一些实施例中，所述根据目标授权规则对所述请求信息进行鉴权，得到鉴权结果可以包括：根据所述层级关系，确定所述层级关系的层级数量；根据所述层级数量，确定对所述目标授权规则执行的数据查询方法；根据所述数据查询方法和所述目标授权规则，对所述请求信息进行鉴权，得到鉴权结果。

在一些例子中，对于类似于MongoDB的数据库而言，MongoDB在3.4版本后支持对于图进行计算的图计算功能，因此，可以进行表单内的图查询。比如，使用Aggragate的$graphLookup stage进行表单内的图查询。本领域技术人员可以理解，这里所说的图是抽象的图。

对于Mysql等关系型数据库，根据所述层级关系，确定所述层级关系的层级数量，当所述层级数量较少时(小于预设阈值时)，可以使用多次Left Join对所述目标授权规则执行数据查询。否则，当所述层级数量较多时(大于或者等于预设阈值时)可以使用动态递归查询的方式对所述目标授权规则执行数据查询，比如配合Neo4j等专业的图数据库对所述目标授权规则执行数据查询，这样，可以提升数据的查询性能。

与相关技术相比，本申请实施例提供的基于ABAC的鉴权方法，通过根据层级关系的数量，来对所述目标授权规则执行不同的数据查询方法，有利于进一步提升数据的查询性能。

在本申请一些实施例中，可以通过层级图表征所述目标授权规则的所述层级关系。关于该部分内容，在前述文中已提及，为避免重复，此处不再赘述。

在本申请一些实施例中，通过图数据库，通过图数据库对所述层级图进行管理，这样，可以进一步利用数据库引擎，有利于资源利用的最大化。

在本申请一些实施例中，在所述根据目标授权规则对所述请求信息进行鉴权，得到鉴权结果之后，所述方法还可以包括：若接收到更新信息，则根据所述更新信息，对所述目标授权规则进行更新。

具体地说，由于本申请实施例里中只保存了相邻节点之间的关系，即的层级关系是最简存储方式，因此当业务实体关系发生变化时，只需要同步删边或者砍树即可，从而与相关技术相比，可以避免大量的计算和更新，提高了计算效率。其中，所述的边可以理解为点与点之间的实体授权关系，所述的树是顶点以及所有它的下级关系，也就是一个实体的所有子资源的继承授权。

此外，在本申请一些实施例中，为了保证业务中实体关系发生变化时目标授权规则能够及时地、准确地同步更新，从而保证授权的准确性。在一些例子中，可以通过使用数据库事物，将业务逻辑和目标授权规则绑定在同一个事务中，以保证两边的数据的一致性；在一些其他例子中，还可以使用事件驱动的方式以保证两边的数据的一致性，具体可根据实际需求确定采用哪种方式，本申请实施例对此不作具体限定。

此外，在一些例子中，还可以采用周期性地轮询机制，定期将ABAC地授权表与业务数据对照的方式来检查目标授权规则，从而可以进一步保障目标授权规则的正确性。

综上所述，与相关技术相比，本申请实施方式提供了一种基于ABAC的鉴权方法，通过在接收用户的请求信息后，根据目标授权规则对所述请求信息进行鉴权，得到鉴权结果，然后再根据所述鉴权结果，对所述请求信息放行或者拦截。其中，由于本申请实施例中的目标授权规则，是根据ABAC的默认授权条目结构的层级关系，对ABAC的默认授权条目结构进行扩展而得到的授权规则，本质上对层级关系作出了进一步的优化扩展，使得把相关技术中无法事先缓存的进行计算的权限转移到了ABAC中，构建了可以以较低的计算性能损耗来支持隐式权限继承的ABAC模型，因此，降低了权限管理***的计算复杂度，进而降低了耗费的计算量的开销，同时，还可以提升鉴权效率。

为方便理解，此处以一实例对本申请实施例提供的方案进行说明。

具体地说，某平台以在线文档的创建、编辑、发布为核心，以组织为单位进行内部文档协作管理。该平台有以下功能特性：

-组织内有管理员和普通成员两种角色；

-普通成员对自己的文档有管理权限(查看、编辑、删除、管理协作者)；

-组织内的文档具有”协作者“概念，协作者为组织内其他成员。普通成员能够管理自己文档的协作者，能够指定协作者的权限(可查看/可编辑)；

-为了方便文档管理，管理员能够在组织内创建和管理“文件夹”；文件夹中可以添加组织内成员的文档，可以创建新的”子文件夹“，可以添加其它外部文件夹为子文件夹。文件夹允许有任意数量的层级；

-对于任意文件夹，管理员能够把组织成员添加至文件夹的协作者。协作者拥有该文件夹以及所有子文件夹内文档的阅读权限。

其中，若采用相关技术中的方案，原权限***的设计如下：

授权层：

由于组织内不仅存在”管理员“、”普通成员“的基本角色，对于文档资源还有较为动态的”创建者“和”协作者“等权限逻辑。在此场景下，若采用RBAC的方案会产生大量的细粒度角色需要维护，无法支持权限***的动态性。所以平台采用ABAC的方案进行常规权限和协作者授权条目管理。

当某位成员被添加至某个文档或文件夹的协作者时，创建相应ABAC条目<成员，文档/文件夹，权限>，存储该成员对于此资源的权限细节，其余“管理员”和“创建者”等权限通过ABAC在鉴权层做动态属性计算判断。

在文件夹协作场景下，由于文件夹可能有任意层级，也可以被添加任意文档。如果将文件夹协作者同里面的所有子文件夹、所有子文档也同步自动建立ABAC授权条目，在文件夹内容发生变动，尤其是根文件夹权限变动时，轻微的变动都会对授权条目产生极大影响而导致***难以维护。所以文件夹相关的权限采用继承式授权，需要在鉴权时动态进行计算和判断。

鉴权层：

在某位组织成员访问组织内某文档时，ABAC鉴权模块依次进行以下判断：

1.判断成员是否为管理员或文档创建者，授予相应权限；

2.判断成员对于该文档的权限是否在ABAC授权条目中存在；

3.进行文件夹鉴权：

(1)查询文档所属的所有文件夹，判断当前成员是否有其中某一文件夹的权限；

(2)依次递归查询这些文件夹的所有父级文件夹，直至找出所有顶层文件夹，判断当前成员是否有其中某一文件夹的权限。

原权限***的设计存在如下瓶颈：在实际业务环境中，由于文件夹通常有较多的层级，相关鉴权计算会产生大量的CPU和内存、数据库吞吐开销，影响用户体验。因此，需要使用本申请提出的方案对其进行优化。

可以结合图3所示，优化方法如下：

授权层：

采用图数据库对条目扩展后的ABAC授权条目进行文件夹层级权限管理：

-在文件夹A内创建或关联新的文件夹B时，创建<文件夹A,文件夹B,协作>授权条目(在图数据库中为关系边的形式)，表示拥有文件夹A协作权限的成员也被授予了文件夹B的协作权限；

-在文件夹A内添加新的文档C时，创建<文件夹A,文档C,查看>授权条目，表示拥有文件夹A协作权限的成员也被授予了文档C的查看权限

-当文件夹B或者文档C在文件夹A中被删除时，同步删除相应的授权条目

其中，该方案实现中需要保证授权条目与文件夹层级关系的一致性，有以下两种方案可做选择：

1.使用数据库事务(Transaction)：将ABAC的条目更新与文件夹内容的添加、删除数据操作声明在同一个事务中，以保证两边的数据一致性

2.使用事件驱动最终一致性：在文件夹内容变更时发布相应事件，权限管理***监听事件进行相应的ABAC授权条目更新。比如，可以使用支持“至少一次”特性(At-Least-Once)的消息队列中间件来确保事件成功发送和处理。

在此之外，还可以使用周期性轮询机制，定期将ABAC授权表与业务数据对照，检查授权图正确性，及时进行纠错。

鉴权层：

鉴权逻辑更新为以下流程，以组织成员U查看文档C为例：

1.判断成员U是否为管理员或文档C创建者，授予相应权限

2.ABAC授权条目鉴权

(1)假设成员U如果对文档C有权限，那么要么权限来源于C的协作者添加了U，要么来源于C的某个父级文件夹协作者添加了U，在授权条目表中会以<文件夹N,用户U,协作>,<文件夹N,文件夹N-1,协作>,...,<文件夹B,文件夹A,协作>,<文件夹A,文档C,查看>

(2)可以使用图数据库的索引能力，直接进行U与C的关系计算，若查询到关联则授权成功。

不难发现，使用采用本申请实施例提供的鉴权方法，无论文件夹与文档的层级有多深，鉴权流程均缩减为对数据库进行一次查询，显著提高了鉴权效率。并且，本申请实施例提供的鉴权方法的扩展性较强，对于后续业务***迭代有很高的适应性，能够支持各种复杂的隐式授权方案。

本申请实施例还提供了一种ABAC的鉴权装置，所述装置可以包括接收模块11、鉴权模块12和输出模块13，如图4所示：

所述接收模块11，用于接收用户的请求信息；

所述鉴权模块12，用于根据目标授权规则对所述请求信息进行鉴权，得到鉴权结果；所述目标授权规则为根据所述ABAC的默认授权条目的层级关系，进行条目扩展后得到的授权规则；

所述输出模块13，用于根据所述鉴权结果，对所述请求信息放行或者拦截。

不难发现，本申请实施例可以是与上述的ABAC的鉴权方法的实施例相对应的装置实施实例，上述的ABAC的鉴权方法的实施例的实现细节在本申请实施例同样适用，为避免重复，此处不再赘述。

此外，本申请实施例还提供了一种基于ABAC的鉴权设备，该设备的结构如图5所示，所述设备包括用于存储计算机可读指令的存储器21和用于执行计算机可读指令的处理器22，其中，当该计算机可读指令被该处理器执行时，触发所述处理器执行所述的基于ABAC的鉴权方法。

本申请实施例中的方法和/或实施例可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在该计算机程序被处理单元执行时，执行本申请的方法中限定的上述功能。

需要说明的是，本申请所述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。

而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言或其组合来编写用于执行本申请的操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图或框图示出了按照本申请各种实施例的设备、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的针对硬件的***来实现，或者可以用专用硬件与计算机指令的组合来实现。

作为另一方面，本申请实施例还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个计算机可读指令，所述计算机可读指令可被处理器执行以实现前述本申请的多个实施例的方法和/或技术方案的步骤。

在本申请一个典型的配置中，终端、服务网络的设备均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体，可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

此外，本申请实施例还提供了一种计算机程序，所述计算机程序存储于计算机设备，使得计算机设备执行所述控制代码执行的方法。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一些实施例中，本申请的软件程序可以通过处理器执行以实现上文步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (10)

1.一种基于ABAC的鉴权方法，其特征在于，所述方法包括：

接收用户的请求信息；

根据目标授权规则对所述请求信息进行鉴权，得到鉴权结果；所述目标授权规则为基于所述ABAC的默认授权条目的层级关系，进行条目扩展后得到的授权规则；

根据所述鉴权结果，对所述请求信息放行或者拦截。

2.根据权利要求1所述的方法，其特征在于，所述目标授权规则的生成方法包括：

获取所述默认授权条目的层级关系；

根据所述层级关系，确定所述默认授权条目的权限继承关系；

根据所述权限继承关系，对所述默认授权条目进行条目扩展，以得到所述目标授权规则。

3.根据权利要求2所述的方法，其特征在于，所述根据所述权限继承关系，对所述默认授权条目进行条目扩展包括：

根据所述权限继承关系，确定所述默认授权条目中资源的父资源和子资源；

获取权限上限，所述权限上限用于表征所述权限继承关系中，可对所述资源执行的操作权限的上限；

根据所述父资源、所述子资源以及所述权限上限，确定附加授权条目；

根据所述附加授权条目，对所述默认授权条目进行条目扩展。

4.根据权利要求1所述的方法，其特征在于，所述根据目标授权规则对所述请求信息进行鉴权，得到鉴权结果包括：

根据所述层级关系，确定所述层级关系的层级数量；

根据所述层级数量，确定对所述目标授权规则执行的数据查询方法；

根据所述数据查询方法和所述目标授权规则，对所述请求信息进行鉴权，得到鉴权结果。

5.根据权利要求1所述的方法，其特征在于，通过层级图表征所述目标授权规则的所述层级关系。

6.根据权利要求5所述的方法，其特征在于，通过图数据库对所述层级图进行管理。

7.根据权利要求1至6中任意一项所述的方法，其特征在于，在所述根据目标授权规则对所述请求信息进行鉴权，得到鉴权结果之后，所述方法还包括：

若接收到更新信息，则根据所述更新信息，对所述目标授权规则进行更新。

8.一种基于ABAC的鉴权装置，其特征在于，所述装置包括接收模块、鉴权模块和输出模块：

所述接收模块，用于接收用户的请求信息；

所述鉴权模块，用于根据目标授权规则对所述请求信息进行鉴权，得到鉴权结果；所述目标授权规则为根据所述ABAC的默认授权条目的层级关系，进行条目扩展后得到的授权规则；

所述输出模块，用于根据所述鉴权结果，对所述请求信息放行或者拦截。

9.一种基于ABAC的鉴权设备，其特征在于，所述设备包括：

一个或多个处理器；以及

存储有计算机程序指令的存储器，所述计算机程序指令在被执行时使所述处理器执行如权利要求1至7中任意一项所述的方法。

10.一种计算机可读介质，其上存储有计算机程序指令，所述计算机程序指令可被处理器执行以实现如权利要求1至7中所述的方法。

Images