CN115001777A - 跨业务门户系统管理方法 - Google Patents

Abstract

本发明公开一种跨业务门户系统管理方法，包括：S1：建立一门户系统，用户登录门户系统并选择登录方式：若账号密码登录则进入S2；若PKI数字证书登录跳转至S4；S2：系统校验账号、密码及/或用户绑定的IP地址，若通过进入S3；S3：系统启动人像活体检测控件抓取用户照片进行人像活体检测，通过后由预置的人像比对引擎服务进行人像识别验证，验证通过进入S5；S4：系统校验PKI数字证书通过后进入步骤S5；S5：系统跳转至门户系统的综合应用服务界面选择要进入的业务系统，门户系统判断所选业务系统的密级，若为低密级直接进入；若为高密级进入S6；S6：若用户已完成人像识别验证则直接进入业务系统，否则系统启动人像活体检测与人像识别验证。

Description

跨业务门户系统管理方法

技术领域

本发明涉及计算机技术领域，具体而言，涉及一种跨业务门户系统管理方法。

背景技术

近年来，随着公安业务的不断变化及信息化水平的快速发展，使得大背景下公安业务应用系统数量不断增加，各业务警种都建设有属于自己的管理系统，各系统之间没有统一的用户数据管理机制，导致各业务系统的用户与机构信息不一致、更新维护不及时、接入标准不一致等问题凸显，使得窗口民警在日常办公时需根据业务需求逐一登录、认证到不同的系统，影响办公效率。

此外，每一套业务系统都有自己的权限管理流程，可是当面临不同业务部门之间人员调动、岗位变化较为频繁的时候，权限管理就会变得非常复杂。比如当民警变更岗位后，与其关联的各业务系统的管理员都需要花费时间解决其访问权限设置问题；或者当民警离职时，与其关联的各系统管理员则需要对其权限进行清除，而在如此复杂的流程中，管理员很容易出现遗漏或差错，这无形之中增加了日常管理的工作量。同时，工作人员在处理各业务的同时大量的消息也无法集中展示，想要查看不同业务系统的消息需要在各系统间切换，各业务系统之间也缺乏统一的技术标准，使得业务系统接入改造耗时耗力。在实际应用时会产生如下问题：

1)不能集中访问各业务系统，需要多次登录；缺乏有效的维护机制，当系统运行较长时间后，会出现用户信息数据不全、数据更新不及时的问题；各系统也无法有效维护，缺乏有效的分级管理机制；

2)权限管理复杂，身份权限信息不集中、角色不能够快速的分配；

3)无法集中展示业务消息，查看各系统消息切换耗时大；

4)没有统一的技术标准，各业务系统接入改造耗时耗力。

因此，需要一套能够统一管理的机制，将各业务系统进行集中的统一管理，解决民警重复操作的问题，提高警务人员工作效率。

发明内容

为了解决上述问题，本发明提供一种跨业务门户系统管理方法，通过门户系统将分散在各个业务系统中的用户帐户信息、组织机构信息进行整合，建立统一数据规范，降低各类警务应用在用户数据获取、管理等方面的开发难度，避免重复建设，提供各个应用系统服务，登录一次即可访问所有相互信任对接的应用系统，无需二次登录。

本发明的另一目的在于，通过统一权限为各类应用系统提供一致的身份权限认证信息，实现快速授权，解决对系统访问用户的身份权限信息集中管理；统一横跨多个单一业务系统的消息，提供统一的消息接收和消息发送服务，解决民警使用业务系统的消息隔阂，从而能够第一时间查看最新消息，实现了各类待办或通知的消息提醒统一在门户系统中展现，而无需进入各业务系统去查看，使重要且紧急的待办消息能够及时处理。且统一消息还能够提供统一的消息接收和发送接口、统一的消息报文标准以及统一的消息分类标准。

为达到上述目的，本发明提供了一种跨业务门户系统管理方法，具体包括：

步骤S1：建立一门户系统作为访问各业务系统的统一入口，用户登录所述门户系统并选择登录方式：

若选择账号密码的方式登录，则进入步骤S2；

若选择PKI数字证书的方式登录，则跳转至步骤S4；

步骤S2：在用户输入账号和密码后，系统校验账号、密码及/或用户绑定的IP地址是否正确，如果校验通过进入步骤S3，否则在用户登录界面给出校验不通过的提示；

步骤S3：系统启动人像活体检测控件抓取用户照片并进行人像活体检测，若人像活体检测不通过返回用户登录界面并给出校验不通过的提示；在人像活体检测通过后由预置的人像比对引擎服务将抓取的用户照片与对应账户所绑定的身份信息进行人像识别验证，若验证通过进入步骤S5，否则返回用户登录界面并给出验证不通过的提示；

步骤S4：系统校验用户接入的PKI数字证书中的用户信息，如果验证通过则进入步骤S5，否则返回用户登录界面并给出验证不通过的提示；

步骤S5：系统跳转至所述门户系统的综合应用服务界面，选择需要进入的业务系统，所述门户系统判断所选择的业务系统的密级：

当所选业务系统为低密级时，直接进入所选业务系统；

当所选业务系统为高密级时，进入步骤S6；

步骤S6：判断此用户是否已经完成人像识别验证：

如果是则直接进入所选业务系统；

否则系统启动人像活体检测控件抓取用户照片并进行人像活体检测，若人像活体检测不通过返回综合应用服务界面并给出校验不通过的提示；在人像活体检测通过后由预置的人像比对引擎服务将抓取的用户照片与对应账户所绑定的身份信息进行人像识别验证，若验证通过进入直接进入所选业务系统，否则返回综合应用服务界面并给出验证不通过的提示。

在本发明一实施例中，其中，步骤S5中还包括在每个业务系统中加载用户在对应系统中的权限菜单，并对各业务系统进行单点登录，其具体包括：

步骤S51：当用户通过门户系统访问任一业务系统时，业务系统的SSO客户端的过滤器分析HTTP请求的session中是否包含TGT，如果没有说明该用户没有认证；

步骤S52：重定向用户请求到对应SSO服务端的登录页面；

步骤S53：由用户通过输入动态密码或者使用PKI数字证书进行登录认证；

步骤S54：认证通过后，对应的SSO服务端产生一Server Ticket，缓存该ServerTicket并且重定向回SSO客户端；同时SSO服务端还生成TGT，用于记录用户登陆令牌，并在浏览器Cookie中保存TGT；

步骤S55：SSO客户端拦截到用户请求，分析请求中有Server Ticket，则发送到SSO服务端对用户信息进行核实，SSO服务端对比缓存中的Server Ticket，验证通过后返回用户信息并清除缓存中该Server Ticket。

在本发明一实施例中，其中，还包括建立门户系统的用户管理中心，并对用户管理中心的数据进行统一管理与维护，其中，用户管理中心包括面向各业务系统的标准服务接口，标准服务接口的请求类型为POST请求，请求参数包括应用编号、用户身份证、机构代码及\或角色代码，其中用户身份证、机构代码和角色代码三者不能同时为空。

在本发明一实施例中，其中，还包括建立门户系统的数据库，数据库包括用户数据库、系统配置信息及认证缓存信息，其中用户数据库的用户数据由预设的各级用户管理员分别管理维护，当用户数据发生更新时，用户管理中心自动将其同步到各应用系统。

在本发明一实施例中，其中，还包括用户角色管理与用户权限管理，具体采用RBAC权限模型，其包括：用户、角色和权限，其中：

为每个用户设置唯一的UID识别，并根据需求授予每个用户不同的角色；

为不同角色设置不同的权限；

用户与角色之间存在映射关系，且角色与权限之间存在映射关系。

在本发明一实施例中，其中，还包括统一消息管理，其包括统一消息管理端及统一消息推送端，并采用kafka发布-订阅模式，具体包括：

各业务系统作为消费者订阅一个或多个主题；

各业务系统作为生产者向统一消息管理端发布消息；以及

统一消息推送端根据各业务系统的订阅推送对应消息，对应消息显示在门户系统中。

本发明提供的跨业务门户系统管理方法，与现有技术相比，通过门户系统将个业务系统的接口整合到一起，实现统一的用户管理、统一的角色管理、统一的权限管理和统一的消息管理。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明一实施例的流程图；

图2为本发明任一业务系统的单点登录流程示意图；

图3为本发明一实施例的用户角色与用户权限映射示意图；

图4为本发明一实施例的消息管理示意图。

具体实施方式

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

图1为本发明一实施例的流程图，如图1所示，本实施例提供一种跨业务门户系统管理方法，具体包括：

步骤S1：建立一门户系统作为访问各业务系统的统一入口，用户登录所述门户系统并选择登录方式：

若选择账号密码的方式登录，则进入步骤S2；账号密码认证是较为普遍的身份认证方法，通常采用如下形式：当用户需要访问系统资源时，系统提示用户输入用户名和密码。系统将用户名和密码传送到认证中心，并和认证中心保存的用户信息进行比对，如果验证通过则允许该用户进行访问操作。

若选择PKI(Public Key Infrastructure)数字证书的方式登录，则跳转至步骤S4；数字证书是目前最常见一种比较安全的身份认证技术。数字证书技术是在PKI体系基础上实现的，用户不但可以通过数字证书完成身份认证，还可以进一步安全加密，数字签名等。

门户系统作为用户访问使用系统的统一入口，可以提供使用系统各项功能、访问相关应用导航功能模块，集中展现各类用户关注信息。门户系统的建设应采用符合业界Portal规范的门户软件，并可提供信息发布、消息提醒、单点登录、工作日志等功能，并提供较强的应用界面集成和信息汇聚展现的能力。门户系统通过实现统一认证服务，为用户分配不同的资源及操作权限。用户通过使用访问密钥获得基于认证服务的认证和授权后，以调用API的方式访问平台资源。

认证方式采用统一进行身份认证，即公安大数据中心中所有警员的注册认证信息，可以对所有的警员进行统一认证。同时，考虑到服务效率与认证中心的压力，在认证过程中，可以采用多因子认证，提供多因子认证平台。多因子认证可在使用证书、用户名和密码、短信认证码认证的同时，搭配生物信息进行认证，例如指纹、声纹、瞳孔等进行认证。在操作期间，为确保警员的真实身份，多因子认证平台还可以通过面部识别，进行二次认证，以识别警员身份无误。

步骤S2：在用户输入账号和密码后，系统校验账号、密码及/或用户绑定的IP地址等信息是否正确，如果校验通过进入步骤S3，否则在用户登录界面给出校验不通过的提示；

步骤S3：系统启动人像活体检测控件抓取用户照片并进行人像活体检测，若人像活体检测不通过返回用户登录界面并给出校验不通过的提示；在人像活体检测通过后由预置的人像比对引擎服务将抓取的用户照片与对应账户所绑定的身份信息进行人像识别验证，若验证通过进入步骤S5，否则返回用户登录界面并给出验证不通过的提示；

步骤S4：系统校验用户接入的PKI数字证书中的用户信息，如果验证通过则进入步骤S5，否则返回用户登录界面并给出验证不通过的提示；

步骤S5：系统跳转至所述门户系统的综合应用服务界面，选择需要进入的业务系统，所述门户系统判断所选择的业务系统的密级：

当所选业务系统为低密级时，直接进入所选业务系统；

当所选业务系统为高密级时，进入步骤S6；

在本实施例中，各业务系统可以以图标或链接的形式展示在门户系统的综合应用服务界面，用户选择时可以通过点击的方式，本实施例不对其具体形式进行限定。

图2为本发明任一业务系统的单点登录流程示意图，如图2所示，在本实施例中，其中，步骤S5中还包括在每个业务系统中加载用户在对应系统中的权限菜单，并对各业务系统进行SSO(Single Sign On)单点登录，以通过SSO客户端提供的过滤器，拦截用户的web请求，其具体包括：

步骤S51：当用户通过门户系统访问任一业务系统时，业务系统的SSO客户端的过滤器分析HTTP(Hyper Text Transfer Protocol，超文本传输协议)请求的session(为计算机网络应用中的会话控制)中是否包含TGT(Ticket Granting Ticket，是CAS为用户签发的登录Ticket，也是用于验证用户登录成功的唯一方式，TGT封装了Cookie值以及Cookie值对应的用户信息)，如果没有说明该用户没有认证；

步骤S52：重定向用户请求到对应SSO服务端的登录页面；

步骤S53：由用户通过输入动态密码或者使用PKI数字证书进行登录认证；

步骤S54：认证通过后，对应的SSO服务端产生一Server Ticket(缩写ST，是当用户访问某一服务时提供的Ticket)，缓存该Server Ticket并且重定向回SSO客户端；同时SSO服务端还生成TGT，用于记录用户登陆令牌，并在浏览器Cookie中保存TGT；Server Ticket是一个随机的编码，不可伪造。

步骤S55：SSO客户端拦截到用户请求，分析请求中有Server Ticket，则发送到SSO服务端对用户信息进行核实，SSO服务端对比缓存中的Server Ticket，验证通过后返回用户信息并清除缓存中该Server Ticket。由于这个Server Ticket是SSO服务端在认证中产生的，所以判断通过是毋庸置疑的。此时此业务系统的session中记录了TGT，可用于之后的该用户访问。

步骤S6：判断此用户是否已经完成人像识别验证：

如果是则直接进入所选业务系统；

否则系统启动人像活体检测控件抓取用户照片并进行人像活体检测，若人像活体检测不通过返回综合应用服务界面并给出校验不通过的提示；在人像活体检测通过后由预置的人像比对引擎服务将抓取的用户照片与对应账户所绑定的身份信息进行人像识别验证，若验证通过进入直接进入所选业务系统，否则返回综合应用服务界面并给出验证不通过的提示。

本实施例通过为各应用系统提供统一的用户身份认证服务，确保了应用安全门户入口，只有安全的认证机制才可以保证综合门户不被非法人员进入。且能够提供快速、高效和安全的服务，应用系统接入改造小，并具有灵活的扩展性、高可用性。统一身份认证管理可以为多个不同种类、不同形式的应用提供统一的认证服务，不需要每个业务的应用系统独立开发、设计认证管理，为应用系统快速推出新的业务和服务准备了基础条件，统一身份认证为这些应用提供了统一的接入形式。

同时还提供了多因子身份认证的方式进行认证服务，支持账号密码和数字证书的身份认证的方式，可以实现数字证书登录的用户进行警种验证，如果数字证书的警种与全国人口信息应用门户系统的用户警种不一致则拒绝登录，防止治安外警种的用户在全国人口信息应用门户系统中被误设置为治安警种。

在本实施例中，其中，还包括建立门户系统的用户管理中心，并对用户管理中心的数据进行统一管理与维护，其中，用户管理中心包括面向各业务系统的标准服务接口，用于供各业务系统调用，以获取统一的用户信息，其中，标准服务接口的请求类型为POST请求，请求参数包括应用编号(appCode，对应为业务系统应用的编号)、用户身份证(idCard)、机构代码(orgCode，可视为业务部门代码)及\或角色代码(roleCode)等，其中用户身份证、机构代码和角色代码三者不能同时为空。本实施例的标准服务接口的详细说明见表1。

表1标准服务接口的详细说明

用户管理中心的数据管理、维护可以采用统一用户单位管理员制度，部直各单位和各省市公安局每个单位确定一至两名统一用户管理员，负责本单位机构和用户数据日常管理和维护，各省市公安局可根据用户数量和单位层级，合理设置下级管理员，按照分级管理、分级维护的原则组织本单位数据维护更新工作，从而实现统一的用户管理。

由于公安用户数据来源是多元化的，除了有公安机关的民警、辅警用户数据信息外，还包括了开发人员、施工人员等用户数据信息。这些数据信息都是由人事系统和OA系统导入进来的，并由各级管理员上报各自管理的用户数据，用户管理中心则负责对导入的用户数据信息进行组织机构代码、性别等相关代码的标准化统一，并对所有用户数据关键字段(身份证、手机号等)进行校验，将用户数据合并归一处理。因此，通过数据标准化处理，构建出一套统一的、最新的、最全的用户数据库，并采用“谁管谁维护”的原则对数据更新维护。

用户管理中心在业务功能方面可以提供包括单点登录对接、身份认证、用户管理、机构管理、管理员管理、日志审计、综合查询、名单管理、租户管理、监测管理等，实现主要业务系统的统一用户管理，提供统一标准的用户管理接口。在业务系统对接方面，提供用户管理服务、机构管理服务、单点登录的标准规范文档，实现第三方业务系统调用相关接口。

在本实施例中，其中，还包括建立门户系统的数据库，数据库包括用户数据库、系统配置信息、认证缓存信息等数据，其中用户数据库的用户数据由预设的各级用户管理员分别管理维护，当用户数据发生更新时，用户管理中心自动将其同步到各应用系统，以保障全网用户数据统一。

图3为本发明一实施例的用户角色与用户权限映射示意图，如图3所示，在本实施例中，其中，还包括用户角色管理与用户权限管理，具体采用RBAC(Role-Based AccessControl)权限模型，其包括：用户、角色和权限，其中：

为每个用户设置唯一的UID(User Identification，用户身份证明)识别，并根据需求授予每个用户不同的角色；

为不同角色设置不同的权限；

用户与角色之间存在映射关系，且角色与权限之间存在映射关系。

RBAC权限模型通过定义角色的权限，并对用户授予某个角色从而来控制用户的权限，实现了用户和权限的逻辑分离，极大地方便了权限的管理，具体对获取各角色的接口说明详见表2。

表2获取角色信息的接口说明

统一授权管理能够将各业务应用系统集中统一权限分配管理，可实现统一用户、应用、机构、权限分配服务，实现跨系统、跨区域、跨组织的权限数据支撑，为应用系统提供准确的用户身份权限信息，保障应用访问安全。实现平台环境下的集中权限(Authorization)管理，对各业务应用资源访问权限通过授权服务进行集中控制。用户可以针对不同的项目以及项目中的某个资源进行授权，从而控制不同的用户访问不同的资源。通过细颗粒度的授权，同步菜单及功能资源，给角色进行分配菜单和功能，通过人员授权，实现用户能够访问菜单和功能的权限；实现人员快速批量授权，解决用户角色能够快速的分配；解决权限扩散，给角色限制一定分配数量，只有角色配额的单位才可进行人员角色分配，并支持上级单位批量快速的下发角色配额功能；主要业务系统对接，开放权限信息服务，并提供统一的标准规范。

图4为本发明一实施例的消息管理示意图，如图4所示，在本实施例中，其中，还包括统一消息管理，其包括统一消息管理端及统一消息推送端，并采用kafka(一种高吞吐量的分布式发布订阅消息系统)发布-订阅模式，具体包括：

各业务系统作为消费者订阅一个或多个主题(topic)；

各业务系统作为生产者向统一消息管理端发布消息；以及

统一消息推送端根据各业务系统的订阅推送对应消息，对应消息显示在门户系统中。

由于统一消息采用的是发布-订阅模式，在发布-订阅消息中，消息被持久化到一个topic中，与点对点消息系统不同的是，消费者可以订阅一个或多个topic，消费者可以消费该topic中所有的数据，同一条数据可以被多个消费者消费，数据被消费后不会立马删除。在发布-订阅消息系统中，消息的生产者称为发布者，消费者称为订阅者，消息发送接口说明详见表3。

表3消息发送接口说明

本发明采用门户系统，所产生的效益主要是能够支持一次登录访问各业务系统，降低各类警务应用在用户数据获取、管理等方面的开发难度。通过灵活的数据同步和梳理策略，可以将分散在各个应用系统中的用户帐户信息、组织机构信息进行整合，建立统一数据规范，降低各类警务应用在用户数据获取、管理等方面的开发难度。

本发明采用统一权限管理产生的效益是能够实现权限快速分配，通过层级和警种业务域实现用户角色快速的分配；防止权限扩散，限制角色分配数量，并支持快速下发机构的角色配额。可以基于云和大数据技术，采用分布式服务和集群架构，提供高并发和高可用的服务。可直接面对全部民警用户开放权限进行管理授权、审计、应用注册等。系统使用角色可以分三种，分别为应用管理员、单位管理员、审计管理员。同时支持通过自定义不同用户对象的访问权限，为各类应用系统提供一致的身份权限认证信息，实现对系统访问用户的身份权限信息集中管理。

本发明采用统一消息管理产生的效益主要是能够将全警业务应用系统的消息接口统一对接到消息中心，把不同种类的消息整合成可管理、高并发、高通用性的消息通知服务，可以提供丰富的支撑性功能和移动端的消息推送服务。消息中心使各业务应用系统的消息传递更加规范、透明，可以摆脱传统的消息查看方式。主要由以下两点：

可以实现应用的待办或通知的消息提醒统一在门户中展现，而无需进入各应用系统去查看，可以避免重要而着急的待办消息不能及时处理。

消息管理中心能够提供统一的消息接收和发送接口、统一的消息报文标准、统一的消息分类标准。统一消息是公安信息化平台的支撑组件。消息中心可以面向全平台提供统一的消息提醒和消息订阅服务等功能，同时消息服务中心也能横跨多个单一业务应用系统，提供统一的消息接收和消息发送服务。消息中心以API接口的方式调用各应用的消息处理接口，实现全平台、各业务应用的消息进行统一的接收和发送。当各类业务应用系统的消息汇聚到消息中心形成不同分类的消息格式，如代办类、通知类、预警类等类型供民警快速查看，且消息中心支持消息的综合查询功能、消息订阅功能、消息的订阅量排行展示和消息的最新发布展示等。消息中心解决民警使用业务应用系统消息的隔阂，从而第一时间查看最新消息，其具有以下优点：

标准统一：采用业界通用的消息对象模型以及统一的消息报文，消息传输规范统一；

体系安全：采用成熟的接入认证以及消息收发的权限控制，保证了消息数据交互的安全性；

集成便捷：采用业界比较成熟的消息接入方式,方便快捷，不影响接入方原有技术框架；

允许发布/订阅流数据：支持订阅/发布多种消息类型，如图片消息、音频消息、视频消息。

本发明的门户系统、统一权限管理、统一消息管理均可采用J2EE技术体系和应用中间件技术。J2EE有极好的跨平台性，基于其建设完成的B/S架构的应用可提供使用者，在公安内网上通过IE等浏览器直接开展工作，同时B/S架构系统的维护只须在服务器端进行即可，便于系统的运维管理。此外，J2EE是国内最为普及的技术实现方法，有大量的专业人才和后备资源备用，最大程度保证系统的长期可持续发展。应用中间件为系统的各类应用服务提供支撑，主要有包括Java应用中间件、数据处理中间件和分布式数据计算中间件等。Java应用中间件主要采用tomcat集群，为系统的门户访问、部分资源应用工具等功能提供支撑。

本发明提供的跨业务门户系统管理方法，与现有技术相比，通过门户系统将个业务系统的接口整合到一起，实现统一的用户管理、统一的角色管理、统一的权限管理和统一的消息管理。

本领域普通技术人员可以理解：附图只是一个实施例的示意图，附图中的模块或流程并不一定是实施本发明所必须的。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围。

Claims (6)

1.一种跨业务门户系统管理方法，其特征在于，包括：

步骤S1：建立一门户系统作为访问各业务系统的统一入口，用户登录所述门户系统并选择登录方式：

若选择账号密码的方式登录，则进入步骤S2；

若选择PKI数字证书的方式登录，则跳转至步骤S4；

步骤S2：在用户输入账号和密码后，系统校验账号、密码及/或用户绑定的IP地址是否正确，如果校验通过进入步骤S3，否则在用户登录界面给出校验不通过的提示；

步骤S3：系统启动人像活体检测控件抓取用户照片并进行人像活体检测，若人像活体检测不通过返回用户登录界面并给出校验不通过的提示；在人像活体检测通过后由预置的人像比对引擎服务将抓取的用户照片与对应账户所绑定的身份信息进行人像识别验证，若验证通过进入步骤S5，否则返回用户登录界面并给出验证不通过的提示；

步骤S4：系统校验用户接入的PKI数字证书中的用户信息，如果验证通过则进入步骤S5，否则返回用户登录界面并给出验证不通过的提示；

步骤S5：系统跳转至所述门户系统的综合应用服务界面，选择需要进入的业务系统，所述门户系统判断所选择的业务系统的密级：

当所选业务系统为低密级时，直接进入所选业务系统；

当所选业务系统为高密级时，进入步骤S6；

步骤S6：判断此用户是否已经完成人像识别验证：

如果是则直接进入所选业务系统；

否则系统启动人像活体检测控件抓取用户照片并进行人像活体检测，若人像活体检测不通过返回综合应用服务界面并给出校验不通过的提示；在人像活体检测通过后由预置的人像比对引擎服务将抓取的用户照片与对应账户所绑定的身份信息进行人像识别验证，若验证通过进入直接进入所选业务系统，否则返回综合应用服务界面并给出验证不通过的提示。

2.根据权利要求1所述的跨业务门户系统管理方法，其特征在于，步骤S5中还包括在每个业务系统中加载用户在对应系统中的权限菜单，并对各业务系统进行单点登录，其具体包括：

步骤S51：当用户通过门户系统访问任一业务系统时，业务系统的SSO客户端的过滤器分析HTTP请求的session中是否包含TGT，如果没有说明该用户没有认证；

步骤S52：重定向用户请求到对应SSO服务端的登录页面；

步骤S53：由用户通过输入动态密码或者使用PKI数字证书进行登录认证；

步骤S54：认证通过后，对应的SSO服务端产生一Server Ticket，缓存该Server Ticket并且重定向回SSO客户端；同时SSO服务端还生成TGT，用于记录用户登陆令牌，并在浏览器Cookie中保存TGT；

步骤S55：SSO客户端拦截到用户请求，分析请求中有Server Ticket，则发送到SSO服务端对用户信息进行核实，SSO服务端对比缓存中的Server Ticket，验证通过后返回用户信息并清除缓存中该Server Ticket。

3.根据权利要求1所述的跨业务门户系统管理方法，其特征在于，还包括建立门户系统的用户管理中心，并对用户管理中心的数据进行统一管理与维护，其中，用户管理中心包括面向各业务系统的标准服务接口，标准服务接口的请求类型为POST请求，请求参数包括应用编号、用户身份证、机构代码及\或角色代码，其中用户身份证、机构代码和角色代码三者不能同时为空。

4.根据权利要求3所述的跨业务门户系统管理方法，其特征在于，还包括建立门户系统的数据库，数据库包括用户数据库、系统配置信息及认证缓存信息，其中用户数据库的用户数据由预设的各级用户管理员分别管理维护，当用户数据发生更新时，用户管理中心自动将其同步到各应用系统。

5.根据权利要求1所述的跨业务门户系统管理方法，其特征在于，还包括用户角色管理与用户权限管理，具体采用RBAC权限模型，其包括：用户、角色和权限，其中：

为每个用户设置唯一的UID识别，并根据需求授予每个用户不同的角色；

为不同角色设置不同的权限；

用户与角色之间存在映射关系，且角色与权限之间存在映射关系。

6.根据权利要求1所述的跨业务门户系统管理方法，其特征在于，还包括统一消息管理，其包括统一消息管理端及统一消息推送端，并采用kafka发布-订阅模式，具体包括：

各业务系统作为消费者订阅一个或多个主题；

各业务系统作为生产者向统一消息管理端发布消息；以及

统一消息推送端根据各业务系统的订阅推送对应消息，对应消息显示在门户系统中。

Images