电商系统中单点登录的原理和架构设计详解

SSO系统产生背景在单Web应用系统中,我们只需要考虑客户端与该服务器的单一会话即可,实现起来也比较容易,只需要登录成功后写入cookie,所以每次请求该 Web应用都会携带cookie,服务器端只考虑验证这个cookie是否有效即可判断是否登录。随着业务增长,出现了系统协同工作,那么每个应用只维持自己的会话会出现如下问题。1.每个系统都要维护一套认证逻辑,造成冗余;2.跨系统之后,认证信息失效,需要各个系统之间兼容

那么,就需要将公共模块抽象出来,组成一个通用的认证系统,承担起所有业务系统的登录认证功能,也就是我们所说的SSO系统,如下图所示

那么,就需要将公共模块抽象出来,组成一个通用的认证系统,承担起所有业务系统的登录认证功能,也就是我们所说的SSO系统,如下图所示。一般的SSO系统模型如上图所示,抽象出认证系统之后,单点登录系统需要完成两个主要工作,全局会话的保持和局部会话的保持。客户端与业务系统之间是局部会话,与SSO系统之间是全局会话

我们会将SSO系统分为两部分,SSO服务端和SSO客户端,SSO服务端则是我们的SSO认证系统,SSO客户端将集成进入业务系统,负责局部会话的新增、删除、验证。如上图所示,抽象出认证系统之后,单点登录系统需要完成两个主要工作,全局会话的保持和局部会话的保持。客户端与业务系统之间是局部会话,与SSO系统之间是全局会话。我们会将SSO系统分为两部分,SSO服务端和SSO客户端,SSO服务端则是我们的SSO认证系统,SSO客户端将集成进入业务系统,负责局部会话的新增、删除、验证。开源框架CAS的原理CAS太过经典,所以基本上所有的SSO系统,所会对CAS有所借鉴。上图展示了CAS的整体架构,同样分为客户端和服务端

客户端支持多种服务器应用,同时也支持多语言,包括GO、Python、PHP、Java、.NET,可以看到对市面上的主要语言都有支持。主要是从事Java开发,本文只会着重说一下Java的实现,如果读者有兴趣,可以去查看其他语言的实现。可以从图中看出服务端的技术实现,首先是 SpringMVC+SpringWebFlow,WebFlow主要用于将组件串行执行,往下是票据组件、认证组件、认证组件支持的存储容器,可以是LDAP、数据库、活动目录,我们基本上的认证思路就是关系数据库+Redis或Memcached来配合实现

下面我将简要说一下整体的认证流程。上图主要通过三种情况,详细描述了CAS的认证过程

上图主要通过三种情况,详细描述了CAS的认证过程

1.首次访问受限资源时小鹏汽车小鹏P7诚邀试驾预约试驾预约试驾广告首次访问时,重定向到SSO服务端登录页,返回登录表单给浏览器,用户提交用户名密码,SSO服务端验证,成功后携带ticket重定向会SSO客户端,客户端与SSO验证ticket有效性,返回验证信息,SSO客户端写局部会话cookie,重定向回原地址,业务系统返回资源

如下图所示客户端关键代码如下:finalAssertionassertion=session!=null?(Assertion)session.getAttribute(CONST_CAS_ASSERTION):null;if(assertion!=null){filterChain.doFilter(request,response);return;}finalStringserviceUrl=constructServiceUrl(request,response);finalStringticket=CommonUtils.safeGetParameter(request,getArtifactParameterName());finalbooleanwasGatewayed=this.gatewayStorage.hasGatewayedAlready(request,serviceUrl);if(CommonUtils.isNotBlank(ticket)||wasGatewayed){filterChain.doFilter(request,response);return;}finalAssertionassertion=session!=null?(Assertion)session.getAttribute(CONST_CAS_ASSERTION):null;if(assertion!=null){filterChain.doFilter(request,response);return;}finalStringserviceUrl=constructServiceUrl(request,response);finalStringticket=CommonUtils.safeGetParameter(request,getArtifactParameterName());finalbooleanwasGatewayed=this.gatewayStorage.hasGatewayedAlready(request,serviceUrl);if(CommonUtils.isNotBlank(ticket)||wasGatewayed){filterChain.doFilter(request,response);return;}如果登录,直接跳转,即执行:response.sendRedirect(urlToRedirectTo);2.第二次访问该系统

response.sendRedirect(urlToRedirectTo);2.第二次访问该系统

第二次访问该系统,会在该域名下存在上一步写的cookie,请求该系统时携带cookie,所有filter不会拦截该请求,直接返回资源

如下图所示。3.首次访问其他系统

快手极速版边看视频边赚钱!下载应用下载应用视频广告在该系统域名下是不存在局部会话的,所以重定向到SSO服务端,SSO服务端会发现此客户端已经登录,所有生成ticket,客户端与SSO验证ticket有效性,返回验证信息,SSO客户端写局部会话cookie,重定向回原地址,业务系统返回资源。分享淘宝SSO系统架构设计以及实现淘宝的SSO系统是比较有新意的,除了校验登录状态模块,还加入了同步登录状态模块,这样就让电商项目在SSO中变得很灵活了

淘宝的SSO系统是比较有新意的,除了校验登录状态模块,还加入了同步登录状态模块,这样就让电商项目在SSO中变得很灵活了

第一步,同步登录状态。在静态页中,会异步请求后台数据,这时候会被同步登录状态的SSO客户端filter拦截。如果需要同步登录状态,filter将重定向到login.taobao.jump接口,这个接口无论用户是否登录,都会重定向回SSO客户端的接口,在以下两个条件下发生跳转:1.局部会话的cookie不存在;2.cookie存在但是无效,全局会话有效。所以,只会发生一次跳转,不会重复。中间的跳转除了携带token参数还会携带来源地址rederecturl

第二步,校验登录状态

第二步,校验登录状态。当用户请求到需要登录的数据资源时会被校验登录状态的filter拦截,出现以下两种情况:1.同步跳转请求,如果没有登录,直接重定向到登录页;2.异步Ajax请求,会直接返回登录状态和rederecturl、loginurl,由JavaScript控制跳转到登录地址。第三步,验证票据。如果SSO服务端登录成功,会携带token请求回SSO客户端,客户端验证token的filter拦截请求,与SSO服务端验证token有效性。如果通过,则返回用户基本信息、cookie值等,所有的cookie值都是由SSO服务端发出的。如果SSO服务端登录成功,会携带token请求回SSO客户端,客户端验证token的filter拦截请求,与SSO服务端验证token有效性。如果通过,则返回用户基本信息、cookie值等,所有的cookie值都是由SSO服务端发出的。作者:佚名

本站所有内容及资料文件均为网友自行上传,若侵犯了您的权益,请留言告知,我们会第一时间删除
erp系统hub网-专注于打造部署erp系统方案 » 电商系统中单点登录的原理和架构设计详解