持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第1天，点击查看活动详情
什么是CAS
-
CAS 全称叫做中央认证服务，英文是 Central Authentication Service。
-
为什么需要用到cas
- 一般的业务系统都需要有身份认证入口，在实现方式上，可以是每个业务系统有一个单独的身份认证模块，将身份认证模块耦合于业务系统中。这种方式会因人员在职状态更新不及时、部门信息更新不准确及人员角色授权不统一等数据一致性问题影响身份认证。
- 从用户的角度来看，实现单点登录，登录了一个业务系统，再使用其他相关的业务系统不需要重新登录。从开发者的角度来看，只需要提供一个统一的身份认证服务。
CAS架构
CAS 分为两部分：
- 一个是 CAS Server，这是单点验证服务，用来校验用户名/密码等，一般来说都是独立部署。
- 另一个则是 CAS Client，相当于就是一个一个的（微）服务。
三个概念
-
TGT
- TGT 全称叫做 Ticket Granting Ticket。
- CAS Server在认证用户的身份后，生成一个TGT对象，存放在自己的缓存中。
- 这个相当于我们平时所见到的 HttpSession 的作用，用户登录成功后，用户的基本信息，如用户名、登录有效期等信息，都将存储在此。
-
TGC
- TGC 全称叫做 Ticket Granting Cookie。
- TGC 以 Cookie 的形式保存在浏览器中，访问业务系统时，携带TGC进行身份认证，根据 TGC 可以帮助用户找到对应的 TGT。
- 这个 TGC 有点类似于会话 ID。
-
ST
- ST 全称是 Service Ticket。这是 CAS Sever 通过 TGT 给用户发放的一张一次性票据。默认过期时间是10s。
- 用户在访问业务服务时，如果没有ST，会 302 到 CAS Server 获取 ST，然后会携带着 ST 302 回来，CAS Client 拿到 ST 后去 CAS Server 校验ST的合法性，CAS Server验证 ST 是合法的，将返回用户的信息给CAS Client。
CAS登录流程
第一次访问app
- 访问app：用户通过浏览器访问 app.example.com/ ，请求发送到服务app，也就是CAS Client。
- 定向认证：CAS Client 判断出请求中没有ST，返回302，携带service参数（指用户原访问页面），指示浏览器跳转到CAS Server进行身份认证。
- 用户认证：CAS Server 将界面重定向到输入身份信息的登录界面，等用户填写完身份信息并点击登录后，浏览器携带service重定向到CAS Server。
- 发放票据：CAS Server校验玩用户身份信息后，首先会生成一个TGT并存放在CAS Server中，根据这个TGT签发一个一次性的ST票据并拼接在service后，另外，将对应的TGC写入到浏览器的cookie中，返回302,指示浏览器跳转到service，如app.example.com/?ticket=xxx
- 验证票据：浏览器将TGC存储到本地，并携带ST访问原目标访问页面。CAS Client获取请求中的ST，并去CAS Server校验ST的有效性。
- 传输用户信息：如果CAS Server验证 ST 是合法的，将返回用户的信息给CAS Client。CAS client 在获取用户信息时，可以使用session--cookie的方式管理用户会话。之后访问同一个业务应用，不用再重定向到CAS Server认证。
第二次访问app
- 用户通过浏览器再次访问app.example.com/，CAS Client通过本地的session--cookie判断已经登录，直接返回请求数据。
第一次访问app2
- 访问app2：用户通过浏览器访问 app2.example.com/，请求发送到服务app… Client。
- 定向认证：CAS Client 判断出请求中没有ST，返回302，携带service参数（指用户原访问页面），指示浏览器跳转到CAS Server进行身份认证。
- 用户认证：CAS Server 根据请求中携带的TGC，找到对应的TGT，判断已经登录。根据这个TGT签发一个一次性的ST票据并拼接在service后，返回302,指示浏览器跳转到service，如app2.example.com/?ticket=xxx
- 接下去的步骤就和之前第一次访问app时一样了，验证票据成功后，传输用户信息。
