cas 原理 与 流程
之前做了一个cas的需求（上篇随笔），搞了好久，下决心要搞懂cas，然后找了篇博文，对照源码，哇塞！这博文写的简直太棒了，我这里做了简化
类似自己的笔记，后面记录了博文出处。 唉，怎么做需求的时候没看到这文章呢....
主要看/WEB-INF/login-webflow.xml里面的流程，然后对应/WEB-INF/cas-servlet.xml跟代码
举例:（我这里简写了，具体代码等后续贴，先看流程，很简单）首次访问集成了CAS-Client的web应用1
以下登录流程都在/WEB-INF/login-webflow.xml跟；
初始化：
initialFlowSetupAction的doExecute（），这里主要是将TGT、warnCookieValue、service参数放在FlowScope作用域中
1，流程一：
ticketGrantingTicketExistsCheck，因为是第一次访问，flowScope.ticketGrantingTicketId（TGT） == null,所以转到流程二
2，流程二：
gatewayRequestCheck，这里的gateway也不存在，转到流程三
3，流程三：
serviceAuthorizationCheck的doExecute(),这里要做的就是判断FlowScope作用域中是否存在service，如果service存在，查找service的注册信息。
初始化的时候已经将service放在了FlowScope作用域中了，所以存在。那么转到流程四
4，流程四：
generateLoginTicket，在这个流程中DefaultUniqueTicketIdGenerator会生成以LT作为前缀的LoginTicket（example:LT-FASFsdfkjsdf67asdff）,这个ticke是casLoginView.jsp的一个隐藏参数，也只会在登录的时候用到。GenerateLoginTicketAction会将LoginTicket放到FlowScope中，然后来到流程五
5，流程五：
viewLoginForm，这时候会流转到CAS单点登录服务器端的登录页面/WEB-INF/jsp/ui/default/casLoginView.jsp，输入用户名、密码submit提交之后，在这里会进到authenticationViaFormAction的doBind()
现在说登录验证流程：
上面说了输入用户名、密码submit提交之后，在这里会进到authenticationViaFormAction的doBind()，然后开始流程
以下登录验证流程也在/WEB-INF/login-webflow.xml跟；
1，流程一：
realSubmit，AuthenticationViaFormAction的submit(),各种登录业务逻辑都可以在这里做
AuthenticationViaFormAction的submit要做的就是判断FlowScope和request中的loginTicket是否相同。如果不同跳转到错误页面，如果相同，则根据用户凭证生成TGT（登录成功票据），并放到requestScope作用域中，同时把TGT缓存到服务器的cache<ticketId,TGT>中。跳转到流程二
2，流程二：
sendTicketGrantingTicket的doExcute(),在这里做的就是是获取TGT，并根据TGT生成cookie添加到response。跳转到流程三
3，流程三：
serviceCheck，这里是看service是否存在。很显然，在登录流程初始化的时候就将service放到flowScope中了。跳转到流程四
4，流程四：
generateServiceTicket的doExecute（）这里要做的是获取service和TGT，并根据service和TGT生成以ST为前缀的serviceTicket（example：ST-2-GGHJjgyhgbada67sdas），并把serviceTicket放到requestScope中。
5，流程五：
warn,由于此时FlowScope中不存在warnCookieValue。跳转到流程六
6，流程六：
redirect，从requestScope中获取serviceTicket，构造response对象，并把response放到requestScope中。跳转到流程七
7，流程七：
postRedirectDecision，由于请求（http://localhost:8080/cas/login?service=http%3A%2F%2Ftest.xhqb.com%3A80%2Fmarketmgr%2F）是get请求，跳转流程八
8，流程八：
redirectView
此时流程如下：
1、跳转到应用系统（http://127.0.0.1:8090/webapp1/main.do?ticket=ST-1-4hH2s5tzsMGCcToDvGCb-cas01.example.org）。
2、进入CAS客户端的AuthenticationFilter过滤器，由于session中获取名为“_const_cas_assertion_”的assertion对象不存在，但是request有ticket参数，所以进入到下一个过滤器。
3、TicketValidationFilter过滤器的validate方法通过httpClient访问CAS服务器端（http://127.0.0.1:8081/cas-server/serviceValidate?ticket=ST-1-4hH2s5tzsMGCcToDvGCb-cas01.example.org&service=http://127.0.0.1:8090/webapp1/main.do）验证ticket是否正确，并返回assertion对象。
------------------------------以上介绍了1、登录流程流转 2、登录验证流程流转；单点登录还有很多其他web应用，下面讲解当第一个web应用1登录成功时，第二个的登录流程流转---------
访问第二个应用，首先初始化InitialFlowSetupAction的doExecute（），进到流程一
1，流程一
ticketGrantingTicketExistsCheck，因为web应用1已经成功登录，所以request的cookies中存在TGT，并保存到FlowScope中，跳到流程二
2，流程二
hasServiceCheck，这时候FlowScope中存在service，跳转到流程三
3，流程三
renewRequestCheck，这时候request中不存在renew，跳转到流程四
4，流程四
generateServiceTicket。这里的流程流程和web应用1是一样的了，可以参考web应用1的流转流程
完。
原文出处：https://blog.csdn.net/dovejing/article/details/44523545 结构大体一致，只是做了简化
