CAS单点登录简介

news2024/11/16 7:29:08

1、传统cookie认证
通常在登录的时候，前端将用户名和密码传送给后端，然后后端将加密后的认证字符串设置成cookie，在以后的每次请求中，都会将cookie发过去，再解密校验请求者的信息，或者进行一系列的鉴权。
这种方式的缺点就是不能跨域，如果是多个应用，如果需要更改登录流程，则需更改多出代码。

2、统一认证中心
基于cookie的流程，如果我拥有多个应用，那么每个应用之间都是相互隔离的，如果来回使用，可能需要几次登录，先不说用户体验，开发体验也很不友好。
所以我们继续改造，将认证服务统一独立起来。只要判断没有登录的，都重定向到认证中心，等登录成功后再再重定向到原应用，每次校验Cookie的时候，都用认证中心的服务校验，这样自然而然就方便多了。
但是这里还是有个问题，后端认证服务统一了，但是前端好像并没有，对于多个前端应用，cookie并不能跨域，也不能在多个应用之间随便读取，如果登录过一次，再切换到另一个应用，也还是得登录。

3、CAS单点登录（Central Authentication Server）
CAS全称Central Authentication Server，也称作中央认证服务。
从结构上看，CAS 包含两个部分： CAS Server 和 CAS Client。CAS Server 需要独立部署，主要负责对用户的认证工作；CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server。
在上面的例子中，我们说的统一认证中心，负责登录的工作部分可以作为CAS Client，而后端部分可以作为CAS Server。
在请求阶段CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket，如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的 CAS Server 登录地址，并传递 Service （也就是要访问的目的资源地址），以便登录成功过后转回该地址。用户在第 3 步中输入认证信息，如果登录成功，CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket，并缓存以待将来验证，之后系统自动重定向到 Service 所在地址，并为客户端浏览器设置一个 Ticket Granted Cookie（TGC），CAS Client 在拿到 Service 和新产生的 Ticket 过后，在之后的请求中与 CAS Server 进行身份核实，以确保 Service Ticket 的合法性。
同时为了解决上述的多个应用之间的问题，我们可以利用cookie的domain属性，在子应用之间分享cookie。
Domain 指定了哪些主机可以接受 Cookie。如果不指定，默认为origin，不包含子域名。如果指定了，则一般包含子域名,可以在多个网页之间共享。Domain

认证流程：