CN110941844A - 一种认证鉴权方法、系统、电子设备及可读存储介质 - Google Patents
一种认证鉴权方法、系统、电子设备及可读存储介质 Download PDFInfo
- Publication number
- CN110941844A CN110941844A CN201911184319.3A CN201911184319A CN110941844A CN 110941844 A CN110941844 A CN 110941844A CN 201911184319 A CN201911184319 A CN 201911184319A CN 110941844 A CN110941844 A CN 110941844A
- Authority
- CN
- China
- Prior art keywords
- access
- user
- application system
- authentication
- target application
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/606—Protecting data by securing the transmission between two devices or processes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices
Abstract
本申请主要涉及一种认证鉴权方法、系统、电子设备及可读存储介质。通过中心系统可以对用户账号和多个应用系统进行统一管理,以及对多个应用系统之间相互访问进行管理,这样,中心系统在接收到用户端发送的访问请求,并在确定用户认证信息合法后,可以根据鉴权信息表判断用户端是否有权限访问所请求访问的应用系统,在确定具有访问权限后,通过针对该应用系统的访问秘钥(预先与该应用系统建立了信用访问关系),从请求访问的应用系统获取访问结果。这里,访问不同应用系统用到的访问秘钥不同,但采用的鉴权方式相同,可以避免重复开发认证鉴权方式,减少开发所需的工作量,并能适应不同应用系统对于访问权限的不同控制需求。
Description
技术领域
本申请涉及认证技术领域,尤其涉及一种认证鉴权方法、系统、电子设备及可读存储介质。
背景技术
通常,企业拥有大量独立运行的应用系统,用户会根据业务需要对企业的不同应用系统进行访问,各个应用系统之间也存在相互访问的情况,由于不同应用系统支持的语言和所属的架构可能不同,所以每个应用系统提供给用户的认证鉴权方式也会有所不同,致使每个应用系统都需要开发自己的认证鉴权方式,随着应用系统数量的不断增多,对于企业来讲,开发认证鉴权方式的任务量将不断增多,在大量应用系统需要相互访问调用的情况下,也会造成重复开发的问题,而且不同应用系统上会注册有多个用户的用户账号,企业也无法对全部用户账号以及多个应用系统进行统一管理。
发明内容
有鉴于此,本申请实施例的目的在于提供一种认证鉴权方法、系统、电子设备及可读存储介质,可以对多个应用系统和多个用户账号的统一管理,以及对多个应用系统之间相互访问进行管理,进而可以避免重复开发认证鉴权方式,可以减少开发所需的工作量,并能适应不同应用系统对于访问权限的不同控制需求。
本申请主要包括以下几个方面:
第一方面,本申请实施例提供一种认证鉴权方法,应用于中心系统,所述中心系统中存储有鉴权信息表,所述鉴权信息表中包含已注册用户账号对于多个应用系统的访问权限信息,所述认证鉴权方法包括:
接收任一用户账号对应的用户端发送的访问请求;所述访问请求携带有所述用户端请求访问的目标应用系统的系统标识和用户认证信息;
在确定所述用户认证信息合法后,根据所述鉴权信息表、所述目标应用系统的系统标识和所述用户认证信息中的用户账号,判断所述用户端是否有权限访问所述目标应用系统;
在确定所述用户端有权限访问所述目标应用系统后,基于针对所述目标应用系统的访问秘钥,从所述目标应用系统获取访问结果,并将所述访问结果转发至所述用户端。
在一种可能的实施方式中,所述用户认证信息包括访问时间和第一签名信息;所述认证鉴权方法还包括根据以下步骤确定所述用户认证信息是否合法:
根据当前时间与所述访问时间之间的时间差,确定所述访问时间是否有效;
在确定出所述访问时间有效后,根据所述第一签名信息,确定所述用户认证信息是否合法。
在一种可能的实施方式中,根据所述第一签名信息,确定所述用户认证信息是否合法,包括:
在存储的账号信息表中查询出与所述用户账号对应的认证秘钥;所述账号信息表中包含已注册用户账号和已注册用户账号对应的认证秘钥;
根据所述用户账号对应的认证秘钥和所述访问时间,生成第二签名信息;
判断所述第一签名信息与所述第二签名信息是否相同;
若相同,则确定所述用户认证信息合法。
在一种可能的实施方式中,在所述根据所述鉴权信息表、所述目标应用系统的系统标识和所述用户认证信息中的用户账号,判断所述用户端是否有权限访问所述目标应用系统之前,所述认证鉴权方法还包括:
计算所述目标应用系统在历史时间段内被访问的访问次数;
确定所述访问次数小于或等于预设次数。
在一种可能的实施方式中,所述认证鉴权方法还包括:
当所述访问次数大于所述预设次数时,则拒绝所述用户端针对所述目标应用系统的所述访问请求。
在一种可能的实施方式中,在所述根据所述鉴权信息表、所述目标应用系统的标识和所述用户认证信息中的用户账号,判断所述用户端是否有权限访问所述目标应用系统之前,所述认证鉴权方法还包括:
确定与所述目标应用系统之间的访问通道的通道状态,所述通道状态包括开放状态、半开放状态和关闭状态;
确定所述访问通道的通道状态为开放状态;或者确定所述访问通道的通道状态为半开放状态,且基于所述半开放状态对应的通过率确定所述访问通道可用。
在一种可能的实施方式中,所述认证鉴权方法还包括:
若所述访问通道的通道状态为关闭状态,则拒绝所述用户端针对所述目标应用系统的所述访问请求。
在一种可能的实施方式中,所述确定与所述目标应用系统之间的访问通道的通道状态,包括:
获取检测时间段内针对所述目标应用系统的访问的总次数和失败次数;
计算所述失败次数与所述总次数之间的比值;
若所述比值小于或等于第一预设阈值,则确定所述通道状态为所述开放状态;
若所述比值大于所述第一预设阈值且小于或等于第二预设阈值,则确定所述通道状态为所述半开放状态;
若所述比值大于所述第二预设阈值,则确定所述通道状态为所述关闭状态。
在一种可能的实施方式中,所述根据所述鉴权信息表、所述目标应用系统的标识和所述用户认证信息中的用户账号,判断所述用户端是否有权限访问所述目标应用系统,包括:
根据所述用户账号,在所述鉴权信息表中查询出所述用户端有权访问的各个应用系统的系统标识;
在确定所述各个应用系统的系统标识中存在所述目标应用系统的系统标识之后,确定所述用户端有权限访问所述目标应用系统。
在一种可能的实施方式中,所述访问请求中还携带有所述用户端请求访问的API信息;所述鉴权信息表的访问权限信息中包括已注册用户账号对于多个应用系统的API的访问权限;所述基于针对所述目标应用系统的访问秘钥,从所述目标应用系统获取访问结果包括:
基于所述鉴权信息表,查询所述用户端有权访问的所述目标应用系统的API信息中是否包含所述用户端请求访问的API信息;
在确定所述用户端有权访问的所述目标应用系统的API信息中包含所述用户端请求访问的API信息后,基于针对所述目标应用系统的访问秘钥,从所述用户端请求访问的API获取所述访问结果。
在一种可能的实施方式中,所述基于针对所述目标应用系统的访问秘钥,从所述目标应用系统获取访问结果,包括:
根据所述目标应用系统的系统标识,在存储的应用系统信息表中查询出所述目标应用系统对应的所述访问秘钥;所述应用系统信息表中包含多个应用系统的系统标识和所述多个应用系统分别对应的访问秘钥;
根据所述访问秘钥,从所述目标应用系统获取所述访问结果。
在一种可能的实施方式中,在所述接收任一用户账号对应的用户端发送的访问请求之前,所述认证鉴权方法还包括:
接收任一未注册用户对应的用户端发送的注册请求;所述注册请求中包括所述未注册用户的用户账号、所述未注册用户对应的用户端请求访问的应用系统的系统标识和所述未注册用户对应的用户端请求访问的应用系统的API信息;
在确定所述注册请求通过审核后,为所述未注册用户分配认证秘钥,并将所述认证秘钥、所述用户账号存储至账号信息表,以及将所述未注册用户有权访问的应用系统的系统标识、有权访问的应用系统的API信息存储至所述鉴权信息表,并将分配的认证秘钥发送至所述未注册用户对应的用户端。
在一种可能的实施方式中,所述认证鉴权方法还包括:
接收任一应用系统的接入请求;所述接入请求包括所述应用系统的系统标识,以及所述应用系统的API信息;
在确定所述接入请求通过审核后,为请求的应用系统分配访问秘钥,并将所述访问秘钥、所述请求的应用系统的系统标识、以及所述请求的应用系统的API信息存储至应用系统信息表中,并将所述访问秘钥发送至所述请求的应用系统。
第二方面,本申请实施例还提供一种认证鉴权系统,所述认证鉴权系统中存储有鉴权信息表,所述鉴权信息表中包含已注册用户账号对于多个应用系统的访问权限信息,所述认证鉴权系统包括:
接收模块,用于接收任一用户账号对应的用户端发送的访问请求;所述访问请求携带有所述用户端请求访问的目标应用系统的系统标识和用户认证信息;
判断模块,用于在确定所述用户认证信息合法后,根据所述鉴权信息表、所述目标应用系统的系统标识和所述用户认证信息中的用户账号,判断所述用户端是否有权限访问所述目标应用系统;
获取模块,用于在确定所述用户端有权限访问所述目标应用系统后,基于针对所述目标应用系统的访问秘钥,从所述目标应用系统获取访问结果,并将所述访问结果转发至所述用户端。
在一种可能的实施方式中,所述用户认证信息包括访问时间和第一签名信息;所述认证鉴权系统还包括确定模块;所述确定模块包括:
第一确定单元,用于根据当前时间与所述访问时间之间的时间差,确定所述访问时间是否有效;
第二确定单元,用于在确定出所述访问时间有效后,根据所述第一签名信息,确定所述用户认证信息是否合法。
在一种可能的实施方式中,所述第二确定单元,用于根据以下步骤确定所述用户认证信息是否合法:
在存储的账号信息表中查询出与所述用户账号对应的认证秘钥;所述账号信息表中包含已注册用户账号和已注册用户账号对应的认证秘钥;
根据所述用户账号对应的认证秘钥和所述访问时间,生成第二签名信息;
判断所述第一签名信息与所述第二签名信息是否相同;
若相同,则确定所述用户认证信息合法。
在一种可能的实施方式中,所述认证鉴权系统还包括限流模块;所述限流模块,用于:
计算所述目标应用系统在历史时间段内被访问的访问次数;
确定所述访问次数小于或等于预设次数。
在一种可能的实施方式中,所述限流模块,还用于:
当所述访问次数大于所述预设次数时,则拒绝所述用户端针对所述目标应用系统的所述访问请求。
在一种可能的实施方式中,所述认证鉴权系统还包括熔断模块;所述熔断模块,用于:
获取与所述目标应用系统之间的访问通道的通道状态,所述通道状态包括开放状态、半开放状态和关闭状态;
确定所述访问通道的通道状态为开放状态;或者确定所述访问通道的通道状态为半开放状态,且基于所述半开放状态对应的通过率确定所述访问通道可用。
在一种可能的实施方式中,所述熔断模块,还用于:
若所述访问通道的通道状态为关闭状态,则拒绝所述用户端针对所述目标应用系统的所述访问请求。
在一种可能的实施方式中,所述熔断模块,用于根据以下步骤确定所述通道状态:
统计在检测时间段内访问所述目标应用系统的失败次数和总次数;
计算所述失败次数与所述总次数之间的比值;
若所述比值小于或等于第一预设阈值,则确定所述通道状态为所述开放状态;
若所述比值大于所述第一预设阈值且小于或等于第二预设阈值,则确定所述通道状态为所述半开放状态;
若所述比值大于所述第二预设阈值,则确定所述通道状态为所述关闭状态。
在一种可能的实施方式中,所述判断模块包括:
第一查询单元,用于根据所述用户账号,在所述鉴权信息表中查询出所述用户端有权访问的各个应用系统的系统标识;
第三确定单元,用于在确定所述各个应用系统的系统标识中存在所述目标应用系统的系统标识之后,确定所述用户端有权限访问所述目标应用系统。
在一种可能的实施方式中,所述访问请求中还携带有所述用户端请求访问的API信息;所述鉴权信息表的访问权限信息中包括已注册用户账号对于多个应用系统的API的访问权限;所述获取模块包括:
第二查询单元,用于基于所述鉴权信息表,查询所述用户端有权访问的所述目标应用系统的API信息中是否包含所述用户端请求访问的API信息;
第一获取单元,用于在确定所述用户端有权访问的所述目标应用系统的API信息中包含所述用户端请求访问的API信息后,基于针对所述目标应用系统的访问秘钥,从所述用户端请求访问的API获取所述访问结果。
在一种可能的实施方式中,所述获取模块包括:
第三查询单元,用于根据所述目标应用系统的系统标识,在存储的应用系统信息表中查询出所述目标应用系统对应的所述访问秘钥;所述应用系统信息表中包含多个应用系统的系统标识和所述多个应用系统分别对应的访问秘钥;
第二获取单元,用于根据所述访问秘钥,从所述目标应用系统获取所述访问结果。
在一种可能的实施方式中,所述认证鉴权系统还包括第一存储模块:
所述接收模块,还用于接收任一未注册用户对应的用户端发送的注册请求;所述注册请求中包括所述未注册用户的用户账号、所述未注册用户对应的用户端请求访问的应用系统的系统标识和所述未注册用户对应的用户端请求访问的应用系统的API信息;
所述第一存储模块,用于在确定所述注册请求通过审核后,为所述未注册用户分配认证秘钥,并将所述认证秘钥、所述用户账号存储至账号信息表,以及将所述未注册用户有权访问的应用系统的系统标识、有权访问的应用系统的API信息存储至所述鉴权信息表,并将分配的认证秘钥发送至所述未注册用户对应的用户端。
在一种可能的实施方式中,所述认证鉴权系统还包括第二存储模块:
所述接收模块,还用于接收任一应用系统的接入请求;所述接入请求包括所述应用系统的系统标识,以及所述应用系统的API信息;
所述第二存储模块,用于在确定所述接入请求通过审核后,为请求的应用系统分配访问秘钥,并将所述访问秘钥、所述请求的应用系统的系统标识、以及所述请求的应用系统的API信息存储至应用系统信息表中,并将所述访问秘钥发送至所述请求的应用系统。
第三方面,本申请实施例还提供一种电子设备,包括:处理器、存储器和总线,所述存储器存储有所述处理器可执行的机器可读指令,当电子设备运行时,所述处理器与所述存储器之间通过所述总线进行通信,所述机器可读指令被所述处理器运行时执行上述第一方面或第一方面中任一种可能的实施方式中所述的认证鉴权方法的步骤。
第四方面,本申请实施例还提供了一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器运行时执行上述第一方面或第一方面中任一种可能的实施方式中所述的认证鉴权方法的步骤。
本申请实施例中,通过中心系统可以对用户账号和多个应用系统进行统一管理,以及对多个应用系统之间相互访问进行管理,这样,中心系统在接收到用户端发送的访问请求,并在确定用户认证信息合法后,可以根据鉴权信息表判断用户端是否有权限访问所请求访问的应用系统,在确定具有访问权限后,通过针对该应用系统的访问秘钥,从请求访问的应用系统获取访问结果。这里,访问不同应用系统用到的访问秘钥不同,但采用的鉴权方式相同,可以避免重复开发认证鉴权方式,减少开发所需的工作量,并能适应不同应用系统对于访问权限的不同控制需求。
为使本申请的上述目的、特征和优点能更明显易懂,下文特举较佳实施例,并配合所附附图,作详细说明如下。
附图说明
为了更清楚地说明本申请实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,应当理解,以下附图仅示出了本申请的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他相关的附图。
图1示出了本申请实施例所提供的一种认证鉴权系统的架构示意图;
图2示出了本申请实施例所提供的一种认证鉴权方法的流程图;
图3示出了本申请实施例所提供的一种认证鉴权系统的功能模块图之一;
图4示出了本申请实施例所提供的一种认证鉴权系统的功能模块图之二;
图5示出了图4所示的确定模块的功能模块图;
图6示出了图4所示的判断模块的功能模块图;
图7示出了图4所示的一种获取模块的功能模块图;
图8示出了图4所示的另一种获取模块的功能模块图;
图9示出了本申请实施例所提供的一种电子设备的结构示意图。
主要元件符号说明:
图中:110-中心系统;120-应用系统;130-用户端;300-认证鉴权系统;310-接收模块;320-判断模块;322-第一查询单元;324-第三确定单元;330-获取模块;332-第二查询单元;334-第一获取单元;336-第三查询单元;338-第二获取单元;340-确定模块;342-第一确定单元;344-第二确定单元;350-限流模块;360-熔断模块;370-第一存储模块;380-第二存储模块;900-电子设备;910-处理器;920-存储器;930-总线。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,应当理解,本申请中的附图仅起到说明和描述的目的,并不用于限定本申请的保护范围。另外,应当理解,示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应当理解,流程图的操作可以不按顺序实现,没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外,本领域技术人员在本申请内容的指引下,可以向流程图添加一个或多个其他操作,也可以从流程图中移除一个或多个操作。
另外,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此,以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围,而是仅仅表示本申请的选定实施例。基于本申请的实施例,本领域技术人员在没有做出创造性劳动的前提下所获得的全部其他实施例,都属于本申请保护的范围。
为了使得本领域技术人员能够使用本申请内容,结合特定应用场景“用户访问应用系统时如何认证鉴权”,给出以下实施方式,对于本领域技术人员来说,在不脱离本申请的精神和范围的情况下,可以将这里定义的一般原理应用于其他实施例和应用场景。
本申请实施例下述方法、系统、电子设备或计算机可读存储介质可以应用于任何需要进行认证鉴权的场景,本申请实施例并不对具体的应用场景作限制,任何使用本申请实施例提供的认证鉴权方法及系统的方案均在本申请保护范围内。
值得注意的是,在本申请提出之前,现有方案中,企业会拥有大量独立运行的应用系统,用户会根据业务需要对企业的不同应用系统进行访问,各个应用系统之间也存在相互访问的情况,由于不同应用系统支持的语言和所属的架构可能不同,所以每个应用系统提供给用户的认证鉴权方式也会有所不同,致使每个应用系统都需要开发自己的认证鉴权方式,随着应用系统数量的不断增多,对于企业来讲,开发认证鉴权方式的任务量将不断增多,在大量应用系统需要相互访问调用的情况下,也会造成重复开发的问题,而且不同应用系统上会注册有多个用户的用户账号,企业也无法对全部用户账号以及多个应用系统进行统一管理。
针对上述问题,本申请实施例中,通过中心系统可以对用户账号和多个应用系统进行统一管理,以及对多个应用系统之间相互访问进行管理,这样,中心系统在接收到用户端发送的访问请求,并在确定用户认证信息合法后,可以根据鉴权信息表判断用户端是否有权限访问所请求访问的应用系统,在确定具有访问权限后,通过针对该应用系统的访问秘钥(预先与该应用系统建立了信用访问关系),从请求访问的应用系统获取访问结果。这里,访问不同应用系统用到的访问秘钥不同,但采用的鉴权方式相同,可以避免重复开发认证鉴权方式,减少开发所需的工作量,并能适应不同应用系统对于访问权限的不同控制需求。
需要说明的是,本申请的创新之处不在于如何鉴权,而在于通过中心系统对多个应用系统(内部系统)的统一管理,以及对多个应用系统之间相互访问的管理。基于此,各个用户账号都可以注册到中心系统上,用户账号对应的用户端可以通过中心系统来访问应用系统,中心系统访问不同应用系统用到的访问秘钥不同,但采用的鉴权方式相同,可以避免重复开发认证鉴权方式,减少开发所需的工作量,并能适应不同应用系统对于访问权限的不同控制需求。
为便于对本申请进行理解,下面结合具体实施例对本申请提供的技术方案进行详细说明。
首先,对本申请可适用的认证鉴权系统的架构进行说明。如图1所示,为本申请实施例提供的一种可适用的认证鉴权的系统架构示意图,包括中心系统110、至少一个应用系统120和至少一个用户端130,其中,至少一个应用系统120事先与中心系统110建立了信用访问连接,中心系统110可以凭借事先约定的访问秘钥对应用系统120进行访问,中心系统110针对不同应用系统120,会使用该应用系统120对应的访问秘钥访问该应用系统120,不同应用系统120对应的访问秘钥不同,这样,可以实现中心系统110对至少一个应用系统120的统一管理;不同用户通过用户端130在中心系统110上注册有不同的用户账号,用户可以凭借事先约定的认证秘钥登录中心系统110上的用户账号,并通过中心系统110访问不同应用系统120,这样,中心系统110可以统一管理各个用户账号,用户通过中心系统110使用统一的认证鉴权方式可以实现对各个应用系统120的访问。
这里,中心系统110上存储有鉴权信息表、账号信息表、应用系统信息表,其中,鉴权信息表中包含已注册用户账号对于多个应用系统120的访问权限信息,这样,任一用户账号对应的用户端130发送访问请求时,中心系统110在确定用户认证信息合法后,可以在鉴权信息表中查询出该用户账号可以访问哪些应用系统120的权限,并判断用户端130是否有权限访问请求访问的应用系统120;账号信息表中包含已注册用户账号和已注册用户账号对应的认证秘钥;应用系统信息表中包含多个应用系统120的系统标识和多个应用系统120分别对应的访问秘钥。
需要说明的是,上述鉴权信息表、账号信息表、应用系统信息表可以分别为独立的表,也可以包含于一张总表中,即为一张表。
鉴于上述对认证鉴权系统架构的描述,下面对任一用户账号对应的用户端130通过中心系统110访问目标应用系统120进行说明,以便说明本申请实施例提供的认证鉴权方法。
图2为本申请实施例所提供的一种认证鉴权方法的流程图。如图2所示,本申请实施例提供的认证鉴权方法,应用于中心系统,所述中心系统中存储有鉴权信息表,所述鉴权信息表中包含已注册用户账号对于多个应用系统的访问权限信息,包括以下步骤:
S201:接收任一用户账号对应的用户端发送的访问请求;所述访问请求携带有所述用户端请求访问的目标应用系统的系统标识和用户认证信息。
在具体实施中,中心系统实时获取任意一个用户账号对应的用户端发送的针对目标应用系统的访问请求,这里,访问请求中携带有该用户端请求访问的目标应用系统的系统标识和用户认证信息,中心系统在获取到目标应用系统的系统标识后,可以知晓该用户端请求访问的是哪一个应用系统,用户认证信息用于认证该用户账号是否为事先注册到中心系统的账号。
一示例中,访问请求可以为http://center.com/get_api_result/system:S2,user:U1,params:,t:1567497268,sign:6512bd43d9caa6e02c990b0a82652dca},其中,目标应用系统的系统标识为系统名称S2,用户认证信息包括用户账号的名称U1、访问时间的时间戳1567497268,第一签名信息6512bd43d9caa6e02c990b0a82652dca。
需要说明的是,用户认证信息中的访问时间可以由客户端获取,并加入访问请求中的,也可以是由中心系统获取的。
进一步地,中心系统在接收到用户端发送的访问请求后,会根据用户认证信息对用户端对应的用户账号进行认证,以确定用户是否为合法用户,这里,用户认证信息包括访问时间和第一签名信息;具体地,根据以下步骤确定所述用户认证信息是否合法:
步骤a:根据当前时间与所述访问时间之间的时间差,确定所述访问时间是否有效。
在具体实施中,中心系统在接收到任一用户账号对应的用户端发送的访问请求时,从访问请求中解析出用户认证信息,这里,认证信息中包括访问时间,进一步地,计算当前时间与用户认证信息中的访问时间之间的时间差,并判断时间差是否小于或等于预设时效阈值,若时间差小于或等于预设时效阈值,则确定访问时间有效,在确定访问时间有效后,才对用户账号是否合法进行进一步判断;若时间差大于预设时效阈值,则确定访问时间无效,在确认无效后,拒绝用户端的访问请求,并向用户端发送访问超时的消息,以提醒用户端对应的用户重新发起访问请求。其中,预设时效阈值可以根据实际需要提前进行设定,优选为1分钟。
步骤b:在确定出所述访问时间有效后,根据所述第一签名信息,确定所述用户认证信息是否合法。
在具体实施中,在确定出访问时间有效后,才对用户账号是否合法进行进一步判断,具体地,根据用户认证信息中的第一签名信息,确定用户认证信息是否合法,即对用户端对应的用户账号进行认证,以确定该用户账号对应的用户是否为合法用户。
需要说明的是,若确定用户认证信息合法,可以说明用户端对应的用户账号为事先注册到中心系统的账号,这样,中心系统可以帮助该用户账号对应的用户对需要访问的目标应用系统进行访问。
进一步地,在步骤b中根据所述第一签名信息,确定所述用户认证信息是否合法,包括以下步骤:
在存储的账号信息表中查询出与所述用户账号对应的认证秘钥;所述账号信息表中包含已注册用户账号和已注册用户账号对应的认证秘钥;根据所述用户账号对应的认证秘钥和所述访问时间,生成第二签名信息;判断所述第一签名信息与所述第二签名信息是否相同;若相同,则确定所述用户认证信息合法。
在具体实施中,中心系统在账号信息表中查询出该用户账号对应的认证秘钥,并根据该认证秘钥和用户认证信息中的访问时间,生成第二签名信息,这里,可以使用消息摘要算法5(Message-Digest Algorithm 5,MD5)生成第二签名信息,进而,判断用户认证信息中的第一签名信息是否与第二签名信息是否相同,若相同,确定出用户认证信息合法,即确定出该用户账号为注册在中心系统的账号。
还需要说明的是,用户端在发送访问请求前,会获取之前在注册账号时中心系统发送的并进行存储的认证秘钥,并根据访问时间和该认证秘钥生成第一签名信息,并在发送访问请求时,在访问请求中携带第一签名信息,这里,第一签名信息和第二签名信息所采用的生成算法相同,都可以采用MD5算法。
这里,在每个用户账号注册至中心系统时,中心系统都会将该用户账号和该用户账号的认证秘钥一一对应存储在账号信息表中,并将认证秘钥发送给用户端,以供用户端发送访问请求时,通过该认证秘钥进行用户账号是否合法的认证。
S202:在确定所述用户认证信息合法后,根据所述鉴权信息表、所述目标应用系统的系统标识和所述用户认证信息中的用户账号,判断所述用户端是否有权限访问所述目标应用系统。
在具体实施中,中心系统在确定用户认证信息合法后,即确认用户账号为已注册的用户后,确定用户账号对应的用户端是否有权限访问目标应用系统,具体地,中心系统在存储的鉴权信息表中查询出用户账号对于多个应用系统的访问权限信息,以及根据用户端请求访问的目标应用系统的系统标识,确定用户端是否有权限访问目标应用系统。
进一步地,步骤S202中根据所述鉴权信息表、所述目标应用系统的系统标识和所述用户认证信息中的用户账号,判断所述用户端是否有权限访问所述目标应用系统,包括以下步骤:
根据所述用户账号,在所述鉴权信息表中查询出所述用户端有权访问的各个应用系统的系统标识;在确定所述各个应用系统的系统标识中存在所述目标应用系统的系统标识之后,确定所述用户端有权限访问所述目标应用系统。
在具体实施中,中心系统在鉴权信息表中查询出用户账号对应的用户端有权访问的各个应用系统的系统标识,这里,鉴权信息表中包含已注册用户账号对于多个应用系统的访问权限信息,并判断该用户账号对应的用户端有权访问的各个应用系统的系统标识中,是否存在目标应用系统的系统标识,若存在,则确定用户端有权访问目标应用系统,若不存在,则确定用户端无权访问目标应用系统,并向用户端发送无权访问目标应用系统的提醒信息和访问失败的信息。
进一步地,在所述根据所述鉴权信息表、所述目标应用系统的系统标识和所述用户认证信息中的用户账号,判断所述用户端是否有权限访问所述目标应用系统之前,所述认证鉴权方法还包括限流检测;其中,根据以下步骤进行限流检测:
计算所述目标应用系统在历史时间段内被访问的访问次数;确定所述访问次数小于或等于预设次数。
在具体实施中,中心系统在确定用户认证信息合法后,对目标应用系统的当前访问进行限流检测,具体地,首先,获取应用信息表中存储的与目标应用系统对应的访问限流参数,访问限流参数包括历史时间段和预设次数,然后,计算目标应用系统在最近历史时间段内被访问的次数,并判断访问次数是否小于或等于预设次数,若是,说明目标应用系统的当前的访问量不满足限流条件,可以允许有权限访问的用户端对目标应用系统的访问。
进一步地,所述认证鉴权方法还包括:当所述访问次数大于所述预设次数时,则拒绝所述用户端针对所述目标应用系统的所述访问请求。
若访问次数大于预设次数,说明目标应用系统的当前的访问量满足限流条件,不允许任何用户端再对目标应用系统进行访问,此时拒绝该用户端针对目标应用系统的访问请求,并向该用户端发送访问失败的消息。通过采用上述方式,可以对访问目标应用系统的访问量进行限制,达到保护目标应用系统的目的,以目标使应用系统更好地提供服务。
需要说明的是,在本发明实施例中所说的拒绝可以理解为,禁止用户端访问目标应用系统,或者说不向用户开放访问目标应用系统的通道,并向用户返回访问错误的指令。
需要说明的是,在一段时间内,若一个应用系统的访问量非常大时,可能出现应用系统崩溃的情况,致使用户无法正常访问应用系统,针对这一技术问题,本申请通过中心系统设置了访问限流设置条件,具体地,在任意一个应用系统与中心系统建立信用访问时,中心系统可以根据该应用系统的实际情况,比如该应用系统的业务信息、配置信息,为该应用系统设置一个访问限流参数,比如,访问频率、历史时间段内的访问次数等,进而在中心系统检测到访问该应用系统的访问量达到访问限流条件时,拒绝用户端针对该应用系统的访问请求,并向用户端发送访问失败的消息。
进一步地,在所述根据所述鉴权信息表、所述目标应用系统的系统标识和所述用户认证信息中的用户账号,判断所述用户端是否有权限访问所述目标应用系统之前,所述认证鉴权方法还包括熔断检测;其中,根据以下步骤进行熔断检测:
确定与所述目标应用系统之间的访问通道的通道状态,所述通道状态包括开放状态、半开放状态和关闭状态;确定所述访问通道的通道状态为开放状态;或者确定所述访问通道的通道状态为半开放状态,且基于所述半开放状态对应的通过率确定所述访问通道可用。
在具体实施中,若所述通道状态为所述开放状态,则判断所述用户端是否有权限访问所述目标应用系统;若所述通道状态为所述半开放状态,基于所述半开放状态对应的预设访问通过概率,确定针对所述访问请求的所述访问通道是否可用;在确定所述访问通道可用后,判断所述用户端是否有权限访问所述目标应用系统;
进一步地,所述认证鉴权方法还包括:
若所述访问通道的通道状态为关闭状态,则拒绝所述用户端针对所述目标应用系统的所述访问请求。
在具体实施中,若所述通道状态为所述关闭状态,则拒绝所述用户端针对所述目标应用系统的所述访问请求,并向所述用户端发送访问失败的消息。
需要说明的是,中心系统在确定用户认证信息合法后,对目标应用系统的当前访问进行熔断检测,具体地,首先,获取应用信息表中存储的与目标应用系统对应的访问熔断参数,然后,根据熔断参数确定与目标应用系统之间的访问通道的通道状态,这里,访问通道的通道状态包括开放状态、半开放状态和关闭状态。若通道状态为开放状态,允许所有有权限的用户端对目标应用系统进行访问;若通道状态为关闭状态,拒绝所有用户端对目标应用系统的访问;若通道状态为半开放状态,只允许应用系统信息表中存储的预设通过概率的访问通过,比如,预设通过概率为30%,则只允许30%的访问通过,对于本次用户端发送的访问请求,需要进行访问是否通过的判断,即在预设通过概率下,计算出本次访问请求对应的访问通道是否满足熔断条件,即访问通道是否可用,在确定访问通道可用后,再进行用户端的权限判定,只有同时满足上述两个条件,中心系统才会帮助用户端通过访问通道访问目标应用系统。这里,一个条件是在用户端发送访问请求时,访问通道没有熔断,即访问通道可用,另一个条件时,该用户端有权限访问目标应用系统。
需要说明的是,为处理高并发业务请求,会为每个应用系统设置熔断机制,通常,在访问任意一个应用系统的失败次数达到一定阈值(例如5秒内20次失败)时,就会启动熔断机制,熔断机制是处理高并发业务、保证应用系统提供的服务正常运行的关键。对于本申请,在任意一个应用系统与中心系统建立信用访问时,中心系统可以根据该应用系统的实际情况,比如该应用系统的业务信息、配置信息,为该应用系统设置一个访问熔断参数,熔断参数比如,通道状态切换条件、不同通道状态下,预设时间段内的失败比例等,进而在中心系统检测到访问该应用系统的访问失败次数占总访问次数的比例达到熔断条件时,关闭中心系统与该应用系统之间的访问通道,拒绝用户端针对该应用系统的访问请求,并向用户端发送访问失败的消息。
进一步地,所述确定与所述目标应用系统之间的访问通道的通道状态,包括:
获取检测时间段内针对所述目标应用系统的访问的总次数和失败次数;计算所述失败次数与所述总次数之间的比值;若所述比值小于或等于第一预设阈值,则确定所述通道状态为所述开放状态;若所述比值大于所述第一预设阈值且小于或等于第二预设阈值,则确定所述通道状态为所述半开放状态;若所述比值大于所述第二预设阈值,则确定所述通道状态为所述关闭状态。
在具体实施中,中心系统从应用系统信息表中,获取目标应用系统的各个通道状态对应第二预设时间段和失败比例,失败比例包括第一阈值和第二阈值,具体地,中心系统统计在最近第二预设时间段内访问目标应用系统的失败次数和总次数,并计算失败次数与总次数之间的比值,当该比值小于或等于第一阈值时,确定与目标应用系统之间的访问通道的通道状态为开放状态,在开放状态下,允许有权限的用户端访问目标应用系统;若该比值大于第一预设阈值且小于或等于第二预设阈值,确定通道状态为半开放状态,在半开放状态,只允许预设通过概率的访问量通过;若该比值大于第二预设阈值,确定通道状态为关闭状态,在关闭状态下,不允许任何用户端访问目标应用系统。这里,通道状态会随着访问失败比例的变化而进行切换,通过采用上述方式,可以来动态判断访问通道的可用性,并通过增加半开放状态这一中间状态,可以使访问通道出现故障时,切换至关闭状态来完全拦截请求,再通过切换回半开放状态分流部分请求,观察目标应用系统返回访问结果成功率,来达到自动恢复的效果。
一示例中,熔断参数中的第二预设时间段为60秒、预设访问通过概率为10%、第一阈值为50%,第二阈值为80%,当第一次请求进入时,系统会记录第一个60秒内的请求次数与失败次数,当到达第二个60秒,会根据第一个60秒的请求通过情况,来确定第二个60秒的访问通道状态,如果请求失败率超过50%,则第二个60秒内的访问通道为半开放状态,这个60秒内,只允许有10%的访问量访问目标应用系统;当到达第三个60秒,会根据第二个60秒的请求通过率情况,来确定第三个60秒的访问通道状态,如果请求失败率超过80%,则第三个60秒内的访问通道切换为关闭状态,这个60秒内,不允许任何用户端对目标应用系统进行访问;如果请求失败率低于50%,则第三个60秒内的访问通道切换为开放状态,这个60秒内,允许有权限的所有用户端对目标应用系统进行访问。
S203:在确定所述用户端有权限访问所述目标应用系统后,基于针对所述目标应用系统的访问秘钥,从所述目标应用系统获取访问结果,并将所述访问结果转发至所述用户端。
在具体实施中,中心系统从鉴权信息表中查询出用户端有权限访问目标应用系统后,获取应用系统信息表中与目标应用系统对应的访问秘钥,通过该访问秘钥来验证中心系统与目标应用系统是否已经建立了信用访问连接,具体地,先根据访问秘钥和访问时间,生成第三签名信息,中心系统将第三签名信息发送给目标应用系统,在接收到目标应用系统反馈回的验证通过消息后,将访问请求发送至目标应用系统,并接收目标应用系统反馈回的访问结果,进而将访问结果转发至用户端。
需要说明的是,目标应用系统在接收到第三签名信息后,将自身存储的秘钥和访问时间生成第四签名信息,并判断第三签名信息和第四签名信息是否相同,若相同,说明中心系统与目标应用系统事先已经建立了信用访问连接,此时,目标应用系统完全信任中心系统,并接受中心系统的访问。
进一步地,步骤S203中基于针对所述目标应用系统的访问秘钥,从所述目标应用系统获取访问结果,包括以下步骤:
根据所述目标应用系统的系统标识,在存储的应用系统信息表中查询出所述目标应用系统对应的所述访问秘钥;所述应用系统信息表中包含多个应用系统的系统标识和所述多个应用系统分别对应的访问秘钥;根据所述访问秘钥,从所述目标应用系统获取所述访问结果。
在具体实施中,中心系统从鉴权信息表中查询出用户端有权限访问目标应用系统后,根据目标应用系统的系统标识,获取应用系统信息表中与目标应用系统对应的访问秘钥,通过该访问秘钥来验证中心系统与目标应用系统是否已经建立了信用访问连接,并在接收到目标应用系统反馈回的验证通过消息后,将访问请求发送至目标应用系统,并接收目标应用系统反馈回的访问结果,进而将访问结果转发至用户端。
进一步地,访问请求中还携带有所述用户端请求访问的API信息;所述鉴权信息表的访问权限信息中包括已注册用户账号对于多个应用系统的API的访问权限;所述基于针对所述目标应用系统的访问秘钥,从所述目标应用系统获取访问结果包括:
基于所述鉴权信息表,查询所述用户端有权访问的所述目标应用系统的API信息中是否包含所述用户端请求访问的API信息;在确定所述用户端有权访问的所述目标应用系统的API信息中包含所述用户端请求访问的API信息后,基于针对所述目标应用系统的访问秘钥,从所述用户端请求访问的API获取所述访问结果。
在具体实施中,中心系统在确定出用户端有权限访问目标应用系统之后,再对用户端是否有权访问目标应用系统的API,这里的API为访问请求中还携带的用户端请求访问的API,具体地,先从鉴权信息表中,查询用户端有权访问的目标应用系统的API信息中是否存在用户端请求访问的API信息,在确定用户端有权访问的目标应用系统的API信息中包含该用户端请求访问的API信息后,通过针对目标应用系统的访问秘钥,通过用户端请求访问的API访问目标应用系统,并从用户端请求访问的API获取访问结果。
需要说明的是,任意一个应用系统在与中心系统建立连接时,会向中心系统提供用于访问该应用系统的应用程序接口的API信息。这样,在任意一个用户端注册至中心系统时,审核用户端是否可以访问请求访问的API,并在鉴权信息表中存储已注册用户账号对于多个应用系统API的访问权限。这里,中心系统可以统一开发的API,这样,不同应用系统可以提供相同的API供用户端访问,不用重复开发相同的API,可以大大减少开发API的工作量。
在步骤S201所述接收任一用户账号对应的用户端发送的访问请求之前,所述认证鉴权方法还包括:任一用户端在中心系统上注册用户账号的步骤,其中,包括以下注册步骤:
步骤(1):接收任一未注册用户对应的用户端发送的注册请求;所述注册请求中包括所述未注册用户的用户端的用户账号、所述未注册用户对应的用户端请求访问的应用系统的系统标识和所述未注册用户对应的用户端请求访问的应用系统的API信息。
在具体实施中,中心系统接收任一用户端发送的注册请求,这里,注册请求中包含用户端的用户账号、所述未注册用户对应的用户端请求访问的应用系统的系统标识和所述未注册用户对应的用户端请求访问的应用系统的API信息。
步骤(2):在确定所述注册请求通过审核后,为所述未注册用户分配认证秘钥,并将所述认证秘钥、所述用户账号存储至账号信息表,以及将所述未注册用户有权访问的应用系统的系统标识、有权访问的应用系统的API信息存储至所述鉴权信息表,并将分配的认证秘钥发送至所述未注册用户对应的用户端。
在具体实施中,中心系统对该用户端发送的注册请求进行审核,审核包括用户账号的审核和对应用系统和API访问权限的审核,在审核通过后,会为用户端分配一个认证秘钥,这里,将认证秘钥和用户账号对应存储在账号信息表中,并将认证秘钥发送给用户端,以便用户端在发送访问请求时,通过认证秘钥进行用户账号的认证,以及将审核通过的用户端有权访问的应用系统的系统标识、请求访问的API信息存储至鉴权信息表,以便,中心系统在收到该用户端发送的访问请求时,查询鉴权信息表,已确定用户端的权限。这里,通过将各个用户端的用户账号统一注册至中心系统,使中心系统可以对各个用户账号进行统一管理,可以方便对用户的历史请求进行分析,比如流量分析、异常监控、用户行为分析等。
进一步地,所述认证鉴权方法还包括:任一应用系统与中心系统建立信用访问连接的步骤,其中,包括以下步骤:
步骤A:接收任一应用系统的接入请求;所述接入请求包括所述应用系统的系统标识,以及所述应用系统的API信息。
在具体实施中,中心系统接收任意一个应用系统发送的接入请求,这里,接入请求包括该应用系统的系统标识,以及该应用系统的API信息。
步骤B:在确定所述接入请求通过审核后,为请求的应用系统分配访问秘钥,并将所述访问秘钥、所述请求的应用系统的系统标识、以及所述请求的应用系统的API信息存储至应用系统信息表中,并将所述访问秘钥发送至所述请求的应用系统。
在具体实施中,中心系统在确定接入请求通过审核后,为该应用系统分配一个访问秘钥,并将访问秘钥发送给该应用系统,以便中心系统通过该访问秘钥对该应用系统进行访问,这里,将该应用系统的系统标识与访问秘钥、该应用系统的API信息对应存储在应用系统信息表中。
在本申请实施例中,通过将各个用户账号注册到中心系统,可以使中心系统统一管理各个用户账号,中心系统在接收到用户端发送的访问请求,并在确定用户认证信息合法后,可以根据鉴权信息表判断用户端是否有权限访问所请求访问的应用系统,其中,鉴权信息表中包含已注册用户账号对于多个应用系统的访问权限信息,在确定具有访问权限后,通过针对该应用系统的访问秘钥,从请求访问的应用系统获取访问结果。这里,访问不同应用系统用到的访问秘钥不同,但采用的鉴权方式相同,可以避免重复开发认证鉴权方式,减少开发所需的工作量,并能适应不同应用系统对于访问权限的不同控制需求。
基于同一申请构思,本申请实施例中还提供了与实施例提供的认证鉴权方法对应的认证鉴权系统,由于本申请实施例中的系统解决问题的原理与本申请上述实施例的认证鉴权方法相似,因此系统的实施可以参见方法的实施,重复之处不再赘述。
参见图3至图8,如图3所示,为本申请实施例提供的一种认证鉴权系统300的功能模块图之一;如图4所示,为本申请实施例提供的一种认证鉴权系统300的功能模块图之二;图5示出了图4所示的确定模块340的功能模块图;图6示出了图4所示的判断模块320的功能模块图;图7示出了图4所示的一种获取模块330的功能模块图;图8示出了图4所示的另一种获取模块330的功能模块图。
认证鉴权系统300中存储有鉴权信息表,所述鉴权信息表中包含已注册用户账号对于多个应用系统的访问权限信息,需要说明的是,这里的认证鉴权系统300可以理解为图1中的中心系统110。
如图3和图4所示,所述认证鉴权系统300包括:
接收模块310,用于接收任一用户账号对应的用户端发送的访问请求;所述访问请求携带有所述用户端请求访问的目标应用系统的系统标识和用户认证信息;
判断模块320,用于在确定所述用户认证信息合法后,根据所述鉴权信息表、所述目标应用系统的系统标识和所述用户认证信息中的用户账号,判断所述用户端是否有权限访问所述目标应用系统;
获取模块330,用于在确定所述用户端有权限访问所述目标应用系统后,基于针对所述目标应用系统的访问秘钥,从所述目标应用系统获取访问结果,并将所述访问结果转发至所述用户端。
在一种可能的实施方式中,所述用户认证信息包括访问时间和第一签名信息;如图4所示,所述认证鉴权系统300还包括确定模块340。
如图5所示,所述确定模块340包括:
第一确定单元342,用于根据当前时间与所述访问时间之间的时间差,确定所述访问时间是否有效;
第二确定单元344,用于在确定出所述访问时间有效后,根据所述第一签名信息,确定所述用户认证信息是否合法。
在一种可能的实施方式中,如图5所示,所述第二确定单元344,用于根据以下步骤确定所述用户认证信息是否合法:
在存储的账号信息表中查询出与所述用户账号对应的认证秘钥;所述账号信息表中包含已注册用户账号和已注册用户账号对应的认证秘钥;
根据所述用户账号对应的认证秘钥和所述访问时间,生成第二签名信息;
判断所述第一签名信息与所述第二签名信息是否相同;
若相同,则确定所述用户认证信息合法。
在一种可能的实施方式中,如图4所示,所述认证鉴权系统300还包括限流模块350;所述限流模块350,用于:
计算所述目标应用系统在历史时间段内被访问的访问次数;
确定所述访问次数小于或等于预设次数。
在一种可能的实施方式中,如图4所示,所述限流模块350,还用于:
当所述访问次数大于所述预设次数时,则拒绝所述用户端针对所述目标应用系统的所述访问请求。
在一种可能的实施方式中,如图4所示,所述认证鉴权系统300还包括熔断模块360;所述熔断模块360,用于:
确定与所述目标应用系统之间的访问通道的通道状态,所述通道状态包括开放状态、半开放状态和关闭状态;
确定所述访问通道的通道状态为开放状态;或者确定所述访问通道的通道状态为半开放状态,且基于所述半开放状态对应的通过率确定所述访问通道可用。
在一种可能的实施方式中,如图4所示,所述熔断模块360,还用于:
若所述访问通道的通道状态为关闭状态,则拒绝所述用户端针对所述目标应用系统的所述访问请求。
在一种可能的实施方式中,如图4所示,所述熔断模块360,用于根据以下步骤确定所述通道状态:
获取检测时间段内针对所述目标应用系统的访问的总次数和失败次数;计算所述失败次数与所述总次数之间的比值;
若所述比值小于或等于第一阈值,则确定所述通道状态为所述开放状态;
若所述比值大于所述第一预设阈值且小于或等于第二预设阈值,则确定所述通道状态为所述半开放状态;
若所述比值大于所述第二预设阈值,则确定所述通道状态为所述关闭状态。
在一种可能的实施方式中,如图6所示,判断模块320包括:
第一查询单元322,用于根据所述用户账号,在所述鉴权信息表中查询出所述用户端有权访问的各个应用系统的系统标识;
第三确定单元324,用于在确定所述各个应用系统的系统标识中存在所述目标应用系统的系统标识之后,确定所述用户端有权限访问所述目标应用系统。
在一种可能的实施方式中,如图7所示,所述访问请求中还携带有所述用户端请求访问的API信息;所述鉴权信息表的访问权限信息中包括已注册用户账号对于多个应用系统的API的访问权限;所述获取模块330包括:
第二查询单元332,用于基于所述鉴权信息表,查询所述用户端有权访问的所述目标应用系统的API信息中是否包含所述用户端请求访问的API信息;
第一获取单元334,在确定所述用户端有权访问的所述目标应用系统的API信息中包含所述用户端请求访问的API信息后,基于针对所述目标应用系统的访问秘钥,从所述用户端请求访问的API获取所述访问结果。
在一种可能的实施方式中,如图8所示,所述获取模块330包括:
第三查询单元336,用于根据所述目标应用系统的系统标识,在存储的应用系统信息表中查询出所述目标应用系统对应的所述访问秘钥;所述应用系统信息表中包含多个应用系统的系统标识和所述多个应用系统分别对应的访问秘钥;
第二获取单元338,用于根据所述访问秘钥,从所述目标应用系统获取所述访问结果。
在一种可能的实施方式中,如图4所示,所述认证鉴权系统300还包括第一存储模块370:
所述接收模块310,还用于接收任一未注册用户对应的用户端发送的注册请求;所述注册请求中包括所述未注册用户的用户账号、所述未注册用户对应的用户端请求访问的应用系统的系统标识和所述未注册用户对应的用户端请求访问的应用系统的API信息;
第一存储模块370,用于在确定所述注册请求通过审核后,为所述未注册用户分配认证秘钥,并将所述认证秘钥、所述用户账号存储至所述账号信息表,以及将所述未注册用户有权访问的应用系统的系统标识、有权访问的应用系统的API信息存储至所述鉴权信息表,并将分配的认证秘钥发送至所述未注册用户对应的用户端。
在一种可能的实施方式中,如图4所示,所述认证鉴权系统300还包括第二存储模块380:
所述接收模块310,还用于接收任一应用系统的接入请求;所述接入请求包括所述应用系统的系统标识,以及所述应用系统的API信息;
所述第二存储模块380,用于在确定所述接入请求通过审核后,为请求的应用系统分配访问秘钥,并将所述访问秘钥、所述请求的应用系统的系统标识、以及所述请求的应用系统的API信息存储至应用系统信息表中,并将所述访问秘钥发送至所述请求的应用系统。
在本申请实施例中,可以对用户账号和多个应用系统进行统一管理,以及对多个应用系统之间相互访问进行管理,这样,在接收到用户端发送的访问请求,并在确定用户认证信息合法后,可以根据鉴权信息表判断用户端是否有权限访问所请求访问的应用系统,在确定具有访问权限后,通过针对该应用系统的访问秘钥,从请求访问的应用系统获取访问结果。这里,访问不同应用系统用到的访问秘钥不同,但采用的鉴权方式相同,可以避免重复开发认证鉴权方式,减少开发所需的工作量,并能适应不同应用系统对于访问权限的不同控制需求。
基于同一申请构思,参见图9所示,为本申请实施例提供的一种电子设备900的结构示意图,包括:处理器910、存储器920和总线930,所述存储器920存储有所述处理器910可执行的机器可读指令,当电子设备900运行时,所述处理器910与所述存储器920之间通过所述总线930进行通信,所述机器可读指令被所述处理器910运行时执行如图2所示的认证鉴权方法的步骤。
具体地,所述机器可读指令被所述处理器910执行时可以执行如下处理:
接收任一用户账号对应的用户端发送的访问请求;所述访问请求携带有所述用户端请求访问的目标应用系统的系统标识和用户认证信息;
在确定所述用户认证信息合法后,根据所述鉴权信息表、所述目标应用系统的系统标识和所述用户认证信息中的用户账号,判断所述用户端是否有权限访问所述目标应用系统;
在确定所述用户端有权限访问所述目标应用系统后,基于针对所述目标应用系统的访问秘钥,从所述目标应用系统获取访问结果,并将所述访问结果转发至所述用户端。
本申请实施例中,通过中心系统可以对用户账号和多个应用系统进行统一管理,以及对多个应用系统之间相互访问进行管理,这样,中心系统在接收到用户端发送的访问请求,并在确定用户认证信息合法后,可以根据鉴权信息表判断用户端是否有权限访问所请求访问的应用系统,在确定具有访问权限后,通过针对该应用系统的访问秘钥,从请求访问的应用系统获取访问结果。这里,访问不同应用系统用到的访问秘钥不同,但采用的鉴权方式相同,可以避免重复开发认证鉴权方式,减少开发所需的工作量,并能适应不同应用系统对于访问权限的不同控制需求。
基于同一申请构思,本申请实施例还提供了一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器运行时执行如图2所示的认证鉴权方法的步骤。
具体地,所述存储介质能够为通用的存储介质,如移动磁盘、硬盘等,所述存储介质上的计算机程序被运行时,能够执行上述认证鉴权方法,访问不同应用系统用到的访问秘钥不同,但采用的鉴权方式相同,可以避免重复开发认证鉴权方式,减少开发所需的工作量,并能适应不同应用系统对于访问权限的不同控制需求。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统和系统的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。在本申请所提供的几个实施例中,应所述理解到,所揭露的系统、系统和方法,可以通过其它的方式实现。以上所描述的系统实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,又例如,多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口,系统或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者所述技术方案的部分可以以软件产品的形式体现出来,所述计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以权利要求的保护范围为准。
Claims (16)
1.一种认证鉴权方法,其特征在于,应用于中心系统,所述中心系统中存储有鉴权信息表,所述鉴权信息表中包含已注册用户账号对于多个应用系统的访问权限信息,所述认证鉴权方法包括:
接收任一用户账号对应的用户端发送的访问请求;所述访问请求携带有所述用户端请求访问的目标应用系统的系统标识和用户认证信息;
在确定所述用户认证信息合法后,根据所述鉴权信息表、所述目标应用系统的系统标识和所述用户认证信息中的用户账号,判断所述用户端是否有权限访问所述目标应用系统;
在确定所述用户端有权限访问所述目标应用系统后,基于针对所述目标应用系统的访问秘钥,从所述目标应用系统获取访问结果,并将所述访问结果转发至所述用户端。
2.根据权利要求1所述的认证鉴权方法,其特征在于,所述用户认证信息包括访问时间和第一签名信息;所述认证鉴权方法还包括根据以下步骤确定所述用户认证信息是否合法:
根据当前时间与所述访问时间之间的时间差,确定所述访问时间是否有效;
在确定出所述访问时间有效后,根据所述第一签名信息,确定所述用户认证信息是否合法。
3.根据权利要求2所述的认证鉴权方法,其特征在于,根据所述第一签名信息,确定所述用户认证信息是否合法,包括:
在存储的账号信息表中查询出与所述用户账号对应的认证秘钥;所述账号信息表中包含已注册用户账号和已注册用户账号对应的认证秘钥;
根据所述用户账号对应的认证秘钥和所述访问时间,生成第二签名信息;
判断所述第一签名信息与所述第二签名信息是否相同;
若相同,则确定所述用户认证信息合法。
4.根据权利要求1所述的认证鉴权方法,其特征在于,在所述根据所述鉴权信息表、所述目标应用系统的系统标识和所述用户认证信息中的用户账号,判断所述用户端是否有权限访问所述目标应用系统之前,所述认证鉴权方法还包括:
计算所述目标应用系统在历史时间段内被访问的访问次数;
确定所述访问次数小于或等于预设次数。
5.根据权利要求4所述的认证鉴权方法,其特征在于,所述认证鉴权方法还包括:
当所述访问次数大于所述预设次数时,则拒绝所述用户端针对所述目标应用系统的所述访问请求。
6.根据权利要求1所述的认证鉴权方法,其特征在于,在所述根据所述鉴权信息表、所述目标应用系统的标识和所述用户认证信息中的用户账号,判断所述用户端是否有权限访问所述目标应用系统之前,所述认证鉴权方法还包括:
确定与所述目标应用系统之间的访问通道的通道状态,所述通道状态包括开放状态、半开放状态和关闭状态;
确定所述访问通道的通道状态为开放状态;或者确定所述访问通道的通道状态为半开放状态,且基于所述半开放状态对应的通过率确定所述访问通道可用。
7.根据权利要求6所述认证鉴权方法,其特征在于,所述认证鉴权方法还包括:
若所述访问通道的通道状态为关闭状态,则拒绝所述用户端针对所述目标应用系统的所述访问请求。
8.根据权利要求6所述的认证鉴权方法,其特征在于,所述确定与所述目标应用系统之间的访问通道的通道状态,包括:
获取检测时间段内针对所述目标应用系统的访问的总次数和失败次数;
计算所述失败次数与所述总次数之间的比值;
若所述比值小于或等于第一预设阈值,则确定所述通道状态为所述开放状态;
若所述比值大于所述第一预设阈值且小于或等于第二预设阈值,则确定所述通道状态为所述半开放状态;
若所述比值大于所述第二预设阈值,则确定所述通道状态为所述关闭状态。
9.根据权利要求1所述的认证鉴权方法,其特征在于,所述根据所述鉴权信息表、所述目标应用系统的标识和所述用户认证信息中的用户账号,判断所述用户端是否有权限访问所述目标应用系统,包括:
根据所述用户账号,在所述鉴权信息表中查询出所述用户端有权访问的各个应用系统的系统标识;
在确定所述各个应用系统的系统标识中存在所述目标应用系统的系统标识之后,确定所述用户端有权限访问所述目标应用系统。
10.根据权利要求9所述的认证鉴权方法,其特征在于,所述访问请求中还携带有所述用户端请求访问的API信息;所述鉴权信息表的访问权限信息中包括已注册用户账号对于多个应用系统的API的访问权限;所述基于针对所述目标应用系统的访问秘钥,从所述目标应用系统获取访问结果包括:
基于所述鉴权信息表,查询所述用户端有权访问的所述目标应用系统的API信息中是否包含所述用户端请求访问的API信息;
在确定所述用户端有权访问的所述目标应用系统的API信息中包含所述用户端请求访问的API信息后,基于针对所述目标应用系统的访问秘钥,从所述用户端请求访问的API获取所述访问结果。
11.根据权利要求1所述的认证鉴权方法,其特征在于,所述基于针对所述目标应用系统的访问秘钥,从所述目标应用系统获取访问结果,包括:
根据所述目标应用系统的系统标识,在存储的应用系统信息表中查询出所述目标应用系统对应的所述访问秘钥;所述应用系统信息表中包含多个应用系统的系统标识和所述多个应用系统分别对应的访问秘钥;
根据所述访问秘钥,从所述目标应用系统获取所述访问结果。
12.根据权利要求1所述的认证鉴权方法,其特征在于,在所述接收任一用户账号对应的用户端发送的访问请求之前,所述认证鉴权方法还包括:
接收任一未注册用户对应的用户端发送的注册请求;所述注册请求中包括所述未注册用户的用户账号、所述未注册用户对应的用户端请求访问的应用系统的系统标识和所述未注册用户对应的用户端请求访问的应用系统的API信息;
在确定所述注册请求通过审核后,为所述未注册用户分配认证秘钥,并将所述认证秘钥、所述用户账号存储至账号信息表,以及将所述未注册用户有权访问的应用系统的系统标识、有权访问的应用系统的API信息存储至所述鉴权信息表,并将分配的认证秘钥发送至所述未注册用户对应的用户端。
13.根据权利要求1所述的认证鉴权方法,其特征在于,所述认证鉴权方法还包括:
接收任一应用系统的接入请求;所述接入请求包括所述应用系统的系统标识,以及所述应用系统的API信息;
在确定所述接入请求通过审核后,为请求的应用系统分配访问秘钥,并将所述访问秘钥、所述请求的应用系统的系统标识、以及所述请求的应用系统的API信息存储至应用系统信息表中,并将所述访问秘钥发送至所述请求的应用系统。
14.一种认证鉴权系统,其特征在于,所述认证鉴权系统中存储有鉴权信息表,所述鉴权信息表中包含已注册用户账号对于多个应用系统的访问权限信息,所述认证鉴权系统包括:
接收模块,用于接收任一用户账号对应的用户端发送的访问请求;所述访问请求携带有所述用户端请求访问的目标应用系统的系统标识和用户认证信息;
判断模块,用于在确定所述用户认证信息合法后,根据所述鉴权信息表、所述目标应用系统的系统标识和所述用户认证信息中的用户账号,判断所述用户端是否有权限访问所述目标应用系统;
获取模块,用于在确定所述用户端有权限访问所述目标应用系统后,基于针对所述目标应用系统的访问秘钥,从所述目标应用系统获取访问结果,并将所述访问结果转发至所述用户端。
15.一种电子设备,其特征在于,包括:处理器、存储器和总线,所述存储器存储有所述处理器可执行的机器可读指令,当电子设备运行时,所述处理器与所述存储器之间通过所述总线进行通信,所述机器可读指令被所述处理器运行时执行如权利要求1至13中任一项所述的认证鉴权方法的步骤。
16.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器运行时执行如权利要求1至13中任一项所述的认证鉴权方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911184319.3A CN110941844B (zh) | 2019-11-27 | 2019-11-27 | 一种认证鉴权方法、系统、电子设备及可读存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911184319.3A CN110941844B (zh) | 2019-11-27 | 2019-11-27 | 一种认证鉴权方法、系统、电子设备及可读存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN110941844A true CN110941844A (zh) | 2020-03-31 |
CN110941844B CN110941844B (zh) | 2022-04-01 |
Family
ID=69908298
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201911184319.3A Active CN110941844B (zh) | 2019-11-27 | 2019-11-27 | 一种认证鉴权方法、系统、电子设备及可读存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110941844B (zh) |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111476640A (zh) * | 2020-04-13 | 2020-07-31 | 江苏思特瑞信息技术有限公司 | 认证方法、系统、存储介质及大数据认证平台 |
CN111985902A (zh) * | 2020-08-25 | 2020-11-24 | 上海帜讯云计算科技有限公司 | 跨系统信息协同管理方法、装置、设备和存储介质 |
CN112328996A (zh) * | 2020-11-25 | 2021-02-05 | 杭州和利时自动化有限公司 | 基于dcs系统的操作认证方法、装置、设备及存储介质 |
CN112804242A (zh) * | 2021-01-25 | 2021-05-14 | 蔡世泳 | 一种无感知自动发现的api安全管理系统及方法 |
CN112818328A (zh) * | 2021-02-26 | 2021-05-18 | 重庆度小满优扬科技有限公司 | 一种多系统权限管理方法、装置、设备以及存储介质 |
CN113411349A (zh) * | 2021-07-22 | 2021-09-17 | 用友汽车信息科技(上海)股份有限公司 | 鉴权认证方法、鉴权认证系统、计算机设备和存储介质 |
CN113691534A (zh) * | 2021-08-24 | 2021-11-23 | 厦门熵基科技有限公司 | 一种身份认证计费系统和方法 |
CN114157503A (zh) * | 2021-12-08 | 2022-03-08 | 北京天融信网络安全技术有限公司 | 访问请求的认证方法及装置、api网关设备、存储介质 |
CN114866982A (zh) * | 2021-02-04 | 2022-08-05 | 广州汽车集团股份有限公司 | 一种车端ecu访问公网进行数据交互的方法及系统 |
CN114978749A (zh) * | 2022-06-14 | 2022-08-30 | 中国电信股份有限公司 | 登录认证方法及系统、存储介质和电子设备 |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20120087331A (ko) * | 2010-12-08 | 2012-08-07 | (주)성훈정보통신 | 소셜머니 기반 소셜 품앗이 서비스 시스템 및 방법 |
CN105099676A (zh) * | 2014-04-18 | 2015-11-25 | 阿里巴巴集团控股有限公司 | 一种用户登录方法、用户终端及服务器 |
CN106776099A (zh) * | 2017-01-11 | 2017-05-31 | 北京皮尔布莱尼软件有限公司 | 一种服务熔断隔离系统和方法 |
CN107171828A (zh) * | 2017-04-18 | 2017-09-15 | 北京思特奇信息技术股份有限公司 | 一种应对远程调用依赖的超时熔断方法和系统 |
CN108701201A (zh) * | 2018-04-08 | 2018-10-23 | 深圳大学 | 一种移动终端的访问控制方法、装置、终端及存储介质 |
CN109274547A (zh) * | 2018-08-17 | 2019-01-25 | 中国平安人寿保险股份有限公司 | 基于网络安全的服务熔断方法、装置、设备及存储介质 |
CN109766210A (zh) * | 2019-01-17 | 2019-05-17 | 多点生活(成都)科技有限公司 | 服务熔断控制方法、服务熔断控制装置和服务器集群 |
CN110311899A (zh) * | 2019-06-17 | 2019-10-08 | 平安医疗健康管理股份有限公司 | 多业务系统访问方法、装置及服务器 |
-
2019
- 2019-11-27 CN CN201911184319.3A patent/CN110941844B/zh active Active
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20120087331A (ko) * | 2010-12-08 | 2012-08-07 | (주)성훈정보통신 | 소셜머니 기반 소셜 품앗이 서비스 시스템 및 방법 |
CN105099676A (zh) * | 2014-04-18 | 2015-11-25 | 阿里巴巴集团控股有限公司 | 一种用户登录方法、用户终端及服务器 |
CN106776099A (zh) * | 2017-01-11 | 2017-05-31 | 北京皮尔布莱尼软件有限公司 | 一种服务熔断隔离系统和方法 |
CN107171828A (zh) * | 2017-04-18 | 2017-09-15 | 北京思特奇信息技术股份有限公司 | 一种应对远程调用依赖的超时熔断方法和系统 |
CN108701201A (zh) * | 2018-04-08 | 2018-10-23 | 深圳大学 | 一种移动终端的访问控制方法、装置、终端及存储介质 |
CN109274547A (zh) * | 2018-08-17 | 2019-01-25 | 中国平安人寿保险股份有限公司 | 基于网络安全的服务熔断方法、装置、设备及存储介质 |
CN109766210A (zh) * | 2019-01-17 | 2019-05-17 | 多点生活(成都)科技有限公司 | 服务熔断控制方法、服务熔断控制装置和服务器集群 |
CN110311899A (zh) * | 2019-06-17 | 2019-10-08 | 平安医疗健康管理股份有限公司 | 多业务系统访问方法、装置及服务器 |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111476640A (zh) * | 2020-04-13 | 2020-07-31 | 江苏思特瑞信息技术有限公司 | 认证方法、系统、存储介质及大数据认证平台 |
CN111476640B (zh) * | 2020-04-13 | 2023-08-04 | 江苏思特瑞信息技术有限公司 | 认证方法、系统、存储介质及大数据认证平台 |
CN111985902A (zh) * | 2020-08-25 | 2020-11-24 | 上海帜讯云计算科技有限公司 | 跨系统信息协同管理方法、装置、设备和存储介质 |
CN112328996A (zh) * | 2020-11-25 | 2021-02-05 | 杭州和利时自动化有限公司 | 基于dcs系统的操作认证方法、装置、设备及存储介质 |
CN112804242A (zh) * | 2021-01-25 | 2021-05-14 | 蔡世泳 | 一种无感知自动发现的api安全管理系统及方法 |
CN114866982A (zh) * | 2021-02-04 | 2022-08-05 | 广州汽车集团股份有限公司 | 一种车端ecu访问公网进行数据交互的方法及系统 |
CN112818328A (zh) * | 2021-02-26 | 2021-05-18 | 重庆度小满优扬科技有限公司 | 一种多系统权限管理方法、装置、设备以及存储介质 |
CN113411349A (zh) * | 2021-07-22 | 2021-09-17 | 用友汽车信息科技(上海)股份有限公司 | 鉴权认证方法、鉴权认证系统、计算机设备和存储介质 |
CN113691534A (zh) * | 2021-08-24 | 2021-11-23 | 厦门熵基科技有限公司 | 一种身份认证计费系统和方法 |
CN113691534B (zh) * | 2021-08-24 | 2023-02-17 | 厦门熵基科技有限公司 | 一种身份认证计费系统和方法 |
CN114157503A (zh) * | 2021-12-08 | 2022-03-08 | 北京天融信网络安全技术有限公司 | 访问请求的认证方法及装置、api网关设备、存储介质 |
CN114978749A (zh) * | 2022-06-14 | 2022-08-30 | 中国电信股份有限公司 | 登录认证方法及系统、存储介质和电子设备 |
CN114978749B (zh) * | 2022-06-14 | 2023-10-10 | 中国电信股份有限公司 | 登录认证方法及系统、存储介质和电子设备 |
Also Published As
Publication number | Publication date |
---|---|
CN110941844B (zh) | 2022-04-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110941844B (zh) | 一种认证鉴权方法、系统、电子设备及可读存储介质 | |
US8819803B1 (en) | Validating association of client devices with authenticated clients | |
CN110213215B (zh) | 一种资源访问方法、装置、终端和存储介质 | |
US9166966B2 (en) | Apparatus and method for handling transaction tokens | |
US8713672B2 (en) | Method and apparatus for token-based context caching | |
US8572686B2 (en) | Method and apparatus for object transaction session validation | |
US8752124B2 (en) | Apparatus and method for performing real-time authentication using subject token combinations | |
US9521032B1 (en) | Server for authentication, authorization, and accounting | |
US8806602B2 (en) | Apparatus and method for performing end-to-end encryption | |
CN110851274A (zh) | 资源访问控制方法、装置、设备及存储介质 | |
US8572690B2 (en) | Apparatus and method for performing session validation to access confidential resources | |
US8726361B2 (en) | Method and apparatus for token-based attribute abstraction | |
US8752157B2 (en) | Method and apparatus for third party session validation | |
US9361443B2 (en) | Method and apparatus for token-based combining of authentication methods | |
CN114444134A (zh) | 一种数据使用授权方法、系统及装置 | |
WO2021146164A1 (en) | Wireless lan (wlan) public identity federation trust architecture | |
US8572724B2 (en) | Method and apparatus for network session validation | |
CN114157438A (zh) | 网络设备管理方法、装置及计算机可读存储介质 | |
CN109639695A (zh) | 基于互信架构的动态身份认证方法、电子设备及存储介质 | |
US8572688B2 (en) | Method and apparatus for session validation to access third party resources | |
US8584201B2 (en) | Method and apparatus for session validation to access from uncontrolled devices | |
US9159065B2 (en) | Method and apparatus for object security session validation | |
RU2589333C2 (ru) | Ограничиваемая удаленной частью модель делегирования | |
KR101160903B1 (ko) | 네트워크 식별자 분류 시스템 및 그 방법 | |
US8726340B2 (en) | Apparatus and method for expert decisioning |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |