1、背景介绍
单点登录： Single Sign On，简称SSO、SSO允许用户在多个APP系统中通过一次登录访问所有相互信任的APP应用系统。
CAS框架：中央身份验证服务(CAS )是用于实现SSO单点登录的框架。
2、学习CAS大部分都是窃取看过的图，进行部分分析
注：因为已经分不清原件了，所以这里不给出地址。
在结构上，CAS包括两个部分。 cas服务器和cas客户端必须独立部署，主要负责用户身份验证。 客户端访问受保护资源的请求由客户端处理。 如果需要登录，请重定向至CAS服务器。
图1是CAS最基本的协议过程。
CAS Client与受保护的客户端APP应用程序一起部署，以使用过滤器保护Web APP应用程序的受保护资源，并过滤来自客户端的所有web请求。 CAS Client还会分析HTTP请求是否包含Service Ticket (上图中的Ticket )，如果没有，则表示未通过身份验证
Step3是在用户验证过程中，如果用户提供了正确的Credentials，CAS Server将生成随机的Service Ticket，然后缓存该Service Ticket并将用户发送到CAS Client (刚才生成的server ServiceTicket不能伪造。 最后，Step 5和Step6在CAS Client和CASServer之间完成了用户身份验证，并在Ticket上检查了用户名称。 因为Ticket是由CASServer生成的，所以CASServer的判断是
该协议完成简单的任务，与CAS的交互均采用SSL协议，确保ST和TGC的安全。 协议的工作步骤2有此重定向步骤，但CAS
在客户端和cas服务器之间进行ticket验证的过程对用户是透明的。
总结如下。
访问服务： SSO客户端请求访问APP应用提供的服务资源。
定向认证： SSO客户端将用户请求重定向到SSO服务器。
用户认证：用户认证。
票证发行： SSO服务器生成随机的服务标签。
票据验证： SSO服务器验证票据服务Ticket的有效性，在验证通过后，客户端可以访问该服务。
用户信息的转发： SSO服务器验证票据的有效性后，将用户认证结果信息转发到客户端。
二.在云中进一步探索和探索
1、传递登录信息
用户首次登录时的过程如下。
1 )用户浏览器访问系统a需要登录受限资源，此时进行登录检查，发现未登录后进行获取单据的操作，发现没有单据。
2 )、系统a发现该请求需要注册，将请求重定向至认证中心，并获得全局权证操作，否则进行注册。
3 )认证中心显示登录页面，用户登录并登录成功后，认证中心将请求重定向至系统a并附上认证路径令牌。 此时，认证中心同时生成全局票据。
4 )、此时再次进行登录检查，发现未登录后，再次进行获取票证的操作。 然后，系统a可获得票据(令牌)，并与认证中心通信以验证该令牌是有效的并证明用户已登录。
5 )系统a向用户返回有限资源。
登录的用户第一次访问APP应用程序组中的系统b时：
1 )要访问另一个APP应用程序b，浏览器必须登录到有限的资源。 此时，进行登录检查，发现没有登录后，进行获取票证的操作，发现没有票证。
2 )、系统b发现该请求需要登录，将请求重定向至认证中心，获得全局权证操纵，获得并获得全局权证，认证中心发现已登录。
3 )认证中心发行临时票据(令牌)，携带该令牌重定向到系统b。
4 )、此时再次进行登录检查，发现未登录后，再次进行获取票证的操作。 该票据(令牌)可在其中获得，系统b可与认证中心通信，以验证该令牌是有效的，并证明用户已经登录。
5 )、系统b向客户端返回有限资源。
2、登录状态判断
当用户登录认证中心时，在用户和认证中心之间建立了一个会话，该会话称为全局会话。 当用户随后访问系统APP时，无法确定每次APP请求时是否都要去验证中心登录。 这是非常低效的。 在单web APP中也不需要考虑这一点。
您可以在系统APP应用程序和用户浏览器之间建立本地会话。 本地会话必须保持客户端及其系统APP会话的登录状态，并且本地会话依赖于全局会话而存在，全局会话必须消失，本地会话必须消失。
当用户访问APP应用程序时，首先确定本地会话是否存在，如果存在，则认为用户已登录，而无需前往验证中心进行确定。 如果没有，则重定向至认证中心以确定是否存在全局会话，如果存在，则当通知APP会话时，APP会话和客户端建立它们之间的本地会话，然后请求认证中心下次APP会话
验证了。3、登出
用户在一个系统登出了，访问其它子系统，也应该是登出状态。要想做到这一点，应用除结束本地局部会话外，还应该通知认证中心该用户登出。
认证中心接到登出通知，即可结束全局会话，同时需要通知所有已建立局部会话的子系统，将它们的局部会话销毁。这样，用户访问其它应用时，都显示已登出状态。
整个登出流程如下：
1)、客户端向应用A发送登出Logout请求。
2)、应用A取消本地会话，同时通知认证中心，用户已登出。
3)、应用A返回客户端登出请求。
4)、认证中心通知所有用户登录访问的应用，用户已登出。
三、拨开云雾见青天
1、对上面所有标红疑问一一解释
1)、问：系统A是如何发现该请求需要登录重定向到认证中心的？
答：用户通过浏览器地址栏访问系统A，系统A(也可以称为CAS客户端)去Cookie中拿JSESSION，即在Cookie中维护的当前回话session的id，如果拿到了，说明用户已经登录，如果未拿到，说明用户未登录。
2)、问：系统A重定向到认证中心，发送了什么信息或者地址变成了什么？
答：假如系统A的地址为http://a:8080/，CAS认证中心的服务地址为http://cas.server:8080/，那么重点向前后地址变化为：http://a:8080/->http://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,保存在用户浏览器上。
用户发送登录系统B的请求，首先会去Cookie中拿JSESSION，因为系统B并未登录过，session会话还未创建，JSESSION的值是拿不到的，然后将请求重定向到CAS认证中心，CAS认证中心先去用户浏览器中拿TGC的值，也就是全局会话id，如果存在则代表用户在认证中心已经登录，附带上认证令牌重定向到系统B。
上面登录状态判断也是这个逻辑。
6)、问：登出的过程，各个系统对当前用户都做了什么？
答：认证中心清除当前用户的全局会话TGT，同时清掉cookie中TGT的id：TGC； 然后是各个客户端系统，比如系统A、系统B，清除局部会话session，同时清掉cookie中session会话id：jsession
2、对系统A登录流程图添加注释，查看