对于单点登录,你不得不了解的CAS

开启掘金成长之旅!这是我参与「掘金日新计划 · 2 月更文挑战」的第 N 天,点击查看活动详情

大家好,我是车辙。之前我们通过面试的形式,讲了JWT实现单点登录(SSO)的设计思路,并且到最后也留下了疑问,什么是CAS

没看过的同学建议点击下方链接先看下,两者还是有一定连贯性的。

传送门:面试系列:4000字长文,让你了解单点登录(一)

寒暄开始

今天是上班的第一天,刚进公司就见到了上次的面试官,穿着格子衬衫和拖鞋,我们就叫他老余吧。老余看见我就开始勾肩搭背聊起来了,完全就是自来熟的样子,和我最近看的少年歌行里的某人很像。

什么是CAS呢

老余:上次你说到了CAS,你觉得CAS是什么?

我:之前我们面试的时候,我讲了JWT单点登录带来的问题,然后慢慢优化,最后衍变成了中心化单点登录系统,也就是CAS的方案。

CAS(Central Authentication Service),中心认证服务,就是单点登录的某种实现方案。你可以把它理解为它是一个登录中转站,通过SSO站点,既解决了Cookie跨域的问题,同时还通过SSO服务端实现了登录验证的中心化。

这里的SSO指的是:SSO系统

它的设计流程是怎样的

老余:你能不能讲下它的大致实现思路,这说的也太虚头巴脑了,简直是听君一席话,如听一席话。
我:你别急呀,先看下它的官方流程图。
对于单点登录,你不得不了解的CAS_第1张图片

重定向到SSO

首先,用户想要访问系统A的页面1,自然会调用www.chezhe1.com的限制接口,(比如说用户信息等接口登录后才能访问)。

接下来 系统A 服务端一般会在拦截器【也可以是过滤器,AOP 啥的】中根据Cookie中的SessionId判断用户是否已登录。如果未登录,则重定向到SSO系统的登录页面,并且带上自己的回调地址,便于用户在SSO系统登录成功后返回。此时回调地址是:www.sso.com?url=www.chezhe1.com

这个回调地址大家应该都不会陌生吧,像那种异步接口或者微信授权、支付都会涉及到这块内容。不是很了解的下面会解释~
另外这个回调地址还必须是前端页面地址,主要用于回调后和当前系统建立会话。

此时如下图所示:
对于单点登录,你不得不了解的CAS_第2张图片

用户登录

  1. 在重定向到SSO登录页后,需要在页面加载时调用接口,根据SessionId判断当前用户在SSO系统下是否已登录。【注意这时候已经在 SSO 系统的域名下了,也就意味着此时Cookie中的domain已经变成了sso.com

    为什么又要判断是否登录?因为在 CAS 这个方案中,只有在SSO系统中为登录状态才能表明用户已登录。
  2. 如果未登录,展现账号密码框,让用户输入后进行SSO系统的登录。登录成功后,SSO页面和SSO服务端建立起了会话。
    此时流程图如下所示:

对于单点登录,你不得不了解的CAS_第3张图片

安全验证

老余:你这里有一个很大的漏洞你发现没有?
我:emm,我当然知道。

对于中心化系统,我们一般会分发对应的AppId,然后要求每个应用设置白名单域名。所以在这里我们还得验证AppId的有效性,白名单域名和回调地址域名是否匹配。否则有些人在回调地址上写个黄色网站那不是凉凉。

image.png

获取用户信息登录

  1. 在正常的系统中用户登录后,一般需要跳转到业务界面。但是在SSO系统登录后,需要跳转到原先的系统A,这个系统A地址怎么来?还记得重定向到SSO页面时带的回调地址吗?

image.png

通过这个回调地址,我们就能很轻易的在用户登录成功后,返回到原先的业务系统。

  1. 于是用户登录成功后根据回调地址,带上ticket,重定向回系统A,重定向地址为:www.chezhe1.com?ticket=123456a
  2. 接着根据ticket,从SSO服务端中获取Token。在此过程中,需要对ticket进行验证。
  3. 根据tokenSSO服务端中获取用户信息。在此过程中,需要对token进行验证。
  4. 获取用户信息后进行登录,至此系统A页面和系统A服务端建立起了会话,登录成功。

此时流程图如下所示:

对于单点登录,你不得不了解的CAS_第4张图片

别以为这么快就结束了哦,我这边提出几个问题,只有把这些想明白了,才算是真的清楚了。

  • 为什么需要 Ticket?
  • 验证 Ticket 需要验证哪些内容?
  • 为什么需要 Token?
  • 验证 Token 需要验证哪些内容?
  • 如果没有Token,我直接通过Ticket 获取用户信息是否可行?

为什么需要 Ticket

我们可以反着想,如果没有Ticket,我们该用哪种方式获取Token或者说用户信息?你又该怎么证明你已经登录成功?用Cookie吗,明显是不行的。

所以说,Ticket是一个凭证,是当前用户登录成功后的产物。没了它,你证明不了你自己。

验证 Ticket 需要验证哪些内容

  1. 签名:对于这种中心化系统,为了安全,绝大数接口请求都会有着验签机制,也就是验证这个数据是否被篡改。至于验签的具体实现,五花八门都有。
  2. 真实性:验签成功后拿到Ticket,需要验证Ticket是否是真实存在的,不能说随便造一个我就给你返回Token吧。
  3. 使用次数:为了安全性,Ticket只能使用一次,否则就报错,因为Ticket很多情况下是拼接在URL上的,肉眼可见。
  4. 有效期:另外则是Ticket的时效,超过一定时间内,这个Ticket会过期。比如微信授权的Code只有5分钟的有效期。
  5. ......

    为什么需要 Token?

    只有通过Token我们才能从SSO系统中获取用户信息,但是为什么需要Token呢?我直接通过Ticket获取用户信息不行吗?

答案当然是不行的,首先为了保证安全性Ticket只能使用一次,另外Ticket具有时效性。但这与某些系统的业务存在一定冲突。因此通过使用Token增加有效时间,同时保证重复使用。

验证 Token 需要验证哪些内容?

和验证 Ticket类似

  1. 签名 2. 真实性 3. 有效期

如果没有 Token,我直接通过 Ticket 获取用户信息是否可行?

这个内容其实上面已经给出答案了,从实现上是可行的,从设计上不应该,因为TicketToken的职责不一样,Ticket 是登录成功的票据,Token是获取用户信息的票据。

用户登录系统B流程

老余:系统A登录成功后,那系统B的流程呢?
我:那就更简单了。

比如说此时用户想要访问系统B,www.chezhe2.com的限制接口,系统B服务端一般会在拦截器【也可以是过滤器,AOP 啥的】中根据Cookie中的SessionId判断用户是否已登录。此时在系统B中该系统肯定未登录,于是重定向到SSO系统的登录页面,并且带上自己的回调地址,便于用户在SSO系统登录成功后返回。回调地址是:www.sso.com?url=www.chezhe2.com。

我们知道之前SSO页面已经与SSO服务端建立了会话,并且因为CookieSSO这个域名下是共享的,所以此时SSO系统会判断当前用户已登录。然后就是之前的那一套逻辑了。
此时流程图如下所示:

对于单点登录,你不得不了解的CAS_第5张图片

技术以外的事

老余:不错不错,理解的还可以。你发现这套系统里,做的最多的是什么,有什么技术之外的感悟没。说到这,老余叹了口气。

我:我懂,做的最多的就是验证了,验证真实性、有效性、白名单这些。明明一件很简单的事,最后搞的那么复杂。像现在银行里取钱一样,各种条条框框的限制。我有时候会在想,技术发展、思想变革对于人类文明毋庸置疑是有益的,但是对于我们人类真的是一件好事吗?如果我们人类全是机器人那样的思维是不是会更好点?

老余:我就随便一提,你咋巴拉巴拉了这么多。我只清楚一点,拥有七情六欲的人总是好过没有情感的机器人的。好了,干活去吧。

总结

这一篇内容就到这了,我们聊了下关于单点登录的 CAS 设计思路,其实CAS 往大了讲还能讲很多,可惜我的技术储备还不够,以后有机会补充。如果想理解的更深刻,也可以去看下微信授权流程,应该会有帮助。

最后还顺便提了点技术之外的事,记得有句话叫做:科学的尽头是哲学,我好像开始慢慢理解这句话的意思了。

如果这篇文章对您有所帮助,可以关注我的公众号《车辙的编程学习圈》,也可以在我的博客网站扫码关注我的博客网站

我是车辙,掘金小册《SkyWalking》作者,一名常被HR调侃为XX杨洋的互联网打工人

你可能感兴趣的:(后端)