CN111488595A - 用于实现权限控制的方法及相关设备 - Google Patents

Abstract

本公开实施例提供了一种用于实现权限控制的方法及相关设备。所述方法应用于准入网关，该方法包括：接收用户终端发送的应用访问请求；根据预先配置的路由访问信息和应用访问请求，确定访问控制单元的目标接口；调用访问控制单元的目标接口，将用户账号信息、目标资源信息和操作行为信息发送至访问控制单元；接收访问控制单元返回的应用权限识别结果，应用权限识别结果是目标接口根据用户账号信息、目标资源信息和操作行为信息匹配访问控制单元中的权限识别策略，根据权限识别策略生成的；根据应用权限识别结果，向用户终端返回针对应用访问请求的响应消息。本公开实施例提供的方案，涉及云安全技术，可以用于身份认证/验证。

Description

用于实现权限控制的方法及相关设备

技术领域

本公开涉及通信技术领域，具体而言，涉及一种用于实现权限控制的方法及装置、电子设备和计算机可读存储介质。

背景技术

企业内部管理中，权限管理是公认的难点。由于组织结构庞大、权限定义复杂、变动频繁等因素，权限的管理显得举步维艰。

因此，需要一种新的用于实现权限控制的方法及装置、电子设备和计算机可读存储介质。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解。

发明内容

本公开实施例提供一种用于实现权限控制的方法及装置、电子设备和计算机可读存储介质，通过准入网关，可以实现更加便捷、有效地访问权限控制。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

本公开实施例提供一种用于实现权限控制的方法，所述方法应用于准入网关；其中，所述方法包括：接收用户终端发送的应用访问请求，所述应用访问请求有携带用户账号信息、待访问的目标资源信息及所述目标资源信息对应的操作行为信息；根据预先配置的路由访问信息和所述应用访问请求，确定访问控制单元的目标接口；调用所述访问控制单元的目标接口，将所述用户账号信息、所述目标资源信息和所述操作行为信息发送至所述访问控制单元；接收所述访问控制单元返回的应用权限识别结果，所述应用权限识别结果是所述目标接口根据所述用户账号信息、所述目标资源信息和所述操作行为信息匹配所述访问控制单元中的权限识别策略，根据所述权限识别策略生成的；根据所述应用权限识别结果，向所述用户终端返回针对所述应用访问请求的响应消息。

本公开实施例提供一种用于实现权限控制的方法，所述方法应用于用于实现权限控制的系统，所述系统包括准入网关和访问控制单元；其中，所述方法包括：所述准入网关接收用户终端发送的应用访问请求，所述应用访问请求携带有用户账号信息、待访问的目标资源信息及所述目标资源信息对应的操作行为信息；所述准入网关根据预先配置的路由访问信息和所述应用访问请求，确定所述访问控制单元的目标接口；所述准入网关调用所述访问控制单元的目标接口，向所述访问控制单元发送所述用户账号信息、所述目标资源信息和所述操作行为信息；所述访问控制单元接收所述用户账号信息、所述目标资源信息和所述操作行为信息，并根据所述用户账号信息、所述目标资源信息和所述操作行为信息匹配所述访问控制单元中的权限识别策略，根据所述权限识别策略生成并向所述准入网关发送应用权限识别结果；所述准入网关根据接收的所述应用权限识别结果，向所述用户终端返回针对所述应用访问请求的响应消息。

本公开实施例提供一种准入网关，包括：访问请求接收单元，用于接收用户终端发送的应用访问请求，所述应用访问请求携带有用户账号信息、待访问的目标资源信息及所述目标资源信息对应的操作行为信息；目标接口确定单元，用于根据预先配置的路由访问信息和所述应用访问请求，确定访问控制单元的目标接口；权限检查请求单元，用于调用所述访问控制单元的目标接口，将所述用户账号信息、所述目标资源信息和所述操作行为信息发送至所述访问控制单元；权限结果接收单元，用于接收所述访问控制单元返回的应用权限识别结果，所述应用权限识别结果是所述目标接口根据所述用户账号信息、所述目标资源信息和所述操作行为信息匹配所述访问控制单元中的权限识别策略，根据所述权限识别策略生成的；响应消息返回单元，用于根据所述应用权限识别结果，向所述用户终端返回针对所述应用访问请求的响应消息。

本公开实施例提供一种用于实现权限控制的系统，所述系统包括准入网关和访问控制单元；其中，所述准入网关用于接收用户终端发送的应用访问请求，所述应用访问请求携带有用户账号信息、待访问的目标资源信息及所述目标资源信息对应的操作行为信息；根据预先配置的路由访问信息和所述应用访问请求，确定所述访问控制单元的目标接口；调用所述访问控制单元的目标接口，向所述访问控制单元发送所述用户账号信息、所述目标资源信息和所述操作行为信息；所述访问控制单元用于接收所述用户账号信息、所述目标资源信息和所述操作行为信息，并根据所述用户账号信息、所述目标资源信息和所述操作行为信息匹配所述访问控制单元中的权限识别策略，根据所述权限识别策略生成并向所述准入网关发送应用权限识别结果；所述准入网关还用于根据接收的所述应用权限识别结果，向所述用户终端返回针对所述应用访问请求的响应消息。

本公开实施例提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现如上述实施例中所述的用于实现权限控制的方法。

本公开实施例提供了一种电子设备，包括：一个或多个处理器；存储装置，配置为存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上述实施例中所述的用于实现权限控制的方法。

在本公开的一些实施例所提供的技术方案中，通过在访问控制(例如，基于角色的访问控制)单元和目标业务应用之间添加一层准入网关，减少了访问控制单元和目标业务应用之间的耦合性，降低了对访问控制单元和目标业务应用的技术栈的约束，使得对于目标业务应用来说，访问控制单元是透明的，降低了对目标业务应用的代码侵入性。此外，当目标业务应用的权限发生变更时，只需要变动准入网关上部署的路由访问信息，不需要修改目标业务应用代码，便于维护。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1示出了可以应用本公开实施例的数据资源处理方法或数据资源处理装置的示例性系统架构的示意图；

图2示出了适于用来实现本公开实施例的电子设备的计算机系统的结构示意图；

图3示意性示出了根据本公开的一实施例的用于实现权限控制的方法的流程图；

图4示意性示出了根据本公开的一实施例的用于实现权限控制的方法的流程图；

图5示意性示出了根据本公开的一实施例的基于API网关实现RBAC权限控制的工作原理示意图；

图6示意性示出了根据本公开的一实施例的功能权限的示意图；

图7示意性示出了根据本公开的一实施例的数据权限的示意图；

图8示意性示出了根据本公开的一实施例的角色管理的用户界面示意图；

图9示意性示出了根据本公开的一实施例的创建角色的用户界面示意图；

图10示意性示出了根据本公开的一实施例的编辑角色的用户界面示意图；

图11示意性示出了根据本公开的一实施例的权限策略管理的用户界面示意图；

图12示意性示出了根据本公开的一实施例的创建权限策略的用户界面示意图；

图13示意性示出了根据本公开的一实施例的管理权限策略的用户界面示意图；

图14示意性示出了根据本公开的一实施例的角色权限管理的用户界面示意图；

图15示意性示出了根据本公开的一实施例的添加角色权限的用户界面示意图；

图16示意性示出了根据本公开的一实施例的角色成员管理的用户界面示意图；

图17示意性示出了根据本公开的一实施例的添加角色成员的用户界面示意图；

图18示意性示出了根据本公开的一实施例的策略中不含限制条件的权限判断逻辑的流程示意图；

图19示意性示出了根据本公开的一实施例的策略中包含限制条件的权限判断逻辑的流程示意图；

图20示意性示出了根据本公开的一实施例的数据范围计算逻辑的流程示意图；

图21示意性示出了根据本公开的一实施例的业务系统/模块通过3A认证进行权限及授权控制的示意图；

图22示意性示出了根据本公开的一实施例的基于准入网关集成3A访问控制服务模式的工作原理示意图；

图23示意性示出了根据本公开的一实施例的权限模型解决的问题的示意图；

图24示意性示出了根据本公开的一实施例的判断访问者是否有权限(无限制条件)的示意图；

图25示意性示出了根据本公开的一实施例的判断访问者是否有权限(有限制条件)的示意图；

图26示意性示出了根据本公开的一实施例的判断访问者是否有权限(有限制条件)的示意图；

图27示意性示出了根据本公开的一实施例的准入网关的框图；

图28示意性示出了根据本公开的一实施例的用于实现权限控制的系统的框图。

具体实施方式

现在将参考附图更全面地描述示例实施例。然而，示例实施例能够以多种形式实施，且不应被理解为限于在此阐述的实施例；相反，提供这些实施例使得本公开将全面和完整，并将示例实施例的构思全面地传达给本领域的技术人员。在图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

本公开所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本公开的各方面。

附图仅为本公开的示意性图解，图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和步骤，也不是必须按所描述的顺序执行。例如，有的步骤还可以分解，而有的步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

本说明书中，用语“一个”、“一”、“该”、“所述”和“至少一个”用以表示存在一个或多个要素/组成部分/等；用语“包含”、“包括”和“具有”用以表示开放式的包括在内的意思并且是指除了列出的要素/组成部分/等之外还可存在另外的要素/组成部分/等；用语“第一”、“第二”和“第三”等仅作为标记使用，不是对其对象的数量限制。

下面结合附图对本公开示例实施方式进行详细说明。

图1示出了可以应用于本公开实施例的漏洞检测方法或漏洞检测装置的示例性系统架构的示意图。

如图1所示，系统架构100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

服务器105可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。终端设备101、102、103可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端设备101、102、103以及服务器105可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

服务器105可例如接收终端设备101(也可以是终端设备102、103)发送的应用访问请求，所述应用访问请求携带有用户账号信息、待访问的目标资源信息及所述目标资源信息对应的操作行为信息；根据预先配置的路由访问信息和所述应用访问请求，确定访问控制单元的目标接口；调用所述访问控制单元的目标接口，将所述用户账号信息、所述目标资源信息和所述操作行为信息发送至所述访问控制单元；接收所述访问控制单元返回的应用权限识别结果，所述应用权限识别结果是所述目标接口根据所述用户账号信息、所述目标资源信息和所述操作行为信息匹配所述访问控制单元中的权限识别策略，根据所述权限识别策略生成的；根据所述应用权限识别结果，向终端设备101返回针对所述应用访问请求的响应消息。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的，服务器105可以是一个实体的服务器，还可以为多个服务器组成，根据实际需要，可以具有任意数目的终端设备、网络和服务器。

下面参考图2，其示出了适于用来实现本申请实施例的终端设备的计算机系统200的结构示意图。图2示出的终端设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图2所示，计算机系统200包括中央处理单元(CPU)201，其可以根据存储在只读存储器(ROM)202中的程序或者从储存部分208加载到随机访问存储器(RAM)203中的程序而执行各种适当的动作和处理。在RAM 203中，还存储有系统200操作所需的各种程序和数据。CPU 201、ROM 202以及RAM 203通过总线204彼此相连。输入/输出(I/O)接口205也连接至总线204。

以下部件连接至I/O接口205：包括键盘、鼠标等的输入部分206；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分207；包括硬盘等的储存部分208；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分209。通信部分209经由诸如因特网的网络执行通信处理。驱动器210也根据需要连接至I/O接口205。可拆卸介质211，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器210上，以便于从其上读出的计算机程序根据需要被安装入储存部分208。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分209从网络上被下载和安装，和/或从可拆卸介质211被安装。在该计算机程序被中央处理单元(CPU)201执行时，执行本申请的系统中限定的上述功能。

需要说明的是，本申请所示的计算机可读存储介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读存储介质，该计算机可读存储介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读存储介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

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

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元也可以设置在处理器中，例如，可以描述为：一种处理器包括发送单元、获取单元、确定单元和第一处理单元。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

作为另一方面，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备可实现功能包括：接收用户终端发送的应用访问请求，所述应用访问请求携带有用户账号信息、待访问的目标资源信息及所述目标资源信息对应的操作行为信息；根据预先配置的路由访问信息和所述应用访问请求，确定访问控制单元的目标接口；调用所述访问控制单元的目标接口，将所述用户账号信息、所述目标资源信息和所述操作行为信息发送至所述访问控制单元；接收所述访问控制单元返回的应用权限识别结果，所述应用权限识别结果是所述目标接口根据所述用户账号信息、所述目标资源信息和所述操作行为信息匹配所述访问控制单元中的权限识别策略，根据所述权限识别策略生成的；根据所述应用权限识别结果，向所述用户终端返回针对所述应用访问请求的响应消息。

需要理解的是，在本公开附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。

首先对本公开实施例中涉及的部分术语进行定义说明。

管理后台/管理平台/认证系统/用于实现权限控制的系统：是为客户/用户提供统一的用户身份及认证管理、业务应用管理(含注册、接入、发布、授权等)的平台，在符合安全网络管控要求下，融合业务应用/服务供给和访问控制，对用户/身份管理、权限管理、微服务框架、容器承载平台进行适配，提供一体化的业务/应用支撑统管和融合平台。

3A：认证系统中集账号(Account)管理、鉴权(Authentication)管理、授权(Authorization)管理于一体的基础服务和安全解决方案。

RBAC(Role Based Access Control)：基于角色的访问控制。在下面的实施例中，3A中集成了访问控制单元，均以访问控制单元中包括RBAC权限模型为例进行举例说明，但本公开并不限定于此。

API(Application Programming Interface，应用程序编程接口)网关：又称准入网关，是为业务应用提供API托管的服务，同时可以支持权限管理、流量监控等。

ACL(Access Control Lists)：访问控制列表ACL是一种基于包过滤的访问控制技术，它可以根据设定的条件对接口上的数据包进行过滤，允许其通过或丢弃。

云技术(Cloud technology)是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。

云技术基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。

云安全(Cloud Security)是指基于云计算商业模式应用的安全软件、硬件、用户、机构、安全云平台的总称。云安全融合了并行处理、网格计算、未知病毒行为判断等新兴技术和概念，通过网状的大量客户端对网络中软件行为的异常监测，获取互联网中木马、恶意程序的最新信息，并发送到服务端进行自动分析和处理，再把病毒和木马的解决方案分发到每一个客户端。

云安全主要研究方向包括：1.云计算安全，主要研究如何保障云自身及云上各种应用的安全，包括云计算机系统安全、用户数据的安全存储与隔离、用户接入认证、信息传输安全、网络攻击防护、合规审计等；2.安全基础设施的云化，主要研究如何采用云计算新建与整合安全基础设施资源，优化安全防护机制，包括通过云计算技术构建超大规模安全事件、信息采集与处理平台，实现对海量信息的采集与关联分析，提升全网安全事件把控能力及风险控制能力；3.云安全服务，主要研究各种基于云计算平台为用户提供的安全服务，如防病毒服务等。

RBAC模型是相关技术中解决大型企业权限管理问题的方法。RBAC的基本思想是：对系统操作的各种权限不是直接授予具体的用户，而是在用户集合与权限集合之间建立一个角色集合。将权限分配给角色，而不是用户，每一种角色对应一组相应的权限。再根据用户的职责赋予一定的角色，用户根据所属的角色获得相应的权限。一旦用户被分配了适当的角色后，该用户就拥有此角色的所有操作权限。

基于角色的访问控制不必在每次创建用户时都进行分配权限的操作，只要分配用户相应的角色即可，而且角色的权限变更比用户的权限变更要少得多，这样将简化用户的权限管理，能减少授权管理的复杂性，降低管理和系统的开销，灵活地支持企业的安全策略，对企业的变化有很大的适应性。

然而RBAC在使用过程中，仍然面临着以下技术问题：

1.访问控制单元提供的权限控制服务与业务应用的代码耦合度高，其实现方式依赖业务应用所使用的技术栈，对双方所使用的技术栈有一定的约束性，对业务代码有一定的侵入性。

2.当业务应用的权限变更频率增高时，也需要频繁地修改业务应用的代码，开发维护的成本高。

基于上述相关技术中存在的技术问题，本公开实施例提出了一种用于实现权限控制的方法，以用于至少部分解决上述问题。图3示意性示出了根据本公开的一实施例的用于实现权限控制的方法的流程图。图3实施例中，所述方法可以应用于准入网关。

如图3所示，本公开实施例提供的方法可以包括以下步骤。

在步骤S310中，接收用户终端发送的应用访问请求，所述应用访问请求携带有用户账号信息、待访问的目标资源信息及所述目标资源信息对应的操作行为信息。

本公开实施例中，用户终端可以是当前准备要访问目标业务应用的任意一个或者多个用户/访问者所使用的终端设备。用户/访问者通过该用户终端向API网关发送希望访问目标业务应用的应用访问请求，该应用访问请求中会携带有用户/访问者的用户账号信息(例如用户名、真实姓名、手机号、身份证号、员工编号等中的任意一个或者多个，只要能够唯一标识该用户/访问者的身份即可)，该用户账号信息(account)可以采用任何标识符来表示，例如name、accountid等，本公开对此不做限定。该应用访问请求中还携带有该用户/访问者当前想要访问该目标业务应用的何种资源(resource)即目标资源信息是什么，以及想对该目标资源进行何种操作，即操作行为信息(action)是什么，由此可以判断该用户/访问者是否具有访问该目标资源的权限，以及是否具有对该目标资源进行该操作的权限。

在步骤S320中，根据预先配置的路由访问信息和所述应用访问请求，确定访问控制单元的目标接口。

本公开实施例中，可以在准入网关中配置路由访问信息(routeRule)，该路由访问信息中包括ACL，可以利用该应用访问请求的resource和action去匹配准入网关中的routeRule，当该应用访问请求的resource和action与某条routeRule中的resource和action匹配中了以后，可以根据该匹配的routeRule中的类型(type)信息，确定准入网关当前调用访问控制单元的哪个接口(即目标接口)来进行权限(right)检查(check)。

在下面的举例说明中，均以访问控制单元中设置了RBAC权限模型为例进行举例说明，但本公开并不限定于此，该访问控制单元可以是3A的一部分，其中包括策略计算模块，可以接收准入网关发送的权限检查请求，检查该应用访问请求是否具有访问权限。

在步骤S330中，调用所述访问控制单元的目标接口，将所述用户账号信息、所述目标资源信息和所述操作行为信息发送至所述访问控制单元。

在示例性实施例中，所述目标接口可以为权限翻译(translate)接口，下述应用权限识别结果可以包括目标数据范围信息。本公开实施例中，目标数据范围信息中限定了该用户/访问者具有访问权限的数据范围。

在示例性实施例中，所述方法还可以包括：根据所述预先配置的路由访问信息和所述应用访问请求，确定指定数据库类型信息。

本公开实施例中，从准入网关中匹配的routeRule的type信息中可以包括指定数据库类型信息，该指定数据库类型信息限定了该用户/访问者当前可以查询的数据库(database，DB)类型。

在示例性实施例中，调用所述访问控制单元的目标接口，将所述用户账号信息、所述目标资源信息和所述操作行为信息发送至所述访问控制单元，可以包括：调用所述访问控制单元的所述指定数据库类型信息对应的权限翻译接口，将所述用户账号信息、所述目标资源信息和所述操作行为信息发送至所述访问控制单元。

在步骤S340中，接收所述访问控制单元返回的应用权限识别结果，所述应用权限识别结果是所述目标接口根据所述用户账号信息、所述目标资源信息和所述操作行为信息匹配所述访问控制单元中的权限识别策略，根据所述权限识别策略生成的。

在步骤S350中，根据所述应用权限识别结果，向所述用户终端返回针对所述应用访问请求的响应消息。

在示例性实施例中，所述目标接口可以为权限检查接口，所述应用权限识别结果可以包括目标权限判断结果。

在示例性实施例中，根据所述应用权限识别结果，向所述用户终端返回针对所述应用访问请求的响应消息，可以包括：若所述目标权限判断结果为有权限，则将所述应用访问请求转发至目标业务应用；接收所述目标业务应用对所述目标资源信息执行与所述操作行为信息对应的操作行为生成的业务执行结果；将所述业务执行结果作为所述响应消息返回至所述用户终端。

在示例性实施例中，根据所述应用权限识别结果，向所述用户终端返回针对所述应用访问请求的响应消息，还可以包括：若所述目标权限判断结果为无权限，则向所述用户终端返回拒绝访问消息，以作为所述响应消息。

在示例性实施例中，根据所述应用权限识别结果，向所述用户终端返回针对所述应用访问请求的响应消息，可以包括：根据所述目标数据范围信息生成数据库过滤器(DBfilter)；根据所述数据库过滤器过滤所述指定数据库类型信息对应的指定数据库中的数据，获得目标数据；将所述目标数据作为所述响应消息返回至所述用户终端。

本公开实施方式提供的用于实现权限控制的方法，通过在访问控制(例如，基于角色的访问控制)单元和目标业务应用之间添加一层准入网关，减少了访问控制单元和目标业务应用之间的耦合性，降低了对访问控制单元和目标业务应用的技术栈的约束，使得对于目标业务应用来说，访问控制单元是透明的，降低了对目标业务应用的代码侵入性。此外，当目标业务应用的权限发生变更时，只需要变动准入网关上部署的路由访问信息，不需要修改目标业务应用代码，便于维护。

图4示意性示出了根据本公开的一实施例的用于实现权限控制的方法的流程图。图4实施例提供的方法可以应用于用于实现权限控制的系统(以下简称为认证系统)，所述系统包括可以准入网关和访问控制单元。

如图4所示，本公开实施例提供的方法可以包括以下步骤。

在步骤S410中，所述准入网关接收用户终端发送的应用访问请求，所述应用访问请求携带有用户账号信息、待访问的目标资源信息及所述目标资源信息对应的操作行为信息。

在步骤S420中，所述准入网关根据预先配置的路由访问信息和所述应用访问请求，确定所述访问控制单元的目标接口。

在步骤S430中，所述准入网关调用所述访问控制单元的目标接口，向所述访问控制单元发送所述用户账号信息、所述目标资源信息和所述操作行为信息。

在步骤S440中，所述访问控制单元接收所述用户账号信息、所述目标资源信息和所述操作行为信息，并根据所述用户账号信息、所述目标资源信息和所述操作行为信息匹配所述访问控制单元中的权限识别策略，根据所述权限识别策略生成并向所述准入网关发送应用权限识别结果。

在示例性实施例中，根据所述用户账号信息、所述目标资源信息和所述操作行为信息匹配所述访问控制单元中的权限识别策略，可以包括：若根据所述用户账号信息、所述目标资源信息和所述操作行为信息，匹配多条权限识别策略，且至少部分权限识别策略中包括限制条件信息，则所述至少部分权限识别策略中的限制条件信息之间是相互与关系。

在示例性实施例中，根据所述用户账号信息、所述目标资源信息和所述操作行为信息匹配所述访问控制单元中的权限识别策略，根据所述权限识别策略生成并向所述准入网关发送应用权限识别结果，可以包括：若根据所述用户账号信息、所述目标资源信息和所述操作行为信息，匹配多条权限识别策略，且所述多条权限识别策略中存在至少一条权限识别策略的效力为拒绝，则生成的所述应用权限识别结果为无权限。

在步骤S450中，所述准入网关根据接收的所述应用权限识别结果，向所述用户终端返回针对所述应用访问请求的响应消息。

在示例性实施例中，所述系统还可以包括管理终端，所述方法还可以包括：在所述管理终端上显示角色管理界面，所述角色管理界面包括创建角色控件；响应于对所述创建角色控件的操作，在所述管理终端上显示创建角色界面，所述创建角色界面包括角色编码控件和角色名称控件；响应于对所述角色编码控件和所述角色名称控件的操作，创建角色。

在示例性实施例中，所述方法还可以包括：在所述管理终端上显示权限策略管理界面，所述权限策略管理界面包括新增权限策略控件；响应于对所述新增权限策略控件的操作，在所述管理终端上显示新增权限策略界面，所述新增权限策略界面包括权限策略编码控件、权限策略名称控件、资源与行为添加控件和效力选择控件；响应于对所述权限策略编码控件、所述权限策略名称控件、所述资源与行为添加控件和所述效力选择控件的操作，创建权限识别策略。

在示例性实施例中，所述角色管理界面还包括角色权限管理控件；其中，所述方法还可以包括：响应于对所述角色权限管理控件的操作，在所述管理终端上显示对应角色的角色权限管理界面，所述角色权限管理界面包括添加角色权限控件；响应于对所述添加角色权限控件的操作，在所述管理终端上显示添加角色权限界面，所述添加角色权限界面包括权限策略选择控件；响应于对所述权限策略选择控件的操作，为对应角色赋予权限识别策略。

在示例性实施例中，所述角色管理界面还包括角色成员管理控件；其中，所述方法还可以包括：响应于对所述角色成员管理控件的操作，在所述管理终端上显示角色成员管理界面，所述角色成员管理界面包括添加角色成员控件；响应于对所述添加角色成员控件的操作，在所述管理终端上显示对应角色的添加角色成员界面，所述添加角色成员界面包括角色成员选择控件；响应于对所述角色成员选择控件的操作，为对应角色添加角色成员。

下面均以RBAC权限模型为例，对上述实施例提供的方法进行举例说明。本公开实施例提供的方法，是在RBAC模型的基础上，引入API网关，形成基于API网关实现RBAC权限控制的解决方案，解决RBAC模型本身的缺陷。

图5示意性示出了根据本公开的一实施例的基于API网关实现RBAC权限控制的工作原理示意图。

如图5所示，本公开实施例提供的方法的工作原理如下：目标业务应用将API发布在API网关上。

在步骤1中，当当前用户想要访问目标业务应用时，该当前用户向API网关发送应用访问请求。

在步骤2中，API网关接收到该当前用户的应用访问请求后，可以从该应用访问请求中获取到该当前用户的账号(account)、该当前用户想要访问的目标资源(resource)及操作行为(action)等信息，然后API网关向RBAC发送权限(right)检查(check)请求，请求进行权限检查。

在步骤3中，RBAC接收到API网管的权限检查请求后，进行策略计算，生成权限计算/判断结果。

在步骤4中，RBAC将权限计算/判断结果返回给API网关。

在步骤5a中，API网关接收到权限计算/判断结果后，若结果是无权限(false)访问，则API网关将向该当前用户发送拒绝访问消息，直接拒绝该当前用户的访问。

在步骤5b中，若结果是有权限(true)访问，API网关会将该当前用户的应用访问请求转发给目标业务应用，让目标业务应用执行业务逻辑。

本公开实施例中，权限可以包括功能权限和数据权限。功能权限指用户登录系统后能看到什么模块/页面，而数据权限指的是用户在某个模块/页面里能看到多少条数据以及哪些数据。在企业系统中，通过配置用户的功能权限可以解决不同的人分管不同业务的需求。数据权限一般和企业的组织架构相关。用户具有的权限是功能权限和数据权限交叉定义的。

图6示意性示出了根据本公开的一实施例的功能权限的示意图。

如图6所示，判断用户是否具有功能权限的过程包括以下步骤。

当用户访问目标业务应用时，经过准入网关，即向准入网关发送应用访问请求。图6中以两个用户即用户A和用户B为例进行举例说明，用户A和用户B分别向准入网关发起应用访问请求。

准入网关分别接收到用户A和用户B的应用访问请求后，准入网关的权限计算模块根据管理后台提供的路由访问信息生成ACL，向3A请求权限检查，分别验证用户A和用户B是否具有访问权限。

3A收到准入网关发送的权限检查请求后，其策略计算模块根据管理后台配置的权限识别策略(或者权限策略)进行权限计算，分别生成用户A和用户B的权限计算结果/判断结果。

然后，3A分别将用户A和用户B的权限计算/判断结果返回准入网关的权限计算模块，权限计算/判断结果包括了是否允许用户A和用户B访问目标业务应用的结果，例如若结果为true，则表示允许访问，若结果为false，则表示不允许访问。

准入网关接收到3A返回的权限计算/判断结果后，准入网关的权限计算模块根据权限计算/判断结果进行权限计算：

1)若权限计算/判断结果为无权限(false)，则准入网关直接拒绝用户访问。例如这里假设针对用户B的应用访问请求返回的结果是false，则准入网关的权限计算模块直接向用户B返回拒绝其访问的消息。

2)若权限计算/判断结果为有权限(true)，则准入网关通过其路由转发模块将用户的应用访问请求转发至目标业务应用的内部服务。

图7示意性示出了根据本公开的一实施例的数据权限的示意图。

如图7所示，判断用户的数据权限的过程包括以下步骤。

当用户访问目标业务应用时，经过准入网关，即向准入网关发送应用访问请求。图7中还是以两个用户即用户A和用户B为例进行举例说明，用户A和用户B分别向准入网关发起应用访问请求。

准入网关分别接收到用户A和用户B的应用访问请求后，准入网关的权限计算模块根据管理后台提供的ACL规则生成ACL，向3A请求权限检查，并在向3A请求权限检查时，在权限检查请求中添加指定数据库类型等信息。

3A收到准入网关发送的权限检查请求后，根据管理后台配置的权限识别策略进行策略计算，获得权限计算结果，此时的权限计算结果包括数据过滤表达式/权限表达式(即上述目标数据范围信息)。

3A将包括数据过滤表达式的权限计算结果返回准入网关。

准入网关根据数据过滤表达式/权限表达式生成数据库过滤器，并通过路由转发到具体的目标业务应用的内部服务。

目标业务应用的内部服务将数据库过滤器转发到与指定数据库类型对应的数据库，该数据库返回经权限过滤的数据结果及目标数据给准入网关。

准入网关将经权限筛选过后的数据结果返回到用户/访问者。这里假设给用户A返回A数据，给用户B返回的是B数据。

下面对管理后台所具有的基本能力进行介绍。

首先介绍角色。“角色”是RBAC模型的核心。根据管理中相对稳定的职权和责任划分不同的角色，每种角色可以完成一定的职能/功能。例如：机构管理员、机构负责人、机构成员等。

本公开实施例中，可以在管理后台对应的管理门户(显示于管理终端上)上管理角色。

图8示意性示出了根据本公开的一实施例的角色管理的用户界面示意图。如图8所示，管理门户的用户界面上包括角色及权限策略管理，角色及权限策略管理中可以包括角色管理和权限策略管理。当选择“角色管理”后，可以看到“创建角色”控件，点击图8上的“创建角色”控件，可以进入图9所示的创建角色的用户界面示意图。

如图9所示，支持创建角色，创建角色时需要确定以下属性：角色编码，这里设置为必填，且设置为只能由英文大小写字母、数字和任意符号组成，全平台唯一即(同业务应用(例如APP(application，应用程序)内)不可重复，且可以设置为不区分大小写；角色名称，这里设置为必填；角色描述，这里设置为选填，且可以规定限制在200个字以内(但并不限定于此，可以根据实际场景进行设置)。

本公开实施例还支持编辑角色。例如，点击图8的角色管理用户界面上，“供应商管理员1”操作下的“编辑”控件，则可以进入图10所示的编辑角色的用户界面示意图。如图10所示，可以编辑角色名称、角色描述，编辑过程中需要遵守的要求同图9实施例中创建角色的要求。

下面介绍权限策略(Policy)。权限策略是用语法结构所描述的一组权限，它可以精确地描述被授权的资源集、行为集以及授权条件。通过给角色附加权限策略，角色中的所有用户就能获得权限策略中指定的访问权限。本公开实施例中，当权限策略中既有Allow(允许)又有Deny(拒绝)的授权语句时，遵循Deny优先的原则。

下面对Policy基本元素进行介绍。Policy基本元素是权限策略的基本组成部分，通过Policy基本元素的基本知识可以更合理的使用权限策略。如下表1所示，权限策略可以包含以下基本元素：

表1权限策略的基本元素

本公开实施例中，可以在管理后台的管理门户上管理权限策略。

图11示意性示出了根据本公开的一实施例的权限策略管理的用户界面示意图。本公开实施例中支持创建权限策略。如图11所示，权限策略管理用户界面上包括“新增权限策略”控件，点击该“新增权限策略”控件，可以进入图12所示的创建权限策略的用户界面示意图。在新增权限策略时，需要确定以下属性：权限策略编码，这里设置为必填，且设置为只能由英文大小写字母、数字和任意符号组成，全平台唯一即(同业务应用(例如APP内)不可重复，且可以设置为不区分大小写；权限策略名称，这里设置为必填；权限策略描述，这里设置为选填，且可以规定限制在200个字以内(但并不限定于此，可以根据实际场景进行设置)；资源与行为，这里设置为必填，可以通过其右侧对应的“添加”控件进行资源与行为的添加；效力，这里设置为必填，可以选择“允许”或者“拒绝”。可选的，还可以添加限制条件/条件(Condition)，例如可以添加以下条件：

本公开实施例还支持编辑权限策略。例如，点击图11所示权限策略管理用户界面上的权限策略“xxx”的操作下的“管理”控件，可以进入图13所示的管理权限策略的用户界面示意图。如图13所示，管理权限策略用户界面上包括“编辑权限策略”控件，点击该控件可以对“xxx”权限策略进行编辑。

本公开实施例中，还可以支持删除权限策略。继续参考图13，还包括“删除权限策略”控件，若点击该控件则可以删除“xxx”权限策略。

下面对授权进行介绍。“授权”是指将一个或多个权限策略添加到权限策略的主体(角色或用户)的过程。本公开实施例中，可以在管理后台的管理门户上对角色进行授权管理。

本公开实施例中，支持为角色赋予权限策略。例如，点击图8的创建角色用户界面上的角色“供应商管理员1”的操作下的“角色权限管理”控件，则可以进入图14所示的角色权限管理的用户界面示意图。如图14所示，角色权限管理用户界面上包括“添加角色权限”控件，点击该控件可以进入图15所示的添加角色权限的用户界面示意图，可以在此界面上为角色“供应商管理员1”选择相应的权限策略。

本公开实施例中，还可以支持将角色与权限策略解除关联。例如，如图14所示，在角色权限管理用户界面上，在该角色信息对应的角色权限列表中，每个权限策略后面对应有操作“移除”控件，通过点击该控件可以将相应的权限策略与该角色之间解除关联。

本公开实施例中，还支持为角色添加成员。为角色添加成员是将角色指派对象(用户、角色)的过程。角色成员可以是用户，也可以是角色，形成角色的嵌套。下面以为角色添加用户为例进行举例说明。

本公开实施例中，可以在管理后台的管理门户上管理角色成员。

本公开实施例中，支持为角色添加成员。例如，点击图8的创建角色用户界面上的角色“供应商管理员1”的操作下的“角色成员管理”控件，则可以进入图16示意性示出了根据本公开的一实施例的角色成员管理的用户界面示意图。图16用户界面上包括“添加角色成员”的控件，点击该控件可以进入图17所示的添加角色成员的用户界面示意图，可以在图17用户界面上为角色“供应商管理员1”添加角色成员。

本公开实施例中，还可以支持将成员从角色中移除。例如，如图16所示，在该角色信息对应的角色成员列表中，角色成员对应的操作包括“移除”控件，点击该控件，则可以将该角色成员从该角色中移除。

下面对权限计算/判断过程进行说明。

本公开实施例中，3A(例如可以包括RBAC权限模型)支持两种类型的权限计算：

1.进行权限判断，计算结果为布尔值：计算结果为true/false。true表示有权限，false表示无权限。

2.进行数据范围计算，计算结果为“$in包含”：在目标业务应用的数据库(这里以MongoDB(一个基于分布式文件存储的数据库)为例进行举例说明，但本公开并不限定于此)中查询一系列枚举值的范围。

下面对这两种类型分别进行说明。

首先，对第一种类型即进行权限判断，计算结果为布尔值的类型进行说明。

图18示意性示出了根据本公开的一实施例的策略中不含限制条件的权限判断逻辑的流程示意图。

如图18所示，当准入网关接收到当前用户的应用访问请求时，准入网关调用3A(3A中包括策略计算模块)的权限检查接口：/rights/check，入参(输入参数)包括：账号(account)、资源(resource)和action(行为)。

然后3A的策略计算模块根据从准入网关接收到的账号、资源和行为筛选命中的policy(策略，且图18实施例中命中的策略中不含限制条件)。3A的策略计算模块再根据命中的策略进行计算：若策略的效力均为allow(允许)，则结果为true(有权限)；若策略中包含效力deny(拒绝)，则结果为false(无权限)。

接着，3A的策略计算模块向准入网关返回权限判断结果或者权限计算结果：true/false。

图19示意性示出了根据本公开的一实施例的策略中包含限制条件的权限判断逻辑的流程示意图。

如图19所示，当准入网关接收到当前用户的应用访问请求时，准入网关调用3A中的策略计算模块的权限检查接口：/rights/check，入参(输入参数)包括：账号(account)、资源(resource)和action(行为)。

然后3A的策略计算模块根据从准入网关接收到的账号、资源和行为筛选命中的policy(策略，且图19实施例中命中的策略中含限制条件)。3A的策略计算模块再根据命中的策略进行计算：条件与条件之间是“与”的关系；效力deny(拒绝)优先于allow(允许)。

本公开实施例中，条件与条件之间是“与”的关系是指3A匹配的多条策略中的多个条件形成一个并集。效力deny优先于allow是指3A匹配的多条策略中，只要有一条策略中的效力是deny，则返回的结果就是false。

接着，3A的策略计算模块向准入网关返回权限判断结果或者权限计算结果：true/false。

接下来，对第二种类型即进行数据范围计算，计算结果为“$in包含”的类型进行说明。此时，权限判断的逻辑如图20所示。当准入网关接收到当前用户的应用访问请求时，准入网关调用3A中的策略计算模块的权限检查接口：/rights/translate(翻译)/mongo(即指定数据库类型为mongo的权限翻译接口)，入参(输入参数)包括：账号(account)、资源(resource)和action(行为)。

然后3A的策略计算模块根据从准入网关接收到的账号、资源和行为筛选命中的policy(策略)。3A的策略计算模块再根据命中的策略进行计算：条件与条件之间是“与”的关系；效力deny(拒绝)优先于allow(允许)。

接着，3A的策略计算模块向准入网关返回数据范围计算结果作为目标数据范围信息：结果为“$in包含”。

图21示意性示出了根据本公开的一实施例的业务系统/模块(包括目标业务应用)通过包括3A的认证系统进行权限及授权控制的示意图。

如图21所示，业务系统/模块可以通过认证系统进行权限及授权控制。基本流程如下表2所示：

表2认证系统使用流程说明

序号	流程名	执行方
			0	前提条件：业务系统定义并实现权限项、权限策略	业务系统
1	业务系统对接认证系统	业务系统
			2	将业务的角色/权限/授权/角色成员等配置至认证系统	业务系统
3	用户访问业务	业务系统
			4	业务系统调用认证系统查询授权情况	业务系统
5	认证系统进行权限判断	认证系统
			6	认证系统将权限判断结果返回至业务系统	认证系统
7	业务系统接收权限判断结果，并执行对应动作	业务系统

图22示意性示出了根据本公开的一实施例的基于准入网关集成3A访问控制服务模式的工作原理示意图。

如图22所示，目标业务应用基于准入网关(API网关)集成3A访问控制服务模式的工作原理如下：

1、当用户访问目标业务应用时，经过准入网关。

2、准入网关根据ACL规则向3A请求权限检查(携带账号、资源和行为)。

3、3A收到请求后进行策略计算。

4、3A将权限计算/判断结果返回准入网关。

5、准入网关根据权限计算/判断结果进行处理：

1)若权限判断结果为无权限(false)，则准入网关直接拒绝用户访问。

2)若权限判断结果为有权限(true)，则准入网关将用户的应用访问请求转发至目标业务应用。

3)若权限计算结果为数据范围，则准入网关在转发该用户的应用访问请求时，添加该数据范围信息。

图23示意性示出了根据本公开的一实施例的权限模型解决的问题的示意图。如图23所示，权限模型要解决的问题包括：

1、控制功能的可访问性：用户bbb的应用访问请求在3A的策略计算模块通过返回true/false结果控制可访问性。

2、使用数据范围控制可访问性：用户aaa的应用访问请求在3A的策略计算通过返回数据范围控制可访问性。

3、使用数据范围过滤结果：用户aaa的应用访问请求将数据范围传向内部服务，通过业务逻辑将访问数据库范围约束在传入的数据范围中，再由数据库返回符合的数据结果作为目标数据返回给用户aaa。

图23中，以两个用户为例进行举例说明，给用户aaa分配的角色是org1-user(组织1用户)，其待访问的资源是系统(system)，行为是列表(list)，用户aaa向准入网关发送的应用访问请求为：GET/api/system/list。准入网关中配置了如下路由规则(routeRule，包含ACL规则在内)：

准入网关根据用户aaa发送的应用访问请求中的资源和行为匹配中上述路由规则，从而可以确定调用管理平台的3A的策略计算模块的/rights/translate/mongo接口，并携带入参：resource:system以及action:list。

这里假设管理平台中配置了系统：xxx，所属机构为：org1；和系统：yyy，所属机构也是org1。且在3A中配置了如下两个权限识别策略：

用户aaa的账号(角色：org1-user)、资源(system)和行为(action)能够与上述两个权限识别策略的主体(subject)、资源(system)和行为(action)匹配，因此可以命中上述两个权限识别策略，且这两个权限识别策略的效力(effect)均为允许(allow)，所以3A给准入网关返回的数据范围/权限表达式为：{“sys.id”:{$in:[“xxx”,”yyy”]}}。准入网关根据从3A获取的权限表达式，在向目标业务应用的内部服务(WebAPI)转发用户aaa的应用访问请求时，会添加该权限表达式对应的数据范围信息：

{Http Headers}

limits:{“sys.id”:{$in:[“xxx”,”yyy”]}}

即在用户aaa的应用访问请求的数据包的Http头中添加限制{“sys.id”:{$in:[“xxx”,”yyy”]}}。

目标业务应用的内部服务接收到附加了上述数据范围信息的用户aaa的应用访问请求后，可以对其进行逻辑处理，调用底层API，将上述数据范围信息传递给底层API：

{Http Headers}

limits:{“sys.id”:{$in:[“xxx”,”yyy”]}}

底层API根据上述权限信息limits:{“sys.id”:{$in:[“xxx”,”yyy”]}}生成数据库过滤器(DB Filter{“sys.id”:{$in:[“xxx”,”yyy”]}})，利用该数据库过滤器去查询数据库MongoDB。

图23中，假设给用户bbb分配的角色是sysxxx-user(系统xxx用户)和sysyyy-user(系统yyy用户)，其待访问的资源是系统(system)，行为是编辑(edit)，用户bbb向准入网关发送的应用访问请求为：POST/api/system/edit，准入网关中配置了如下路由规则：

准入网关根据用户bbb发送的应用访问请求中的资源和行为匹配中上述路由规则，从而可以确定调用管理平台的3A的/rights/check接口，携带入参：resource:system、action:edit。

用户bbb的账号(角色：sysxxx-user和sysyyy-user)、资源(system)和行为(action)能够分别与上述两个权限识别策略的主体(subject)、资源(system)和行为(action)匹配，因此可以命中上述两个权限识别策略，根据这两个权限识别策略可以获得权限判断结果：true/false，如果为true，则表示权限判断结果为有权限，则向目标业务应用的内部服务转发用户bbb的应用访问请求，内部服务调用底层API。如果为false，则表示无权限，此时，准入网关向用户bbb返回拒绝访问消息。

图24示意性示出了根据本公开的一实施例的判断访问者是否有权限(无限制条件)的示意图。

如图24所示，上述实施例提供的方法的应用场景之一：需要判断访问者(当前用户)是否有权限(假设命中的Policy无限制条件)。图24实施例中，认证系统包括准入网关和3A。

当前用户访问业务时，目标业务应用需要获取当前用户是否有权限访问。图24场景中不涉及包含条件的Policy。

场景描述如下：

业务规则：系统管理员可以创建系统

用户：zhangsan

所属的角色：「系统的管理员(sys-manager)」

在目标业务应用中的操作/行为：希望创建新系统

其对应的工作原理和执行结果如图24所示：

步骤1，预先在3A中配置/定义如下策略(Policy)：

步骤2，在准入网关上配置如下路由规则(包含ACL规则)：

步骤3，当用户zhangsan请求访问目标业务应用时，经过准入网关，请求API：

用户：zhangsan

角色：sys-manager

POST/api/sytem/create

步骤4，准入网关根据用户发送的应用访问请求中携带的账号、资源及行为与上述步骤2在准入网关上配置的上述路由规则，可以确定调用3A的/rights/check接口，并携带入参为account:zhangsan，resource:system，action:create。3A根据上述入参，根据account:zhangsan能够确定对应的角色为sys-manager，当入参的账号、资源和行为分别与3A中的策略中的主体、资源和行为匹配时，表明该条策略命中。然后，3A根据命中的策略计算权限结果：若均为allow，则结果为true；若包含deny，则结果为false。这里假设命中的策略中的效力为allow。

步骤5，A向准入网关返回权限判断结果：true/false。

步骤6，准入网关获取权限判断结果进行处理：

步骤6.1，若结果为true，则有权限，准入网关将该用户zhangsan的应用访问请求转发至目标业务应用。

步骤6.2，若结果为false，则无权限，准入网关直接向用户zhangsan发送拒绝访问消息。

这里由于上述命中的策略中只包含allow，则对应的结果为true，因此，准入网关将zhangsan的应用访问请求转发至目标业务应用。目标业务应用根据应用访问请求执行业务逻辑。在图24实施例中，用户zhangsan可以创建系统。

图25示意性示出了根据本公开的一实施例的判断访问者是否有权限(有限制条件)的示意图。

如图25所示，上述实施例提供的方法的应用场景之一：需要判断访问者(当前用户)是否有权限(假设命中的Policy有限制条件)。

场景描述：用户访问业务时，目标业务应用需要获取当前用户是否有权限访问。此场景将涉及包含ContainCondition(包含限制条件)类型条件的Policy。

业务规则：

「xxx系统(xxx)」和「yyy系统(yyy)」属于「机构1(org1)」。

允许「xxx系统的用户(sysxxx-user)」和「机构1的用户(org1-user)」访问包含xxx系统的系统列表(list)，并查看详情(view)和编辑(edit)。

允许「yyy系统的用户(sysyyy-user)」和「机构1的用户(org1-user)」访问包含yyy系统的系统列表，并查看详情和编辑。

用户：lisi

所属的角色：「xxx系统的用户(sysxxx-user)」「yyy系统的用户(sysyyy-user)」

在目标业务应用中的操作：希望编辑系统zzz

工作原理和执行结果如图25所示。

步骤1，在3A中配置如下两条权限识别策略：

步骤2，在准入网关上配置路由规则(含ACL)如下：

步骤3，当用户请求访问目标业务应用时，经过准入网关，请求API：

用户：lisi

角色：sysxxx-user,sysyyy-user

POST/api/sytem/edit

步骤4，准入网关向3A请求权限检查。具体地，准入网关根据路由规则(含ACL规则)，调用3A的权限检查接口进行权限判断：

权限检查接口：/rights/check

入参：

account：lisi

resource:system

action:edit

context:zzz

步骤5，权限检查接口将执行逻辑。

首先，根据主体、资源和行为，筛选命中的权限识别策略(Policy)。然后，根据命中的Policy计算权限结果：

条件与条件之间是“与”的关系；效力deny优先于allow；从而计算出最终的权限结果。

在图25实施例中，假设计算的权限结果为false。

步骤6，准入网关获取权限判断结果进行处理：

步骤6.1，若结果为true，则有权限，准入网关将该用户lisi的应用访问请求转发至目标业务应用。

步骤6.2，若结果为false，则无权限，准入网关直接向用户lisi发送拒绝访问消息。

这里由于上述命中的策略中只包含allow，则对应的结果为true，因此，准入网关将lisi的应用访问请求转发至目标业务应用。目标业务应用根据应用访问请求执行业务逻辑。在图25实施例中，结果为false，准入网关直接拒绝用户lisi的应用访问请求。

图26示意性示出了根据本公开的一实施例的判断访问者是否有权限(有限制条件)的示意图。

图26对应的是应用场景之一：需要判断访问者是否有权限(有限制条件)。

场景描述如下：用户访问业务时，目标业务应用需要向当前用户返回有权限访问的数据范围。此场景通过ContainCondition类型的条件实现。

业务规则：

「xxx系统(xxx)」和「yyy系统(yyy)」属于「机构1(org1)」。

允许「xxx系统的用户(sysxxx-user)」和「机构1的用户(org1-user)」访问包含xxx系统的系统列表，并查看详情和编辑。

允许「yyy系统的用户(sysyyy-user)」和「机构1的用户(org1-user)」访问包含yyy系统的系统列表，并查看详情和编辑。

用户：wangwu

所属的角色：机构1的用户(org1-user)

在目标业务应用中的操作：希望访问有权限的系统列表

工作原理和执行结果如图26所示。

步骤1，在3A中配置如图25所示的两个权限识别策略。

步骤2，在准入网关上配置如图25所示的路由规则(含ACL规则)。

步骤3，当用户请求访问目标业务应用时，经过准入网关，请求API：

用户：wangwu

角色：org1-user

GET/api/system/list

步骤4，准入网关向3A请求数据范围。具体地，准入网关根据上述路由规则(含ACL)，调用3A的下述接口请求数据范围：

请求数据范围的接口：/rights/translate/mongo

入参：

account：wangwu

resource:system

action:list

请求数据范围的接口执行以下逻辑：

首先，根据主体、资源和行为，筛选命中的权限识别策略(Policy)。然后，根据命中的Policy计算数据范围：

条件与条件之间是“与”的关系；效力deny优先于allow；从而计算出最终的权限结果。

在图26实施例中，计算的结果为xxx和yyy(即表明多个匹配命中的权限识别策略之间的条件是相互与关系)。

步骤5，3A将数据范围返回准入网关。准入网关获取到数据范围：{"sys.id":{$in:["xxx","yyy"]}}。

步骤6，准入网关向目标业务应用转发用户的应用访问请求，并在转发应用访问请求时添加数据范围：

[Http Headers]

limits:{"sys.id":{$in:["xxx","yyy"]}。

本公开实施方式提供的实现权限控制的方法，通过在与3A对接的目标业务应用中间加一层API网关，基于API网关来实现RBAC权限控制，一方面，将目标业务应用和权限服务解耦，大大减少3A与目标业务应用的代码耦合性，由API网关来完成数据格式之间的转换，降低对3A与目标业务应用的技术栈的约束。另一方面，使得3A对于目标业务应用来说是透明的，即对目标业务应用来说，权限模型是透明的，降低侵入性，提升安全系数。同时，后期如果目标业务应用的权限发生变更，只需要变动在网关的ACL，不需要修改目标业务应用代码，便于维护。

图27示意性示出了根据本公开的一实施例的准入网关的框图。如图27所示，本公开实施例提供的准入网关2700可以包括：访问请求接收单元2710、目标接口确定单元2720、权限检查请求单元2730、权限结果接收单元2740以及响应消息返回单元2750。

其中，访问请求接收单元2710可以用于接收用户终端发送的应用访问请求，所述应用访问请求携带有用户账号信息、待访问的目标资源信息及所述目标资源信息对应的操作行为信息。目标接口确定单元2720可以用于根据预先配置的路由访问信息和所述应用访问请求，确定访问控制单元的目标接口。权限检查请求单元2730可以用于调用所述访问控制单元的目标接口，将所述用户账号信息、所述目标资源信息和所述操作行为信息发送至所述访问控制单元。权限结果接收单元2740可以用于接收所述访问控制单元返回的应用权限识别结果，所述应用权限识别结果是所述目标接口根据所述用户账号信息、所述目标资源信息和所述操作行为信息匹配所述访问控制单元中的权限识别策略，根据所述权限识别策略生成的。响应消息返回单元2750可以用于根据所述应用权限识别结果，向所述用户终端返回针对所述应用访问请求的响应消息。

在示例性实施例中，所述目标接口可以为权限检查接口，所述应用权限识别结果可以包括目标权限判断结果。其中，响应消息返回单元2750可以包括：路由转发单元，可以用于若所述目标权限判断结果为有权限，则将所述应用访问请求转发至目标业务应用；业务执行结果接收单元，可以用于接收所述目标业务应用对所述目标资源信息执行与所述操作行为信息对应的操作行为生成的业务执行结果；业务执行结果返回单元，可以用于将所述业务执行结果作为所述响应消息返回至所述用户终端。

在示例性实施例中，响应消息返回单元2750还可以包括：拒绝访问单元，可以用于若所述目标权限判断结果为无权限，则向所述用户终端返回拒绝访问消息，以作为所述响应消息。

在示例性实施例中，所述目标接口可以为权限翻译接口，所述应用权限识别结果可以包括目标数据范围信息。其中，准入网关2700还可以包括：指定数据库确定单元，可以用于根据所述路由访问信息和所述应用访问请求，确定指定数据库类型信息。其中，权限检查请求单元2730可以包括：权限翻译接口调用单元，可以用于调用所述访问控制单元的所述指定数据库类型信息对应的权限翻译接口，将所述用户账号信息、所述目标资源信息和所述操作行为信息发送至所述访问控制单元。

在示例性实施例中，响应消息返回单元2750可以包括：数据库过滤器生成单元，可以用于根据所述目标数据范围信息生成数据库过滤器；目标数据获得单元，可以用于根据所述数据库过滤器过滤所述指定数据库类型信息对应的指定数据库中的数据，获得目标数据；目标数据返回单元，可以用于将所述目标数据作为所述响应消息返回至所述用户终端。

图28示意性示出了根据本公开的一实施例的用于实现权限控制的系统的框图。如图28所述，本公开实施例提供的用于实现权限控制的系统2800可以包括准入网关2810和访问控制单元2820。其中，准入网关2810用于接收用户终端发送的应用访问请求，所述应用访问请求携带有用户账号信息、待访问的目标资源信息及所述目标资源信息对应的操作行为信息；根据预先配置的路由访问信息和所述应用访问请求，确定访问控制单元2820的目标接口；调用访问控制单元2820的目标接口，向访问控制单元2820发送所述用户账号信息、所述目标资源信息和所述操作行为信息。访问控制单元2820用于接收所述用户账号信息、所述目标资源信息和所述操作行为信息，并根据所述用户账号信息、所述目标资源信息和所述操作行为信息匹配访问控制单元2820中的权限识别策略，根据所述权限识别策略生成并向准入网关2810发送应用权限识别结果。准入网关2810还用于根据接收的所述应用权限识别结果，向所述用户终端返回针对所述应用访问请求的响应消息。

在示例性实施例中，访问控制单元2820还可以用于若根据所述用户账号信息、所述目标资源信息和所述操作行为信息，匹配多条权限识别策略，且至少部分权限识别策略中包括限制条件信息，则所述至少部分权限识别策略中的限制条件信息之间是相互与关系。

在示例性实施例中，访问控制单元2820还可以用于若根据所述用户账号信息、所述目标资源信息和所述操作行为信息，匹配多条权限识别策略，且所述多条权限识别策略中存在至少一条权限识别策略的效力为拒绝，则生成的所述应用权限识别结果为无权限。

在示例性实施例中，用于实现权限控制的系统2800还可以包括管理终端，用于实现权限控制的系统2800可以用于：在管理终端上显示角色管理界面，所述角色管理界面包括创建角色控件；响应于对所述创建角色控件的操作，在管理终端上显示创建角色界面，所述创建角色界面包括角色编码控件和角色名称控件；响应于对所述角色编码控件和所述角色名称控件的操作，创建角色。

在示例性实施例中，用于实现权限控制的系统2800还可以用于：在管理终端上显示权限策略管理界面，所述权限策略管理界面包括新增权限策略控件；响应于对所述新增权限策略控件的操作，在管理终端上显示新增权限策略界面，所述新增权限策略界面包括权限策略编码控件、权限策略名称控件、资源与行为添加控件和效力选择控件；响应于对所述权限策略编码控件、所述权限策略名称控件、所述资源与行为添加控件和所述效力选择控件的操作，创建权限识别策略。

在示例性实施例中，所述角色管理界面还可以包括角色权限管理控件。其中，用于实现权限控制的系统2800还可以用于：响应于对所述角色权限管理控件的操作，在管理终端上显示对应角色的角色权限管理界面，所述角色权限管理界面包括添加角色权限控件；响应于对所述添加角色权限控件的操作，在管理终端上显示添加角色权限界面，所述添加角色权限界面包括权限策略选择控件；响应于对所述权限策略选择控件的操作，为对应角色赋予权限识别策略。

在示例性实施例中，所述角色管理界面还可以包括角色成员管理控件。其中，用于实现权限控制的系统2800还可以用于：响应于对所述角色成员管理控件的操作，在管理终端上显示角色成员管理界面，所述角色成员管理界面包括添加角色成员控件；响应于对所述添加角色成员控件的操作，在管理终端上显示对应角色的添加角色成员界面，所述添加角色成员界面包括角色成员选择控件；响应于对所述角色成员选择控件的操作，为对应角色添加角色成员。

本公开实施例提供的准入网关和用于实现权限控制的系统中的各个单元的具体实现可以参照上述用于实现权限控制的方法中的内容，在此不再赘述。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本公开实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (15)

1.一种用于实现权限控制的方法，其特征在于，所述方法应用于准入网关；其中，所述方法包括：

接收用户终端发送的应用访问请求，所述应用访问请求携带有用户账号信息、待访问的目标资源信息及所述目标资源信息对应的操作行为信息；

根据预先配置的路由访问信息和所述应用访问请求，确定访问控制单元的目标接口；

调用所述访问控制单元的目标接口，将所述用户账号信息、所述目标资源信息和所述操作行为信息发送至所述访问控制单元；

接收所述访问控制单元返回的应用权限识别结果，所述应用权限识别结果是所述目标接口根据所述用户账号信息、所述目标资源信息和所述操作行为信息匹配所述访问控制单元中的权限识别策略，根据所述权限识别策略生成的；

根据所述应用权限识别结果，向所述用户终端返回针对所述应用访问请求的响应消息。

2.根据权利要求1所述的用于实现权限控制的方法，其特征在于，所述目标接口为权限检查接口，所述应用权限识别结果包括目标权限判断结果；其中，根据所述应用权限识别结果，向所述用户终端返回针对所述应用访问请求的响应消息，包括：

若所述目标权限判断结果为有权限，则将所述应用访问请求转发至目标业务应用；

接收所述目标业务应用对所述目标资源信息执行与所述操作行为信息对应的操作行为生成的业务执行结果；

将所述业务执行结果作为所述响应消息返回至所述用户终端。

3.根据权利要求2所述的用于实现权限控制的方法，其特征在于，根据所述应用权限识别结果，向所述用户终端返回针对所述应用访问请求的响应消息，还包括：

若所述目标权限判断结果为无权限，则向所述用户终端返回拒绝访问消息，以作为所述响应消息。

4.根据权利要求1所述的用于实现权限控制的方法，其特征在于，所述目标接口为权限翻译接口，所述应用权限识别结果包括目标数据范围信息；其中，所述方法还包括：

根据所述路由访问信息和所述应用访问请求，确定指定数据库类型信息；

其中，调用所述访问控制单元的目标接口，将所述用户账号信息、所述目标资源信息和所述操作行为信息发送至所述访问控制单元，包括：

调用所述访问控制单元的所述指定数据库类型信息对应的权限翻译接口，将所述用户账号信息、所述目标资源信息和所述操作行为信息发送至所述访问控制单元。

5.根据权利要求4所述的用于实现权限控制的方法，其特征在于，根据所述应用权限识别结果，向所述用户终端返回针对所述应用访问请求的响应消息，包括：

根据所述目标数据范围信息生成数据库过滤器；

根据所述数据库过滤器过滤所述指定数据库类型信息对应的指定数据库中的数据，获得目标数据；

将所述目标数据作为所述响应消息返回至所述用户终端。

6.一种用于实现权限控制的方法，其特征在于，所述方法应用于用于实现权限控制的系统，所述系统包括准入网关和访问控制单元；其中，所述方法包括：

所述准入网关接收用户终端发送的应用访问请求，所述应用访问请求携带有用户账号信息、待访问的目标资源信息及所述目标资源信息对应的操作行为信息；

所述准入网关根据预先配置的路由访问信息和所述应用访问请求，确定所述访问控制单元的目标接口；

所述准入网关调用所述访问控制单元的目标接口，向所述访问控制单元发送所述用户账号信息、所述目标资源信息和所述操作行为信息；

所述访问控制单元接收所述用户账号信息、所述目标资源信息和所述操作行为信息，并根据所述用户账号信息、所述目标资源信息和所述操作行为信息匹配所述访问控制单元中的权限识别策略，根据所述权限识别策略生成并向所述准入网关发送应用权限识别结果；

所述准入网关根据接收的所述应用权限识别结果，向所述用户终端返回针对所述应用访问请求的响应消息。

7.根据权利要求6所述的用于实现权限控制的方法，其特征在于，根据所述用户账号信息、所述目标资源信息和所述操作行为信息匹配所述访问控制单元中的权限识别策略，包括：

若根据所述用户账号信息、所述目标资源信息和所述操作行为信息，匹配多条权限识别策略，且至少部分权限识别策略中包括限制条件信息，则所述至少部分权限识别策略中的限制条件信息之间是相互与关系。

8.根据权利要求6所述的用于实现权限控制的方法，其特征在于，根据所述用户账号信息、所述目标资源信息和所述操作行为信息匹配所述访问控制单元中的权限识别策略，根据所述权限识别策略生成并向所述准入网关发送应用权限识别结果，包括：

若根据所述用户账号信息、所述目标资源信息和所述操作行为信息，匹配多条权限识别策略，且所述多条权限识别策略中存在至少一条权限识别策略的效力为拒绝，则生成的所述应用权限识别结果为无权限。

9.根据权利要求6所述的用于实现权限控制的方法，其特征在于，所述系统还包括管理终端，所述方法还包括：

在所述管理终端上显示角色管理界面，所述角色管理界面包括创建角色控件；

响应于对所述创建角色控件的操作，在所述管理终端上显示创建角色界面，所述创建角色界面包括角色编码控件和角色名称控件；

响应于对所述角色编码控件和所述角色名称控件的操作，创建角色。

10.根据权利要求9所述的用于实现权限控制的方法，其特征在于，还包括：

在所述管理终端上显示权限策略管理界面，所述权限策略管理界面包括新增权限策略控件；

响应于对所述新增权限策略控件的操作，在所述管理终端上显示新增权限策略界面，所述新增权限策略界面包括权限策略编码控件、权限策略名称控件、资源与行为添加控件和效力选择控件；

响应于对所述权限策略编码控件、所述权限策略名称控件、所述资源与行为添加控件和所述效力选择控件的操作，创建权限识别策略。

11.根据权利要求10所述的用于实现权限控制的方法，其特征在于，所述角色管理界面还包括角色权限管理控件；其中，所述方法还包括：

响应于对所述角色权限管理控件的操作，在所述管理终端上显示对应角色的角色权限管理界面，所述角色权限管理界面包括添加角色权限控件；

响应于对所述添加角色权限控件的操作，在所述管理终端上显示添加角色权限界面，所述添加角色权限界面包括权限策略选择控件；

响应于对所述权限策略选择控件的操作，为对应角色赋予权限识别策略。

12.根据权利要求11所述的用于实现权限控制的方法，其特征在于，所述角色管理界面还包括角色成员管理控件；其中，所述方法还包括：

响应于对所述角色成员管理控件的操作，在所述管理终端上显示角色成员管理界面，所述角色成员管理界面包括添加角色成员控件；

响应于对所述添加角色成员控件的操作，在所述管理终端上显示对应角色的添加角色成员界面，所述添加角色成员界面包括角色成员选择控件；

响应于对所述角色成员选择控件的操作，为对应角色添加角色成员。

13.一种准入网关，其特征在于，包括：

访问请求接收单元，用于接收用户终端发送的应用访问请求，所述应用访问请求携带有用户账号信息、待访问的目标资源信息及对所述目标资源信息对应的操作行为信息；

目标接口确定单元，用于根据预先配置的路由访问信息和所述应用访问请求，确定访问控制单元的目标接口；

权限检查请求单元，用于调用所述访问控制单元的目标接口，将所述用户账号信息、所述目标资源信息和所述操作行为信息发送至所述访问控制单元；

权限结果接收单元，用于接收所述访问控制单元返回的应用权限识别结果，所述应用权限识别结果是所述目标接口根据所述用户账号信息、所述目标资源信息和所述操作行为信息匹配所述访问控制单元中的权限识别策略，根据所述权限识别策略生成的；

响应消息返回单元，用于根据所述应用权限识别结果，向所述用户终端返回针对所述应用访问请求的响应消息。

14.一种用于实现权限控制的系统，其特征在于，所述系统包括准入网关和访问控制单元；其中，

所述准入网关用于接收用户终端发送的应用访问请求，所述应用访问请求携带有用户账号信息、待访问的目标资源信息及所述目标资源信息对应的操作行为信息；根据预先配置的路由访问信息和所述应用访问请求，确定所述访问控制单元的目标接口；调用所述访问控制单元的目标接口，向所述访问控制单元发送所述用户账号信息、所述目标资源信息和所述操作行为信息；

所述访问控制单元用于接收所述用户账号信息、所述目标资源信息和所述操作行为信息，并根据所述用户账号信息、所述目标资源信息和所述操作行为信息匹配所述访问控制单元中的权限识别策略，根据所述权限识别策略生成并向所述准入网关发送应用权限识别结果；

所述准入网关还用于根据接收的所述应用权限识别结果，向所述用户终端返回针对所述应用访问请求的响应消息。

15.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，配置为存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1至12中任一项所述的方法。

Images