CAS单点登录
一、单系统登陆机制
-
http无状态协议
web应用采用==browser/server==架构，http作为通信协议。http是无状态的，浏览器的每一次请求，服务器会独立处理，不与之前或之后的请求产生关联。
但是这也意味着任何用户都可以通过浏览器访问服务器资源，如果想保护浏览器资源，就必须限制浏览器请求；就需要鉴别浏览器请求，响应合法请求。==既然http是无状态的，那就让服务器和浏览器共同维护一个状态，这就是会话机制==。
-
会话机制
浏览器第一次请求服务器，服务器会创建一个会话，并将会话id作为相应的一部分发送给浏览器，浏览器会存储会话id，并在后续第二次和第三次请求中带上会话id，服务器取得请求中的会话id就知道是不是同一个用户了。
浏览器可以通过 1、请求参数 2、cookie保存会话id。
二、单点登录(Single Sign-On)
SSO体系中的主要的三部分
- User （多个）
- Web应用（多个）
- SSO认证中心（1个）
SSO实现基本核心原则
- 所有的登陆都在SSO认证中心进行
- SSO认证中心通过一些方法告诉Web应用当前访问用户究竟是不是已通过认证的用户
- SSO认证中心和所有的Web应用建立一种信任关系，SSO认证中心对用户身份正确行的判断会通过某种方法告知Web应用，而且判断结果必须被Web应用信任
1、登陆
通过认证中心简介授权令牌来实现，当SSO验证了用户信息的正确性后，就会创建授权令牌，在接下来的跳转过程中，授权令牌作为参数发送给各个子系统，子系统拿到令牌，即得到了授权，可以借此创建局部会话，局部会话登陆方式与单系统的登陆方式相同。
具体流程
- 首先用户访问系统一受保护的资源，系统一发现为登陆，跳转到SSO认证中心，并将自己的参数传递过去
- SSO认证中心发现用户未登陆，将用户引导至登陆页面
- 用户输入用户名和密码提交至SSO认证中心
- SSO认证中心校验用户信息，创建用户与SSO认证中心之间的对话，称为==全局对话==，同时==创建授权令牌==
- SSO认证中心带着令牌跳转最初的请求地址（系统一)
- 系统一拿到令牌，去SSO认证中心校验令牌是否有效
- SSO认证中心校验令牌，返回有效，注册系统一的地址
- 系统一使用该令牌创建与用户的会话，称为==局部会话==，返回用户受保护资源
- 用户访问系统二受保护的资源
- 系统二发现用户未登录，跳转到SSO认证中心，并将自己的地址作为参数传递过去
- SSO认证中心发现用户一登录，跳转回系统二的地址，并附上令牌
- 系统二拿到令牌，去SSO认证中心校验令牌是否有效
- SSO认证中心校验令牌，返回有效地址，注册系统二地址
- 系统二使用该令牌创建与用户的局部会话，返回给用户受保护资源
用户登录成功，会与SSO认证中心及各个子系统创建会话，用户与SSO认证中心的会话称为全局会话，用户与各个子系统的会话称为局部会话，局部会话建立后，用户访问子系统受保护资源不再通过SSO认证中心
- 局部会话存在，全局会话一定存在
- 全局会话存在，局部会话不一定存在
- 全局会话销毁，局部会话必须销毁
2、注销
- 用户向系统一发起注销请求
- 系统一根据用户与系统一建立的会话id拿到令牌，向SSO认证中心发起注销请求
- SSO认证中心校验令牌有效，销毁全局会话，同时去除所有用此令牌注册的系统地址
- SSO认证中心向所有注册系统发起注销请求
- 各注册系统接收SSO认证中心的注销请求，销毁局部会话
- SSO认证中心引导用户至登陆页面
三、CAS基本原理
1、结构体系
CAS Server： 负责完成对用户的认证工作，需要独立部署，处理用户名/密码等凭证
CAS Client： 负责处理对客户端受保护资源的访问请求，需要对请求方进行身份验证，重定向到CAS Server进 行认证（原则上客户端应用不再接收任何的用户名密码等）
2、CAS协议
CAS协议是一个简单而强大的==基于票据的协议==，涉及一个或多个客户端和一台服务器。即在CAS中，通TGT（Ticket Granting Ticket）来获取ST（Server Ticket） ，通过ST来访问具体的服务
在SSO中的令牌也就是CAS中的ST。
3、具体流程
首先用户访问受保护的资源，权限没有认证，所以会把请求的URL以参数跳转到CAS认证中心，CAS认证中心发现没有SSO session，所以弹出登录页面，输入用户信息，提交到CAS认证中心进行信息的认证，如果信息正确，==CAS认证中心就会创建一个SSO session和CAS TGC （cookie）==，这个==CASTGC cookie包含了TGT==，而==用户session则以TGT为key创建==，同时服务端会分发一个ST返回给用户。用户拿到了ST后，访问带参数ST的资源地址，同时应用将ST发送给CAS认证中心，CAS认证中心对ST进行校验，同时判断相应的cookie（包含TGT）是否正确（通过先前设定的key），判断ST是否是有效的，结果会返回一个包含成功信息的XML给应用。应用在建立相应的session和cookie跳转到浏览器，用户再通过浏览器带cookie去应用访问受保护的资源地址，cookie和后端session验证成功便可以成功访问到信息。
第二次访问应用时，浏览器就会携带相应的cookie信息，后台session验证用户是否登录，与一般单系统应用登录模式一样。
当我们访问其他的应用，与前面的步骤也是基本相同，首先用户访问受保护的资源，跳转回浏览器，==浏览器含有先前登录的CASTGC cookie==，CASTGC cookie包含了TGT并发送到CAS认证中心，CAS认证中心校验TGT是否有效，如果有效分发浏览器一个带ST参数的资源地址URL，应用程序拿到ST后，再发送给CAS认证中心，如果认证了ST有效后，结果会返回一个包含成功信息的XML给应用。同样的步骤，应用在建立相应的session和cookie跳转到浏览器，用户再通过浏览器带cookie去应用访问受保护的资源地址，验证session成功便可以成功访问到信息。
4、术语概念
TGC（ticket-granting cookie）：
授权的票据证明，由CAS Server通过SSL方式发送给终端用户，存放用户的身份凭证的Cookie，在浏览器和CAS Server间通讯时使用，并且只能基于安全通道传输（Https），是CAS Server用来明确用户身份的凭证
TGT（Ticket Grangting Ticket）
TGT是CAS为用户签发的登陆票据，拥有了TGT，用户就可以证明自己砸CAS成功登陆过，TGT封装了Cookie值对应的用户信息。用户在CAS认证成功后，CAS生成TGC，写入浏览器，同时生成一个TGT对象，放入自己的缓存，TGT对象的ID就是Cookie的值。当http请求到来时，如果传过来的有CAS生成的Cookie，则CAS以此Cookie值为keu查询缓存中有无TGT，如果有的话 ，则说明用户之前登陆过，如果没有，则用户需要重新登录。
ST（Service Ticket）
ST是CAS为用户签发的访问某一Service的票据。用户访问Service时，Service发现用户没有ST，则要求用户去CAS获取ST。用户向CAS发送获取ST请求，如果请求包含cookie，则CAS会以此cookie值为key查询缓存总有无TGT，如果存在TGT，则用ciTGT签发一个ST，返回给用户。用户凭借ST访问Service，service拿ST去CAS验证，验证通过后，允许用户访问资源。
