Really, as the old saying goes, “There are no stupid people, only lazy people”. Some time ago, I needed to integrate CAS with other projects, so I found several tutorials on the Internet and read them. Ok, it is very simple. I have learned them and started doing them (I thought I understood them). The integration is done, the login is successful, and you think you’re done. However, not a few days out of the bug, this next miserable, had not learned the problem do not know how to solve. Helpless, had to calm down to learn a good (at the beginning too lazy to pay the price). The principle is actually very simple, as long as the patience to study will eventually understand.
Look at the picture below
Disassembly instructions for each step in the figure:
First, the user accesses www.cas.client.com. After receiving the request, the CAS client determines whether the user logs in. The authentication process is performed in the AuthenticationFilter. AuthenticationFilter checks whether the user logs in. If the user does not log in, the user is redirected to the login page.
So how do you verify that the user is logged in?
If the session contains const_cas_ASSERTION, you are logged in. Skip this filter and run other filters.
If the ticket parameter is not empty (it may be returned after login), run the TicketValidationFilter command to verify ticket.
If neither of the preceding two conditions is met, the CAS server is redirected to return to the login page for login.
If you find that the user is not logged in, redirect the browser to www.cas.server.com with a parameter service. The parameter value is the requested address in step 1.
③ : After receiving the request, the CAS server returns the login page to the browser.
④ The user enters the user name and password and submits them to the CAS server for authentication.
⑤ : The CAS server verifies that the user name and password are valid.
CASTGC in Cookie: The purpose of adding this value to the Cookie is that the next time you visit www.cas.server.com, the browser carries the TGC in the Cookie to the server, and the server looks up the corresponding TGT based on this TGC. To determine whether the user has logged in and whether the login page needs to be displayed. A TGT is to a TGC what a SESSION is to a SESSIONID in a Cookie.
TGT: Ticket Granted Ticket (commonly known as a large token, or Ticket stub, he can issue ST).
TGC: Ticket Granted Cookie (value in Cookie), stored in Cookie, based on which the TGT can be found.
ST: Service Ticket (small token), which is generated by the TGT and takes effect after being used once by default. So that’s the ticket value up here.
6:www.cas.client.com After ticket is obtained, the TicketValidationFilter is displayed, which verifies whether ticket is valid.
7:www.cas.server.com verifies the ticket after receiving it. The verification result is returned to inform www.cas.client.com that the ticket is valid.
Today:www.cas.client.com returns the requested resource to the browser.
In order to deepen the understanding, but also for future reference, sorting records. Also, don’t be lazy, use your hands and brains more!
Refer to the article, https://blog.csdn.net/javaloveiphone/article/details/52439613 https://www.cnblogs.com/lihuidu/p/6495247.html https://blog.csdn.net/xiao__gui/article/details/38082761Copy the code* Like a small partner move small hands, little attention. Follow the official wechat account [programmer Mark Chou] to get more advanced Java architecture materials (“Spring Cloud micro services practice“”Deep analysis of Spring source code“”In-depth understanding of Apache Dubbo and combat“”Practice guide for front-line architects“”25 topics Java Interview Questions Manual“”Java surface by“…) .
