CN111917767A - 一种客户端的请求认证方法、装置、设备及存储介质 - Google Patents

一种客户端的请求认证方法、装置、设备及存储介质 Download PDF

Info

Publication number
CN111917767A
CN111917767A CN202010746859.2A CN202010746859A CN111917767A CN 111917767 A CN111917767 A CN 111917767A CN 202010746859 A CN202010746859 A CN 202010746859A CN 111917767 A CN111917767 A CN 111917767A
Authority
CN
China
Prior art keywords
target
request
client
authentication
cookie
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
Application number
CN202010746859.2A
Other languages
English (en)
Other versions
CN111917767B (zh
Inventor
张庆伟
侯满
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Suzhou Inspur Intelligent Technology Co Ltd
Original Assignee
Suzhou Inspur Intelligent Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Suzhou Inspur Intelligent Technology Co Ltd filed Critical Suzhou Inspur Intelligent Technology Co Ltd
Priority to CN202010746859.2A priority Critical patent/CN111917767B/zh
Publication of CN111917767A publication Critical patent/CN111917767A/zh
Application granted granted Critical
Publication of CN111917767B publication Critical patent/CN111917767B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/563Data redirection of data network streams

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本申请公开了一种客户端的请求认证方法、装置、设备及介质,方法包括:当接收到客户端发送的目标处理请求时,判断目标处理请求中是否携带Authentication请求头;若携带,则进一步判断目标处理请求中是否携带预先在请求认证通过时发送给客户端的目标Cookie;若是,则在判断出目标Cookie有效的情况下处理目标处理请求;若否或目标Cookie无效,则在判断出Authentication请求头中的Token有效的情况下处理目标处理请求,并生成目标Cookie;若未携带,则向客户端反馈401重定向信息,并等待接收客户端发送的处理请求。本方法能够提高对客户端的请求认证的处理效率。

Description

一种客户端的请求认证方法、装置、设备及存储介质
技术领域
本发明涉及请求认证领域,特别涉及一种客户端的请求认证方法、装置、设备及计算机可读存储介质。
背景技术
图1为现有技术中一种基于Kerberos的请求认证流程的示意图。在现有技术中,客户端(Client)通过与KDC(Key Distribution Center,Kerberos认证服务器)交互,获得服务访问票据ST(Service Ticket),并且根据ST生成Token(客户端基于ST生成的交互认证票据),向服务端发送处理请求时携带Token,服务端在验证Token有效的情况下,对处理请求进行响应。但是,现有技术的方法中,由于Token不可重用,服务端对客户端发送的处理请求都会进行401重定向(子过程1),相当于客户端发送的每个处理请求都要经过两次发送才能够得到服务端响应;其次,每次客户端都需要根据ST重新协商加密算法、再次生成加密字符串Token(子过程2),然后将Token发送到服务端去认证,服务端接收到Token之后还要经过复杂的解密过程鉴定Token的有效性(子过程3)。这样一来,虽然保证了每次交互都是足够安全,但服务端对客户端的请求认证过程的耗时长,对客户端的请求认证的效率低下。
因此,如何提高对客户端的请求认证的处理效率,是本领域技术人员目前需要解决的技术问题。
发明内容
有鉴于此,本发明的目的在于提供一种客户端的请求认证方法,能够提高对客户端的请求认证的处理效率;本发明的另一目的是提供一种客户端的请求认证装置、设备及计算机可读存储介质,均具有上述有益效果。
为解决上述技术问题,本发明提供一种客户端的请求认证方法,包括:
当接收到客户端发送的目标处理请求时,判断所述目标处理请求中是否携带Authentication请求头;
若携带,则进一步判断所述目标处理请求中是否携带预先在请求认证通过时发送给所述客户端的目标Cookie;
若是,则在判断出所述目标Cookie有效的情况下处理所述目标处理请求;
若否或所述目标Cookie无效,则在判断出所述Authentication请求头中的Token有效的情况下处理所述目标处理请求,并生成所述目标Cookie;
若未携带,则向所述客户端反馈401重定向信息,并等待接收所述客户端发送的处理请求。
优选地,所述在判断出所述目标Cookie有效的情况下处理所述目标处理请求的过程,具体包括:
判断所述目标Cookie的格式是否正确;
若正确,则判断所述目标Cookie的时间是否在有效期内;
若是,则表示所述目标Cookie有效,处理所述目标处理请求;
否则,则表示所述目标Cookie无效。
优选地,所述在判断出所述Authentication请求头中的Token有效的情况下处理所述目标处理请求,并生成所述目标Cookie的过程,具体包括:
在判断出所述Authentication请求头中的所述Token有效的情况下处理所述目标处理请求,并生成与所述目标处理请求对应类型的所述目标Cookie。
优选地,若判断出所述Authentication请求头中的所述Token无效,进一步包括:
收集请求认证失败的原因,并将所述原因反馈给所述客户端。
优选地,进一步包括:
所述客户端通过Redis和/或Memcached和/或Zookeeper保存所述目标Cookie。
优选地,判断所述Authentication请求头中的所述Token是否有效过程,具体包括:
解析所述Token,并判断解析后的所述Token是否为有效地经过加密的KerberosTicket。
优选地,进一步包括:
记录所述目标处理请求以及发送所述目标处理请求的所述客户端的信息。
为解决上述技术问题,本发明还提供一种客户端的请求认证装置,包括:
第一判断模块,用于当接收到客户端发送的目标处理请求时,判断所述目标处理请求中是否携带Authentication请求头;若携带,则调用第二判断模块;若未携带,则调用第一执行模块;
所述第二判断模块,用于判断所述目标处理请求中是否携带预先在请求认证通过时发送给所述客户端的目标Cookie;若是,则调用第二执行模块;若否或所述目标Cookie无效,则调用第三执行模块;
所述第二执行模块,用于在判断出所述目标Cookie有效的情况下处理所述目标处理请求;
所述第三执行模块,用于在判断出所述Authentication请求头中的Token有效的情况下处理所述目标处理请求,并生成所述目标Cookie;
所述第一执行模块,用于向所述客户端反馈401重定向信息,并等待接收所述客户端发送的处理请求。
为解决上述技术问题,本发明还提供一种客户端的请求认证设备,包括:
存储器,用于存储计算机程序;
处理器,用于执行所述计算机程序时实现上述任一种客户端的请求认证方法的步骤。
为解决上述技术问题,本发明还提供一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现上述任一种客户端的请求认证方法的步骤。
本发明提供的一种客户端的请求认证方法,包括:当接收到客户端发送的目标处理请求时,判断目标处理请求中是否携带Authentication请求头;若携带,则进一步判断目标处理请求中是否携带预先在请求认证通过时发送给客户端的目标Cookie;若是,则在判断出目标Cookie有效的情况下处理目标处理请求,并生成目标Cookie;若否或目标Cookie无效,则在判断出Authentication请求头中的Token有效的情况下处理目标处理请求;若未携带,则向客户端反馈401重定向信息,并等待接收客户端发送的处理请求。可见,客户端利用预先接收到的服务端在请求认证通过时反馈的目标Cookie设置目标处理请求,以利用目标Cookie进行请求认证,当不存在目标Cookie或者目标Cookie无效的情况下,才利用Authentication请求头进行请求认证,在Authentication请求头中的Token无效的情况下才需要客户端进行401重定向;因此避免了现有技术中在每次进行请求认证时均需要进行401重定向、计算Token以及验证Token的操作,减少信息交互次数、避免大量的计算过程,从而能够缩短对客户端的请求认证的校验时间,提高对客户端的请求认证的处理效率。
为解决上述技术问题,本发明还提供了一种客户端的请求认证装置、设备及计算机可读存储介质,均具有上述有益效果。
附图说明
为了更清楚地说明本发明实施例或现有技术的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据提供的附图获得其他的附图。
图1为现有技术中一种基于Kerberos的请求认证流程的示意图;
图2为本发明实施例提供的一种客户端的请求认证方法的流程图;
图3为本发明实施例提供的另一种客户端的请求认证方法的流程图;
图4为本发明实施例提供的一种客户端的请求认证装置的结构图;
图5为本发明实施例提供的一种客户端的请求认证设备的结构图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
本发明实施例的核心是提供一种客户端的请求认证方法,能够提高对客户端的请求认证的处理效率;本发明的另一核心是提供一种客户端的请求认证装置、设备及计算机可读存储介质,均具有上述有益效果。
为了使本领域技术人员更好地理解本发明方案,下面结合附图和具体实施方式对本发明作进一步的详细说明。
图2为本发明实施例提供的一种客户端的请求认证方法的流程图。如图2所示,一种客户端的请求认证方法包括:
S10:当接收到客户端发送的目标处理请求时,判断目标处理请求中是否携带Authentication请求头;
S20:若携带,则进一步判断目标处理请求中是否携带预先在请求认证通过时发送给客户端的目标Cookie;
S30:若是,则在判断出目标Cookie有效的情况下处理目标处理请求;
S40:若否或目标Cookie无效,则在判断出Authentication请求头中的Token有效的情况下处理目标处理请求,并生成目标Cookie;
S50:若未携带,则向客户端反馈401重定向信息,并等待接收客户端发送的处理请求。
可以理解的是,当客户端存在处理需求时,需要向服务端发送处理请求,以便服务端通过响应处理请求来实现客户端的处理需求。在本实施例中,对客户端以及服务端的具体类型均不做限定,例如,服务端可以是ES(Elasticsearch)服务端,即一种基于Lucene的开源的分布式全文检索搜索引擎的服务器。并且在实际操作中,客户端可以是向多个服务端发送处理请求进行请求认证,即通过服务集群对客户端进行请求认证,本实施例对此也不做限定。
具体的,对于服务端而言,当接收到客户端发送的目标处理请求时,首先判断目标处理请求中是否携带Authentication请求头。需要说明的是,基于Kerberos安全认证是以Authentication请求头为判断依据的,只有目标处理请求中携带Authentication请求头才会被服务端认为,本次对客户端的目标处理请求的认证应该走Kerberos安全认证逻辑,而不是其他安全认证逻辑。
在确定出目标处理请求中携带Authentication请求头之后,进一步判断目标处理请求中是否携带预先在请求认证通过时发送给客户端的目标Cookie。
需要说明的是,Cookie指的是某些服务为鉴别客户端的用户身份,进行权限跟踪而存储在用户客户端本地的数据(通常经过加密),由用户客户端计算机暂时或永久保存的信息。在本实施例中,Cookie的内容包含:认证成功的principal信息,timestamp信息以及Kerberos type信息。
若目标处理请求中携带预先在请求认证通过时发送给客户端的目标Cookie,则可以直接对目标Cookie进行有效性判断,并在判断出目标Cookie有效的情况下,处理目标处理请求,并将处理结果反馈给客户端。
若目标处理请求中未携带预先在请求认证通过时发送给客户端的目标Cookie,或者判断出目标Cookie无效,即表示客户端是首次向服务端发送目标处理请求进行请求认证或者客户端之前的请求认证未通过或客户端之前的请求认证得到的目标Cookie的时间超过有效期,则需要进一步判断目标处理请求中的Authentication请求头中的Token是否有效,并在Token有效的情况下处理目标处理请求,并生成目标Cookie,然后将生成的目标Cookie以及处理结果一起反馈给客户端。
若目标处理请求中未携带Authentication请求头,则首先向客户端反馈401重定向信息,并等待接收客户端发送的处理请求;此时客户端通过与KDC(Key DistributionCenter,Kerberos认证服务器)交互,获得服务访问票据ST(Service Ticket),并且根据服务访问票据ST生成Token(Client基于ST生成的交互认证票据),然后在目标处理请求中携带Token,并再次向服务端发送目标处理请求。对应的,服务端在再次接收到客户端发送的目标处理请求后,再次对携带有Token的目标处理请求进行认证,认证通过则处理目标处理请求,并生成Cookie,将生成的目标Cookie以及处理结果一起反馈给客户端。
本发明实施例提供的一种客户端的请求认证方法,包括:当接收到客户端发送的目标处理请求时,判断目标处理请求中是否携带Authentication请求头;若携带,则进一步判断目标处理请求中是否携带预先在请求认证通过时发送给客户端的目标Cookie;若是,则在判断出目标Cookie有效的情况下处理目标处理请求,并生成目标Cookie;若否或目标Cookie无效,则在判断出Authentication请求头中的Token有效的情况下处理目标处理请求;若未携带,则向客户端反馈401重定向信息,并等待接收客户端发送的处理请求。可见,客户端利用预先接收到的服务端在请求认证通过时反馈的目标Cookie设置目标处理请求,以利用目标Cookie进行请求认证,当不存在目标Cookie或者目标Cookie无效的情况下,才利用Authentication请求头进行请求认证,或在Authentication请求头中的Token无效的情况下才需要客户端进行401重定向;因此避免了现有技术中在每次进行请求认证时均需要进行401重定向、计算Token以及验证Token的操作,减少信息交互次数、避免大量的计算过程,从而能够缩短对客户端的请求认证的校验时间,提高对客户端的请求认证的处理效率。
在上述实施例的基础上,本实施例对技术方案作了进一步的说明和优化,具体的,本实施例中,在判断出目标Cookie有效的情况下处理目标处理请求的过程,具体包括:
判断目标Cookie的格式是否正确;
若正确,则判断目标Cookie的时间是否在有效期内;
若是,则表示目标Cookie有效,处理目标处理请求;
否则,则表示目标Cookie无效。
在本实施例中,在判断目标Cookie是否有效的过程中,首先判断目标Cookie的格式是否正确;具体的,预先设置Cookie的标准格式,然后获取目标Cookie的格式,将该格式与标准格式进行比较,以确定目标Cookie的格式是否正确。
在判断出目标Cookie的格式正确后,判断目标Cookie的时间是否在有效期内;具体的,获取目标Cookie的有效期,然后将目标Cookie的时间与有效期进行比较,以确定目标Cookie是否在有效期内。本实施例对目标Cookie的有效期不做限定,目标Cookie的有效期越短,越可以防止攻击者窃取和利用该目标Cookie,相对保障认证的安全性,具体的,有效期可以是20分钟,在20分钟之后,目标Cookie失效,需要重新获取目标Cookie。在目标Cookie的格式正确且在有效期内的情况下,表示目标Cookie有效,因此可以对目标处理请求进行响应,处理目标处理请求;否则,则表示目标Cookie无效。
可见,本实施例通过对目标Cookie的格式和有效期进行判断以确定目标Cookie的格式的有效性,操作过程便捷。
在上述实施例的基础上,本实施例对技术方案作了进一步的说明和优化,具体的,本实施例中,在判断出Authentication请求头中的Token有效的情况下处理目标处理请求,并生成目标Cookie的过程,具体包括:
在判断出Authentication请求头中的Token有效的情况下处理目标处理请求,并生成与目标处理请求对应类型的目标Cookie。
具体的,在实际操作中,可以根据实际需求设置多种Cookie规范,并设置不同类型的处理请求与不同类型的Cookie规范的对应关系。不同规范的Cookie对应的认证难度不同,即对应认证的精准度不同,Cookie越复杂,越能够保障对客户端进行请求认证的安全性。在服务器需要生成目标Cookie时,具体是根据目标处理请求的类型,确定出对应的Cookie规范,并生成与目标处理请求类型对应的目标Cookie。
可见,本实施例通过进一步设置多种类型的Cookie,并在判断出Authentication请求头中的Token有效的情况下处理目标处理请求,并生成与目标处理请求对应类型的目标Cookie,因此能够根据实际需求灵活针对不同的认证请求设置对应的目标Cookie,有效地利用资源。
在上述实施例的基础上,本实施例对技术方案作了进一步的说明和优化,具体的,本实施例中,若判断出Authentication请求头中的Token无效,进一步包括:
收集请求认证失败的原因,并将原因反馈给客户端。
具体的,在本实施例中,是在判断出Authentication请求头中的Token无效之后,即表示当前对客户端的目标处理请求认证失败时,进一步收集请求认证失败的原因,然后将收集到的请求认证失败的原因反馈给客户端。在其他的实施方式中,在判断出Authentication请求头中未携带Token时,也可以进一步收集请求认证失败的原因,本实施例对此不做限定。
需要说明的是,在实际操作中,可以通过采集客户端与服务端的交互信息的方式,获取与请求认证失败的原因相关的信息,也可以是通过采集服务端在进行请求认证时的相关信息,获取与请求认证失败的原因相关的信息,本实施例对此不做限定。
可见,本实施例通过进一步收集请求认证失败的原因,并将原因反馈给客户端,能够便于后续分析认证失败的原因,以及时对客户端或者服务端的异常情况进行调整,从而进一步保障对请求认证的准确度。
作为优选的实施方式,在本实施例中,判断Authentication请求头中的Token是否有效过程,具体包括:
解析Token,并判断解析后的Token是否为有效地经过加密的Kerberos Ticket。
在实际操作中,在判断Authentication请求头中的Token是否有效时,首先需要对Authentication请求头中的Token进行解析,然后判断解析后的Token是否为有效地经过加密的Kerberos Ticket,具体包括判断Token是否合法、token的格式是否正确以及校验过程是否出现异常等,本实施例对具体的校验判断过程不做限定。
可见,按照本实施例的方法,能够便捷快速地确定出Authentication请求头中的Token是否有效。
在上述实施例的基础上,本实施例对技术方案作了进一步的说明和优化,具体的,本实施例中,客户端通过Redis和/或Memcached和/或Zookeeper保存目标Cookie。
具体的,在本实施例中,客户端在接收到服务器反馈的目标Cookie之后,可以进一步通过Redis和/或Memcached和/或Zookeeper保存目标Cookie;因此当客户端重启时,可以直接从Redis和/或Memcached和/或Zookeeper中获取预先保存的目标Cookie,并利用该目标Cookie设置对应的目标处理请求。对应的,在目标Cookie有效的情况下,则可以认证通过。
可见,本实施例的方法,能进一步使得客户端在重启的情况下更便捷地获取目标Cookie,进一步提升操作便捷度。
在上述实施例的基础上,本实施例对技术方案作了进一步的说明和优化,具体的,本实施例进一步包括:
记录目标处理请求以及发送目标处理请求的客户端的信息。
具体的,在本实施例中,是进一步获取客户端发送的目标处理请求以及发送目标处理请求的客户端的信息,并将目标处理请求以及对应的客户端的信息进行记录。具体可以将目标处理请求以及对应的客户端的信息记录至审计日志中,一般与后续根据记录的信息查看服务端接收到的认证请求的情况,例如哪些客户端对服务器进行访问,具体的访问操作类型等,从而进一步提升用户的使用体验。
如图3所示,本实施例提供了另一种客户端的请求认证方法的流程图。具体的,当客户端存在处理需求时,首先判断是否收到了服务端根据之前的处理请求反馈的Set-Cookie Response头,如果收到了Set-Cookie Response头,并且该Set-Cookie Response头的内容不为空,即接收到目标Cookie,则初始化Cookie请求头;如果目标Cookie过期或ST即将过期,设置Cookie请求头头的内容为null;在Set-Cookie Response头的内容不为null的情况下,则将该目标Cookie设置到Cookie请求头中,向服务端发送处理请求Request。
在客户端向服务端发送目标处理请求Request之后,请求认证的具体过程如下:
P1:服务端在接收到客户端发送的目标处理请求Request之后,首先判断目标处理请求Request是否携带Authentication请求头;若携带,则跳转至P2,若未携带,则跳转至P8;
P2:若携带Authentication请求头,则判断处理请求Request中是否携带Cookie请求头;若携带,则跳转至P3,否则跳转至P5;
P3:服务端解析并判断Cookie请求头中的目标Cookie的有效性,具体包括解析目标Cookie并判断目标Cookie的格式是否正确,以及目标Cookie的时间是否在有效期内;如果判断目标Cookie有效则跳转至P4,否则跳转至P5;
P4:响应目标处理请求Request,并将得出的处理结果返回给客户端;
P5:服务端解析Authentication请求头中的Token并判断Token是否有效,具体包括解析Token,并判断解析后的Token是否为有效地经过加密的Kerberos Ticket;如果是则跳转至P6,否则跳转至P7;
P6:若Token有效,则响应目标处理请求Request,并生成Set-Cookie Response,并将该Set-Cookie Response连同处理结果一起返回给客户端;
其中,Set-Cookie Response可以为:<Set-Cookie:insightos.es.auth user=elastic@BIGDATA.COM&type=kerberos&expire=1589277923444;
P7:若Token无效,则收集认证失败的原因,并将原因反馈给客户端;
P8:若未携带Authentication请求头,则表示该目标处理请求Request属于未认证请求,因此向客户端发送401重定向信息,要求客户端提供Authentication请求头;
P9:客户端接收到401重定向信息之后,通过与KDC交互,获得服务访问票据ST,并且根据ST生成Token;
P10:客户端将Token设置为Authentication请求头的Content,并再次向服务端发送更新后的处理请求Request,并跳转至P1。
可见,通过本实施例的方式,能够提高对客户端的处理请求的认证效率。
并且,为了更为直观的描述优化结果,通过在远程虚拟机上搭建了一个3节点的ES服务集群,ES服务集群中的所有参数未经优化,虚拟机网卡为千兆网卡,OS系统为CentOS7.4。通过实际测试,得到的测试数据如下表1所示:
表1不同的请求认证方式对应的测试数据
模式 同步API 异步API Request压测次数 平均响应速度(每秒)
普通模式 100000 1928
普通模式 100000 8536
BasicAuth 100000 947
BasicAuth 100000 7558
Kerberos 100000 310
Kerberos 100000 1492
Kerberos+Cookie 100000 1027
Kerberos+Cookie 100000 8176
通过对比表1中数据可以得出:
1)RestClient在使用异步API时的性能远高于同步API;
2)纯Kerberos认证模式下异步API的平均响应速度只有相同条件下BasicAuth认证平均响应速度的23%,普通模式的17%;
3)在Kerberos+Cookie优化模式下的平均响应速度甚至超过了同条件下的BasicAuth模式的平均响应速度。
上文对于本发明提供的一种客户端的请求认证方法的实施例进行了详细的描述,本发明还提供了一种与该方法对应的客户端的请求认证装置、设备及计算机可读存储介质,由于装置、设备及计算机可读存储介质部分的实施例与方法部分的实施例相互照应,因此装置、设备及计算机可读存储介质部分的实施例请参见方法部分的实施例的描述,这里暂不赘述。
图4为本发明实施例提供的一种客户端的请求认证装置的结构图,如图4所示,一种客户端的请求认证装置包括:
第一判断模块41,用于当接收到客户端发送的目标处理请求时,判断目标处理请求中是否携带Authentication请求头;若携带,则调用第二判断模块42;若未携带,则调用第一执行模块43;
第二判断模块42,用于判断目标处理请求中是否携带预先在请求认证通过时发送给客户端的目标Cookie;若是,则调用第二执行模块44;若否或目标Cookie无效,则调用第三执行模块45;
第二执行模块44,用于在判断出目标Cookie有效的情况下处理目标处理请求;
第三执行模块45,用于在判断出Authentication请求头中的Token有效的情况下处理目标处理请求,并生成目标Cookie;
第一执行模块43,用于向客户端反馈401重定向信息,并等待接收客户端发送的处理请求。
本发明实施例提供的客户端的请求认证装置,具有上述客户端的请求认证方法的有益效果。
作为优选的实施方式,一种客户端的请求认证装置进一步包括:
收集模块,用于收集请求认证失败的原因,并将原因反馈给客户端。
作为优选的实施方式,一种客户端的请求认证装置进一步包括:
记录模块,用于记录目标处理请求以及发送目标处理请求的客户端的信息。
图5为本发明实施例提供的一种客户端的请求认证设备的结构图,如图5所示,一种客户端的请求认证设备包括:
存储器51,用于存储计算机程序;
处理器52,用于执行计算机程序时实现如上述客户端的请求认证方法的步骤。
本发明实施例提供的客户端的请求认证设备,具有上述客户端的请求认证方法的有益效果。
为解决上述技术问题,本发明还提供一种计算机可读存储介质,计算机可读存储介质上存储有计算机程序,计算机程序被处理器执行时实现如上述客户端的请求认证方法的步骤。
本发明实施例提供的计算机可读存储介质,具有上述客户端的请求认证方法的有益效果。
以上对本发明所提供的客户端的请求认证方法、装置、设备及计算机可读存储介质进行了详细介绍。本文中应用了具体实施例对本发明的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本发明的方法及其核心思想。应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以对本发明进行若干改进和修饰,这些改进和修饰也落入本发明权利要求的保护范围内。
说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言,由于其与实施例公开的方法相对应,所以描述的比较简单,相关之处参见方法部分说明即可。
专业人员还可以进一步意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。

Claims (10)

1.一种客户端的请求认证方法,其特征在于,包括:
当接收到客户端发送的目标处理请求时,判断所述目标处理请求中是否携带Authentication请求头;
若携带,则进一步判断所述目标处理请求中是否携带预先在请求认证通过时发送给所述客户端的目标Cookie;
若是,则在判断出所述目标Cookie有效的情况下处理所述目标处理请求;
若否或所述目标Cookie无效,则在判断出所述Authentication请求头中的Token有效的情况下处理所述目标处理请求,并生成所述目标Cookie;
若未携带,则向所述客户端反馈401重定向信息,并等待接收所述客户端发送的处理请求。
2.根据权利要求1所述的方法,其特征在于,所述在判断出所述目标Cookie有效的情况下处理所述目标处理请求的过程,具体包括:
判断所述目标Cookie的格式是否正确;
若正确,则判断所述目标Cookie的时间是否在有效期内;
若是,则表示所述目标Cookie有效,处理所述目标处理请求;
否则,则表示所述目标Cookie无效。
3.根据权利要求1所述的方法,其特征在于,所述在判断出所述Authentication请求头中的Token有效的情况下处理所述目标处理请求,并生成所述目标Cookie的过程,具体包括:
在判断出所述Authentication请求头中的所述Token有效的情况下处理所述目标处理请求,并生成与所述目标处理请求对应类型的所述目标Cookie。
4.根据权利要求1所述的方法,其特征在于,若判断出所述Authentication请求头中的所述Token无效,进一步包括:
收集请求认证失败的原因,并将所述原因反馈给所述客户端。
5.根据权利要求1所述的方法,其特征在于,进一步包括:
所述客户端通过Redis和/或Memcached和/或Zookeeper保存所述目标Cookie。
6.根据权利要求1所述的方法,其特征在于,判断所述Authentication请求头中的所述Token是否有效过程,具体包括:
解析所述Token,并判断解析后的所述Token是否为有效地经过加密的KerberosTicket。
7.根据权利要求1至6任一项所述的方法,其特征在于,进一步包括:
记录所述目标处理请求以及发送所述目标处理请求的所述客户端的信息。
8.一种客户端的请求认证装置,其特征在于,包括:
第一判断模块,用于当接收到客户端发送的目标处理请求时,判断所述目标处理请求中是否携带Authentication请求头;若携带,则调用第二判断模块;若未携带,则调用第一执行模块;
所述第二判断模块,用于判断所述目标处理请求中是否携带预先在请求认证通过时发送给所述客户端的目标Cookie;若是,则调用第二执行模块;若否或所述目标Cookie无效,则调用第三执行模块;
所述第二执行模块,用于在判断出所述目标Cookie有效的情况下处理所述目标处理请求;
所述第三执行模块,用于在判断出所述Authentication请求头中的Token有效的情况下处理所述目标处理请求,并生成所述目标Cookie;
所述第一执行模块,用于向所述客户端反馈401重定向信息,并等待接收所述客户端发送的处理请求。
9.一种客户端的请求认证设备,其特征在于,包括:
存储器,用于存储计算机程序;
处理器,用于执行所述计算机程序时实现如权利要求1至7任一项所述的客户端的请求认证方法的步骤。
10.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的客户端的请求认证方法的步骤。
CN202010746859.2A 2020-07-29 2020-07-29 一种客户端的请求认证方法、装置、设备及存储介质 Active CN111917767B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010746859.2A CN111917767B (zh) 2020-07-29 2020-07-29 一种客户端的请求认证方法、装置、设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010746859.2A CN111917767B (zh) 2020-07-29 2020-07-29 一种客户端的请求认证方法、装置、设备及存储介质

Publications (2)

Publication Number Publication Date
CN111917767A true CN111917767A (zh) 2020-11-10
CN111917767B CN111917767B (zh) 2022-06-07

Family

ID=73286709

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010746859.2A Active CN111917767B (zh) 2020-07-29 2020-07-29 一种客户端的请求认证方法、装置、设备及存储介质

Country Status (1)

Country Link
CN (1) CN111917767B (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112836204A (zh) * 2021-02-03 2021-05-25 中国人民财产保险股份有限公司 一种令牌更新方法和装置

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101047504A (zh) * 2006-03-29 2007-10-03 腾讯科技(深圳)有限公司 一种网站登录认证方法及认证系统
CN103179134A (zh) * 2013-04-19 2013-06-26 中国建设银行股份有限公司 基于Cookie的单点登录方法、系统及其应用服务器
CN104811488A (zh) * 2015-04-13 2015-07-29 深信服网络科技(深圳)有限公司 基于负载均衡设备的会话保持方法及系统和负载均衡设备
EP3005764A1 (en) * 2013-06-05 2016-04-13 Citrix Systems Inc. Systems and methods for enabling an application management service to remotely access enterprise application store
CN107579991A (zh) * 2017-09-28 2018-01-12 北京奇安信科技有限公司 一种对客户端进行云端防护认证的方法、服务器和客户端
CN110232265A (zh) * 2019-06-21 2019-09-13 杭州安恒信息技术股份有限公司 双重身份认证方法、装置及系统
CN110995702A (zh) * 2019-12-02 2020-04-10 杭州安恒信息技术股份有限公司 一种基于分布式微服务的用户认证方法

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101047504A (zh) * 2006-03-29 2007-10-03 腾讯科技(深圳)有限公司 一种网站登录认证方法及认证系统
CN103179134A (zh) * 2013-04-19 2013-06-26 中国建设银行股份有限公司 基于Cookie的单点登录方法、系统及其应用服务器
EP3005764A1 (en) * 2013-06-05 2016-04-13 Citrix Systems Inc. Systems and methods for enabling an application management service to remotely access enterprise application store
CN104811488A (zh) * 2015-04-13 2015-07-29 深信服网络科技(深圳)有限公司 基于负载均衡设备的会话保持方法及系统和负载均衡设备
CN107579991A (zh) * 2017-09-28 2018-01-12 北京奇安信科技有限公司 一种对客户端进行云端防护认证的方法、服务器和客户端
CN110232265A (zh) * 2019-06-21 2019-09-13 杭州安恒信息技术股份有限公司 双重身份认证方法、装置及系统
CN110995702A (zh) * 2019-12-02 2020-04-10 杭州安恒信息技术股份有限公司 一种基于分布式微服务的用户认证方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112836204A (zh) * 2021-02-03 2021-05-25 中国人民财产保险股份有限公司 一种令牌更新方法和装置

Also Published As

Publication number Publication date
CN111917767B (zh) 2022-06-07

Similar Documents

Publication Publication Date Title
CN111556006B (zh) 第三方应用系统登录方法、装置、终端及sso服务平台
CN112218294B (zh) 基于5g的物联网设备的接入方法、系统及存储介质
CN106101258B (zh) 一种混合云的接口调用方法、装置及系统
CN108306877B (zh) 基于node js的用户身份信息的验证方法、装置和存储介质
CN107196950B (zh) 校验方法、装置及服务端
WO2018036314A1 (zh) 一种单点登录认证方法及装置、存储介质
CN101605108B (zh) 一种即时通信的方法、系统及装置
US8638941B2 (en) Distributing keypairs between network appliances, servers, and other network assets
US10621651B2 (en) Automatic recharge system and method, and server
EP3319267A1 (en) Wireless system access control method and device
CN106375270A (zh) 令牌生成并认证的方法及认证服务器
CN110912689A (zh) 一种唯一值的生成、验证方法及系统
CN113992408B (zh) 多系统统一登录信息处理方法及系统
US9832198B2 (en) Service-based message access layer frame and implementation method thereof
CN111241523B (zh) 认证处理方法、装置、设备和存储介质
CN114338212A (zh) 身份验证令牌管理方法、装置、电子设备及可读存储介质
CN113676452A (zh) 基于一次性密钥的重放攻击抵御方法及系统
CN113225351A (zh) 一种请求处理方法、装置、存储介质及电子设备
CN111181913B (zh) 一种信息验证方法及装置
CN111917767B (zh) 一种客户端的请求认证方法、装置、设备及存储介质
CN113505353B (zh) 一种认证方法、装置、设备和存储介质
JP6081857B2 (ja) 認証システムおよび認証方法
CN111371811A (zh) 一种资源调用方法、资源调用装置、客户端及业务服务器
CN108809927B (zh) 身份认证方法及装置
CN113691534B (zh) 一种身份认证计费系统和方法

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