一种基于角色访问控制的权限管理方法及装置与流程

本申请涉及计算机技术领域，尤其涉及一种基于角色访问控制的权限管理方法及装置。

背景技术：

目前，常见的权限管理功能，可以基于角色访问控制(Role-Based Access Control，RBAC)技术实现。RBAC技术包含用户(USERS)、角色(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，权限赋予角色，角色指定给一个用户，此用户就拥有了该角色所具有的元操作的权限。其中，元操作，是最小的权限管理单元。

为了在用户请求执行某项元操作(如请求访问某统一资源定位符URL对应的网络资源)时，查询用户是否具备执行该项元操作的权限，按照现有的RBAC技术，会为用户分配角色标识，以使得后续可以根据用户具备的角色标识确定用户的角色，进而确定用户的角色具有的元操作的权限。

按照上述现有技术，只能建立起用户与角色标识的对应关系，因此在确定用户具有的元操作的权限时，只能依据该对应关系确定出用户的角色，进而确定用户的角色具备的元操作的权限，从而灵活性较低。比如，针对具备三个角色(角色标识分别为A、B和C)的用户而言，在确定该用户具备的元操作的权限时，只能根据用户与角色标识A、B和C的对应关系，先确定出用户的角色，而后确定用户的角色具备的元操作的权限，灵活性较低。

技术实现要素：

本申请实施例提供一种基于角色访问控制的权限管理方法，用以解决现有技术中的基于角色访问控制的权限管理方法仅能够建立用户与角色标识的对应关系，从而灵活性较低的问题。

本申请实施例还提供一种基于角色访问控制的权限管理装置，用以解决现有技术中的基于角色访问控制的权限管理方法仅能够建立用户与角色标识的对应关系，从而灵活性较低的问题。

本申请实施例采用下述技术方案：

一种基于角色访问控制的权限查询方法，该方法包括：

在用户执行目标元操作前，根据预先建立的用户与元操作的权限关系，判断所述目标元操作是否在用户的权限范围内；其中，所述元操作是最小的权限管理单元；所述用户与元操作的权限关系通过如下方式建立：用户与角色组之间的第一对应关系，用户具有所属角色组中各角色的权限，每一个角色具有至少一种元操作的权限；

如果是，则允许所述用户执行所述目标元操作，否则，拒绝所述用户执行所述目标元操作。

一种基于角色访问控制的权限查询装置，该装置包括：

判断模块，用于在用户执行目标元操作前，根据预先建立的用户与元操作的权限关系，判断所述目标元操作是否在用户的权限范围内；其中，所述元操作是最小的权限管理单元；所述用户与元操作的权限关系通过如下方式建立：用户与角色组之间的第一对应关系，用户具有所属角色组中各角色的权限，每一个角色具有至少一种元操作的权限；

执行模块，用于如果是，则允许所述用户执行所述目标元操作，否则，拒绝所述用户执行所述目标元操作。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

通过该方案，作为用户是否能够执行目标元操作的判断依据的所述权限关系，它的建立方式可以包括：用户与角色组之间的第一对应关系，用户具有所属角色组中角色的权限，每一个角色具有至少一种元操作的权限。也就是说，本方案中可以建立用户与角色组之间的对应关系，基于该对应关系，可以确定出用户具备所属角色组中角色具有的元操作的权限，从而在可以建立用户与角色(角色标识)之间的对应关系作为所述判断依据之外，还可以建立用户与角色之间的对应关系作为所述判断依据，因此解决了现有技术中的基于角色访问控制的权限管理方法仅能够建立用户与角色标识的对应关系，灵活性较低的问题。

附图说明

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

图1a为本申请实施例提供的一种基于角色访问控制的权限管理方法的流程图；

图1b为本申请实施例1中的第一对应关系～第四对应关系的示意图；

图2为本申请实施例提供的一种基于角色访问控制的权限管理方法中步骤103的具体流程图一；

图3a为本申请实施例中不同角色组的层级关系示意图；

图3b为本申请实施例中项目执行人员的层级关系示意图；

图4为本申请实施例提供的一种基于角色访问控制的权限管理方法中存在负向角色的角色组的组成图；

图5为本申请实施例提供的一种基于角色访问控制的权限管理方法中步骤103的具体流程图二；

图6为本申请实施例提供的一种基于角色访问控制的权限管理方法在实际中的一种实施场景示意图；

图7为本申请实施例提供的一种基于角色访问控制的权限管理装置的结构示意图。

具体实施方式

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

以下结合附图，详细说明本申请各实施例提供的技术方案。

实施例1

本申请实施例1提供一种基于角色访问控制的权限管理方法，该方法的执行主体，可以但不限于为服务器，或者，该方法的执行主体，可以但不限于手机、平板电脑、个人电脑(Personal Computer，PC)等能够被配置为执行本申请实施例提供的该方法的用户终端中的至少一种。

为了便于清楚的描述本申请实施例1提供的该方法，下文以方法的执行主体为服务器为例，详细介绍本申请实施例提供的方法。本领域技术人员可以理解，该方法的执行主体为服务器只是一种示例性说明，并不是对本方法的执行主体的具体限定。

具体的，实施例1提供的一种基于角色访问控制的权限管理方法的实现流程示意图如图1a所示。所述方法包括如下主要步骤：

步骤101：服务器在用户执行目标元操作前，根据预先建立的用户与元操作的权限关系，判断所述目标元操作是否在用户的权限范围内；若判断结果为是，则执行步骤102；若判断结果为否，则执行步骤103；

这里所说的用户，是指具备角色从而享有角色所具有的至少一种元操作的权限的对象。所述对象，可以是用户终端也可以是客户端。

这里所说的目标元操作，是指用户期望进行的元操作。用户可以通过向服务器发送请求(请求中可以包含目标元操作的唯一标识)的方式，请求服务器执行目标元操作，也即请求服务器运行用户执行目标元操作。服务器在接收到该请求后，响应于该请求，可以执行步骤101。

所述预先建立的用户与元操作的权限关系，包括通过角色组关联起来的用户与元操作的权限关系。在本实施例中，角色组，是角色构成的集合。本申请实施例中，角色组中一般包含至少两个角色。比如，角色A和角色B构成的集合，就是一个角色组。通过角色组关联起来的用户与元操作的权限关系，是指：用户与角色组之间的对应关系(后称第一对应关系)，用户具有用户所属角色组中各角色的权限。其中，角色组中的每一个角色具有至少一种元操作的权限。

本申请实施例中，用户与角色组之间的第一对应关系，可以是指用户与角色组标识之间的对应关系。其中，角色组标识，是指角色组具备的唯一标识符。

在本实施例中，针对每个用户，为了建立起用户与角色组标识之间的第一对应关系，可以预先根据用户的角色所属角色组为用户分配角色组标识。用户被分配角色组标识后，后续若期望查询自身具备的权限，则可以采用向服务器发送所述请求(该请求除包含所述目标元操作的唯一标识外，还可以包含用户的角色组标识)的方式，触发服务器执行如图1a所示的流程。

针对为用户分配角色组标识的具体实现方式而言，本实施例中，可以采用以下两种方式之一：

第一种，人工分配方式。

以某软件开发项目为例进行说明，假设对该项目所开发的代码进行的不同操作(增、删、改和查看)对应不同角色，每个角色具有相应的元操作的权限。比如，完成该项目所需要的角色包括代码增加角色(角色标识为Ⅰ，后将该角色简写为角色Ⅰ)、代码删除角色(角色标识为Ⅱ，后将该角色简写为角色Ⅱ)、代码修改角色(角色标识为Ⅲ，后将该角色简写为角色Ⅲ)和代码查看角色(角色标识为Ⅳ，后将该角色简写为角色Ⅳ)。其中，代码增加角色、代码增加角色和代码修改角色，分别具备对服务器保存的该项目的代码进行增、删、改(对代码进行增、删、改均为元操作)的权限；代码查看角色具备查看所述代码(查看所述代码也是一种元操作)的权限，但不能对所述代码进行增、删、改。

上述角色的标识以及关于角色具备的元操作的权限的文字描述，可以保存在服务器中；此外，参与该项目且待分配角色的项目执行人员的信息(如项目执行人员的名称和项目执行人员使用的个人电脑的IP地址)也可以保存在服务器中。保存在服务器中的该些信息，均可以由服务器展示在同一页面中，以便于该项目的管理人员进行查看；为了便于该项目的管理人员进行操作，该页面中还可以包含一些控件。

基于上述假设，该项目的管理人员可以通过对所述页面进行操作，将上述多个角色进行归类分组形成多个角色组——比如，管理人员可以选中所述页面中展示的角色标识，并点击页面中显示有文字“合并”的按钮一，使得服务器将被选中的角色标识对应的角色合并为一个角色组，而后，服务器为该角色组分配角色组标识。其中，服务器合并角色以及为角色组分配角色组标识，实质上就是建立角色组标识与角色标识的对应关系。

假设管理人员通过该操作，触发服务器合并得到两个角色组，这两个角色组各自的角色组标识分别为x和y。其中，角色组x中的角色包括角色Ⅰ和角色Ⅱ，即角色组标识映射角色标识Ⅰ和Ⅱ；角色组y中的角色包括角色Ⅲ和角色Ⅳ，即角色组标识映射角色标识Ⅲ和Ⅳ。

服务器在完成角色组标识x和y的分配后，可以显示分配的角色组标识x和y，若管理人员进一步选中x和y这两个标识，并点击页面中显示有文字“合并”的按钮二，则可以触发服务器合并x和y对应的这两个角色组，并为合并得到的角色组分配角色组标识z。

而后，管理人员根据项目需求，通过操作服务器，将角色组的标识分别分配给项目执行人员。比如，将x分配给项目执行人员1(姓名张三，对应的IP地址为192.168.1.07)，将y分配给项目执行人员2(姓名李四，对应的IP地址为192.168.1.08)。其中，这里所说的分配，其实质可以等同于建立起对应关系，即建立起x和张三以及192.168.1.07的对应关系，以及建立起y和李四以及192.168.1.08的对应关系；而分配的具体实现方式，比如可以包括：管理人员通过操作服务器先后选中x这一标识和项目执行人员张三的姓名及IP地址，然后点击“确定”按钮，则服务器建立起被选中的x、张三的姓名及IP地址的对应关系。至此，人工分配方式完毕。

为便于项目执行人员后续查询自身的具备的权限，服务器可以根据项目执行人员的IP地址，将项目执行人员被分配的项目组标识发送给项目执行人员。这样，当项目执行人员在查询自身具备的元操作的权限时，就可以根据获知的角色组标识查询服务器，以使得服务器根据角色组标识，确定与用户相对应的角色组，进而根据与用户相对应的角色组中角色具有的元操作的权限，判断所述目标元操作是否在用户的权限范围内。具体而言，当与用户相对应的角色组中角色具有的元操作的权限中，存在与所述目标元操作相匹配的元操作的权限时，判定所述目标元操作在用户的权限范围内；否则，判定所述目标元操作不在用户的权限范围内。

需要特别说明的是，在软件开发项目中，项目执行人员之间可能会有不同层级关系，具备层级关系的项目执行人员，他们各自的角色组标识对应的角色组之间往往也存在一定的层级关系。管理人员在为项目执行人员分配角色组标识时，可以基于管理人员所获知的项目执行人员之间的层级关系，为项目执行人员分配具备层级关系的角色组的角色组标识。

请参照图3a，为申请实施例中不同角色组的层级关系示意图。图3a中共存在三个层级的角色组，从上至下依次包含第一层角色组、第二层角色组和第三层角色组，其中，层级相对而言最靠近角色的角色组，可称为底层角色组。结合项目执行人员的层级关系，以下对图3a中所示的层级关系进行介绍。

项目执行人员的层级关系，如图3b所示。图3b中：

项目总经理处于最高的层级，对应于第一层角色组；

项目1经理和项目2经理所处层级低于项目总经理所在层级，对应于第二层角色组，其中，项目2经理也对应于底层角色组；

项目1组长1和项目1组长2所处层级低于项目1经理和项目2经理所处层级，对应于第三层角色组，也对应于底层角色组。

本申请实施例中，管理人员可以预先获知如图3b所示的层级关系，从而基于该层级关系，通过操作服务器实现为项目执行人员分配角色组标识，并建立起如图3a所示的层级关系。

继续沿用上例，假设服务器当前已经完成了为不同的角色组分配角色组标识x、y和z，以下对管理人员如何通过操作服务器实现建立起如图3a所示的层级关系进行介绍：

由于管理人员获知如图3b所示的层级关系，并且，也获知第一层角色组1的角色组标识(比如为z)，那么，管理人员可以通过操作服务器，将z分配给项目总经理。按照类似的操作方式，管理人员可以实现为如图3b所示的各项目执行人员分配相应的角色组标识。在这样的情况下，服务器除了可以保存各项目执行人员的信息(如姓名、IP地址等)、角色组标识、角色组中包含的角色的角色标识的对应关系外，还可以保存如图3a所示的层级关系，以方便后续查询角色组之间的层级关系。

以下，对保存的如图3a所示的层级关系如何发挥它的作用，进行详细介绍。

由前文的介绍可知，在本实施例中，每个角色组都有与其对应的角色组标识，角色组标识用于标识角色组，因此，服务器根据用户发送来的请求中包含的角色组标识，可以确定出具备角色组标识的角色组。比如，服务器中保存有分别具备角色组标识x、y和z的角色组，而用户发送来的角色组标识为z，那么，服务器就可以根据角色组标识z，从服务器保存的几个角色组中，确定出角色组标识为z的角色组。在本实施例中，为便于区分描述，将确定出的具备该角色组标识的角色组称为第一角色组。

本实施例中，针对“第一角色组包含的角色”具体而言，如图3a所示，假设第一角色组为第一层角色组1，那么，层级位于第一层角色组1以下，且包含于第一层角色组1的各角色组包含的角色(角色A、角色B、角色C、角色D和角色E)，都是第一角色组包含的角色；假设第一角色组为第二层角色组2，那么，第二层角色组2所包含的角色(角色C和角色D)，都是第一角色组包含的角色。第一角色组包含的角色，一般地，可以指第一角色组包含的角色标识。需要说明的是，图3a中的第二层角色组1、第二层角色组2、第三层角色组1和第三层角色组2，均为包含于第一层角色组1的角色组。其中，第二层角色组1和第二层角色组2，可以理解为直接包含于第一层角色组1的角色组；而第三层角色组1和第三层角色组2，可以理解为间接包含于第一层角色组1的角色组。

在本实施例中，服务器可以将第一角色组包含的各角色分别对应的全部元操作的权限，确定为用户具备的权限范围包含的权限，或者，服务器也可以随机将第一角色组包含的各角色分别对应的权限中的部分元操作的权限，确定为用户具备的元操作的权限。比如，第一角色组包含角色A和角色B，角色A拥有元操作的权限a1～a10，角色B拥有元操作的权限b1～b10。服务器可以将元操作的权限a1～a10和b1～b10确定为用户的元操作的权限；或者，服务器将元操作的权限a1～a10确定为用户的元操作的权限；或者，服务器可以将元操作的权限b1～b10确定为用户的元操作的权限；再或者，服务器可以将元操作的权限a1～a5和b6～b10确定为用户的元操作的权限；等等。

进一步的，若角色组集合包含的各角色组之间具有层级关系(如图3a所示)，则步骤101具体包括如图2所示的如下步骤：

步骤201、服务器根据所述第一对应关系，确定用户对应的第一角色组；

该步骤201的具体实现方式已经在前文进行介绍，此处不再赘述。

步骤202、服务器根据角色组集合包含的各角色组之间的层级关系，以及第一角色组，从角色组集合中确定满足预定条件的各底层角色组。

这里所说的角色组集合，是由角色组构成的集合。如图3a所示，第一层角色组1、第二层角色组1、第二层角色组2、第三层角色组1和第三层角色组2，就构成一个角色组集合。如前文所述，服务器可以预先保存该角色组集合中不同角色组之间的层级关系以备后续查询。

这里所说的底层角色组，如前文举例所述，是仅包含角色而不再包含其他角色组的角色组，比如，图3a中第三层角色组1、第三层角色组2和第二层角色组2均为底层角色组。

在本实施例中，预定条件包括：层级低于第一角色组，且包含于第一角色组。其中，层级低于第一角色组且包含于第一角色组的理解，在此举例进行说明：如图3a中，第二层角色组1和第二层角色组2均层级低于第一层角色组1，第三层角色组1和第三层角色组2均层级低于第二层角色组1。

在本实施例中，以第一角色组为第二层角色组1为例，第三层角色组1和第三层角色组2均层级低于第二层角色组1，第三层角色组1包含于第二层角色组1。因此，第三层角色组1为满足预定条件的底层角色组。

步骤203、根据所述各底层角色组分别包含的角色所具有的各元操作的权限，判断所述目标元操作是否在用户的权限范围内。

在本实施例中，以第一角色组为第二层角色组1为例，通过执行步骤202，可以确定出第三层角色组1和第三层角色组2为满足预定条件的底层角色组。

在本实施例中，服务器可以将第三层角色组1和第三层角色组2包含的各角色分别具备的全部元操作的权限，确定为用户具备的元操作的权限，或者，服务器也可以随机将第三层角色组1和第三层角色组2包含的各角色分别对应的权限中的部分权限，确定为用户具备的元操作的权限。比如，第三层角色组1包含角色A和角色B，角色A拥有权限a1～a10，角色B拥有权限b1～b10。服务器可以将权限a1～a10和b1～b10确定为用户具备的元操作的权限；或者，服务器将权限a1～a10确定为用户具备的元操作的权限；或者，服务器可以将权限b1～b10确定为用户具备的元操作的权限；再或者，服务器可以将权限a1～a5和b6～b10确定为用户具备的元操作的权限；等等。用户所具备的所有元操作的权限，构成用户的权限范围。

基于用户具备的元操作的权限，可以进一步判断所述目标元操作是否与用户具备的元操作的权限范围相匹配。

举例而言，当所述元操作包括操作指定的统一资源标识符(URL)对应的网络资源，所述用户的权限范围包括用户具备操作权限的网络资源的URL时，在一种实施方式中，上述步骤203的具体实现方式可以包括：

将确定出的所述用户具备操作权限的网络资源的URL与所述目标元操作对应的URL进行比对；

当所述用户具备操作权限的网络资源的URL中，存在与所述目标元操作对应的URL相匹配的URL时，判定所述目标元操作在所述用户的权限范围内；否则，判定所述目标元操作未在所述用户的权限范围内。

举例而言，可以采用以下两种方式判断用户具备操作权限的网络资源的URL中，是否存在与所述目标元操作对应的URL相匹配的URL：

第一种，全匹配方式：服务器将确定的用户的权限对应的资源标识与用户发送来的请求访问的资源的标识进行比对，以获得标识比对结果。具体实现为，以web应用为例，若用户请求访问的URL与确定的用户权限的URL完全相同，则判定用户具备操作权限的网络资源的URL中存在与所述目标元操作对应的URL相匹配的URL。例如：用户请求访问的URL为:/user/view/btime，若用户请求访问的资源标识与确定的用户权限对应的资源标识一致，则允许用户访问与“/user/view/btime”对应的信息。

第二种，前缀匹配方式：若用户请求访问的操作的通配符(该通配符以字符串为前缀，以*结尾)与确定的用户权限对应的通配符(该通配符以字符串为前缀，以*结尾)的字符串相同，则判定用户具备操作权限的网络资源的URL中存在与所述目标元操作对应的URL相匹配的URL。

进一步的，为了使用户获知自身具备的角色的权限，服务器在根据第一角色组包含的各角色分别对应的权限，确定用户的权限后，还可以向用户发送权限列表。具体的，服务器根据确定出的用户的权限，向用户发送权限列表。其中，权限列表包含权限的信息。例如，用户具有查看权限、宣传权限、修改权限等，服务器将向用户反馈其具备查看查看权限、宣传权限、修改权限，及权限范围、宣传权限范围、修改权限范围，等等。本方法实施例通过将用户的权限列表反馈给用户，使得用户可以明确获知自己的权限，有效避免用户做无效工作，提高用户的工作效率。

第二种，服务器自动分配方式。

在一种实施方式中，以网络广告公司为例，假设待分配角色组标识的对象，是该网络广告公司的客户(后称广告客户)。那么，可以在服务器内预先存储广告客户等级的标识和角色组标识的对应关系。其中，这里所说的客户等级，比如可以有高、中、低三类，这三类广告客户的客户等级可以从提供给这三类广告客户分别用于登录服务器的账号中表现出来。比如高等级广告客户的账号以数字“00”开头；中等级广告客户的账号以数字“01”开头；低等级广告客户的账号以数字“02”开头。由于账号可以体现广告客户的等级，因此所述账号可以作为广告客户等级的标识。提供账号给广告客户的方式可以有多种，比如在网络广告公司与广告客户签订合作合同时，可以以书面形式告知账号，本申请实施例对此不作限定。

基于上述假设，若某广告客户希望被分配角色组标识，则可以将该广告客户自身被分配的账号发送给服务器。服务器根据接收到的该账号，通过查询账号(广告客户等级的标识)和角色组标识的对应关系，就可以确定该广告客户对应的角色组标识，并将该角色组标识分配给该广告客户。

当然，本申请实施例中，视具体应用场景的不同，还可以采用其他方式实现为待分配角色组标识的对象分配角色组标识，本申请实施例对此不作限定。

本申请实施例中，作为用户是否能够执行目标元操作的判断依据的所述权限关系(即用户与元操作的权限关系)，它的建立方式可以包括：用户与角色组之间的第一对应关系，用户具有所属角色组中角色的权限，每一个角色具有至少一种元操作的权限。也就是说，本方案中可以建立用户与角色组之间的对应关系，基于该对应关系，可以确定出用户具备所属角色组中角色具有的元操作的权限，从而在可以建立用户与角色(角色标识)之间的对应关系作为所述判断依据之外，还可以建立用户与角色之间的对应关系作为所述判断依据，因此解决了现有技术中的基于角色访问控制的权限管理方法仅能够建立用户与角色标识的对应关系，灵活性较低的问题。

需要说明的是，为了进一步提升建立的所述判断依据的灵活性，本申请实施例中，用户与元操作的权限关系，还可以包括如下方式之一或者任意组合：

1、用户与负向角色之间的第二对应关系；

其中，所述负向角色是指用户不具备的角色；每一个所述负向角色具有至少一种元操作的权限，用户不具有对应的负向角色中各元操作的权限。

2、用户与角色之间的第三对应关系；

其中，用户具有对应的角色中各元操作的权限。

4、用户与元操作之间的第四对应关系。

其中，所述第四对应关系中用户直接映射于元操作的权限。

本申请实施例1中所述的第一对应关系～第四对应关系的示意图，如图1b所示。由图1b可以看出，针对同一用户而言，针对该用户可以建立起的用户与元操作的权限关系，可以包括但不限于用户与角色组的第一对应关系、用户与负向角色的第二对应关系、用户直接映射于角色而得到的用户与角色的第三对应关系以及用户直接映射于元操作的权限而得到的第四对应关系这四种对应关系中的至少一种。因此，如上文所述，采用本申请实施例提供的方案，能够提升建立的作为所述判断依据的权限关系的灵活性。在实际应用中，管理人员可以视实际需求，选择采用这四种对应关系中的至少一种，作为用户与元操作之间的权限关系。

以下说明，在用户与元操作的权限关系还包括上述第二对应关系、第三对应关系及第四对应关系中的任意一种时，服务器如何在执行完毕前述步骤202后，在执行步骤203之前，确定出用户的权限范围，以便判断目标元操作是否在确定用户的权限范围内。

当步骤101中所述的用户与元操作的权限关系还包括用户与负向角色之间的第二对应关系时，在上述步骤202执行完毕之后，在执行步骤203之前，服务器还可以执行步骤：在所述各底层角色组分别包含的角色所具有的各元操作中，删除所述负向角色所具有的各元操作。若所述的用户与元操作的权限关系，仅包括所述第一对应关系和所述第二对应关系，而不包括所述第三对应关系和所述第四对应关系，那么，在所述各底层角色组分别包含的角色所具有的各元操作中删除所述负向角色所具有的各元操作后，所剩余的元操作，构成用户的权限范围。

需要说明的是，在所述各底层角色组分别包含的角色所具有的各元操作中，删除所述负向角色所具有的各元操作的具体实现方式可以如图5所示，包括如下步骤：

步骤501、对用户的负向角色与确定出的所述各底层角色组分别包含的角色进行比对，以得到比对结果；

在本实施例中，所述负向角色为预先规定的、用户不应具备的角色。以第一角色组为第二层角色组1为例，如图3a中满足预定条件的各底层角色组为第三层角色组1和第三层角色组2。以第三层角色组1为例，假设第三层角色组1包含角色A和角色B，角色A为负向角色(如图4所示)；角色B为所述其他角色。那么，在本申请实施例中，可以将负向角色与角色A和角色B进行比对。

在实际应用中，负向角色，可以由管理员根据实际需求进行设置。比如，管理员可以将某用户的负向角色设置为A，以表示该用户不应具备角色A。

一般地，负向角色和非负向角色(也即正向角色)可以保存在不同的存储空间中，也即，负向角色的标识和非负向角色的标识可以保存在不同的存储空间中，以便服务器根据存储空间区分角色的标识是负向角色的标识还是正向角色的标识。

步骤502、根据比对结果，在所述各底层角色组分别包含的角色所具有的各元操作中，删除与所述负向角色一致的角色所具有的各元操作。

在本实施例中，继续沿用上例，根据通过执行步骤501得到的比对结果。当角色A与负向角色一致，将角色A删除，并将角色B对应的元操作的权限确定为用户具备的元操作的权限。

本申请实施例中，在能够为用户分配角色组标识的情况下，结合负向角色的使用，能够使得为用户分配角色具有了更大的灵活性，且同时能够兼顾避免过大的资源耗费。以下举例分析该效果是如何产生的。

按照现有技术，为各用户一一分配相应的各角色标识，会耗费较多的处理资源，尤其是在用户具备的角色较多的情况下，这个问题体现得尤为明显。比如，如果有10个用户均具备三个角色(角色标识分别为A、B和C)，那么，为了使得后续可以根据用户具备的角色标识确定用户的角色，需要为这10个用户分别分配角色标识A、B和C，从而总计会执行30次分配操作，耗费较多的处理资源。

而采用本申请实施例提供的方案，可以为用户分配角色组标识，由于角色组是角色构成的集合，因此相对于用户所对应的角色标识的数量而言，用户所对应的角色组标识的数量要小，从而相较于现有技术中的权限查询方法而言，采用本申请可以减少分配标识时所耗费的处理资源。

为了使得分配标识时耗费的处理资源较少，一般说来，角色组越少越好，因为这样可以使得能够被分配的角色组标识比较少。然而，对于形形色色的用户而言，他们可以具备的角色总是随着实际情况的变化有着不同的可能性，因此，如何兼顾减少分配标识时所耗费的处理资源以及角色分配的灵活性，成为亟待解决的问题。

本申请实施例中，引入了“负向角色”来指示用户不应具备的角色，从而，即便角色组包含的角色是相对固定不容易改变的，也可以通过负向角色，来调整用户所属角色组中的角色，使得不改变角色组数量(即不改变角色组标识的数量)的情况下，可以灵活地按照需求为用户进行角色分配。

当步骤101中所述的用户与元操作的权限关系还包括用户与角色之间的第三对应关系时，在上述步骤202执行完毕之后，在执行步骤203之前，服务器还可以执行步骤：在所述各底层角色组分别包含的角色所具有的各元操作中，增加所述第三对应关系中该角色所具有的各元操作。若所述的用户与元操作的权限关系，仅包括所述第一对应关系和所述第三对应关系，而不包括所述第二对应关系和所述第四对应关系，那么，在所述各底层角色组分别包含的角色所具有的各元操作中增加所述第三对应关系中该角色所具有的各元操作后，各底层角色组分别包含的角色所具有的各元操作以及增加的各元操作，共同构成用户的权限范围。

类似地，当步骤101中所述的用户与元操作的权限关系还包括用户与元操作之间的第四对应关系时，在上述步骤202执行完毕之后，在执行步骤203之前，服务器还可以执行步骤：在所述各底层角色组分别包含的角色所具有的各元操作中，增加所述第四对应关系中该角色所具有的各元操作。若所述的用户与元操作的权限关系，仅包括所述第一对应关系和所述第四对应关系，而不包括所述第二对应关系和所述第三对应关系，那么，在所述各底层角色组分别包含的角色所具有的各元操作中增加所述第四对应关系中该角色所具有的各元操作后，各底层角色组分别包含的角色所具有的各元操作以及增加的各元操作，共同构成用户的权限范围。

当然，所述用户与元操作的权限关系，除了包括所述第一对应关系外，还可以包括其他三种对应关系中的任意两种或全部三种。当所述用户与元操作的权限关系包括所述第二对应关系时，一般会在确定出的所述各底层角色组分别包含的角色所具有的各元操作中，删除与所述负向角色一致的角色所具有的各元操作；当所述用户与元操作的权限关系包括所述第三对应关系和/或第四对应关系时，一般会在确定出的所述各底层角色组分别包含的角色所具有的各元操作中，增加所述第三对应关系和/或第四对应关系中该角色所具有的各元操作。

步骤102：服务器允许所述用户执行所述目标元操作，流程结束；

步骤103：服务器拒绝所述用户执行所述目标元操作，流程结束。

需要说明的是，本申请实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也可由不同设备作为执行主体。

实施例2

本实施例2将以网络广告系统开发场景为例，综合说明上述实施例1提供的基于角色访问控制的权限查询的方法的实际应用流程。该场景所包含的设备可以为用户权限中心服务器2和输入显示设备3，如图6所示。

在本实施例2提供的网络广告系统开发场景下，基于角色访问控制的权限查询的方法的实现流程图如图6所示，包括如下步骤：

第一，用户权限中心服务器2建立的用户与元操作的权限关系，包括通过角色组关联起来的用户与元操作的权限关系。如用户与角色组1之间的对应关系；

第二，预先根据用户4的角色所属角色组为用户4分配角色组标识，其中，可以是人工为用户分配角色组标识，也可以是用户权限中心服务器为用户分配角色组标识；

第三，用户4将获知的角色组标识通过输入显示设备3输入，用户权限中心服务器2确定具备该角色组标识的角色组；

第四，用户权限中心服务器2根据该角色组包含的各角色分别对应的权限，确定用户4的权限；

第五，用户权限中心服务器2根据确定出的用户4的权限，向输入显示设备3发送权限列表；

第六，用户4通过输入显示设备3输入请求访问的资源的标识，用户权限中心服务器2根据请求访问的资源的标识与确定的用户4的权限对应的资源标识进行比对，获得比对结果并根据比对结果执行相应操作。

以上为本申请实施例提供的基于角色访问控制的权限查询的方法，基于同样的思路，本申请实施例还提供了相应的基于角色访问控制的权限管理装置，如图7所示。

图7为本申请实施例提供的基于角色访问控制的权限管理装置结构示意图，具体包括：

判断模块701，用于在用户执行目标元操作前，根据预先建立的用户与元操作的权限关系，判断所述目标元操作是否在用户的权限范围内；其中，所述元操作是最小的权限管理单元；所述用户与元操作的权限关系通过如下方式建立：用户与角色组之间的第一对应关系，用户具有所属角色组中各角色的权限，每一个角色具有至少一种元操作的权限；

执行模块702，用于如果判断模块得到的判断结果为是，则允许所述用户执行所述目标元操作，否则，拒绝所述用户执行所述目标元操作。

所述判断模块701包括：

第一角色组确定单元7011，用于根据所述第一对应关系，确定用户对应的第一角色组；

底层角色组确定单元7012，用于根据角色组集合包含的各角色组之间的层级关系，以及所述第一角色组，从所述角色组集合中确定满足预定条件的各底层角色组；其中，所述预定条件，包括：层级低于所述第一角色组，且包含于所述第一角色组；

判断单元7013，用于根据所述各底层角色组分别包含的角色所具有的各元操作的权限，判断所述目标元操作是否在用户的权限范围内。

其中，所述用户与元操作的权限关系还包括如下方式之一或者任意组合：

用户与负向角色之间的第二对应关系；所述负向角色是指用户不具备的角色；每一个负向角色具有至少一种元操作的权限，用户不具有对应的负向角色中各元操作的权限；

用户与角色之间的第三对应关系；用户具有对应的角色中各元操作的权限；

用户与元操作之间的第四对应关系；所述第四对应关系中用户直接映射于元操作的权限。

所述判断模块701还包括：

删除单元，用于当所述用户与元操作的权限关系还包括用户与负向角色之间的第二对应关系时，在判断单元根据所述各底层角色组分别包含的角色所具有的各元操作的权限，判断所述目标元操作是否在用户的权限范围内之前，在所述各底层角色组分别包含的角色所具有的各元操作中，删除所述负向角色所具有的各元操作；

第一增加单元，用于当所述用户与元操作的权限关系还包括用户与角色之间的第三对应关系时，在判断单元根据所述各底层角色组分别包含的角色所具有的各元操作的权限，判断所述目标元操作是否在用户的权限范围内之前，在所述各底层角色组分别包含的角色所具有的各元操作中，增加所述第三对应关系中该角色所具有的各元操作；

第二增加单元，用于当所述用户与元操作的权限关系还包括用户与元操作之间的第四对应关系时，在判断单元根据所述各底层角色组分别包含的角色所具有的各元操作的权限，判断所述目标元操作是否在用户的权限范围内之前，在所述各底层角色组分别包含的角色所具有的各元操作中，增加所述第四对应关系中该元操作。

其中，若所述元操作包括操作指定的统一资源标识符URL对应的网络资源；所述用户的权限范围，包括用户具备操作权限的网络资源的URL；则

所述判断单元701包括：

比对子单元，用于将确定出的所述用户具备操作权限的网络资源的URL与所述目标元操作对应的URL进行比对；

判定子单元，用于当所述用户具备操作权限的网络资源的URL中，存在与所述目标元操作对应的URL相匹配的URL时，判定所述目标元操作在所述用户的权限范围内；否则，判定所述目标元操作未在所述用户的权限范围内。

通过该方案，作为用户是否能够执行目标元操作的判断依据的所述权限关系，它的建立方式可以包括：用户与角色组之间的第一对应关系，用户具有所属角色组中角色的权限，每一个角色具有至少一种元操作的权限。也就是说，本方案中可以建立用户与角色组之间的对应关系，基于该对应关系，可以确定出用户具备所属角色组中角色具有的元操作的权限，从而在可以建立用户与角色(角色标识)之间的对应关系作为所述判断依据之外，还可以建立用户与角色之间的对应关系作为所述判断依据，因此解决了现有技术中的基于角色访问控制的权限管理方法仅能够建立用户与角色标识的对应关系，灵活性较低的问题。

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

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

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

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

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

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