权限控制的方法、装置、设备、存储介质及程序产品与流程

本申请涉及计算机技术，尤其涉及一种权限控制的方法、装置、设备、存储介质及程序产品。

背景技术：

随着信息化的进一步发展，数据的使用和价值越来越被重视。一个统一的数据架构管理系统，能够提高数据标准化水平，满足数据一致性要求。打通数据管理的全业务流程等是各组织面临的一个新的挑战。在实现这个系统的过程中，满足管理需要的权限管理模型更是设计之重。

目前，在对某一机构的数据架构管理系统进行权限管理时，通常采用基于角色的访问控制(role-basedaccesscontrol，简称rbac)模型，它包含用户、角色、资源、操作、会话五个基本要素。权限被赋予角色，而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话是用户与激活的角色集合之间的映射。rbac模型基于基本的权限主体和权限客体关系设计，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。关系相对简单，无法适用于包含多个分支机构或者多层次机构的数据架构管理系统的业务安全需要。

技术实现要素：

本申请提供一种权限控制的方法、装置、设备、存储介质及程序产品。

一方面，本申请提供一种权限控制的方法，包括：

响应于用户的登录请求，若对所述用户安全认证通过，则根据所述用户的身份标识，获取所述用户的角色集合和机构信息；

根据所述用户的角色集合和机构信息，获取所述用户具有操作权限的功能菜单；

根据所述用户具有操作权限的功能菜单，生成并显示所述用户对应的登录页面，所述登录页面包含所述用户具有操作权限的功能菜单，并且所述登录页面不包含所述用户不具有操作权限的功能菜单。

另一方面，本申请提供一种权限控制的装置，包括：

权限控制模块，用于响应于用户的登录请求，若对所述用户安全认证通过，则根据所述用户的身份标识，获取所述用户的角色集合和机构信息；根据所述用户的角色集合和机构信息，获取所述用户具有操作权限的功能菜单；

反馈模块，用于根据所述用户具有操作权限的功能菜单，生成并显示所述用户对应的登录页面，所述登录页面包含所述用户具有操作权限的功能菜单，并且所述登录页面不包含所述用户不具有操作权限的功能菜单。

另一方面，本申请提供一种权限控制的设备，包括：

处理器，存储器，以及存储在所述存储器上并可在所述处理器上运行的计算机程序；

其中，所述处理器运行所述计算机程序时实现上述所述权限控制的方法。

另一方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现上述所述的权限控制的方法。

另一方面，本申请提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述所述的权限控制的方法。

本申请提供权限控制的方法、装置、设备、存储介质及程序产品，响应于用户的登录请求，若对所述用户安全认证通过，则根据所述用户的身份标识，获取所述用户的角色集合和机构信息；根据所述用户的角色集合和机构信息，获取所述用户具有操作权限的功能菜单；根据所述用户具有操作权限的功能菜单，生成并显示所述用户对应的登录页面，所述登录页面包含所述用户具有操作权限的功能菜单，并且所述登录页面不包含所述用户不具有操作权限的功能菜单，能够为不同的用户设置不同的角色和机构信息，来配置用户对系统业务功能的不同的访问权限。在用户登录时，根据用户对应的角色集合和机构信息动态地构建用户对应的功能菜单，并生成包含所述用户具有操作权限的功能菜单的登录页面，能够实现复杂的数据架构管理系统的权限控制，在不破坏系统原有体系结构和业务逻辑的情况下，通过权限的灵活配置，可以满足不同应用系统的个性化需要。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为本申请实施例提供的rbac0模型的示意图；

图2为本申请实施例提供的数据架构管理系统的主要功能模块的示例图；

图3为本申请实施例一提供的权限控制的方法流程图；

图4为本申请实施例二提供的权限管理模型的框架示意图；

图5为本申请实施例二提供的职务、机构、用户、角色及功能权限实体的关系的示意图；

图6为本申请实施例二提供的权限控制的方法流程图；

图7为本申请实施例三提供的权限控制的装置的结构示意图；

图8为本申请实施例四提供的权限控制的装置的结构示意图；

图9为本申请实施例五提供的权限控制的设备的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

首先对本申请所涉及的名词进行解释：

权限管理：系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授权的资源。

权限管理模型：实现权限管理的一组要素间关系的抽象定义。

权限主体：权限管理模型中的用户和角色实体。

权限客体：权限管理模型中的资源实体和一组对应的操作。

web系统：一种基于超文本和http的、全球性的，动态交互的，跨平台的分布式图形信息系统。

此外，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。在以下各实施例的描述中，“多个”的含义是两个以上，除非另有明确具体的限定。

随着信息化的进一步发展，数据的使用和价值越来越被重视。一个统一的数据架构管理系统，能够提高数据标准化水平，满足数据一致性要求。打通数据管理的全业务流程等是各组织面临的一个新的挑战。在实现这个系统的过程中，满足管理需要的权限管理模型更是设计之重。

目前，在对某一机构的数据架构管理系统进行权限管理时，通常采用基于角色的访问控制(role-basedaccesscontrol，简称rbac)模型。rbac模型分为rbac0，rbac1，rbac2，rbac3。rbac0是rbac的核心思想，如图1所示，rbac0模型包含用户、角色、资源、操作、会话五个基本要素。权限被赋予角色，而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话是用户与激活的角色集合之间的映射。rbac1是把rbac的角色进行了分层,在角色中引入了继承的概念。rbac2是考虑了rbac角色之间的相互约束关系。rbac3结合了rbac1和rbac2，同时具备角色等级和约束。

rbac模型基于基本的权限主体和权限客体关系设计，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限，关系相对简单，无法适用于包含多个分支机构或者多层次机构的数据架构管理系统的业务安全需要，无法满足数据架构管理系统的权限管理需要，主要体现在以下两方面：一是，rbac模型基于基本的权限主体和权限客体关系设计，关系相对简单，并且只是个抽象的模型关系，而数据架构管理系统以及业务安全需要，除了需要用户和角色，还包括多个不同的机构，用户还可以有不同的职务，不同用户所在机构不同，或者不同用户在用以机构的职务不同。二是，rbac模型没有对权限的管理配置进行描述，无法满足系统的可扩展性。

本申请提供一种权限控制的方法、装置、设备、存储介质及程序产品，可以应用于包含多机构的复杂数据架构管理系统的权限管理。数据架构管理系统的涉及的主要功能模块如图2所示，包括数据项管理、数据模型管理、数据资源管理、权限管理、版本管理和任务流程管理等功能模块。该数据架构管理系统管理了某组织(可以包含多个机构)全量系统的数据模型和数据资源模型，打通了从设计到生产全流程的数据模型和数据资源。系统用户涵盖了各职能部门。其中，办公系统是各机构各子拥有的办公系统，办公系统中存储有用户信息和机构信息。应用服务信息管理系统用于提供应用系统服务目录信息，通过应用系统服务目录信息可获得对应机构所负责的应用系统的数据模型信息。安全认证系统用于实现用户进行安全认证。权限管理模块用于实现用户权限的控制，需要和安全认证系统、办公系统、应用服务信息管理系统进行交互，获得用户和相关资源的完整信息。

本申请提供的权限控制的方法，响应于用户的登录请求，若对用户安全认证通过，则根据用户的身份标识，获取用户的角色集合和机构信息；根据用户的角色集合和机构信息，获取用户具有操作权限的功能菜单；根据用户具有操作权限的功能菜单，生成并显示用户对应的登录页面，登录页面包含用户具有操作权限的功能菜单，并且登录页面不包含用户不具有操作权限的功能菜单，能够为不同的用户设置不同的角色和机构信息，来配置用户对系统业务功能的不同的访问权限。在用户登录时，根据用户对应的角色集合和机构信息动态地构建用户对应的功能菜单，并生成包含用户具有操作权限的功能菜单的登录页面，能够实现复杂的数据架构管理系统的权限控制，在不破坏系统原有体系结构和业务逻辑的情况下，通过权限的灵活配置，可以满足不同应用系统的个性化需要。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

实施例一

图3为本申请实施例一提供的权限控制的方法流程图。本实施例中的方法应用于权限控制的设备，该权限控制的设备可以是权限控制的服务器、云平台、集群等，在其他实施例中，该方法还可应用于其他设备，本实施例以权限控制的设备为例进行示意性说明。

如图3所示，该方法具体步骤如下：

步骤s101、响应于用户的登录请求，若对用户安全认证通过，则根据用户的身份标识，获取用户的角色集合和机构信息。

其中，用户的角色集合包括预先配置的该用户具有的一个或者多个角色。

本实施例中，接收到用户的登录请求之后，可以根据用户输入的安全验证信息，对用户进行安全认证。

如果对用户安全认证不通过，则用户为非法用户，拒绝进入系统。

如果对用户安全认证通过，则用户为合法用户，根据用户的身份标识可以获取用户具有的一个或者多个角色，根据用户具有的角色，可以进一步确定用户的机构信息。其中，机构信息可以包括所在机构和/或职务信息。

步骤s102、根据用户的角色集合和机构信息，获取用户具有操作权限的功能菜单。

该步骤中，根据用户的角色集合和机构信息，以及配置的角色菜单权限信息，确定与用户的角色集合中任一角色具有映射关系的功能菜单，得到用户具有操作权限的功能菜单。

本实施例中，默认情况下，用户拥有所在机构内的各项功能菜单的操作权限，但是用户不具有其他机构的功能菜单的操作权限。

步骤s103、根据用户具有操作权限的功能菜单，生成并显示用户对应的登录页面，登录页面包含用户具有操作权限的功能菜单，并且登录页面不包含用户不具有操作权限的功能菜单。

在获取到用户具有操作权限的功能菜单之后，生成包含用户具有操作权限的功能菜单的登录页面，并显示登录页面。用户可以在显示的登录页面上对示出的功能菜单进行操作。

本申请实施例中，响应于用户的登录请求，若对用户安全认证通过，则根据用户的身份标识，获取用户的角色集合和机构信息；根据用户的角色集合和机构信息，获取用户具有操作权限的功能菜单；根据用户具有操作权限的功能菜单，生成并显示用户对应的登录页面，登录页面包含用户具有操作权限的功能菜单，并且登录页面不包含用户不具有操作权限的功能菜单，能够为不同的用户设置不同的角色和机构信息，来配置用户对系统业务功能的不同的访问权限。在用户登录时，根据用户对应的角色集合和机构信息动态地构建用户对应的功能菜单，并生成包含用户具有操作权限的功能菜单的登录页面，能够实现复杂的数据架构管理系统的权限控制，在不破坏系统原有体系结构和业务逻辑的情况下，通过权限的灵活配置，可以满足不同应用系统的个性化需要。

实施例二

图4为本申请实施例二提供的权限管理模型的框架示意图；图5为本申请实施例二提供的职务、机构、用户、角色及功能权限实体的关系的示意图；图6为本申请实施例二提供的权限控制的方法流程图。

在上述实施例一的基础上，本实施例中，权限管理模型可以如图4所示，应用服务信息管理系统提供应用系统服务目录信息。办公系统与机构和用户关联，能够提供对应机构的机构信息和用户信息。通过应用系统服务目录与机构的关系将应用系统服务目录信息与机构关联。安全认证系统与用户关联，用于对用户进行安全认证。用户与机构关联，用户具有机构信息。通过用户与角色的关系将用户与角色关联。通过配置用户与角色的关系，可以实现数据访问权限关系和跨机构数据访问权限关系的配置，从而配置用户对应用系统服务目录信息对应数据模型的数据访问权限，以及配置用户进行跨机构的业务模块、业务对象和物理模型等的数据访问权限。通过配置角色功能权限信息来将角色与页面的功能项关联，为角色关联具有操作权限的功能项。通过配置角色菜单权限信息、结合角色与职务关系为角色关联功能菜单，从而为角色配置具有操作权限的功能菜单，任一功能菜单具有对应的功能页面，功能页面上具有一个或者多个功能项。通过配置用户对应的角色，以及角色对应的机构和/或职务信息，来实现将用户与职务关联，确定用户与职务的关系，根据职务与机构的所属关系，可以进一步确定用户所在机构。

本实施例中，基于图4所示的权限管理模型的框架，数据架构管理系统的权限管理包括如下几个部分：

用户信息初始化和用户信息合法性验证：管理员可以通过从办公系统拉取并保存用户信息，完成用户信息的初始化，并可在线实时更新保存的用户信息，使得保存的用户信息与办公系统保持用户信息的一致性。用户的合法性通过安全认证系统进行验证，用户可通过密码、指纹、人脸，usbkey等方式进行不同等级强度的安全验证。如果为非法的用户，则拒绝进入系统，如果为合法的用户，则允许用户进入系统，可以根据配置的用户的角色信息，读取用户的访问权限信息和职务信息，并保存用户的会话中。

功能权限的动态配置：角色对应的功能权限包含角色拥有哪些功能页面(与功能菜单对应)和页面上的功能项的访问权限，功能权限根据功能模块划分，对每个角色需要完成的任务分配相应的功能菜单集和功能项集，根据系统的扩展，可对不同的角色进行功能权限的动态授权。

动态系统菜单：由于不同的用户拥有角色、职务不同。对系统业务功能的访问权限不同，在用户进入系统后，需要根据用户对应角色的功能菜单列表，构建用户的系统功能菜单，并显示包含用户具有操作权限的功能菜单的登录页面。

页面操作权限生成和验证：当用户需要访问一个页面时，系统将根据用户对应角色集的功能菜单访问权限，判断该用户是否具有访问该页面的权限。如果用户无权限访问页面，则无法获得该页面的访问。如果用户有权限访问页面，则需要根据用户对业务功能访问权限进一步判断用户是否具有该页面对应功能项的操作权限。如果该用户有相应的功能项的操作权限，则在页面中生成对应功能项的操作按钮。其中判断页面生成的操作按钮可以由标签库实现，实现业务逻辑和功能按钮展现的分离。

数据访问权限验证：用户能操作的数据范围为通过应用服务信息管理系统获得该机构的应用系统服务目录信息，并通过应用系统服务目录信息可获得该机构所负责的系统的数据模型信息。

图5中示出了部分实体及实体关系的示例，如图5所示，用户(user)、角色(role)、用户角色(role_user)分别定义了用户实体和属性，角色实体和属性，角色和用户的关系。例如，如图5所示，用户(user)可以包括以下属性：用户id、用户名、用户状态、用户职位、机构。角色(role)可以包括以下属性：角色id和角色名。用户角色实体关系(role_user)通过用户id和角色id的映射关系将用户(user)和角色(role)关联起来。

菜单(menu)实体定义树形关系的菜单，如图5所示，可以包括以下属性：菜单id、父菜单id、菜单名、菜单url。其中，父菜单id定义该节点的上级父节点，菜单url定义该节点指向的入口页面，如果该域非空，该节点非叶子节点。角色菜单(role_menu)定义了每一个角色对应的菜单节点，通过角色id和菜单id的映射关系将角色与具有操作权限的菜单关联起来。

功能权限(auth)实体定义具体的操作，比如增、删、改、查、下载等功能项。如图5所示，功能权限(auth)可以包括如下属性：功能id、菜单id、功能名称。角色功能(role_auth)定义了每一个角色对应的功能项，通过角色id和功能id的映射关系将角色与具有操作权限的功能项关联起来。

职务信息(post)定义具体职务的信息，用于权限审批工作流和资源审批工作流。如图5所示，职务信息(post)可以包括如下属性：职务id、职务名。机构信息(org)定义系统内各机构的信息，用于数据访问权限的控制。如图5所示，机构信息(org)可以包括如下属性：职务id、机构名、父机构id。

本实施例中，能够灵活地配置用户的角色集合、机构信息、以及为不同的角色配置功能菜单与功能项的权限信息。

示例性地，响应于管理员用户对任一角色的菜单权限配置操作，确定角色具有操作权限的功能菜单，并保存角色的角色菜单权限信息，角色菜单权限信息包括角色与角色具有操作权限的功能菜单之间的映射关系。

其中，任一功能菜单对应一个功能页面。

本实施例中，管理员用户可以对任一角色具有操作权限的功能菜单进行增、删、改、查询等，并更新角色的角色菜单权限信息，从而能够灵活地配置角色具有操作权限的功能菜单。

示例性地，响应于管理员用户对任一角色的功能权限配置操作，确定角色具有操作权限的功能项，并保存角色的角色功能权限信息，角色功能权限信息包括角色与角色具有操作权限的功能项之间的映射关系。

本实施例中，管理员用户可以对任一角色具有操作权限的功能项进行增、删、改、查询等，并更新角色的角色功能权限信息，从而能够灵活地配置角色具有操作权限的功能项。

示例性地，响应于管理员用户对任一角色的属性配置操作，保存角色的机构信息，机构信息包括角色对应的机构和/或职务信息。

本实施例中，管理员可以对任一角色的机构信息进行增、删、改、查询等，并更新角色的机构信息，从而能够灵活地配置角色对应的机构和/或职务信息。

本实施例中，根据用户具有操作权限的功能菜单，生成并显示用户对应的登录页面之后，还包括：响应于用户对登录页面上任一功能菜单的访问操作，根据用户的角色集合和机构信息，在任一功能菜单对应的功能页面包含的所有功能项中，确定用户具有操作权限的功能项；根据用户具有操作权限的功能项，生成并显示目标页面，目标页面包含用户具有操作权限的功能项，并且目标页面包含不包含用户不具有操作权限的功能项。

如图6所示，权限控制的方法具体流程如下：

步骤s201、响应于用户的登录请求，根据用户输入的安全验证信息，对用户进行安全认证。

本实施例中，接收到用户的登录请求之后，可以根据用户输入的安全验证信息，对用户进行安全认证。

如果对用户安全认证不通过，则用户为非法用户，拒绝进入系统，执行步骤s202显示提示信息。

如果对用户安全认证通过，则用户为合法用户，执行步骤s203，获取用户具有操作权限的功能菜单，并显示包含用户具有操作权限的功能菜单的登录页面。

该步骤中，用户的合法性通过安全认证系统进行验证，用户可通过密码、指纹、人脸，usbkey等方式进行不同等级强度的安全认证。

步骤s202、若对用户安全认证不通过，则显示提示信息。

其中，提示信息用于提示用户的安全认证未通过，提示信息还可以包括安全认证未通过的原因等信息，此处不做具体限定。

步骤s203、若对用户安全认证通过，则根据用户的身份标识，获取用户的角色集合和机构信息。

其中，用户的角色集合包括预先配置的该用户具有的一个或者多个角色。

根据用户的身份标识可以获取用户具有的一个或者多个角色，根据用户具有的角色，可以进一步确定用户的机构信息。其中，机构信息可以包括所在机构和/或职务信息。

步骤s204、根据用户的角色集合和机构信息，获取用户具有操作权限的功能菜单。

该步骤中，根据用户的角色集合和机构信息，以及配置的角色菜单权限信息，确定与用户的角色集合中任一角色具有映射关系的功能菜单，得到用户具有操作权限的功能菜单。

本实施例中，默认情况下，用户拥有所在机构内的各项功能菜单的操作权限，但是用户不具有其他机构的功能菜单的操作权限。

一种可选地实施方式中，管理员还可以为用户配置具有跨机构的访问权限，可以通过为用户配置具有一个或者多个具有访问权限的机构信息，在用户登录时，获取的用户具有操作权限的功能菜单可以包括用户所在机构、或者用户具有访问权限的其他机构的功能菜单。

步骤s205、根据用户具有操作权限的功能菜单，生成并显示用户对应的登录页面，登录页面包含用户具有操作权限的功能菜单，并且登录页面不包含用户不具有操作权限的功能菜单。

在获取到用户具有操作权限的功能菜单之后，生成包含用户具有操作权限的功能菜单的登录页面，并显示登录页面。用户可以在显示的登录页面上对示出的功能菜单进行操作。

步骤s206、响应于用户对登录页面上任一功能菜单的访问操作，根据用户的角色集合和机构信息，在任一功能菜单对应的功能页面包含的所有功能项中，确定用户具有操作权限的功能项。

用户对登录页面上任一功能菜单进行访问操作，根据用户的角色集合和机构信息，在任一功能菜单对应的功能页面包含的所有功能项中，确定用户具有操作权限的功能项。

该步骤中，根据用户的角色集合和机构信息，以及配置的角色功能权限信息，确定与用户的角色集合中任一角色具有映射关系的功能项，得到用户具有操作权限的功能菜单。

在实际应用中，配置角色功能权限信息时，可以将一个页面上的部分功能项或者全部功能项的操作权限配置给角色。

本实施例中，默认情况下，用户拥有所在机构内的各项功能菜单对应功能页面上的功能项的操作权限，但是用户不具有其他机构的功能项的操作权限。

一种可选地实施方式中，根据用户的角色集合和机构信息，获取用户具有操作权限的功能菜单之后，根据用户的角色集合和机构信息，获取用户具有操作权限的功能项；将用户的操作权限信息保存在会话中，操作权限信息包括用户具有操作权限的功能菜单和功能项。

这样，在后续需要使用用户的操作权限信息时，可以直接从会话中获取，能够提高效率。

示例性地，响应于用户对登录页面上任一功能菜单的访问操作，可以根据当前会话中用户的操作权限信息，确定用户具有操作权限的功能项。

步骤s207、根据用户具有操作权限的功能项，生成并显示目标页面，目标页面包含用户具有操作权限的功能项，并且目标页面包含不包含用户不具有操作权限的功能项。

在获取到用户具有操作权限的功能项之后，生成包含用户具有操作权限的功能项的目标页面，并显示目标页面。用户可以在显示的目标页面上对示出的功能项进行操作。

本实施例中，用户能操作的数据范围为通过应用服务信息管理系统获得该机构的应用系统服务目录信息，并通过应用系统服务目录信息可获得该机构所负责的系统的数据模型信息。

一种可选地实施方式中，响应于用户对目标数据模型的操作请求，根据用户的机构信息和跨机构数据访问权限信息，获取用户具有数据访问权限的机构的应用系统服务目录信息；根据用户具有数据访问权限的机构的应用系统服务目录信息，获取用户具有数据访问权限的机构的数据模型信息；根据用户具有数据访问权限的机构的数据模型信息，确定用户是否具有目标数据模型的操作权限；若确定用户不具有目标数据模型的操作权限，则拒绝用户对目标数据模型的操作请求。

可选地，响应于为用户配置目标机构的跨机构数据访问权限的操作，更新用户的跨机构数据访问权限信息，跨机构数据访问权限信息包含用户具有跨机构数据访问权限的一个或者多个机构的信息。

本申请实施例中，提供一种针对复杂系统的权限管理模型，根据应用个性化的需要，可在该模型的基础上扩展、定制和裁剪出符合自身系统需要的权限管理模型，可以快速裁剪定制出满足需要的权限管理模型，使得在不破坏系统原有体系结构和业务逻辑的情况下，通过对功能权限进行灵活配置管理，实现功能权限的可扩展性，以满足不同应用系统的个性化需要。

实施例三

图7为本申请实施例三提供的权限控制的装置的结构示意图。本申请实施例提供的权限控制的装置可以执行权限控制的方法实施例提供的处理流程。如图7所示，该权限控制的装置30包括：权限管理模块301和反馈模块302。

具体地，权限管理模块301，用于响应于用户的登录请求，若对用户安全认证通过，则根据用户的身份标识，获取用户的角色集合和机构信息；根据用户的角色集合和机构信息，获取用户具有操作权限的功能菜单；

反馈模块302，用于根据用户具有操作权限的功能菜单，生成并显示用户对应的登录页面，登录页面包含用户具有操作权限的功能菜单，并且登录页面不包含用户不具有操作权限的功能菜单。

本申请实施例提供的装置可以具体用于执行上述实施例一所提供的方法实施例，具体功能此处不再赘述。

本申请实施例中，响应于用户的登录请求，若对用户安全认证通过，则根据用户的身份标识，获取用户的角色集合和机构信息；根据用户的角色集合和机构信息，获取用户具有操作权限的功能菜单；根据用户具有操作权限的功能菜单，生成并显示用户对应的登录页面，登录页面包含用户具有操作权限的功能菜单，并且登录页面不包含用户不具有操作权限的功能菜单，能够为不同的用户设置不同的角色和机构信息，来配置用户对系统业务功能的不同的访问权限。在用户登录时，根据用户对应的角色集合和机构信息动态地构建用户对应的功能菜单，并生成包含用户具有操作权限的功能菜单的登录页面，能够实现复杂的数据架构管理系统的权限控制，在不破坏系统原有体系结构和业务逻辑的情况下，通过权限的灵活配置，可以满足不同应用系统的个性化需要。

实施例四

图8为本申请实施例四提供的权限控制的装置的结构示意图。在上述实施例三的基础上，本实施例中，权限管理模块还用于：

根据用户具有操作权限的功能菜单，生成并显示用户对应的登录页面之后，响应于用户对登录页面上任一功能菜单的访问操作，根据用户的角色集合和机构信息，在任一功能菜单对应的功能页面包含的所有功能项中，确定用户具有操作权限的功能项；根据用户具有操作权限的功能项，生成并显示目标页面，目标页面包含用户具有操作权限的功能项，并且目标页面包含不包含用户不具有操作权限的功能项。

一种可选的实施方式中，权限管理模块还用于：

根据用户的角色集合和机构信息，获取用户具有操作权限的功能菜单之后，根据用户的角色集合和机构信息，获取用户具有操作权限的功能项；将用户的操作权限信息保存在会话中，操作权限信息包括用户具有操作权限的功能菜单和功能项。

一种可选的实施方式中，权限管理模块还用于：

将用户的操作权限信息保存在会话中之后，响应于用户对登录页面上任一功能菜单的访问操作，根据当前会话中用户的操作权限信息，确定用户具有操作权限的功能项；根据用户具有操作权限的功能项，生成并显示目标页面，目标页面包含用户具有操作权限的功能项，并且目标页面包含不包含用户不具有操作权限的功能项。

一种可选的实施方式中，如图8所示，该权限控制的装置30还包括：安全认证模块303，用于：

响应于用户的登录请求，若对用户安全认证通过，则根据用户的身份标识，获取用户的角色集合和机构信息之前，根据用户输入的安全验证信息，对用户进行安全认证；若对用户安全认证不通过，则显示提示信息。

一种可选的实施方式中，权限管理模块还用于：

响应于用户对目标数据模型的操作请求，根据用户的机构信息和跨机构数据访问权限信息，获取用户具有数据访问权限的机构的应用系统服务目录信息；根据用户具有数据访问权限的机构的应用系统服务目录信息，获取用户具有数据访问权限的机构的数据模型信息；根据用户具有数据访问权限的机构的数据模型信息，确定用户是否具有目标数据模型的操作权限；若确定用户不具有目标数据模型的操作权限，则拒绝用户对目标数据模型的操作请求。

一种可选的实施方式中，如图8所示，该权限控制的装置30还包括：权限配置模块304，用于：

响应于为用户配置目标机构的跨机构数据访问权限的操作，更新用户的跨机构数据访问权限信息，跨机构数据访问权限信息包含用户具有跨机构数据访问权限的一个或者多个机构的信息。

一种可选的实施方式中，权限配置模块304还用于：

响应于管理员用户对任一角色的菜单权限配置操作，确定角色具有操作权限的功能菜单，并保存角色的角色菜单权限信息，角色菜单权限信息包括角色与角色具有操作权限的功能菜单之间的映射关系；其中，任一功能菜单对应一个功能页面。

一种可选的实施方式中，权限配置模块304还用于：

响应于管理员用户对任一角色的功能权限配置操作，确定角色具有操作权限的功能项，并保存角色的角色功能权限信息，角色功能权限信息包括角色与角色具有操作权限的功能项之间的映射关系。

一种可选的实施方式中，权限配置模块304还用于：

响应于管理员用户对任一角色的属性配置操作，保存角色的机构信息，机构信息包括角色对应的机构和/或职务信息。

本申请实施例提供的装置可以具体用于执行上述实施例二所提供的方法实施例，具体功能此处不再赘述。

本申请实施例中，提供一种针对复杂系统的权限管理模型，根据应用个性化的需要，可在该模型的基础上扩展、定制和裁剪出符合自身系统需要的权限管理模型，可以快速裁剪定制出满足需要的权限管理模型，使得在不破坏系统原有体系结构和业务逻辑的情况下，通过对功能权限进行灵活配置管理，实现功能权限的可扩展性，以满足不同应用系统的个性化需要。

实施例五

图9为本申请实施例五提供的权限控制的设备的结构示意图。如图9所示，该权限控制的设备70包括：处理器701，存储器702，以及存储在存储器702上并可在处理器701上运行的计算机程序。

其中，处理器701运行计算机程序时实现上述任一方法实施例提供的权限控制的方法。

本申请实施例中，响应于用户的登录请求，若对用户安全认证通过，则根据用户的身份标识，获取用户的角色集合和机构信息；根据用户的角色集合和机构信息，获取用户具有操作权限的功能菜单；根据用户具有操作权限的功能菜单，生成并显示用户对应的登录页面，登录页面包含用户具有操作权限的功能菜单，并且登录页面不包含用户不具有操作权限的功能菜单，能够为不同的用户设置不同的角色和机构信息，来配置用户对系统业务功能的不同的访问权限。在用户登录时，根据用户对应的角色集合和机构信息动态地构建用户对应的功能菜单，并生成包含用户具有操作权限的功能菜单的登录页面，能够实现复杂的数据架构管理系统的权限控制，在不破坏系统原有体系结构和业务逻辑的情况下，通过权限的灵活配置，可以满足不同应用系统的个性化需要。

本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，计算机程序被处理器执行时实现上述任一方法实施例提供的方法。

本申请实施例还提供了一种计算机程序产品，程序产品包括：计算机程序，计算机程序存储在可读存储介质中，权限控制的设备的至少一个处理器可以从可读存储介质读取计算机程序，至少一个处理器执行计算机程序使得，权限控制的设备执行上述任一方法实施例提供的方法。

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

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

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

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例方法的部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求书指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。