1. First understand a few concepts
1), TGC: Ticket-granting cookie, a cookie that stores user authentication credentials, used in the communication between the browser and the CAS Server.
2), TGT: ticket granting ticket, the ID of the TGT object is the value of the TGC, on the server side, the TGT is queried through the TGC. TGT encapsulates the TGC value and the user information corresponding to this cookie value.
3), ST: service ticket, a ticket issued by CAS for a user to access a service, ST is issued by TGT.
2. The process of single sign-on
Now there are System A, System B, and Certification Center.
When a user accesses system A for the first time:
1) The user accesses the system A through the browser https://localhost:8443/spring-shiro-cas/index, and the system A cannot obtain the local session. At this time, the system A needs to do an additional operation, which is to redirect to the authentication center
2) Request https://localhost:8443/cas-server/login? service = https://localhost:8443/spring-shiro-cas/cas , the authentication center sees whether the browser carries TGC, if it does not, return The cas login form lets users log in.
service The function of the parameter can actually be considered as a callback. url（在cas客户端也就是系统A配置）After passing the server authentication in the future, it will be redirected to System A. /cas is the address of the interceptor, which receives the cas server ticket, and then passes it to casFilter to process the verification ticket after interception.
But there is another role here is the registration service. In short, the registration service is to let our authentication center know which systems have completed login here. One of the important purposes is to complete the single-point logout function.
3) The user enters the username and password, the verification is correct, creates a global session TGT on the server, and sets the cookie TGC, path=/cas-server
Redirect to system A, and carry the verification ticket ST, https://localhost:8443/spring-shiro-cas /cas ?ticket=ST-39-2Vh3Ee6xYUs4y0XTy4bw-cas01.example.org
System A sees that the access address is /cas and hands it to casFilter for processing.
4) The casfilter of system A sends the ticket obtained in the address bar to the certification center for ticket verification. The authentication center verifies that the ticket is valid, and returns the user login information to system A, which creates a local session locally. And set cookie, path=/spring-shiro-cas
Redirect the request resource.
5) Request https://localhost:8443/spring-shiro-cas/index, carry a cookie, the system verifies the cookie session, and returns the resource page to the browser after passing.
When the user accesses system A for the second time:
1) The user visits https://localhost:8443/spring-shiro-cas/index again with a cookie. System A finds the local session through the cookie, which proves that the user has logged in to the system before.
2) System A returns the restricted resource to the user.
When a user accesses system B for the first time:
1) The user accesses the system B https://localhost:8443/spring-shiro-cas-2/index through the browser, and the system A cannot obtain the local session. At this time, the system B needs to do an additional operation, which is to redirect to Certification Center
2) Request https://localhost:8443/cas-server/login? service = https://localhost:8443/spring-shiro-cas-2/cas , the authentication center will check whether the browser carries TGC, and see if there is , to obtain the global session TGT, which proves that you have logged in.
3) Redirect to system B and carry the verification ticket ST, https://localhost:8443/spring-shiro-cas-2 /cas ?ticket=ST-56-2bb3Ee6xYUskkdTy4bw-cas01.example.org
4) System B sends the ticket obtained in the address bar to the certification center for ticket verification. The authentication center verifies that the ticket is valid, and returns the user login information to system B, which creates a local session locally. And set cookie, path=/spring-shiro-cas-2
Redirect the request resource.
5) Request https://localhost:8443/spring-shiro-cas-2/index, carry the cookie, the system verifies the cookie session, and returns the resource page to the browser after passing.
Question: How does CAS solve the problem that cookies cannot be cross-domain?
As mentioned in the authentication process described above, the path of the cookie TGC generated by the authentication center to pass the cookie to the browser after verifying the user's login is in /cas-server, as long as the requested path includes https://localhost:8443/cas-server, Then CAS can know that the current user has already logged in, but due to cross-domain reasons, the client (application system) cannot directly obtain the cookie, so the client cannot directly trust the current user.
So the process is that the browser accesses the client. The client says that I can't know who you are (no cookie). You go to the authentication center to see if he has your information.
浏览器找到认证中心（这时携带身份凭证cookie TGC了），认证中心说：“我知道你是谁，你拿着这个登录票据ticket去找客户端。”
浏览器把ticket给了客户端，客户端说：“你稍等，我向认证中心确认下你这个票据是不是他给的”，得到确认后客户端终于把浏览器请求的资源返回给它。
这个地方不理解原理的时候很容易认为用户登录系统A之后，系统A会存放登录状态session，生成cookie给浏览器path=/spring-shiro-cas，但是由于跨域的原因，在访问系统B的时候，系统B又拿不到这个cookie.那怎么知道它有没有登录过呢？
这种想法就是错误的！！
要清楚首次单点登录的时候是会产生两个cookie的，一个是CAS和浏览器的全局会话，一个是应用系统和浏览器的局部会话。
系统A和浏览器的session-cookie是局部会话，确实访问系统B的时候不起作用了。
但是！！因为登录系统A的时候是去的认证中心，身份凭证是存放在CAS 服务器中，是全局会话，用户再首次访问任何一个系统都会要求去认证中心看有没有这个东西，所以只要登录过一次，后面都会带上。
我们再来回顾下这个过程
1. 单点登录的过程中，第一步应用服务器将请求重定向到认证服务器，用户输入账号密码认证成功后，只是在浏览器和认证服务器之间建立了信任(TGC)，但是浏览器和应用系统之间并没有建立信任。
2. ST是CAS认证中心认证成功后返回给浏览器，浏览器带着它去访问应用系统，应用系统再凭它去认证中心验证你这个用户是否合法。只有这样，浏览器和应用系统才能建立信任的会话。
3. 而TGC的作用主要是用于实现单点登录，就是当浏览器要访问应用系统2时，应用系统2也会重定向到认证中心，但是此时由于TGC的存在，认证中心信任了该浏览器，就不需要用户再输入账号密码了，直接返回给浏览器ST，重复2中的步骤。
最后来个官方详细图解：
