CN117220924A - 系统权限控制方法、装置及系统 - Google Patents

Abstract

本申请属于权限管理领域，尤其涉及一种系统权限控制方法、装置及系统。方法包括：后端服务器接收网络请求，根据网络请求确定鉴权请求消息，并向统一鉴权中心发送鉴权请求消息，由统一鉴权中心完成角色鉴权和资源鉴权，并接收统一鉴权中心发送的鉴权结果，根据鉴权结果确定是否执行请求的操作。本申请通过将角色鉴权和资源鉴权的统一处理，使后端服务器不再需要进行资源鉴权，使后端服务器的接口中代码简洁明了，方便阅读，从而减少了系统的安全漏洞，避免因开发人员的疏忽导致的鉴权漏洞，提升了系统安全性以及开发效率。

Description

系统权限控制方法、装置及系统

技术领域

本申请涉及权限管理技术领域，特别涉及一种系统权限控制方法、装置及系统。

背景技术

目前大多数软件系统都有相对应的账户系统，在账户系统中，不同的账户拥有不同的权限，且不同的账户还拥有独立的下属资源。其中，权限主要包括角色权限和资源权限两个层面。角色权限是指平台上的不同角色对应的平台功能是不一样的。资源权限是指平台上不同账户对一个特定的资源所拥有的操作权限。

针对复杂多样的权限问题，一般的软件系统在处理权限问题时，往往先通过API网关进行角色的权限判断，再通过后端进行资源的权限判断，同时执行业务，因此执行业务的代码与权限处理的代码放在一起，这样的后端的代码阅读性和维护性很差，往往很难适应需求的变更。

发明内容

本申请提供了一种系统权限控制方法、装置及系统，通过后端服务器构造权限判断的必要信息，再由统一鉴权中心进行权限判断，使后端服务器不需要再进行权限判断从而简化了后端服务器的代码，提高了系统的安全性。

所述技术方案如下：

第一方面，本申请实施例提供一种系统权限控制方法，法应用于后端服务器，方法包括：

后端服务器接收来自客户端的网络请求，网络请求用于指示用户的身份以及请求的操作；

后端服务器根据网络请求，向统一鉴权中心发送鉴权请求消息，鉴权请求消息用于请求统一鉴权中心对用户进行角色鉴权以及对用户请求的操作进行资源鉴权；

后端服务器接收来自统一鉴权中心的鉴权结果，鉴权结果用于表示用户是否具有执行操作的权限；

后端服务器根据鉴权结果确定是否执行操作。

本申请通过后端服务器获取网络请求，根据网络请求生成相应的请求身份信息，请求路由信息以及策略请求信息，并将请求身份信息，请求路由信息以及策略请求信息发送至统一鉴权中心，由统一鉴权中心结合请求身份信息和请求路由信息完成角色鉴权，结合请求身份信息和策略请求信息完成资源鉴权，达到角色鉴权和资源鉴权统一，这样，后端服务器每一个接口中的业务代码中都不再需要进行资源鉴权，使代码简洁明了方便阅读，从而减少了系统的安全漏洞，避免因开发人员的疏忽导致的鉴权漏洞，提升了系统安全性以及开发效率。

在第一方面的一种可能的实现方式中，鉴权请求消息包括：请求身份信息、请求路由信息以及策略请求信息。请求身份信息用于指示用户的身份，请求路由信息用于指示用户请求执行的操作，资源请求信息用于指示用户请求执行的操作需要的资源。

在第一方面的一种可能的实现方式中，根据鉴权结果确定是否执行操作，本申请实施例提供的方法包括：

后端服务器在鉴权结果表示用户不具有执行操作的权限的情况下，发送反馈信息，反馈信息用于指示用户不具有执行操作的权限；

后端服务器在鉴权结果表示用户具有执行操作的权限，执行操作。

在第一方面的一种可能的实现方式中，在根据网络请求，向统一鉴权中心发送鉴权请求消息之前，本申请实施例提供的方法还包括：

后端服务器确定指示请求的操作需要的资源的源代码。

在第一方面的一种可能的实现方式中，确定指示请求的操作需要的资源的源代码包括：

后端服务器在网络请求中设定策略规则；

后端服务器根据策略规则生成源代码。

第二方面，本申请实施例提供一种系统权限控制装置，装置包括：

第一接收单元，用于接收来自客户端的网络请求，网络请求用于指示用户的身份以及请求的操作；

发送单元，用于根据网络请求，向统一鉴权中心发送鉴权请求消息，鉴权请求消息用于请求统一鉴权中心对用户进行角色鉴权以及对用户请求的操作进行资源鉴权；

第二接收单元，用于接收来自统一鉴权中心的鉴权结果，鉴权结果用于表示用户是否具有执行操作的权限；

处理单元，用于根据鉴权结果确定是否执行操作。

在第二方面的一种可能的实现方式中，处理单元，还用于确定指示请求的操作需要的资源的源代码。

第三方面，本申请实施例提供一种系统权限控制系统，系统包括：客户端、后端服务器、统一鉴权中心；

客户端用于向后端服务器发送网络请求；

后端服务器用于根据网络请求，向统一鉴权中心发送鉴权请求消息，鉴权请求消息包括：请求身份信息、请求路由信息以及策略请求信息，以及用于根据统一鉴权中心反馈的鉴权结果，执行或不执行操作；

统一鉴权中心用于根据鉴权请求消息确定用户是否有执行操作的权限。

在第三方面的一种可能的实现方式中，后端服务器包括：服务器入口点、拦截器以及业务逻辑层；

服务器入口点用于接收网络请求，以及用于向拦截器发送网络请求；

拦截器用于根据网络请求确定请求身份信息、请求路由信息以及策略请求信息，拦截器还用于向统一鉴权中心发送鉴权请求消息，以及用于接收鉴权结果；

拦截器还用于在鉴权结果表示用户不具有执行操作的权限的情况下，向服务器入口点发送反馈信息，反馈信息用于指示用户不具有执行操作的权限；

业务逻辑层用于在鉴权结果表示用户具有执行操作的权限的情况下，根据网络请求执行操作。

第四方面，本申请实施例提供一种电子设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如第二方面任一项所述的零知识证明工具测试方法。

第五方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如第二方面所述的零知识证明工具测试方法。

第六方面，提供了一种芯片，所述芯片包括处理器，所述处理器和与所述处理器耦合的通信接口，所述处理器用于运行计算机程序或指令，以实现上述所述的零知识证明工具测试方法，所述通信接口用于与所述芯片之外的其它模块进行通信。

可以理解的是，上述第二方面、第三方面、第四方面、第五方面以及第六方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一种系统的权限判断示意图；

图2是本申请实施例提供的一种系统权限控制系统的示意图；

图3是本申请实施例提供的一种系统权限控制方法的流程示意图；

图4是本申请实施例提供的一种中间件生成拦截器源代码的流程示意图；

图5是本申请实施例提供的一种系统权限控制装置的结构示意图；

图6是本申请实施例提供的另一种系统权限控制系统的示意图；

图7是本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述，在其它情况中，各个实施例中的具体技术细节可以互相参考，在一个实施例中没有描述的具体系统可参考其它实施例。

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

在本申请说明书中描述的参考“本申请实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在另一些实施例中”、“本申请一实施例”、“本申请其他实施例”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

大多数软件系统都有相应的账户系统，不同的账户具有不同的权限，且不同的账户具有独立的下属资源。比如，办公自动化(office automation，OA)平台，在整个OA平台上有很多账户，每个账户对应一个角色，这些角色种类很多，包括平台管理员、普通成员、系统维护人员、流程审批管理人员等。其中，每个角色对应的权限各不相同，权限主要包括角色权限和资源权限两个层面。角色权限是指平台上的不同角色对应的平台功能不同。资源权限是指平台上不同账户对一个特定的资源所拥有的操作权限。

在一些相关技术中，软件系统在处理权限问题时，后端代码是将平台的业务逻辑代码，和涉及到的权限处理逻辑代码放在一起。但是，这样的后端代码往往很难适应需求的变更，且后端代码的阅读性和维护性较差。

在另一些相关技术中，权限处理方式是在软件系统的最前端应用程序编程接口(application programming interface，API)网关处，结合基于角色的访问控制(role-based access control，RBAC)模型对请求进行权限判断和控制。如图1所示，API网关将访问请求进行报文头解析，解析出请求的用户身份、请求的统一资源定位器(uniformResource Locator，URL)以及请求方法。网关根据用户身份对应的角色，判断当前请求的URL是否在用户对应角色的权限范围内。这样可以有效的判断出用户是否拥有某个功能的权限，而且这个权限判断并不和业务代码耦合在一起，是独立在API网关内部的。

但是这种权限判断仅仅是完成了角色权限的判断，对资源权限的判断就无法完成了。而软件系统中拥有非常多的接口，对于API网关来说，这些接口协议是无法被理解的，这些接口的资源权限也就无法做出判断，只能将资源权限的判断下放到接口自身的逻辑上去，需要在后端中完成资源权限的判断，这导致后端需要针对每一个接口进行逻辑判断，而每个接口都有相同或者不相同的逻辑判断，导致了代码冗长，不易阅读。

其中，权限的判断又称为鉴权，为了方便说明，以下将角色权限的判断称为角色鉴权，资源权限的判断称为资源鉴权。可以理解的是，权限的判断也可以为其他的名称，在此处不做限定。

为了解决现有技术中角色鉴权的和资源鉴权分散，逻辑复杂的问题，本申请实施例提供了一种系统权限控制方法，基于protobuf在后端服务器中通过中间件发起鉴权，由统一鉴权中心进行鉴权，使角色鉴权和资源鉴权统一，提升了系统的安全度以及开发效率。同时后端服务器的每一个接口中的业务代码都不再需要进行资源鉴权，使代码简洁明了，更加方便阅读。

在对本申请实施例进行详细地解释说明之前，先对本申请实施例的应用场景予以说明。

图2为本申请实施例提供的一种系统权限控制系统示意图，该系统包括：客户端201、后端服务器202以及鉴权端203。

其中，客户端201与后端服务器202相对应，客户端201用于为用户提供本地服务。

举例说明，客户端201为web客户端(比如web浏览器)，其主要功能是将用户向后端服务器请求的资源呈现出来，显示在web客户端(比如web浏览器)的窗口中。

其中，后端服务器202用于处理请求，以及提供请求对应的响应。

举例说明，后端服务器202可以为谷歌远程过程调用(google remote procedurecall，gRPC)后端服务器。其中，gRPC是一种基于protobuf协议构建的，可以在任何环境中运行的现代开源高性能远程过程调用(remote procedure call，RPC)框架，其中，protobuf协议提供了一个强大的二进制序列化工具集和语言定义服务。

其中，鉴权端203用于角色鉴权以及资源鉴权，比如，鉴权端203可以是统一鉴权中心。

在本申请实施例中，一种系统权限控制方法的执行主体并未特别限定，只要可以通过运行记录有本申请实施例的一种系统权限控制方法的代码的程序，以根据本申请实施例的一种系统权限控制方法进行通信即可。例如，本申请实施例提供的一种系统权限控制方法的执行主体可以是后端服务器202中能够调用程序并执行程序的功能模块，或者为应用于后端服务器202中的通信装置，例如，芯片、芯片系统、集成电路等等，这些芯片、芯片系统、集成电路可以设置于后端服务器202内部，也可以相对于后端服务器202独立，本申请实施例不做限制。

下述以客户端201为web客户端，后端服务器202为gRPC后端服务器，鉴权端203为统一鉴权中心为例，对一种系统权限控制方法进行说明。

参考图3，本申请实施例提供了一种系统权限控制方法的流程示意图，该方法包括以下步骤：

步骤301、gRPC后端服务器接收来自web客户端的网络请求。

其中，网络请求用于指示用户的身份以及请求的操作。

举例说明，以软件系统为OA平台为例，用户的身份可以是普通人员、流程审批人员、系统维护人员等，请求的操作可以是请假申请、请假申请审批、系统维护等。

举例说明，以软件系统为购物平台为例，用户的身份可以是卖家、买家、管理人员等，请求的操作可以是付款、收款、管理平台等。

可以理解的是，不同的用户身份拥有不同的操作权限，比如，普通人员可以进行请假申请的操作，流程审批人员可以进行审批请假申请的操作，系统维护人员可以进行系统维护的操作。再比如，买家可以进行付款操作，卖家可以进行收款操作，管理人员可以进行关闭卖家商铺、维护购物平台等操作。

在一种可能的实施例中，web客户端向gRPC后端服务器发送网络请求。

举例说明，以软件系统为OA平台，网络请求为请假申请为例，用户A为普通人员，用户A在OA平台对应的账户为普通OA成员，用户A通过web客户端登录OA平台，并通过web客户端向gRPC后端服务器发送请假申请，该请假申请可以指示该账户为普通OA成员，同时还可以指示需要进行的操作为请假申请。

值得说明是是，gRPC后端服务器也可以从其他地方获取网络请求，在本申请中不做限定。

步骤302、gRPC后端服务器根据网络请求，向统一鉴权中心发送鉴权请求消息。

其中，鉴权请求消息用于请求统一鉴权中心对用户进行角色鉴权以及对用户请求的操作进行资源鉴权。角色鉴权是判断用户是否是有权限进行用户所请求的操作。资源鉴权是判断用户是否有权限对特定资源执行操作。

举例说明，以软件系统为OA平台为例，用户A在OA平台上发起请假申请，OA平台将请假单X发送至用户B，用户B在OA平台上发起审批请假申请。基于上述场景，角色鉴权就是确定用户A的身份，并判断用户A是否有权限进行请假申请的操作，以及确定用户B的身份，并判断用户B是否有权限进行审批请假申请的操作。而资源鉴权就是判断用户B是否有权限对请假单X进行审批请假申请的操作。

在本申请的一个实施例中，鉴权请求消息包括请求身份信息、请求路由信息以及策略请求信息。

其中，请求身份信息用于确定用户的身份，请求路由信息用于确定请求的操作，资源请求信息用于确定请求的操作需要的资源。请求身份信息和请求路由信息可以用于角色鉴权，请求身份信息和资源请求信息可以用于资源鉴权。

其中，请求身份信息可以是请求令牌(token)。请求token的本质是用户身份信息，是服务器生成的一串字符串，例如，用户唯一的身份标识(user identification，UID)。

举例说明，用户A通过web客户端访问OA平台，会带有一个唯一标识用户身份信息的请求token，OA平台根据请求token，可以判断出是用户A发起的请求。

其中，请求路由信息用于表示用户请求在软件系统上进行的操作，或者使用的功能。在软件系统上每一个操作或功能都有对应的请求路由信息。

举例说明，以软件系统为OA平台为例，在OA平台上，功能B对应请求路由信息B，OA平台根据请求路由信息B，确定用户请求使用功能B。

其中，策略请求信息用于确定请求的操作所使用的资源。比如，请求的操作为审批请假申请，所使用的资源为请假单。

在本申请的一个可能的实现方式中，gRPC后端服务器根据网络请求生成策略请求信息，可以通过为网络请求定义策略规则，根据策略规则从网络请求中提取策略请求信息。

作为一种示例，以网络请求为请假申请为例，网络申请中包括一个协议(protobufmessage)，该协议为请假单审批数据，具体如下所示：

message LeaveApproval{//请假申请

string leaveID＝1；//请假单的号

bool approvalResults＝2；//请假单的审批结果

}

对于上述protobuf message，gRPC后端服务器需要从中抽取出策略请求，首先为protobuf message定义策略请求规则option，具体如以下代码所示：

其中，为请假申请(LeaveApproval)这个信息(message)定义了一个名为“auth.auth”的策略规则(option)，其中需要定义多个策略(policy)构成的策略数组(policies)。由于该message只需要处理一个维度的资源鉴权，所以只需要一个policy。其中，policy由策略名称(policy_name)的字段和策略要求(policy_request)的字段，两个字段构成，policy_name为当前protobuf message做资源鉴权时选择的是哪种策略(比如，审批规则(approvalRule))，policy_request中策略所需要的一个字段(比如，请假单号(leaveID))。

举例说明，以leaveID＝"1234"为例，即请假单号为1234，用户A对该请假申请进行审批操作，则对用户A的信息和leaveID进行资源归属判断，判断leaveID＝"1234"的请假申请是否在用户A的资源归属之下。

值得说明的是，软件系统中有关系比较复杂的资源归属关系，可能涉及两个或两个以上的字段，所以软件系统中会有不同的策略规则，每个策略规则都有不同的字段要求。

可选的，如果message中的数据需要进行多维度资源鉴权，则可以添加多个policy，在本申请实施例中不做限定。

在本申请实施例中，统一鉴权中心作为一个账户服务器与gRPC后端服务器分开设置。值得说明的是，统一鉴权中心可以在gRPC后端服务器中，也可以是一个单独的服务器不在gRPC后端服务器中，本申请实施例不做限定。

在本申请的一个实施例中，统一鉴权中心身维护角色、资源和账户的关系，在获取到鉴权请求消息后，可以对应维护的关系完成角色鉴权和资源鉴权。

其中，统一鉴权中心维护的角色、资源和账户关系可以是自身维护，也可以是来自其他设备或服务器，比如数据库，在本申请中不做限定。

举例说明，以软件系统为OA平台，用户A为系统维护人员为例，用户A请求维护系统，根据统一鉴权中心维护的关系可知，用户A为系统维护人员，具有维护系统的权限。因此，gRPC后端服务器将用户A的身份信息，请求的维护系统的操作发送至统一鉴权中心后，统一鉴权中心完成角色鉴权，换言之，统一鉴权中心确定用户A有权限进行维护系统的操作。

步骤303、gRPC后端服务器接收来自统一鉴权中心的鉴权结果，鉴权结果用于表示用户是否具有执行操作的权限。

其中，鉴权结果有两种，鉴权结果1表示用户不具有执行操作的权限，鉴权结果2表示用户具有执行操作的权限。

步骤304、gRPC后端服务器根据鉴权结果确定是否执行操作。

其中，gRPC后端服务器根据鉴权结果确定是否执行操作，包括两种情况：

情况1、

在鉴权结果表示用户不具有执行操作的权限的情况下，gRPC后端服务器发送反馈信息。反馈信息用于指示用户不具有执行操作的权限。

举例说明，以软件系统为OA平台为例，用户C为普通人员，用户C通过web客户端发送网络请求，请求进行系统维护，由统一鉴权中心中维护的关系可知普通人员没有权限进行系统维护，因此统一鉴权中心完成鉴权后，反馈鉴权结果为不通过，则gRPC后端服务器发送反馈信息，拒绝用户C的网络请求，并在web客户端显示拒绝的提示信息。

情况2、

在鉴权结果表示用户具有执行操作的权限，gRPC后端服务器执行操作。

作为一种示例，gRPC后端服务器包括业务逻辑层，业务逻辑层用于根据网络请求执行请求的操作。

举例说明，以软件系统为OA平台，用户D为系统维护人员为例，用户D通过web客户端发送网络请求，请求的操作为进行系统维护，由统一鉴权中心中维护的关系可知系统维护人员有权限进行系统维护，因此统一鉴权中心完成鉴权后，反馈鉴权结果为通过，则gRPC后端服务器将网络请求发送至业务逻辑层，由业务逻辑层执行进行系统维护的操作，比如，通过web客户端可以显示出系统维护界面以供用户D进行系统维护。

本申请通过gRPC后端服务器获取网络请求，根据网络请求生成相应的请求身份信息，请求路由信息以及策略请求信息，并将请求身份信息，请求路由信息以及策略请求信息发送至统一鉴权中心，由统一鉴权中心结合请求身份信息和请求路由信息完成角色鉴权，结合请求身份信息和策略请求信息完成资源鉴权，达到角色鉴权和资源鉴权统一，这样，gRPC后端服务器每一个接口中的业务代码中都不再需要进行资源鉴权，使代码简洁明了方便阅读，从而减少了系统的安全漏洞，避免因开发人员的疏忽导致的鉴权漏洞，提升了系统安全性以及开发效率。

在本申请的一个实施例中，在根据网络请求生成请求身份信息、请求路由信息以及策略请求信息之前，本申请实施例提供的方法还包括：gRPC后端服务器确定指示请求的操作需要的资源的源代码。

在一种可能的实现方式中，gRPC后端服务器包括gRPC拦截器，gRPC拦截器用于确定请求的操作需要的资源，换言之，确定策略请求信息的源代码为gRPC拦截器的源代码。

其中，gRPC拦截器还用于确定请求身份信息以及请求路由信息。

在本申请的一个实施例中，gRPC后端服务器确定指示请求的操作需要的资源的源代码，包括：gRPC后端服务器在网络请求中设定策略规则。gRPC后端服务器根据策略规则生成源代码。

在本申请的一个具体的实现方式中，gRPC后端服务器通过中间件生成gRPC拦截器的源代码。参考图4，图4为中间件生成gRPC拦截器源代码的流程图，首先启动中间件protoc-gen-auth，读取protobuf文件，然后对protobuf文件中所有message的策略规则进行自动化分析，并生成对应的源代码编译到gRPC后端服务器。当gRPC后端服务器获取到网络请求之后，会在业务逻辑层执行前自动化执行源代码，通过源代码生成网络请求对应的请求身份信息、请求路由信息以及策略请求信息。

值得说明的是，对于策略要求相对复杂的场景，也只需要相应的逻辑字段，中间件可以生成源代码，不需要在接口中书写复杂的鉴权代码。

举例说明，复杂场景下的策略要求如以下代码所示。

其中，message A中的除了简单的string aa字段，还有B b这种结构体字段，复杂的数组C c字段。

图5为本申请实施例提供的一种系统权限控制装置，如图5所示，装置包括：

第一接收单元501，用于接收来自客户端的网络请求，网络请求用于指示用户的身份以及请求的操作。

发送单元502，用于根据网络请求，向统一鉴权中心发送鉴权请求消息。鉴权请求消息用于请求统一鉴权中心对用户进行角色鉴权以及对用户请求的操作进行资源鉴权。

第二接收单元503，用于接收来自统一鉴权中心的鉴权结果。所述鉴权结果用于表示用户是否具有执行操作的权限。

处理单元504，用于根据鉴权结果确定是否执行操作。

在本申请的一个实施例中，处理单元504，还用于确定指示请求的操作需要的资源的源代码。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各单元的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的单元完成，即将所述装置的内部结构划分成不同的单元，以完成以上描述的全部或者部分功能。实施例中的各单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各单元的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

图6为本申请实施例提供的一种系统权限控制系统，如图6所示，系统包括：web客户端601、gRPC后端服务器602、统一鉴权中心603。

其中，web客户端601用于向gRPC后端服务器602发送网络请求。

其中，gRPC后端服务器602用于根据网络请求，向统一鉴权中心发送鉴权请求消息，鉴权请求消息包括：请求身份信息、请求路由信息以及策略请求信息；以及用于根据统一鉴权中心反馈的鉴权结果，执行或不执行操作。

其中，统一鉴权中心603用于根据鉴权请求消息确定用户是否有执行操作的权限。

在本申请的一个实施例中，如图6所示，系统权限控制系统还可以包括数据库604以及平台管理端605。

其中，数据库604用于存储用户对应的账户以及资源。

其中，平台管理端605用于设置用户对应的账户以及资源。

在本申请的一个实施例中，gRPC后端服务器602包括：服务入口点6021、gRPC拦截器6022以及业务逻辑层6023。

其中，服务入口点6021用于接收网络请求，以及用于向gRPC拦截器6022发送网络请求。

其中，gRPC拦截器6022用于根据网络请求确定请求身份信息、请求路由信息以及策略请求信息，并用于向统一鉴权中心603发送请求身份信息、请求路由信息以及策略请求信息，以及接收来自同一鉴权中心603的鉴权结果。

其中，业务逻辑层6023用于在鉴权结果为通过的情况下，根据网络请求进行业务逻辑处理。

作为一种示例，统一鉴权中心603获取到来自gRPC拦截器6022的请求身份信息、请求路由信息以及策略请求信息，进行角色鉴权和资源鉴权之后，向gRPC拦截器6022发送鉴权结果。在鉴权结果表示用户具有执行操作的权限的情况下，gRPC拦截器6022向业务逻辑层6023发送网络请求，业务逻辑层6023执行请求的操作。在鉴权结果表示用户不具有执行操作的权限的情况下，gRPC拦截器6022向服务入口点6021发送拒绝访问的信息。

在本申请的一个实施例中，在鉴权结果表示用户具有执行操作的权限的情况下，gRPC拦截器6022向业务逻辑层6023发送网络请求，业务逻辑层6023执行请求的操作之后，业务逻辑层6023向数据库604发送资源逻辑关系，用于更新数据库604。

举例说明，以软件系统为OA平台，用户A为普通人员，用户B为用户A的主管为例。在数据库604中，记录用户B为用户A的主管，并有权限审批用户A的申请(比如请假申请、升职申请等)。当用户A向OA平台发送申请成为主管的网络请求时，用户B审批该网络请求并同意用户A的申请，此时用户A和用户B的关系发生变化，用户B不再是用户A的主管，当业务逻辑层2023执行完该操作之后，将用户B和用户A的身份信息发送至数据库604，数据库604更新之前记录的数据，即用户A由普通人员变为主管，用户B不再拥有审批用户A的申请的权限。

本申请实施例还提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行实现如上述系统权限控制方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在移动终端上运行时，使得移动终端执行时实现可实现上述系统权限控制方法实施例中的步骤。

图7为本申请实施例提供的一种电子设备的结构示意图。如图7所示，电子设备701包括：处理器7011、存储器7012以及存储在存储器7012中并可在处理器7011上运行的计算机程序7013，处理器7011执行计算机程序7013时实现上述实施例中的方法中的步骤。

电子设备701可以是一个通用计算机设备或一个专用计算机设备。在具体实现中，电子设备701可以是台式机、便携式电脑、网络服务器、掌上电脑、移动手机、平板电脑、无线终端设备、通信设备或嵌入式设备，本申请实施例不限定电子设备701的类型。本领域技术人员可以理解，图7仅仅是电子设备701的举例，并不构成对电子设备701的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，比如还可以包括输入输出设备、网络接入设备等。

处理器7011可以是中央处理单元(Central Processing Unit，CPU)，处理器7011还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者也可以是任何常规的处理器。

存储器7012在一些实施例中可以是电子设备701的内部存储单元，比如电子设备701的硬盘或内存。存储器7012在另一些实施例中也可以是电子设备701的外部存储设备，比如电子设备701上配备的插接式硬盘、智能存储卡(Smart Media Card，SMC)、安全数字(Secure Digital，SD)卡、闪存卡(Flash Card)等。进一步地，存储器7012还可以既包括电子设备701的内部存储单元也包括外部存储设备。存储器7012用于存储操作系统、应用程序、引导装载程序(Boot Loader)、数据以及其他程序等。存储器7012还可以用于暂时地存储已经输出或者将要输出的数据。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述方法实施例中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，该计算机程序包括计算机程序代码，该计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。该计算机可读介质至少可以包括：能够将计算机程序代码携带到拍照装置/终端设备的任何实体或装置、记录介质、计算机存储器、ROM(Read-Only Memory，只读存储器)、RAM(Random Access Memory，随机存取存储器)、CD-ROM(Compact Disc Read-Only Memory，只读光盘)、磁带、软盘和光数据存储设备等。本申请提到的计算机可读存储介质可以为非易失性存储介质，换句话说，可以是非瞬时性存储介质。

应当理解的是，实现上述实施例的全部或部分步骤可以通过软件、硬件、固件或者其任意结合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。该计算机指令可以存储在上述计算机可读存储介质中。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的实施例中，应该理解到，所揭露的装置/计算机设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/计算机设备实施例仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (10)

1.一种系统权限控制方法，其特征在于，所述方法应用于后端服务器，所述方法包括：

接收来自客户端的网络请求，所述网络请求用于指示用户的身份以及请求的操作；

根据所述网络请求，向统一鉴权中心发送鉴权请求消息，所述鉴权请求消息用于请求所述统一鉴权中心对所述用户进行角色鉴权以及对所述用户请求的操作进行资源鉴权；

接收来自所述统一鉴权中心的鉴权结果，所述鉴权结果用于表示所述用户是否具有执行所述操作的权限；

根据所述鉴权结果确定是否执行所述操作。

2.根据权利要求1所述的方法，其特征在于，所述鉴权请求消息包括：请求身份信息、请求路由信息以及策略请求信息；

所述请求身份信息用于指示所述用户的身份，所述请求路由信息用于指示所述用户请求执行的所述操作，所述资源请求信息用于指示所述用户请求执行的所述操作需要的资源。

3.根据权利要求1所述的方法，其特征在于，所述根据所述鉴权结果确定是否执行所述操作，包括：

在所述鉴权结果表示所述用户不具有执行所述操作的权限的情况下，发送反馈信息，所述反馈信息用于指示所述用户不具有执行所述操作的权限；

在所述鉴权结果表示所述用户具有执行所述操作的权限，执行所述操作。

4.根据权利要求1或2所述的方法，其特征在于，在根据所述网络请求，向统一鉴权中心发送鉴权请求消息之前，所述方法还包括：

确定指示请求的所述操作需要的资源的源代码。

5.根据权利要求4所述的方法，其特征在于，所述确定指示请求的所述操作需要的资源的源代码，包括：

在所述网络请求中设定策略规则；

根据所述策略规则生成所述源代码。

6.一种系统权限控制装置，其特征在于，所述装置包括：

第一接收单元，用于接收来自客户端的网络请求，所述网络请求用于指示用户的身份以及请求的操作；

发送单元，用于根据所述网络请求，向统一鉴权中心发送鉴权请求消息，所述鉴权请求消息用于请求所述统一鉴权中心对所述用户进行角色鉴权以及对所述用户请求的操作进行资源鉴权；

第二接收单元，用于接收来自所述统一鉴权中心的鉴权结果，所述鉴权结果用于表示所述用户是否具有执行所述操作的权限；

处理单元，用于根据所述鉴权结果确定是否执行所述操作。

7.根据权利要求6所述的装置，其特征在于，所述处理单元，还用于确定指示请求的所述操作需要的资源的源代码。

8.一种系统权限控制系统，其特征在于，所述系统包括：客户端、后端服务器、统一鉴权中心；

所述客户端用于向所述后端服务器发送网络请求；

所述后端服务器用于根据所述网络请求，向所述统一鉴权中心发送鉴权请求消息，所述鉴权请求消息包括：请求身份信息、请求路由信息以及策略请求信息，以及用于根据所述统一鉴权中心反馈的鉴权结果，执行或不执行所述操作；

所述统一鉴权中心用于根据所述鉴权请求消息确定所述用户是否有执行所述操作的权限。

9.根据权利要求8所述的系统，其特征在于，所述后端服务器包括：服务器入口点、拦截器以及业务逻辑层；

所述服务器入口点用于接收所述网络请求，以及用于向所述拦截器发送所述网络请求；

所述拦截器用于根据所述网络请求确定请求身份信息、请求路由信息以及策略请求信息，所述拦截器还用于向所述统一鉴权中心发送鉴权请求消息，以及用于接收所述鉴权结果；

所述拦截器还用于在所述鉴权结果表示所述用户不具有执行所述操作的权限的情况下，向所述服务器入口点发送反馈信息，所述反馈信息用于指示所述用户不具有执行所述操作的权限；

所述业务逻辑层用于在所述鉴权结果表示所述用户具有执行所述操作的权限的情况下，根据所述网络请求执行所述操作。

10.一种电子设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至5任一项所述的方法。