前提
cas server的url: https://server.cas.com:8443/cas
cas client的url:https://app2.server.cas.com:8001/
cas server版本5.3.14
cas client版本3.5.0
代码实现参考：
1、浏览器向客户端发起请求
先通过过滤器AuthenticationFilter，先通过url判断是否是可以免认证，通过ignoreUrlPatternMatcherStrategyClass，正则匹配策略的类进行定义。然后， 取请求中的session和session中的assertion。
如果session和assertion为空时，说明还未登录，cas client 会构造一个重定向到cas server的url 返回给浏览器。格式如下所示：
https://server.cas.com:8443/cas/login/?service=http%3A%2F%2Fapp1.cas.com%3A8082%2F
2、重定向到服务端
https://server.cas.com:8443/cas/login/?service=http%3A%2F%2Fapp2.server.cas.com%3A8082%2F
3、服务端显示登录界面和用户登录（即登录验证）
浏览器重定向到服务端后，链接中的/login 对应到login-webflow.xml。webflow里面定义了登录的流程。
先初始化（initializeLoginAction），再展示casLoginView的视图，填写用户名和密码后，提交，如果认证（authenticationViaFormAction）成功，则创建TGT（createTicketGrantingTicket），否则根据认证结果，走不同的流程。
先讲两个非常重要的配置类
CasSupportActionsConfiguration为登录web-flow中expression中action的初始化配置类
DefaultLoginWebflowConfigurer为通过代码的形式定义web-flow（不包含login-webflow.xml里面的几个节点）
举例说明
可以看到新版本通过DefaultLoginWebflowConfigurer定义启动action为initialFlowSetupAction，旧版本通过web-flow.xml定义启动action为initialFlowSetupAction。
再举例讲一下新版本通过代码定义web-flow
定义了flow节点的name为initialAuthenticationRequestValidationCheck、flow的action为initialAuthenticationRequestValidationAction和成功后下一个flow节点为ticketGrantingTicketCheck
接着，我们开始看认证过程。
webflow中的initializeLoginAction 对应的实现类为InitializeLoginAction
webflow中的authenticationViaFormAction 对应的实现类为 InitialAuthenticationAction
webflow中的createTicketGrantingTicket 对应的实现类为CreateTicketGrantingTicketAction。
其中，initializeLoginAction类很简单，这里不做分析。首先，分析authenticationViaFormAction，具体调用过程。
先到CasSupportActionsConfiguration根据“authenticationViaFormAction ”找到对应的类InitialAuthenticationAction
进入InitialAuthenticationAction可以看出初始化和Action对应的doExecute()方法均在AbstractAuthenticationAction
final Event finalEvent =this.initialAuthenticationAttemptWebflowEventResolver.resolveSingle(requestContext);
final Event finalEvent =this.initialAuthenticationAttemptWebflowEventResolver.resolveSingle(requestContext);
调用initialAuthenticationAttemptWebflowEventResolver的resolveSingle方法，InitialAuthenticationAttemptWebflowEventResolver只实现了resolveInternal方法。所以，完整的调用链如下所示。
关于Cas的认证过程参考下面的博客，讲解得非常细致，我不再赘述。大家只要了解两个对象的含义，credential为用户提供的认证凭据principal为认证后添加的用户属性（包括sessionId和Token等自构造的信息）
https://www.cnblogs.com/tyroz/p/12106441.html
我只补充一点，PolicyBasedAuthenticationManager的authenticateInternal方法，会将所有实例化的authenticationHandler进行逐个的认证。实例化后的authenticationHandler，分别代入authenticateAndResolvePrincipal方法进行认证。
通过spring.factories文件，可以将我们自定义的MyAuthenticationHandler注册到认证执行计划中。这样authenticateAndResolvePrincipal就可以调到MyAuthenticationHandler。
下面就是创建TGT
CentralAuthenticationService的实现为DefaultCentralAuthenticationService，该实现在cas-server-core模块里面，作用为TGT、ST的生成、存储、检测
4、重定向到客户端登录地址，返回ticket和TGT
生成票据后，cas server会返回给浏览器一个重定向地址，地址格式如下
http://app2.server.cas.com:8082/?ticket=ST-4-8srAV1Nt6XBz0HJwBEl684aFuYcPC201906081002
其中ticket为票据，
5、客户端传输服务和票据给服务端进行验证
通过客户端的校验过滤器Cas30ProxyReceivingTicketValidationFilter实现，具体实现由AbstractUrlBasedTicketValidator的validate方法实现。
6、cas服务端验证成功返回用户信息
服务端返回的认证结果如下所示
客户端的过滤器Cas30ProxyReceivingTicketValidationFilter的具体实现过滤器，拿到服务端的返回结果后，将serviceResponse转成assertion，再重定向浏览器到客户端的访问地址。
重定向到客户端的访问地址。http://app2.server.cas.com:8082/
参考文章：
1、https://blog.csdn.net/qq_34021712/category_9278675.html（讲解构建cas服务端和客户端环境）
2、https://my.oschina.net/woniuyi/blog/4449262 （讲解登录和登出流程的博客）
代码参考
