一、什么是单点登录？

单点登录SSO（Single Sign On）说得简单点就是在一个多系统共存的环境下，用户在一处登录后，就不用在其他系统中登录，也就是用户的一次登录能得到其他所有系统的信任。单点登录在大型网站里使用得非常频繁，例如像阿里巴巴这样的网站，在网站的背后是成百上千的子系统，用户一次操作或交易可能涉及到几十个子系统的协作，如果每个子系统都需要用户认证，不仅用户会疯掉，各子系统也会为这种重复认证授权的逻辑搞疯掉。

二、何谓CAS

CAS（Central Authentication Service）是耶鲁大学的一个开源项目，旨在为web应用系统提供一种可靠的单点登录解决方案。采用CAS最大的是从安全性角度来考虑的，用户在CAS录入用户名和密码之后通过ticket进行认证，不会在网上传输密码，保证安全性。

三、CAS中的关键词理解

ST（Service Ticket）：服务票据，服务的唯一标识码，由TGT生成ST，返回给用户，接着拿着生成 的ST去访问service，service又会把ST拿到CAS系统去验证，验证通过后才允许用户访问该资源。

TGC（ Ticket Granting Cookie）：CAS系统用来识别用户身份的凭证。

TGT（Ticket Grangting Ticket）：授权票据，获取这TGT之后才能申请服务票据（ST），用户如果在CAS系统认证成功之后，就会生成TGC写入浏览器，同时也生成一个TGT，TGT对象的id就是cookie值。之后每次请求过来通过此cookie来从缓存获取TGT，就不用提交身份认证信息（Credentials）。

Session：各个应用系统会创建自己的session表示是否登录，而这里的每个session都是ST验证通过之后组装生成的。

四 、基础模式

SSO访问流程主要有以下步骤：

用户首次登录时流程如下：

1)、用户浏览器访问系统A需登录受限资源，此时进行登录检查，发现未登录，然后进行获取票据操作，发现没有票据。

2)、系统A发现该请求需要登录，将请求重定向到认证中心，获取全局票据操作，没有，进行登录。

3)、认证中心呈现登录页面，用户登录，登录成功后，认证中心重定向请求到系统A，并附上认证通过令牌，此时认证中心同时生成了全局票据。

4)、此时再次进行登录检查，发现未登录，然后再次获取票据操作，此时可以获得票据(令牌)，系统A与认证中心通信，验证令牌有效,证明用户已登录。

5)、系统A将受限资源返给用户。

已登录用户首次访问应用群中系统B时：

1)、浏览器访问另一应用B需登录受限资源，此时进行登录检查，发现未登录，然后进行获取票据操作，发现没有票据。

2)、系统B发现该请求需要登录，将请求重定向到认证中心，获取全局票据操作，获取全局票据，可以获得，认证中心发现已经登录。

3)、认证中心发放临时票据(令牌)，并携带该令牌重定向到系统B。

4)、此时再次进行登录检查，发现未登录，然后再次获取票据操作，此时可以获得票据(令牌)，系统B与认证中心通信，验证令牌有效,证明用户已登录。

5)、系统B将受限资源返回给客户端。

五、cas登出流程

用户发起登出请求动作

APP将登出请求转发到CAS Server的logou接口

CAS server接受请求后，会检测用户的TGC Cookie是否存在，如果存在即销毁该用户对应的TGT和CAS服务器的session信息。

CAS Server根据登录过的ServerURL向APP发出登出请求。

APP LogOut Filter会解析这个参数，取得sessionId，根据这个Id取得session后，把session删除，将session中的Service Ticket清除掉。

六、辅助说明

CAS的SSO实现方式可简化理解为：1个Cookie和N个Session。CAS Server创建cookie，在所有应用认证时使用，各应用通过创建各自的Session来标识用户是否已登录。

用户在一个应用验证通过后，以后用户在同一浏览器里访问此应用时，客户端应用中的过滤器会在session里读取到用户信息，所以就不会去CAS Server认证。如果在此浏览器里访问别的web应用时，客户端应用中的过滤器在session里读取不到用户信息，就会去CAS Server的login接口认证，但这时CAS Server会读取到浏览器传来的cookie（TGC），所以CAS Server不会要求用户去登录页面登录，只是会根据service参数生成一个Ticket，然后再和web应用做一个验证ticket的交互而已。

七、对问题的统一回答

1)、问：系统A是如何发现该请求需要登录重定向到认证中心的？

答：用户通过浏览器地址栏访问系统A，系统A(也可以称为CAS客户端)去Cookie中拿JSESSION，即在Cookie中维护的当前回话session的id，如果拿到了，说明用户已经登录，如果未拿到，说明用户未登录。

2)、问：系统A重定向到认证中心，发送了什么信息或者地址变成了什么？

答：假如系统A的地址为http://a:8080/，CAS认证中心的服务地址为http://cas.server:8080/，那么重点向前后地址变化为：http://a:8080/————>ttp://cas.server:8080/?service=http://a:8080/，由此可知，重点向到认证中心，认证中心拿到了当前访问客户端的地址。

3)、问：登录成功后，认证中心重定向请求到系统A，认证通过令牌是如何附加发送给系统A的？

答：重定向之后的地址栏变成：http://a:8080/?ticket=ST-XXXX-XXX，将票据以ticket为参数名的方式通过地址栏发送给系统A

4)、问：系统A验证令牌，怎样操作证明用户登录的？

答：系统A通过地址栏获取ticket的参数值ST票据，然后从后台将ST发送给CAS server认证中心验证，验证ST有效后，CAS server返回当前用户登录的相关信息，系统A接收到返回的用户信息，并为该用户创建session会话，会话id由cookie维护，来证明其已登录。

5)、问：登录B系统，认证中心是如何判断用户已经登录的？

答：在系统A登录成功后，用户和认证中心之间建立起了全局会话，这个全局会话就是TGT(Ticket Granting Ticket)，TGT位于CAS服务器端，TGT并没有放在Session中，也就是说，CAS全局会话的实现并没有直接使用Session机制，而是利用了Cookie自己实现的，这个Cookie叫做TGC(Ticket Granting Cookie)，它存放了TGT的id,保存在用户浏览器上。

相关内容分析可以查看：《SSO CAS单点系列》之 实操！轻松玩转SSO CAS就这么简单(相识篇)

用户发送登录系统B的请求，首先会去Cookie中拿JSESSION，因为系统B并未登录过，session会话还未创建，JSESSION的值是拿不到的，然后将请求重定向到CAS认证中心，CAS认证中心先去用户浏览器中拿TGC的值，也就是全局会话id，如果存在则代表用户在认证中心已经登录，附带上认证令牌重定向到系统B。

上面登录状态判断也是这个逻辑。

6)、问：登出的过程，各个系统对当前用户都做了什么？

答：认证中心清除当前用户的全局会话TGT，同时清掉cookie中TGT的id：TGC；

然后是各个客户端系统，比如系统A、系统B，清除局部会话session，同时清掉cookie中session会话id：jsession

这篇文章先写到这里，在下一篇文章我会详细写下搭建cas服务器和客户端的步骤