CN107506658A

CN107506658A - 一种用户权限管理***及方法

Info

Publication number: CN107506658A
Application number: CN201710557928.3A
Authority: CN
Inventors: 麦林; 盛运林; 李心语; 黄涛; 彭庭坤; 王鹏; 杨; 杨�一
Original assignee: Shanghai Best Network Technology Co Ltd
Current assignee: Shanghai Best Network Technology Co Ltd
Priority date: 2017-07-10
Filing date: 2017-07-10
Publication date: 2017-12-22

Abstract

本发明公开了一种用户权限管理***及方法，其中，用户权限管理***包括：数据库，包括用于保存用户与角色的对应关系的用户角色关联表，用于保存角色与功能权限的对应关系的角色功能权限关联表和用于保存角色与数据权限的对应关系的角色数据权限关联表，功能权限用于确定可执行的功能，数据权限用于确定允许访问的数据；角色查询单元，用于查询用户角色关联表，获得在线用户对应的角色；功能权限查询单元，用于根据在线用户对应的角色查询角色功能权限关联表，以核实在线用户请求的功能是否可执行；数据权限查询单元，用于当在线用户请求的功能可执行，则根据在线用户对应的角色查询角色数据权限关联表，获得在线用户对应的数据权限。

Description

一种用户权限管理***及方法

技术领域

本发明涉及计算机技术领域，尤其涉及一种用户权限管理***及方法。

背景技术

随着计算机技术和互联网技术的发展，当今世界已经进入大数据时代。企业和政府越来越注重信息化建设和数据共享，如何保障信息和数据安全也因此格外受到重视。

企业和政府通常通过网站或应用软件等形式对外或对内提供各种服务和数据资源的访问。如果没有建立有效的权限管理机制，一旦用户访问到其权限范围外的服务、数据或者资源，无疑会带来极大的安全隐患。因此，必须通过权限管理功能，限制每个用户只能访问其被授权的数据和资源。

常见的权限管理方法包括：自主访问控制(DAC)、强制访问控制(MAC)、基于角色的访问控制(RBAC)等等。自主访问控制(DAC)允许客体的拥有者对其客体资源进行管理，客体的拥有者也可以向其它主体授予其拥有客体的访问权限，未授权主体对客体的访问是禁止的。强制访问控制(MAC)模型中，***强制主体服从访问策略，主体和客体都被标记了固定的安全属性，每次访问发生时，***会检测主体和客体的安全属性以确认主体是否有权限访问。基于角色的访问控制(RBAC)基本思想是向角色授予访问权限，用户通过被赋予不同角色从而获得角色所拥有的权限。RBAC与DAC和MAC的一个重要区别在于定义了角色的概念，使角色成为主体和客体之间的桥梁，通过角色可以更加灵活的控制主体对客体的访问权限，简化了权限管理工作。

基于角色的访问控制(RBAC)建立了用户、角色、权限三者的关系模型，如图1所示。然而，随着权限管理的应用场景日趋复杂，在很多应用场景中，需要管理越来越多的用户角色和处理大量数据、资源，RBAC的基本模型已经无法满足各种多变的实际应用场景需求。

因此，本领域的技术人员致力于开发一种更为合理和安全的用户权限管理***及方法。

发明内容

本发明所要解决的技术问题是现有的基于角色的访问控制无法满足越来越多变的实际应用场景需求。

为解决上述技术问题，本发明提供了一种用户权限管理***，包括：

数据库，包括用于保存用户与角色的对应关系的用户角色关联表，用于保存角色与功能权限的对应关系的角色功能权限关联表和用于保存角色与数据权限的对应关系的角色数据权限关联表，所述功能权限用于确定可执行的功能，所述数据权限用于确定允许访问的数据；

角色查询单元，用于查询所述用户角色关联表，获得在线用户对应的角色；

功能权限查询单元，用于根据所述在线用户对应的角色查询所述角色功能权限关联表，以核实所述在线用户请求的功能是否可执行；

数据权限查询单元，用于当所述在线用户请求的功能可执行，则根据所述在线用户对应的角色查询所述角色数据权限关联表，获得所述在线用户对应的数据权限。

进一步地，所述角色与数据权限的对应关系包括角色与行数据权限的对应关系和角色与列数据权限的对应关系。

进一步地，所述数据库还包括：用于保存与用户关联的功能权限和功能权限属性参数的用户功能权限属性表和用于保存与用户关联的数据权限和数据权限属性参数的用户数据权限属性表。

进一步地，所述数据权限属性参数包括数据行权限属性参数和数据列权限属性参数。

进一步地，所述数据库还包括用于保存与功能权限关联的显示信息的资源表；所述用户权限管理***还包括：资源提取单元，当所述在线用户请求的功能可执行，所述资源提取单元用于根据所述请求的功能对应的功能权限提取所述资源表中关联的显示信息。

进一步地，所述数据库还包括用于保存与功能权限关联的操作的功能操作表和用于保存与数据权限关联的操作对象的对象信息表；所述用户权限管理***还包括：执行单元，当所述在线用户请求的功能可执行，所述执行单元用于根据所述功能操作表和对象信息表执行所述在线用户请求的功能。

进一步地，所述数据库还包括：用于保存用户标识的用户表，用于保存角色标识的角色表，用于保存功能权限标识的功能权限表和用于保存数据权限标识的数据权限表。

为解决上述技术问题，本发明还提供了一种用户权限管理的方法，包括以下步骤：

预先建立数据库，所述数据库中包括用于保存用户与角色的对应关系的用户角色关联表，用于保存角色与功能权限的对应关系的角色功能权限关联表和用于保存角色与数据权限的对应关系的角色数据权限关联表，所述功能权限用于确定可执行的功能，所述数据权限用于确定允许访问的数据；

查询所述用户角色关联表，获得在线用户对应的角色；

根据所述在线用户对应的角色查询所述角色功能权限关联表，以核实所述在线用户请求的功能是否可执行；

当所述在线用户请求的功能可执行，则根据所述在线用户对应的角色查询所述角色数据权限关联表，获得所述在线用户对应的数据权限。

进一步地，所述数据库还包括用于保存与功能权限关联的显示信息的资源表；所述用户权限管理的方法还包括：当所述在线用户请求的功能可执行，根据所述请求的功能对应的功能权限提取所述资源表中关联的显示信息。

进一步地，所述数据库还包括用于保存与功能权限关联的操作的功能操作表和用于保存与数据权限关联的操作对象的对象信息表；所述用户权限管理方法还包括：当所述在线用户请求的功能可执行，根据所述功能操作表和对象信息表执行所述在线用户请求的功能。

本发明的用户权限管理***及方法，在基于角色的访问控制(RBAC)基础模型上改进，具有如下技术效果：

(1)将权限分为功能权限和数据权限，从功能和数据两个维度上对权限进行配置，权限配置更加灵活、准确；在管理用户操作行为时，先根据功能权限判断用户是否被允许执行操作，再根据数据权限限定用户可访问的数据范围，权限管理流程更合理、安全；因此本发明技术方案能够适应各种应用场合需求。

(2)在***可视化界面的显示上，将依赖于权限的资源拆分出来，配置资源和功能权限的映射关系，从而实现对可视化界面资源的独立配置，界面展示逻辑更加清晰。

(3)通过功能权限属性参数和数据权限属性参数，可以为配置同个角色的不同用户定制不同权限，使用户授予的权限更加精准，信息和数据资源更加安全有保障。

以下将结合附图对本发明的构思、具体结构及产生的技术效果作进一步说明，以充分地了解本发明的目的、特征和效果。

附图说明

图1是现有基于角色的访问控制的基础模型示意图；

图2是本发明用户权限管理***实施例一的示意图；

图3是本发明用户权限管理***实施例二的示意图；

图4是本发明用户权限管理***实施例三的示意图；

图5是本发明用户权限管理***的模型示意图；

图6是本发明用户权限管理***中数据库示意图；

图7是本发明用户权限管理***实施例三的关于功能权限具体实例说明示意图；

图8是本发明用户权限管理***实施例三的关于数据权限具体实例说明示意图。

具体实施方式

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

实施例一

图2是本发明用户权限管理***实施例一的示意图，如图2所示，本实施例的用户权限管理***包括数据库、角色查询单元、功能权限查询单元和数据权限查询单元。

数据库，包括用户角色关联表、角色功能权限关联表和角色数据权限关联表。

用户角色关联表，用于保存用户与角色的对应关系。

角色功能权限关联表，用于保存角色与功能权限的对应关系，其中功能权限用于确定可执行的功能。

角色数据权限关联表，用于保存角色与数据权限的对应关系，其中数据权限用于确定允许访问的数据。所述角色与数据权限的对应关系可以进一步包括角色与行数据权限的对应关系和角色与列数据权限的对应关系。

角色查询单元，用于查询用户角色关联表，获得在线用户对应的角色。

功能权限查询单元，用于根据在线用户对应的角色查询角色功能权限关联表，以核实在线用户请求的功能是否可执行。

数据权限查询单元，用于当在线用户请求的功能可执行，则根据在线用户对应的角色查询角色数据权限关联表，获得在线用户对应的数据权限。

实施例二

图3是本发明用户权限管理***实施例二的示意图，如图3所示，本实施例的用户权限管理***包括数据库、角色查询单元、功能权限查询单元和数据权限查询单元。

数据库，除了包括实施例一中的用户角色关联表、角色功能权限关联表和角色数据权限关联表，还包括用户表、角色表、功能权限表、数据权限表、功能操作表、和对象信息表这六个基本信息表。

结合图5所示，基于角色的访问控制(RBAC)的改进模型，包括用户、角色、功能权限、数据权限、操作和操作对象，对应于数据库中的用户表、角色表、功能权限表、数据权限表、功能操作表和对象信息表。

用户表，用于保存用户的基本信息，所述用户为***的使用者。如图6实例所示，用户表包括用户标识(ID)、用户名、密码等字段。

角色表，用于保存所有定义的角色的基本信息，角色是根据组织机构内的职务和岗位进行定义的，不同职务承担不同的职能，所需权限有很大的差异，而同样职务和岗位的用户，所需要的权限大致相同，所以以职务和岗位来划分角色。比如，财务岗位的角色需要对账、***管理等财务相关权限。人事岗位的角色需要员工信息、职级、工资管理等人事相关权限。如图6所示，角色表包括角色名、角色描述等字段。

功能权限表，用于保存所有定义的功能权限，功能权限指执行某项操作的许可。比如，运营岗位需要对官网新闻频道的内容进行管理，那么对应的功能权限包括“创建一条新闻”、“删除某条新闻”、“编辑某条新闻”等等。如图6所示，功能权限表包括功能权限码、功能权限名、功能权限描述等字段。

数据权限表，用于保存所有定义的数据权限，数据权限即允许访问的数据范围。许多操作的实质都是对数据的读或写，因此需要限定所允许访问的数据范围，在执行操作时根据数据权限进行限制。从数据库的角度细分，数据权限分为两个维度：行权限和列权限。行权限是指对数据库里某一条数据的访问许可。比如，一家公司分为全国、省、市三级市场，则可以定义全国、省、市三级数据权限，授予对应级别市场负责人。全国负责人可以查询全国范围的业绩、订单、用户信息等数据，省负责人只允许查看该省数据，城市负责人则只允许查看该城市数据。列权限是指对数据表里不同字段的访问许可。再比如，对于一家公司的员工职级和工资信息查询功能，人事负责人可以查看所有员工数据；部门负责人只允许查看该部门员工数据；普通员工只允许查看本人数据。这一点可以用行权限限制。但是，员工职级和工资信息中有一部分敏感信息，限公司人事和员工本人可见。那么可以定义工资摘要、工资详情两级数据权限，工资摘要权限允许访问工资信息中的非敏感字段，工资详情权限允许访问工资信息中的所有字段。用户拥有查询本人工资详情的权限；人事负责人有查询所有员工工资详情的权限，包括可以访问敏感信息；而部门负责人只有查询部门所有员工工资摘要的权限，不包括员工的敏感信息。如图6所示，数据权限表包括数据权限码、数据权限名、数据权限描述等字段。

功能操作表，用于保存所有定义的操作，对象信息表，用于保存所有定义的操作对象(也简称为对象)。操作和对象是权限概念中的两个元素，权限指执行某项操作的许可。比如，员工允许查询本人工资信息。在这条权限中，操作是查询行为，操作对象是工资信息。如图6所示，功能操作表包括功能码、功能名、功能权限码、功能描述等字段。通过功能操作表中的功能权限码与功能权限表中的功能权限码进行关联，标明该功能操作所归属的功能权限。同样的，对象信息表中包括数据权限码。通过对象信息表中的数据权限码与数据权限表中的数据权限码进行关联，标明该对象所归属的数据权限。

在本实施例中，数据库用于保存用户、角色、功能权限和数据权限之间关联关系的关联表，具体包括用户角色关联表、角色功能权限关联表和角色数据权限关联表。

用户角色关联表，用于保存用户和角色的所有对应关系，例如，用户与角色的对应关系以用户标识(用户表中用户ID)与角色标识(角色表中角色名)的对应关系的形式保存在用户角色关联表中。如图6所示，用户角色关联表包括用户ID、角色名等字段。表里每条数据中的用户ID和角色名将用户和角色相关联，表明该用户拥有该角色的权限，包括功能权限和数据权限。

角色功能权限关联表，用于保存每个角色和其拥有的功能权限之间所有的对应关系，例如，角色与功能权限的对应关系以角色标识(角色表中角色名)与功能权限标识(功能权限表中的功能权限码)的对应关系的形式保存在角色功能权限关联表中。如图6所示，角色功能权限关联表包括ID、角色名、功能权限码等字段。表里每条数据中的角色名和功能权限码将角色和功能权限相关联，表明该角色拥有该功能权限。

角色数据权限关联表，用于保存每个角色和其拥有的数据权限之间所有的对应关系。例如，角色与数据权限的对应关系以角色标识(角色表中角色名)与数据权限标识(数据权限表中的数据权限码)的对应关系的形式保存在角色数据权限关联表中，如图6所示，角色数据权限关联表包括ID、角色名、数据权限码等字段。表里每条数据中的角色名和数据权限码将角色和数据权限相关联，表明该角色拥有该数据权限。

在本实施例中，功能单元包括角色查询单元、功能权限查询单元和数据权限查询单元。

角色查询单元，用于查询用户角色关联表，获得在线用户对应的角色。比如，为新用户创建账户后，为其配置角色，该用户和配置的角色的对应关系保存在用户角色关联表中，当用户登录时，在用户角色关联表中查询该用户的角色，用户在角色权限的限制下进行相关操作。

功能权限查询单元，用于根据在线用户对应的角色查询角色功能权限关联表，以核实在线用户请求的功能是否可执行。比如，当用户发起操作时，首先在用户角色关联表中查询该用户的角色，然后在角色功能权限关联表中查询该角色拥有的功能权限，判定用户发起操作是否在该角色拥有的功能权限范围内(即查询用户是否拥有发起操作的功能权限)，如果用户没有发起操作的功能权限，则拒绝该操作，如果有功能权限则进入下一步。

数据权限查询单元，用于当在线用户请求的功能可执行，则根据在线用户对应的角色查询角色数据权限关联表，获得在线用户对应的数据权限。比如，当用户拥有发起该操作的功能权限时，继而在角色数据权限关联表中查询该角色拥有的数据权限(可访问的数据范围)的限制条件下，向用户返回操作结果。

需要说明的是，在其他实施例中，也可以不需要单独配置用户表、角色表、功能权限表、功能操作表、数据权限表和对象信息表，例如：用户表和角色表的内容可以保存在用户角色关联表中；功能权限表和功能操作表的内容可以保存在角色功能权限关联表中，或者功能操作表的内容可以保存在功能权限表中；数据权限表和对象信息表的内容可以保存在角色数据权限关联表中，或者对象信息表的内容可以保存在数据权限表中。

实施例三

图4是本发明用户权限管理***实施例三的示意图，如图4所示，本实施例的用户权限管理***包括数据库(包括用户表、角色表、功能权限表、数据权限表、功能操作表、对象信息表、用户角色关联表、角色功能权限关联表和角色数据权限关联表)、角色查询单元、功能权限查询单元和数据权限查询单元。这些与实施例二的类似，此处不再赘述。

在本实施例中，数据库还包括用户功能权限属性表、用户数据权限属性表和资源表；功能单元还包括资源提取单元和执行单元。

用户功能权限属性表，用于保存与用户关联的功能权限和功能权限属性参数，即记录了用户功能权限的属性值，如图6所示，用户功能权限属性表包括ID、用户ID、功能权限码、参数1、参数2、参数3等字段。

用户数据权限属性表，用于保存与用户关联的数据权限和数据权限属性参数，即记录了用户数据权限的属性值，如图6所示，用户数据权限属性表包括ID、用户ID、数据权限码、参数1、参数2、参数3等字段。数据权限属性参数可以进一步包括数据行权限属性参数和数据列权限属性参数。

需要说明的是，功能权限的属性值可以包括对功能权限的时间、次数等属性的限定，比如，该用户只能在9点后查询数据，其中功能权限是查询，功能权限的属性是9点后。数据权限的属性值可以包括对数据权限的行、列等属性的限定，由于数据在数据库中具有行和列两个维度，通过数据行权限属性参数对数据权限允许访问的数据范围在行属性权限的限定下缩小可访问的数据条数；通过数据列权限属性参数对数据权限允许访问的数据在列属性权限的限定下缩小可访问数据列数。比如，市场部城市负责人具体负责浙江、杭州这两个城市，则数据权限是城市级别，数据权限的属性是浙江和杭州，该数据权限的属性是通过数据行权限属性参数限定；再比如，市场部城市负责人只能查看市场部相关的数据，不能查看其他部的数据，则数据权限是城市级别，数据权限的属性是市场部，该数据权限的属性是通过数据列权限属性参数限定的。

综上所述，用户功能权限属性表和用户数据权限属性表使权限设置更有层次，功能权限和数据权限的设置可以基于角色(例如组织架构员工级别)设置一个大的权限范围，涉及到每个角色下的各个用户，可以根据用户具体涉及的范围，在用户功能权限属性表和用户数据权限属性表中进一步限定。比如，只要是市场部城市负责人级别的用户都可以设置数据权限是城市级别，具体负责的城市，可以使用数据行权限属性参数做具体权限限制，而不需要在数据权限中直接设置具体那个城市的权限，以避免数据权限表和功能权限表过于庞大，检索时间长。

资源表，用于保存与功能权限关联的显示信息的资源表，即保存所有依赖于权限的可视化界面资源。***通常会提供可视化界面供用户使用，而不同用户对应不同角色，拥有的权限也不同。用户登录后，***需要根据用户的权限显示可视化界面，展示用户有权限访问的资源(包括功能入口和信息)，隐藏用户没有权限访问的资源。比如，用户以财务角色登录时，***会展示财务管理模块，包含对账、***管理等财务功能入口。用户以人事角色登录时，***会展示人事管理模块，包含工资、请假等人事功能入口，而不会展示财务管理模块。如图6所示，资源表包括资源码、资源名、功能权限码和资源描述等字段。通过资源表中的功能权限码与功能权限表中的功能权限码进行关联，标明该资源所依赖的功能权限。

资源提取单元，用于当在线用户请求的功能可执行，根据请求的功能对应的功能权限提取资源表中关联的显示信息。

执行单元，用于当在线用户请求的功能可执行，根据功能操作表和在对象信息表执行在线用户请求的功能。

需要说明的是，用户可以拥有多个角色，可以分别进入每个角色所对应的操作界面，或者进入到多个角色拥有的所有权限的操作界面。

下面详细说明当用户使用本实施例的用户权限管理***时，该***的工作流程如下：

1)根据需求创建角色，配置角色的功能权限和数据权限；

2)创建用户，配置用户角色；

3)根据需求配置用户的功能权限属性参数和/或数据权限属性参数；

4)当用户初次登陆时，***检查用户的权限，如果用户没有配置角色(即用户没有权限限制)则登录失败，如果用户已配置角色(即用户有权限限制)则进入下一步；

5)用户登录成功后，***创建会话，用户通过会话激活角色，与角色关联；

6)***查询该角色所拥有的功能权限，根据功能权限查询可展示的界面资源，并向用户展示相应功能入口和信息；

7)当用户进行操作时，***查询用户是否拥有该操作的功能权限，如果没有所需的功能权限则拒绝该操作，如果有，则进入下一步；

8)***查询该角色的数据权限、该用户的数据权限属性或该用户的功能权限属性，在权限属性的限定条件下执行操作，并向用户返回操作结果。

下面将通过实例具体说明如何关联用户、角色、数据权限、功能权限、数据权限的属性，以及***工作流程。

如图7和图8所示，创建用户user1，该用户是市场部城市负责人级别；在角色表中定义角色名为“marketing_city_manager”的角色，表示市场部-城市负责人的角色；在数据权限表中定义数据权限码为“area_city”，表示数据的访问范围限定在城市级别，在功能权限表中定义功能权限码为“query_order”,表示业务订单查询权限。角色数据权限关联表中通过一条数据将角色和数据权限关联起来，这条数据中的角色名为“marketing_city_manager”，数据权限码为“area_city”，表明该角色拥有该数据权限；角色功能权限关联表中通过一条数据将角色和功能权限关联起来，这条数据中的角色名为“marketing_city_manager”，功能权限码为“query_order”，表明该角色拥有该功能权限。该用户所负责的具体城市是“浙江”和“杭州”时，则在用户数据权限属性表中添加一条数据，记录该用户这条数据权限的属性值，这条数据中的用户ID为该用户ID，数据权限码为“area_city”，参数1是该用户负责城市所属省份名称“浙江”，参数2是该用户负责城市名称“杭州”。

当用户user1发起业务订单查询时，本实施例的用户权限管理***的工作流程如下：

1)用户输入用户名和密码登录***；

2)***根据用户ID在用户角色关联表查询该用户角色，供用户选择；

3)用户创建会话并选择激活角色“marketing_city_manager”；

4)***查询角色功能权限关联表，判断该角色是否被许可执行业务订单查询操作。由于该用户角色为市场部城市负责人，在角色功能权限关联表中存在一条数据，角色名为“marketing_city_manager”，功能权限码为“query_order”,说明该角色已经被授予业务订单查询权限；

5)***查询角色数据权限关联表，获取该角色的数据权限“area_city”；

6)***查询用户数据权限属性表，获取该用户的数据权限“area_city”的属性值为“浙江”和“杭州”；

7)***执行业务订单查询操作，并将数据的地域范围限定在“浙江-杭州”，返回该城市的订单数据，完成操作。

下面将通过实例具体说明如何管理数据的行权限、列权限及设置数据权限属性参数。

如图8所示，以查询工资信息为例，人事部-总监允许查看所有员工的工资详情，市场部-总监允许查看市场部所有员工的工资摘要。角色表定义了人事总监角色“hr_director”和市场部总监角色“marketing_director”。数据权限表定义了“工资摘要”的数据权限码“salary_summary”(限定数据的列权限)、“工资明细”的数据权限码“salary_desc”(限定数据的列权限)、“公司范围”的数据权限码“scope_company”(限定数据的行权限)和“部门范围”的数据权限码“scope_department”(限定数据的行权限)。在角色数据权限关联表，其中一条数据将角色“hr_director”分别与数据权限“salary_desc”和“scope_company”相关联，表示人事部-总监的角色所拥有的数据权限；其中一条数据将角色“marketing_director”分别与数据权限“salary_summary”和“scope_department”相关联，表示市场部-总监的角色所拥有的数据权限。

此外，在用户数据权限属性表里，还为市场部-总监的角色的用户定义了一条数据，记录了用户ID、数据权限码“scope_department”和参数1“marketing”,从而限定该用户“部门范围”数据权限为市场部。

如图8所示，用户user2关联了人事部-总监“hr_director”角色，该用户查询员工工资信息时，数据权限为“salary_desc”和“scope_company”，可以查看到全公司员工的工资详情，包括税前工资、个人缴纳社保、个人缴纳公积金、个人所得税、扣发工资、实发工资、公司缴纳社保、公司缴纳公积金等。用户user3关联了市场部-总监“marketing_director”的角色，该用户查询员工工资信息时，数据权限为“salary_summary”和“scope_department”，数据权限属性参数为市场部“marketing”，可以查看市场部员工的工资摘要，只包括税前工资和实发工资，隐藏了其它工资细节。

下面将通过实例具体说明如何使用功能权限的属性参数。

举例说明，为了便于离线查看和统计订单，***提供了生成订单报表并导出excel文件的功能。当订单数据量较大时，报表操作会对服务器产生较高的负载。考虑到订单报表功能并不是高频使用功能，为了避免其对***性能造成影响，***对此功能的使用时间进行限制。比如，限制大部分拥有该权限的用户只允许在服务器负载非高峰时段进行此操作，只对个别用户开放全时段的操作许可。如图7所示，用户user4关联了市场部_员工“marketing_staff”角色；功能权限表定义权限码“export_order_report”，表示导出订单报表的权限。用户user4，只允许在服务器负载非高峰时段导出订单报表，因此在用户功能权限属性表中记录了一条数据，记录了该用户ID、功能权限码“export_order_report”和参数1“server_free_time”，从而实现对该用户操作时间的限制；用户user3关联了市场部_总监“marketing_director”角色，没有设置该用户的功能权限属性参数，说明该用户对导出订单报表的操作没有时间限制。

以上详细描述了本发明的较佳具体实施例。应当理解，本领域的普通技术人员无需创造性劳动就可以根据本发明的构思作出诸多修改和变化。因此，凡本技术领域中技术人员依本发明的构思在现有技术的基础上通过逻辑分析、推理或者有限的实验可以得到的技术方案，皆应在由权利要求书所确定的保护范围内。

Claims

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

2.如权利要求1所述的用户权限管理***，其特征在于，所述角色与数据权限的对应关系包括角色与行数据权限的对应关系和角色与列数据权限的对应关系。

3.如权利要求1所述的用户权限管理***，其特征在于，所述数据库还包括：用于保存与用户关联的功能权限和功能权限属性参数的用户功能权限属性表和用于保存与用户关联的数据权限和数据权限属性参数的用户数据权限属性表。

4.如权利要求3所述的用户权限管理***，其特征在于，所述数据权限属性参数包括数据行权限属性参数和数据列权限属性参数。

5.如权利要求1所述的用户权限管理***，其特征在于，

所述数据库还包括用于保存与功能权限关联的显示信息的资源表；

所述用户权限管理***还包括：资源提取单元，当所述在线用户请求的功能可执行，所述资源提取单元用于根据所述请求的功能对应的功能权限提取所述资源表中关联的显示信息。

6.如权利要求1或5所述的用户权限管理***，其特征在于，

所述数据库还包括用于保存与功能权限关联的操作的功能操作表和用于保存与数据权限关联的操作对象的对象信息表；

所述用户权限管理***还包括：执行单元，当所述在线用户请求的功能可执行，所述执行单元用于根据所述功能操作表和对象信息表执行所述在线用户请求的功能。

7.如权利要求1所述的用户权限管理***，其特征在于，所述数据库还包括：用于保存用户标识的用户表，用于保存角色标识的角色表，用于保存功能权限标识的功能权限表和用于保存数据权限标识的数据权限表。

8.一种用户权限管理的方法，其特征在于，包括以下步骤：

查询所述用户角色关联表，获得在线用户对应的角色；

9.如权利要求8所述的用户权限管理的方法，其特征在于，

所述用户权限管理的方法还包括：当所述在线用户请求的功能可执行，根据所述请求的功能对应的功能权限提取所述资源表中关联的显示信息。

10.如权利要求8所述的用户权限管理的方法，其特征在于，

所述用户权限管理方法还包括：当所述在线用户请求的功能可执行，根据所述功能操作表和对象信息表执行所述在线用户请求的功能。