ナゲッツの成長の旅を始めましょう! 今日は「ナゲッツデイリー新企画・2月アップデートチャレンジ」初参加、イベント詳細はこちら
皆さんこんにちはルートです。以前、シングル サインオン (SSO) を実装するための設計思想についてインタビュー形式でお話ししましたJWTが、最後にそれは何ですか? という質問も残しましたCAS。
まだ読んでいない学生は、下のリンクをクリックして最初に読むことをお勧めします。この 2 つはまだある程度の一貫性があります。
快楽が始まる
今日は初出勤ですが、入社したとき、前回の面接官に会いました.彼は格子縞のシャツとスリッパを着ていました.彼をLao Yuと呼びましょう. ラオ・ユーが私を見たとき、彼はフックアップしてチャットしました. それは完全になじみがあり、最近見たボーイズ・ソング・ラインの誰かに非常に似ていました.
キャスとは？
Lao Yu: 前回、それについて言及しましたがCAS、CASそれは何だと思いますか?
私：以前インタビューした際に、JWTシングルサインオンが引き起こす問題点について話し、それから徐々に最適化し、最終的に集中型シングルサインオンシステム、つまりソリューションに進化させましたCAS。
中央認証サービスである CAS (Central Authentication Service) は、シングル サインオンの特定の実装です。ログイン転送ステーションとして理解できます.SSOサイトを通じて、Cookieクロスドメインの問題を解決するだけでなく、SSOサーバーを介したログイン認証の集中化も実現します.
ここでの SSO とは、SSO システムを指します。
その設計プロセスはどのようなものですか
Lao Yu: その実現の全体的なアイデアについて話してもらえますか? これは頭が空っぽすぎます. 言わなければならないことを聞いているようなものです.
私: 心配しないで、まず公式のフローチャートを見てください。
SSO にリダイレクト
まず、システム A のページ 1 にアクセスしたい場合、ユーザーは当然、www.chezhe1.com制限されたインターフェイスを呼び出します (たとえば、ユーザー情報やその他のインターフェイスは、ログイン後にのみアクセスできます)。
接下来 系统A 服务端一般会在拦截器【也可以是过滤器，AOP 啥的】中根据Cookie中的SessionId判断用户是否已登录。如果未登录，则重定向到SSO系统的登录页面，并且带上自己的回调地址，便于用户在SSO系统登录成功后返回。此时回调地址是：www.sso.com?url=www.chezhe1.com。
这个回调地址大家应该都不会陌生吧，像那种异步接口或者微信授权、支付都会涉及到这块内容。不是很了解的下面会解释~
另外这个回调地址还必须是前端页面地址，主要用于回调后和当前系统建立会话。
此时如下图所示：
用户登录
- 在重定向到
SSO登录页后，需要在页面加载时调用接口，根据SessionId判断当前用户在SSO系统下是否已登录。【注意这时候已经在 SSO 系统的域名下了，也就意味着此时Cookie中的domain已经变成了sso.com】
为什么又要判断是否登录？因为在 CAS 这个方案中，只有在SSO系统中为登录状态才能表明用户已登录。
- 如果未登录，展现账号密码框，让用户输入后进行
SSO系统的登录。登录成功后，SSO页面和SSO服务端建立起了会话。 此时流程图如下所示：
安全验证
老余：你这里有一个很大的漏洞你发现没有？
我：emm，我当然知道。
对于中心化系统，我们一般会分发对应的AppId，然后要求每个应用设置白名单域名。所以在这里我们还得验证AppId的有效性，白名单域名和回调地址域名是否匹配。否则有些人在回调地址上写个黄色网站那不是凉凉。
获取用户信息登录
- 在正常的系统中用户登录后，一般需要跳转到业务界面。但是在
SSO系统登录后，需要跳转到原先的系统A，这个系统A地址怎么来？还记得重定向到SSO页面时带的回调地址吗？
通过这个回调地址，我们就能很轻易的在用户登录成功后，返回到原先的业务系统。
- 于是用户登录成功后根据回调地址，带上
ticket，重定向回系统A，重定向地址为：www.chezhe1.com?ticket=123456a。 - 接着根据
ticket，从SSO服务端中获取Token。在此过程中，需要对ticket进行验证。 - 根据
token从SSO服务端中获取用户信息。在此过程中，需要对token进行验证。 - 获取用户信息后进行登录，至此系统A页面和系统A服务端建立起了会话，登录成功。
此时流程图如下所示：
别以为这么快就结束了哦，我这边提出几个问题，只有把这些想明白了，才算是真的清楚了。
- 为什么需要 Ticket?
- 验证 Ticket 需要验证哪些内容？
- 为什么需要 Token?
- 验证 Token 需要验证哪些内容？
- 如果没有Token，我直接通过Ticket 获取用户信息是否可行？
为什么需要 Ticket
我们可以反着想，如果没有Ticket，我们该用哪种方式获取Token或者说用户信息？你又该怎么证明你已经登录成功？用Cookie吗，明显是不行的。
所以说，Ticket是一个凭证，是当前用户登录成功后的产物。没了它，你证明不了你自己。
验证 Ticket 需要验证哪些内容
- 签名：对于这种中心化系统，为了安全，绝大数接口请求都会有着验签机制，也就是验证这个数据是否被篡改。至于验签的具体实现，五花八门都有。
- 真实性：验签成功后拿到
Ticket，需要验证Ticket是否是真实存在的，不能说随便造一个我就给你返回Token吧。 - 使用次数：为了安全性，
Ticket只能使用一次，否则就报错，因为Ticket很多情况下是拼接在URL上的，肉眼可见。 - 有效期：另外则是
Ticket的时效，超过一定时间内，这个Ticket会过期。比如微信授权的Code只有5分钟的有效期。 - ......
为什么需要 Token?
只有通过Token我们才能从SSO系统中获取用户信息，但是为什么需要Token呢？我直接通过Ticket获取用户信息不行吗？
答案当然是不行的，首先为了保证安全性，Ticket只能使用一次，另外Ticket具有时效性。但这与某些系统的业务存在一定冲突。因此通过使用Token增加有效时间，同时保证重复使用。
验证 Token 需要验证哪些内容？
和验证 Ticket类似
- 签名 2. 真实性 3. 有效期
如果没有 Token，我直接通过 Ticket 获取用户信息是否可行？
这个内容其实上面已经给出答案了，从实现上是可行的，从设计上不应该，因为Ticket和Token的职责不一样，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服务端建立了会话，并且因为Cookie在SSO这个域名下是共享的，所以此时SSO系统会判断当前用户已登录。然后就是之前的那一套逻辑了。 此时流程图如下所示：
技术以外的事
老余：不错不错，理解的还可以。你发现这套系统里，做的最多的是什么，有什么技术之外的感悟没。说到这，老余叹了口气。
我：我懂，做的最多的就是验证了，验证真实性、有效性、白名单这些。明明一件很简单的事，最后搞的那么复杂。像现在银行里取钱一样，各种条条框框的限制。我有时候会在想，技术发展、思想变革对于人类文明毋庸置疑是有益的，但是对于我们人类真的是一件好事吗？如果我们人类全是机器人那样的思维是不是会更好点？
老余：我就随便一提，你咋巴拉巴拉了这么多。我只清楚一点，拥有七情六欲的人总是好过没有情感的机器人的。好了，干活去吧。
总结
这一篇内容就到这了，我们聊了下关于单点登录的 CAS 设计思路，其实CAS 往大了讲还能讲很多，可惜我的技术储备还不够，以后有机会补充。如果想理解的更深刻，也可以去看下微信授权流程，应该会有帮助。
最后还顺便提了点技术之外的事，记得有句话叫做：科学的尽头是哲学，我好像开始慢慢理解这句话的意思了。
この記事がお役に立てば、私の公式アカウント「Rut's Programming Learning Circle」に注目していただくか、私のブログ Web サイトのコードをスキャンして、私のブログ Web サイトをフォローしてください。
私は Che Rut です。ナゲッツの小冊子「SkyWalking」の著者であり、HR から XX Yang Yang としてしばしば嘲笑されるインターネット ワーカーです。