CN115987585A - 多应用管理系统、应用程序访问方法 - Google Patents

Abstract

本申请公开了一种多应用管理系统、应用程序访问方法。其中，该系统包括：多个终端设备，服务器集群，其中，多个终端设备中的每个终端设备，用于向服务器发送访问请求，其中，访问请求中携带有登陆终端设备的用户账号的用户标识信息；服务器，用于依据访问请求中的用户标识信息，确定与用户标识信息对应的用户权限；依据用户权限，确定至少一个目标应用，其中，目标应用为用户账号有权限访问的应用。本申请解决了由于目前在进行系统架构设计时，无法兼容各种不同应用的权限适配，造成对多用户的权限管理复杂繁琐、效率低下的技术问题。

Description

多应用管理系统、应用程序访问方法

技术领域

本申请涉及多应用权限认证技术领域，具体而言，涉及一种多应用管理系统、应用程序访问方法。

背景技术

随着数字化建设的步伐越来越快，各种应用架构层出不穷，分布式应用开发也越来越流行，大数据时代，数据的来源也变的越来越广泛，各种类型的数据也是爆发性增长。因此对数据的管理及安全要求也越来越高，目前在进行系统架构设计时，无法兼容各种不同应用的权限适配，造成对多用户的权限管理复杂繁琐、效率低下的技术问题。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种多应用管理系统、应用程序访问方法，以至少解决由于目前在进行系统架构设计时，无法兼容各种不同应用的权限适配，造成对多用户的权限管理复杂繁琐、效率低下的技术问题。

根据本申请实施例的一个方面，提供了一种多应用管理系统，包括：多个终端设备，服务器集群，其中，多个终端设备中的每个终端设备，用于向服务器发送访问请求，其中，访问请求中携带有登陆终端设备的用户账号的用户标识信息；服务器，用于依据访问请求中的用户标识信息，确定与用户标识信息对应的用户权限；依据用户权限，确定至少一个目标应用，其中，目标应用为用户账号有权限访问的应用。

可选地，服务器中设置有前台模块，中台模块，后台模块，其中，后台模块，用于存储用户账号的用户数据，其中，用户数据包括用户账号的权限数据和访问行为数据；中台模块，用于向应用程序提供标准接口，其中，应用程序通过标准接口连接至中台模块；前台模块，用于向终端设备提供与终端设备对应的目标应用的应用信息，以及将终端设备发送的访问请求转发至对应的应用，其中，每个终端设备对应一个前台模块。

可选地，服务器中设置有路由层，其中，路由层，用于接收访问请求；依据访问请求中的用户标识，转发访问请求至与用户标识对应的前台模块。

可选地，中台模块，还用于依据用户权限，从通过标准接口连接至中台模块的应用程序中确定目标应用，并生成包含有目标应用的应用信息的前台模块。

可选地，服务器还包括权限管理模块，其中，权限管理模块用于依据各个用户账号的用户标识信息，从应用程序中获取各个用户账号对应的权限信息，并将权限信息存储到后台模块中。

可选地，权限管理模块还用于响应应用程序的权限修改指令，修改用户标识信息对应的用户权限。

可选地，权限修改指令包括权限设置指令，权限继承指令，其中，响应应用程序的权限修改指令，修改用户标识信息对应的用户权限的步骤包括：响应权限设置指令，确定用户账号在访问应用程序时对应的角色，其中，应用程序对应多个角色，角色为通过应用程序执行目标功能时所需的最小权限集合；响应权限继承指令，将第一角色对应的权限集合赋予第二角色对应的权限集合，并确定第二角色为用户账号对应的角色。

可选地，权限管理模块还用于在修改用户标识信息对应的用户权限后，确定用户权限是否符合权限管理标准，并在确定用户权限不符合权限管理标准的情况下，生成并向应用程序反馈警示信息。

可选地，用户权限包括资源权限和条件权限，其中，资源权限包括以下至少之一：逻辑资源权限，实体资源权限；条件权限包括以下至少之一：可见组织范围权限，限定条件权限，其中，可见组织范围权限用于确定用户账号可访问的应用程序，限定条件权限用于确定用户在访问应用程序时的限定条件。

根据本申请实施例的另一个方面，还提供了一种应用程序访问方法，包括：接收终端设备发送的访问请求，其中，访问请求中携带有登陆终端设备的用户账号的用户标识信息；依据用户标识信息，确定用户账号的访问权限；依据访问权限，确定至少一个目标应用，其中，目标应用为用户账号有权限访问的应用；向终端设备发送至少一个目标应用的应用信息。

在本申请实施例中，应用多应用管理系统，包括：包括多个终端设备，服务器集群，其中，多个终端设备中的每个终端设备，用于向服务器发送访问请求，其中，访问请求中携带有登陆终端设备的用户账号的用户标识信息；服务器，用于依据访问请求中的用户标识信息，确定与用户标识信息对应的用户权限；依据用户权限，确定至少一个目标应用，其中，目标应用为用户账号有权限访问的应用的结构，通过对多应用、多组织和多用户的管理，增加组织实体和业务系统双重认证校验，满足不同用户对多个应用的权限访问，对用户和权限的逻辑分离，简化用户和权限的关系，达到了使平台的权限规则更易扩展、更易维护，方便快捷对权限进行管理的目的，进而解决了由于目前在进行系统架构设计时，无法兼容各种不同应用的权限适配，造成对多用户的权限管理复杂繁琐、效率低下技术问题。

附图说明

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

图1是根据本申请实施例提供的一种多应用管理系统的结构示意图；

图2是根据本申请实施例提供的一种账户体系业务流程的示意图；

图3是根据本申请实施例提供的一种权限模型的示意图；

图4是根据本申请实施例提供的一种用户架构的示意图；

图5是根据本申请实施例提供的一种Nacos注册中心架构的示意图；

图6是根据本申请实施例提供的一种权限认证模型的示意图；

图7是根据本申请实施例提供的一种用于实现应用程序访问的方法的计算机终端(或电子设备)的硬件结构框图；

图8是根据本申请实施例提供的一种应用程序访问的方法流程的示意图。

具体实施方式

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

在相关技术中，在进行系统架构设计时，无法兼容各种不同应用的权限适配，因此，存在对多用户的权限管理复杂繁琐、效率低下问题。为了解决该问题，本申请实施例中提供了相关的解决方案，以下详细说明。

根据本申请实施例，还提供了一种多应用管理系统的实施例。图1是根据本申请实施例提供的一种多应用管理系统的结构示意图。如图1所示，该系统包括：多个终端设备10，服务器集群12，其中，

多个终端设备10中的每个终端设备10，用于向服务器12发送访问请求，其中，访问请求中携带有登陆终端设备10的用户账号的用户标识信息；

服务器12，用于依据访问请求中的用户标识信息，确定与用户标识信息对应的用户权限；依据用户权限，确定至少一个目标应用，其中，目标应用为用户账号有权限访问的应用。

在本申请的一些实施例中，服务器12中设置有前台模块，中台模块，后台模块，其中，后台模块，用于存储用户账号的用户数据，其中，用户数据包括用户账号的权限数据和访问行为数据；中台模块，用于向应用程序提供标准接口，其中，应用程序通过标准接口连接至中台模块；前台模块，用于向终端设备提供与终端设备对应的目标应用的应用信息，以及将终端设备发送的访问请求转发至对应的应用，其中，每个终端设备对应一个前台模块。

在本申请的一些实施例中，服务器中设置有路由层，其中，路由层，用于接收访问请求；依据访问请求中的用户标识，转发访问请求至与用户标识对应的前台模块。

在本申请的一些实施例中，中台模块，还用于依据用户权限，从通过标准接口连接至中台模块的应用程序中确定目标应用，并生成包含有目标应用的应用信息的前台模块。

本申请将平台划分了多重账户体系，不同账户体系在平台内享有的权限通过角色映射进行区分。图2是根据本申请实施例提供的一种账户体系业务流程的示意图，如图2所示，整个请求流程按照以下规则模式实现：

对于服务层的组织实体为了保证系统的灵活性和功能可复用，将公共的能力服务拆分出来形成能力中台(即上述中台模块)，针对不同用户的权限识别，形成独立的业务前台(即上述前台模块)，后台(即上述后台模块)处理整个系统的数据存储。

用户在登录后会在请求的header(消息头部)中携带用户标识，每个请求都会首先进入路由层。路由层根据header中的用户标识对访问请求进行分发，不同的用户访问不同的应用。每个用户可以通过路由层精准访问到当前权限下的应用模块，实现不同用户之间的多应用管理。

每个用户在访问后台时，根据其请求中携带的用户标识，统一api网关会根据不同的用户标识将数据传递到对应的中后台服务，并且在转发的过程中做鉴权，拦截，熔断，降级等安全保障。

本申请提供统一的API与各应用、各子系统连接，通过统一权限认证管理，基于系统账户权限认证校验，网关层配置鉴权，拦截，熔断，降级等多重安全保障，实现不同组织和应用的分权分域管理。

中台能力与业务前台独立运行，中台对外提供标准接口(即上述标准接口)。前台对中台能力二次组装，每个用户都会有一个与其对应的前台。针对不同的用户，满足个性化组装中台能力，保证每个用户的个性化需求互不冲突。

后台负责整个系统的数据(即上述用户数据)存储，数据存储根据数据的性质进行安全隔离及脱敏处理。

通过上述流程规则，基于OAuth2.0授权网络标准，精简了繁琐的加密算法，适配多种登录认证模式。利用https传输对认证的安全性进行了保证，满足多应用权限认证。

在本申请的一些实施例中，服务器还包括权限管理模块，其中，权限管理模块用于依据各个用户账号的用户标识信息，从应用程序中获取各个用户账号对应的权限信息，并将权限信息存储到后台模块中。

在本申请的一些实施例中，权限管理模块还用于响应应用程序的权限修改指令，修改用户标识信息对应的用户权限。

在本申请的一些实施例中，权限修改指令包括权限设置指令，权限继承指令，其中，响应应用程序的权限修改指令，修改用户标识信息对应的用户权限的步骤包括：响应权限设置指令，确定用户账号在访问应用程序时对应的角色，其中，应用程序对应多个角色，角色为通过应用程序执行目标功能时所需的最小权限集合；响应权限继承指令，将第一角色对应的权限集合赋予第二角色对应的权限集合，并确定第二角色为用户账号对应的角色。

图3是根据本申请实施例提供的一种权限模型的示意图，本申请以权限认证作为核心底座，权限管理模块形成标准的原则模型，如图3所示，权限认证包括如下原则：

1)多对多关系，一个用户可以有不同的角色，同时每个角色都至少有一个权限，用户和权限被分离独立，使得权限的授权认证更加灵活。

2)角色继承，继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承，适合于角色之间层次分明，可以给角色分组分层，例如，可以通过权限继承指令，将角色A(即上述第一角色)对应的权限集合赋予角色B(即上述第二角色)对应的权限集合。

举例说明，假设公司岗位具有上下级关系，且上级拥有下级的所有权限，此公司中角色包括：员工、主管、老板、三者级别依次递增，则在系统中可以设置老板角色多继承员工角色和主观角色的全部权限，通过上述角色继承关系的设定可以避免当员工角色或主管角色对应的权限增加后，在无继承的情况下出现员工或主观有权限而老板无权限的问题。

3)互斥角色，同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。互斥角色是指各自权限互相制约的两个角色。对于这类角色一个用户在某一次活动中只能被分配其中的一个角色，不能同时获得两个角色的使用权。

4)基数约束，一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限。同样一个角色对应的访问权限数目也应受限，以控制高级权限在系统中的分配。

举例说明，图4是根据本申请实施例提供的一种用户架构的示意图，可以对图4中所示的一个组织用户可拥有的角色数目进行限制，例如，规定一个组织用户只可以同时拥有用户政府角色、企业角色和协会角色中的一种角色。

5)先决条件角色，可以分配角色给用户仅当该用户已经是另一角色的成员；对应的可以分配访问权限给角色，仅当该角色已经拥有另一种访问权限。指要想获得较高的权限，要首先拥有低一级的权限。

举例说明，只有在用户已拥有主管角色的权限的基础上，才可以为该用户赋予老板角色的权限。

6)运行时互斥，允许一个用户具有两个角色的成员资格，但在运行中不可同时激活这两个角色。

在本申请的一些实施例中，权限管理模块还用于在修改用户标识信息对应的用户权限后，确定用户权限是否符合权限管理标准，并在确定用户权限不符合权限管理标准的情况下，生成并向应用程序反馈警示信息。

具体地，多应用管理系统涉及多个服务端进行发布应用服务，为了防止某一个服务宕机，但不影响正常的业务流程，本申请通过集成注册中心解决当前问题，客户端在调用时通过注册中心获取服务端信息，获取信息之后，再进行调用，如果需要添加加服务，或者服务宕机，只需要修改注册中心的信息即可。

图5是根据本申请实施例提供的一种Nacos注册中心架构的示意图，如图5所示，其中，provider app为服务提供方，用于向nacos注册服务信息及元数据；consumer app为服务消费方，用于从nacos获取服务提供方信息，发起服务调用；open api提供了api与客户端交互，通过api注册删除更新服务信息、配置信息等；config service为配置服务，存储应用的配置信息，实现配置数据的集中管理与动态更新；name service用于将对象名和其关联的元数据的映射管理；consistency protocol为一致性协议，可集群部署实现高可用，使用raft协议选主与数据局同步；nacos console提供了控制台，方便用户查看、修改nacos中的数据，通过集成Nacos注册中心，根据其简单易用的特性集，可以快速实现动态服务发现、服务配置管理、服务及流量管理。更敏捷、更容易地构建、交付和管理整个应用平台。

Nacos可以与Spring、Spring Boot、Spring Cloud等框架集成，并能代替SpringCloud Eureka模块和Spring Cloud Config模块。通过Nacos Server服务和spring-cloud-starter-alibaba-nacos-config配置模块实现配置的动态变更，和spring-cloud-starter-alibaba-nacos-discovery模块实现服务的注册与发现。

通过集成注册中心，本系统可以增添以下保证：

1)服务发现与健康检查，使服务更容易注册自己并通过DNS或HTTP接口发现其它服务。提供服务的实时健康检查，以防止向不健康的主机或服务实例发送请求。

2)动态配置管理，动态配置服务允许所有环境中以集中和动态的方式管理所有服务的配置。消除在更新配置时重新部署应用程序和服务的需要，这使配置更改更加高效和灵活。

3)动态DNS服务，支持加权路由，可以更轻松地在数据中心的生产环境中实施中间层负载平衡，灵活的路由策略，流量控制和简单的DNS解析服务。可以轻松实现基于DNS的服务发现，并防止应用程序耦合到特定于供应商的服务发现API。

4)服务和元数据管理，提供易于使用的服务仪表板，可管理服务元数据、配置、kubernetes DNS、服务运行状况和指标统计。

本申请不仅可以通过注册中心防止出现服务宕机问题，也可以满足大量用户访问、高并发请求。在集成注册中心的基础上，加入负载均衡策略，保证服务的稳定性和安全性，既解决并发压力，提高应用处理性能，又提供故障转移，实现高可用。通过双重保证，提升安全性能防护。

下面对本申请实施例的中多应用管理系统进一步进行介绍。

图6是根据本申请实施例提供的一种权限认证模型的示意图，如图6所示。

本系统通过多应用权限认证架构的设计，全面管理多应用、多组织和多用户等信息，增加组织实体和业务系统双重认证校验，满足不同用户对多个应用的权限访问。整个系统平台以权限认证作为底座核心，系统架构设计上满足可配置和强扩展，兼容不同框架的权限适配，可以高效、快捷地集成多个应用。本平台下的用户账号、用户授权、身份认证、权限控制等行为都由该系统统一管理，每个用户都有唯一的身份标识，并被授予不同的角色权限，通过对用户、角色和权限之间的映射，满足最小权限原则、责任分离原则和数据抽象原则，即可以将角色配置成其完成任务所需的最小权限集合，也可以通过调用相互独立互斥的角色来共同完成敏感的任务，还可以通过权限的抽象来体现角色分配，区别典型的读、写、执行权限。

在本申请的一些实施例中，用户权限包括资源权限和条件权限，其中，资源权限包括以下至少之一：逻辑资源权限，实体资源权限；条件权限包括以下至少之一：可见组织范围权限，限定条件权限，其中，可见组织范围权限用于确定用户账号可访问的应用程序，限定条件权限用于确定用户在访问应用程序时的限定条件。

通过上述步骤，通过对多应用、多组织和多用户的管理，增加组织实体和业务系统双重认证校验，满足不同用户对多个应用的权限访问，对用户和权限的逻辑分离，简化用户和权限的关系，达到了使平台的权限规则更易扩展、更易维护，方便快捷对权限进行管理的目的，进而解决了由于目前在进行系统架构设计时，无法兼容各种不同应用的权限适配，造成对多用户的权限管理复杂繁琐、效率低下技术问题。

根据本申请实施例，还提供了一种应用程序访问的方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本申请实施例所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。图7示出了一种用于实现应用程序访问方法的计算机终端(或电子设备)的硬件结构框图。如图7所示，计算机终端70(或电子设备70)可以包括一个或多个(图中采用702a、702b，……，702n来示出)处理器702(处理器702可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器704、以及用于通信功能的传输模块706。除此以外，还可以包括：显示器、输入/输出接口(I/O接口)、通用串行总线(USB)端口(可以作为BUS总线的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图7所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，计算机终端70还可包括比图7中所示更多或者更少的组件，或者具有与图7所示不同的配置。

应当注意到的是上述一个或多个处理器702和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到计算机终端70(或电子设备)中的其他元件中的任意一个内。如本申请实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。

存储器704可用于存储应用软件的软件程序以及模块，如本申请实施例中的应用程序访问方法对应的程序指令/数据存储装置，处理器702通过运行存储在存储器704内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述应用程序访问方法。存储器704可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器704可进一步包括相对于处理器702远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端70。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置706用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端70的通信供应商提供的无线网络。在一个实例中，传输装置706包括一个网络适配器(Network Interface Controller，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置706可以为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

显示器可以例如触摸屏式的液晶显示器(LCD)，该液晶显示器可使得用户能够与计算机终端70(或电子设备)的用户界面进行交互。

在上述运行环境下，本申请实施例提供了一种应用程序访问方法，图8是根据本申请实施例提供的一种应用程序访问的方法流程的示意图，如图8所示，该方法包括如下步骤：

步骤S802，接收终端设备发送的访问请求，其中，访问请求中携带有登陆终端设备的用户账号的用户标识信息；

步骤S804，依据用户标识信息，确定用户账号的访问权限；

步骤S806，依据访问权限，确定至少一个目标应用，其中，目标应用为用户账号有权限访问的应用；

步骤S808，向终端设备发送至少一个目标应用的应用信息。

需要说明的是，本实施例中图8所示的应用程序访问方法可应用于图1所示的多应用管理系统中，对上述多应用管理系统的相关解释说明也适用于本申请实施例中，在此不再赘述。

本申请实施例还提供了一种非易失性存储介质，非易失性存储介质包括存储的计算机程序，其中，非易失性存储介质所在设备通过运行计算机程序执行以下应用程序访问方法：接收终端设备发送的访问请求，其中，访问请求中携带有登陆终端设备的用户账号的用户标识信息；依据用户标识信息，确定用户账号的访问权限；依据访问权限，确定至少一个目标应用，其中，目标应用为用户账号有权限访问的应用；向终端设备发送至少一个目标应用的应用信息。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

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

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

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

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

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种多应用管理系统，其特征在于，包括多个终端设备，服务器集群，其中，

所述多个终端设备中的每个终端设备，用于向所述服务器发送访问请求，其中，所述访问请求中携带有登陆所述终端设备的用户账号的用户标识信息；

所述服务器，用于依据所述访问请求中的所述用户标识信息，确定与所述用户标识信息对应的用户权限；依据所述用户权限，确定至少一个目标应用，其中，所述目标应用为所述用户账号有权限访问的应用。

2.根据权利要求1所述的多应用管理系统，其特征在于，所述服务器中设置有前台模块，中台模块，后台模块，其中，

所述后台模块，用于存储所述用户账号的用户数据，其中，所述用户数据包括所述用户账号的权限数据和访问行为数据；

所述中台模块，用于向应用程序提供标准接口，其中，所述应用程序通过所述标准接口连接至所述中台模块；

所述前台模块，用于向所述终端设备提供与所述终端设备对应的所述目标应用的应用信息，以及将所述终端设备发送的访问请求转发至对应的应用，其中，每个所述终端设备对应一个所述前台模块。

3.根据权利要求2所述的多应用管理系统，其特征在于，所述服务器中设置有路由层，其中，

所述路由层，用于接收所述访问请求；依据所述访问请求中的用户标识，转发所述访问请求至与所述用户标识对应的前台模块。

4.根据权利要求2所述的多应用管理系统，其特征在于，所述中台模块，还用于依据所述用户权限，从通过所述标准接口连接至所述中台模块的应用程序中确定所述目标应用，并生成包含有所述目标应用的应用信息的所述前台模块。

5.根据权利要求2所述的多应用管理系统，其特征在于，所述服务器还包括权限管理模块，其中，所述权限管理模块用于依据各个用户账号的用户标识信息，从所述应用程序中获取各个用户账号对应的权限信息，并将所述权限信息存储到所述后台模块中。

6.根据权利要求5所述的多应用管理系统，其特征在于，所述权限管理模块还用于响应所述应用程序的权限修改指令，修改所述用户标识信息对应的所述用户权限。

7.根据权利要求6所述的多应用管理系统，其特征在于，所述权限修改指令包括权限设置指令，权限继承指令，其中，所述响应所述应用程序的权限修改指令，修改所述用户标识信息对应的所述用户权限的步骤包括：

响应所述权限设置指令，确定所述用户账号在访问所述应用程序时对应的角色，其中，所述应用程序对应多个角色，所述角色为通过所述应用程序执行目标功能时所需的最小权限集合；

响应所述权限继承指令，将第一角色对应的权限集合赋予第二角色对应的权限集合，并确定所述第二角色为所述用户账号对应的角色。

8.根据权利要求6所述的多应用管理系统，其特征在于，所述权限管理模块还用于在修改所述用户标识信息对应的所述用户权限后，确定所述用户权限是否符合权限管理标准，并在确定所述用户权限不符合所述权限管理标准的情况下，生成并向所述应用程序反馈警示信息。

9.根据权利要求1所述的多应用管理系统，其特征在于，所述用户权限包括资源权限和条件权限，其中，

所述资源权限包括以下至少之一：逻辑资源权限，实体资源权限；

所述条件权限包括以下至少之一：可见组织范围权限，限定条件权限，其中，所述可见组织范围权限用于确定所述用户账号可访问的应用程序，所述限定条件权限用于确定所述用户在访问所述应用程序时的限定条件。

10.一种应用程序访问方法，其特征在于，包括：

接收终端设备发送的访问请求，其中，所述访问请求中携带有登陆所述终端设备的用户账号的用户标识信息；

依据所述用户标识信息，确定所述用户账号的访问权限；

依据所述访问权限，确定至少一个目标应用，其中，所述目标应用为所述用户账号有权限访问的应用；

向所述终端设备发送所述至少一个目标应用的应用信息。

Images