CN110225039A

CN110225039A - 权限模型获取、鉴权方法、网关、服务器以及存储介质

Info

Publication number: CN110225039A
Application number: CN201910515749.2A
Authority: CN
Inventors: 洪平华; 樊天; 张跃泷
Original assignee: Wuxi Huayun Data Technology Service Co Ltd
Current assignee: Wuxi Huayun Data Technology Service Co Ltd
Priority date: 2019-06-14
Filing date: 2019-06-14
Publication date: 2019-09-10
Anticipated expiration: 2039-06-14
Also published as: CN110225039B

Abstract

本申请公开了权限模型获取、鉴权方法、网关、服务器以及存储介质，API网关包括至少一个参数分别对应的权限名称；若API请求携带的第一参数对应目标权限名称，将目标权限名称发送至鉴权服务器。鉴权服务器是基于目标权限名称获得权限模型，不是基于URL获得权限模型，因此在构建权限模型时，无需考虑是针对哪个URL即API请求的；API网关可以基于API请求中携带的参数确定其待验证的权限模型的权限名称，若同一类型的API请求携带的参数不同，其对应的权限模型的权限名称可能不同，即一个类型的API请求可能对应多个权限模型；不同类型或同一类型API请求携带的参数不同，对应的权限名称可能相同，在构建API请求时，无需必须构建与之对应的权限模型，使得两者解耦合。

Description

权限模型获取、鉴权方法、网关、服务器以及存储介质

技术领域

本申请涉及计算机技术领域，更具体的说，是涉及一种权限模型获取、鉴权方法、网关、服务器以及存储介质。

背景技术

API(Application Programming Interface，应用程序编程接口)网关是客户端利用API请求访问一个或多个服务器中存储的各服务方提供的服务对象的统一入口。API网关是将各服务方提供的服务对象聚合起来，所有要调用这些服务对象的客户端都需要通过API网关进行访问。基于这种方式API网关可以对API请求进行统一管控，例如，对API请求进行鉴权。

目前，API网关对API请求进行鉴权的过程如图1所示。API网关12接收到终端11发送的待鉴权的API请求后，从API请求中获取待访问服务对象对应的URL(Uniform ResourceLocator，统一资源定位符)以及用户标识，并将URL以及用户标识发送至鉴权服务器13；参见图1，鉴权服务器13中包括多个权限模型，每一权限模型包括：URL以及权限信息；鉴权服务器13基于接收到URL确定与待鉴权的API请求对应的目标权限模型，并基于接收到的用户标识，以及确定的目标权限模型进行鉴权。若鉴权通过后，API网关12可将API请求发送至存储有相应服务对象的后端服务器14中，后端服务器14基于API请求执行相应的响应操作。

综上，一个权限模型对应一种权限信息，若权限信息发生变化，则需要建立新的权限模型，同理需要建立与新的权限模型对应的API请求，即权限模型与API请求是强耦合的，一对一的关系。

发明内容

有鉴于此，本申请提供了一种权限模型获取、鉴权方法、网关、服务器以及存储介质，以解决现有技术中权限模型与API请求是强耦合的，一对一对应的关系。

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

第一方面，一种权限模型获取方法，应用于应用程序编程接口API网关，包括：

获取API请求，所述API请求至少携带有第一参数，所述第一参数包括用户标识和第一上下文信息中的至少一种；

从预先构建的至少一个参数分别对应的权限名称中，获取与所述第一参数对应的目标权限名称；

至少将所述目标权限名称发送至鉴权服务器，所述目标权限名称是所述鉴权服务器获得用于验证所述API请求的权限模型的依据；

其中，不同权限名称对应不同的权限模型。

第二方面，一种鉴权方法，应用于鉴权服务器，包括：

获取应用程序编程接口API网关发送的目标权限名称；

其中，所述目标权限名称是所述API网关确定的与第一参数对应的权限名称，所述第一参数是待鉴权的API请求中携带的用户标识和第一上下文信息中的至少一种；

从多个权限模型中，获得所述目标权限名称对应的目标权限模型；

基于所述目标权限模型，对所述API请求进行鉴权。

第三方面，一种应用程序编程接口API网关，包括：

第一获取模块，用于获取API请求，所述API请求至少携带有第一参数，所述第一参数包括用户标识和第一上下文信息中的至少一种；

第二获取模块，用于从预先构建的至少一个参数分别对应的权限名称中，获取与所述第一参数对应的目标权限名称；

发送模块，用于至少将所述目标权限名称发送至鉴权服务器，所述目标权限名称是所述鉴权服务器获得用于验证所述API请求的权限模型的依据；

其中，不同权限名称对应不同的权限模型。

第四方面，一种鉴权服务器，包括：

第三获取模块，用于获取应用程序编程接口API网关发送的目标权限名称；

第四获取模块，用于从多个权限模型中，获得所述目标权限名称对应的目标权限模型；

鉴权模块，用于基于所述目标权限模型，对所述API请求进行鉴权。

第五方面，一种应用程序编程接口API网关，包括：

存储器，用于存储程序；

处理器，用于执行所述程序，所述程序具体用于：

其中，不同权限名称对应不同的权限模型。

第六方面，一种鉴权服务器，包括：

存储器，用于存储程序；

处理器，用于执行所述程序，所述程序具体用于：

获取应用程序编程接口API网关发送的目标权限名称；

基于所述目标权限模型，对所述API请求进行鉴权。

第七方面，一种可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，实现如上述任一项所述的权限模型获取方法包含的各个步骤。

第八方面，一种可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，实现如上述任一项所述的鉴权方法包含的各个步骤。

经由上述的技术方案可知，本申请提供了一种应用于API网关的权限模型获取方法，在API网关中预先构建了至少一个参数分别对应的权限名称；若当前API请求携带的第一参数对应目标权限名称，则至少将目标权限名称发送至鉴权服务器，目标权限名称是鉴权服务器获得用于验证该API请求的权限模型的依据。鉴权服务器是基于目标权限名称获得权限模型，而不是基于URL获得权限模型，因此在构建权限模型时，不需要考虑其是针对哪个URL即API请求的。API网关可以基于API请求中携带的参数确定其待验证的权限模型的权限名称，若同一类型中不同API请求携带的参数不同，其对应的权限模型的权限名称可能不同，即一个类型的API请求可能对应多个权限模型；不同类型或同一类型的API请求携带的参数不同，对应的权限名称可能相同，即在构建API请求时，也无需必须构建与之对应的权限模型。综上，API请求与权限模型不是一一对应的，使得权限模型与API请求解耦合。

附图说明

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

图1为现有技术API网关对API请求进行鉴权的过程示意图；

图2为由终端、API网关、鉴权服务器以及后端服务器所构成的硬件环境示意图；

图3为本申请实施例公开的一种应用于应用程序编程接口API网关的权限模型获取方法流程图；

图4为本申请实施例公开的一种应用于鉴权服务器的鉴权方法流程图；

图5为本申请实施例公开的API网关的一种实现方式的结构示意图；

图6为本申请实施例公开的鉴权服务器的一种实现方式的结构示意图；

图7为本申请实施例公开的一种API网关的设备硬件结构框图；

图8为本申请实施例公开的一种鉴权服务器的设备硬件结构框图。

具体实施方式

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

本申请公开了一种权限模型获取方法、API网关和可读存储介质，以及鉴权方法、鉴权服务器和可读存储介质。

上述权限模型获取方法可以应用于API网关。上述鉴权方法可以应用于鉴权服务器。

上述鉴权服务器可以是一台服务器，也可以是由若干台服务器组成的服务器集群，或者是一个云计算服务中心。

在一可选实施例中，上述权限模型获取方法以及鉴权方法可以应用于图2所示的由终端11、API网关12、鉴权服务器13以及后端服务器14所构成的硬件环境中。

终端11可以是诸如台式机、移动终端(例如智能手机)、ipad等电子设备。

用户可以在终端11上进行操作；终端11可以基于用户的操作行为生成待鉴权的API请求，并将其发送至API网关12。

上述API请求可以携带有参数，例如用户标识、上下文信息、URL等。本申请实施例中，不同API请求携带的参数可能不同，例如，用于更新主机信息的API请求携带的参数可以包括主机标识以及要更改的信息；用于审批程序的API请求携带的参数可以包括申请人信息以及申请的内容等。

API网关12可以基于终端11发送的待鉴权的API请求，得到与该待鉴权的API请求对应的目标权限名称，并将目标权限名称发送至鉴权服务器13。这里，目标权限名称为鉴权服务器13获得用于验证API请求的权限模型的依据，并且不同权限名称对应不同的权限模型。

可选的，可以在鉴权服务器13上或独立于鉴权服务器13设置数据库15。数据库15用于存储权限模型。这里，鉴权服务器13可以从数据库15存储或读取权限模型中的数据。

本申请中一个权限模型至少可以包括：权限名称以及与权限名称对应的权限信息。需要说明的是，本申请中权限模型为至少包含权限名称与权限信息对应关系的模型。可选的，权限模型的实现形式可以包括以下至少一种：表格、函数、结构体以及数据结构。本申请实施例不对权限信息的具体内容进行限定，例如权限信息可以是访问权限、控制权限、操作权限、增加权限、删除权限等。

在一可选实施例中，上述权限模型还可以包括上下文信息，该上下文信息是指针对待操作对象的待操作内容，例如要对主机进行开机操作，则主机即为待操作对象，开机为待操作内容。

目前的鉴权服务器13中的权限模型可以包括URL、上下文信息(可选)以及权限信息。其中，上下文信息(可选)是指，权限模型可以包括上下信息，也可以不包括上下文信息。鉴权服务器13可以基于API请求携带的URL查找对应的权限模型，因此权限模型与API请求一一对应，即必须有相同的URL。而本申请鉴权服务器13可以基于权限名称查找对应的权限模型。由于API请求可以携带参数，不同的参数对应的权限名称可能相同，可能不同，具体根据实际情况而定，即不同类型或同一类型的API请求携带的不同参数对应的权限名称可能相同，可能不同，也就是一个API请求可能与其他API请求共用一个权限模型，即API请求与权限模型并不是一一对应的，即构建一个API请求后，并不一定必须构建相应的权限模型。若同一类型的多个API请求携带的参数不同，那么对应的权限名称可能不同，也就是一个类型的API请求可能对应多个权限模型，即构建一个权限模型后，并不一定必须构建相应类型的API请求，即API请求与权限模型不再必须是一一对应的关系，API请求与权限模型完全解耦合。

在一可选实施例中，本申请的鉴权服务器13中的权限模型可以包括：权限名称、上下文信息以及权限信息。鉴权服务器13基于接收到的目标权限名称，确定目标权限模型，若目标权限模型包含的上下文信息与API请求携带的上下文信息相同，则从目标权限模型中获得目标权限名称对应的权限信息，鉴权服务器13基于API请求携带的用户标识确定该用户标识对应的用户角色，并确定该用户角色对应的权限信息，若用户标识对应的权限信息与目标权限模型中目标权限名称对应的权限信息相同，则确定鉴权成功，否则鉴权失败。鉴权服务器13还可以将鉴权成功的信息发送至API网关12，由API网关12将API请求发送至存储有相应服务对象的后端服务器14中。

在一可选实施例中，本申请的鉴权服务器13中的权限模型可以包括权限名称以及与权限名称对应的权限信息，不包括上下文信息。但是需要维护上下文信息与权限模型的对应关系，本申请实施例提供但不限于以下维护方式，如表1所示的表格，利用表格维护权限模型(例如权限名称)与上下文信息的对应关系。例如表1所示的权限名称与上下文信息的对应关系。

表1权限名称与上下文信息的对应关系

权限名称	上下文信息
		开机	针对主机1进行开机操作
开机	针对主机1以及主机2进行开机操作
		关机	针对主机1进行关机操作
修改	要修改的主机1的内容
		升级	针对主机2进行升级操作
升级	针对主机3进行升级操作

如表1所示，可选的，可以在权限模型之外设置至少一个表格，若权限名称与上下文信息的对应关系改变，无需改变权限模型，仅需要变更上下文信息与权限模型的对应关系即可，从而使得权限模型更为简单。例如，若针对主机4进行开机操作也需要进行权限验证，则仅需将表1所示的表格增加一行(例如底色为灰色的一行)变为表2即可，无需更改权限名称“开机”对应的权限模型。

表2权限名称与上下文信息的对应关系

当然，上述表格仅为一种可选的示例，除此之外还可以通过其他方式实现维护权限名称与上下文信息的对应关系的目的，例如设置函数关系等。

若本申请的鉴权服务器13中的权限模型包括权限名称以及与权限名称对应的权限信息，不包括上下文信息，那么鉴权服务器13接收到目标权限名称、上下文信息和用户标识后，可以基于目标权限名称获得目标权限模型，基于权限名称与上下文信息的对应关系，获得目标权限名称对应的目标上下文信息，若目标上下文信息包括鉴权服务器13接收到的上下文信息，则从目标权限模型中获取目标权限名称对应的目标权限信息；获取用户标识对应的用户角色，获取用户角色对应的权限信息，若用户角色对应的权限信息与目标权限名称对应的目标权限信息相同，则确定鉴权成功，否则鉴权失败。

在一可选实施例中，本申请提及的同一类型的API请求至少携带有相同的URL。

下面结合图3，对上述本申请提及的权限模型的获取方法进行说明。参见图3，为本申请公开的一种应用于API网关的权限模型获取方法流程图，该方法可以包括：

步骤S300、获取API请求，所述API请求至少携带有第一参数，所述第一参数包括用户标识和第一上下文信息中的至少一种。

在一可选实施例中，本申请中的上下文信息是指针对待操作对象的待操作内容，例如要对主机进行开机操作，则主机即为待操作对象，开机为待操作内容。

上述用户标识为用于操作待操作对象的用户的标识，例如，待操作对象为主机，操作主机的用户可以为用户A、用户B、用户C等等。可以理解的是，不同用户对应的用户标识不同。

需要说明的是，上述第一参数中的“第一”仅用于区分不同的参数，并非限定参数的先后顺序；上述第一上下文信息中的“第一”仅用于区分不同的上下文信息，并非限定上下文信息的先后顺序。同理，下述本申请实施例即将提及的第二参数以及第二上下文信息中的“第二”，以及第三参数中的“第三”也仅用于区分，而非限定参数以及上下文信息的先后顺序。

步骤S310、从预先构建的至少一个参数分别对应的权限名称中，获取与所述第一参数对应的目标权限名称。

目前是基于API请求携带的URL确定权限模型，并基于确定的权限模型进行鉴权，导致API请求与权限模型必须具有相同的URL，即API请求必须与权限模型一一对应。可以理解的是，若针对同一待操作对象具有不同的鉴权需求，例如，针对主机A是否具有开机权限的鉴权需求，针对主机A是否具有升级权限的鉴权需求，由于是两种不同的鉴权需求，那么需要两个权限模型，需要两个相应的API请求，即针对主机A进行开机鉴权的权限模型A包含URL A，针对主机A进行升级鉴权的权限模型B包括URL B，则权限模型A对应的API请求需要携带URL A，权限模型B对应的API请求需要携带URL B，由于针对同一待操作对象有不同鉴权需求时，需要构建具有不同URL的API请求，使得构建的API请求较多，从而不利于API请求的管理。

可以理解的是，若对同一待操作对象具有不同的鉴权需求，API请求携带的参数应该不同，基于此，预先构建至少一个参数分别对应的权限名称，可选的，针对同一待操作对象有不同鉴权需求时，可以构建具有相同URL的API请求，仅仅修改其携带的参数即可，从而可以对同一待操作对象对应的API请求进行统一管理，例如，针对同一待操作对象的API请求，至少具有相同的URL。

本申请设置的权限名称为API请求与权限模型的中间过渡，使得API请求与权限模型可以不必一一对应。

可选的，API请求携带的参数与权限名称可以一一对应，则不同参数对应的权限名称可以不同，例如，参数1对应权限名称1，参数2对应权限名称2，参数3对应权限名称3。这样携带的参数不同的API请求不能共用同一权限模型。

可选的，API请求携带的参数与权限名称可以不必一一对应，则不同的参数可以对应同一个权限名称。需要说明的是，即使API请求携带的参数与权限名称不是一一对应，仍需使得一个参数仅对应一个权限名称。例如，参数1对应权限名称1，参数2对应权限名称1，参数3对应权限名称2。这样携带的参数不同的API请求可能共用同一权限模型。

本步骤还可以基于上述API请求携带的第一参数，从上述对应关系中确定第一参数对应的目标权限名称。这里，目标权限名称是指一个具体的API请求所携带的第一参数对应的权限名称。本申请实施例中，上述具体的API请求即为上述本申请提及的终端11发送至API网关12的待鉴权的API请求。

步骤S320、至少将所述目标权限名称发送至鉴权服务器，所述目标权限名称是所述鉴权服务器获得用于验证所述API请求的权限模型的依据。

其中，不同权限名称对应不同的权限模型。

在一可选实施例中，鉴权服务器13可以基于接收到的目标权限名称确定权限模型，进而基于该权限模型进行权限验证。

本申请提供了一种应用于API网关的权限模型获取方法，在API网关中预先构建了至少一个参数分别对应的权限名称；若当前API请求携带的第一参数对应目标权限名称，则至少将目标权限名称发送至鉴权服务器，目标权限名称是鉴权服务器获得用于验证该API请求的权限模型的依据。鉴权服务器是基于目标权限名称获得权限模型，而不是基于URL获得权限模型，因此在构建权限模型时，不需要考虑其是针对哪个URL即API请求的。API网关可以基于API请求中携带的参数确定其待验证的权限模型的权限名称，若同一类型的API请求携带的参数不同，其对应的权限模型的权限名称可能不同，即同一API请求可能对应多个权限模型；不同类型或同一类型的API请求携带的参数不同，对应的权限名称可能相同，即携带参数相同的不同API请求可能共用一个权限模型，即在构建API请求时，也无需必须构建与之对应的权限模型。综上，API请求与权限模型不是一一对应的，使得权限模型与API请求解耦合。

在一可选实施例中，可以将至少一个参数与权限名称的对应关系进行整理，例如，按照API请求的类型进行整理，以得到不同API请求类型分别对应的“至少一个参数与权限名称的对应关系”，可选的，每一API请求类型对应的“至少一个参数与权限名称的对应关系”可以对应一API模型。

在一可选实施例中，可以基于API请求携带的URL划分API请求的类型，例如，将携带相同URL的API请求划分为一类。

在一可选实施例中，可以基于API请求携带的URL以及提交方式信息划分API请求的类型，例如，携带有相同URL且携带有相同提交方式信息的API请求属于同一类API请求。

本申请实施例中，将能够区分API请求类型的信息称为API模型的属性标识。

下面以URL以及提交方式信息为API模型的属性标识为例，对API模型进行说明。下面API模型的表现形式仅为一种示例，除此之外还可以有其它表现形式，例如结构体、数据结构、表格等。

本申请示例的API模型A可以如下：

上述API模型A的属性标识包括URL为executeVmAction以及提交方式信息为POST；上述API模型A包括三个参数分别对应的权限名称，例如，start参数对应的权限名称startVM，stop参数对应的权限名称stopVM，restart参数对应的权限名称startVM。

其中，同一类型的API请求中，携带restart参数的API请求以及携带start参数的API请求共用同一权限名称为startVM的权限模型。

在一可选实施例中，API模型可以存储在API网关12中，具体可以参见图2。

本申请实施例提及的提交方式信息用于表征发送API请求的客户端与存储待访问服务对象的服务器的交互方式。

可选的，提交方式信息至少可以包括下述任一种：

第一种，GET请求：HTTP客户端发送请求的类型，表示向存储待访问服务对象的服务器请求一个文件，这里HTTP表征从发送API请求的客户端到存储待访问服务对象的服务器端的请求消息。

第二种，POST请求：HTTP客户端发送请求的类型，表示向存储待访问服务对象的服务器发送数据让存储待访问服务对象的服务器进行处理。

第三种，PUT请求：HTTP客户端发送请求的类型，表示向存储待访问服务对象的服务器请求新增文件，或使用请求中的有效负载替换目标文件。

第四种，DELETE请求：HTTP客户端发送请求的类型，表示向存储待访问服务对象的服务器请求删除文件。

在一可选实施例中，API请求还可以携带有表征API模型的属性标识的第二参数。

本申请可以基于API请求携带的第二参数，确定与其对应的API模型，进而可以基于该具体的API模型确定第一参数对应的目标权限名称，也即上述步骤S310，从预先构建的至少一个参数分别对应的权限名称中，获取与所述第一参数对应的目标权限名称的过程具体可以包括：

A1、根据预先构建的多个API模型，获取所述第二参数对应的目标API模型。

可选的，可以预先构建多个API模型，例如图2所示“API模型1”至“API模型n”，其中n≥2。

本步骤可以基于待鉴权的API请求携带的第二参数，从预先构建的多个API模型中，确定目标API模型。可选的，待鉴权的API请求携带的一个具体的第二参数可以唯一确定一个目标API模型。

假设待鉴权的API请求如下：

POST/executeVmAction

{"action":"start",

"instance_id":"123",}

则待鉴权的API请求携带的第二参数包括executeVmAction和POST，基于该第二参数，可以确定上述示例的API模型A。

A2、从所述目标API模型包含的至少一个参数分别对应的权限名称中，获取与所述第一参数对应的目标权限名称。

一个目标API模型可以包括至少一个参数与权限名称的对应关系。

假设，若API请求携带的第一参数为restart，第二参数为executeVmAction和POST。则可以首先基于第二参数，确定目标API模型为上述示例的API模型；该目标API模型包括start参数对应的权限名称startVM，stop参数对应的权限名称stopVM，restart参数对应的权限名称startVM。然后从该目标API模型中查找restart参数对应的目标权限名称，参见上述示例的API模型，从该API模型中确定的第一参数restart对应的目标权限名称为startVM。

本申请实施例中，若一个携带参数A的API请求对应的权限模型发生变更，则仅需要修改该API请求对应的API模型包含的参数A对应的权限名称A即可，例如将参数A对应的权限名称A变更为权限名称B。若鉴权服务器中已经包含权限名称B对应的权限模型，则鉴权服务器不需要做任何变更，若鉴权服务器中不包含权限名称B对应的权限模型，则仅仅在鉴权服务器中增加一个权限名称B的权限模型即可。使得维护权限模型更加便捷。

在一可选实施例中，从目标API模型中查找第一参数对应的目标权限名称的方式可以有多种，例如遍历查找，二分查找(若目标API模型可以对第一参数按照一定顺序排序，例如若第一参数首字母为英文，则按照“a”至“z”的顺序排序)等。本申请以遍历的方式为例进行说明，则上述A2，从所述目标API模型包含的至少一个参数分别对应的权限名称中，获取与所述第一参数对应的目标权限名称的过程具体可以包括：

B1、遍历所述目标API模型包含的至少一个权限名称分别对应的限制条件，一个权限名称对应的限制条件包括与该权限名称对应的参数的值需要满足的条件。

在一可选实施例中，一个权限名称对应的限制条件可以包括与该权限名称对应的参数的值需要满足的条件。

上述限制条件可以包括多种方式，本申请提供但不限于以下几种：

第一种，限制条件可以包括基本条件，这里基本条件至少可以包括：大于、等于、小于以及存在。

具体可以参见上述示例的API模型A，其中constraint表示限制条件，可选的，限制条件可以为一个基本条件eq即“等于”，示例的API模型A包含的三个限制条件分别用于：判断API请求携带的参数action的值是否等于start或stop或restart。

第二种，限制条件可以包括复合条件，这里复合条件至少可以包括以下至少一种：与“and”、或“or”以及非“not”。

例如，API请求携带的参数1的值“not”restart“and”参数2的值“not”start。

第三种，限制条件可以包括基本条件与复合条件的组合。

例如，API请求携带的参数1的值“eq”start且参数2的值“eq”up且参数3的值“not”0。

本步骤可以通过遍历的方式查找目标API模型包含的至少一个权限名称分别对应的限制条件；可选的，可以通过从前往后的方式遍历查找，还可以通过从后往前的方式遍历查找。

B2、若所述第一参数满足所述至少一个权限名称分别对应的限制条件中的目标限制条件，获取所述目标限制条件对应的所述目标权限名称。

仍以上述示例的API模型A为例，若API请求携带的第一参数的值等于start，或者restart，那么第一参数满足"eq":{"ref":{"context":{"name":"action","source":"body"}},value":"start"}这一限制条件，或者，满足"eq":{"ref":{"context":{"name":"action","source":"body"}},"value":"restart"}这一限制条件。那么目标权限名称为startVM。

若API请求携带的第一参数的值等于stop，那么第一参数满足"eq":{"ref":{"context":{"name":"action","source":"body"}},"value":"stop"}这一限制条件。那么目标权限名称为stopVM。

可选的，若第一参数不满足任意一个权限名称分别对应的限制条件中的目标限制条件，则无需验证权限。

可选的，若该API模型不包含限制条件，则说明无需验证权限。

综上，本申请实施例通过遍历目标API模型包含的至少一个权限名称分别对应的限制条件，得到目标限制条件，并基于该目标限制条件得到对应的目标权限名称，提高了查找目标限制条件对应的目标权限名称的效率。

目前API请求携带的参数的名称必须符合API规范设定的参数名称规范，否则API网关无法识别API请求中携带的参数，从而使得鉴权服务器无法进行鉴权。例如，若API规范设定的参数名称规范中用户标识的名称为user_id，若API请求中携带的用户标识的名称为idtifiy，则API网关无法从API请求中获得用户标识这一参数。

为解决上述问题，本申请可以在上述本申请公开的实施例的基础上，将API请求中携带的不符合API规范设定的参数名称与规范的参数名称进行绑定，从而不会出现无法鉴权的情况，该过程具体可以包括：

C1、从所述API请求中获取第三参数，所述第三参数包括用户标识和第二上下文信息中的至少一种。

可选的，API请求还可以携带第三参数，该第三参数包括用户标识和第二上下文信息中的至少一种。则本步骤可以从API请求中获取第三参数。

需要说明的是，本申请实施例中第一参数与第三参数可以相同，可以不同，即第一上下文信息与第二上下文信息可以相同可以不同。第一参数和第三参数两者的用途分别为：第一参数用于获取权限名称；第三参数用于获取具有预设格式的目标参数，以便后续进行鉴权。

可以理解的是，API请求携带的第三参数的参数名称可能不符合API规范，例如用户自定义的名称，为了能够使得本申请中的API网关能够从API请求中获取不符合API规范设定的第三参数，可选的，API网关包括各种不符合API规范的参数名称与符合规范的参数名称的对应关系，例如，API网关包括不符合API规范的参数名称idtifiy、ID分别与符合规范的参数名称user_id对应。API网关通过不符合API规范设定的参数名称与符合规范的参数名称的对应关系，可以从API请求中获得相应的参数。

C2、将所述第三参数转换为具有预设格式的目标参数。

这里目标参数即为上述本申请提及的符合规范的参数名称，也即目标参数必须具有预设格式。

C3、将所述目标参数发送至所述鉴权服务器。

可选的，可以将目标参数发送至鉴权服务器13，以使得鉴权服务器13可以基于目标参数以及权限模型，来确定鉴权成功或失败。

综上，本申请实施例可以将第三参数与目标参数进行绑定，以使得鉴权服务器13可以基于目标参数完成鉴权过程，由于目标参数具有预设格式，因此不会出现无法鉴权的情况。并且本申请实施例由于可以将第三参数与目标参数进行绑定，从而实现了终端11无需限定API请求携带参数的名称的目的。

在一可选实施例中，上述C2，将所述第三参数转换为具有预设格式的目标参数的过程可以包括多种方式，本申请提供但不限于以下两种。

第一种，可以预先构建第三参数与目标参数的对应关系，进而基于该对应关系进行转换，基于此，上述C2，将所述第三参数转换为具有预设格式的目标参数的过程具体可以包括：

D1、获取与所述目标权限名称对应的目标绑定规则，所述目标绑定规则包括所述第三参数与所述目标参数的对应关系。

可选的，权限名称与绑定规则的对应关系的表现形式至少有两种，接下来分别介绍。

第一种表现形式，以表格的方式表现权限名称与绑定规则的对应关系，例如表3所示的权限名称与绑定规则的对应关系。

表3权限名称与绑定规则的对应关系

上述表3中目标参数user_id、resourceid以及nameid均为具有预设格式的参数，即符合API规范设定的参数。

当然，上述表3仅为一种可选的示例，除此之外还可以有其他表现形式，例如函数、结构体、数据结构等。

本步骤可以基于预先获取的目标权限名称，获取目标权限名称对应的目标绑定规则。这里预先获取的目标权限名称的方式详细可参照前述实施例中介绍，在此不再详细赘述。

第二种表现形式，以函数的形式表现权限名称与绑定规则的对应关系。例如，可选的本申请示例的API模型B可以如下：

综上，在基于第一参数确定目标权限名称后，可以从目标权限名称对应的一个或多个绑定规则中，确定目标绑定规则。例如遍历目标权限名称对应的一个或多个绑定规则，获得包含第三参数的目标绑定规则。

例如，目标权限名称为startVM，目标权限名称仅对应一个绑定规则，即"source":{"context":{"name":"instance_id","source":"body"}},"target":"resourceId"，假设待鉴权的API请求携带的第三参数为instance_id，那么由于该绑定规则中包括第三参数instance_id，那么该绑定规则即为目标绑定规则。

D2、基于所述目标绑定规则，将所述第三参数的值赋值给具有预设格式的所述目标参数。

可选的，可以基于目标绑定规则中第三参数与目标参数的对应关系，将第三参数的值赋值给具有预设格式的目标参数，以完成绑定过程。

例如，若第三参数的名称为ID，则可以在上述表3所示的对应关系中查找ID对应的目标参数，进而可以将第三参数ID的值赋值给目标参数user_id。

第二种，本申请实施例还可以在API模型中预先设置至少一个绑定规则，进而可以基于API模型中的绑定规则，得到目标绑定规则，并完成绑定过程，基于此，上述C2，将所述第三参数转换为具有预设格式的目标参数的过程具体可以包括：

E1、遍历所述目标API模型包含的至少一个绑定规则。

本申请实施例中，可以预先构建API模型中的一个或多个绑定规则，例如，可选的本申请示例的API模型C可以如下：

本申请实施例还可以通过遍历的方式查找目标API模型包括的至少一个绑定规则中的目标绑定规则；可选的，本申请实施例中的遍历方式可以为：从前至后遍历，或，从后至前遍历。

E2、获取所述至少一个绑定规则中包含所述第三参数的目标绑定规则，所述目标绑定规则包括所述第三参数与所述目标参数的对应关系。

可选的，可以基于API请求携带的第三参数，从API模型中获取至少一个绑定规则中包含第三参数的目标绑定规则，该目标绑定规则包括第三参数与目标参数的对应关系。这里，目标绑定规则的展现形式详细可参照前述D1介绍，此处不再赘述。

例如，第三参数的参数名称为instance_id，在遍历目标API模型(这里以上述示例的API模型C为目标API模型)包含的多个绑定规则的过程中发现"source":{"context":{"name":"instance_id","source":"body"}},"target":"resourceId"这一绑定规则包括第三参数，因此，将该绑定规则确定为目标绑定规则。

E3、基于所述目标绑定规则，将所述第三参数的值赋值给具有预设格式的所述目标参数。

本步骤与上述D2对应，详细可参照前述介绍，此处不再赘述。

前述本申请实施例中详细介绍了目标API模型包含与第一参数对应的目标权限名称的情况。可以理解的是，目标API模型中可能不包含与第一参数对应的目标权限名称，则若目标API模型不包含与第一参数对应的目标权限名称，表征无需验证权限，因此可以直接确定鉴权成功。

可选的，确定目标API模型是否包含与第一参数对应的目标权限名称可以包括至少两种情况，接下来分别介绍。

第一种情况，API模型包括所需权限函数(上述示例的API模型中，required_permissions即为所需权限函数)，各个权限名称设置在所需权限函数中，该所需权限函数用于管理各个权限名称。则本申请实施例可以基于目标API模型是否包含所需权限函数来确定目标API模型是否包含与第一参数对应的目标权限名称，即，可以首先遍历目标API模型来查看是否包含该所需权限函数，若目标API模型不包含所需权限函数，则表征目标API模型不包含与第一参数对应的目标权限名称；若目标API模型包含所需权限函数，则可以进一步遍历该所需权限函数来查看其是否包含与第一参数对应的目标权限名称，若不包含，则表征目标API模型不包含与第一参数对应的目标权限名称。

第二种情况，API模型不包括所需权限函数，各个权限名称未设置在一个函数中。本申请实施例可以直接遍历API模型，来查看其是否包含与第一参数对应的目标权限名称，若不包含，则表征目标API模型不包含与第一参数对应的目标权限名称。

综上，若目标API模型不包含与第一参数对应的目标权限名称，则API网关12可以直接确定鉴权成功，而无需将API请求携带的第一参数发送至鉴权服务器13，减少了鉴权服务器13的工作量。

上述本申请实施例详细介绍了应用于API网关12的权限模型获取方法，除此之外，本申请还公开了一种应用于鉴权服务器13的鉴权方法，接下来，请参阅附图4，对本申请公开的应用于鉴权服务器13的鉴权方法进行详细说明，该过程具体可以包括：

步骤S400、获取应用程序编程接口API网关发送的目标权限名称。

其中，所述目标权限名称是所述API网关确定的与第一参数对应的权限名称，所述第一参数是待鉴权的API请求中携带的用户标识和第一上下文信息中的至少一种。

由前述实施例介绍可知，API网关12可以接收终端11发送的API请求，进而可以基于API请求携带的至少第一参数，得到与第一参数对应的目标权限名称，并发送至鉴权服务器13。则本步骤中，鉴权服务器13可以接收API网关12发送的目标权限名称。

上述第一参数为终端11生成的待鉴权的API请求中携带的参数，该第一参数可以包括用户标识和第一上下文信息中的至少一种。

步骤S410、从多个权限模型中，获得所述目标权限名称对应的目标权限模型。

鉴权服务器13上或独立于鉴权服务器13设置的数据库中存储有多个权限模型，则本步骤可以基于目标权限名称，从多个权限模型中，获取与该目标权限名称对应的目标权限模型。

可选的，上述任一个权限模型至少可以包括权限名称以及与权限名称对应的权限信息，则本申请可以基于从API网关12得到的目标权限名称，得到与其对应的目标权限模型。

可选的，上述任一个权限模型还可以包括权限名称、与权限名称对应的权限信息以及上下文信息。

步骤S420、基于所述目标权限模型，对所述API请求进行鉴权。

可选的，本申请中，鉴权服务器13还可以包括用户标识绑定的用户角色，以及用户角色对应的一个或多个权限信息。则本步骤至少可以基于目标权限模型中目标权限名称对应的权限信息，以及鉴权服务器13接收到的API请求携带的用户标识对应的权限信息，对API请求进行鉴权。

本申请提供的应用于鉴权服务器的鉴权方法，权限模型至少可以包括权限名称以及与权限名称对应的权限信息，并且权限名称与权限模型为一一对应的关系，即一个权限名称仅对应一个权限模型。则对于鉴权服务器而言，接收到的API网关发送的权限名称不同，得到的权限模型就不同，即在鉴权服务器中不是基于URL获得相应的权限模型，而是基于权限名称得到相应的权限模型，使得在鉴权服务器中构建权限模型时，由于不必做到权限模型与API请求的URL一致，所以不需要考虑是针对哪个API请求的，也无需构建相应的API请求。对于API网关而言，与目前权限定义只能是API级别不同，可以基于API请求中携带的参数定义权限，即使是同一API请求，其携带的参数不同，需要验证该API请求的权限模型可能相同可能不同，即构建一个API请求后，也无需必须构建一个与之对应的权限模型，例如可以与其他API请求共用一个权限模型，只要验证的权限信息一致就可以，从而使得权限模型与API请求解耦合，即API请求与权限模型不再必须是一一对应的关系。使得构建的API请求相对于目前而言较少，便于管理。

在一可选实施例中，若目标权限模型仅包括权限名称以及与权限名称对应的权限信息，则鉴权服务器13可以基于接收到的API请求携带的用户标识确定该用户标识对应的用户角色，并确定该用户角色对应的权限信息，若用户标识对应用户角色具有的权限信息与目标权限模型中目标权限名称对应的权限信息相同，则确定鉴权成功，否则鉴权失败。

在另一可选实施例中，本申请还可以获取API网关12发送的目标参数，该目标参数包括用户标识和第二上下文信息中的至少一种，并且该目标参数具有预设格式。由于目标参数具有预设格式，因此鉴权服务器13可以基于目标参数，对API请求进行鉴权，保证了可以完成鉴权过程，而不会出现无法鉴权的情况。

在又一可选实施例中，目标权限模型还可以包括权限名称、与权限名称对应的权限信息以及目标上下文信息，这里目标上下文信息与上述权限模型中包括的上下文信息对应，所不同的是，该目标上下文信息是指与目标权限名称对应的目标权限模型中包括的上下文信息。

若上述目标参数包括用户标识以及第二上下文信息，则上述步骤S420,基于所述目标权限模型，对所述API请求进行鉴权的过程具体可以包括：

F1、获取所述目标权限模型包含的权限信息。

前述已经说明了，API网关12可以获取API请求携带的第一参数对应的目标权限名称，该目标权限名称可以对应数据库15中存储的一个目标权限模型。可以理解的是，该目标权限模型中可能包括一个或多个权限信息，则本步骤可以获取目标权限模型中包含的权限信息。

F2、从预构建的权限模型与上下文信息关联关系中，获取目标权限模型对应的目标上下文信息。

由上述实施例中介绍可知，本申请可以预先构建权限名称与上下文信息的对应关系，例如表1所示对应关系，而本申请权限名称与权限模型一一对应，因此权限模型与上下文信息也存在对应关系，则本步骤可以从权限模型与上下文信息存在的对应关系中，得到目标权限模型对应的目标上下文信息。

参见表1，目标权限模型对应的目标上下文信息可能有多个。

F3、若所述第二上下文信息与所述目标上下文信息匹配，且，所述用户标识对应用户角色具有的权限信息与所述目标权限模型包含的权限信息匹配，确定鉴权成功。

这里，第二上下文信息与目标上下文信息匹配是指，可以理解的是，目标权限模型中可能对应多个目标上下文信息，则可选的，只要目标上下文信息中至少一个上下文信息与第二上下文信息相同，则确定第二上下文信息与目标上下文信息匹配。

用户标识对应用户角色具有的权限信息与目标权限模型包含的权限信息匹配是指，用户标识对应用户角色具有的权限信息与目标权限模型中目标权限名称对应的权限信息相同。

上述本申请公开的实施例中详细描述了方法，对于本申请的方法可采用多种形式的装置实现，因此本申请还公开了两种装置，下面给出具体的实施例进行详细说明。

参见图5，图5为本申请实施例公开的API网关的一种实现方式的结构示意图。

如图5所示，该API网关可以包括：

第一获取模块51，用于获取API请求，所述API请求至少携带有第一参数，所述第一参数包括用户标识和第一上下文信息中的至少一种；

第二获取模块52，用于从预先构建的至少一个参数分别对应的权限名称中，获取与所述第一参数对应的目标权限名称，不同的参数对应的权限名称不同；

发送模块53，用于至少将所述目标权限名称发送至鉴权服务器，所述目标权限名称是所述鉴权服务器获得用于验证所述API请求的权限模型的依据；

其中，不同权限名称对应不同的权限模型。

在一可选实施例中，上述API请求还携带有表征API模型的属性标识的第二参数；

上述第二获取模块可以包括：

第一获取单元，用于根据预先构建的多个API模型，获取所述第二参数对应的目标API模型；

第二获取单元，用于从所述目标API模型包含的至少一个参数分别对应的权限名称中，获取与所述第一参数对应的目标权限名称。

在一可选实施例中，上述第二获取单元可以包括：

第一遍历单元，用于遍历所述目标API模型包含的至少一个权限名称分别对应的限制条件，一个权限名称对应的限制条件包括与该权限名称对应的参数的值需要满足的条件；

第二获取子单元，用于若所述第一参数满足所述至少一个权限名称分别对应的限制条件中的目标限制条件，获取所述目标限制条件对应的所述目标权限名称。

在一可选实施例中，还可以包括：

第三获取单元，用于从所述API请求中获取第三参数，所述第三参数包括用户标识和第二上下文信息中的至少一种；

转换单元，用于将所述第三参数转换为具有预设格式的目标参数；

发送单元，用于将所述目标参数发送至所述鉴权服务器。

在一可选实施例中，上述转换单元可以包括：

第五获取单元，用于获取与所述目标权限名称对应的目标绑定规则，所述目标绑定规则包括所述第三参数与所述目标参数的对应关系；

第一赋值单元，用于基于所述目标绑定规则，将所述第三参数的值赋值给具有预设格式的所述目标参数。

在一可选实施例中，上述转换单元可以包括：

第二遍历单元，用于遍历所述目标API模型包含的至少一个绑定规则；

第六获取单元，用于获取所述至少一个绑定规则中包含所述第三参数的目标绑定规则，所述目标绑定规则包括所述第三参数与所述目标参数的对应关系；

第二赋值单元，用于基于所述目标绑定规则，将所述第三参数的值赋值给具有预设格式的所述目标参数。

在一可选实施例中，还可以包括：

第一鉴权单元，用于若所述目标API模型不包含与所述第一参数对应的权限名称，确定鉴权成功。

在一可选实施例中，上述第二参数包括待访问服务对象的URL统一资源定位符以及提交方式信息，所述提交方式信息用于表征发送所述API请求的客户端与存储所述待访问服务对象的服务器的交互方式。

参见图6，为本申请实施例公开的鉴权服务器的一种实现方式的结构示意图。

如图6所示，该鉴权服务器可以包括：

第三获取模块61，用于获取应用程序编程接口API网关发送的目标权限名称；

其中，所述目标权限名称是所述API网关确定的与第一参数对应的权限名称，所述第一参数是待鉴权的API请求中携带的用户标识和第一上下文信息中的至少一种；不同的参数对应的权限名称不同；

第四获取模块62，用于从多个权限模型中，获得所述目标权限名称对应的目标权限模型；

鉴权模块63，用于基于所述目标权限模型，对所述API请求进行鉴权。

在一可选实施例中，还可以包括：

第七获取单元，用于获取所述API网关发送的目标参数，所述目标参数包括用户标识和第二上下文信息中的至少一种；所述目标参数具有预设格式。

在一可选实施例中，上述目标参数包括用户标识以及第二上下文信息，上述鉴权模块可以包括：

第八获取单元，用于获取所述目标权限模型包含的权限信息；

第九获取单元，用于从预构建的权限模型与上下文信息关联关系中，获取目标权限模型对应的目标上下文信息；

第二鉴权单元，用于若所述第二上下文信息与所述目标上下文信息匹配，且，所述用户标识对应用户角色具有的权限信息与所述目标权限模型包含的权限信息匹配，确定鉴权成功。

参见图7，为本申请实施例公开的一种API网关的设备硬件结构框图，API网关12的硬件结构可以包括：至少一个处理器71，至少一个通信接口72，至少一个存储器73和至少一个通信总线74；

在本申请实施例中，处理器71、通信接口72、存储器73、通信总线74的数量为至少一个，且处理器71、通信接口72、存储器73通过通信总线74完成相互间的通信；

处理器71可能是一个中央处理器CPU，或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit)，或者是被配置成实施本发明实施例的一个或多个集成电路等；

存储器73可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatilememory)等，例如至少一个磁盘存储器；

其中，存储器73存储有程序，处理器71可调用存储器73存储的程序，所述程序用于：

从预先构建的至少一个参数分别对应的权限名称中，获取与所述第一参数对应的目标权限名称，不同的参数对应的权限名称不同；

其中，不同权限名称对应不同的权限模型。

可选的，所述程序的细化功能和扩展功能可参照上文描述。

参见图8，为本申请实施例公开的一种鉴权服务器的设备硬件结构框图，鉴权服务器13的硬件结构可以包括：至少一个处理器81，至少一个通信接口82，至少一个存储器83和至少一个通信总线84；

在本申请实施例中，处理器81、通信接口82、存储器83、通信总线84的数量为至少一个，且处理器81、通信接口82、存储器83通过通信总线84完成相互间的通信；

处理器81可能是一个中央处理器CPU，或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit)，或者是被配置成实施本发明实施例的一个或多个集成电路等；

存储器83可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatilememory)等，例如至少一个磁盘存储器；

其中，存储器83存储有程序，处理器81可调用存储器83存储的程序，所述程序用于：

获取应用程序编程接口API网关发送的目标权限名称；

基于所述目标权限模型，对所述API请求进行鉴权。

可选的，所述程序的细化功能和扩展功能可参照上文描述。

本申请实施例还公开了一种应用于应用程序编程接口API网关12的可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时，实现如上述应用于应用程序编程接口API网关12的权限模型获取方法。

本申请实施例还公开了一种应用于鉴权服务器13的可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时，实现如上述应用于鉴权服务器13的鉴权方法。

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

还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims

1.一种权限模型获取方法，其特征在于，应用于应用程序编程接口API网关，包括：

其中，不同权限名称对应不同的权限模型。

2.根据权利要求1所述权限模型获取方法，其特征在于，所述API请求还携带有表征API模型的属性标识的第二参数；

所述从预先构建的至少一个参数分别对应的权限名称中，获取与所述第一参数对应的目标权限名称，包括：

根据预先构建的多个API模型，获取所述第二参数对应的目标API模型；

从所述目标API模型包含的至少一个参数分别对应的权限名称中，获取与所述第一参数对应的目标权限名称。

3.根据权利要求2所述权限模型获取方法，其特征在于，所述从所述目标API模型包含的至少一个参数分别对应的权限名称中，获取与所述第一参数对应的目标权限名称，包括：

遍历所述目标API模型包含的至少一个权限名称分别对应的限制条件，一个权限名称对应的限制条件包括与该权限名称对应的参数的值需要满足的条件；

若所述第一参数满足所述至少一个权限名称分别对应的限制条件中的目标限制条件，获取所述目标限制条件对应的所述目标权限名称。

4.根据权利要求1至3任一所述权限模型获取方法，其特征在于，还包括：

从所述API请求中获取第三参数，所述第三参数包括用户标识和第二上下文信息中的至少一种；

将所述第三参数转换为具有预设格式的目标参数；

将所述目标参数发送至所述鉴权服务器。

5.根据权利要求4所述权限模型获取方法，其特征在于，所述将所述第三参数转换为具有预设格式的目标参数，包括：

获取与所述目标权限名称对应的目标绑定规则，所述目标绑定规则包括所述第三参数与所述目标参数的对应关系；

基于所述目标绑定规则，将所述第三参数的值赋值给具有预设格式的所述目标参数。

6.根据权利要求4所述权限模型获取方法，其特征在于，所述将所述第三参数转换为具有预设格式的目标参数，包括：

遍历所述目标API模型包含的至少一个绑定规则；

获取所述至少一个绑定规则中包含所述第三参数的目标绑定规则，所述目标绑定规则包括所述第三参数与所述目标参数的对应关系；

7.根据权利要求1所述权限模型获取方法，其特征在于，还包括：

若所述目标API模型不包含与所述第一参数对应的权限名称，确定鉴权成功。

8.根据权利要求1所述权限模型获取方法，其特征在于，所述第二参数包括待访问服务对象的URL统一资源定位符以及提交方式信息，所述提交方式信息用于表征发送所述API请求的客户端与存储所述待访问服务对象的服务器的交互方式。

9.一种鉴权方法，其特征在于，应用于鉴权服务器，包括：

获取应用程序编程接口API网关发送的目标权限名称；

基于所述目标权限模型，对所述API请求进行鉴权。

10.根据权利要求9所述鉴权方法，其特征在于，还包括：

获取所述API网关发送的目标参数，所述目标参数包括用户标识和第二上下文信息中的至少一种；所述目标参数具有预设格式。

11.根据权利要求10所述鉴权方法，其特征在于，所述目标参数包括用户标识以及第二上下文信息，所述基于所述目标权限模型，对所述API请求进行鉴权包括：

获取所述目标权限模型包含的权限信息；

从预构建的权限模型与上下文信息关联关系中，获取目标权限模型对应的目标上下文信息；

若所述第二上下文信息与所述目标上下文信息匹配，且，所述用户标识对应用户角色具有的权限信息与所述目标权限模型包含的权限信息匹配，确定鉴权成功。

12.一种应用程序编程接口API网关，其特征在于，包括：

其中，不同权限名称对应不同的权限模型。

13.一种鉴权服务器，其特征在于，包括：

14.一种应用程序编程接口API网关，其特征在于，包括：

存储器，用于存储程序；

处理器，用于执行所述程序，所述程序具体用于：

其中，不同权限名称对应不同的权限模型。

15.一种鉴权服务器，其特征在于，包括：

存储器，用于存储程序；

处理器，用于执行所述程序，所述程序具体用于：

获取应用程序编程接口API网关发送的目标权限名称；

基于所述目标权限模型，对所述API请求进行鉴权。

16.一种可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，实现如上述任一项所述的权限模型获取方法包含的各个步骤。

17.一种可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，实现如上述任一项所述的鉴权方法包含的各个步骤。