CN118035982A - 用户权限管理方法 - Google Patents

Abstract

本申请公开了一种用户权限管理方法，其中，所述方法包括：为目标软件的每一类用户端配置至少一种授权模型；响应于用户基于目标用户端输入的针对应用程序编程接口的访问信息，将所述目标用户端对应的授权模型作为目标授权模型；根据所述访问信息和所述目标授权模型确定是否对用户进行授权。通过本申请提供的技术方案能够对目标软件不同类型用户端的用户进行个性化的授权管理，使每一类用户端的用户拥有不同的应用程序编程接口访问权限。

Description

用户权限管理方法

技术领域

本申请属于软件设计技术领域，尤其涉及一种用户权限管理方法。

背景技术

认证和授权是软件设计中的重要环节，设计认证和授权有诸多优势，例如可以限制用户对软件系统资源的访问，确保只有经过身份验证且授权的用户才能访问敏感数据和相关功能；可以确保只有授权的用户才能修改数据，避免敏感数据被随意篡改；可以记录和追踪用户对软件系统资源的访问和操作；可以确保只有授权的用户才能访问其个人信息和数据，保护用户隐私；可以确保软件系统符合安全和隐私方面的合规要求等。因此，通过认证和授权可以保障软件系统满足安全性、数据保护、用户隐私和合规的要求。

目前，软件系统通常会布署在多种不同类型的用户端，例如App端、小程序端、网页端等，如何对不同类型用户端的用户进行个性化的授权管理是亟需解决的问题。

发明内容

本申请的实施例提供了一种用户权限管理方法，进而至少在一定程度上可以对软件不同类型用户端的用户进行个性化的授权管理。

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

根据本申请实施例的第一方面，提供了一种用户权限管理方法，包括：为目标软件的每一类用户端配置至少一种授权模型；响应于用户基于目标用户端输入的针对应用程序编程接口的访问信息，将所述目标用户端对应的授权模型作为目标授权模型；根据所述访问信息和所述目标授权模型确定是否对用户进行授权。

在本申请的一些实施例中，基于前述方案，所述授权模型包括基于菜单的权限访问控制MBAC模型、基于角色的权限访问控制RBAC模型和基于属性的权限访问控制ABAC模型中的至少一种。

在本申请的一些实施例中，基于前述方案，所述目标授权模型包括所述MBAC模型，在所述为目标软件的每一类用户端配置至少一种授权模型之前，所述方法还包括：根据所述目标软件的功能信息确定所述MBAC模型中的菜单；确定所述MBAC模型中的角色；确定所述MBAC模型中的角色与菜单的第一关联关系和第二关联关系，其中，所述第一关联关系用于表征角色对菜单的查看权限，所述第二关联关系用于表征角色对菜单对应的应用程序编程接口的访问权限。

在本申请的一些实施例中，基于前述方案，所述根据所述访问信息和所述目标授权模型确定是否对用户进行授权，包括：根据用户基于所述目标用户端输入的登录信息确定目标角色；根据所述访问信息确定目标应用程序编程接口；根据所述目标角色、所述目标应用程序编程接口和所述第二关联关系确定是否允许用户访问所述目标应用程序编程接口。

在本申请的一些实施例中，基于前述方案，在所述根据用户基于所述目标用户端输入的登录信息确定目标角色之后，所述方法还包括：根据所述第一关联关系确定所述目标角色对应的菜单；输出所述目标角色对应的菜单的显示界面。

在本申请的一些实施例中，基于前述方案，所述目标授权模型包括所述RBAC模型，在所述为目标软件的每一类用户端配置至少一种授权模型之前，所述方法还包括：确定所述RBAC模型中的角色；根据所述目标用户端对应的应用程序编程接口确定多个应用程序编程接口集合；确定所述RBAC模型中的角色与每个应用程序编程接口集合的第三关联关系，其中，所述第三关联关系用于表征角色对应用程序编程接口集合的访问权限。

在本申请的一些实施例中，基于前述方案，所述根据所述访问信息和所述目标授权模型确定是否对用户进行授权，包括：根据用户基于所述目标用户端输入的登录信息确定目标角色；根据所述访问信息确定目标应用程序编程接口；

在所述目标用户端对应的应用程序编程接口和至少一个应用程序编程接口集合中均包括所述目标应用程序编程接口的情况下，根据所述第三关联关系，确定所述目标应用程序编程接口所在的应用程序编程接口集合对应的角色；根据所述目标角色或所述目标角色的子角色中是否包括所述目标应用程序编程接口所在的应用程序编程接口集合对应的角色，对应确定是否允许用户访问所述目标应用程序编程接口。

在本申请的一些实施例中，基于前述方案，所述目标授权模型包括所述ABAC模型，在所述为目标软件的每种用户端配置至少一种授权模型之前，所述方法还包括：确定所述ABAC模型中的主体属性、客体属性和环境属性；将所述主体属性、所述客体属性、所述环境属性和访问结果组合，得到所述ABAC模型中的访问策略。

在本申请的一些实施例中，基于前述方案，所述根据所述访问信息和所述目标授权模型确定是否对用户进行授权，包括：根据用户基于所述目标用户端输入的登录信息确定目标角色；根据所述访问信息确定目标应用程序编程接口和目标环境；将所述主体属性为所述目标角色，所述客体属性为所述目标应用程序编程接口且环境属性为所述目标环境的访问策略作为目标访问策略，并根据所述目标访问策略中的访问结果确定是否允许用户访问所述目标应用程序编程接口。

在本申请的一些实施例中，基于前述方案，所述为目标软件的每一类用户端配置至少一种授权模型，包括：为所述目标软件的每一类用户端配置一种授权模型，且每一类用户端对应的授权模型各不相同；或，为所述目标软件的每一类用户端配置多种授权模型。

在本申请的一些实施例中，基于前述方案，在所述为所述目标软件的每一类用户端配置多种授权模型之后，所述方法还包括：为所述目标软件的每一类用户端配置授权决策规则，其中，所述授权决策规则包括：在一种授权模型对应的授权结果为允许用户访问的情况下对用户进行授权、在全部授权模型对应的授权结果均为允许用户访问的情况下对用户进行授权、或在多数授权模型对应的授权结果为允许用户访问的情况下对用户进行授权。

在本申请的一些实施例中，基于前述方案，所述根据所述访问信息和所述目标授权模型确定是否对用户进行授权，包括：根据所述访问信息确定所述目标授权模型中每种授权模型的授权结果；根据所述每种授权模型的授权结果和所述授权决策规则，确定是否对用户进行授权。

根据本申请实施例的第二方面，提供了一种用户权限管理装置，包括：授权模型配置模块，用于为目标软件的每一类用户端配置至少一种授权模型；

授权模型确定模块，用于响应于用户基于目标用户端输入的针对应用程序编程接口的访问信息，将所述目标用户端对应的授权模型作为目标授权模型；用户授权模块，用于根据所述访问信息和所述目标授权模型确定是否对用户进行授权。

根据本申请实施例的第三方面，提供了一种用户权限管理设备，包括处理器和存储器，所述存储器存储有能够被所述处理器执行的计算机程序指令，所述处理器执行所述计算机程序指令时，实现如上述第一方面任一项所述的方法的步骤。

根据本申请实施例的第四方面，提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序指令，所述计算机程序指令被处理器执行时，促使所述处理器实现如上述第一方面任一项所述的方法的步骤。

在本申请中，通过为目标软件的每一类用户端配置至少一种授权模型；响应于用户基于目标用户端输入的针对应用程序编程接口的访问信息，将所述目标用户端对应的授权模型作为目标授权模型；根据所述访问信息和所述目标授权模型确定是否对用户进行授权。通过本申请提供的技术方案能够对目标软件不同类型用户端的用户进行个性化的授权管理，使每一类用户端的用户拥有不同的应用程序编程接口访问权限。

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

附图说明

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

图1示出了一个实施例中用户权限管理方法的应用环境图；

图2示出了一个实施例中用户权限管理方法的流程示意图；

图3示出了一个实施例中MBAC模型的原理示意图；

图4示出了步骤203的一种细节示意图；

图5示出了步骤203的另一种细节示意图；

图6示出了步骤203的又一种细节示意图；

图7示出了图6的一种演示图；

图8示出了一个实施例中用户权限管理装置的框图；

图9示出了一个实施例中用户权限管理设备的结构示意图。

具体实施方式

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

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

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

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

还需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的对象在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在图示或描述的那些以外的顺序实施。

为了使本领域技术人员更好的理解本申请，首先结合图1对本申请所涉及的应用场景进行简单说明。

图1示出了可以应用本申请实施例的用户权限管理方法的场景示意图。如图1所示，目标软件可以在多种类型的用户端(如手机App端、微信小程序端、Web端以及其他设备)上进行部署，用户可以通过调用应用程序编程接口访问目标软件的后端服务。不同类型用户端的用户对于目标软件的后端服务的访问权限通常并不相同，例如图1中手机App用户的权限是访问后端服务1和后端服务2、微信小程序用户的权限是访问后端服务2和后端服务4、Web端用户的权限是访问后端服务1、其他设备用户的权限是访问后端服务3，因此需要对目标软件不同类型用户端的用户进行个性化的授权管理。本申请实施例通过为目标软件的每一类用户端配置至少一种授权模型；响应于用户基于目标用户端输入的针对应用程序编程接口的访问信息，将目标用户端对应的授权模型作为目标授权模型；根据访问信息和目标授权模型确定是否对用户进行授权，实现了对不同用户端的用户进行个性化的授权管理。

图2示出了一个实施例中用户权限管理方法的流程示意图。如图2所示，提供了一种用户权限管理方法，该方法可以包括以下步骤201至203。

在步骤201中，为目标软件的每一类用户端配置至少一种授权模型。

其中，用户端可以包括App端、小程序端、Web端以及其他设备等多种类型。授权模型可以包括DAC(Discretionary Access Control，基于自由裁量权的访问控制)模型、RBAC(Role-Based Access Control，基于角色的权限访问控制)模型、ABAC(Attribute-BasedAccess Control，基于属性的权限访问控制)模型、MBAC(Menu-Based Access Control，基于菜单的权限访问控制)模型中的至少一种。

可以理解的是，DAC模型中资源的所有者有权决定哪个用户或用户组可以访问其资源，每个资源都对应一个访问控制列表，该访问控制列表中列出了允许或禁止访问该资源的用户或用户组。

DAC模型具有多种优点，包括：允许资源的所有者自由决定哪个用户或用户组可以访问其资源，以及访问权限的级别；不需要复杂的规则和策略，而是依赖资源的所有者进行权限设置；允许资源的所有者对每个用户或用户组进行个性化的权限控制，这使得资源的所有者能够根据具体的需求和要求，为不同的用户或用户组分配不同的权限。

DAC模型也具有多种缺点，包括：过度依赖资源的所有者进行权限设置，可能导致资源的所有者过度授权或错误授权，如果资源的所有者授予了不合理的权限，可能会导致权限滥用、数据泄露或系统遭受攻击的风险；DAC模型的权限控制是基于所有者、所属组和其他用户三个类别的权限，无法进行细粒度更高的访问控制。

DAC模型通常适用于用户量级较少的Linux系统，在Linux系统中，每个文件和目录都有所属用户和所属组，并且为其分配了权限。这些权限分为三个类别：所有者、所属组和其他用户。每个类别都有读取、写入和执行三种权限。Linux系统允许文件和目录的所有者、所属组和其他用户分别设置不同的权限，以控制对文件和目录的访问。例如，只有文件所有者拥有写入权限，其他用户只有读取权限。

RBAC模型可以将用户分配给不同的角色，并根据角色的权限和职责控制用户对资源的权限。RBAC模型的基本原则是将权限分配和管理关联到用户对应的角色上，而不是直接关联到用户，如此权限只需要分配给角色，而不需要逐个用户进行设置，有效简化了权限管理。RBAC模型包括用户、角色和权限这三个核心组件。用户是软件系统中的实体，可以被分配到一个或多个角色；角色可以根据用户的职位或职能来定义，例如管理员、组长等；权限指用户或角色可以执行的操作或访问的资源，比如拥有“组长”角色的用户可以查看组内的业绩数据。

RBAC模型具有多种优点，包括：通过将权限分配给角色，而不是直接关联到用户，简化权限的管理和维护；减少了权限的滥用和误用、提高了系统的安全性；允许将多个角色授予一个用户，或将一个角色授予多个用户，从而实现了权限的灵活分配；减少了权限检查的复杂性，提高了软件系统的性能和响应速度。

ABAC模型可以基于属性管理控制用户对资源的访问权限。其核心思想是通过定义策略规则，将用户的属性、资源的属性和环境的属性结合起来进行访问控制决策。这些属性可以是任何与用户、资源和环境相关的信息，如用户的角色、组织、资源类型、访问地址、访问时间等。ABAC的访问控制策略规则通常基于策略语言进行定义，例如XACML(eXtensibleAccess Control Markup Language，可扩展访问控制标记语言)。

ABAC模型具有多种优点，包括：1、灵活性：可以根据具体的属性进行细粒度更高的访问控制，以满足不同的业务需求；2、动态性：可以根据实时信息(例如用户当前的属性、环境的状态等)进行访问控制决策，使得访问控制更加动态；3、可扩展性：可以轻松地集成和扩展到不同的应用和系统中，以适应不同的访问控制需求；4、精细化控制：允许根据多个属性来进行访问控制决策，从而实现更精细化的权限管理和控制。

MBAC模型中，用户的权限可以根据其角色和菜单的关联进行管理，以保障只有经过授权的用户可以访问菜单对应的功能。

在步骤202中，响应于用户基于目标用户端输入的针对应用程序编程接口的访问信息，将目标用户端对应的授权模型作为目标授权模型。

可以理解的是，目标用户端为用户当前使用的用户端。当用户基于目标用户端输入针对应用程序编程接口的访问信息之后，需要基于授权模型确定是否允许用户访问相应的应用程序编程接口，即确定是否对用户进行授权。由于目标用户端已配置授权模型，因此可以利用目标用户端对应的授权模型确定是否对用户进行授权。

在步骤203中，根据访问信息和目标授权模型确定是否对用户进行授权。

可以理解的是，通过对访问信息进行解析，可以得到用户想要访问的应用程序编程接口，而目标授权模型中通常预先定义好授权规则，因此可以根据访问信息和目标授权模型确定是否对用户进行授权。

本申请实施例通过为目标软件的每一类用户端配置至少一种授权模型；响应于用户基于目标用户端输入的针对应用程序编程接口的访问信息，将所述目标用户端对应的授权模型作为目标授权模型；根据所述访问信息和所述目标授权模型确定是否对用户进行授权。通过本申请提供的技术方案能够对目标软件不同类型用户端的用户进行个性化的授权管理，使每一类用户端的用户拥有不同的应用程序编程接口访问权限。

在一些实施例中，目标授权模型可以包括MBAC模型，在配置MBAC模型之前，可以根据目标软件的功能信息确定MBAC模型中的菜单；确定MBAC模型中的角色；确定MBAC模型中的角色与菜单的第一关联关系和第二关联关系，其中，第一关联关系用于表征角色对菜单的查看权限，第二关联关系用于表征角色对菜单对应的应用程序编程接口的访问权限。

在实现过程中，可以将目标软件的每一个功能或者每一组功能定义为一个菜单，并根据用户的职责和权限需求定义不同的角色，再将菜单与角色进行关联，每个角色可以关联一个或多个菜单，以控制用户对相应功能的访问权限。

需要说明的是，当菜单为一组功能时，可以采用子菜单的形式表征一组功能中的具体功能，例如菜单为“设备列表”，其子菜单为“添加设备”、“删除设备”以及“修改设备”，在此情况下，每个菜单会对应多个子菜单，进而也会对应多个应用程序编程接口。

图3示出了一个实施例中MBAC模型的原理示意图。如图3所示，一个角色可以对应多个不同的用户，一个菜单可以对应多个不同的应用程序编程接口，将每个角色与菜单进行关联，可以确定每个角色对菜单的查看或访问权限。进一步地将每个角色与菜单对应的应用程序编程接口进行关联，可以确定每个角色对应用程序编程接口的访问权限，实现了对目标软件的功能的精细化访问控制。

在利用MBAC模型确定是否对用户进行授权时，可以根据用户基于目标用户端输入的登录信息确定目标角色；根据访问信息确定目标应用程序编程接口；根据目标角色、目标应用程序编程接口和第二关联关系确定是否允许用户访问目标应用程序编程接口。

在实现过程中，用户可以在目标用户端输入登录信息，在登录成功后输入访问信息。通过对登录信息进行解析可以得到用户的角色(即目标角色)，通过对访问信息进行解析，可以得到用户想要访问的应用程序编程接口(即目标应用程序编程接口)。根据目标角色和第二关联关系可以确定目标角色允许访问的应用程序编程接口集合，如果应用程序编程接口集合中包括目标应用程序编程接口，则允许用户访问，否则，不允许用户访问。

在根据用户基于目标用户端输入的登录信息确定目标角色之后，还可以根据第一关联关系确定目标角色对应的菜单；输出目标角色对应的菜单的显示界面。

可以理解的是，在确定了目标角色对应的菜单后，可以生成包含有目标角色对应的菜单的显示界面，并输出该显示界面，这样用户在登录软件后，只能看到其角色被授权的菜单，其他菜单将被隐藏或禁用。

通过利用MBAC模型对用户进行授权判断，可以保障只有经过授权的用户才能访问目标软件的特定功能，实现了目标软件的功能的精细化授权，提高了目标软件的安全性。

在一些实施例中，目标授权模型可以包括RBAC模型，在为目标软件的每一类用户端配置至少一种授权模型之前，还可以确定RBAC模型中的角色；根据目标用户端对应的应用程序编程接口确定多个应用程序编程接口集合；确定RBAC模型中的角色与每个应用程序编程接口集合的第三关联关系，其中，第三关联关系用于表征角色对应用程序编程接口集合的访问权限。

在实现过程中，可以根据用户的职责和权限需求定义不同的角色，例如定义“管理员”角色、“组长”角色、“设备管理员”角色等。在定义角色时还可以考虑角色之间的关系，父角色(例如“管理员”)可以自动得到子角色(例如“设备管理员”)的全部权限。定义完角色后，可以将角色分配给用户，一个用户可以拥有多个角色，拥有的权限是所有角色的并集，例如一个用户可以同时拥有“招商管理员”和“商户管理员”等多个角色，该用户同时具有“招商管理员”的权限和“商户管理员”的权限。

可以理解的是，目标用户端可以支持多种应用程序编程接口，对这些应用程序编程接口进行分组，可以得到多个应用程序编程接口集合，将每个应用程序编程接口集合与角色进行关联，确保每个角色只有其对应的应用程序编程接口集合的访问权限。在将每个应用程序编程接口集合与角色进行关联后，还可以根据行为日志监控用户的访问行为，定期审计每个角色对应用程序编程接口集合的权限，并根据需要更新角色和权限，以确保软件系统安全。

图4示出了目标授权模型包括RBAC模型时步骤203的细节示意图。如图4所示，根据访问信息和目标授权模型确定是否对用户进行授权，可以包括以下步骤：

步骤401，根据用户基于目标用户端输入的登录信息确定目标角色；

步骤402，根据访问信息确定目标应用程序编程接口；

步骤403，在目标用户端对应的应用程序编程接口和至少一个应用程序编程接口集合中均包括目标应用程序编程接口的情况下，根据第三关联关系，确定目标应用程序编程接口所在的应用程序编程接口集合对应的角色；

步骤404，根据目标角色或目标角色的子角色中是否包括目标应用程序编程接口所在的应用程序编程接口集合对应的角色，对应确定是否允许用户访问目标应用程序编程接口。

在实现过程中，用户可以在目标用户端输入登录信息，在登录成功后输入访问信息。通过对登录信息进行解析可以得到用户的角色(即目标角色)，通过对访问信息进行解析，可以得到用户想要访问的应用程序编程接口(即目标应用程序编程接口)。

如果目标用户端对应的应用程序编程接口不包括目标应用程序编程接口，则不允许用户访问目标应用程序编程接口，否则需要进一步判断目标应用程序编程接口是否在至少一个应用程序编程接口集合中。如果目标应用程序编程接口不在至少一个应用程序编程接口集合中，则允许用户访问，否则需要根据第三关联关系，确定目标应用程序编程接口所在的应用程序编程接口集合对应的角色。如果目标角色或目标角色的子角色中包括目标应用程序编程接口所在的应用程序编程接口集合对应的角色，则允许用户访问，否则不允许用户访问。

通过利用RBAC模型对用户进行授权判断，可以减少权限的滥用和误用，提高目标软件的安全性和响应速度。

在一些实施例中，目标授权模型可以包括ABAC模型，在为目标软件的每种用户端配置至少一种授权模型之前，还可以确定ABAC模型中的主体属性、客体属性和环境属性；将主体属性、客体属性、环境属性和访问结果组合，得到ABAC模型中的访问策略。

其中，主体属性可以为用户属性，如用户的角色、组织机构等；客体属性可以为资源属性，如资源类型、资源所有者等；环境属性可以为访问时间、IP地址、设备信息等。

访问策略可以基于属性之间的关系按照实际需求制订，例如访问策略可以为：当满足角色为管理员、资源类型为文件、且访问时间为2024年时，允许用户访问。访问策略可以使用规则引擎或访问控制语言进行定义。

图5示出了目标授权模型包括ABAC模型时步骤203的细节示意图。如图5所示，根据访问信息和目标授权模型确定是否对用户进行授权，可以包括以下步骤：

步骤501，根据用户基于目标用户端输入的登录信息确定目标角色；

步骤502，根据访问信息确定目标应用程序编程接口和目标环境；

步骤503，将主体属性为目标角色，客体属性为目标应用程序编程接口且环境属性为目标环境的访问策略作为目标访问策略，并根据目标访问策略中的访问结果确定是否允许用户访问目标应用程序编程接口。

在实现过程中，用户可以在目标用户端输入登录信息，在登录成功后输入访问信息。通过对登录信息进行解析可以得到用户的角色(即目标角色)，通过对访问信息进行解析，可以得到用户想要访问的应用程序编程接口(即目标应用程序编程接口)和用户的访问环境(即目标环境)。

遍历所有的访问策略，以查询是否命中主体属性为目标角色，客体属性为目标应用程序编程接口且环境属性为目标环境的访问策略，如果未命中，则不允许用户访问；如果命中多条访问策略，则选取优先级最高的访问策略。在命中访问策略的情况下，如果访问策略中的访问结果是允许访问，则允许用户访问，否则不允许用户访问。在对用户进行授权判断后，还可以记录访问结果，以便于后续的审计和追踪。

通过利用ABAC模型对用户进行授权判断，可以基于具体的主体属性、客体属性和环境属性进行访问控制，使得访问控制更加动态和实时，实现了更精细化和动态的权限管理。

在一些实施例中，在为为目标软件的每一类用户端配置授权模型时，可以为目标软件的每一类用户端配置一种授权模型，且每一类用户端对应的授权模型各不相同；或，为目标软件的每一类用户端配置多种授权模型。

以目标软件部署在手机App端、微信小程序端和Web端三类用户端为例，可以分别为手机App端配置ABAC模型、微信小程序端配置RBAC模型、Web端配置MBAC模型，也可以为手机App端配置RBAC模型和ABAC模型、为微信小程序端配置RBAC模型ABAC模型、为Web端配置RBAC模型、ABAC模型和MBAC模型。

可以理解的是，RBAC模型存在一些潜在的缺点，包括：1、复杂性：在大规模软件系统中，角色和权限的维护需要精确的规划和管理，以确保正确的权限分配和避免冗余或过度授权；2、灵活性限制：由于角色是预先定义的，该模型无法提供细粒度高的权限控制；3、难以应对动态环境：在一些动态环境中，用户的角色和权限可能需要频繁变更，RBAC模型无法快速适应这些变更；4、风险扩散：如果一个角色被授予了过多的权限，那么一旦该角色被滥用或受到攻击，该角色的所有用户都会受到影响，进而会带来较大的安全风险。

ABAC模型也存在一些潜在的缺点，包括：需要定义和维护大量的属性和策略规则；ABAC模型的访问决策需要评估多个属性，这可能会引入额外的性能开销；配置的结果以规则引擎的形式呈现，不能直观的反应权限关系，可读性较差。

通过为每一类用户端配置不同的授权模型，可以实现为不同类型用户端的用户授予不同的权限，而通过为同一类用户端配置多种授权模型，不仅可以最大限度地发挥不同授权模型的优势，而且还可以减少潜在的缺点对软件系统的影响。

在为目标软件的每一类用户端配置多种授权模型之后，可以为目标软件的每一类用户端配置授权决策规则，其中，授权决策规则包括：在一种授权模型对应的授权结果为允许用户访问的情况下对用户进行授权、在全部授权模型对应的授权结果均为允许用户访问的情况下对用户进行授权、或在多数授权模型对应的授权结果为允许用户访问的情况下对用户进行授权。

针对授权决策规则中的第三种情况，如果授权模型的数量为n且n为偶数，那么如果授权结果为允许用户访问的授权模型的数量达到n/2，则对用户进行授权；如果n为奇数，那么如果授权结果为允许用户访问的授权模型的数量达到n/2+1，则对用户进行授权。

图6示出了目标授权模型为多种授权模型时步骤203的细节示意图。如图6所示，根据访问信息和目标授权模型确定是否对用户进行授权，可以包括以下步骤：

步骤601，根据访问信息确定目标授权模型中每种授权模型的授权结果；

步骤602，根据每种授权模型的授权结果和授权决策规则，确定是否对用户进行授权。

在实现过程中，可以参照前述实施例确定MBAC模型、RBAC模型和ABAC模型的授权结果，在此不再赘述。以下结合图7介绍如何确定是否对用户进行授权。

如图7所示，手机App端配置了RBAC模型和ABAC模型，并且配置了“最少允许”(即在一种授权模型对应的授权结果为允许用户访问的情况下对用户进行授权)的授权决策规则。当用户通过手机App访问目标软件的后端服务时，RBAC模型的授权结果为允许用户访问后端服务对应的应用程序编程接口，ABAC模型授权结果为不允许用户访问后端服务对应的应用程序编程接口，由于授权决策规则是“最少允许”，所以最终允许用户访问后端服务。

微信小程序端配置了RBAC模型和ABAC模型，并且配置了“全部允许”(即在全部授权模型对应的授权结果均为允许用户访问的情况下对用户进行授权)的授权决策规则。当用户通过微信小程序访问目标软件的后端服务时，RBAC模型授权结果为允许用户访问后端服务对应的应用程序编程接口，ABAC模型授权结果为不允许用户访问后端服务对应的应用程序编程接口，由于授权决策规则是“全部允许”，所以最终不允许用户访问后端服务。

Web端配置了RBAC模型、ABAC模型和MBAC模型，并且配置了“多数允许”(即在多数授权模型对应的授权结果为允许用户访问的情况下对用户进行授权)的授权决策规则。当用户通过网页访问目标软件的后端服务时，RBAC模型授权结果为允许用户访问后端服务对应的应用程序编程接口，ABAC模型授权结果为允许用户访问后端服务对应的应用程序编程接口，MBAC模型授权结果为允许用户访问后端服务对应的应用程序编程接口，由于授权决策规则是“多数允许”，所以最终允许用户访问后端服务。

通过为用户端配置多种授权模型，并配置授权决策规则，进而对用户进行授权决策，有效减少了各授权模型潜在的缺点对软件系统的影响，提高了用户权限管理的灵活性和可靠性。

以下介绍本申请的装置实施例，可以用于执行本申请上述实施例中的用户权限管理方法。对于本申请装置实施例中未披露的细节，请参照本申请上述的用户权限管理方法的实施例。

图8示出了本申请实施例中的用户权限管理装置的框图。如图8所示，本申请实施例的用户权限管理装置，包括：授权模型配置模块801、授权模型确定模块802和用户授权模块803，其中，授权模型配置模块801，用于为目标软件的每一类用户端配置至少一种授权模型；授权模型确定模块802，用于响应于用户基于目标用户端输入的针对应用程序编程接口的访问信息，将目标用户端对应的授权模型作为目标授权模型；用户授权模块803，用于根据访问信息和目标授权模型确定是否对用户进行授权。

在本申请的一些实施例中，基于前述方案，授权模型包括基于菜单的权限访问控制MBAC模型、基于角色的权限访问控制RBAC模型和基于属性的权限访问控制ABAC模型中的至少一种。

在本申请的一些实施例中，基于前述方案，授权模型配置模块801还用于根据目标软件的功能信息确定MBAC模型中的菜单；确定MBAC模型中的角色；确定MBAC模型中的角色与菜单的第一关联关系和第二关联关系，其中，第一关联关系用于表征角色对菜单的查看权限，第二关联关系用于表征角色对菜单对应的应用程序编程接口的访问权限。

在本申请的一些实施例中，基于前述方案，用户授权模块803，还用于根据用户基于目标用户端输入的登录信息确定目标角色；根据访问信息确定目标应用程序编程接口；根据目标角色、目标应用程序编程接口和第二关联关系确定是否允许用户访问目标应用程序编程接口。

在本申请的一些实施例中，基于前述方案，用户授权模块803，还用于根据第一关联关系确定目标角色对应的菜单；输出目标角色对应的菜单的显示界面。

在本申请的一些实施例中，基于前述方案，授权模型配置模块801还用于确定RBAC模型中的角色；根据目标用户端对应的应用程序编程接口确定多个应用程序编程接口集合；确定RBAC模型中的角色与每个应用程序编程接口集合的第三关联关系，其中，第三关联关系用于表征角色对应用程序编程接口集合的访问权限。

在本申请的一些实施例中，基于前述方案，用户授权模块803，还用于根据用户基于目标用户端输入的登录信息确定目标角色；根据访问信息确定目标应用程序编程接口；在目标用户端对应的应用程序编程接口和至少一个应用程序编程接口集合中均包括目标应用程序编程接口的情况下，根据第三关联关系，确定目标应用程序编程接口所在的应用程序编程接口集合对应的角色；根据目标角色或目标角色的子角色中是否包括目标应用程序编程接口所在的应用程序编程接口集合对应的角色，对应确定是否允许用户访问目标应用程序编程接口。

在本申请的一些实施例中，基于前述方案，授权模型配置模块801还用于确定ABAC模型中的主体属性、客体属性和环境属性；将主体属性、客体属性、环境属性和访问结果组合，得到ABAC模型中的访问策略。

在本申请的一些实施例中，基于前述方案，用户授权模块803，还用于根据用户基于目标用户端输入的登录信息确定目标角色；根据访问信息确定目标应用程序编程接口和目标环境；将主体属性为目标角色，客体属性为目标应用程序编程接口且环境属性为目标环境的访问策略作为目标访问策略，并根据目标访问策略中的访问结果确定是否允许用户访问目标应用程序编程接口。

在本申请的一些实施例中，基于前述方案，授权模型配置模块801还用于为目标软件的每一类用户端配置一种授权模型，且每一类用户端对应的授权模型各不相同；或，为目标软件的每一类用户端配置多种授权模型。

在本申请的一些实施例中，基于前述方案，授权模型配置模块801还用于为目标软件的每一类用户端配置授权决策规则，其中，授权决策规则包括：在一种授权模型对应的授权结果为允许用户访问的情况下对用户进行授权、在全部授权模型对应的授权结果均为允许用户访问的情况下对用户进行授权、或在多数授权模型对应的授权结果为允许用户访问的情况下对用户进行授权。

在本申请的一些实施例中，基于前述方案，用户授权模块803，还用于根据访问信息确定目标授权模型中每种授权模型的授权结果；根据每种授权模型的授权结果和授权决策规则，确定是否对用户进行授权。

基于同一发明构思，本申请实施例还提供了一种用户权限管理设备，参考图9，示出了本申请实施例中的用户权限管理设备的结构示意图，所述用户权限管理设备包括一个或多个存储器904、一个或多个处理器902及存储在存储器904上并可在处理器902上运行的至少一条计算机程序(计算机程序指令)，处理器902执行所述计算机程序时实现如前所述的方法。

其中，在图用户权限管理设备中，总线架构(用总线900来代表)，总线900可以包括任意数量的互联的总线和桥，总线900将包括由处理器902代表的一个或多个处理器和存储器904代表的存储器的各种电路链接在一起。总线900还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口905在总线900和接收器901和发送器903之间提供接口。接收器901和发送器903可以是同一个元件，即收发机，提供用于在传输介质上与各种其他装置通信的单元。处理器902负责管理总线900和通常的处理，而存储器904可以被用于存储处理器902在执行操作时所使用的数据。

基于同一发明构思，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序指令，所述计算机程序指令被处理器执行时，促使所述处理器实现如前所述的方法的步骤。

基于同一发明构思，本申请实施例提供了一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如前述方法实施例中任一实施例所述的用户权限管理方法。

本文中所描述的功能可在硬件、由处理器执行的软件、固件或其任何组合中实施。如果在由处理器执行的软件中实施，那么可将功能作为一或多个指令或代码存储于计算机可读媒体上或经由计算机可读媒体予以传输。其它实例及实施方案在本申请及所附权利要求书的范围及精神内。举例来说，归因于软件的性质，上文所描述的功能可使用由处理器、硬件、固件、硬连线或这些中的任何者的组合执行的软件实施。此外，各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

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

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

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

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

Claims (12)

1.一种用户权限管理方法，其特征在于，包括：

为目标软件的每一类用户端配置至少一种授权模型；

响应于用户基于目标用户端输入的针对应用程序编程接口的访问信息，将所述目标用户端对应的授权模型作为目标授权模型；

根据所述访问信息和所述目标授权模型确定是否对用户进行授权。

2.根据权利要求1所述的用户权限管理方法，其特征在于，所述授权模型包括基于菜单的权限访问控制MBAC模型、基于角色的权限访问控制RBAC模型和基于属性的权限访问控制ABAC模型中的至少一种。

3.根据权利要求2所述的用户权限管理方法，其特征在于，所述目标授权模型包括所述MBAC模型，在所述为目标软件的每一类用户端配置至少一种授权模型之前，所述方法还包括：

根据所述目标软件的功能信息确定所述MBAC模型中的菜单；

确定所述MBAC模型中的角色；

确定所述MBAC模型中的角色与菜单的第一关联关系和第二关联关系，其中，所述第一关联关系用于表征角色对菜单的查看权限，所述第二关联关系用于表征角色对菜单对应的应用程序编程接口的访问权限。

4.根据权利要求3所述的用户权限管理方法，其特征在于，所述根据所述访问信息和所述目标授权模型确定是否对用户进行授权，包括：

根据用户基于所述目标用户端输入的登录信息确定目标角色；

根据所述访问信息确定目标应用程序编程接口；

根据所述目标角色、所述目标应用程序编程接口和所述第二关联关系确定是否允许用户访问所述目标应用程序编程接口。

5.根据权利要求4所述的用户权限管理方法，其特征在于，在所述根据用户基于所述目标用户端输入的登录信息确定目标角色之后，所述方法还包括：

根据所述第一关联关系确定所述目标角色对应的菜单；

输出所述目标角色对应的菜单的显示界面。

6.根据权利要求2所述的用户权限管理方法，其特征在于，所述目标授权模型包括所述RBAC模型，在所述为目标软件的每一类用户端配置至少一种授权模型之前，所述方法还包括：

确定所述RBAC模型中的角色；

根据所述目标用户端对应的应用程序编程接口确定多个应用程序编程接口集合；

确定所述RBAC模型中的角色与每个应用程序编程接口集合的第三关联关系，其中，所述第三关联关系用于表征角色对应用程序编程接口集合的访问权限。

7.根据权利要求6所述的用户权限管理方法，其特征在于，所述根据所述访问信息和所述目标授权模型确定是否对用户进行授权，包括：

根据用户基于所述目标用户端输入的登录信息确定目标角色；

根据所述访问信息确定目标应用程序编程接口；

在所述目标用户端对应的应用程序编程接口和至少一个应用程序编程接口集合中均包括所述目标应用程序编程接口的情况下，根据所述第三关联关系，确定所述目标应用程序编程接口所在的应用程序编程接口集合对应的角色；

根据所述目标角色或所述目标角色的子角色中是否包括所述目标应用程序编程接口所在的应用程序编程接口集合对应的角色，对应确定是否允许用户访问所述目标应用程序编程接口。

8.根据权利要求2所述的用户权限管理方法，其特征在于，所述目标授权模型包括所述ABAC模型，在所述为目标软件的每种用户端配置至少一种授权模型之前，所述方法还包括：

确定所述ABAC模型中的主体属性、客体属性和环境属性；

将所述主体属性、所述客体属性、所述环境属性和访问结果组合，得到所述ABAC模型中的访问策略。

9.根据权利要求8所述的用户权限管理方法，其特征在于，所述根据所述访问信息和所述目标授权模型确定是否对用户进行授权，包括：

根据用户基于所述目标用户端输入的登录信息确定目标角色；

根据所述访问信息确定目标应用程序编程接口和目标环境；

将所述主体属性为所述目标角色，所述客体属性为所述目标应用程序编程接口且环境属性为所述目标环境的访问策略作为目标访问策略，并根据所述目标访问策略中的访问结果确定是否允许用户访问所述目标应用程序编程接口。

10.根据权利要求2所述的用户权限管理方法，其特征在于，所述为目标软件的每一类用户端配置至少一种授权模型，包括：

为所述目标软件的每一类用户端配置一种授权模型，且每一类用户端对应的授权模型各不相同；或，

为所述目标软件的每一类用户端配置多种授权模型。

11.根据权利要求10所述的用户权限管理方法，其特征在于，在所述为所述目标软件的每一类用户端配置多种授权模型之后，所述方法还包括：

为所述目标软件的每一类用户端配置授权决策规则，其中，所述授权决策规则包括：在一种授权模型对应的授权结果为允许用户访问的情况下对用户进行授权、在全部授权模型对应的授权结果均为允许用户访问的情况下对用户进行授权、或在多数授权模型对应的授权结果为允许用户访问的情况下对用户进行授权。

12.根据权利要求11所述的用户权限管理方法，其特征在于，所述根据所述访问信息和所述目标授权模型确定是否对用户进行授权，包括：

根据所述访问信息确定所述目标授权模型中每种授权模型的授权结果；

根据所述每种授权模型的授权结果和所述授权决策规则，确定是否对用户进行授权。