单点登录的实现方式对比

分类:前端来源:站内 最近更新:2021-06-15 15:38:55浏览:1741留言:2

单点登录的实现方式对比

概览

单点登录英文全称Single Sign On(SSO)。它的解释是:在多个应用系统中,只需要登录一次,就可以访问其他相互信任的应用系统。是比较流行的企业业务整合的解决方案之一。

背景

在企业发展初期,企业使用的系统很少,通常一个或者两个,每个系统都有自己的登录模块,运营人员每天用自己的账号登录,很方便。但随着企业的发展,用到的系统随之增多,运营人员在操作不同的系统时,需要多次登录,而且每个系统的账号都不一样,这对于运营人员来说,很不方便。于是,就想到是不是可以在一个系统登录,其他系统就不用登录了呢?这就是单点登录要解决的问题。

20210615151802.jpg

分析

在分析单点登录之前,先回顾登录一个系统是如何实现的。在最早期,前后端未分离的项目中,都是客户端登录,把用户名密码给后端,后端验证正确,存储session会话。然后就可以进入系统了。

1623741643562769139.jpg

前后端分离之后,前端请求后端接口,后端生成一个和账号关联的token签,返回给前端,前端下次请求接口时带上token签就能得到数据

1623741705523928107.jpg

单点实现方式

1.把多个系统合并到一个系统里,即统一的域名(只是实现了效果,严格上不是单点登录)

       www.a.com/xt1,    www.a.com/xt2

        方式一:通过二级目录区分不同的系统,通过Nginx拦截二级目录代理到对应的系统里

        方式二:通过微前端架构方式把多个系统合并到一个系统里

        优点:最简单方式,通过Nginx配置就行

        缺点:只能在一个域名下,通过二级目录区分,对域名和目录挑剔的应用不适用


  2.顶级域名一致,通过设置Cookies的domain为顶级域名就可以保障所有同一个域下的系统单点登录了

        如:app1.a.com   app2.a.com   app3.a.com 设置这些域名的domain为.a.com就行

        优点:适用于大部分公司。满足不同域名不同系统

        缺点:本地测试时需要绑定a.com域名下的host。如果需要换顶级域名,就是灾难,要更改所有系统


 3.所有系统内嵌一个通用的iframe页面。然后通过iframe中possMesage方法把登录cookies告诉父级页面。

1623741833282848268.jpg

        优点:适合不同域名下的系统

        缺点:oss页面路径更新后,所有系统要更新。对老版本浏览器不支持。

    4.标准的单点登录是CAS流程了

image.png

这个图示通用的CAS流程图。自行百度研究了。可以简化了一个流程图

image2.png

第一次访问www.qiandu.com

标号1:用户访问http://www.qiandu.com,经过他的第一个过滤器(cas提供,在web.xml中配置)AuthenticationFilter。

      过滤器全称:org.jasig.cas.client.authentication.AuthenticationFilter

      主要作用:判断是否登录,如果没有登录则重定向到认证中心。

标号2:www.qiandu.com发现用户没有登录,则返回浏览器重定向地址。  

1623742086884369347.jpg

        首先可以看到我们请求www.qiandu.com,之后浏览器返回状态码302,然后让浏览器重定向到cas.qiandu.com并且通过get的方式添加参数service,该参数目的是登录成功之后会要重定向回来,因此需要该参数。并且你会发现,其实server的值就是编码之后的我们请求www.qiandu.com的地址。

标号3:浏览器接收到重定向之后发起重定向,请求cas.qiandu.com。

标号4:认证中心cas.qiandu.com接收到登录请求,返回登陆页面。

1623742146819793804.jpg

  上图就是标号3的请求,以及标号4的响应。请求的URL是标号2返回的URL。之后认证中心就展示登录的页面,等待用户输入用户名密码。

标号5:用户在cas.qiandu.com的login页面输入用户名密码,提交。

标号6:服务器接收到用户名密码,则验证是否有效,验证逻辑可以使用cas-server提供现成的,也可以自己实现。

 1623742197070324403.jpg

        上图就是标号5的请求,以及标号6的响应了。当cas.qiandu.com即csa-server认证通过之后,会返回给浏览器302,重定向的地址就是Referer中的service参数对应的值。后边并通过get的方式挟带了一个ticket令牌,这个ticket就是ST(数字3处)。同时会在Cookie中设置一个CASTGC,该cookie是网站cas.qiandu.com的cookie,只有访问这个网站才会携带这个cookie过去。

         Cookie中的CASTGC:向cookie中添加该值的目的是当下次访问cas.qiandu.com时,浏览器将Cookie中的TGC携带到服务器,服务器根据这个TGC,查找与之对应的TGT。从而判断用户是否登录过了,是否需要展示登录页面。TGT与TGC的关系就像SESSION与Cookie中SESSIONID的关系。

      TGT:Ticket Granted Ticket(俗称大令牌,或者说票根,他可以签发ST)

      TGC:Ticket Granted Cookie(cookie中的value),存在Cookie中,根据他可以找到TGT。

      ST:Service Ticket (小令牌),是TGT生成的,默认是用一次就生效了。也就是上面数字3处的ticket值。

标号7:浏览器从cas.qiandu.com哪里拿到ticket之后,就根据指示重定向到www.qiandu.com,请求的url就是上面返回的url。

1623742269445625366.jpg

标号8:www.qiandu.com在过滤器中会取到ticket的值,然后通过http方式调用cas.qiandu.com验证该ticket是否是有效的。

标号9:cas.qiandu.com接收到ticket之后,验证,验证通过返回结果告诉www.qiandu.com该ticket有效。

标号10:www.qiandu.com接收到cas-server的返回,知道了用户合法,展示相关资源到用户浏览器上。

1623742318707663393.jpg

4.2、第二次访问www.qiandu.com

上面以及访问过一次了,当第二次访问的时候发生了什么呢?

标号11:用户发起请求,访问www.qiandu.com。会经过cas-client,也就是过滤器,因为第一次访问成功之后www.qiandu.com中会在session中记录用户信息,因此这里直接就通过了,不用验证了。

标号12:用户通过权限验证,浏览器返回正常资源。

 

4.3、访问mail.qiandu.com

标号13:用户在www.qiandu.com正常上网,突然想访问mail.qiandu.com,于是发起访问mail.qiandu.com的请求。

标号14:mail.qiandu.com接收到请求,发现第一次访问,于是给他一个重定向的地址,让他去找认证中心登录。

     1623742399505632337.jpg

      上图可以看到,用户请求mail.qiandu.com,然后返回给他一个网址,状态302重定向,service参数就是回来的地址。

标号15:浏览器根据14返回的地址,发起重定向,因为之前访问过一次了,因此这次会携带上次返回的Cookie:TGC到认证中心。

标号16:认证中心收到请求,发现TGC对应了一个TGT,于是用TGT签发一个ST,并且返回给浏览器,让他重定向到mail.qiandu.com

1623742463188285237.jpg

  可以发现请求的时候是携带Cookie:CASTGC的,响应的就是一个地址加上TGT签发的ST也就是ticket。

标号17:浏览器根据16返回的网址发起重定向。

标号18:mail.qiandu.com获取ticket去认证中心验证是否有效。

标号19:认证成功,返回在mail.qiandu.com的session中设置登录状态,下次就直接登录。

标号20:认证成功之后就反正用想要访问的资源了。

缺点:这个是标准的CAS流程。但是不适用与前后端分离的架构方式

    5.前后端分离下的CAS流程

1623742636946338378.jpg

优点:适合不同域名下的系统

缺点:token明文传输,不能保障一个浏览器登录一个账号(token被串改,如果要避免如何做……可以不直接传token,可以用临时一次性的ST去换取token)


总结

CAS流程是标准的单点登录逻辑,但是在目前前后端分离流行的今天,都是采用JWT的方式,由前端存放token,请求接口时带上token。采用顶级域的方式最可采用。


1

发表评论

评论列表(2)

  • 匿名
    前后端分离,前端页面有CDN缓存。只能通过前端来判断,是否登陆吧?
    2022-04-06 22:47:20
    回复 0
  • 管理员
    回复 匿名的话:"前后端分离,前端页面有CDN缓存。只能通过前端来判断,是否登陆吧?"
    这个要看业务场景,前后端分离性下,建议前端判断登录。前端可以用 localStorage存储token签判断,简单仿版。如果需求有会话过期时间的判断,这个时候可以在请求登录接口后,让后端设置前端的cookies。后面的token签后端自己去抓cookies就行,当然这边要控制好跨域
    2022-05-13 10:02:17
    回复 0
共 2 条留言

热门