CN114065183A - 一种权限控制方法、装置、电子设备和存储介质 - Google Patents

Abstract

本申请实施例提出了一种权限控制方法、装置、电子设备和计算机存储介质，该方法包括：接收用户针对目标API接口的业务访问请求，根据所述业务访问请求，获取权限标签和用户的角色信息；所述权限标签包括所述目标API接口的接口信息；将所述权限标签和用户的角色信息与预先确定的权限策略进行对比，确定所述用户针对目标API接口的访问权限；所述权限策略用于表征每种角色信息与至少一种权限标签的映射关系。

Description

一种权限控制方法、装置、电子设备和存储介质

技术领域

本申请涉及网络安全技术领域，尤其涉及一种权限控制方法、装置、电子设备和计算机存储介质。

背景技术

相关技术中，可以利用openstack社区提供的开源项目keystone实现对接口的权限控制，具体过程为keystone通过policy.json机制实现了统一的权限策略，在需要对接口进行权限控制时，首先需要在接口上定义@controller.protected()装饰器，然后在policy.json中配置对应接口的权限策略。然而，上述方案中keystone必须显式针对每个应用程序接口(Application Programming Interface，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接口对应的权限标签；即，在用户每次的访问过程中，不需要开发人员针对每个API接口通过手工编码的方式定义对应的权限标签，可以在提升开发效率的同时降低引入权限漏洞的风险；进一步地，与相关技术中需要对每个API接口提供权限控制的装饰器，才能实现权限控制相比，本申请实施例仅通过将权限标签和用户角色与预先确定的权限策略进行对比，便可直接确定用户针对目标API接口的访问权限，使得开发人员不需要深度感知权限控制的概念，能够降低权限控制的复杂度。

附图说明

图1A为相关技术中的一种针对服务器进行权限控制的结构图；

图1B为本申请实施例中的一种针对服务器进行权限控制的结构图；

图1C为本申请实施例中的一种在产品侧进行权限控制的结构图；

图2A为本申请实施例中的一种权限控制方法的流程示意图；

图2B为本申请实施例中的一种确定权限标签的流程示意图；

图2C为本申请实施例中的另一种确定权限标签的流程示意图；

图2D为本申请实施例中的一种根据接口信息确定权限标签的示意图；

图2E为本申请实施例中的一种确定用户是否拥有访问权限的示意图；

图2F为本申请实施例中的一种判定请求参数是否为资源访问参数的示意图；

图2G为本申请实施例中的一种确定业务访问请求合法性的示意图；

图3A为本申请实施例中的一种对权限校验进行说明的示意图；

图3B为本申请实施例中的用户进行业务访问时自动鉴权的流程示意图；

图3C为本申请实施例中的一种生成权限标签和权限策略的流程示意图；

图3D为本申请实施例中的另一种生成权限标签和权限策略的流程示意图；

图3E为本申请实施例中的一种权限校验的流程示意图；

图4为本申请实施例的权限控制装置的组成结构示意图；

图5为本申请实施例提供的电子设备的结构示意图。

具体实施方式

以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所提供的实施例仅仅用以解释本申请，并不用于限定本申请。另外，以下所提供的实施例是用于实施本申请的部分实施例，而非提供实施本申请的全部实施例，在不冲突的情况下，本申请实施例记载的技术方案可以任意组合的方式实施。

需要说明的是，在本申请实施例中，术语“包括”、“包含”或者其任何其它变体意在涵盖非排他性的包含，从而使得包括一系列要素的方法或者装置不仅包括所明确记载的要素，而且还包括没有明确列出的其它要素，或者是还包括为实施方法或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个......”限定的要素，并不排除在包括该要素的方法或者装置中还存在另外的相关要素(例如方法中的步骤或者装置中的单元，例如的单元可以是部分电路、部分处理器、部分程序或软件等等)。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，I和/或J，可以表示：单独存在I，同时存在I和J，单独存在J这三种情况。另外，本文中术语“至少一种”表示多种中的任意一种或多种中的至少两种的任意组合，例如，包括I、J、R中的至少一种，可以表示包括从I、J和R构成的集合中选择的任意一个或多个元素。

例如，本申请实施例提供的权限控制方法包含了一系列的步骤，但是本申请实施例提供的权限控制方法不限于所记载的步骤，同样地，本申请实施例提供的权限控制装置包括了一系列模块，但是本申请实施例提供的权限控制装置不限于包括所明确记载的模块，还可以包括为获取相关时序数据、或基于时序数据进行处理时所需要设置的模块。

本申请实施例可以应用于终端设备和服务器组成的计算机系统中，并可以与众多其它通用或专用计算系统环境或配置一起操作。这里，终端设备可以是瘦客户机、厚客户机、手持或膝上设备、基于微处理器的系统、机顶盒、可编程消费电子产品、网络个人电脑、小型计算机系统，等等，服务器可以是服务器计算机系统小型计算机系统﹑大型计算机系统和包括上述任何系统的分布式云计算技术环境，等等。

终端设备、服务器等电子设备可以在由计算机系统执行的计算机系统可执行指令(诸如程序模块)的一般语境下描述。通常，程序模块可以包括例程、程序、目标程序、组件、逻辑、数据结构等等，它们执行特定的任务或者实现特定的抽象数据类型。计算机系统/服务器可以在分布式云计算环境中实施，分布式云计算环境中，任务是由通过通信网络连接的远程处理设备执行的。在分布式云计算环境中，程序模块可以位于包括存储设备的本地或远程计算系统存储介质上。

相关技术中，对接口进行权限控制的方案主要有以下两种：一种是利用openstack社区提供的开源项目keystone，具体实现为keystone通过policy.json机制实现了统一的权限策略，在接口需要进行权限控制时，首先需要在接口上定义@controller.protected()装饰器，然后在policy.json中配置对应接口的权限策略。另一种是通过将不同的业务进行分类，以业务为粒度定义权限策略，使得权限策略的定义不再需要细化到接口级别。然而，上述两种方案存在以下技术问题：

1)第一种方案中keystone必须显式针对每个API接口定义权限策略，并为其提供权限控制的装饰器，才能实现权限控制，使得开发人员需要深度感知权限控制的概念，增加权限控制的复杂度。

2)被动进行资源归属性检查；上述两种方案均必须显式针对API接口的输入数据进行资源归属性检查，否则就无法实现资源隔离，开发人员需要手工编码实现检查，开发效率低、同时还容易引入权限漏洞。

针对上述技术问题，提出以下各实施例。

图1A为相关技术中的一种针对服务器进行权限控制的结构图，如图1A所示，该结构图包括：服务器A和服务器B；其中，服务器A中包括微服务A和微服务B；服务器B中包括微服务C和微服务D；权限控制通过在服务器A和服务器B的网关服务入口处手工编写权限控制代码Code实现，该代码与业务模块代码耦合在一起；当某一用户的业务访问请求流入服务器A后，由于服务器A中微服务A和微服务B之间的访问都是受信的，因而在这种情况下，容易出现服务器内部某个微服务被攻破时，整个系统的服务都会被控制的问题，降低网络服务的安全性。

图1B为本申请实施例中的一种针对服务器进行权限控制的结构图，相比于图1A，该结构图中通过权限控制中间件M替换权限控制代码Code，且服务器A和服务器B中还包括权限中心；这里，权限中心可以包括两个部分，1)权限控制服务medusa；2)资源归属性检查模块，这两者结合在一起组成权限中心的功能；其中，权限控制服务medusa提供了权限策略和权限标签管理，以及权限策略校验。

参见图1B，除了服务器网关入口，内部微服务之间的相互访问也会进行无差别的权限控制，权限控制通过权限控制中间件M实现，由权限中心统一控制，对业务服务完全透明；即使系统内的某个微服务被攻陷，权限控制仍会对其它微服务进行安全管控，将业务损失降低到最小程度，进而，实现零信任权限控制。

本申请实施例可以应用于使用微服务架构的产品中；其中，微服务架构是一项以微服务为粒度部署业务的技术；不同的业务通过不同的微服务对外发布特性，服务和服务之间高度的隔离，通过标准协议通信。本申请实施例可以作用于产品网关入口，对所有登录后的API接口的业务访问请求进行统一的权限控制；使用本申请实施例可以做到微服务级别的零信任安全，同时适用于单体架构和分布式架构；这里，零信任是新一代的网络安全防护理念，它的关键在于打破默认的“信任”，用一句通俗的话来概括，就是“持续验证，永不信任”。默认不信任企业网络内外的任何人、设备和系统，基于身份认证和授权(IAM，Identityand Access Management)重新构建访问控制的信任基础，从而确保身份可信、设备可信、应用可信和链路可信。

图1C为本申请实施例中的一种在产品侧进行权限控制的结构图，如图1C所示，通过对用户的业务访问请求进行权限控制，使得用户只能对拥有权限的资源进行访问，而在权限不足时，需要联系管理员，用户无法直接进行资源访问；可见，通过权限控制可以有效确保系统资源的安全性。

在本申请的一些实施例中，权限控制方法可以利用权限控制装置中的处理器实现，上述处理器可以为特定用途集成电路(Application Specific Integrated Circuit，ASIC)、数字信号处理器(Digital Signal Processor，DSP)、数字信号处理装置(DigitalSignal Processing Device，DSPD)、可编程逻辑装置(Programmable Logic Device，PLD)、现场可编程逻辑门阵列(Field Programmable Gate Array，FPGA)、中央处理器(CentralProcessing Unit，CPU)、控制器、微控制器、微处理器中的至少一种。

图2A为本申请实施例中的一种权限控制方法的流程示意图，如图2A所示，该方法包括如下步骤：

步骤200：接收用户针对目标API接口的业务访问请求，根据业务访问请求，获取权限标签和用户的角色信息；权限标签包括目标API接口的接口信息。

本申请实施例中，目标API接口表示用户本次想要进行业务服务访问的API接口；目标API接口可以是业务系统中的任意一个API接口；这里，业务系统可以提供多种业务服务；每个API接口与多种业务服务中的每种业务服务是一一对应的。

示例性地，用户向目标API接口发送业务访问请求，由于业务访问请求是用户针对目标API接口发送的，因而，该业务访问请求中包括目标API接口的接口信息。在一些实施例中，接口信息除了可以包括目标API接口的接口名和接口路径外，还可以包括目标API接口的接口描述和接口读写属性等信息。

示例性地，根据目标API接口的上述接口信息，可以确定出与目标API接口对应的权限标签，参见图2B；其中，每个API接口对应一个权限标签，权限标签是权限动作的实现，表示用户对某个API接口对应资源的访问行为。

示例性地，根据业务访问请求，获取权限标签，可以包括：根据预先确定的权限策略中包括的接口路径和权限分组的映射关系，得到目标API接口的权限分组；根据目标API接口的权限分组和接口名，确定目标API接口的权限标签。

本申请实施例中，权限标签可以指代用户对资源的访问行为，其中，一个API接口拥有一个唯一的权限标签，用户需要拥有与之相比配的权限标签，才能合法访问此API接口；权限策略一般是一组权限标签的集合，权限策略之间也可以实现继承关系，通过将权限策略与用户绑定来实现对用户的授权行为。

本申请实施例中，权限策略定义了业务系统中的每个API接口与各个权限分组的映射关系；这里，每个API接口与权限分组可以是一对一或多对一的映射关系；若多个API接口对应同一权限分组，则说明这些API接口所拥有的业务访问权限相同；其中，每个API接口拥有的业务访问权限可以由开发人员根据对应业务服务的权限控制需求预先确定的。

示例性地，图2C为本申请实施例中的另一种确定权限标签的流程示意图，如图2C所示，iam:msp表示权限分组，create_msp表示这个权限分组下的接口，与实际的目标API接口的接口名create_msp对应；根据权限策略relation.yaml中包括的接口路径和权限分组的映射关系，可以确定出与目标API接口的接口路径iam_api.app.msp对应的权限分组iam:msp；其中，接口路径即为目标API接口所在业务模块的代码路径，这个映射关系是为了将后台参差不齐的权限业务实现隔离开来，为用户提供统一、标准的权限架构。进一步地，根据目标API接口的权限分组iam:msp和接口名create_msp，可以得到目标API接口的权限标签iam:msp:create_msp。

图2D为本申请实施例中的一种根据接口信息确定权限标签的示意图，如图2D所示，箭头左侧表示目标API接口的接口信息，箭头右侧表示权限标签的属性信息；其中，目标API接口的接口信息可以包括：接口名‘name’、接口路径‘path’、接口对应资源位置‘url’、接口描述‘desc’以及接口读写属性‘action_type’；权限标签的属性信息可以包括：权限标签名‘name’、接口描述‘desc’、权限标签读写属性‘action_group’、权限标签服务‘service’；结合图2B和图2C可知，本申请实施例中目标API接口的权限标签指的是权限标签名，即，权限标签名‘name’字段的值，其代表了访问目标API接口时需提供的权限。

示例性地，业务访问请求还包括用户的身份信息；对于根据业务访问请求，获取用户的角色信息的实现方法，可以为：通过对业务访问请求进行识别，得到用户的身份信息，再根据用户的身份信息确定用户的角色信息；这里，角色信息用于表征用户的角色，而用户的角色可以是系统管理员、管理员、访客、商家、消费者等角色；其中，不同用户之间的角色还可以具有上下级关系。

这里，对于用户访问目标API接口的方式不作限定；例如，可以通过用户令牌的方式进行访问，也可以通过其它方式进行访问。

在一些实施例中，上述方法应用于使用微服务架构的业务系统中，业务系统中包括多种微服务，上述方法还可以包括：目标API接口是多种微服务中任意一种微服务的访问接口。示例性地，参见图1B，目标API接口可以是服务器A和服务器B中包括的任意一种微服务的访问接口，可见，本申请实施例是以微服务为粒度进行权限控制的，即使某个微服务被攻陷，权限控制仍会对其它微服务进行安全管控，将业务损失降低到最小程度，进而，实现零信任权限控制。

步骤201：将权限标签和用户的角色信息与预先确定的权限策略进行对比，确定用户针对目标API接口的访问权限；权限策略用于表征每种角色信息与至少一种权限标签的映射关系。

示例性地，可以在接收用户针对目标API接口的业务访问请求前，获取权限策略；权限策略是根据每个API接口的权限控制需求对应确定的；权限控制需求表示每种角色信息对于每个API接口的使用需求。

示例性地，权限策略可以根据每个API接口的权限控制需求对应确定；由于每个API接口与每种业务服务是一一对应的，即，权限策略可以是在需求阶段通过用户对每种业务服务的权限控制需求转化为来，比如，订单管理模块对应的API接口需要开放给商家，不应开放给消费者。这里，商家、消费者指的是用户的角色信息，可见，权限控制需求表示每种角色信息对于每个API接口的使用需求，其中，角色信息的使用需要包括两种情况：可使用和不可使用。

在一些实施例中，权限策略包括每个API接口的权限标签，获取每个API接口的权限标签，可以包括：在每个API接口开发完成后，根据每个API接口的接口信息，获取每个API接口的权限标签。

示例性地，确定权限策略的权限控制需求可以根据每种角色信息对于每个API接口的使用需求转化而来，并且与每个API接口对应的权限标签也包含在权限策略中；因而，可以基于每个API接口，建立每种角色信息与权限标签的映射关系；这里，每种角色信息可以与一个或多个权限标签存在映射关系。

示例性地，在根据上述步骤200得到与当前用户的业务访问请求对应的权限标签和用户的角色信息后，可以根据权限策略中预先存储的每种角色信息与至少一种权限标签的映射关系，确定与当前用户的角色信息存在映射关系的权限标签集；图2E为本申请实施例中的一种确定用户是否拥有访问权限的示意图，如图2E所示，从当前用户的业务访问请求中获取目标API接口的接口信息和用户的角色信息，根据该接口信息确定权限标签；将该权限标签与用户的角色信息传入到权限控制服务medusa进行权限校验；这里，权限控制服务medusa包括上述权限策略；可见，根据权限控制服务medusa包括的权限策略中预先存储的角色信息与权限标签的映射关系，可以确定出上述权限标签集。

示例性地，权限标签集中权限标签的数目为大于或等于零的整数；若该权限标签集中包括当前用户的权限标签，则说明用户拥有针对目标API接口的访问权限；反之，若该权限标签集中未包括当前用户的权限标签，则说明用户不拥有针对目标API接口的访问权限，此时，采用预先设置的拦截策略拒绝该用户的业务访问请求。

在一些实施例中，上述方法还可以包括：在确定用户拥有针对目标API接口的访问权限后，自动对业务访问请求需要访问的目标资源进行资源归属性检查，确定业务访问请求的合法性。

示例性地，为了实现目标资源的自动资源归属性检查，在确定用户拥有针对目标API接口的访问权限后，首先需要对业务访问请求的入参行为进行分析，以判定业务访问请求中的请求参数是否为资源访问参数；图2F为本申请实施例中的一种判定请求参数是否为资源访问参数的示意图，如图2F所示，通过入参行为分析判定该请求参数是否满足以下设定条件：请求参数的参数类型是uuid、请求参数的参数值类型是uuid、请求参数的参数字段名是_id或_ids后缀、请求参数包括系统认定需要进行资源归属性检查的其它入参字段名，则可以判定请求参数是否为资源访问参数；即，如果满足上述设定条件，则判定请求参数为资源访问参数；反之，则判定请求参数不为资源访问参数。

可见，本申请实施例通过入参行为分析能够对任何疑似是资源访问的请求参数进行筛查，对于系统未能识别的资源访问参数，均采用默认拒绝的控制策略，以确保系统的安全性。

在一些实施例中，自动对业务访问请求需要访问的目标资源进行资源归属性检查，确定业务访问请求的合法性，可以包括：从业务访问请求中获取资源访问参数，根据资源访问参数，确定需要访问的目标资源；查询目标资源的归属信息，根据目标资源的归属信息与用户的身份信息的比对结果，确定业务访问请求的合法性。

图2G为本申请实施例中的一种确定业务访问请求合法性的示意图，如图2G所示，首先进行入参行为分析，具体为：对业务访问请求中的请求参数进行行为分析，确定请求参数为资源访问参数；接着，进行资源归属查询，具体为：从业务系统中查询与资源访问参数对应的目标资源的归属信息；最后，进行归属性校验，具体为：将目标资源的归属信息与用户的身份信息进行比对，校验用户的业务访问请求的合法性。

在一些实施例中，上述方法还可以包括：在确定业务访问请求合法时，确定用户拥有目标资源的操作权限；即，用户可以访问与目标API接口对应的业务服务；在确定业务访问请求不合法时，确定执行预先设置的拦截策略；即，用户无法访问与目标API接口对应的业务服务。

在一些实施例中，上述方法可以应用于使用微服务架构的业务系统中，业务系统中包括多种微服务，上述方法还可以包括：目标API接口是多种微服务中任意一种微服务的访问接口。示例性地，参见图1B，目标API接口可以是服务器A和服务器B中包括的任意一种微服务的访问接口，可见，本申请实施例是以微服务为粒度进行权限控制的，即使某个微服务被攻陷，权限控制仍会对其它微服务进行安全管控，将业务损失降低到最小程度，进而，实现零信任权限控制。

本申请实施例提出了一种权限控制方法、装置、电子设备和计算机存储介质，该方法包括：接收用户针对目标API接口的业务访问请求，根据所述业务访问请求，获取权限标签和用户的角色信息；所述权限标签包括所述目标API接口的接口信息；将所述权限标签和用户的角色信息与预先确定的权限策略进行对比，确定所述用户针对目标API接口的访问权限；所述权限策略用于表征每种角色信息与至少一种权限标签的映射关系。可以看出，本申请实施例利用用户的业务访问请求中目标API接口的接口信息，可以得到与该目标API接口对应的权限标签；即，在用户每次的访问过程中，不需要开发人员针对每个API接口通过手工编码的方式定义对应的权限标签，可以在提升开发效率的同时降低引入权限漏洞的风险；进一步地，与相关技术中需要对每个API接口提供权限控制的装饰器，才能实现权限控制相比，本申请实施例仅通过将权限标签和用户角色与预先确定的权限策略进行对比，便可直接确定用户针对目标API接口的访问权限，使得开发人员不需要深度感知权限控制的概念，能够降低权限控制的复杂度。

为了能够更加体现本申请的目的，在本申请上述实施例的基础上，进行进一步的举例说明。

参见图3A，本申请实施例可以针对权限校验三要素(主体、客体和动作)中的客体和权限动作提供自动化的支撑，即，对客体自动实现资源归属性检查；根据API接口的接口信息自动生成权限标签，并进行相应的权限控制。这里，主体表示业务访问请求的发起方，即，用户，客体表示业务访问请求的目标方，即，上述目标资源；权限动作表示请求目的，权限动作的具体实现是权限标签。

示例性地，权限控制可以分两个部分，一个部分是业务服务(API接口)的权限控制需求的自动注册，另一个部分是用户的业务访问请求的权限校验。

示例性地，图3B为本申请实施例中的用户进行业务访问时自动鉴权的流程示意图，如图3B所示，该流程包括以下步骤：

步骤A1：注册业务服务的权限控制需求。

示例性地，业务服务的权限控制需求一般在需求阶段定义，业务开发人员提出各个业务模块的权限控制需求，如业务A需要开放给超级管理员和租户使用，业务B仅开放给租户使用。IAM小组成员会将这些权限控制需求转化成权限策略，业务服务的API接口开发完成后，会自动转换成权限标签，此时就完成了权限控制需求的自动注册。

步骤A2：接收用户的业务访问请求。

示例性地，用户针对目标API接口的业务访问请求的权限校验在用户实际使用产品时进行，在通过统一的权限控制中间件接收到用户的业务访问请求后，根据业务访问请求确定与API接口对应的权限标签。

步骤A3：向权限中心申请授权。

示例性地，权限中心包括权限控制服务medusa，根据权限控制服务medusa包括的权限策略中预先存储的角色信息与权限标签的映射关系，以及根据当前用户的业务访问请求确定的权限标签和角色信息，确定用户是否拥有针对目标API接口的访问权限，并在确定用户拥有针对目标API接口的访问权限后，自动对业务访问请求需要访问的目标资源进行资源归属性检查，确定业务访问请求的合法性。

步骤A4：权限中心通过授权。

示例性地，若根据步骤A3确定用户的业务访问请求合法时，权限中心向权限控制中间件发送通过授权的指令。

步骤A5：请求业务服务。

示例性地，若权限控制中间件接收到权限中心发送的通过授权的指令后，则允许用户访问与其业务访问请求对应的实际业务服务。

可见，本申请实施例通过自动识别用户业务访问请求的权限访问需求，自动校验其合法性并进行结果反馈；当用户行为合法时，请求透明转交到业务服务，当用户行为非法时，自动执行拦截动作。

示例性地，权限控制需求的自动注册分为权限标签和权限策略的自动生成，参见图2B，权限标签的生成依赖于业务服务提供API接口的接口信息，权限策略生成则依赖于需求阶段定义的用户角色对于每个API接口的使用需求。

图3C为本申请实施例中的一种生成权限标签和权限策略的流程示意图，如图3C所示，权限标签可以根据API接口的接口信息(也叫API资产信息)进行确定，权限策略在需求阶段通过用户对不同业务服务的权限控制需求进行确定，比如订单管理模块需要开放给商家，不应开放给消费者。

示例性地，IAM小组成员通过将不同业务服务的权限控制需求转化成权限策略表，这里，权限策略表是权限控制需求的直接产物，权限策略表经过策略生成工具可以得到权限策略；业务开发人员针对与每个业务模块的权限控制需求，进行业务接口编码，得到每个API接口的接口信息；这里，每种业务服务与业务模块是一一对应的。进一步地，在得到每种业务服务的权限策略和权限标签后，自动调用策略同步工具，将权限策略和权限标签同步到权限中心。

表1

示例性地，图3D为本申请实施例中的另一种生成权限标签和权限策略的流程示意图，图3D介绍了生成权限标签和权限策略的各流程阶段涉及到的配置文件、脚本工具等，该图与图3C是完全对应的，此处不再赘述。这里，通过上述表1已对图3D中涉及的关键对应进行说明。

其中，policy.xls文件的示例如表2所示，每条记录代表了一种业务服务的权限控制需求，如第一条记录表示IAM小组成员需要对外提供管理服务提供商(Managed Serviceprovider，MSP)管理的功能，此功能仅面向admin开放，对admin而言，其拥有完全控制权限。

表2这里，policy.xls文件表头中各字段的含义如表3所示：

表3

图3E为本申请实施例中的一种权限校验的流程示意图，如图3E所示，该权限校验过程中，首先获取权限标签生成流程(图3D)中的权限策略relation.yaml文件，通过权限策略relation.yaml文件，可以得到与每个API接口对应的权限标签，并将得到的每个API接口对应的权限标签，以及根据每个API接口的权限控制需求确定的用户的角色信息与权限标签的映射关系发送给权限控制中间件；权限控制中间件将每个API接口对应的权限标签，以及用户的角色信息与权限标签的映射关系传入到权限中心的权限控制服务medusa中；如果当前用户向权限控制中间件发起针对目标API接口的业务访问请求，权限控制中间件根据当前用户的业务访问请求，确定包含目标API接口的权限标签以及用户的角色信息，并将目标API接口的权限标签、用户的角色信息发送到权限中心的权限控制服务medusa中用于对当前用户是否拥有目标API接口的访问权限进行校验；并在权限校验后，对业务访问请求需要访问的目标资源进行资源归属性检查，进一步确定业务访问请求的合法性；在确定业务访问请求合法的情况下，允许用户访问与其业务访问请求对应的实际业务服务；反之，自动执行拦截动作。

可见，本申请实施例的权限控制过程不仅对业务开发人员完全透明，还为业务开发人员屏蔽了权限控制机制，省去了权限控制设计、编码、联调以及处理问题的工作量；此外，用客观手段代替业务开发人员手工编码实现权限控制，降低了权限相关的问题数，大大降低了符合SDL(Simple DirectMedia Layer)流程所需付出的安全成本。

图4为本申请实施例的权限控制装置的组成结构示意图，如图4所示，该装置包括：获取模块400和确定模块401，其中：

获取模块400，用于接收用户针对目标API接口的业务访问请求，根据所述业务访问请求，获取权限标签和用户的角色信息；所述权限标签包括所述目标API接口的接口信息；

确定模块401，用于将所述权限标签和用户的角色信息与预先确定的权限策略进行对比，确定所述用户针对目标API接口的访问权限；所述权限策略用于表征每种角色信息与至少一种权限标签的映射关系。

在一些实施例中，所述确定模块401，还用于：

在确定所述用户拥有针对所述目标API接口的访问权限后，自动对所述业务访问请求需要访问的目标资源进行资源归属性检查，确定所述业务访问请求的合法性。

在一些实施例中，所述确定模块401，用于自动对所述业务访问请求需要访问的目标资源进行资源归属性检查，确定所述业务访问请求的合法性，包括：

从所述业务访问请求中获取资源访问参数，根据所述资源访问参数，确定需要访问的目标资源；

查询所述目标资源的归属信息，根据所述目标资源的归属信息与所述用户的身份信息的比对结果，确定所述业务访问请求的合法性。

在一些实施例中，所述确定模块401，还用于：

在确定所述业务访问请求合法时，确定所述用户拥有所述目标资源的操作权限；

在确定所述业务访问请求不合法时，确定执行预先设置的拦截策略。

在一些实施例中，所述接口信息包括接口名和接口路径，所述获取模块400，用于根据所述业务访问请求，获取权限标签，包括：

根据预先确定的权限策略中包括的接口路径和权限分组的映射关系，得到所述目标API接口的权限分组；根据所述目标API接口的权限分组和所述接口名，确定所述目标API接口的权限标签。

在一些实施例中，所述获取模块400，还用于：

在所述接收用户针对目标API接口的业务访问请求前，获取所述权限策略；所述权限策略是根据每个API接口的权限控制需求对应确定的；所述权限控制需求表示所述每种角色信息对于每个API接口的使用需求。

在一些实施例中，所述权限策略包括所述每个API接口的权限标签，所述获取模块400，还用于获取所述每个API接口的权限标签，包括：

在所述每个API接口开发完成后，根据所述每个API接口的接口信息，获取所述每个API接口的权限标签。

在一些实施例中，所述装置应用于使用微服务架构的业务系统中，所述业务系统中包括多种微服务，所述目标API接口是所述多种微服务中任意一种微服务的访问接口。

在实际应用中，上述获取模块400和确定模块401均可以由位于电子设备中的处理器实现，该处理器可以为ASIC、DSP、DSPD、PLD、FPGA、CPU、控制器、微控制器、微处理器中的至少一种。

另外，在本实施例中的各功能模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

集成的单元如果以软件功能模块的形式实现并非作为独立的产品进行销售或使用时，可以存储在一个计算机可读取存储介质中，基于这样的理解，本实施例的技术方案本质上或者说对相关技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)或processor(处理器)执行本实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

具体来讲，本实施例中的一种权限控制方法对应的计算机程序指令可以被存储在光盘、硬盘、U盘等存储介质上，当存储介质中的与一种权限控制方法对应的计算机程序指令被一电子设备读取或被执行时，实现前述实施例的任意一种权限控制方法。

基于前述实施例相同的技术构思，参见图5，其示出了本申请实施例提供的电子设备500，可以包括：存储器501和处理器502；其中，

存储器501，用于存储计算机程序和数据；

处理器502，用于执行存储器中存储的计算机程序，以实现前述实施例的任意一种权限控制方法。

在实际应用中，上述存储器501可以是易失性存储器(volatile memory)，例如RAM；或者非易失性存储器(non-volatile memory)，例如ROM、快闪存储器(flash memory)、硬盘(Hard Disk Drive，HDD)或固态硬盘(Solid-State Drive，SSD)；或者上述种类的存储器的组合，并向处理器502提供指令和数据。

上述处理器502可以为ASIC、DSP、DSPD、PLD、FPGA、CPU、控制器、微控制器、微处理器中的至少一种。可以理解地，对于不同的检测设备，用于实现上述处理器功能的电子器件还可以为其它，本申请实施例不作具体限定。

在一些实施例中，本申请实施例提供的装置具有的功能或包含的模块可以用于执行上文方法实施例描述的方法，其具体实现可以参照上文方法实施例的描述，为了简洁，这里不再赘述。

上文对各个实施例的描述倾向于强调各个实施例之间的不同之处，其相同或相似之处可以互相参考，为了简洁，本文不再赘述。

本申请所提供的各方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。

本申请所提供的各产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。

本申请所提供的各方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用硬件实施例、软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其它可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其它可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可装载到计算机或其它可编程数据处理设备上，使得在计算机或其它可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其它可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上，仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。

Claims (11)

1.一种权限控制方法，其特征在于，所述方法包括：

接收用户针对目标API接口的业务访问请求，根据所述业务访问请求，获取权限标签和用户的角色信息；所述权限标签包括所述目标API接口的接口信息；

将所述权限标签和用户的角色信息与预先确定的权限策略进行对比，确定所述用户针对目标API接口的访问权限；所述权限策略用于表征每种角色信息与至少一种权限标签的映射关系。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在确定所述用户拥有针对所述目标API接口的访问权限后，自动对所述业务访问请求需要访问的目标资源进行资源归属性检查，确定所述业务访问请求的合法性。

3.根据权利要求2所述的方法，其特征在于，所述自动对所述业务访问请求需要访问的目标资源进行资源归属性检查，确定所述业务访问请求的合法性，包括：

从所述业务访问请求中获取资源访问参数，根据所述资源访问参数，确定需要访问的目标资源；

查询所述目标资源的归属信息，根据所述目标资源的归属信息与所述用户的身份信息的比对结果，确定所述业务访问请求的合法性。

4.根据权利要求2或3所述的方法，其特征在于，所述方法还包括：

在确定所述业务访问请求合法时，确定所述用户拥有所述目标资源的操作权限；

在确定所述业务访问请求不合法时，确定执行预先设置的拦截策略。

5.根据权利要求1所述的方法，其特征在于，所述接口信息包括接口名和接口路径；所述根据所述业务访问请求，获取权限标签，包括：

根据预先确定的权限策略中包括的接口路径和权限分组的映射关系，得到所述目标API接口的权限分组；根据所述目标API接口的权限分组和所述接口名，确定所述目标API接口的权限标签。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在所述接收用户针对目标API接口的业务访问请求前，获取所述权限策略；所述权限策略是根据每个API接口的权限控制需求对应确定的；所述权限控制需求表示所述每种角色信息对于每个API接口的使用需求。

7.根据权利要求6所述的方法，其特征在于，所述权限策略包括所述每个API接口的权限标签，获取所述每个API接口的权限标签，包括：

在所述每个API接口开发完成后，根据所述每个API接口的接口信息，获取所述每个API接口的权限标签。

8.根据权利要求1所述的方法，其特征在于，所述方法应用于使用微服务架构的业务系统中，所述业务系统中包括多种微服务，所述方法还包括：

所述目标API接口是所述多种微服务中任意一种微服务的访问接口。

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

获取模块，用于接收用户针对目标API接口的业务访问请求，根据所述业务访问请求，获取权限标签和用户的角色信息；所述权限标签包括所述目标API接口的接口信息；

确定模块，用于将所述权限标签和用户的角色信息与预先确定的权限策略进行对比，确定所述用户针对目标API接口的访问权限；所述权限策略用于表征每种角色信息与至少一种权限标签的映射关系。

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

11.一种计算机存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至8任一项所述的方法。

Images