❶ CAS TGC 安全性问题
CAS 的安全性是一个非常重要的 Topic 。 CAS 从 v1 到 v3 ，都很依赖于 SSL ，它假定了这样一个事实，用户在一个非常不安全的网络环境中使用 SSO ， Hacker 的 Sniffer 会很容易抓住所有的 Http Traffic ，包括通过 Http 传送的密码甚至 Ticket 票据。
TGC/PGT 安全性
对于一个 CAS 用户来说，最重要是要保护它的 TGC ，如果 TGC 不慎被 CAS Server 以外的实体获得， Hacker 能够找到该 TGC ，然后冒充 CAS 用户访问所有授权资源。
SSO 的安全性问题比普通应用的安全性还要严重，因为 SSO 存在一种门槛效应。以前即使 Hacker 能够截获用户在 Web 应用 A 的密码，它也未必能知道用户在 Web 应用 B 的密码，但 SSO 让 Hacker 只需要截获 TGC( 突破了门槛 ) ，即能访问所有与该用户相关的所有应用系统。
PGT 跟 TGC 的角源宽册色是一样的，如果被 Hacker 获得，后果可想而知。
从基础模式可以看出， TGC 是 CAS Server 通过 SSL 方式发送给终端用户，因此，要截取 TGC 难度非常大，从而确保 CAS 的安全性。
因此，某些人认为 CAS 可以不使用 SSL 的想法需要更正一下， CAS 的传输安全性仅仅依赖与 SSL 。
跟 Kerberos 一样 TGT ， TGC 也有自己的存活周期。下面是 CAS 的 web.xml 中，通过 grantingTimeout 来巧搜设置 CAS TGC 存活周期的参数，参数默认是 120 分钟，在合适的范围内设置最小值，太短，会影响 SSO 体验，太长，会增加安全性风险。
<context-param>
<param-name>e.yale.its.tp.cas.grantingTimeout</param-name>
<param-value>7200</param-value>
</context-param>
TGC 面临的风险主要并非传输窃取。比如你登陆了之后，没有 Logout ，离开了电脑，别人就可以打开你的浏览器，直接访问你授权访问的应用 ) ，设置一个 TGC 的有效期，可以减少雹宏被别人盗用，或者被 Hacker 入侵你的电脑直接获取你系统目录下的 TGC Cookie 。
Service Ticket/Proxy Ticket 安全性
首要明白， Service Ticket 是通过 Http 传送的，以为着所网络中的其他人可以 Sniffer 到其他人的 Ticket 。
CAS 协议从几个方面让 Service Ticket 变得更加安全。
l Service Ticket 只能使用一次。
CAS 协议规定，无论 Service Ticket 验证是否成功， CAS Server 都会将服务端的缓存中清除该 Ticket ，从而可以确保一个 Service Ticket 被使用两次。
l Service Ticket 在一段时间内失效。
假设用户拿到 Service Ticket 之后，他请求 helloservice 的过程又被中断了， Service Ticket 就被空置了，事实上，此时， Service Ticket 仍然有效。 CAS 规定 Service Ticket 只能存活一定的时间，然后 CAS Server 会让它失效。通过在 web.xml 中配置下面的参数，可以让 Service Ticket 在多少秒内失效。
<context-param>
<param-name>e.yale.its.tp.cas.serviceTimeout</param-name>
<param-value>300</param-value>
</context-param>
该参数在业务应用的条件范围内，越小越安全。
l Service Ticket 是基于随机数生成的。
Service Ticket 必须足够随机，如果 Service Ticket 生成规则被猜出（如果你使用了 ST+Helloservice+ 自增序列的方式， Hacker 就可以构造下一个 Ticket ）， Hacker 就等于绕过 CAS 认证，直接访问所有服务。
❷ 登录那点事
client：提供用户名和密码或者是其他的认证凭证
server：验证client提供的认证凭证，记录登录状态
过程：访问系统时，client必须输入用户名和密码，server进行验证，验证通过后server建立一个叫做session的东西，然后把sessionId通过cookie发送给浏览器，下次登录的时候会带着cookie一起发过来，server从cookie中拿到sessionId就知道已经登录啦。
cookie和session的作用就是保持client和server的交互状态，这样一来可以将无状态的通信转化成有状态的交互，也就是让server有了“记忆”能力。
现在有三个服务，需要输入三次用户信息，但是如果有成百上千的服务呢？HOW???
参考上面简单登录的原理：服务端如何有了“记忆”能力呢：在client和server之间引入了一个中间层（cookie或者是session）。（题外话：计算机世界的99%的问题都可以通过一个引入一个中间层来解决）
所有我们可以想到一个可行的解决方案：对这个“中间层”做共享。
比如说先登录了A，就有了一个cookie，然后在用cookie去登录其他的系统。但是这样明显是有问题的：
1，cookie不能跨域，比如说a.com产生的cookie是不能传递给b.com的
2，就算cookie可以传递，但是其他系统并没有session来校验这个cookie。
解决方案：
1.cookie做共享可以挂到同一个一级域名下，比如A叫a.corp.com，B叫b.corp.com，C叫c.corp.com，这样cookie不就能共享了嘛
2，将session也做共享，从内存里面拿出来，放入一个大家都能访问的中间层里面，比如说redis。（题外话：又是中间层）
像下面这样：
可以解决多系统登录的问题么？可以解决！！！ 但是
1，要共享cookie就必须让所有的系统都在同一个域名下
2，多用户账号的存在。比如张三登录了A，然后去登录B，通过这种方式的话B需要去校验张三这个用户的合法性，此张三可能未必是彼张三！各个业务系统必须自己去维护自己系统的用户，而且用户信息还不止一个。
HOW？？？？
Single Sign One ：单点登录
消除多用户信息的问题，不用各个业务系统自己去维护用户信息，建立一个统一的用户认证中心（中间层：又是我哈哈哈），所有用户的认证工作都交给这个认证中心来完成。各个子业务只需要负责实现自己的业务即可，不在需要关心用户、认证等细节。
大致流程如下：
用户第一次访问A系统：www.a.corp.com，这个时候如果A发现用户没有登录的话，那他需要做的一项操作就是重定向认证中心：www.sso.com/login?redirect=www.a.corp.com。
其中www.sso.com/login就是认证中心的登录地址，redirect=www.a.corp.com就是登录完成后需要跳转到的地址。在认证中心登录之后认证中心会做以下几件事情：
1，建立一个session
2，发放ticket
3，重定向到你的地址，并在浏览器种下cookie信息。注意这个cookie是认证中心服务器的cookie哦。如：ssoid=1,domain=sso.com
需要注意的有两点：
1，进行了两次重定向。第一次是重定向到SSO的服务器，第二次是重定向我们的后端服务器。
2，流程完成后再浏览器种了两个cookie，一个是sso服务器的cookie，一个是子系统A的cookie。
接下来我们访问B系统：
这个时候会有三个cookie：
1，认证中心的cookie domain: sso.com
2，A系统的cookie domain： a.corp.com
3, B系统的cookie domain： b.corp.com
本质上就是保存了一个认证中心的cookie和多个子系统的cookie。一般我们称SSO的cookie的对应的会话成为全局会话，各自子系统cookie对应的会话称为局部会话。
概述
CAS（Central Authentication Service） 是 Yale 大学发起的一个企业级的、开源的项目，旨在为 Web 应用系统提供一种可靠的单点登录解决方法（属于 Web SSO）。
CAS 开始于 2001 年， 并在 2004 年 12 月正式成为 JA-SIG 的一个项目。
特性
1、 开源的、多协议的 SSO 解决方案；Protocols：Custom Protocol、CAS、OAuth、OpenID、RESTful API、SAML1.1、SAML2.0 等。
2、 支持多种认证机制：Active Directory、JAAS、JDBC、LDAP、X.509 Certificates 等；
3、 安全策略：使用票据（Ticket）来实现支持的认证协议；
4、 支持授权：可以决定哪些服务可以请求和验证服务票据（Service Ticket）；
5、 提供高可用性：通过把认证过的状态数据存储在 TicketRegistry 组件中，这些组件有很多支持分布式环境的实现，如：BerkleyDB、Default 、EhcacheTicketRegistry、JDBCTicketRegistry、JBOSS TreeCache、JpaTicketRegistry、MemcacheTicketRegistry 等；
6、 支持多种客户端： Java、 .Net、 PHP、 Perl、 Apache, uPortal 等。
体系结构
从结构上看，CAS 包含两个部分：CAS Server 和 CAS Client，CAS 需要独立部署，主要负责对用户的认证工作，CAS Server 会处理用户名 / 密码等凭证 (Credentials)。
负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到 CAS Server 进行认证。CAS Client一般与 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。过滤从客户端过来的每一个 Web 请求，同时， CAS Client 会分析 HTTP 请求中是否包请求 Service Ticket
术语
Ticket Granting ticket (TGT) ：可以认为是CAS Server根据用户名密码生成的一张票，存在server端
Ticket-granting cookie (TGC) ：其实就是一个cookie，存放用户身份信息，由server发给client端
Service ticket (ST) ：由TGT生成的一次性票据，用于验证，只能用一次。相当于server发给client一张票，然后client拿着这是个票再来找server验证，看看是不是server签发的。就像是我给了你一张我的照片，然后你拿照片再来问我，这个照片是不是你。。。没错，就是这么无聊。
安全性
TGC安全性：
对于一个 CAS 用户来说，最重要是要保护它的 TGC，如果 TGC 不慎被 CAS Server 以外的实体获得，Hacker 能够找到该 TGC，然后冒充 CAS 用户访问所有授权资源。从基础模式可以看出， TGC 是 CAS Server 通过 SSL 方式发送给终端用户，因此，要截取 TGC 难度非常大，从而确保 CAS 的安全性。TGT 的存活周期默认为 120 分钟。
ST安全性：
ST（Service Ticket）是通过 Http 传送的，因此网络中的其他人可以 Sniffer 到其他人的 Ticket。CAS 通过以下几方面来使 ST 变得更加安全：
1、 ST 只能使用一次
CAS 协议规定，无论 Service Ticket 验证是否成功， CAS Server 都会清除服务端缓存中的该 Ticket，从而可以确保一个 Service Ticket 不被使用两次。
2、 ST 在一段时间内失效
CAS 规定 ST 只能存活一定的时间，然后 CAS Server 会让它失效。默认有效时间为 5 分钟。
3、 ST 是基于随机数生成的
ST 必须足够随机，如果 ST 生成规则被猜出，Hacker 就等于绕过 CAS 认证，直接访问对应的服务。
流程
上图是3个登录场景，分别为：第一次访问www.qian.com、第二次访问、以及登录状态下第一次访问mail.qian.com。
第一次访问www.qian.com
标号1： 用户访问http://www.qian.com，经过他的第一个过滤器：org.jasig.cas.client.authentication.AuthenticationFilter（cas提供，在web.xml中配置）。主要作用：判断是否登录，如果没有登录则重定向到认证中心
标号2： www.qian.com发现用户没有登录，则返回浏览器重定向地址。
首先可以看到我们请求www.qian.com，之后浏览器返回状态码302，然后让浏览器重定向到cas.qian.com并且通过get的方式添加参数service，该参数目的是登录成功之后会要重定向回来，因此需要该参数。并且你会发现，其实server的值就是编码之后的我们请求www.qian.com的地址。
标号3： 浏览器接收到重定向之后发起重定向，请求cas.qian.com。
标号4： 认证中心cas.qian.com接收到登录请求，返回登陆页面。
上图就是标号3的请求，以及标号4的响应。请求的URL是标号2返回的URL。之后认证中心就展示登录的页面，等待用户输入用户名密码。
标号5： 用户在cas.qian.com的login页面输入用户名密码，提交。
标号6 ：服务器接收到用户名密码，则验证是否有效，验证逻辑可以使用cas-server提供现成的，也可以自己实现。
上图就是标号5的请求，以及标号6的响应了。当cas.qian.com即csa-server认证通过之后，会返回给浏览器302，重定向的地址就是Referer中的service参数对应的值。后边并通过get的方式挟带了一个ticket令牌，这个ticket就是ST（数字3处）。同时会在Cookie中设置一个CASTGC，该cookie是网站cas.qian.com的cookie，只有访问这个网站才会携带这个cookie过去。
Cookie中的CASTGC：向cookie中添加该值的目的是当下次访问cas.qian.com时，浏览器将Cookie中的TGC携带到服务器，服务器根据这个TGC，查找与之对应的TGT。从而判断用户是否登录过了，是否需要展示登录页面。TGT与TGC的关系就像SESSION与Cookie中SESSIONID的关系。点击这里了解Java如何操作Cookie。
TGT：Ticket Granted Ticket（俗称大令牌，或者说票根，他可以签发ST）
TGC：Ticket Granted Cookie（cookie中的value），存在Cookie中，根据他可以找到TGT。
ST：Service Ticket （小令牌），是TGT生成的，默认是用一次就生效了。也就是上面数字3处的ticket值。
标号7 ：浏览器从cas.qian.com哪里拿到ticket之后，就根据指示重定向到www.qian.com，请求的url就是上面返回的url。
标号8 ：www.qian.com在过滤器中会取到ticket的值，然后通过http方式调用cas.qian.com验证该ticket是否是有效的。
标号9 ：cas.qian.com接收到ticket之后，验证，验证通过返回结果告诉www.qian.com该ticket有效。
标号10 ：www.qian.com接收到cas-server的返回，知道了用户合法，展示相关资源到用户浏览器上。
第二次访问www.qian.com
标号11 ：用户发起请求，访问www.qian.com。会经过cas-client，也就是过滤器，因为第一次访问成功之后www.qian.com中会在session中记录用户信息，因此这里直接就通过了，不用验证了。
标号12 ：用户通过权限验证，浏览器返回正常资源。
访问mail.qian.com
标号13 ：用户在www.qian.com正常上网，突然想访问mail.qian.com，于是发起访问mail.qian.com的请求。
标号14 ：mail.qian.com接收到请求，发现第一次访问，于是给他一个重定向的地址，让他去找认证中心登录。
上图可以看到，用户请求mail.qian.com，然后返回给他一个网址，状态302重定向，service参数就是回来的地址。
标号15 ：浏览器根据14返回的地址，发起重定向，因为之前访问过一次了，因此这次会携带上次返回的Cookie：TGC到认证中心。
标号16 ：认证中心收到请求，发现TGC对应了一个TGT，于是用TGT签发一个ST，并且返回给浏览器，让他重定向到mail.qian.com
可以发现请求的时候是携带Cookie：CASTGC的，响应的就是一个地址加上TGT签发的ST也就是ticket。
标号17 ：浏览器根据16返回的网址发起重定向。
标号18 ：mail.qian.com获取ticket去认证中心验证是否有效。
标号19 ：认证成功，返回在mail.qian.com的session中设置登录状态，下次就直接登录。
标号20 ：认证成功之后就反正用想要访问的资源了。
配置filter
我们需要在应用的web.xml文件中配置四个Filter，这四个Filter必须按照固定的顺序来进行配置，而且它们必须配置在应用的其它Filter之前。它们的先后顺序要求如下：
1、AuthenticationFilter
casServerLoginUrl用来指定Cas Server登录地址，serverName或service用来指定认证成功后需要跳转地址。
2、TicketValidationFilter
请求通过AuthenticationFilter的认证之后，如果请求中携带了参数ticket则将会由TicketValidationFilter来对携带的ticket进行校验。 TicketValidationFilter只是对验证ticket的这一类Filter的统称，其并不对应Cas Client中的一个具体类型。Cas Client中有多种验证ticket的Filter，
都继承自，它们的验证逻辑都是一致的，都有实现，不同的是使用的TicketValidator不一样。这里我们使用Cas10TicketValidationFilter，也可以使用或Saml11TicketValidationFilter。
3、
用于将每一个请求对应的HttpServletRequest封装为其内部定义的CasHttpServletRequestWrapper，该封装类将利用之前保存在Session或request中的Assertion对象重写HttpServletRequest的getUserPrincipal()、getRemoteUser()和isUserInRole()方法。
这样在我们的应用中就可以非常方便的从HttpServletRequest中获取到用户的相关信息
4、AssertionThreadLocalFilter
AssertionThreadLocalFilter可以在应用的其它地方获取Assertion对象，找个过滤器会把Assertion对象存放到当前的线程变量中，我们在程序的任何地方都可以从线程变量中获取当前Assertion，就不需要再从Session或request中进行解析了。这个线程变量是由AssertionHolder持有的，我们在获取当前的 Assertion时也只需要通过AssertionHolder的getAssertion()方法获取即可
❸ 终于搞明白了，CAS单点登录原理解析！！
真的如老话所说，“没有笨的人，只有懒得人”。前段时间时间需要和其他项目做cas集成，于是乎在网上找了几篇教程看了一下，好了，很简单，学会了，开搞（自以为研究明白）。集成完事了，登录成功了，自以为这就过去了。然而，没过几天就出bug了，这下惨了，当初没有好好学出了问题都不知道咋解决。无奈，只得静下心来好好学习一番（当初太懒付出的代价）。原理其实很简单的，只要耐下心来好好研究终会搞懂的。
先看下图
那么是如何验证用户是否登录过呢？
如果session中包含“ const_cas_assertion ”属性，说明已经登录，跳过此过滤器执行配置的其他过滤器；
如果ticket参数不为空（可能是登陆后跳转回来的），跳过此过滤器，执行TicketValidationFilter 验证ticket；
如果前两个条件都不满足，重定向到cas服务端，返回登录页面进行登录操作。
Cookie中的CASTGC：向cookie中添加该值的目的是当下次访问 www.cas.server.com 时，浏览器将Cookie中的TGC携带到服务器，服务器根据这个TGC，查找与之对应的TGT。从而判断用户是否登录过了，是否需要展示登录页面。TGT与TGC的关系就像SESSION与Cookie中SESSIONID的关系。
TGT：Ticket Granted Ticket（俗称大令牌，或者说票根，他可以签发ST）。
TGC：Ticket Granted Cookie（cookie中的value），存在Cookie中，根据他可以找到TGT。
ST：Service Ticket （小令牌），是亏吵喊TGT生成的，默认是用一次就生效了。也就是上面的销野ticket值。
为了加深理解，也为了以后作参考，整理记录。另外，还要说一句碰滑，不要偷懒，多动手多动脑！
❹ 为什么有了tgt还要st
TGT是茄敬尘CAS为用户签发的登录票据，拥有了TGT，用户就可以证明自己在CAS成功登录过。
TGT是CAS为用户签发的登录ticket，也是颤禅用于验证用户登录成功的唯一方式。TGT封装了Cookie值以及Cookie值对应的用户信息，CAS通过Cookie值（TGC）为key查询缓存中有无TGT（TGC：TGT（key：value）），如果有的话就说明用户稿旁已经登录成。
ST是当用户访问某一服务时提供的ticket。用户在访问其他服务时，发现没有cookie或ST，那么就会302到CAS服务器获取ST。然后会携带着ST302回来。
❺ cas认证是什么认证
CAS是CentralAuthenticationService的缩写，中央认证服务，一种独立开放指令协议。
CAS是Yale大学发起的一个开源项目，旨在为Web应用系统提供一种可靠的单点登录方法，CAS在2004年12月正式成为JA-SIG的一个项目。
特点
1、开源的企业级单点登录解决方案。
2、CASServer为需要独立部署的Web应用。
3、CASClient支持非常多的客户端(这里指单点登录系统中的各个Web应用)，包括Java,.Net,PHP,Perl,Apache,uPortal,Ruby等。
原理和协议
从结构上看，CAS包含两个部分：CASServer和CASClient。CASServer需要独立部署，主要负责对用户的认证工作；
CASClient负责处理对客户端受保护资源的访问请求，需要登录时，重定向到CASServer。图是CAS最基本的协议过程：
CASClient与受保护的客户端应用部署在一起，以Filter方式保护受保护的资源。对于访问受保护资源的每个Web请求，CASClient会分析该请求的Http请求中是否包含ServiceTicket，
如果没有，则说明当前用岁竖户尚未登录，于是将请求重定向到指定好的CASServer登录地址，并传递Service（也就是要访问的目的资源地址），以便登录成功过后转回该地址。
用户在第3步中输入认证信息，如果登录成功，CASServer随机产生一个相当长度、唯一、不可伪造的ServiceTicket，并缓存以待将来验证，
之后系统自动重定向到Service所在地址，并为客户端浏览器设置一个TicketGrantedCookie（TGC），
CASClient在拿到Service和新产生的Ticket过后，在第5，6步中与CASServer进行身份核实，以确保ServiceTicket的合法性。
在该协议中，所有与CAS的交互均采用SSL协议，确保，ST和TGC的安全性。协议工作过程中会有2次重定向的过程，但是CASClient与CASServer之间进行Ticket验证的过程对于用户是透明的。
另外，CAS协议中还提供了Proxy（代理）模式，以适应更加高级、复杂的应用场景，具体介绍可以参考CAS官方网站上的相关文档。
(5)CAS50清除TGC缓存扩展阅读
使用CAS在Tomcat中实现单点登录中部署客户端应用
单点登录的目的是为了让多个相关联的应用使用相同的登录过程，本文在讲解过程中构造2个简单的应用，分别以casTest1和casTest2来作为示例，它们均只有一个页面，显示欢迎信息和当前登录用户名。
这2个应用使用同一套登录信息，并且只有登录过的用户才能访问，通过本文的配置，实现单点登录，即只需登录一次就可以访问这两个应用。
与CASServer建立信任关系
假设CASServer单独部署在一台机器A，而客户端应用部署在机器B上，由于客户端应用与CASServer的通信采用SSL，因此，需要在A与B的JRE之间建立信任关系。
首先与A机器一样，要生成B机器上的证书，配置Tomcat的SSL协议。
其次，下载http://blogs.sun.com/andreas/entry/no_more_unable_to_find的InstallCert.java，运行“javaInstallCertcompA:8443”命令，
并且在接下来出现的询问中输入1。
这样，就将A添加到了B的truststore中。如果多个客户端应用分别部署在不同机器上，那么每个机器都需要与CASServer所在机器建立信任关系。
配置CASFilter
准备好应用casTest1和casTest2过后，分别部署在B和C机器上，由于casTest1和casTest2，B和C完全等同，我们乎和大以casTest1在B机器上的配置做介绍，
假设A和B的域名分别为domainA和domainB。
将cas-client-java-2.1.1.zip改名为cas-client-java-2.1.1.jar并拷贝到casTest1/WEB-INF/lib目录下，修棚春改web.xml文件，添加CASFilter，如清单10所示：
清单10.添加CASFilter
<web-app>...<filter><filter-name>CASFilter</filter-name>
<filter-class>e.yale.its.tp.cas.client.filter.CASFilter</filter-class><init-param>
<param-name>e.yale.its.tp.cas.client.filter.loginUrl</param-name><param-value>https://domainA:8443/cas/login</param-value>
</init-param><init-param>
<param-name>e.yale.its.tp.cas.client.filter.validateUrl</param-name>
<param-value>https://domainA:8443/cas/serviceValidate</param-value></init-param>
<init-param><param-name>e.yale.its.tp.cas.client.filter.serverName</param-name>
<param-value>domainB:8080</param-value></init-param>
</filter><filter-mapping>
<filter-name>CASFilter</filter-name>
<url-pattern>/protected-pattern/*</url-pattern></filter-mapping>
</web-app>
对于所有访问满足casTest1/protected-pattern/路径的资源时，都要求到CASServer登录，如果需要整个casTest1均受保护，可以将url-pattern指定为“/*”。
从清单10可以看到，我们可以为CASFilter指定一些参数，并且有些是必须的，表格1和表格2中分别是必需和可选的参数：
表格1.CASFilter必需的参数
表格2.CASFilter可选参数
传递登录用户名
CAS在登录成功过后，会给浏览器回传Cookie，设置新的到的ServiceTicket。但客户端应用拥有各自的Session，我们要怎么在各个应用中获取当前登录用户的用户名呢？
CASClient的Filter已经做好了处理，在登录成功后，就可以直接从Session的属性中获取，如清单11所示：
清单11.在Java中通过Session获取登录用户名
1//以下两者都可以
2session.getAttribute(CASFilter.CAS_FILTER_USER);
3session.getAttribute("e.yale.its.tp.cas.client.filter.user");
在JSTL中获取用户名的方法如清单12所示：
清单12.通过JSTL获取登录用户名
1<c:outvalue="${sessionScope[CAS:'e.yale.its.tp.cas.client.filter.user']}"/>
另外，CAS提供了一个CASFilterRequestWrapper类，该类继承自HttpServletRequestWrapper，主要是重写了getRemoteUser()方法，
只要在前面配置CASFilter的时候为其设置“e.yale.its.tp.cas.client.filter.wrapRequest”参数为true，就可以通过getRemoteUser（）方法来获取登录用户名，具体方法如清单13所示：
清单13.通过CASFilterRequestWrapper获取登录用户名
=newCASFilterRequestWrapper(request);2out.println("Thelogonuser:"+reqWrapper.getRemoteUser());
❻ 【单点登录】CAS协议
CAS协议是专门为CAS开发的一种简单而强大的基于票据的协议。
CAS涉及到一个或多个客户端与一个服务端，客户端嵌入CASified应用程序(称为“CAS服务”)，而CAS服务器是一个独立组件:
1.CAS服务器负责对用户进行身份验证并授予对应用程序的访问权
2.CAS客户端保护CAS应用程序，并从CAS服务器检索被授予用户的标识。
关键概念：
1.存储在CASTGC cookie中的 TGT (票据授予票据)表示用户的一个SSO session。
2. ST (服务票证)作为url中的GET参数传输，表示由CAS服务器为特定用户授予认证应用程序的访问权限。
WEB流程：
1.用户访问目标应用程序，通过浏览器发送GET请求到目标应用
2.目标应用检测到用户未认证，则转发请求到CAS服务端，带上查询参数service，值为目标应用地址。
3.CAS服务端检测用户发现没有SSO session 则返回CAS登录页面。
4.用户在CAS登录页面填写登录表单，提交进行认证。
5.认证成功后CAS服务端创建SSO session,并创态携建TGT票据到Cookie中 （Set-Cookie:CASTGC=TGT-xxxxxx），并重定向到目标应用程序带上查询参数ticket=ST-xxxxx。
6.目标应用发送请求向CAS服务器验证ST票据，验证成功后目标应用创建用户访问session,并把sessionID放入cookie中。
7.用户访败闭悄问目标应用通过sessionID获取到session,登陆成功。
8.用户访问其他CAS客户端应用，其他CAS客户端重定向请求到CAS服务器，同步骤2。
9.CAS服务器检测到用户TGT这个cookie,获取到SSO session，直接认证成功，并重定向到目标应用程序带上查询参数ticket=ST-xxxxx。
10.同步骤6，察渣7，成功登陆其他CAS客户端应用。
❼ 2022-03-10 CAS认证流程
CAS认证流程图：
(1) 用户通过浏洞弊览器访问指定瞎和页面；
(2) 页面对应的后台进行安全校验：检查service-ticket和access token是否存在，若不存在，则 重定向 到CAS服务器 /cas/login/；
(3) CAS服务纳神族器要求用户提供SSO登录凭证；
(4) 用户提供用户名和密码给CAS服务器；
(5) CAS服务器将service ticket和 service URL返回给后台；
(6) 后台发送验证请求给CAS服务器检验service ticket和service URL是否匹配；
(7) 若后台得到service ticket和service URL匹配，返回前台浏览器，TGC一并存储到浏览器中；
(8) 浏览器访问指定页面；
❽ 从http验证流程解析CAS单点登录
JAVA单点登录有好多种方式，譬如用cookie的domain做，用中间代理做等等，但都需要自行做许多开发工作。而其中耶鲁大学的开源项目CAS提供了一个一站式解决方案，只需很少的扩展即可轻松实现企业级单点登录。基础知识网上其他挺多的，这里我就不详述了。本文通过分析http请求过程中http header，cookie等数据剖析了cas（ 非代理模式，默认验证逻辑。其他如restletAPI等可扩展逻辑本文不会覆盖 ）的验证流程，在开发调试中提供了另一种方便的方式掌控整个流程的关键点 。
TGT: cas服务端生成的每个用户唯一的ticket。
TGC: cas服务端根据TGT生成的每个用户的cookie,其value是TGT。
ST: cas服务端根据每个应用，每个用户生成的一个ticket,验证一次就销毁。
Shiro: JAVA权限管理框架
下面将通过两个客户端应用A、B分别跟cas server端交互来详述整个交互流程。本文基于CAS 4.x。 CAS 5.X默认逻辑一致，只不过通过spring boot进行了重新模块划分。
Cas client拦截请求发现session中无cas assertion(其实就是用户名和ticket)并且没有ST则跳转CAS server(本项目由于用了shiro重写拦截逻辑所以是判断shiro中有没有保存验证后的用户信息), server端发现无TGC跳转配置的CAS登陆URL
Response返回302指示重定向。同时可见response返回两个cookie: CASPRIVACY=和CASTGC= TGT-1--cas01.example.org
也就是说：cas server端验证通过后产生ST并在location URL后面赋给ticket。此时往客户端浏览器写入TGC,并且指示浏览器重定向到location位置，其正是客户端应用验证ST的路径。
此步骤产生2个ticket: TGT,ST;产生一个cookie:TGC,此cookie是通过用户私密信息与TGT加密生成。
此时客户端应用由于受到shiro的保护，request cookie中就不是JSESSIONID而是shiro的SessionId：sid，uuid模式，其与第一步中的sid一致。
Response返回302指示重定向到另一个页面(第一次访问的页面或者shiro配置的successful url)，同时可见生成了新的session和sessionID。同时可见response返回2个cookie: JSESSIONID,为servlet容器产生的session id，其为location中的jsessionid；rememberMe,为shiro为自动登录配置的。
此步骤验证ST后（通过url connection去cas server验证ST）如果通过则重定向到新页面(第一次访问的页面或者shiro配置的successful url)产生一个新的容器session id。（为何要重新创建session，因为其会在新的session中保存登陆了客户端应用的凭证CAS Assertion,其为客户端验证ST后返回的）到了这步骤以后属于客户端自身的逻辑。CAS作用到此为止。
可以看到这次直接就访问了，也没有经过验证ticket和与cas服务端交互。此是因为session中已经保存了cas assertion，所以算作登陆了。
可见产生了新的shiro session，并提示跳转CAS服务端登陆URL。
可见并没有要求登陆而是直接就提示跳转到location的URL做验证并产生了一个新的ST。这是因为CAS服务端读取了A应用登陆后在浏览器生成的TGC, request cookie中带入了（下图可以看到），从而认为用户已经登陆，所以直接生成ST，并要求重定向到客户端应用B去验证。
步骤同A应用。
如图
如下图：
可见登出时发生四次请求。
直接访问CAS server端的登出url。Cookie中有CASTGC和server端的JSESSIONID。
返回中CASTGC清空，CASPRIVACY清空。 此时说明server端已经清除了A应用的ST和浏览器的CASTGC
跳转到了客户端应用，发现新创建了shiro session（sid）和servlet容器session（JSESSIONID）
并且发现rememberMe和SID的cookie都被换成deleteMe啦。 此为shiro的loginout拦截器干的好事。
正常访问首页，但是因为没登陆所以提示要重定向到CAS服务端去登陆。（如果有了首页就改为跳转到首页）
同原来步骤。
总的来说，cas （非代理模式，默认验证逻辑） 是用一个cookie(TGC), N个session(N个子系统session，其中存储了cas receipt)来保证各应用的统一登录。