CN101588390B - 提高集中认证服务系统业务黏性的方法及负载均衡设备 - Google Patents
提高集中认证服务系统业务黏性的方法及负载均衡设备 Download PDFInfo
- Publication number
- CN101588390B CN101588390B CN2009100878585A CN200910087858A CN101588390B CN 101588390 B CN101588390 B CN 101588390B CN 2009100878585 A CN2009100878585 A CN 2009100878585A CN 200910087858 A CN200910087858 A CN 200910087858A CN 101588390 B CN101588390 B CN 101588390B
- Authority
- CN
- China
- Prior art keywords
- server
- cas
- web
- client
- transmitting
- 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.)
- Active
Links
Images
Landscapes
- Computer And Data Communications (AREA)
- Information Transfer Between Computers (AREA)
Abstract
本发明提供了一种提高集中认证服务系统业务黏性的方法及负载均衡设备。本发明通过使能基于流量源地址的会话保持功能,并通过特殊的转发处理流程,使得LB统一转发表中一个Web服务器只与唯一一个CAS服务器相对应,进而保证了客户端在通过某一台CAS服务器的认证后,后续的Web服务器对该客户端的验证请求能够被转发到同一台CAS服务器,从而满足了CAS系统的业务黏性,使得用户认证能够正常进行。
Description
技术领域
本发明涉及集中认证服务系统(CAS,Central Authentication Service),具体涉及一种提高CAS业务黏性的方法及负载均衡(LB,Load Balance)设备。
背景技术
随着信息技术和网络技术在组织机构中的广泛应用,很多机构和单位已经拥有了各种各样的应用系统,如办公自动化系统、人力资源管理系统、财务系统、客户关系管理系统、企业资源计划(ERP,Enterprise Resource Planning)系统、政府网上审批系统、学校一卡通系统以及其它的业务应用系统。用户如果要想享受到这些应用系统带来的诸多好处,就需要登录到相应的应用系统中,而每个应用系统都要求用户遵循其独立的身份认证安全策略,比如要求输入用户身份标识(ID,identification)和对应的口令。
显然,过多的应用系统对于用户使用以及系统维护都是不利的。为了简化用户登录和提高信息系统整体的安全性,现有技术提出了单点登录(SSO,Single Sign-On)技术,即通过用户的一次性鉴别登录,可获得访问多个系统和应用软件的授权,使得用户可对所有被授权的各类信息资源进行无缝地访问。CAS是一种针对网站(Web)应用的单点登录机制。CAS是由耶鲁大学发起的一个开源项目,目前已经成为事实上的工业标准。下面简单介绍CAS系统的基本概念:
CAS服务器(CAS Server):主要负责完成对用户的认证工作;
Web应用程序服务器(Web Application Server):本发明中简称为Web服务器,用于在接收到用户对本地Web应用的受保护资源的访问请求时,将用户重定向到CAS服务器以进行身份认证,而Web服务器本身不执行用户名加密码等类似的认证;
Web浏览器(Web Browser):用户的Web浏览器,也可以称为CAS系统中的客户端。
图1示出了CAS的体系结构及工作流程,其中虚线表示安全超文本传输协议(HTTPS,Secure Hypertext Transfer Protocol)流量,实线表示超文本传输协议(HTTP,Hypertext Transfer Protocol)流量。如图1所示,CAS工作流程包括:
步骤1,Web浏览器向Web服务器发出HTTP访问请求,比如,访问以下网站http://www.h3c.com。
步骤2,Web服务器接收到上述访问请求后,向Web浏览器返回网址(HTTP)重定向响应,指示Web浏览器去往CAS服务器进行身份认证。
步骤3,Web浏览器根据重定向响应中的内容,通过HTTPS方式访问CAS服务器的Login URL,比如:https://secure.h3c.com/CAS/servlet/login。Login URL处理实际的主(primary)认证:提示用户输入NetID(简单地说就是用户名)及其密码,并进行验证。(根据具体部署而定,CAS可协同后端的认证业务服务程序一起进行验证,图1中未示出该部分)。
这里,Web浏览器在向CAS服务器访问Login URL的时候,将携带HTTP访问请求参数,用以指示自己希望访问的Web服务,比如步骤1中的http://www.h3c.com,该参数称为ServiceID,此时Web浏览器向CAS服务器发出的登录请求如下所示:
https://secure.h3c.com/CAS/login?service=http://www.h3c.com/authtication.jsp
步骤4,如果用户身份认证通过,CAS服务器将为Web浏览器生成一个长字符串,称为服务票据(Service Ticket或Ticket),并在自身内部数据库内创建一个Service Ticket和ServiceID关联:(Service Ticket、ServiceID);然后,重定向该Web浏览器到最初的Web服务器(根据ServiceID,CAS服务器知道应该将用户重定向到哪个URL,该ServiceID也被称为“callBack URL”)。
步骤5,Web浏览器根据重定向响应中的callBack URL,向对应的Web服务器重新发出访问请求,并携带所述Service Ticket作为请求参数,比如,
http://www.h3c.com/authenticate.jsp?ticket=opaque-ticket-string
步骤6,Web服务器接收到Web浏览器再次发出的访问请求后,通过HTTPS方式向CAS服务器的Validation URL发出验证请求,并在该验证请求中携带ServiceID参数(参数名为service)和Service Ticket参数(参数名为ticket),Validation URL可以是如下所示:
https://secure.h3c.com/CAS/serverlet/validat
步骤7,CAS服务器的Validation URL接收到验证请求后,将判断该验证请求中的Service Ticket是否存在于自身内部数据库:如果存在,并且该ServiceTicket关联的Web服务与Web服务器传递过来的ServiceID参数值一致,则返回验证成功的指示,该指示中包括有用户的NetID;否则,验证失败。
Web服务器收到CAS服务器发送的验证成功的指示后,就可开始向相应的用户提供相应的Web服务,至此,整个CAS认证流程结束。其中,CAS服务器上缓存了用户的ServiceID、Ticket、用户名(NetID)等信息,是整个CAS系统的核心。从流量拓扑上可以看出,整个CAS工作流量是三角形的,如图2所示,其中虚线表示HTTPS流量,实线表示HTTP流量。
随着网络的发展,出于系统性能和高可用性的考虑,CAS系统中已经开始采用虚服务器(VS,Virtual Server)的方式,对Web服务器和CAS服务器实现负载均衡处理。如图3所示,目前基于开放系统互连参考模型(OSI)传输层的负载均衡技术是基于传输层的端口号定义虚服务器。每个虚服务器对应一组真实服务器(服务器群),这些真实服务器用于提供相应的Web业务或Web服务。图3中,CAS虚服务器对应于真实的CAS服务器1~2,Web虚服务器对应于真实的Web服务器1~2。CAS服务器、Web浏览器和Web服务器三者之间的流量均由LB设备进行转发。例如,当Web浏览器需要访问Web服务器对应的Web服务时,将会发出一个访问请求,该访问请求的目的地址是Web虚服务器。该访问请求在到达LB设备时,LB设备判断出该访问请求的目的地址是虚服务器的地址,因此根据自身的LB转发表进行转发,具体的转发过程是:在首次转发时,根据预定的负载均衡算法,从Web虚服务器群中选择一个Web服务器,如Web服务器1,分配给该Web浏览器,并将该访问请求转发给Web服务器1,同时在LB转发表中记录该Web浏览器的相关表项,将该Web浏览器和Web服务器1相对应;后续如果再收到该客户端的访问上述Web服务的访问请求时,就可以直接根据LB转发表中的相关转发表项直接进行转发。对于Web浏览器向CAS虚服务器发送的认证请求,以及Web服务器向CAS虚服务器发送的验证请求,LB设备都通过类似的处理方式进行转发,从而实现了Web服务器之间、CAS服务器之间的负载均衡。
在现有的基于传输层的LB设备内,分别针对各个虚服务器创建了对应的LB转发表,因此LB设备在不同虚服务器之间进行的负载分发是相互独立。比如图3中,用户的Web浏览器向CAS虚服务器发送身份认证请求时,该用户的身份认证请求可能分发到CAS服务器1上(依据于CAS虚服务的负载均衡算法);而Web服务器1在向CAS虚服务器发送对该Web浏览器的验证请求时,该验证请求可能被分发到CAS服务器2上。
由于CAS服务器上缓存了用户的ServiceID、Service Ticket和用户名等信息。对同一用户而言,他的相关信息都缓存在某一台真实的CAS服务器上,后续的Web服务器的验证请求也必须发送到相同的CAS服务器上,才能保证验证得以正常进行,CAS系统的这种业务特性被称为业务黏性。由于现有技术的LB设备中针对各个虚服务器的流量转发是相互独立的,因此不能满足CAS业务黏性要求,例如,在用户的Web浏览器通过某一台CAS服务器的身份认证后,后续的Web服务器对该用户的验证请求可能被转发到另外一台CAS服务器,从而导致该用户验证失败,导致该用户不能正常访问原本应该允许访问的Web服务。
发明内容
本发明实施例所要解决的技术问题是提供一种提高CAS业务黏性的方法及LB设备,满足CAS业务的黏性要求,使得用户认证流程能够正常进行。
为解决上述技术问题,本发明实施例提供方案如下:
一种提高集中认证服务CAS系统业务黏性的方法,所述CAS系统包括:
对应于CAS虚服务器的CAS服务器群,所述CAS服务器群包括至少两个用于对客户端进行身份认证的CAS服务器;
对应于Web虚服务器的Web服务器群,所述Web服务器群包括至少两个用于提供同一Web服务的Web服务器;以及,
用于对去往所述CAS虚服务器和所述Web虚服务器的流量进行负载均衡处理的负载均衡LB设备;
所述方法包括:
LB设备对去往所述CAS虚服务器和所述Web虚服务器的流量转发均使能基于流量源地址的会话保持功能,并建立LB统一转发表,在所述LB统一转发表的转发表项中记录负载均衡处理过程中形成的客户端、CAS服务器和Web服务器三者之间的对应关系,其中,与同一客户端对应的CAS服务器和Web服务器相互对应;
LB设备在转发第一客户端向所述CAS虚服务器发送的、用于对访问所述Web服务的第一客户端进行身份认证的认证请求时,如果所述LB统一转发表中没有记录所述第一客户端对应的CAS服务器,但记录有所述第一客户端对应的第一Web服务器,则在所述LB统一转发表中查找是否存在所述第一Web服务器对应的CAS服务器:如果存在,则将所述认证请求转发至所述第一Web服务器对应的CAS服务器,并在LB统一转发表中记录所述第一客户端对应的CAS服务器为所述第一Web服务器对应的CAS服务器。
优选地,上述方法中,还包括:
LB设备接收所述第一Web服务器发送的对第一客户端的验证请求,根据所述LB统一转发表,确定所述第一Web服务器对应的CAS服务器,并将所述验证请求转发至所述CAS服务器。
优选地,上述方法中,LB设备在转发所述认证请求时,如果所述LB统一转发表中没有记录所述第一客户端对应的CAS服务器,但记录有所述第一客户端对应的第一Web服务器,且所述LB统一转发表中不存在所述第一Web服务器对应的CAS服务器,则进一步按照预定的负载均衡算法,从所述CAS服务器群中选择出第一CAS服务器,将所述认证请求转发至所述第一CAS服务器,并在LB统一转发表中记录所述第一客户端对应的CAS服务器为所述第一CAS服务器。
优选地,上述方法中,LB设备在转发所述认证请求时,如果所述LB统一转发表中既没有记录所述第一客户端对应的CAS服务器,也没有记录所述第一客户端对应的Web服务器,则按照预定的负载均衡算法,从所述CAS服务器群中选择出第二CAS服务器,将所述认证请求转发至所述第二CAS服务器,并在LB统一转发表中记录所述第一客户端对应的CAS服务器为所述第二CAS服务器。
优选地,上述方法中,LB设备在转发所述认证请求时,如果所述LB统一转发表中记录有所述第一客户端对应的CAS服务器,则直接将所述认证请求转发至所述第一客户端对应的CAS服务器。
优选地,上述方法中,所述对去往所述CAS虚服务器和所述Web虚服务器的流量转发均使能基于流量源地址的会话保持功能为:
LB设备在接收到去往所述CAS虚服务器的第一流量时,如果所述LB统一转发表中存在有第一流量源地址对应的CAS服务器,则直接将所述第一流量转发至所述第一流量源地址对应的CAS服务器;以及,
LB设备在接收到去往所述Web虚服务器的第二流量时,如果所述LB统一转发表中存在有第二流量源地址对应的Web服务器,则直接将所述第二流量转发至所述第二流量源地址对应的Web服务器。
优选地,上述方法中,进一步为所述LB统一转发表中的转发表项设置老化时间,并在所述老化时间超时后,删除相应的转发表项;以及,检测各CAS服务器和各Web服务器的工作状态,并在检测到发生故障的CAS服务器或Web服务器时,在LB统一转发表的相关转发表项中删除该发生故障的CAS服务器或Web服务器的信息。
本发明实施例还提供了一种集中认证服务CAS系统中的负载均衡LB设备,所述CAS系统还包括:
对应于CAS虚服务器的CAS服务器群,所述CAS服务器群包括至少两个用于对客户端进行身份认证的CAS服务器;以及,
对应于Web虚服务器的Web服务器群,所述Web服务器群包括至少两个用于提供同一Web服务的Web服务器;
所述LB设备包括:
转发表单元,用于建立LB统一转发表,在所述LB统一转发表的转发表项中记录在对去往所述CAS虚服务器和所述Web虚服务器的流量进行负载均衡处理过程中形成的客户端、CAS服务器和Web服务器三者之间的对应关系,其中,与同一客户端对应的CAS服务器和Web服务器相互对应;
转发处理单元,用于对去往所述CAS虚服务器和所述Web虚服务器的流量转发均使能基于流量源地址的会话保持功能,并在转发第一客户端向所述CAS虚服务器发送的、用于对访问所述Web服务的第一客户端进行身份认证的认证请求时,如果所述LB统一转发表中没有记录所述第一客户端对应的CAS服务器,但记录有所述第一客户端对应的第一Web服务器,则在所述LB统一转发表中查找是否存在所述第一Web服务器对应的CAS服务器:如果存在,则将所述认证请求转发至所述第一Web服务器对应的CAS服务器,并触发所述转发表单元在LB统一转发表中记录所述第一客户端对应的CAS服务器为所述第一Web服务器对应的CAS服务器。
优选地,上述LB设备中,所述转发单元,还用于接收所述第一Web服务器发送的对第一客户端的验证请求,根据所述LB统一转发表,确定所述第一Web服务器对应的CAS服务器,并将所述验证请求转发至所述CAS服务器。
优选地,上述LB设备中,所述转发单元,还用于在转发所述认证请求时,如果所述LB统一转发表中没有记录所述第一客户端对应的CAS服务器,但记录有所述第一客户端对应的第一Web服务器,且所述LB统一转发表中不存在所述第一Web服务器对应的CAS服务器,则进一步按照预定的负载均衡算法,从所述CAS服务器群中选择出第一CAS服务器,将所述认证请求转发至所述第一CAS服务器,并触发所述转发表单元在LB统一转发表中记录所述第一客户端对应的CAS服务器为所述第一CAS服务器。
优选地,上述LB设备中,所述转发单元,还用于在转发所述认证请求时,如果所述LB统一转发表中既没有记录所述第一客户端对应的CAS服务器,也没有记录所述第一客户端对应的Web服务器,则按照预定的负载均衡算法,从所述CAS服务器群中选择出第二CAS服务器,将所述认证请求转发至所述第二CAS服务器,并触发所述转发表单元在LB统一转发表中记录所述第一客户端对应的CAS服务器为所述第二CAS服务器。
优选地,上述LB设备中,所述转发单元,还用于在转发所述认证请求时,如果所述LB统一转发表中记录有所述第一客户端对应的CAS服务器,则直接将所述认证请求转发至所述第一客户端对应的CAS服务器。
优选地,上述LB设备中,所述对去往所述CAS虚服务器和所述Web虚服务器的流量转发均使能基于流量源地址的会话保持功能为:LB设备在接收到去往所述CAS虚服务器的第一流量时,如果所述LB统一转发表中存在有第一流量源地址对应的CAS服务器,则直接将所述第一流量转发至所述第一流量源地址对应的CAS服务器;以及,LB设备在接收到去往所述Web虚服务器的第二流量时,如果所述LB统一转发表中存在有第二流量源地址对应的Web服务器,则直接将所述第二流量转发至所述第二流量源地址对应的Web服务器。
优选地,上述LB设备中,所述转发表单元,还用于为所述LB统一转发表中的转发表项设置老化时间,并在所述老化时间超时后,删除相应的转发表项;以及,用于检测各CAS服务器和各Web服务器的工作状态,并在检测到发生故障的CAS服务器或Web服务器时,在LB统一转发表的相关转发表项中删除该发生故障的CAS服务器或Web服务器的信息。
从以上所述可以看出,本发明实施例提供的提高CAS业务黏性的方法及LB设备,将针对各个虚服务器的LB转发表合并成一张LB统一转发表,在LB统一转发表中形成CAS服务器和Web服务器之间的对应关系;通过使能基于流量源地址的会话保持功能,并通过特殊的转发处理流程,本发明实施例使得LB统一转发表中一个Web服务器只与唯一一个CAS服务器相对应,进而保证了客户端在通过某一台CAS服务器的认证后,后续的Web服务器对该客户端的验证请求能够被转发到同一台CAS服务器,从而满足了CAS系统的业务黏性,使得用户认证能够正常进行。
附图说明
图1为现有技术的CAS的体系结构及其工作流程示意图;
图2为现有技术的CAS系统的三角形流量拓扑示意图;
图3为现有技术的CAS系统中基于传输层的负载均衡处理的示意图;
图4为本发明实施例的一个具体应用环境示意图;
图5为本发明实施例所述提高CAS业务黏性的方法的流程图;
图6为本发明实施例中认证请求转发的转发处理流程示意图;
图7为本发明实施例所述LB设备的结构示意图。
具体实施方式
本发明提供了一种提高CAS业务黏性的方法及LB设备,本发明在LB设备将多个独立的、针对各个虚服务器的LB转发表合并成一张统一的转发表:LB统一转发表;并使能基于流量源地址的会话保持功能;同时,在流量转发过程中,通过特殊的转发处理,使得客户端在通过某一台CAS服务器的身份认证后,后续的Web服务器对该客户端的验证请求能够被转发到同一台CAS服务器,从而提高了CAS业务黏性,满足了业务黏性要求,使得用户认证能够正常进行。以下将结合附图,通过具体实施例对本发明作进一步的说明。
图4所示为本发明实施例的一个具体应用环境。图4中示出了一个CAS系统,该CAS系统包括有:
客户端,即Web浏览器;
用于对去往所述CAS虚服务器和所述Web虚服务器的流量进行负载均衡处理的LB设备;
CAS服务器群,该CAS服务器群对应一个CAS虚服务器,该CAS服务器群具体包括两个用于对客户端进行身份认证的CAS服务器:CAS服务器1~2;以及,
Web服务器群1,该Web服务器群对应一个Web虚服务器1,该Web服务器群1具体包括有用于提供同一Web服务的两个Web服务器:Web服务器1~2。
图4中,客户端和CAS服务器之间、客户端和Web服务器之间、Web服务器和CAS服务器之间,均通过LB设备连接,各设备的IP地址如图4所示。针对图4所示的应用环境,本实施例所述提高CAS业务黏性的方法,如图5所示,包括以下步骤:
步骤51,LB设备对去往所述CAS虚服务器和所述Web虚服务器的流量转发均使能基于流量源地址的会话保持功能,并建立LB统一转发表,所述LB统一转发表的转发表项中记录在负载均衡处理过程中形成的客户端、CAS服务器和Web服务器三者之间的对应关系,其中,与同一客户端对应的CAS服务器和Web服务器相互对应。
这里,LB设备在首次转发某个客户端去往CAS虚服务器或Web虚服务器1的流量时,将进行负载均衡处理,按照预定的负载均衡算法为该客户端分配其所对应的CAS服务器或Web服务器,作为去往CAS虚服务器或Web虚服务器的流量的目的地,从而形成了客户端与CAS服务器、以及客户端与Web服务器之间的对应关系。即,LB设备在负载均衡处理过程中分配给某个客户端的、作为该客户端去往CAS虚服务器的流量的目的地的CAS服务器,与该客户端相对应;在负载均衡处理过程中分配给某个客户端的、作为该客户端去往Web虚服务器1的流量的目的地的Web服务器,也与该客户端相对应。同时,LB设备分配给该客户端的CAS服务器,与LB设备分配给该客户端的Web服务器也相对应,即,与同一客户端对应的CAS服务器和Web服务器相互对应。上述对应关系在LB统一转发表中表现为:LB统一转发表中的每一行代表某个客户端的转发表项,在该转发表项中分别记录该客户端对应的CAS服务器、该客户端对应的Web服务器的信息,存在于同一转发表项中的客户端、CAS服务器和Web服务器两两之间相互对应。
步骤52,LB设备在转发第一客户端向所述CAS虚服务器发送的、用于对访问所述Web服务的第一客户端进行身份认证的认证请求时:
如果所述LB统一转发表中记录有所述第一客户端对应的CAS服务器,则直接将所述认证请求转发至所述第一客户端对应的CAS服务器;
如果所述LB统一转发表中没有记录所述第一客户端对应的CAS服务器,但记录有所述第一客户端对应的第一Web服务器,则在所述LB统一转发表中查找是否存在所述第一Web服务器对应的CAS服务器:如果存在,则将所述认证请求转发至所述第一Web服务器对应的CAS服务器,并在LB统一转发表中记录所述第一客户端对应的CAS服务器为所述第一Web服务器对应的CAS服务器;如果不存在,则进一步按照预定的负载均衡算法,从所述CAS服务器群中选择出第一CAS服务器,将所述认证请求转发至所述第一CAS服务器,并在LB统一转发表中记录所述第一客户端对应的CAS服务器为所述第一CAS服务器;
如果所述LB统一转发表中既没有记录所述第一客户端对应的CAS服务器,也没有记录所述第一客户端对应的Web服务器,则按照预定的负载均衡算法,从所述CAS服务器群中选择出第二CAS服务器,将所述认证请求转发至所述第二CAS服务器,并在LB统一转发表中记录所述第一客户端对应的CAS服务器为所述第二CAS服务器。
步骤53,LB设备接收所述第一Web服务器发送的对第一客户端的验证请求,根据所述LB统一转发表,确定所述第一Web服务器对应的CAS服务器,并将所述验证请求转发至所述CAS服务器。
上述步骤51中,所述对去往所述CAS虚服务器和所述Web虚服务器的流量转发均使能基于流量源地址的会话保持功能,具体包括:LB设备在接收到去往所述CAS虚服务器的第一流量时,如果所述LB统一转发表中存在有第一流量源地址对应的CAS服务器,则直接将所述第一流量转发至所述第一流量源地址对应的CAS服务器;以及,LB设备在接收到去往所述Web虚服务器的第二流量时,如果所述LB统一转发表中存在有第二流量源地址对应的Web服务器,则直接将所述第二流量转发至所述第二流量源地址对应的Web服务器。
当然,图4中的Web服务器群1还可以包括有多于两个的Web服务器,CAS服务器群也可以包括有多于两个的CAS服务器。图4的CAS系统还可以包括更多的Web服务器群,每个Web服务器群对应于同一种Web服务,通过该Web服务器群下的Web服务器提供相应的Web服务。在CAS系统中包括更多的Web服务器群时,针对每个Web服务器群,本发明实施例的处理流程与图5所示的流程类似。
从以上所述可知,本实施例中LB设备通过合并各个虚服务器的LB转发表,在转发客户端的认证请求时,如果LB统一转发表中没有该客户端对应的CAS服务器,则根据该客户端对应的第一Web服务器,在LB统一转发表中查找与该第一Web服务器对应的CAS服务器,将认证请求转发给第一Web服务器对应的CAS服务器。上述步骤52中的LB转发处理方式,使得对于任意一个Web服务器,在CAS服务器群中最多只存在一个CAS服务器,与该Web服务器相对应,而只有该CAS服务器才可能保存有该客户端的ServiceID、Ticket和用户名等信息,从而满足了 CAS系统的业务黏性的要求,使得客户端的认证过程得以正常进行,实现了CAS服务器群中的CAS服务器、Web服务器群中的Web服务器及客户端的Web浏览器之间的高度黏性的三角形流量业务的负载均衡。
为了更容易理解上述步骤52中LB转发处理方式的意义,可以通过反向考虑,例如,假设LB统一转发表中已经形成了客户端1、Web服务器1、CAS服务器1三者之间的对应关系,且客户端2与Web服务器1相对应,但LB统一转发表中尚无客户端2对应的CAS服务器。假设LB设备在转发客户端2的认证请求时,没有按照上述步骤52的处理,将该认证请求转发给Web服务器1对应的CAS服务器1,而是按照负载均衡算法选择了CAS服务器2进行转发,从而CAS服务器2上将保存有客户端2的ServiceID、Ticket和用户名等信息,并且在LB统一转发表中会形成Web服务器1与CAS服务器1的对应关系,以及Web服务器1与CAS服务器2的对应关系,即Web服务器1与多个CAS服务器相对应。这样,在后续LB设备转发Web服务器发送的、对客户端1或2的验证请求时,由于该验证请求的源地址(Web服务器1)对应于多个CAS服务器,按照基于流量源地址的会话保持功能,LB设备将无法确定选择哪一个CAS服务器进行转发,也就无法保证后续的验证处理能够正常进行,即无法满足CAS业务的黏性要求。
以下基于图4所示的应用环境,通过上述实施例的一个具体的应用实例,对上述流程进行做进一步的说明。
现有技术中,LB设备在实现基于传输层的负载均衡处理时,对每个虚服务器的访问分别构建LB转发表,如下表1所示,表1是针对虚服务器1构建的一张LB转发表,表1中省略了端口等非关键信息。LB设备在接收到某个客户端发送给虚服务器1的流量时,在表1中查找到该客户端对应的真实服务器,然后将流量转发到该对应的真实服务器。
表1
现有技术中相互独立的虚服务器的LB转发表无法满足客户端、Web服务器和CAS服务器之间的黏性要求。因此,本应用实例中,将LB设备上相互独立的多个虚服务器的LB转发表合并为一张LB统一转发表,从而将多个LB转发表相关联,建立起客户端、CAS服务器和Web服务器三者之间的对应关系。表2示出了一种可能的合并后的LB统一转发表,其中每行分别是针对某个客户端的转发表项,每行中所记录的客户端、CAS服务器和Web服务器两两之间相互对应。
表2
表2所示的LB统一转发表,可以随着CAS系统中的Web虚服务器的增加而增加相应的Web虚服务器的列,如下表3所示,表3中包括有两个Web虚服务器,相对于表2,增加了Web虚服务器2一列。同样的,每行中的客户端、CAS服务器和Web服务器两两之间相互对应。
表3
图4中包括有两个虚服务器,其中,Web虚服务器1的虚IP地址为192.168.88.1。Web虚服务器1对应于一个具体的Web服务(假设为Web服务1),该Web虚服务器1还对应于Web服务器群1,Web服务器群1包括有用于提供上述Web服务的真实Web服务器1~2,Web服务器1~2的IP地址分别为192.168.66.63和192.168.168.66.64。CAS虚服务器为对应于CAS服务器群,该CAS虚服务器的虚IP地址为192.168.88.3。该CAS虚服务器对应于一个CAS服务器群,该CAS服务器群包含CAS服务器1~2,CAS服务器1~2的IP地址分别为192.168.66.105和192.168.66.106。
以下以客户端1访问Web服务器群1的Web服务的过程(下述的步骤61~69),来说明本发明实施例所述方法的工作机制。
在对LB设备进行初始配置时,需要将CAS虚服务器和Web虚服务器1相关联,以构建一张同时包括CAS虚服务器和Web虚服务器1的LB统一转发表,并对去往所有虚服务器的流量转发均使能基于流量源地址的会话保持功能。使能基于源地址的会话保持功能后,LB设备在转发报文时,如果LB转发表已经有相应的转发表项时,就不再根据负载均衡算法选择欲转发的真实服务器,而是根据相应的转发表项,直接修改该报文的目的地址并进行转发。
步骤61,客户端1在需要访问Web服务器群1提供的Web服务1时,向该Web服务器群1对应的Web虚服务器1发送相应的HTTP访问请求,该HTTP访问请求的目的IP地址为Web虚服务器1的虚IP地址192.168.88.1。
该HTTP访问请求到达LB设备后,LB设备查找LB统一转发表,如果没有找到对应的转发表项,则根据预定的负载均衡算法(如轮循算法、源地址哈希算法等),从Web服务器群1中选择一个服务器(假设为Web服务器1)分配给客户端1,并将HTTP访问请求的目的地址修改为修改Web服务器1然后在转发该HTTP访问请求,同时,在LB统一转发表中记录下分配给客户端1的Web服务器1的信息,如下表4所示:
表4
步骤62,Web服务器1接收到LB设备转发的HTTP访问请求后,检查发现该HTTP访问请求中没有Service Ticket,因此向客户端1返回HTTP重定向报文,指示客户端1去往CAS虚服务器进行认证。HTTP重定向报文到达LB设备后,LB设备根据表4的转发表项,将HTTP重定向报文的源IP地址由Web服务器1的IP地址192.168.66.63变更为Web虚服务器1的虚IP地址192.168.88.1,再将该HTTP重定向报文转发给客户端1。
步骤63,客户端1根据HTTP重定向报文,向CAS虚服务器发送访问Web服务1的HTTPS认证请求,请求对客户端1进行身份认证,确认客户端1是否可以访问Web服务1。该HTTPS认证请求的目的地址为CAS虚服务器的虚IP地址192.168.88.3,且该HTTPS认证请求中携带有ServiceID参数,用于指示客户端1希望访问的Web服务1。
步骤64,LB设备接收到上述HTTPS认证请求后,按照图6所示的转发处理流程进行转发处理:
步骤641,以该HTTPS认证请求的源IP地址(即客户端1的IP地址)为索引,查找LB统一转发表,判断是否记录有客户端1对应的CAS服务器:若是,则进入步骤642;否则,进入步骤643。
步骤642,将上述HTTPS认证请求转发至客户端1对应的CAS服务器。
步骤643,以该HTTPS认证请求的源IP地址(即客户端1的IP地址)为索引,查找LB统一转发表,判断Web服务器群1中是否存在客户端1对应的Web服务器:如果存在,则进入步骤645;否则,说明客户端在向CAS服务器进行认证之前并未向Web服务器发送相应的访问请求,即当前认证是预认证,此时进入步骤644。这里,以客户端1为索引查找LB统一转发表的方式是:在LB统一转发表中,查找客户端1所在的行和Web服务器群1所在的列的交点处是否记录有相应的Web服务器的信息。
步骤644,LB设备根据预定的负载均衡算法从CAS服务器群中选择一个CAS服务器分配给客户端1,然后将该HTTPS认证请求的目的IP地址修改为该CAS服务器后转发出去,同时在LB统一转发表中记录下分配给客户端1的CAS服务器的信息。
步骤645,这里,假设LB设备在以客户端1为索引,查找到Web服务器群1中分配给客户端1的Web服务器为Web服务器1,此时,则进一步以Web服务器1为索引,查找LB统一转发表,判断是否存在与Web服务器1对应的CAS服务器:如果存在,则进入步骤646;否则,进入步骤647。这里,以Web服务器1为索引查找LB统一转发表的方式是:在记录有Web服务器1的所有的行中查找是否记录有CAS服务器的信息,如果查找到某个CAS服务器,则该CAS服务器就是Web服务器1对应的CAS服务器。其原因在于,该CAS服务器和Web服务器1记录在同一行中,因此均对应于同一个客户端,即,它们是分配给同一个客户端的CAS服务器和Web服务器,因此是相互对应的CAS服务器和Web服务器。
步骤646,将上述HTTPS认证请求转发至Web服务器1对应的CAS服务器,并在客户端1的转发表项中增加Web服务器1对应的CAS服务器的信息。
步骤647,按照预定的负载均衡算法,从CAS服务器群中选择出一个CAS服务器,假设为CAS服务器1,然后将HTTPS认证请求转发至该CAS服务器1,并在LB统一转发表中客户端1的转发表项中记录CAS服务器1的信息。
这里,假设步骤64之后,LB统一转发表如下表5所示,其中,客户端1所在行和CAS虚服务器所在列的交点位置处记录了CAS服务器1的信息(如CSA服务器1的IP地址信息)
表5
步骤65,CAS服务器1通过客户端1的认证之后,为客户端1生成一个Service Ticket,并在自身内部数据库内将该Service Ticket和客户端1请求访问的Web服务(ServiceID)相关联,并向客户端1返回一个携带有该Service Ticket的重定向响应报文,指示客户端1使用Server Ticket向Web虚拟服务器继续进行Web服务访问。LB设备收到CAS服务器1发送的重定向响应报文后,修改该报文的源地址为CAS虚服务器的虚IP地址后,再转发至客户端1。
步骤66,客户端1在接收到LB设备转发的重定向响应报文后,再次向Web虚服务器1发送HTTP访问请求,并在该访问请求中携带Service Ticket参数。LB设备接收到该HTTP访问请求后,根据LB统一转发表,以客户端1为索引进行检索,找到客户端1对应的Web服务器1,因此,修改该HTTP访问请求的目的IP地址为Web服务器1的IP地址后再转发该HTTP访问请求。
步骤67,Web服务器1接收到携带有Service Ticket参数的HTTP访问请求后,向CAS虚服务器的虚IP地址发送HTTPS验证请求,验证客户端1是否合法并被授权。该验证请求中携带有Service Ticket参数和ServiceID参数。
步骤68,LB设备接收到上述验证请求后,以该验证请求的源IP地址即Web服务器1的IP地址为索引,查找LB统一转发表,判断是否存在与Web服务器1对应的CAS服务器,具体查找方式是:在记录有Web服务器1的行中查找是否记录有CAS服务器的信息,如果查找到某个CAS服务器,则该CAS服务器就是Web服务器1对应的CAS服务器。对应于表5所示的LB统一转发表,LB设备将会查找到CAS服务器1的记录信息,从而使用CAS服务器1替代该验证请求的目的地址并进行转发。
步骤69,CAS服务器1接收到上述验证请求后,根据自身内部的数据库中记录的Service Ticket和ServiceID的关联信息,完成相应的验证。在验证通过之后,向Web服务器1返回验证通过的验证结果。该验证结果到达LB设备后,LB设备使用CAS虚服务器的虚IP地址替换该验证结果的源地址后,将该验证结果转发给Web服务器1。Web服务器1接收到该验证结果后,将向客户端1提供相应的Web服务,从而客户端1可以正常地访问相应的Web服务。
可以看出,本实例中通过将LB设备上的多个虚服务器的LB转发表合并,并在转发流量时,按照特殊的转发处理流程进行查表转发,满足了CAS的业务黏性要求。
对于LB统一转发表,本实施例可以按照以下条件对其进行维护:
1)、LB设备使能对各个虚服务器,如Web虚服务器、CAS虚服务器的健康检测,用以检测真实的服务器的工作状态。如果检测到某个真实的服务器发生故障,则在LB统一转发表的相关转发表项中删除该发生故障的服务器的信息。
2)、LB设备上设置转发表项的老化时间,根据老化时间触发对相关转发表项的删除操作。老化时间的长短可依据于应用环境中CAS服务器上的Service Ticket或授权的票据证明(TGC,ticket-granting cookie)的保存时间(在当前的CAS实现中,对TGC的老化时间通常为8小时)进行设置。
基于以上所述的提高CAS业务黏性的方法,本发明实施例还相应地提供了一种LB设备。该LB设置在CAS系统中,所述CAS系统还包括:
对应于CAS虚服务器的CAS服务器群,所述CAS服务器群包括至少两个用于对客户端进行身份认证的CAS服务器;以及,
对应于Web虚服务器的Web服务器群,所述Web服务器群包括至少两个用于提供同一Web服务的Web服务器。
如图7所示,本实施例所述的LB设备具体包括:
转发表单元,用于建立LB统一转发表,在所述LB统一转发表的转发表项中记录在对去往所述CAS虚服务器和所述Web虚服务器的流量进行负载均衡处理过程中形成的客户端、CAS服务器和Web服务器三者之间的对应关系,其中,与同一客户端对应的CAS服务器和Web服务器相互对应;
转发处理单元,用于对去往所述CAS虚服务器和所述Web虚服务器的流量转发均使能基于流量源地址的会话保持功能,并在转发第一客户端向所述CAS虚服务器发送的、用于对访问所述Web服务的第一客户端进行身份认证的认证请求时,如果所述LB统一转发表中没有记录所述第一客户端对应的CAS服务器,但记录有所述第一客户端对应的第一Web服务器,则在所述LB统一转发表中查找是否存在所述第一Web服务器对应的CAS服务器:如果存在,则将所述认证请求转发至所述第一Web服务器对应的CAS服务器,并触发所述转发表单元在LB统一转发表中记录所述第一客户端对应的CAS服务器为所述第一Web服务器对应的CAS服务器。
上述对去往所述CAS虚服务器和所述Web虚服务器的流量转发均使能基于流量源地址的会话保持功能,具体包括:LB设备在接收到去往所述CAS虚服务器的第一流量时,如果所述LB统一转发表中存在有第一流量源地址对应的CAS服务器,则直接将所述第一流量转发至所述第一流量源地址对应的CAS服务器;以及,LB设备在接收到去往所述Web虚服务器的第二流量时,如果所述LB统一转发表中存在有第二流量源地址对应的Web服务器,则直接将所述第二流量转发至所述第二流量源地址对应的Web服务器。
这里,优选地,所述转发单元,还用于接收所述第一Web服务器发送的对第一客户端的验证请求,根据所述LB统一转发表,确定所述第一Web服务器对应的CAS服务器,并将所述验证请求转发至所述CAS服务器。
这里,优选地,所述转发单元,还用于在转发所述认证请求时,如果所述LB统一转发表中没有记录所述第一客户端对应的CAS服务器,但记录有所述第一客户端对应的第一Web服务器,且所述LB统一转发表中不存在所述第一Web服务器对应的CAS服务器,则进一步按照预定的负载均衡算法,从所述CAS服务器群中选择出第一CAS服务器,将所述认证请求转发至所述第一CAS服务器,并触发所述转发表单元在LB统一转发表中记录所述第一客户端对应的CAS服务器为所述第一CAS服务器。
这里,优选地,所述转发单元,还用于在转发所述认证请求时,如果所述LB统一转发表中既没有记录所述第一客户端对应的CAS服务器,也没有记录所述第一客户端对应的Web服务器,则按照预定的负载均衡算法,从所述CAS服务器群中选择出第二CAS服务器,将所述认证请求转发至所述第二CAS服务器,并触发所述转发表单元在LB统一转发表中记录所述第一客户端对应的CAS服务器为所述第二CAS服务器。
这里,优选地,所述转发单元,还用于在转发所述认证请求时,如果所述LB统一转发表中记录有所述第一客户端对应的CAS服务器,则直接将所述认证请求转发至所述第一客户端对应的CAS服务器。
综上所述,本发明实施例提供的提高CAS业务黏性的方法及LB设备,在LB统一转发表中形成CAS服务器和Web服务器之间的对应关系,并通过特殊的转发处理流程,使得一个Web服务器只与唯一一个CAS服务器相对应,从而提高了CAS系统的业务黏性,使得用户认证能够正常进行。
以上所述仅是本发明的实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以作出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。
Claims (12)
1.一种提高集中认证服务CAS系统业务黏性的方法,所述CAS系统包括:
对应于CAS虚服务器的CAS服务器群,所述CAS服务器群包括至少两个用于对客户端进行身份认证的CAS服务器;
对应于Web虚服务器的Web服务器群,所述Web服务器群包括至少两个用于提供同一Web服务的Web服务器;以及,
用于对去往所述CAS虚服务器和所述Web虚服务器的流量进行负载均衡处理的负载均衡LB设备;
其特征在于,所述方法包括:
LB设备对去往所述CAS虚服务器和所述Web虚服务器的流量转发均使能基于流量源地址的会话保持功能,并建立LB统一转发表,在所述LB统一转发表的转发表项中记录负载均衡处理过程中形成的客户端、CAS服务器和Web服务器三者之间的对应关系,其中,与同一客户端对应的CAS服务器和Web服务器相互对应;
LB设备在转发第一客户端向所述CAS虚服务器发送的、用于对访问所述Web服务的第一客户端进行身份认证的认证请求时,如果所述LB统一转发表中没有记录所述第一客户端对应的CAS服务器,但记录有所述第一客户端对应的第一Web服务器,则在所述LB统一转发表中查找是否存在所述第一Web服务器对应的CAS服务器:如果存在,则将所述认证请求转发至所述第一Web服务器对应的CAS服务器,并在LB统一转发表中记录所述第一客户端对应的CAS服务器为所述第一Web服务器对应的CAS服务器;
其中,所述对去往所述CAS虚服务器和所述Web虚服务器的流量转发均使能基于流量源地址的会话保持功能为:
LB设备在接收到去往所述CAS虚服务器的第一流量时,如果所述LB统一转发表中存在有第一流量源地址对应的CAS服务器,则直接将所述第一流量转发至所述第一流量源地址对应的CAS服务器;以及,
LB设备在接收到去往所述Web虚服务器的第二流量时,如果所述LB统一转发表中存在有第二流量源地址对应的Web服务器,则直接将所述第二流量转发至所述第二流量源地址对应的Web服务器。
2.如权利要求1所述的方法,其特征在于,还包括:
LB设备接收所述第一Web服务器发送的对第一客户端的验证请求,根据所述LB统一转发表,确定所述第一Web服务器对应的CAS服务器,并将所述验证请求转发至所述CAS服务器。
3.如权利要求2所述的方法,其特征在于,
LB设备在转发所述认证请求时,如果所述LB统一转发表中没有记录所述第一客户端对应的CAS服务器,但记录有所述第一客户端对应的第一Web服务器,且所述LB统一转发表中不存在所述第一Web服务器对应的CAS服务器,则进一步按照预定的负载均衡算法,从所述CAS服务器群中选择出第一CAS服务器,将所述认证请求转发至所述第一CAS服务器,并在LB统一转发表中记录所述第一客户端对应的CAS服务器为所述第一CAS服务器。
4.如权利要求3所述的方法,其特征在于,LB设备在转发所述认证请求时,如果所述LB统一转发表中既没有记录所述第一客户端对应的CAS服务器,也没有记录所述第一客户端对应的Web服务器,则按照预定的负载均衡算法,从所述CAS服务器群中选择出第二CAS服务器,将所述认证请求转发至所述第二CAS服务器,并在LB统一转发表中记录所述第一客户端对应的CAS服务器为所述第二CAS服务器。
5.如权利要求1至4任一项所述的方法,其特征在于,LB设备在转发所述认证请求时,如果所述LB统一转发表中记录有所述第一客户端对应的CAS服务器,则直接将所述认证请求转发至所述第一客户端对应的CAS服务器。
6.如权利要求1所述的方法,其特征在于,进一步为所述LB统一转发表中的转发表项设置老化时间,并在所述老化时间超时后,删除相应的转发表项;以及,检测各CAS服务器和各Web服务器的工作状态,并在检测到发生故障的CAS服务器或Web服务器时,在LB统一转发表的相关转发表项中删除该发生故障的CAS服务器或Web服务器的信息。
7.一种集中认证服务CAS系统中的负载均衡LB设备,所述CAS系统还包括:
对应于CAS虚服务器的CAS服务器群,所述CAS服务器群包括至少两个用于对客户端进行身份认证的CAS服务器;以及,
对应于Web虚服务器的Web服务器群,所述Web服务器群包括至少两个用于提供同一Web服务的Web服务器;
其特征在于,所述LB设备包括:
转发表单元,用于建立LB统一转发表,在所述LB统一转发表的转发表项中记录在对去往所述CAS虚服务器和所述Web虚服务器的流量进行负载均衡处理过程中形成的客户端、CAS服务器和Web服务器三者之间的对应关系,其中,与同一客户端对应的CAS服务器和Web服务器相互对应;
转发处理单元,用于对去往所述CAS虚服务器和所述Web虚服务器的流量转发均使能基于流量源地址的会话保持功能,并在转发第一客户端向所述CAS虚服务器发送的、用于对访问所述Web服务的第一客户端进行身份认证的认证请求时,如果所述LB统一转发表中没有记录所述第一客户端对应的CAS服务器,但记录有所述第一客户端对应的第一Web服务器,则在所述LB统一转发表中查找是否存在所述第一Web服务器对应的CAS服务器:如果存在,则将所述认证请求转发至所述第一Web服务器对应的CAS服务器,并触发所述转发表单元在LB统一转发表中记录所述第一客户端对应的CAS服务器为所述第一Web服务器对应的CAS服务器;
其中,所述对去往所述CAS虚服务器和所述Web虚服务器的流量转发均使能基于流量源地址的会话保持功能为:
LB设备在接收到去往所述CAS虚服务器的第一流量时,如果所述LB统一转发表中存在有第一流量源地址对应的CAS服务器,则直接将所述第一流量转发至所述第一流量源地址对应的CAS服务器;以及,
LB设备在接收到去往所述Web虚服务器的第二流量时,如果所述LB统一转发表中存在有第二流量源地址对应的Web服务器,则直接将所述第二流量转发至所述第二流量源地址对应的Web服务器。
8.如权利要求7所述的LB设备,其特征在于,
所述转发处理单元,还用于接收所述第一Web服务器发送的对第一客户端的验证请求,根据所述LB统一转发表,确定所述第一Web服务器对应的CAS服务器,并将所述验证请求转发至所述CAS服务器。
9.如权利要求8所述的LB设备,其特征在于,
所述转发处理单元,还用于在转发所述认证请求时,如果所述LB统一转发表中没有记录所述第一客户端对应的CAS服务器,但记录有所述第一客户端对应的第一Web服务器,且所述LB统一转发表中不存在所述第一Web服务器对应的CAS服务器,则进一步按照预定的负载均衡算法,从所述CAS服务器群中选择出第一CAS服务器,将所述认证请求转发至所述第一CAS服务器,并触发所述转发表单元在LB统一转发表中记录所述第一客户端对应的CAS服务器为所述第一CAS服务器。
10.如权利要求9所述的LB设备,其特征在于,
所述转发处理单元,还用于在转发所述认证请求时,如果所述LB统一转发表中既没有记录所述第一客户端对应的CAS服务器,也没有记录所述第一客户端对应的Web服务器,则按照预定的负载均衡算法,从所述CAS服务器群中选择出第二CAS服务器,将所述认证请求转发至所述第二CAS服务器,并触发所述转发表单元在LB统一转发表中记录所述第一客户端对应的CAS服务器为所述第二CAS服务器。
11.如权利要求7至10任一项所述的LB设备,其特征在于,
所述转发处理单元,还用于在转发所述认证请求时,如果所述LB统一转发表中记录有所述第一客户端对应的CAS服务器,则直接将所述认证请求转发至所述第一客户端对应的CAS服务器。
12.如权利要求7所述的LB设备,其特征在于,
所述转发表单元,还用于为所述LB统一转发表中的转发表项设置老化时间,并在所述老化时间超时后,删除相应的转发表项;以及,用于检测各CAS服务器和各Web服务器的工作状态,并在检测到发生故障的CAS服务器或Web服务器时,在LB统一转发表的相关转发表项中删除该发生故障的CAS服务器或Web服务器的信息。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2009100878585A CN101588390B (zh) | 2009-06-24 | 2009-06-24 | 提高集中认证服务系统业务黏性的方法及负载均衡设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2009100878585A CN101588390B (zh) | 2009-06-24 | 2009-06-24 | 提高集中认证服务系统业务黏性的方法及负载均衡设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101588390A CN101588390A (zh) | 2009-11-25 |
CN101588390B true CN101588390B (zh) | 2012-06-27 |
Family
ID=41372453
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2009100878585A Active CN101588390B (zh) | 2009-06-24 | 2009-06-24 | 提高集中认证服务系统业务黏性的方法及负载均衡设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101588390B (zh) |
Families Citing this family (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102104483B (zh) * | 2009-12-18 | 2013-10-02 | 杭州华三通信技术有限公司 | 一种基于负载均衡的单点登录方法、系统和负载均衡设备 |
CN102075445B (zh) * | 2011-02-28 | 2013-12-25 | 杭州华三通信技术有限公司 | 负载均衡方法及装置 |
CN103634269B (zh) * | 2012-08-21 | 2017-04-19 | 中国银联股份有限公司 | 单点登录系统及方法 |
CN103795694A (zh) * | 2012-10-31 | 2014-05-14 | 中国电信股份有限公司 | 许可控制方法及系统 |
CN103905203A (zh) * | 2014-04-02 | 2014-07-02 | 北京中交兴路车联网科技有限公司 | 一种单点认证方法及装置 |
CN105337949B (zh) * | 2014-08-13 | 2019-03-15 | 中国移动通信集团重庆有限公司 | 一种SSO认证方法、web服务器、认证中心和token校验中心 |
CN106878434A (zh) * | 2017-02-28 | 2017-06-20 | 杭州迪普科技股份有限公司 | 一种重定向的方法及装置 |
CN107733995A (zh) * | 2017-09-21 | 2018-02-23 | 北京信安世纪科技股份有限公司 | 一种会话保持方法、装置和电子设备 |
CN109802925B (zh) * | 2017-11-17 | 2021-10-29 | 阿里巴巴(中国)有限公司 | 一种公共WiFi接入的认证方法和系统 |
CN107911379B (zh) * | 2017-11-29 | 2020-02-21 | 贝壳找房(北京)科技有限公司 | 一种cas服务器 |
CN109101337A (zh) * | 2018-07-23 | 2018-12-28 | 赛尔网络有限公司 | 一种基于HAProxy的服务器节点升级方法及电子设备 |
CN109286663A (zh) * | 2018-09-14 | 2019-01-29 | 郑州云海信息技术有限公司 | 一种分布式系统业务分配方法、装置及设备 |
CN109815010A (zh) * | 2018-12-29 | 2019-05-28 | 深圳供电局有限公司 | 一种云平台统一身份认证方法及系统 |
CN109451074B (zh) * | 2018-12-29 | 2021-07-06 | 杭州全维技术股份有限公司 | 一种基于portal协议的服务器负载均衡处理办法 |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2008036947A2 (en) * | 2006-09-22 | 2008-03-27 | Bea Systems, Inc. | Reverse proxy system |
-
2009
- 2009-06-24 CN CN2009100878585A patent/CN101588390B/zh active Active
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2008036947A2 (en) * | 2006-09-22 | 2008-03-27 | Bea Systems, Inc. | Reverse proxy system |
Also Published As
Publication number | Publication date |
---|---|
CN101588390A (zh) | 2009-11-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101588390B (zh) | 提高集中认证服务系统业务黏性的方法及负载均衡设备 | |
US11683300B2 (en) | Tenant-aware distributed application authentication | |
CN107645486B (zh) | 登录认证方法和装置 | |
CN101626369B (zh) | 一种单点登录方法、设备及系统 | |
CN106375270B (zh) | 令牌生成并认证的方法及认证服务器 | |
US7953790B2 (en) | Session information inheriting method and apparatus | |
US7673001B1 (en) | Enterprise management of public instant message communications | |
CN102638454B (zh) | 一种面向http身份鉴别协议的插件式单点登录集成方法 | |
US8683565B2 (en) | Authentication | |
US8850553B2 (en) | Service binding | |
US7596804B2 (en) | Seamless cross-site user authentication status detection and automatic login | |
CN102104483B (zh) | 一种基于负载均衡的单点登录方法、系统和负载均衡设备 | |
US8732815B2 (en) | System, method of authenticating information management, and computer-readable medium storing program | |
JP3937475B2 (ja) | アクセス制御システムおよびその方法 | |
CN101064729B (zh) | 通过cdn网络实现ftp下载服务的系统和方法 | |
CN102713926B (zh) | 机密信息泄露防止系统及方法 | |
CN102356620B (zh) | 网络应用访问 | |
CN101540755B (zh) | 一种修复数据的方法、系统和装置 | |
CN104811462B (zh) | 一种接入网关重定向方法及接入网关 | |
US20100154040A1 (en) | Method, apparatus and system for distributed delegation and verification | |
JP2005538434A (ja) | 連携型(フェデレーテッド)環境におけるユーザ判定による認証のための方法およびシステム | |
CN101656609A (zh) | 一种单点登录方法、系统及装置 | |
CN104052736A (zh) | 用于预签名dnssec启用区域至记录集中的系统和方法 | |
CN110519240A (zh) | 一种单点登录方法、装置及系统 | |
CN102143131A (zh) | 用户注销方法及认证服务器 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CP03 | Change of name, title or address |
Address after: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No. Patentee after: Xinhua three Technology Co., Ltd. Address before: 310053 Hangzhou hi tech Industrial Development Zone, Zhejiang province science and Technology Industrial Park, No. 310 and No. six road, HUAWEI, Hangzhou production base Patentee before: Huasan Communication Technology Co., Ltd. |
|
CP03 | Change of name, title or address |