CN114745431A - 基于边车技术的无侵入式权限认证方法、***、介质和设备 - Google Patents

Abstract

本申请提供了一种基于边车技术的无侵入式权限认证方法、***、计算机可读存储介质和电子设备。该方法通过部署在边车容器中的反向代理组件执行，所述边车容器与部署有业务组件的业务容器部署于同一容器组中；包括：主动劫持指向所述业务组件的访问请求，并对所述访问请求进行用户合法性验证；响应于所述访问请求通过用户合法性验证，基于预先配置的用户操作权限，对所述访问请求中的操作行为进行鉴权；响应于所述操作行为通过鉴权，以反向代理的方式将所述访问请求转发至所述业务容器。从而在云原生场景下，在反向代理组件中实现业务组件所需要的权限认证能力，再结合边车技术构建基于反向代理组件的统一切面，将权限认证能力与业务组件解耦。

Description

基于边车技术的无侵入式权限认证方法、***、介质和设备

技术领域

本申请涉及云原生技术领域，特别涉及一种基于边车技术的无侵入式权限认证方法、***、计算机可读存储介质和电子设备。

背景技术

在云原生应用开发过程中，许多被不同应用所需要的通用能力的代码需要被重复编写，比如校验会话的时效性、验证用户的合法性、验证用户的操作权限等能力的相关代码在云原生应用的开发过程中需要被反复使用，代码重复性很高。

为了降低代码的重复性，现有技术中，通常采用面向切面编程的编程模式来使用通用能力的代码模块，即将通用能力的代码模块作为一个切面，当某个组件需要使用某项通用能力时，只需要在该组件指定的位置动态地切入对应的切面，即可使该组件具有该项通用能力。比如，Java语言中的spring技术能够以统一的拦截策略来完成一些通用能力的注入，使用通用能力的组件需要重复配置spring的面向切面编程的配置模块，但spring技术对Java语言的依赖性较强，无法适配所有编程语言。使用python语言进行面向切面编程时，需要自行编写***来完成拦截和通用能力的注入，使用通用能力的组件需要重复调用该***的功能，但调用***的功能对组件代码的侵入性较强，无法将组件与***解耦。

可见，现有技术在实现面向切面编程的编程模式时，对编程语言的依赖性较强，与组件的耦合性较高，不能满足云原生场景下对业务代码无侵入，适配所有编程语言的需求。

发明内容

本申请的目的在于提供一种基于边车技术的无侵入式权限认证方法、***、计算机可读存储介质和电子设备，以解决或缓解上述现有技术中存在的问题。

为了实现上述目的，本申请提供如下技术方案：

本申请提供了一种基于边车技术的无侵入式权限认证方法，该方法通过部署在边车容器中的反向代理组件执行，所述边车容器与部署有业务组件的业务容器部署于同一容器组中；所述方法包括：主动劫持指向所述业务组件的访问请求，并对所述访问请求进行用户合法性验证；响应于所述访问请求通过用户合法性验证，基于预先配置的用户操作权限，对所述访问请求中的操作行为进行鉴权；响应于所述操作行为通过鉴权，以反向代理的方式将所述访问请求转发至所述业务容器。

优选的，所述对所述访问请求进行用户合法性验证，包括：验证所述访问请求的令牌是否失效；响应于所述令牌失效，则向所述访问请求的发送端反馈重新登录指令；或者，响应于所述令牌有效，则将所述令牌发送至外部的认证服务器，以对所述访问请求进行用户合法性验证。

优选的，所述响应于所述访问请求通过用户合法性验证，基于预先配置的用户操作权限，对所述访问请求中的操作行为进行鉴权，包括：响应于所述访问请求通过用户合法性验证，基于所述访问请求中包含的用户信息所属的用户组对应的操作权限，对所述操作行为进行操作权限认证。

优选的，所述基于所述访问请求中包含的用户信息所属的用户组对应的操作权限，对所述操作行为进行操作权限认证，包括：将所述访问请求中包含的用户信息和所述操作行为对应的完整API路径地址发送给权限管理模块；所述权限管理模块用于根据所述用户信息查询所属的用户组，以及根据所述操作行为对应的完整API路径地址，确定所述操作行为所需的操作权限，并验证所述操作行为所需的操作权限是否属于所述用户组对应的操作权限。

优选的，还包括：所述权限管理模块还用于对所述访问请求中包含的所述业务组件的访问地址进行验证。

优选的，还包括：所述权限管理模块还用于接收对应于所述业务组件的权限操作请求，并生成对应于所述业务组件的权限配置信息；所述权限配置信息用于定义所述用户组和所述用户组对应的操作权限。

优选的，还包括：所述权限管理模块还用于持久化存储所述权限配置信息，以及将所述权限配置信息导出为可动态加载的权限文件。

本申请实施例还提供一种基于边车技术的无侵入式权限认证***，通过部署在边车容器中的反向代理组件执行，所述边车容器与部署有业务组件的业务容器部署于同一容器组中，所述基于边车技术的无侵入式权限认证***包括：合法性验证单元，配置为主动劫持指向所述业务组件的访问请求，并对所述访问请求进行用户合法性验证；鉴权单元，配置为响应于所述访问请求通过用户合法性验证，基于预先配置的用户操作权限，对所述访问请求中的操作行为进行鉴权；请求转发单元，配置为响应于所述操作行为通过鉴权，以反向代理的方式将所述访问请求转发至所述业务容器。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序为如上任一所述的基于边车技术的无侵入式权限认证方法。

本申请实施例还提供一种电子设备，包括：存储器、处理器、以及存储在所述存储器中并可在所述处理器上运行的程序，所述处理器执行所述程序时实现如上任一所述的基于边车技术的无侵入式权限认证方法。

有益效果：

本申请的技术方案，边车容器与业务容器部署在同一容器组中，业务容器中部署有业务组件，边车容器中部署有反向代理组件；通过反向代理组件执行无侵入式权限认证，具体的，反向代理组件主动劫持指向业务组件的访问请求，并对访问请求进行用户合法性验证；当访问请求通过用户合法性验证时，再基于预先配置的用户操作权限对访问请求中的操作行为进行鉴权；如果访问请求中的操作行为通过鉴权，则以反向代理的方式将访问请求转发至业务容器。

籍此，在云原生场景下，将业务组件所需要用户合法性验证、操作行为鉴权等通用能力在反向代理组件中实现，再结合边车技术构建基于反向代理组件的无侵入式统一切面，切入任意业务组件的业务逻辑，让该切面能够被不同业务组件重复使用，并使得业务组件对通用能力的注入无感知，从而将用户合法性验证、操作行为鉴权等通用能力与业务组件进行解耦，且对编程语言无依赖，能够适配任意编程语言和编程框架。

此外，将用于权限认证的边车容器和业务容器部署在同一容器组中，边车容器和业务容器之间可以通过本地服务器(localhost)直接通信，网络损耗小；应用管理员从用户合法性、操作权限等多个层面对访问请求设置身份验证和鉴权，权限控制精准。

部署在边车容器中的反向代理组件代替部署在业务容器中的业务组件实现了用户合法性验证、操作行为鉴权等通用能力，使得业务组件在设计和开发过程中，无需考虑会话过期、用户合法性、操作权限等权限控制问题。

附图说明

构成本申请的一部分的说明书附图用来提供对本申请的进一步理解，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。其中：

图1为根据本申请的一些实施例提供的一种基于边车技术的无侵入式权限认证方法的流程示意图；

图2为根据本申请的一些实施例提供的一种对业务组件进行权限配置的逻辑示意图；

图3为根据本申请的一些实施例提供的另一种对业务组件进行权限配置的逻辑示意图；

图4为根据本申请的一些实施例提供的一种基于边车技术的无侵入式权限认证方法的逻辑示意图；

图5为根据本申请的一些实施例提供的另一种基于边车技术的无侵入式权限认证方法的逻辑示意图；

图6为根据本申请的一些实施例提供的一种基于边车技术的无侵入式权限认证***的结构示意图；

图7为根据本申请的一些实施例提供的电子设备的结构示意图；

图8为根据本申请的一些实施例提供的电子设备的硬件结构。

具体实施方式

下面将参考附图并结合实施例来详细说明本申请。各个示例通过本申请的解释的方式提供而非限制本申请。实际上，本领域的技术人员将清楚，在不脱离本申请的范围或精神的情况下，可在本申请中进行修改和变型。例如，示为或描述为一个实施例的一部分的特征可用于另一个实施例，以产生又一个实施例。因此，所期望的是，本申请包含归入所附权利要求及其等同物的范围内的此类修改和变型。

基于前述对现有技术的分析，可以知道，现有技术在实现面向切面编程的编程模式时，对编程语言的依赖性较强，与组件的耦合性较高，不能满足云原生场景下对业务代码的无侵入，不能适配所有编程语言的需求。因而，申请人提出了一种基于边车技术的无侵入式权限认证技术，将实现具体业务能力的业务组件部署在业务容器中，在业务容器的同一容器组(Pod)中的边车容器中部署用于权限认证的反向代理组件，使边车容器能够主动劫持业务容器的访问流量，并完成对访问请求的用户身份验证和操作行为的鉴权，之后，将访问流量转发至业务容器中，从而在云原生场景下，将业务组件所需要用户合法性验证、操作行为鉴权等通用能力在反向代理组件中实现，再结合边车技术构建基于反向代理组件的无侵入式统一切面，切入任意业务组件的业务逻辑，让该切面能够被不同业务组件重复使用，并使得业务组件对通用能力的注入无感知，从而将用户合法性验证、操作行为鉴权等通用能力与业务组件进行解耦，且对编程语言无依赖，能够适配任意编程语言和编程框架。

示例性方法

在本申请实施例中，在边车容器中设置反向代理组件，由反向代理组件实现校验会话的时效性、验证用户的合法性、以及验证用户的操作权限等通用能力；反向代理组件在完成通用能力后，将访问流量转发至业务容器中，从而在云原生场景下，基于边车技术实现统一的、业务无感知的权限控制切面，并能够被不同编程语言实现的业务组件无差异地使用。

如图1所示，该基于边车技术的无侵入式权限认证方法包括：

步骤S101、主动劫持指向业务组件的访问请求，并对访问请求进行用户合法性验证。

在本申请实施例中，将实现具体业务能力的业务组件部署在业务容器中，在业务容器所在容器组中动态部署用于权限认证的边车容器，并在边车容器中部署反向代理组件，具体实现对访问请求进行权限认证的功能。

用户通过客户端向业务容器中的业务组件发送访问请求，边车容器具有访问对同一容器组中的其他容器的流量进行主动劫持的能力，因此在本申请实施例中边车容器可以主动劫持访问业务容器的流量(用户的访问请求)，使其进入边车容器中的反向代理组件的服务端口，由反向代理组件对业务请求进行用户合法性验证。

在一些可选实施例中，对访问请求进行用户合法性验证包括：验证访问请求的令牌是否失效；响应于令牌失效，则向访问请求的发送端反馈重新登录指令；或者，响应于令牌有效，则将令牌发送至外部的认证服务器，以对访问请求进行用户合法性验证。

需要说明的是，在令牌机制出现之前，客户端每次请求访问服务端，服务端都需要查询用户身份信息数据库，来对访问请求中的用户名和密码进行比对，判定用户名和密码是否正确，当客户端频繁向服务端发送访问请求时，服务端的压力很大。而令牌(token)是认证服务器生成的一串字符串，作为客户端进行访问请求的一个临时令牌，用于代替用户名和密码进行用户合法性认证，以减少查询用户身份信息数据库的频次，从而减轻认证服务器的压力。

具体的，反向代理组件首先验证客户端发出的访问请求中的令牌是否有效(比如，令牌是否过期)，如果令牌失效(比如，令牌过期)，则向客户端(访问请求的发送端)反馈指令，以指示客户端跳转至登录页面，要求用户重新登录；用户在客户端使用用户名和密码进行登录时，客户端会将用户名和密码发送至外部的认证服务器进行用户合法性认证，如果合法性认证通过，则创建令牌并将令牌返回给客户端进行存储，用户下次使用客户端发送访问请求时会优先使用客户端中存储的令牌进行合法性认证，即将令牌与访问请求一并发出；如果访问请求中的令牌没有失效(比如，令牌未过期)，则访问外部的认证服务器验证用户的合法性，即判定用户是不是***的有效用户。如果合法性认证通过，则认证服务器将对令牌的累计存活时长进行重置，当累计存活时长达到该令牌的过期时长，该令牌将过期。

需要特别说明的是，为了让反向代理组件实现对令牌是否过期的验证，本申请实施例中在认证服务器创建令牌并将令牌返回给客户端时，在反向代理组件中对令牌进行存储，以及对该令牌对应的反馈信息的反馈时刻进行记录，从而计算出该令牌的过期时刻，对该令牌是否过期进行验证。如果访问请求使用未过期的令牌进行用户合法性认证，则需要由外部的认证服务器进一步进行用户合法性验证，从而将一部分使用过期令牌的访问请求在反向代理组件中进行了拦截，以减轻认证服务器的压力。

基于前述说明可知，导致令牌失效的原因有多种，第一种可能的原因是，令牌作为一种临时的用户合法性认证工具，本身具有时效性，即存储在认证服务器中的令牌超过预设时间没有进行刷新，则该令牌自然失效。第二种可能的原因是，令牌作为一种用户名和密码的替代工具，本身和密码具有极强的关联关系，一旦用户修改了用户名对应的密码，则认证服务器将创建新的令牌，原先存储的令牌自然失效。第三种可能的原因是，客户端对本地存储的令牌进行了清除，则用户在使用客户端时只能重新登录，并将用户名和密码发送给认证服务器进行用户合法性认证，认证服务器将创建新的令牌，原先存储的令牌自然失效。

在本申请实施例中，认证服务器通过验证令牌是否有效来对访问请求进行合法性验证。其中，令牌是在外部的认证服务器中创建、存储并发送至客户端；每次用户使用客户端进行用户合法性认证时，认证服务器都会相应的创建(使用用户名和密码进行用户合法性)或者刷新(使用令牌进行用户合法性)令牌；如果令牌在认证服务器中存在，则认证服务器通过用户合法性验证。

需要说明的是，即便访问请求的令牌通过了反向代理组件的验证，并不代表该访问请求一定能通过用户合法性认证，一是由于反向代理组件部署在业务容器同一容器组下的边车容器中，容易受到恶意篡改，可靠性不如外部的认证服务器高，二是由于反向代理组件对令牌是否过期的验证并不能确保用户合法性验证，可能存在令牌未过期，但不合法的情况，比如用户使用另一台客户端访问外部的认证服务器进行了密码修改，使得外部的认证服务器创建了新的令牌，而对于本客户端和反向代理组件，仍存储着原先的令牌，并使用原先的令牌发送访问请求，原先的令牌仍能够通过反向代理组件的验证，但却无法通过外部的认证服务器的用户合法性认证。

步骤S102、响应于访问请求通过用户合法性验证，基于预先配置的用户操作权限，对访问请求中的操作行为进行鉴权。

在本申请实施例中，反向代理组件可以通过将令牌发送至外部的认证服务器，对访问请求进行合法性验证，判定用户是否合法；也可以通过用户名、密码方式在客户端登录，通过外部的认证服务器进行合法性验证，用户登录时的用户名、密码与认证服务器中预先存储的账号信息匹配成功，则判定用户为合法用户。如果判定用户不合法，则向客户端反馈用户合法性验证失败的信息，如果判定用户合法，则对访问请求中的操作行为进行鉴权，即验证用户的操作行为是否被授权。

需要说明的是，外部的认证服务器中存储的账号信息可以以明文的方式进行存储，也可以是以密文的方式进行存储，还可以只存储账号信息对应的哈希值，本申请实施例对此不做限定。

具体的，响应于访问请求通过用户合法性验证，基于访问请求中包含的用户信息所属的用户组对应的操作权限，对操作行为进行操作权限认证。进一步的，将访问请求中包含的用户信息和操作行为对应的完整API路径地址发送给权限管理模块；权限管理模块根据用户信息查询所属的用户组，并根据操作行为对应的完整API路径地址，确定操作行为所需的操作权限，然后，验证操作行为所需的操作权限是否属于用户组对应的操作权限。

在本申请实施例中，反向代理组件将用户的信息和操作行为对应的完整API路径地址发送给权限管理模块的权限中心，权限中心通过解析收到的完整API路径地址确定用户的操作行为，并在权限数据库中查询发出访问请求的用户对应的用户组，根据用户对应的用户组被授权的操作行为，验证用户的操作行为是否合法，即验证用户的操作行为所需的操作权限是否属于用户组对应的操作权限。

需要说明的是，可以由应用管理员创建与业务组件相关的用户组，并将创建的用户角色加入创建的用户组中，从而使用户角色获取用户组所具有的对业务组件的操作权限。应用管理员通过将业务组件的操作权限按照用户组进行配置，实现对用户组中的用户角色的操作权限的配置，进而，有效防止用户篡权行为的发生。在此，应用管理员还可以通过修改(比如，删除)用户组中的用户角色，将访问业务组件的用户角色移出相应的用户组，从而实现对用户角色的操作权限的限制。

在一具体的例子中，权限管理模块除了验证操作行为所需的操作权限是否属于用户组对应的操作权限外，还对访问请求中包含的业务组件的访问地址进行验证。具体的，由权限中心将业务组件的访问地址与权限中心的配置进行验证，以实现用户的操作行为和操作行为对应的访问地址的一致性检查。

需要说明的是，权限中心预先配置了业务组件的访问地址，如果访问请求中包含的业务组件的访问地址与权限中心的配置不吻合，那么该访问请求中的操作行为就可能对其他业务组件进行操作，导致篡权行为的发生。

在另一具体的例子中，权限管理模块还用于接收对应于业务组件的权限操作请求，并生成对应于业务组件的权限配置信息。其中，权限配置信息用于定义用户组和用户组对应的操作权限。

如图2所示，权限管理模块部署在集群中，具体可以是一种基于角色的访问控制权限模型(Role-Based Access Control，简称RBAC)的权限管理微服务组件，应用管理员在权限管理模块中配置业务组件的权限配置。具体的，应用管理员通过管理员操作界面向权限管理模块发送权限操作请求，权限管理模块对权限操作请求进行处理，生成业务组件的权限配置信息。

如图3所示，应用管理员除了可以通过管理员操作界面直接向权限管理模块发送权限操作请求外，还可以在集群的API网关中设置权限管理API，应用管理员通过管理员操作界面发出的权限操作请求通过API网关中的权限管理API转发至权限管理模块，由权限管理模块对权限操作请求进行处理，生成业务组件的权限配置信息。

在另一具体的例子中，权限管理模块还用于持久化存储权限配置信息，以及将权限配置信息导出为可动态加载的权限文件。具体的，权限管理模块通过对权限操作请求进行处理，生成业务组件的权限配置信息，并持久化存储在权限管理模块的权限数据库中；在权限管理模块中持久化存储的权限配置信息可以导出为可动态加载的权限文件，以便在部署新的业务组件时，通过将权限文件导入新的业务组件对应的权限数据库中，对新的业务组件的权限进行配置。

以Kubernetes集群为例，在一应用场景中，为了便于在多个Kubernetes集群上进行权限配置，应用管理员可以在某个Kubernetes集群上的业务组件的权限能力配置完成后，将业务组件的权限配置信息导出为可动态加载的权限文件。当应用管理员在把该业务组件部署至另一个Kubernetes集群上时，只需要将该业务组件对应的权限文件导入该Kubernetes集群的权限管理模块的权限数据库中，即可实现对该Kubernetes集群上的业务组件的权限能力进行配置。

在另一应用场景中，当应用管理员要将业务组件部署在另一个Kubernetes集群上时，通过管理员操作界面将可动态加载的权限文件导入权限管理模块的权限数据库中，实现对该Kubernetes集群上的业务组件的权限能力进行配置。

此外，在业务组件运行过程中，应用管理员还可以通过管理员操作界面对业务组件的权限能力进行修改，比如，修改某个用户角色所属的用户组，或者，为某个用户组绑定新的操作权限，或者，将某个用户组的操作权限删除。

步骤S103、响应于操作行为通过鉴权，以反向代理的方式将访问请求转发至业务容器。

在本申请实施例中，反向代理组件通过访问外部的认证服务器对访问请求中的操作行为进行鉴权，如果访问请求中的操作行为未被授权，则向客户端反馈操作行为越权的信息；如果访问请求中的操作行为被授权，则反向代理组件将以反向代理的方式将访问请求转发至业务容器，由部署在业务容器中的业务组件对访问请求进行响应，并通过边车容器将结果反馈给客户端。

在一具体场景中，如图4所示，用户通过客户端直接向业务组件发送访问请求，边车容器主动劫持访问请求并完成用户合法性验证和操作行为鉴权后，将访问请求转发至业务组件，由业务组件对访问请求进行响应，并通过边车容器将结果直接反馈给客户端。

在另一具体场景中，如图5所示，在集群中设置API网关，用户通过客户端向集群的API网关发送访问业务组件的访问请求，API网关将访问请求转发至业务组件时，边车容器主动劫持访问请求并完成用户合法性验证和操作行为鉴权后，再将访问请求发送至业务组件，由业务组件对访问请求进行响应，并依次通过边车容器、API网关将结果直接反馈给客户端。

本申请实施例中，在边车容器中完成业务组件所需的访问请求的身份验证和鉴权，通过localhost直接将访问请求发送给业务容器，由业务容器进行响应并将结果反馈给客户端，籍此，将边车技术和权限认证技术相结合，构建基于反向代理组件的无侵入式统一切面，切入任意业务组件的业务逻辑，使该切面能够被不同类型的业务组件作为可以按需***的权限认证切面进行使用，整个过程业务代码无侵入，权限认证功能和业务组件相解耦，能够适用于任意的编程语言和编程框架。

示例性***

如图6所示，该基于边车技术的无侵入式权限认证，通过部署在边车容器中的反向代理组件执行，所述边车容器与部署有业务组件的业务容器部署于同一容器组中，基于边车技术的无侵入式权限认证***包括：合法性验证单元601、鉴权单元602和请求转发单元603。

合法性验证单元601配置为主动劫持指向业务组件的访问请求，并对访问请求进行用户合法性验证；鉴权单元602，配置为响应于访问请求通过用户合法性验证，基于预先配置的用户操作权限，对访问请求中的操作行为进行鉴权；请求转发单元603配置为响应于操作行为通过鉴权，以反向代理的方式将访问请求转发至业务容器。

本申请实施例提供的基于边车技术的无侵入式权限认证***能够实现上述任一基于边车技术的无侵入式权限认证方法的步骤、流程，并达到相同的技术效果，在此不再一一赘述。

示例性设备

图7为根据本申请的一些实施例提供的电子设备的结构示意图；如图7所示，该电子设备包括：

一个或多个处理器701；

计算机可读介质，可以配置为存储一个或多个程序702，一个或多个处理器701执行一个或多个程序702时，实现如下步骤：主动劫持指向业务组件的访问请求，并对访问请求进行用户合法性验证；响应于访问请求通过用户合法性验证，基于预先配置的用户操作权限，对访问请求中的操作行为进行鉴权；响应于操作行为通过鉴权，以反向代理的方式将访问请求转发至业务容器。

图8为根据本申请的一些实施例提供的电子设备的硬件结构；如图8所示，该电子设备的硬件结构可以包括：处理器801、通信接口802、计算机可读介质803和通信总线804。

其中，处理器801、通信接口802、计算机可读存储介质803通过通信总线804完成相互间的通信。

可选地，通信接口802可以为通信模块的接口，如GSM模块的接口。

其中，处理器801具体可以配置为：主动劫持指向业务组件的访问请求，并对访问请求进行用户合法性验证；响应于访问请求通过用户合法性验证，基于预先配置的用户操作权限，对访问请求中的操作行为进行鉴权；响应于操作行为通过鉴权，以反向代理的方式将访问请求转发至业务容器。

处理器801可以是通用处理器，包括中央处理器(central processing unit，简称CPU)、网络处理器(Network Processor，简称NP)等，还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

本申请实施例的电子设备以多种形式存在，包括但不限于：

(1)移动通信设备：这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括：智能手机(例如：iPhone)、多媒体手机、功能性手机，以及低端手机等。

(2)超移动个人计算机设备：这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括：PDA、MID和UMPC设备等，例如iPad。

(3)便携式娱乐设备：这类设备可以显示和播放多媒体内容。该类设备包括：音频、视频播放器(例如：iPod)，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。

(4)服务器：提供计算服务的设备，服务器的构成包括处理器、硬盘、内存、***总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。

(5)其它具有数据交互功能的电子装置。

需要指出，根据实施的需要，可将本申请实施例中描述的各个部件/步骤拆分为更多部件/步骤，也可以将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤，以实现本申请实施例的目的。

上述根据本申请实施例的方法可在硬件、固件中实现，或者被实现为可存储在记录介质(诸如CD ROM、RAM、软盘、硬盘或磁光盘)中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器存储介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如ASIC或FPGA)的记录介质上的这样的软件处理。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如，RAM、ROM、闪存等)，当软件或计算机代码被计算机、处理器或硬件访问且执行时，实现在此描述的基于边车技术的无侵入式权限认证方法。此外，当通用计算机访问用于实现在此示出的方法的代码时，代码的执行将通用计算机转换为用于执行在此示出的方法的专用计算机。

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

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其它实施例的不同之处。尤其，对于设备及***实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。

以上所描述得设备及***实施例仅仅是示意性的，其中作为分离不见说明的单元可以使或者也可以不是物理上分开的，作为单元提示的不见可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅为本申请的优选实施例，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种基于边车技术的无侵入式权限认证方法，其特征在于，通过部署在边车容器中的反向代理组件执行，所述边车容器与部署有业务组件的业务容器部署于同一容器组中；所述方法包括：

主动劫持指向所述业务组件的访问请求，并对所述访问请求进行用户合法性验证；

响应于所述访问请求通过用户合法性验证，基于预先配置的用户操作权限，对所述访问请求中的操作行为进行鉴权；

响应于所述操作行为通过鉴权，以反向代理的方式将所述访问请求转发至所述业务容器。

2.根据权利要求1所述的基于边车技术的无侵入式权限认证方法，其特征在于，所述对所述访问请求进行用户合法性验证，包括：

验证所述访问请求的令牌是否失效；

响应于所述令牌失效，则向所述访问请求的发送端反馈重新登录指令；

或者；

响应于所述令牌有效，则将所述令牌发送至外部的认证服务器，以对所述访问请求进行用户合法性验证。

3.根据权利要求1所述的基于边车技术的无侵入式权限认证方法，其特征在于，所述响应于所述访问请求通过用户合法性验证，基于预先配置的用户操作权限，对所述访问请求中的操作行为进行鉴权，包括：

响应于所述访问请求通过用户合法性验证，基于所述访问请求中包含的用户信息所属的用户组对应的操作权限，对所述操作行为进行操作权限认证。

4.根据权利要求3所述的基于边车技术的无侵入式权限认证方法，其特征在于，所述基于所述访问请求中包含的用户信息所属的用户组对应的操作权限，对所述操作行为进行操作权限认证，包括：

将所述访问请求中包含的用户信息和所述操作行为对应的完整API路径地址发送给权限管理模块；所述权限管理模块用于根据所述用户信息查询所属的用户组，以及根据所述操作行为对应的完整API路径地址，确定所述操作行为所需的操作权限，并验证所述操作行为所需的操作权限是否属于所述用户组对应的操作权限。

5.根据权利要求4所述的基于边车技术的无侵入式权限认证方法，其特征在于，还包括：

所述权限管理模块还用于对所述访问请求中包含的所述业务组件的访问地址进行验证。

6.根据权利要求4或5中任一项所述的基于边车技术的无侵入式权限认证方法，其特征在于，还包括：

所述权限管理模块还用于接收对应于所述业务组件的权限操作请求，并生成对应于所述业务组件的权限配置信息；所述权限配置信息用于定义所述用户组和所述用户组对应的操作权限。

7.根据权利要求6所述的基于边车技术的无侵入式权限认证方法，其特征在于，还包括：

所述权限管理模块还用于持久化存储所述权限配置信息，以及将所述权限配置信息导出为可动态加载的权限文件。

8.一种基于边车技术的无侵入式权限认证***，其特征在于，通过部署在边车容器中的反向代理组件执行，所述边车容器与部署有业务组件的业务容器部署于同一容器组中，所述基于边车技术的无侵入式权限认证***包括：

合法性验证单元，配置为主动劫持指向所述业务组件的访问请求，并对所述访问请求进行用户合法性验证；

鉴权单元，配置为响应于所述访问请求通过用户合法性验证，基于预先配置的用户操作权限，对所述访问请求中的操作行为进行鉴权；

请求转发单元，配置为响应于所述操作行为通过鉴权，以反向代理的方式将所述访问请求转发至所述业务容器。

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序为如权利要求1-7任一所述的基于边车技术的无侵入式权限认证方法。

10.一种电子设备，其特征在于，包括：存储器、处理器、以及存储在所述存储器中并可在所述处理器上运行的程序，所述处理器执行所述程序时实现如权利要求1-7任一所述的基于边车技术的无侵入式权限认证方法。

Images